Почему договор на разработку не спасает от убытков — и что делать бизнесу

Кажется, все идет по плану: подрядчик работает, менеджеры отчитываются, сроки вроде соблюдаются. Но к концу проекта бюджет оказывается на 30–50% выше, чем закладывали, а продукт работает не так, как планировалось.

Этот материал будет полезен собственникам цифрового бизнеса, руководителям ИТ‑проектов, которые заказывают разработку у подрядчиков

Почему договоры не работают

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

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

Причины зачастую кроются в слабой проработке договора заказной разработки. 

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

Особенно ощутимы такие риски в сложных проектах разработки и интеграции. Например, по договору заказчик хочет получить продукт, ключевая метрика которого — активация аудитории, и ее удержание спустя 15 дней после его первого запуска. Но по KPI в договоре исполнитель должен заботиться только о скачиваниях продукта, и выполнении формальных признаков вроде «‎разработать 25 микросервисов, добавить личный кабинет» 

Как выйти из проекта без потерь

Главный вопрос, который стоит задать еще до подписания договора: как мы выйдем из проекта без потерь, если что‑то пойдет не так?

На него должен отвечать сам договор. В нем важно заранее определить:

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

Практика показывает: установка лимитов отклонений по бюджету в пределах 15–20% и метрик качества (например, не более 5% задач возвращаются на доработку) значительно снижают риски.

Как контролировать подрядчика

Чтобы сохранить управляемость проекта:

• пропишите SLA и KPI: они должны отвечать назначению продукта. Это проще всего сделать «‎сверху вниз»: определите главную метрику продукта, и определите, какие показатели важны для ее достижения
• определите контрольные точки: их лучше выбирать с точки зрения качественных, а не количественных требований к продукту 
• обеспечьте себе доступ к Git, таск‑трекерам и дашбордам, в которых работает исполнитель
• согласуйте механизм эскалации: кто и как реагирует на отклонения

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

Договор как часть архитектуры

Договор на разработку — это не просто страховка от споров. Это часть архитектуры управления цифровыми активами компании. От того, как он спроектирован, зависит не только результат проекта, но и способность бизнеса повторно использовать его, масштабировать продукт и защищать права на интеллектуальную собственность.

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

Почему это выгодно

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

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

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