Как состав команды разработки влияет на успех проекта. Объясняем в цифрах
Когда компания создает продукт на быстрорастущем рынке, то перед ней стоит вполне конкретная задача — в короткие сроки провести исследование, разработать решение и выкатить его, пока это не сделали конкуренты. Казалось бы, эта задача понятна большинству фаундеров, и поначалу они готовы нанять под нее полноценную продуктовую команду. Однако мнение часто меняется при оценке затрат на проект. Тогда и рождается идея начать разработку с командой в усеченном составе.
Иногда эта идея продиктована тем, что руководители не понимают, какую роль в команде играют некоторые специалисты — например, UX-исследователь, скрам-мастер или проджект-менеджер. Но чаще они попросту осторожничают, опасаясь, что проект не взлетит — и считают более безопасным донанять специалистов по ходу дела.
Это не приводит ни к чему хорошему. Приведу пример из практики. Однажды перед компанией, куда я пришел на роль менеджера по продукту, встала задача организовать прием карт через мобильное приложение вместо POS-терминалов. Для разработки продукта требовалась полная продуктовая команда, но менеджмент решил начать с усеченной. Проект удалось закончить — но если бы команда изначально была полной, то вышло бы в два раза быстрее, а ROI был бы выше в десятки раз. Почему так — поясню ниже.
Кто входит в усеченную команду
Чем усеченная команда разработки отличается от полной? В ее состав обычно входят:
- продакт-менеджер,
- аналитик,
- проджект-менеджер / скрам-мастер,
- бэкенд-разработчик,
- фронтенд-разработчик,
- тестировщик,
- UI/UX дизайнер.
Фултайм работают только два разработчика и продакт, остальные — на частичной занятости. Иначе говоря, четыре из семи участников команды либо задействованы в нескольких проектах сразу, либо работают на аутсорсе ограниченное количество часов.