Февраль, 2015

Fixed price VS Dedicated team: какую схему финансового взаимодействия выбрать?

Опубликовано: 10.02.2015 | 4116

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

(Модель Time & Material стоит отдельного рассмотрения; вы обязательно прочтете о ней в наших следующих статьях. Сравнительную таблицу со всеми тремя моделями вы можете изучить здесь.)


С точки зрения клиента

1. Модель с фиксированной ставкой (Fixed price model).

Когда использовать:

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

Модель с фиксированной ставкой любит грамотно и тщательно составленную документацию. Документацию, требования в которой не будут меняться с направлением ветра, настроением и чем бы то ни было. Конечно, договариваться с подрядчиком можно о чем угодно, но если проект идет полным ходом, а вы решаете перевернуть все с ног на голову – пеняйте на себя. И имейте в виду, что дедлайн (с большой вероятностью) будет просрочен, а релиз проекта – задержан.

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

2. Модель с выделенной командой (Dedicated team model).

Когда использовать:

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

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

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

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

И не бойтесь, что мнение подрядчика будет идти вразрез с тем, что оптимально для вас, ведь обстоятельства одни. Впрочем, вот вам мнение разработчиков относительно каждой из моделей взаимодействия.

С точки зрения разработчика

Чтобы быть как можно более объективными, мы обсудили вопрос с теми из наших разработчиков, которые имеют опыт более 3 лет и успели за это время поработать как в выделенной команде, так и в проектах с фиксированной оценкой. И вот, что из этого вышло…

Преимущества выделенной команды:

  • Некоторые люди любят знать, что они будут делать следующие несколько месяцев, поэтому они предпочитают стабильность работы в выделенной команде.
  • Модель выделенной команды позволяет разработчику получить более глубокие знания технологий проекта. Осознание того, что скорее всего придется поддерживать проект после окончания его разработки, заставляет разработчиков более четко продумывать его архитектуру, масштабируемость и т.д.
  • Ежедневное общение с заказчиком или его представителем – обязательное требование для таких проектов. Это повышает коммуникативные навыки разработчиков и улучшает взаимопонимание между клиентом и командой.


Минусы выделенных команд:

  • На каждом проекте есть более или менее интересные задачи. Так вот задачи по доработке и поддержке проектов, как правило, относятся к не самым интересным. К примеру, одна из наших команд тратила более 20% времени на техподдержку разных проектов заказчика. И это удручало.
  • Поскольку любая выделенная команда – это «компания внутри компании», команда подчиняется всем процессам заказчика. Иногда эти процессы отличаются от тех, к которым они привыкли в своей компании. Тут важную роль играет способность конкретного специалиста приспосабливаться к новым условиям: все очень индивидуально.
  • У выделенных команд обычно упрощенные спецификации на разработку нового функционала или проекта. Это дает им определенную свободу: возможность предлагать свои решения поставленных задач, вместо того чтобы слепо следовать написанным спецификациям. Но и здесь есть свои оговорки: буквально каждое такое решение должно быть согласовано с владельцем продукта на стороне клиента до начала его разработки, что требует от специалиста настойчивости в обосновании своих решений.


Преимущества проектов с фиксированной ценой:

  • Некоторые разработчики, напротив, любят изменения. Каждый новый проект требует изучения новых технологий, подходов и решений. И четкий дедлайн воспринимается некоторыми специалистами как вызов: достаточно ли они хороши, чтобы справиться с задачей в короткие сроки?
  • Понятные спецификации позволяют более полно взглянуть на проект.
  • Новый проект, к примеру стартап, может рассмотреть предложенное подрядчиком техническое решение, которое наилучшим образом подойдет для реализации проекта, разработки его архитектуры, подбора необходимых инструментов и т.д.
  • Уже на стадии оценки разработчики «разбивают» проект на отдельные задачи, так что клиент заранее представляет, как будет строиться работа. В то время как выделенная команда проделывает то же самое, уже в процессе работы на стороне заказчика.


Минусы проектов с фиксированной ценой:

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

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