Как оплачивается контрактная разработка

В сфере контрактной разработки электроники и программного обеспечения распространены следующие модели оплаты, или модели сотрудничества:

• фиксированный бюджет (Fixed Price, Fixed Budget);
• почасовая оплата, или время и материалы (Time & Material);
• выделенная команда (Dedicated Team);
• аутстаф (Outstaffing).

За более чем 10 лет на рынке команда КЕДР Solutions в той или иной степени работала по каждой из них. В этой статье мы подробнее расскажем, что представляют собой эти модели, каковы их плюсы и минусы, а также приведем несколько примеров проектов из нашей практики.

Проекты с фиксированным бюджетом

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

Это не значит, что вся сумма оплачивается разом. Во‑первых, сам проект и выплаты по нему разбиваются на этапы. Чем он крупнее, тем больше этапов. Во‑вторых, оплату каждого этапа можно разбить на предоплату и постоплату. Самый паритетный вариант — разделить их 50 на 50.

Преимущества:

1. Предсказуемость. Заказчик четко понимает, во сколько ему обойдется разработка и когда он получит результат, а исполнитель — что предстоит сделать и сколько он заработает.
2. Автономность исполнителя. Это проекты категории «купил и забыл». Все детали оговариваются заранее, поэтому регулярного и глубокого участия заказчика не требуется. Команда и так знает, что делать.

Недостатки:

1. Нужно детальное ТЗ и видение продукта. Поскольку исполнитель берет на себя ответственность за соблюдение сроков и результата, фиксированный бюджет можно применять только к проектам, у которых есть подробное и продуманное техническое задание, а видение продукта не будет меняться в ходе работ.
2. Изменение планов не предполагается. Внесение незначительных изменений допустимо и даже неизбежно: предусмотреть каждую мелочь в проекте невозможно. Кроме того, если коррективы вносятся почти сразу после старта проекта, то команда может просто переоценить проект: это не приведет к заметным сдвигам в планах. Но значительные изменения в середине процесса или на поздних стадиях потребуют серьезной доработки или переработки продукта сильно за рамками бюджета. Все непредвиденные изменения фиксируются в дополнительных соглашениях, и оплачивать их нужно отдельно. При этом, если изменения крупные и важные, то проект придется начинать практически с нуля, а первоначальные сроки и бюджет, скорее всего, сдвинутся.
3. Высокая цена за час разработки. В любом проекте по разработке электроники или ПО есть риски. Например, согласованный на старте микроконтроллер или датчик может по объективным причинам стать недоступен. Тогда придется подбирать альтернативы, возможно, проводить дополнительные исследования и испытания, а это дополнительное время. В проектах с фиксированной оплатой такие потенциальные риски ложатся на разработчика, поэтому он закладывает эти риски в стоимость проекта. Отсюда и более высокая ставка, чем у других моделей оплаты.

Проект заказал крупный производитель систем промышленной автоматизации, у которого большой опыт работы с контрактными разработчиками. Обратившись в КЕДР Solutions, заказчик уже имел подробное техническое задание. После обсуждения и изучения ТЗ команде были ясны требования и видение продукта, был предоставлен образец прибора. Это позволило точно оценить проект, поэтому мы и предложили работать по модели с фиксированным бюджетом.

Каким проектам подходит фиксированный бюджет. Эксперты КЕДР Solutions рекомендуем рассматривать эту модель, если:

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

Проекты с почасовой оплатой

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

Обычно команда каждый месяц отчитывается клиенту о проделанной работе и выставляет счет.

Преимущества:

1. Гибкость. Заказчик сам решает, какие функции реализовать, а от каких отказаться, сделать все проще и дешевле или качественно, но дороже. В таких проектах изменения ожидаемы.
2. Больше контроля. Поскольку клиент в большей степени вовлечен в проект, взаимодействие с командой становится более прозрачным. Работая по этой модели, проще понять, на что именно тратятся время и ресурсы исполнителя.
3. Дешевле, чем фиксированная оплата. При работе с фиксированным бюджетом исполнитель вынужден закладывать в стоимость услуг всевозможные риски. Здесь же часть рисков берет на себя заказчик, поэтому почасовая ставка ниже.

Недостатки:

1. Нет четкого бюджета и дедлайна. Поскольку у команды не всегда есть четкое понимание, что нужно делать, то и сроки, и бюджет остаются не определены. Можно увлечься и потратить основную часть денег на второстепенные задачи, но так и не прийти к законченному и рабочему решению. Так что тут важно соблюдать баланс, придерживаться хотя бы примерной дорожной карты.
2. Требует участия заказчика. В отличие от работы по фиксированной оплате, здесь не получится просто «заплатить и забыть». Вам регулярно будет писать и звонить то аккаунт‑менеджер, то руководитель проекта и спрашивать, как им действовать дальше. Поэтому нужно закладывать время на постоянную коммуникацию.

