Почему смета растёт после старта — и какие пять строк должны быть в оценке

Fixed price не фиксирует неизвестное. Проверяем результат, границы, зависимости, приёмку и правила изменений до подписания договора.

Материал подготовила команда 13FOX (tfox.dev). Мы создаём сайты, мобильные приложения и цифровые сервисы для бизнеса и показываем, как принимать продуктовые решения по проверяемым данным.

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

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

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

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

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

Главная мысль: контролировать нужно не обещание «цена не изменится», а связь между результатом, условиями оценки и каждым решением об изменении объёма.

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

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

Платформы тоже меняют обязательные условия. Apple объявила 3 февраля 2026 года, что с 28 апреля загрузки в App Store Connect должны собираться как минимум с SDK iOS и iPadOS 26. С 31 августа 2026 года Google Play требует для новых приложений и обновлений на телефонах и планшетах целевой уровень Android 16, или API 36; для части форм-факторов сроки отличаются, а для обновления приложения можно запросить продление до 1 ноября 2026 года. Эти факты не говорят, сколько будет стоить обновление, но показывают, почему версия платформы и ответственность за совместимость должны быть в смете.

«API стандартный», «контент предоставит заказчик», «нагрузка небольшая» звучат как факты, но это условия оценки. Хорошее допущение можно проверить: какая версия API, какой набор контента, кто передаёт доступ, к какой дате и что меняется, если условие не выполняется.

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

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

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

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

Допустим, в коммерческом предложении написано: «Авторизация: дизайн, разработка, тестирование». Заказчик представляет вход по телефону. Команда считает вход по электронной почте. После старта появляются код из SMS, восстановление доступа, защита от подбора кода, вход на втором устройстве и перенос старых пользователей. Слово «авторизация» не изменилось, а работа стала другой.

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

Возражение звучит справедливо: «Точную смету всё равно невозможно сделать до разработки. Зачем тогда детализация?» Затем, чтобы отличить уточнение от расширения. Например, цену этапа «вход по телефону» можно зафиксировать, когда согласованы способ входа, восстановление доступа, ошибки и проверка результата. Если корпоративный вход ещё не исследован, его лучше вынести в следующий этап, а не прятать в обещание неизменной цены.

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

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

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

Рабочий порядок короткий:

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

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

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

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

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

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

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

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

Во время разработки связываем изменение с конкретным решением: убрать или перенести менее важную задачу, расширить этап либо отложить идею. Для сложной интеграции полезно отдельно согласовать объекты данных, направления обмена, поведение при повторе и сбое. Как это выглядит на примере конкретной интеграции, показано в материале об интеграции Битрикс24 и 1С.

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

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

Если появляется новое требование, бизнесу нужны минимум три варианта: заменить часть объёма без роста бюджета, перенести изменение в следующий этап или согласовать дополнительную работу с понятными последствиями. Именно наличие выбора отличает управляемое изменение от сметы, которая растёт сама собой.

Материал подготовила команда 13FOX (tfox.dev). Мы начинаем разработку с проверяемых границ этапа и отдельно фиксируем решения, которые меняют стоимость, срок или критерии приёмки.