Как состав команды разработки влияет на успех проекта. Объясняем в цифрах

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

Иногда эта идея продиктована тем, что руководители не понимают, какую роль в команде играют некоторые специалисты — например, UX-исследователь, скрам-мастер или проджект-менеджер. Но чаще они попросту осторожничают, опасаясь, что проект не взлетит — и считают более безопасным донанять специалистов по ходу дела.

Это не приводит ни к чему хорошему. Приведу пример из практики. Однажды перед компанией, куда я пришел на роль менеджера по продукту, встала задача организовать прием карт через мобильное приложение вместо POS-терминалов. Для разработки продукта требовалась полная продуктовая команда, но менеджмент решил начать с усеченной. Проект удалось закончить — но если бы команда изначально была полной, то вышло бы в два раза быстрее, а ROI был бы выше в десятки раз. Почему так — поясню ниже.

Кто входит в усеченную команду

Чем усеченная команда разработки отличается от полной? В ее состав обычно входят:

• продакт-менеджер,
• аналитик,
• проджект-менеджер / скрам-мастер,
• бэкенд-разработчик,
• фронтенд-разработчик,
• тестировщик,
• UI/UX дизайнер.

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