Управление разработкой в распределённой команде

В Ratio мы продаём разработку на заказ. Чтобы решать наши задачи, производственный процесс должен:

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

Роли в производственном процессе

В проекте обязательно участвуют трое: менеджер, тимлид и разработчик.

Учёт задач мы ведём в сервисе YouTrack от JetBrains.

Параметры задачи в YouTrack

В YouTrack у задачи есть поля с дополнительной информацией. Вот какими пользуемся мы:

• Assignee — исполнитель. Менеджер указывает тимлида, тимлид — разработчика;
• Due Date — внутренний дедлайн;
• Estimation — оценка срока выполнения задачи, в часах;
• Priority — приоритет. Три основных значения: Normal (обычная задача), Major (важно, но не критично), Critical (важно). Есть ещё Show-stopper — когда что-то сломалось настолько, что вредит бизнесу клиента;
• Spent time — потраченное время;
• State — статус задачи. Все возможные статусы мы перечислили в регламенте ниже.

Требования, дедлайн, оценка

Главное правило при постановке задачи: исполнитель должен понять всё с первого раза и точно знать, что от него потребуют в итоге.

В список тимлида задача попадает в статусе Open, но иногда в ней не хватает понятного описания или материалов. Работа тимлида — не пропускать сырые задачи и говорить менеджеру чего не хватает.

Готовую задачу тимлид передаёт исполнителю. Если видит, что один человек не справится — делит работу на части. Перед стартом тимлид ставит дедлайн и оценивает, сколько времени займёт выполнение задачи. Если в дальнейшем срок увеличивается, то нужно согласовать это с менеджером.

Разработчик может не согласится с оценкой. Так тимлид понимает, что требования сформулированы неправильно или у разработчика недостаточно информации. Например, он может быть не в курсе, что часть работы уже сделана на другом проекте.

Для простоты используем правило «взялся — ходи», как в шахматах. Если разработчик начал выполнять задачу — значит, он принял оценку и обещает закончить в срок.

Система KPI

Для разработчиков мы используем три основных KPI:

• выработка — за 40-часовую рабочую неделю разработчик обязан выполнить задач на 35 часов. Ещё пять закладываем на коммуникацию и мелочи, которые не учитываются в трекере;
• попадание в оценку — отклонение от предварительной оценки времени на выполнение (estimation) не должно превышать 20%;
• дедлайн — задачи должны быть выполнены в согласованный срок. Если в качестве дедлайна указан только день, значит задача должна быть готова к 19:00 по мск.

Например, 10-часовая задача с дедлайном на завтра должна быть выполнена максимум за 12 часов и не позже 19:00 завтрашнего дня.

Если не дотягиваешь по выработке, то получишь меньше: как поработал, так и заработал. Превысил оценку более, чем на 20% — будет оплачено только оценённое, а не фактически затраченное время. Поэтому разработчики заранее предупреждают, если есть риск превысить estimation или не успеть до дедлайна.

Переработка свыше 35 часов в неделю допускается в пределах 20%, чтобы не выгорать. Сверхурочные часы оплачиваются.

Рабочий процесс

Когда разработчик принимается за задачу, он меняет её статус на In Progress — в этот момент запускается таймер. Если нужно отвлечься или передохнуть, задача переходит в Paused, таймер останавливается. Когда разработчик вернулся — снова ставит In Progress.

Менеджер следит за списком Ready to Check. Чтобы проверить задачу, он переключает ветку git на тестовом сервере и проходит по тест-плану. Если всё круто, задача получает
статус Verified — проект готов к развёртыванию.

Деплой на боевом сервере

В статусе Verified задача возвращается к тимлиду. Он заливает результат на боевой сервер по одной из трёх схем:

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

После деплоя тимлид присваивает задаче статус Deployed.

Завершение задачи

Менеджер проверяет проект на боевом сервере. Если всё хорошо — задача получает заветный статус Completed. Ура, мы справились.

Если на продакшене оказывается неработающий код, то релиз откатывается обратно. Но такое случается редко, критические ошибки менеджер и тимлид замечают на этапах Fixed и Ready to Check.