Заказная разработка: как пересмотр требований сокращает смету на 4,6 млн рублей
Ситуация: компания планирует разработать B2B-портал для своих дилеров. Подрядчик изучает техническое задание и оценивает проект почти в 13 млн рублей.
Сумма немаленькая, но обоснованная. В смете учтены разработка, интеграции, тестирование, проектирование и другие необходимые работы.
Затем команда подробнее разбирается в бизнес-процессах заказчика, пересматривает несколько технических решений и получает новую оценку — 8,4 млн рублей вместо 13 млн.
Разница — 4,6 млн рублей. При этом основные задачи будущего портала остаются прежними.
Рассказываем на примере проекта SVK.Digital, откуда взялась такая экономия и почему иногда лучше потратить больше времени на анализ требований, чем сразу приступать к разработке.
Что хотел получить заказчик
К нам обратился производитель промышленного оборудования с дилерской сетью из 600 компаний и ассортиментом около 12 тысяч товаров.
Заказы дилеры оформляли по электронной почте или через менеджеров. Чтобы узнать актуальную цену, наличие оборудования или статус поставки, приходилось обращаться к сотрудникам производителя.
Компания хотела создать B2B-портал, где партнёры смогут самостоятельно находить товары, оформлять заказы, проверять остатки, отслеживать поставки и получать документы.
Дополнительно заказчик предусмотрел согласование заказов, аналитику закупок, возвраты и рекламации. Всё это требовалось связать с 1С, где уже хранились данные о товарах, ценах, заказах и контрагентах.
На первый взгляд — обычный личный кабинет для партнёров. Но за каждым разделом стояла своя бизнес-логика.
Например, что означает «показывать актуальные остатки»? Обновлять данные раз в сутки, каждые 15 минут или обращаться в 1С при каждом открытии страницы?
Для пользователя разница может быть почти незаметна. Для стоимости разработки — весьма существенна.
Первая оценка — почти 13 млн рублей
Первоначальное техническое задание включало весь заявленный функционал.
Мы оценили проект в 3 600 часов работы, или 12 960 000 рублей при средней ставке команды 3 600 рублей в час.
Самые трудоёмкие направления:
- Backend-разработка — 870 часов.
- Frontend-разработка — 700 часов.
- Интеграции — 530 часов.
- Тестирование — 490 часов.
Остальное приходилось на аналитику, дизайн, инфраструктуру и управление проектом.
Важно понимать, что разработка сложной системы — это не только создание интерфейсов. Значительная часть бюджета уходит на то, чего пользователь не видит: обработку ошибок, передачу данных, безопасность, проверку бизнес-логики и обеспечение стабильной работы.
Смета соответствовала заявленным требованиям. Но прежде чем её утверждать, мы решили проверить, действительно ли бизнесу нужны все предусмотренные функции.
И здесь началось самое интересное.
Пять решений, которые изменили стоимость проекта
1. Не стали дублировать функционал 1С
По первоначальному плану портал должен был самостоятельно согласовывать заказы, проверять лимиты, учитывать договорные условия и управлять статусами.
Но в процессе анализа выяснилось, что значительная часть этих операций уже выполняется в ERP-системе производителя.
Зачем создавать второй механизм согласования, если первый работает?
Мы предложили оставить эту логику в 1С. Портал будет передавать заказ и получать информацию о результатах его обработки.
Таким образом, не нужно разрабатывать вторую систему согласования, синхронизировать правила и поддерживать две реализации одной бизнес-логики.
2. Отказались от постоянных запросов остатков
Заказчик хотел показывать дилерам актуальное наличие товаров.
Первоначальная концепция предполагала почти непрерывный обмен с 1С. Но каждый такой запрос создаёт дополнительную нагрузку на учётную систему.
После обсуждения выяснилось, что дилерам необязательно видеть остатки с точностью до секунды.
Мы предложили обновлять отображаемые данные каждые 15 минут, а фактическую доступность товара проверять перед окончательным подтверждением заказа.
При этом пользователь видит время последнего обновления и получает уведомление, если количество товара изменилось.
Результат — более простая интеграция, меньше обращений к 1С и снижение зависимости портала от скорости ответа внешней системы.
3. Не стали создавать вторую аналитическую платформу
В техническое задание входили графики закупок, показатели задолженности, оборачиваемость товаров и управленческие отчёты.
Однако у производителя уже работала BI-система, которая решала большинство этих задач.
Разрабатывать собственный аналитический модуль внутри портала означало бы повторять существующий функционал.
Поэтому для первого релиза оставили только то, что действительно нужно дилерам: историю заказов, суммы закупок, основные статусы и выгрузку данных.
Расширенную аналитику можно будет добавить позже, если возникнет подтверждённая потребность.
4. Перенесли возвраты и рекламации на следующий этап
Автоматизация возвратов выглядела логичным дополнением к порталу.
Но это отдельный процесс: обращения, документы, согласования, проверки и обмен статусами с 1С.
Анализ показал, что основную нагрузку на сотрудников создают вовсе не возвраты, а ежедневная обработка заказов и запросов о поставках.
Поэтому мы предложили сначала автоматизировать наиболее частые операции, а существующий порядок обработки рекламаций временно сохранить.
Функция не исчезла из планов. Её просто не стали оплачивать в первом релизе.
5. Упростили пользовательские сценарии
Первоначально портал проектировался как большая система с множеством разделов, отчётов и настроек.
Но дилеры в основном приходят за конкретными действиями: найти товар, проверить цену, повторить заказ и узнать дату поставки.
Вокруг этих операций и решили строить первый релиз.
Меньше сложных интерфейсов — меньше затрат на проектирование, frontend-разработку и тестирование.
При этом основные возможности портала сохраняются.
Что получилось после пересмотра требований
Мы повторно оценили объём разработки, оставив прежнюю часовую ставку.
Результаты двух оценок:
Первоначальный вариант: 3 600 часов, 12 960 000 рублей.
Пересмотренный вариант: 2 330 часов, 8 388 000 рублей.
Разница: 1 270 часов и 4 572 000 рублей, или 35,3% первоначальной сметы.
В первом релизе сохранились каталог оборудования, персональные цены, остатки, оформление и повторение заказов, интеграция с 1С, история закупок, статусы поставок и получение документов.
Экономия возникла не из-за снижения ставок специалистов или отказа от качества. Мы изменили состав первого релиза, использовали возможности существующих систем и упростили отдельные технические решения.
Но здесь есть важный нюанс.
Сокращение сметы первого релиза не означает, что все будущие расходы исчезли. Некоторые функции перенесены на следующие этапы и впоследствии потребуют дополнительных инвестиций.
Кроме того, отдельно необходимо учитывать лицензии, инфраструктуру, сопровождение и возможные доработки 1С.
На чём экономить нельзя
Уменьшать бюджет за счёт отказа от ненужных функций — разумно. Но сокращать критически важные инженерные работы опасно.
Например, каждый дилер должен видеть только свои цены, заказы и документы. Ошибка в разграничении доступа может раскрыть коммерческую информацию других партнёров.
Или представим ситуацию: дилер отправил заказ, но в этот момент 1С перестала отвечать. Пользователь повторно нажал кнопку, и система создала два одинаковых заказа.
Поэтому надёжная обработка ошибок интеграции, защита от дублирования операций, тестирование и мониторинг должны оставаться в смете.
Именно здесь часто скрывается разница между внешне похожими предложениями подрядчиков.
Один закладывает в стоимость полноценную систему обработки ошибок, другой — только простой обмен данными. Пока всё работает, результат кажется одинаковым. Разница проявляется при первом серьёзном сбое.
Почему самая дешёвая смета не всегда выгоднее
Допустим, один подрядчик оценил разработку портала в 8 млн рублей, а другой — в 5 млн.
Это ещё не означает, что второй работает эффективнее.
В его предложении могут отсутствовать важные интеграционные сценарии, нагрузочное тестирование, документация или подготовка инфраструктуры.
А иногда подрядчики просто по-разному понимают требования.
Поэтому перед заключением договора стоит выяснить:
- Что именно входит в стоимость? Какие функции, интеграции и дополнительные работы предусмотрены?
- Что можно не разрабатывать? Есть ли аналогичные возможности в существующих корпоративных системах?
- Какие функции можно отложить? Что необходимо для первого запуска, а что потребуется только при дальнейшем развитии?
- Какие риски способны увеличить бюджет? Например, ограничения API или необходимость доработки 1С.
- Что произойдёт после запуска? Кто отвечает за исправление ошибок, мониторинг и сопровождение системы?
Разница между предложениями становится понятнее, когда сравниваешь не только суммы, но и содержание работ.
Главный вывод: бюджет определяется ещё до начала разработки
В нашем примере пересмотр требований позволил уменьшить предварительную смету первого релиза с 12,96 до 8,39 млн рублей.
При этом никто не предлагал отказаться от основных бизнес-задач.
Мы выяснили, какие процессы действительно требуют автоматизации, какие функции уже существуют в корпоративных системах и какие возможности можно реализовать позже.
Именно такие решения часто оказывают на стоимость проекта большее влияние, чем выбор языка программирования или стоимость часа разработчика.
Поэтому перед запуском заказной разработки полезно задать себе вопрос: мы собираемся оплачивать решение бизнес-задачи или просто реализацию всех пунктов технического задания?
Это далеко не всегда одно и то же.
В SVK.Digital мы начинаем работу над сложными веб-сервисами с анализа бизнес-задач, существующей ИТ-инфраструктуры и технических ограничений.
Если вы планируете разработку корпоративного портала или веб-приложения, можно начать с обсуждения задачи с нашим пресейл-инженером и аналитиком. Они помогут определить основные риски, возможную архитектуру и ориентировочный бюджет.
Подробнее о нашем подходе — заказная разработка SVK.Digital.