Заказная продуктовая разработка: чем она отличается от проектной и когда нужна

Короткий ответ: проектная разработка отвечает за сдачу оговорённого объёма работ, продуктовая — за то, что система продолжает работать и развиваться после запуска. Разница проявляется не в коде, а в договоре, бюджете и в том, кто принимает решения по ходу.

Термин «заказная продуктовая разработка» звучит как маркетинговая склейка, но за ним стоит вполне конкретное различие. Разберём его.

Проектный подход: сдать и разойтись

Классическая схема: заказчик приносит техническое задание, подрядчик оценивает объём, стороны фиксируют сроки и бюджет, работа сдаётся по акту.

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

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

В проектной логике каждое такое открытие превращается в спор о том, входило ли оно в объём. Обе стороны правы по-своему, и обе тратят время на переговоры вместо разработки.

Продуктовый подход: отвечать за то, что система работает

Здесь фиксируется не объём работ, а направление и способ принятия решений. Есть цель, есть бюджет на итерацию, есть регулярная приёмка. Что именно делается в следующем месяце, определяется по результатам предыдущего.

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

Пять практических отличий

Договор. В проектном — фиксированный объём с приложением-ТЗ. В продуктовом — рамочный договор с итерациями и понятным порядком изменения приоритетов. Второй вариант пугает заказчиков открытостью, но именно он честнее отражает реальность, когда требования уточняются по ходу.

Бюджет. Проектный называет итоговую сумму сразу и закладывает в неё риск неопределённости — обычно 20–40% сверху. Продуктовый называет стоимость итерации и горизонт: «в таком темпе за полгода получится вот столько». Суммарно продуктовый чаще выходит дешевле, потому что не оплачивается страховка от неизвестности.

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

Состав команды. Проектный обходится разработчиками по ТЗ. Продуктовый требует того, кто задаёт вопросы бизнесу и превращает ответы в требования. Без этой роли итерации превращаются в поток случайных доработок.

Что после релиза. Проектный заканчивается гарантийным периодом на исправление ошибок. Продуктовый переходит в ежемесячное сопровождение с развитием. Это не «подсадить на абонентку»: система, которая интегрирована с учётом и которой пользуются каждый день, требует внимания просто потому, что вокруг неё меняются API, законы и процессы.

Как понять, что нужен продуктовый подход

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

Задача сформулирована как цель, а не как решение: «сократить время обработки заказа», а не «сделать вот такую форму». Пользователей больше одной роли, и у них разные интересы. Система будет интегрирована с тем, что уже работает, — а значит, вскроются особенности, которых никто не помнил. Бизнес-процесс, который автоматизируется, сам меняется по ходу проекта.

Обратные признаки, при которых проектный подход правильнее: объём действительно понятен, интеграций мало, система автономна, а после запуска её не планируют развивать. Такие задачи существуют, и продавать под них итерации было бы навязыванием.

Отдельно стоит разобраться, нужна ли вообще заказная разработка: часто задача закрывается настройкой готового решения. Об этом — в разборе коробки против заказной платформы с правилом 30% доработок.

Что спросить у подрядчика

Три вопроса, ответы на которые показывают подход лучше презентации.

«Что произойдёт, если на третий месяц мы поймём, что нужный процесс устроен иначе, чем мы описали?» Проектный подрядчик расскажет про порядок изменения ТЗ. Продуктовый — про то, как это встроено в процесс изначально.

«Кто с вашей стороны будет разбираться в нашем бизнесе и как часто мы будем встречаться?» Если ответ — «пришлите ТЗ, дальше мы сами», это проектная схема независимо от названия.

«Что происходит после запуска?» Ответ «гарантия три месяца на баги» и ответ «переходим в ежемесячное сопровождение с планом развития» описывают два разных продукта.

Итог

Продуктовая заказная разработка — не более модная версия проектной, а другой способ распределить ответственность и риск. Она подходит, когда задача сложнее, чем её первая формулировка, а система будет жить и меняться. Она не подходит, когда объём ясен и развивать нечего.

Главный практический критерий — наличие человека со стороны бизнеса, готового участвовать еженедельно. Есть такой человек — продуктовый подход даст лучший результат за те же деньги. Нет — лучше честно взять фиксированный объём и не делать вид.

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