Разработка под ключ, поддержка или выделенная команда: что именно вы покупаете в ИТ
Как различать предмет договора и объект закупки в цифровых проектах, чтобы не перепутать результат, услугу, сопровождение и команду
В ИТ слово разработка часто скрывает разные модели покупки. Заказчик может ждать готовую систему, а подрядчик фактически продавать процесс работ. Или, наоборот, клиенту нужна поддержка, а в обсуждение начинают незаметно протаскивать развитие продукта и новые функции.
Из-за этого ломается не только договорная логика. Плывут ожидания по срокам, приемке, бюджету и ролям: кто принимает решения, кто отвечает за результат и как вообще меняется объем работ. Поэтому до разговора о цене полезно сначала назвать, что именно покупается.
Почему здесь чаще всего возникает путаница
Проблема обычно начинается не в момент расчета бюджета, а раньше: когда разные стороны по-разному понимают сам предмет покупки.
Ждут готовую систему
Но в договоре по факту описаны только работы, этапы или команда без ясных границ конечного результата.
Не различают поддержку и развитие
Сопровождение должно удерживать систему в рабочем состоянии, а не незаметно превращаться в бесплатный поток новых функций.
Путают команду с результатом
Выделенная команда дает емкость и экспертизу, но не обещает фиксированный результат сама по себе, если это отдельно не зафиксировано.
Что реально можно купить у ИТ-подрядчика
На практике в цифровых проектах чаще всего покупают не абстрактную «разработку», а один из нескольких разных предметов. У каждого из них своя логика обещания, приемки и изменений.
Разработку под ключ
Здесь заказчик покупает готовый результат: систему, модуль или согласованный набор функций с понятными критериями приемки и границами поставки.
Развитие или доработку существующей системы
Здесь покупают изменения в уже живом контуре: новые функции, интеграции, переработку отдельных блоков или управляемое развитие платформы.
Поддержку и сопровождение
В этом формате покупают стабильную работу системы, SLA, обработку инцидентов, обновления и предсказуемый сервисный контур, а не новый продукт.
Выделенную команду
Здесь покупают не заранее закрытый объем функций, а инженерную емкость: специалистов, команду или усиление под конкретный период и контур задач.
Почему «готовый модуль» все равно не отменяет проект
Отдельный частый случай — когда продается не разработка с нуля, а внедрение готовой основы, платформы или модуля. Это ускоряет старт, но не убирает проектную работу вокруг него.
Покупают не только модуль
Вместе с ним почти всегда нужны адаптация, настройка, интеграции, перенос данных, проверка ограничений и приемка в реальном контуре заказчика.
Ускорение не отменяет границы поставки
Готовая основа сокращает часть работ, но не убирает вопросы о границах поставки, критериях результата и том, что входит в первую очередь.
Нужен отдельный разговор о внедрении
Если этого не сделать, заказчик может воспринимать модуль как «почти готовую систему», хотя основная сложность остается в проекте адаптации.
Что меняется вместе с предметом покупки
Один и тот же подрядчик может работать во всех этих моделях, но внутренняя логика сделки будет разной.
Результат и приемка
Для под ключ важны границы результата и критерии приемки. Для поддержки — уровень сервиса. Для команды — состав и доступность ресурса, а не перечень готовых функций.
Деньги и бюджет
Готовый результат чаще тяготеет к фиксированному объему этапа и логике контрольных этапов. Поддержка живет по периоду и SLA. Команда обычно считается через команду на месяц или другой согласованный горизонт.
Роль заказчика
Чем ближе модель к команде, развитию или плавающему списку приоритетов, тем важнее участие заказчика в приоритетах, требованиях и решениях по изменениям.
Когда какая модель подходит лучше
Удобнее выбирать не по модному слову в КП, а по типу задачи и по тому, что на самом деле хочет купить компания.
Разработка под ключ
- подходит, когда результат уже можно очертить
- нужны понятные критерии приемки
- изменения можно проводить через отдельную процедуру
Развитие существующей системы
- подходит, когда контур уже живой
- нужно менять и расширять функциональность
- часть требований уточняется по ходу работ
Поддержка и сопровождение
- подходит, когда системе нужна устойчивость
- важны SLA, реакции на инциденты и регламентные работы
- новая крупная разработка не является главным предметом покупки
Выделенная команда
- подходит, когда есть собственный список задач или продуктовый контур
- нужно быстро увеличить емкость
- заказчик готов участвовать в приоритетах и управлении
Что важно зафиксировать в КП, договоре или объекте закупки
Если это не зафиксировать, дальше начинается обычная путаница: ждут одно, подписывают другое, спорят уже после старта.
Что именно поставляется
Система, набор работ, сервисный уровень, команда или внедрение готового модуля. Это нужно называть прямо, без расплывчатого слова «разработка».
Как принимается результат
Через критерии приемки, демонстрацию результата, SLA-метрики, отчеты по поддержке или подтверждение выделенной инженерной емкости.
Как проходят изменения
Если объем и приоритеты могут двигаться, это должно быть частью модели работы, а не скрытым источником конфликта после подписания.
Что не входит в обещание
Поддержка не равна развитию продукта, команда не равна фиксированный результат, а готовый модуль не означает нулевые затраты на внедрение.
Ошибки, которые особенно дорого обходятся
Именно они чаще всего создают спор уже после старта проекта, когда деньги и ожидания вложены, а базовая модель сделки так и не названа.
Покупают команду, ждут фиксированный результат
Тогда заказчик считает, что подрядчик обязан довести весь объем, а подрядчик считает, что продает время и инженерную емкость.
Покупают поддержку, а обсуждают план развития
Сервисный договор начинает раздуваться функциями, при этом правила развития системы и отдельный бюджет на изменения не зафиксированы.
Покупают модуль, но забывают про внедрение
Кажется, что большая часть работы уже сделана, хотя именно адаптация, интеграции и приемка обычно определяют сложность проекта.
FAQ
Можно ли сочетать несколько моделей в одном проекте?
Да. Например, сначала провести предпроектный этап или аудит, потом сделать внедрение под ключ, а дальше вынести поддержку в отдельный сервисный контур. Главное — не смешивать эти обещания в один неясный предмет договора.
Чем выделенная команда отличается от аутстаффинга и аутсорса под ключ?
На рынке выделенную команду часто называют аутстаффингом, но важнее не слово, а модель работы. В такой схеме заказчик в большей степени управляет приоритетами и контуром задач. При модели под ключ подрядчик отвечает прежде всего за поставку согласованного результата.
Почему поддержку и развитие лучше разделять?
Потому что это разные обещания. Поддержка нужна для устойчивой работы системы, а развитие — для изменения функций и бизнес-логики. Если смешать их в один договор без границ, быстро размываются и SLA, и бюджет на доработки.
Что делать, если еще неясно, какую модель выбрать?
Полезно начать с короткого обследования или предпроектного этапа. Это помогает понять текущее состояние системы, границы задачи и то, где честнее покупать готовый результат, а где лучше идти через сервис или команду.
Что почитать и сделать дальше
Если вопрос уже упирается в раннюю оценку проекта, полезно посмотреть материал Как оценить проект без полного ТЗ. Он помогает понять, когда можно обещать фиксированный объем этапа, а когда лучше не маскировать неопределенность красивой цифрой.
Если сама задача еще не собрана, а спор идет между готовым результатом, сервисом и командой, следующим шагом часто становится предпроектный этап, аудит кода и архитектуры или более широкий ИТ-аудит. Такой разбор помогает выбрать модель работы не на уровне слов, а на уровне реального состояния системы.
08.05.2026
ОКВЭД 62.01
Сведения об ИТ-деятельности© 2018–2026, ООО «РоботБулл Технолоджи» ИНН 9710065224