Разработчик не попадает в дедлайны – о чём это может говорить
– рассказывает Павел, руководитель frontend-отдела

Представим ситуацию. Разработчик говорит, что на решение задачи ему понадобится две недели.
А дальше события могут развиваться по-разному, самые критичные варианты выглядят примерно так:
1. Через две недели тимлид пришёл к сотруднику в надежде увидеть результат – оказалось, для решения нужно ещё две недели.
2. Задача выполнена в срок, но после тестирования выявлено большое количество багов. На их устранение нужна минимум неделя.
3. Задача выполнена, но на ревью выяснилось: код не соответствует принятому стайлгайду, UI и компоненты написаны с нуля, хотя их можно было взять из UI-кита. Приведение кода к желаемому виду также займёт одну, а то и две недели.

*
Я больше 10 лет в коммерческой разработке и последние 3 года выполняю роль тимлида на проектах, а также руковожу отделом ~50 разработчиков, которые задействованы на разных продуктах по масштабу и сложности. И могу сказать, что некорректное планирование задачи на самом деле распространено. На какие моменты обратить внимание руководителю, если он столкнулся с подобным?

Возможные причины
🔹 Отсутствие промежуточного контроля. Если слепо верить в корректность оценки сотрудника, можно заметить проблему слишком поздно – когда уже нет возможности скорректировать действия. А «подвести» может и достаточно опытный разработчик: например, он давно не уходил в отпуск – его продуктивность снизилась, а он продолжает оценивать «как раньше».
🔹 Несоответствие уровня решаемых задач и компетенций сотрудника. Здесь всё просто: чем выше уровень задач относительно уровня навыков разработчика, тем выше неопределённость в результате (по времени и качеству).
🔹 Нарушенные коммуникации. Например, сотруднику сообщили, что готовый компонент таблицы уже есть на проекте. Он лежит в репозитории, и его просто нужно взять.
🥁🥁🥁
Репозиториев 12 :) Тимлид в отпуске и не отвечает уже третий день. Другие участники не могут сказать, где лежит этот компонент, а сроки горят. В итоге он пилит свой велосипед, списывает на него 8 часов. На ревью через неделю ему говорят: всё удалить и использовать наше, «ведь мы же говорили взять имеющийся». Это мало того что удорожает разработку, но также в высшей степени демотивирует сотрудника.
Здесь ещё играет роль отсутствие поддержки со стороны команды и плохое погружение сотрудника.

В четверг напомню список must-have практик, которые помогают избегать подобных кейсов 👆