Аутсорсинг разработки перестал быть способом сэкономить на программистах. Сегодня заказчик отдаёт подрядчику не код, а ответственность за результат – работающую систему, которую можно запустить в эксплуатацию и развивать годами. Цена ошибки при выборе модели и формулировке контракта измеряется не процентами бюджета, а сорванными сроками внедрения. Разберём три рабочие модели сотрудничества и пункты договора, на которых проекты спотыкаются чаще всего.
Три модели: за что вы платите
Fixed Price – фиксированная цена за фиксированный объём работ. Модель работает, когда требования описаны до последней экранной формы и не изменятся по ходу проекта. Подходит для понятных задач: перенос данных, интеграция с готовой системой, доработка типового решения. Риск подрядчик закладывает в цену, поэтому Fixed Price почти всегда дороже при том же объёме. Любое изменение требований превращается в отдельное допсоглашение со своей сметой и здесь рождается большинство конфликтов.
Time & Material – оплата по фактически затраченному времени и ресурсам. Заказчик получает гибкость: требования можно уточнять на ходу, приоритеты – менять между итерациями. Цена этой гибкости – необходимость контролировать ход работ самостоятельно. Без внятного бэклога и регулярной приёмки T&M превращается в бюджет без дна.
Выделенная команда (dedicated team) – подрядчик формирует под вас группу разработчиков, которой вы управляете как собственной. Модель оправдана на длинных проектах, где система развивается итерациями месяцами и годами, например при построении корпоративных бизнес-систем с постоянным потоком доработок. Вы платите за команду целиком, а не за конкретные функции.
Для госсектора выбор сужает 94-ФЗ: конкурс требует заранее определённого предмета и цены, поэтому на практике остаётся Fixed Price с детальным техническим заданием в составе конкурсной документации.
Подводные камни контракта
Договор на разработку проверяется по нескольким болевым точкам.
Приёмка и критерии готовности. «Система работает» – не критерий. Пропишите измеримые условия: перечень функций, сценарии приёмочных испытаний, допустимое число дефектов по категориям. Без этого спор о том, выполнен ли этап, решается силой переговоров, а не договором.
Исключительные права. По умолчанию права на созданную программу остаются у исполнителя. Если вам нужен исходный код и право его дорабатывать у любого подрядчика – это прямо фиксируется в договоре с передачей исключительных прав, иначе вы попадаете в пожизненную зависимость от автора.
Гарантия и сопровождение. Разделите устранение дефектов (бесплатно в гарантийный срок) и развитие функционала (отдельный договор). Граница между «ошибкой» и «новым требованием» должна быть в тексте, а не в устной договорённости.
Инфраструктура и данные. Заранее договоритесь, на чьих мощностях идёт разработка и тестирование, где хранятся данные и резервные копии. Аренда вычислительных ресурсов вроде облачных хранилищ Amazon снимает часть капитальных затрат, но переносит чувствительные данные за периметр – для госзаказчика это отдельный разговор о допустимости.
Что отдавать на аутсорсинг
Передавайте подрядчику то, что не относится к вашему ядру компетенций, но требует серьёзной инженерной работы: интеграционные слои, хранилища данных и BI-отчётность, специализированные подсистемы. Архитектурный контроль и владение требованиями оставляйте у себя – это и есть ваша часть ответственности за результат.
Правильная модель плюс грамотный договор не гарантируют успех проекта, но убирают самые дорогие способы его провалить. Начинайте не с выбора подрядчика, а с описания того, что считаете успехом, – остальное переговоры выстроят вокруг этого.
