Заказная разработка: как пересмотр требований сокращает смету на 4,6 млн рублей

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

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

Например, проект B2B-портала для производителя промышленного оборудования. Первоначальная оценка составила почти 13 млн рублей. После уточнения бизнес-процессов и пересмотра технических решений бюджет первого релиза сократился до 8,4 млн рублей.

Посмотрим, какие требования повлияли на смету, за счёт чего удалось сократить 1 270 часов разработки и какие компромиссы стали возможны.

Исходная задача: B2B-портал для 600 дилеров

К нам обратился производитель промышленного оборудования с дилерской сетью из 600 компаний. В ассортименте около 12 тысяч товарных позиций. Каталог, цены, остатки и документы хранятся в 1С.

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

Компания решила создать B2B-портал, в котором партнёры смогут самостоятельно работать с каталогом, оформлять заказы и получать документы.

В первоначальное техническое задание вошли:

• - Каталог с характеристиками, поиском и фильтрацией по 12 тысячам товаров.
• - Персональные цены и условия поставок для каждого дилера.
• - Отображение актуальных складских остатков.
• - Оформление заказов с несколькими адресами доставки.
• - Согласование заказов с учётом ролей и лимитов.
• - Отслеживание статусов поставок.
• - Доступ к счетам, накладным и другим документам.
• - Оформление возвратов и рекламаций.
• - Аналитика закупок, задолженности и товарооборота.
• - Интеграция с 1С, включая двусторонний обмен данными.

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

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

Например, пункт «отображать актуальные остатки» можно реализовать несколькими способами: обновлять данные раз в сутки, синхронизировать их каждые 15 минут или обращаться в ERP при каждом запросе пользователя. У этих вариантов разные требования к инфраструктуре, производительности и отказоустойчивости.

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

Первая оценка: 3 600 часов и почти 13 млн рублей

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

Для расчёта использовали средневзвешенную ставку 3 600 рублей за час работы команды. Она учитывает участие аналитиков, проектировщиков, разработчиков, тестировщиков, DevOps-инженеров и руководителя проекта.

Первоначальная смета выглядела следующим образом:

При ставке 3 600 рублей за час стоимость разработки составила 12 960 000 рублей.

Основную часть трудозатрат формировали backend, frontend и интеграции. При этом значительная доля бюджета приходилась на работы, которые пользователь почти не видит: обработку ошибок обмена с ERP, разграничение доступа, тестирование бизнес-сценариев, подготовку инфраструктуры и управление проектом.

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

Что выяснилось после уточнения требований

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

Выяснилось несколько обстоятельств, которые существенно изменили представление о будущем продукте.

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

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

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

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

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

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

Эти уточнения позволили пересмотреть состав работ. Главная бизнес-задача оставалась прежней: дилеры должны самостоятельно оформлять заказы и отслеживать их исполнение.

Пять инженерных решений, которые сократили смету

1. Согласование заказов оставили в ERP

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

Для этого потребовались бы отдельная модель прав, интерфейсы согласования, бизнес-логика и синхронизация результатов с ERP.

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

В результате сократился объём backend-разработки, количество интерфейсов и сценариев тестирования.

У решения было и долгосрочное преимущество: правила обработки заказов остаются в одной системе. При изменении бизнес-процессов производителю не придётся поддерживать две независимые реализации одной логики.

2. Остатки начали обновлять асинхронно

Первоначальная концепция предполагала почти непрерывное получение информации об остатках из ERP.

Однако частые синхронные запросы создавали бы дополнительную нагрузку на учётную систему. Производительность портала зависела бы от скорости ответа внешнего сервиса.

Мы выбрали периодическую синхронизацию: обновление отображаемых остатков каждые 15 минут с дополнительной проверкой доступности товара перед окончательным подтверждением заказа.

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

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

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

3. Аналитику оставили в существующей BI-системе

Изначально заказчик хотел видеть в личном кабинете графики закупок, оборачиваемости товаров, задолженности и другие аналитические показатели.

Но большинство управленческих отчётов уже существовало в корпоративной BI-системе.

Мы исключили из первого релиза разработку собственных аналитических панелей. Для дилеров оставили историю заказов, суммы закупок, основные статусы и выгрузку данных.

Это сократило объём проектирования интерфейсов, backend-разработки и тестирования.

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

4. Возвраты перенесли в следующий релиз

Автоматизация возвратов и рекламаций требовала отдельного набора функций: создания обращений, загрузки документов, проверки оснований, согласования и обмена статусами с ERP.

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

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

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

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

5. Интерфейс построили вокруг основных операций дилера

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

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

В первом релизе сосредоточились на каталоге, корзине, повторном заказе, истории закупок и документах.

Количество интерфейсов и пользовательских состояний сократилось. Вместе с ним уменьшились трудозатраты на дизайн, frontend-разработку и тестирование.

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