Приведем пример. Заказчик спроектировал контрольно‑измерительный прибор для электроники и обратился к нам за разработкой программного обеспечения для продукта. Клиент планировал создать несколько приложений, а детальное ТЗ отсутствовало. Не было и четкого понимания, каких сложностей стоило ожидать или как реализовать те или иные идеи. Модель с фиксированной оплатой тут не применить, поэтому мы условились сделать работу по почасовой.

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

Каким проектам подходит почасовая оплата? Мы рекомендуем рассматривать эту модель, если:

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

Проекты с выделенной командой

Перечисленные выше модели оплаты допускают, что руководство компании‑разработчика может перебрасывать непосредственных исполнителей на другие проекты, если сроки текущего это позволяют. Модель выделенной команды отличается тем, что на проект выделяется команда — обычно во главе с руководителем проектов, — и все рабочее время она тратит только на этот проект, не отвлекаясь на другие задачи.

Здесь возможна как предоплата, так и оплата в конце месяца.

Преимущества:

1. Не нужно искать и нанимать специалистов. Тщательно отбирать специалистов не требуется: они уже наняты компанией‑разработчиком. Временное расширение штата за счет команды исполнителя позволяет закрыть дефицит кадров, не нанимая сотрудников на постоянку.
2. Высокий уровень контроля. Заказчик управляет процессомом разработки, нагрузкой выделенной команды и задачами через общение с руководителем проектов.
3. Глубокое погружение. Поскольку команда не отвлекается на другие проекты, она глубоко погружается в тему, что положительно сказывается на скорости и качестве работы.
4. Более доступная почасовая ставка. Ставка у этой модели сотрудничества ниже, чем у перечисленных выше, т.к. исполнитель почти не несет рисков, а загрузка специалистов гарантирована.

Недостатки:

1. Руководство остается на заказчике. Клиент сам несет ответственность за проект. Выделенная команда отвечает только за свое направление. Если заказчик не может загрузить команду работой, из‑за чего она простаивает, ему все равно придется оплатить всю оговоренную сумму за месяц.
2. Трудности с интеграцией. Как и с любым новичком в коллективе, с выделенной командой может быть трудно найти общий язык — особенно поначалу. Могут возникнуть отдельные сложности, если заказчика и исполнителей отделяют многие часовые пояса.

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

В нее вошли техлид и три разработчика. На частичную занятость также привлекались руководитель проектов, схемотехник и тестировщик. Проект длился почти 1,5 года.

Каким проектам подходит выделенная команда? Мы рекомендуем рассматривать эту модель, если:

• вам не нужна полноценная команда разработчиков в штате — только временная помощь;
• задач так много, что требуется не пара лишних рук, а слаженная команда из нескольких специалистов;
• над проектом предполагается работать довольно продолжительное время и нужно сделать все как можно скорее.

Аутстаф

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

Преимущества и недостатки у аутстафа в целом такие же, как и у выделенной команды.

Приведем пример. В сфере embedded‑разработки и разработки на C/C++ аутстаф не слишком востребован. Впрочем, у нас такой опыт был.

Заказчик пришел к нам со своей операционной системой. Он сам руководил проектом, у него были свои разработчики, но не хватало рук, чтобы исправлять периодически обнаруживаемые баги в продукте. Поэтому мы договорились работать по аутстафу. На проект был выделен один программист, который закрывает задачи, логирует время, отчитывается о проделанной работе, а мы раз в месяц выставляем клиенту счет.

Гибридные модели

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

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

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

Исследовательский этап + фиксированный бюджет. Проект можно разделить на два этапа. На первом проводится глубокая предпроектная подготовка — исполнитель дописывает ТЗ, тестирует компоненты или технологии, делает аналитику. Смысл в том, чтобы максимально снять все риски и неопределенности, которые затрудняют точную оценку проекта. После этого можно спокойно оценить оставшуюся часть проекта и зафиксировать цифры. Правда это работает не со всеми проектами.

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

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

Мы предложили выполнить проект в два этапа. Сначала мы собрали и проанализировали требования к будущим устройствам и составили детальное ТЗ. Затем оценили стоимость и сроки второго этапа — непосредственно разработки.

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

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

В заключение

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

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