Как топменеджеры-программисты со сроками облажались ч.4 (заключительная)

А теперь квинт-эссенция ошибок…

Когда разработчик пилит проект, он видит свою часть задач, когда тимлид смотрит на то как работает команда, он видит общий результат.

А дьявол кроется в деталях, и вот пример:

Фронтендеру сказали разверстать и прикрутить логику к интерфейсу.

И задача кажется вполне понятной и простой - 3 дня на разработку.

После изучения макетов и документации, он приступает к работе.

Но, у него появляются вопросы, которые не очевидны в доках, или не были там учтены.

Он обращается за консультацией к аналитикам.

Получив информацию, выясняется что есть ошибки в макетах.

Он обращается к дизайнеру.

Дизайнер вносит доработки.

Но, они меняют логику компонента, который разработчик первоначально оценивал.

Он продолжает свою работу, и выясняется что его компонент взаимосвязан с другим компонентом.

А в нем есть ошибка или недоработка, которую приходится устранять.

Параллельно приходится думать над архитектурой и видоизменять ее, чтобы все не превратилось в большой комок говна. Да, все делается в попыхах, но не совсем бездумно.

Параллельно он занимается код-ревью других разработчиков, а учитывая что все работают в спешке, этих МР достаточно много, и код в них ну…так себе.

Кто закладывал время на ревью? Никто не закладывал время на ревью…

Бекенд для данной фичи не готов, приходится прикручивать Моки.

Кто закладывал время на прикручивание моков? Никто…

И тут еще приходят видоизменения от дизайнеров, которые не меняют бизнес логику, но меняют логику работы компонентов фронта, и это добавляет работы.

Итого, 3 дня превращаются в 6-7.

И, подобные процессы происходят на всех этапах, у всех сотрудников - аналитики бегают по созвонам и уточняют требования, бекендеры сидят на митингах и уточняют какие данные и как нужно отдавать фронтам, и тд. и тп.

Умножаем это все на количество задач, потом на количество сотрудников. И получаем удвоение сроков разработки (а то и утроение с учетом информации из предыдущих статей).

Почему, когда выставлялся срок на разработку руководством (с опытом, вродебы в разработке), не был учтен этот живой и многогранный процесс?

Я ничего особенного не описал выше, это обычная рутина на большинстве активно разрабатываемых проектов, это не неожиданность.

Но, так или иначе, если судить о процессе с точки зрения одного разработчика, и не учитывая остальных игроков команды, да, на 3 дня делов.

А если предположить, что придется взаимодействовать еще с 10-20 людьми в команде, то реальность больно бьет по фантазиям.

Мне кажется, именно это неумение видеть проект с точки зрения команды, воспринимать команду как большой организм и приводит к таким ошибкам в планировании.

Почему облажалось именно руководство?

При назначении срока выполнения, ответственность ложится на того кто этот срок назначил.

Если программист говорит что сделает задачу за 1 день, это его ответственность.

Если руководство говорит что его команда сделает проект за месяц, это ответственность руководства.