Вторая оценка: 2 330 часов и 8,4 млн рублей

После пересмотра требований мы повторно оценили весь объём работ.

Ставку оставили прежней — 3 600 рублей за час. Это позволило сравнить именно изменение трудозатрат.

Направление работ	Первая оценка	Вторая оценка
Аналитика и проектирование	240 ч	200 ч
UX/UI-дизайн	260 ч	150 ч
Backend-разработка	870 ч	570 ч
Frontend-разработка	700 ч	450 ч
Интеграции с корпоративными системами	530 ч	310 ч
Тестирование и обеспечение качества	490 ч	330 ч
DevOps и инфраструктура	160 ч	100 ч
Управление проектом	350 ч	220 ч
Итого	3 600 ч	2 330 ч
Стоимость	12 960 000 ₽	8 388 000 ₽

Разница составила 1 270 часов, или 4 572 000 рублей — 35,3% первоначального бюджета.

При этом в первом релизе сохранились основные возможности:

• - Авторизация и разграничение доступа.
• - Каталог оборудования с поиском и фильтрами.
• - Персональные цены дилеров.
• - Отображение доступных остатков.
• - Формирование и повторение заказов.
• - Интеграция с 1С.
• - Отслеживание статусов поставок.
• - Получение документов.
• - История заказов и выгрузка данных.

Часть функций перенесли на последующие этапы. Часть реализовали через существующие корпоративные системы. Для некоторых сценариев выбрали более простую техническую реализацию.

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

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

Что нельзя сокращать вместе с функционалом

Уменьшение объёма первого релиза закономерно снижает затраты на разработку и тестирование. Но некоторые инженерные требования сохраняют значение независимо от количества экранов.

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

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

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

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

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

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

Даже идеально написанный код не исправит противоречия в бизнес-данных. Иногда подготовка справочников и правил обмена занимает больше времени, чем разработка пользовательского интерфейса.

Почему окончательная стоимость всё равно может измениться

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

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

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

Поэтому качественная смета должна содержать перечень допущений:

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

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

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

При работе по Time & Material стоимость зависит от фактических трудозатрат. В Fixed Price подрядчик дополнительно учитывает неопределенность и ответственность за согласованный результат. Поэтому сравнивать предложения только по итоговой сумме некорректно.

Самая дешёвая смета может оказаться самой дорогой

Предположим, что другой подрядчик предложил разработать такой же портал за 5 млн рублей.

Возможно, команда действительно нашла способ сократить объём работ. Но стоит проверить, какие задачи включены в предложение.

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

Рассмотрим простой пример.

Одна команда предусматривает полноценный механизм повторной отправки заказов при сбоях ERP. Другая ограничивается обычным HTTP-запросом.

Пока обмен работает без ошибок, оба решения выглядят одинаково. Разница проявится, когда учётная система перестанет отвечать, пользователь повторно нажмёт кнопку отправки и в ERP появятся два заказа вместо одного.

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

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

Семь вопросов, которые стоит задать подрядчику

1. Какие требования вы приняли за основу оценки? Если у команды нет зафиксированного состава функций и допущений, точность названной суммы вызывает вопросы.

2. Какие компоненты предлагаете разработать самостоятельно? Нужно выяснить, почему существующие системы, библиотеки или платформы не закрывают соответствующие задачи.

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

4. Какая глубина тестирования предусмотрена? Важно понимать, кто проверяет бизнес-логику, доступы, интеграции и поведение системы при сбоях.

5. Какие требования можно перенести на следующий релиз? Здесь часто появляется возможность уменьшить первоначальные инвестиции и быстрее проверить продукт в эксплуатации.

6. Какие риски могут изменить бюджет? Подрядчик должен уметь назвать конкретные неизвестные и объяснить, какие последствия они могут вызвать.

7. Что произойдёт после запуска? Стоит заранее обсудить гарантийные обязательства, мониторинг, поддержку, документацию, передачу исходного кода и возможность работы с другой командой.

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

Когда заказная разработка действительно оправдана

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

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

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

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

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

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

Что определяет итоговую стоимость заказной разработки

В разобранном проекте первоначальная оценка B2B-портала составила 12,96 млн рублей. После уточнения бизнес-процессов и пересмотра технических решений стоимость первого релиза снизилась до 8,39 млн рублей.

Разница в 4,57 млн рублей появилась благодаря пяти решениям: использованию существующей логики ERP, асинхронному обмену данными, отказу от дублирования аналитики, переносу возвратов на следующий этап и упрощению пользовательских сценариев.

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

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

В SVK.Digital мы начинаем обсуждение заказной разработки с анализа задачи и технических ограничений. На первой встрече с пресейл-инженером и аналитиком можно обсудить возможную архитектуру, определить основные риски и получить ориентир по срокам и бюджету.

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