Включаем разумный контроль
– рассказывает Павел, руководитель frontend-отдела

В предыдущем посте я поделился одной из частых проблем на проектах – непопадание разработчика в дедлайны. Этот и другие негативные кейсы можно избежать, если отследить в самом зачатке и отработать. Основной инструмент здесь – контроль. Моя цель сегодня – ещё раз подсветить его важность и дать must-have практики: от созвонов до процессных моментов.
Это не ноу-хау, но иногда надо возвращаться к базе и проводить экспресс-скрининг. А то бывает уходишь в дебри, работаешь со сложными инструментами, а за ними забываешь о простом и сердитом)

1. Ежедневный статус голосом. Здесь отслеживаем, чем человек занимался в течение дня, и определяем есть ли у него проблемы. Если команда большая или поджимают сроки, статус можно собирать текстом. А возникшие вопросы – обсуждать точечно. Важно (!): один раз в неделю обязательно нужен созвон для обсуждения вопросов голосом.

2. Ежедневные коммиты.
Даже если задача выходит за рамки одного дня и не завершена, необходимо чтобы сотрудник коммитил свою работу за день. В таком случае мы:
▪️ понимаем, что сотрудник пишет код, который соответствует кодстайлу, и движется в правильном направлении;
▪️ снижаем вероятность, что в задаче на 20 часов активная работа начинается в последние 8;
▪️ в случае если разработчик заболел, (/недоступен для связи/ уволился/ у него вышел из строя компьютер/ компьютер украли…) максимальная потеря кода будет не более 8 часов.

3. Декомпозиция задач
Лучше, чтобы подзадача не занимала более 6 часов. Бывают редкие ситуации, когда задачу разбивать мельче чем на 10–15 часов избыточно – тут в игру вступают ежедневные коммиты.

4. Распределение задач
У тимлидов существует подход – давать сотруднику максимально разноплановые задачи, чтобы любой мог заменить любого. Я и сам его приверженец: люблю, чтобы задачи у разработчиков были посильные, но и в то же время достаточно сложные и интересные для них. Так сотрудник постоянно развивается и сохраняет высокий уровень мотивации и лояльности проекту и компании.
К сожалению, в реальной разработке абсолютизировать этот подход не получается. Часто у нас есть на выполнение задачи 8 часов, и мы не можем позволить себе дать её джуну, который будет сидеть с ней в 2–3 раза дольше.
Чем слабее сотрудник, тем более мелкие задачи ему нужно давать: лучше ~ 2–4 часа. Это же правило действует для сотрудников на этапе погружения, чтобы:
▪️ быстрее определить реальный уровень сотрудника,
▪️ быстро заметить, если сотрудник не справляется,
▪️ снизить уровень стресса сотрудника на входе.

5. Актуальная и понятная документация по производственным процессам
В каком состоянии документация на проекте? – Если не описан Flow, то первым делом внимания требуют:
▪️ правила описания задачи при её создании,
▪️ правило перехода задачи из одного статуса в другой, кто становится ответственным для каждого статуса;
▪️ git-flow проекта: правило создания, именования, мёрджа и удаления веток + правило описания коммитов.
На написание инструкции нужно не более четырёх часов + ознакомительный созвон. Чтобы зафиксированные правила выполнялись, первые три недели потребуется пристальное внимание, а когда все привыкнут, усилий нужно гораздо меньше.
Наличие этого документа на 3–5 страницы экономит часы времени на погружении и минимизирует вопросы в процессе работы.

6. Линтер и форматировщик кода*
Пункт со звёздочкой, потому что не всегда получается внедрить линтер. Когда кодовая база уже большая, добавление 3–5 правил может привести к исправлению десятков, а порой и больше сотни файлов. В устоявшейся команде, которая уже привыкла работать без линтера (да, такие существуют) весьма не просто внедрить такие изменения. И часто дело не только в привычке, но и в горящих сроках. Запланировать внедрение и рефакторинг всё-таки надо – на менее активные периоды разработки.