Сравним подходы и расскажем, в каких случаях стоит выкупить команду, а в каких работать по Fixed Price.
Fixed Price подходит для небольших проектов с понятным набором задач, выкуп команды — для сложных сервисов в активной фазе развития или проектов с высокой степенью неопределённости. Рассказываем о плюсах и минусах каждого формата и как их можно совмещать на больших проектах.
Fixed Price — это формат сотрудничества, при котором заказчик платит за работу подрядчика одну согласованную и закреплённую договором сумму. Это может быть оплата всего проекта разом, либо работу делят на этапы, и каждый оплачивают отдельно.
- 1. Если вы точно знаете, что хотите получить в результате, и можете чётко сформулировать своё видение продукта и требования к нему.
- 2. У вас небольшой проект с ограниченным объёмом стандартных работ. Например, вам нужен лендинг ко дню рождения компании.
- 3. Вам нужно быстро запустить MVP на рынок, и вы хотите точно знать сроки и стоимость разработки.
- 1. Риски несёт только исполнитель — он должен выполнить проект в рамках согласованной суммы и сроков. Если возникнут непредвиденные сложности или изменения — это проблема компании, которая оказывает услуги.
- 2. Заказчику не нужно тратить время на контроль расходов на проекте.
- 3. Заказчик знает точную стоимость проекта и может планировать свои траты.
- 1. Заказчик не может вносить изменения в проект без дополнительной оплаты. Приходится тщательно прорабатывать все детали разработки ещё до начала работы. Подготовка и согласования отнимают много времени.
- 2. Во время разработки приоритеты бизнеса могут измениться, и заказчик захочет изменить структуру проекта. Исполнитель может отказаться вносить изменения, если они не вписываются в бюджет или нарушают соглашение.
- 3. Чтобы не выйти за бюджет, подрядчик закладывает часть суммы проекта на риски:— запас часов на гарантийное обслуживание;— риски на простои команды из-за пауз в согласованиях;— технические риски реализации, если задача окажется сложнее, чем оценил техлид;— запас на дополнительные пожелания заказчика.Это влияет на конечную стоимость. В некоторых случаях почасовая оплата может обойтись дешевле.
Выкуп команды — формат сотрудничества, в котором из специалистов компании-разработчика формируют отдельную команду для работы только над одним продуктом. Сотрудников подбирают с учётом требований и специфики проекта. В команду могут входить любые специалисты, например менеджер, тимлид, аналитики, разработчики, дизайнеры, тестировщики.
Оплата работы команды происходит по модели Time and Material — за потраченные часы специалистов на решение задач.
- 1. У инхаус-команды не хватает экспертизы или ограниченный опыт. Аутстафф в этом кейсе не спасёт. Выкуп команды поможет настроить внутренние процессы, связанные с управлением, аналитикой, проектированием, дизайном, разработкой, тестированием или техподдержкой.
- 2. У бизнеса не хватает ресурсов и нет времени на найм новых сотрудников. Особенно, когда речь идёт о краткосрочной загрузке. В таких случаях можно нанять аутстафф, но такими сотрудниками кто-то должен управлять. А расширять управленческую команду ещё сложнее, чем искать рядовых исполнителей. В то время как выкупленной командой руководит менеджер на стороне подрядчика.
- 3. У продукта редкий стек технологий. Найм разработчиков может занять месяцы, выкупить готовую команду и погрузить их в задачи можно за неделю.
- 4. Сложно определить точный объём и сроки работы заранее. Например, после запуска MVP, когда продукт переходит в фазу активного развития. Первые пользователи дают обратную связь, которую нужно быстро брать в работу — делать интерфейс понятнее и удобнее, развивать новую функциональность. Заранее определить набор работ на полгода вперёд в таком случае просто невозможно.
- 1. Заказчик может вносить изменения в проект и в состав команды в любой момент. Если в новом спринте не нужен дизайнер — его можно снять с задач и не оплачивать его часы.
- 2. Не нужно никого обучать: команда приходит, получает информацию и сразу начинает работу — только обеспечьте доступы. При этом смена участника в команде не приводит к потере контекста всего проекта подрядчиком, как это часто бывает в аутстаффе.
- 3. Заказчик платит только за то, что ему нужно, а исполнитель получает оплату за сделанную работу.
- 4. Работа по T&M требует меньше юридических согласований — не нужно каждый раз подписывать допсоглашения с фиксированным составом работ и их стоимостью. Разработка идёт быстрее, процесс становится более гибким и управляем.
- 5. Заказчик покупает не только работу команды, но и выстроенный процесс разработки с постоянными отчётами и полным контролем проекта менеджером.
- 6. У команды разработчиков, работающих в качестве постоянных сотрудников, более глубокое понимание бизнес-процессов и целей компании. Это позволяет им более эффективно работать над проектом и создавать продукт, который будет соответствовать требованиям заказчика.
- 7. Команда быстро реагирует на изменения в проекте и внедряет новые идеи. Это позволяет заказчику быстрее адаптироваться к рыночным изменениям и получать конкурентные преимущества.
- Заказчик не может точно знать, сколько будет стоить проект в итоге и когда он будет завершен. Чтобы этого избегать, мы перед каждым месяцем согласуем с заказчиком лимиты по бюджету. На каждом проекте выделяем совместно управляемые приоритеты, чтобы сделать самое важное и не выйти за пределы установленных сумм.
- Заказчик должен следить за ходом работы и контролировать расходы. Исполнитель должен вести подробную документацию о потраченных часах и готовых задачах. Если в компании выстроены процессы автоматизации, как у нас, с этим не возникает проблем. Как мы считаем деньги в разработке, читайте по ссылке.
- Заказчик может получить недоделанный или некачественный продукт, если не установит чётких критериев успеха. Исполнитель может потерять мотивацию, если не видит конечной цели. Избежать этих последствий поможет проактивный менеджер проекта, который не просто перетаскивает тикеты в таск-трекере, а следить за достижением бизнес-целей заказчика.
Мы прибегаем к формату Fixed Price (фиксированный бюджет), Fixed Time (фиксированные сроки), Flex Scope (гибкий набор задач) во время разработки MVP. Закрепляем договором сроки и стоимость разработки, но оставляем заказчику возможность менять список задач в бэклоге в рамках оговоренного бюджета. Такой подход позволяет придерживаться чёткого плана работ и распределять ответственность внутри проекта. При этом мы оставляем место для гибкости на случай, если приоритеты бизнеса изменятся во время разработки, и какие-то функции потребуется разработать раньше.
FFF формат идеально подходит для запуска продукта с нуля. На этом этапе важно быстро зарелизить сервис, чтобы он начал приносить деньги и привлекать клиентов. В таких проектах важны закреплённые договором сроки и стоимость разработки.
После запуска MVP мы подключаемся к полноценной поддержке сервиса командой, которая его разрабатывала. Для этого предлагаем выкуп команды.
После запуска продукт переживает фазу активного развития, особенно в первые 6-12 месяцев. Пользователи начинают взаимодействовать с продуктом и давать обратную связь. Нужно быстро обрабатывать данные и на их основе дорабатывать сервис.
Команда, которая занималась разработкой MVP, уже погружена в бизнес-цели заказчика и понимает особенности продукта. Таких специалистов проще зафиксировать на фултайм за проектом для его развития.
- Следить за обновлением технических компонентов.
- Рефакторить код, чтобы избегать легаси.
- 3аниматься доработкой новой функциональности, которую заложили в рамках проектирования, но не включили в MVP.
- Анализировать данные о пользователях и предлагать улучшения.
- Настраивать производственные процессы в инхаус-команде.
Выкуп команды происходит по T&M — это выгоднее в долгосрочной перспективе, поскольку в T&M не включают проценты на риски. Работа по T&M более гибкая и управляемая, так как не нужно каждый раз подписывать допсоглашения с фиксированным составом работ и их стоимостью.
Если кратко, то Fixed Price подходит для простых и стандартных проектов, а выкуп команды и T&M — для сложных и инновационных с непредсказуемым набором задач.
Если вы разрабатываете что-то сложнее сайта-визитки или MVP с ограниченным набором функций, стоит рассмотреть работу по T&M. В долгосрочной перспективе этот формат выгоднее, так как позволяет специалистам брать в работу задачи без долгих юридических согласований, а также в оплату не входят проценты, заложенные на риски. В разработке сложных сервисов с нуля мы смешиваем форматы: MVP разрабатываем по FFF, развитие сервиса ведём по T&M с выкупом команды.