Как выстроить работу с выделенной командой

Когда компания подключает к продукту выделенную команду, разработчики включаются в рабочие процессы и берут задачи из общего бэклога. Если подрядчику передали только стек технологий и список задач, команда быстро теряет связь с продуктом: тикеты закрываются, а решения начинают расходиться с планами заказчика. Чтобы этим процессом можно было управлять, сторонам нужно заранее договориться о целях, ответственности и порядке работы с изменениями.

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

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

Сначала формулируют задачу бизнеса

Перед тем как искать специалистов, подрядчику важно понять, зачем заказчику нужна внешняя команда. Просто запроса «нужны разработчики с таким-то стеком» для этого недостаточно.

На старте заказчик и подрядчик договариваются:

• какую часть продукта забирает внешняя команда;
• какого результата от неё ждут;
• какие изменения планируются дальше;
• где заканчивается её зона ответственности.

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

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

Настроить порядок работы с изменениями

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

Поэтому изменения проходят через последовательный процесс, и на каждом шаге видно, кто за него отвечает:

1. Внутренняя команда заказчика описывает, что изменилось и зачем это нужно продукту.
2. Внешняя команда оценивает, какие задачи придётся сдвинуть и как запрос повлияет на загрузку, технический долг и сроки.
3. Менеджер подрядчика собирает варианты действий и показывает последствия каждого.
4. Владелец продукта со стороны заказчика выбирает вариант и утверждает приоритет.
5. После этого задача попадает в бэклог или в текущий спринт.

Для приоритизации заранее назначают ответственных за каждый шаг и фиксируют SLA на рассмотрение изменений. Тимлид внешней команды понимает, что делать с загрузкой, а заказчик видит цену каждого нового запроса ещё до того, как задача попадёт в работу.

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

Включить внешнюю команду в процессы проекта

Выдать внешним разработчикам доступ к репозиторию и добавить задачи в трекер недостаточно: команде нужен тот же контекст, с которым работает внутренняя команда заказчика. Для этого внешнюю команду подключают к основным процессам проекта: добавляют в рабочие чаты и на встречи; зовут на ретроспективы и обсуждения задач; проводят код-ревью по общим правилам; назначают наставника на время онбординга.

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

Подготовить проект к ротации специалистов

Специалисты внешней команды могут переходить на другие проекты или покидать команду, за поиск замены и подключение нового сотрудника отвечает только подрядчик, и процесс лучше выстроить заранее:

1. найти специалиста под требования заказчика;
2. передать ему текущие задачи и контекст проекта;
3. подключить к встречам и рабочим каналам;
4. оформить доступы и нужные документы.

Уходящий специалист передаёт свою зону ответственности, а новый проходит онбординг и постепенно забирает задачи. Внутренняя команда заказчика помогает разобраться в продукте, а менеджер подрядчика следит за передачей знаний и сообщает сроки замены, чтобы избежать ситуации, когда проект временно остается без исполнителя.

Сообщать о рисках вместе с решением

Проблемы на проекте случаются в любом случае: задача оказывается сложнее, требования меняются, сроки приходится пересчитывать. Главное, что нужно сделать подрядчику — передать заказчику нужные данные, на основании которых можно принять решение.

Менеджеру внешней команды нужно зафиксировать: что произошло; какие задачи и сроки это затрагивает; какие варианты есть у команды; сколько времени потребует каждый вариант; кто отвечает за следующий шаг.

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

Понять, когда исполнитель стал партнёром

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

Обычно заказчик:

• заранее обсуждает с подрядчиком планы проекта;
• советуется по организации работы;
• подключает внешнюю команду к сложным кросс-функциональным задачам;
• учитывает её при планировании ресурсов и бюджета.

На этом этапе от менеджера подрядчика ждут инициативы. Он может предложить варианты улучшения процесса, описать риски и показать, что получит проект в каждом сценарии. Контекст бизнеса и финальное решение остаются у команды заказчика.

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

По такому принципу в Centicore Group выстраивается работа выделенных команд: погружение специалистов в контекст проекта, подключение их к процессам заказчика и предварительное согласование порядка взаимодействия. Подробнее о компании и проектах можно узнать на centicore.ru.

Что в итоге

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

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