Если в продуктовой разработке важно уметь забить на мелочи (смотри заметку про Продуктового забиваку), то в проектной разработке важно замечать мелочи и не забивать на них.
Проект = фронт + бюджет + срок.
Не забивать на мелочи в проекте важно, потому что внешние метрики проекта сильно от них зависят. Метрики такие: выполнить фронт работ и оставить заказчика довольным.
Выполненный фронт позволит закрыть текущий проект, а довольный заказчик — это отзывы и новые проекты.
Если заказчик видит, что на мелочи "забивают" или просто пропускают, то он думает: "Что же там тогда, если поглубже копнуть!?"
А если заказчик начинает усиленно копать, то проект начинает двигаться по формальной стороне — закрыть фронт. В итоге всем тяжело: у разработчика — тяжёлый заказчик, у заказчика — тяжёлый проект, которому он уделяет повышенное внимание, и "неумеха" разработчик, которому надо пальцем показывать.
Проектные мелочи — это не только, когда кнопки ровные во всех браузерах и ничего не едет.
Это:
* тексты без опечаток и ошибок,
* внимание к мнениям заказчика, которые он высказывает,
* умение увидеть, что фронт работ некорректный (глупости в ТЗ), обосновать это и улучшить,
* своевременное информирование заказчика о ходе работ,
* обещать = сделать.
Гарантийный срок не панацея
Некоторые очень сильно верят в силу фразы: "Если в процессе работы что-то найдётся, то есть гарантийный срок, в который мы поправим". Я её и сам много раз говорил.
В розовом мире после этих слов должно произойти безапелляционное принятие работ.
Но с прожжёнными заказчиками, которым итог действительно важен, так не работает. Пока проект не сдан — заказчик ТРЕБУЕТ, а исполнитель шустрит. Когда начинается гарантийный срок — заказчик ПРОСИТ, а исполнитель планирует исправление или и вовсе "это не баг". Это все понимают.
Будьте внимательны!
.......................
В этом месте принято просить лайки и подписаться на канал, а я не буду — смотрите сами 😉.
Эта заметка из моего телеграм-канала @proudobstvo — про UX, продуктовую разработку и саморазвитие.