Как посчитать бюджет на разработку цифрового продукта?

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

Фраза «нужно приложение, как у конкурента» не дает сметы. Она похожа на просьбу назвать цену дома по одной фотографии фасада. Видно, что дом существует, но не видно грунта, коммуникаций, планировки и того, будет ли в нем жить семья или работать склад.

Начните не с суммы, а с решения

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

Бюджет становится управляемым, когда перед расчетом есть ответы на пять вопросов:

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

Если на эти вопросы пока нет ответа, в бюджет нужно включать не «полную разработку», а этап прояснения. Он дешевле, чем построить большой продукт вокруг неверного предположения. О том, почему первый релиз должен проверять ценность, а не демонстрировать все идеи команды, я подробнее писал в материале о разнице между прототипом и MVP.

Из чего обычно складывается бюджет

Полезно видеть не одну строку «разработка», а несколько независимых частей. Тогда собственник понимает, за что платит и где можно сознательно сократить объем, а не просто попросить скидку.

1. Исследование и постановка задачи

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

Этот этап не обязан превращаться в толстый документ. Его хороший результат — понятный первый сценарий, границы проекта и список вопросов, которые нельзя замести под ковёр.

2. Проектирование

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

Проектирование не делает продукт красивее само по себе. Оно снижает количество дорогих переделок в момент, когда код уже написан.

3. Разработка и проверка

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

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

4. Запуск

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

5. Эксплуатация и развитие

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

Как оценивать работу без самообмана

У хорошей оценки есть диапазон и условия. Например: «первый сценарий займет столько-то при условии, что данные уже доступны, а правила расчета утверждает один ответственный». Это честнее, чем точная цена до разговора с пользователями.

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

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

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

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

Как не потерять бюджет в изменениях

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

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

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

Простой пример

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

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

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

Частые ошибки

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

Считать только создание. Хостинг, поддержка, контроль доступов, резервные копии и развитие не исчезают после акта.

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

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

Короткий чек-лист

1. Опишите один рабочий сценарий, который хотите улучшить.
2. Назовите главный риск: спрос, данные, интеграция, правила или технология.
3. Отделите первый результат от списка приятных дополнений.
4. Запросите оценку по этапам и с явными допущениями.
5. Сразу обсудите запуск, поддержку и порядок изменений.

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

Связанные вопросы

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