Проектная команда (Task force)

Общее описание #

Проектная команда (task force, strike team) — это временная кросс-функциональная команда, которая собирается под конкретную цель: реализовать проект, запустить продукт, решить кризисную проблему. После достижения цели команда распускается, а участники возвращаются в свои постоянные отделы или переходят в новые проектные команды.

Ключевое свойство, которое отличает проектную команду от матричной структуры, — временность и одинарное подчинение. Участник на время проекта подчиняется руководителю проекта, и только ему. Двойного подчинения функциональному руководителю нет — функциональный отдел выступает «источником кадров», а не второй линией управления.

Исторически эта модель пришла из проектного менеджмента и военной терминологии (task force — оперативное соединение под конкретную задачу). В IT она применяется для запуска новых продуктов, миграций, кризисных доработок и крупных разовых задач, которые не вписываются в регулярный продуктовый цикл.

Что из себя представляет #

Состав проектной команды кросс-функциональный: в неё входят все роли, необходимые для достижения цели проекта. Типичный набор:

• руководитель проекта (project manager, иногда — product owner)
• разработчики нужных специализаций (бекенд, фронтенд, мобильная разработка)
• QA-инженер
• аналитик и/или дизайнер (если проект этого требует)
• DevOps-инженер (для инфраструктурных проектов)

Размер — 5-12 человек. Команда больше 12 человек обычно неэффективна как единая проектная единица: её выгоднее разбить на подкоманды с общим координационным ядром.

Срок жизни — от нескольких недель до года. Короткие task force (кризисные, «потушить пожар») живут недели-месяцы. Длинные проектные команды (запуск нового продукта с нуля) могут существовать 6-12 месяцев, после чего либо распускаются, либо трансформируются в постоянную продуктовую команду, если продукт пошёл в регулярную эксплуатацию.

Управление и распределение задач и ролей #

• Руководитель проекта — единственный руководитель команды на время её существования. Он:
  • формирует план проекта и milestones;
  • распределяет задачи между участниками;
  • отвечает за результат перед заказчиком или бизнесом;
  • управляет бюджетом, сроками, рисками.
• Участники подчиняются руководителю проекта на время работы. Их функциональные руководители (из тех отделов, откуда они пришли) не вмешиваются в ежедневную работу — они только «отпустили» человека в проект.
• Заказчик / спонсор проекта — представитель бизнеса, который ставит цель и принимает результат. С ним взаимодействует руководитель проекта, а не вся команда.

Планирование обычно идёт через классический проектный цикл: цели → декомпозиция → план с этапами → контроль исполнения → приёмка. В отличие от продуктовой команды, которая работает итеративно и непрерывно, проектная команда чаще использует вехи (milestones) и формальную приёмку результата.

Требования к участникам #

• Готовность к быстрому старту. Проектная команда собирается под цель, и времени на долгий онбординг нет. Участники должны быстро вникать в контекст — особенно если приходят из разных продуктовых команд или отделов.
• Универсальность. В проектной команде часто не хватает «чистого» специалиста на каждую роль, и участники должны быть готовы выходить за рамки специализации: бекендер может взять на себя часть DevOps-задач, аналитик — часть тестирования.
• Самостоятельность. Руководитель проекта не может контролировать каждый шаг — он управляет планом в целом. Участники должны уметь брать задачу и доводить её до результата без микроменеджмента.
• Толерантность к неопределённости. Проекты часто начинаются с неполных требований и меняются по ходу. Участники должны быть готовы к пересмотру плана, а не требовать идеального ТЗ.
• Готовность к завершению. В отличие от продуктовой команды, проектная команда заканчивается. Участники должны быть готовы вернуться в свой постоянный отдел или перейти в новый проект — это часть модели, а не сбой.

Когда лучше всего подходит и почему #

• Запуск нового продукта с нуля. Когда нет ещё регулярной разработки и нужно быстро сделать MVP, проектная команда — естественная форма: собрали людей, сделали, запустили. Если продукт «взлетает», команда может трансформироваться в продуктовую.
• Крупные разовые задачи и миграции. Перенос системы на новую архитектуру, интеграция после M&A, переезд инфраструктуры — это проекты с чёткой целью и концом, а не бесконечная разработка. Проектная команда подходит идеально.
• Кризисные доработки (task force в узком смысле). Продакшен-инцидент, потеря ключевого клиента, срочная доработка под регулятор — небольшая команда экспертов собирается на недели, решает проблему и распускается.
• Исследовательские и R&D-проекты. Когда цель — проверить гипотезу или сделать прототип, а дальше неясно. Проектная команда позволяет выделить людей на время эксперимента без обязательств содержать их в этой роли постоянно.
• Аутстаффинг и работа под клиента. Клиент платит за конкретный проект — команда собирается под него, сдаёт результат и распускается (или переходит на следующий проект клиента).

Когда хуже всего подходит и почему #

• Непрерывная продуктовая разработка. Если продукт живёт и развивается постоянно, проектная команда — неправильная модель: она распускается, а продукт требует постоянного владения. Здесь нужна продуктовая команда.
• Задачи без чёткой цели и конца. Проектная команда работает, когда есть определённый результат и момент «готово». Если цель размыта («улучшать качество продукта»), команда будет существовать бесконечно без реального завершения — это вырождается в плохо оформленную продуктовую команду.
• Команды, где важна долгосрочная ответственность за продукт в продакшене. Проектная команда сдаёт результат и уходит. Если после сдачи начинаются проблемы в продакшене, ответственных уже нет — они распущены. Для продуктов с долгой жизнью это риск.
• Частая смена проектов без накопления экспертизы. Если сотрудники постоянно прыгают между проектными командами, они не успевают накопить предметную экспертизу ни в одном продукте. Качество работы падает, а онбординг в каждый новый проект съедает время.
• Малые организации с одним продуктом. Если компания делает один продукт, держать проектную структуру бессмысленно — проще сформировать постоянную продуктовую команду.

Главное отличие от матричной структуры #

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

• Проектная команда — временная, с одинарным подчинением руководителю проекта. После цели команда распускается.
• Матричная структура — постоянная модель с двойным подчинением: функциональному руководителю (solid line) и проектному (dotted line). Сотрудник остаётся в функциональном отделе всегда.

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