Менеджмент

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

Как контролировать разработку сайтов, веб-приложений и информационных систем на удалёнке. Разбираем учёт задач, серверную инфраструктуру, дедлайны и KPI.

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

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

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

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

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

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

Тимлид проверяет, готова ли задача. До старта разработки менеджер должен понятно её описать и дать все необходимые материалы.

Тимлидов набираем из разработчиков Ratio

Так надёжнее

Также тимлид отвечает за качество кода и предварительную оценку трудозатрат (estimation).

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

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

Менеджер завершает производственный цикл: принимает задачу у тимлида и, если всё хорошо, делает пометку «завершёна».

Если нужны правки — задача возвращается на доработку. При этом тимлид учитывает, что могут возникнуть баги, поэтому в estimation уже заложено время на исправление косяков.

Учёт задач мы ведём в сервисе 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.

Если в задаче появился блокирующий вопрос, она отправляется в To be Discussed и ждёт ответа от менеджера или тимлида.

У разработчика локально развёрнута актуальная копия проекта, над которым он работает — чтобы мы не потеряли код из-за проблем с интернетом. Перед деплоем проект заливается на тестовую площадку. Когда тесты пройдены, разработчик устанавливает статус Fixed — это задачи, которые ждут проверки кода.

У тимлида есть список задач в статусе Fixed. На проверку отводятся сутки.

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

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

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

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

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

Серверная инфраструктура в Ratio

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

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

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

Для версионирования используем Git: feature-ветки, ветка разработки и боевая ветка — как у правильных ребят. Репозитории хранятся на GitHub, там же тимлиды проверяют код.

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