Почему растёт стоимость разработки приложения: короткий ответ
Смета растёт, когда меняется её исходная база: результат, внешняя зависимость, допущение, критерий приёмки или правило изменения объёма. Само изменение нормально. Проблема начинается, когда никто не может показать, какая строка изменилась, что добавилось и почему прежней оценки уже не хватает.
Честная оценка не обязана угадывать будущее. Она обязана объяснять, что именно посчитано, на каких условиях держится сумма и как команда поступит, если условия изменятся. Тогда новая задача не превращается в спор: ею можно заменить менее важную задачу, её можно перенести, добавить в этап или отклонить.
Главная мысль: контролировать нужно не обещание «цена не изменится», а связь между результатом, условиями оценки и каждым решением об изменении объёма.
Одна строка выглядит просто, пока не нужно принимать результат
Допустим, в коммерческом предложении написано: «Авторизация: дизайн, разработка, тестирование». Заказчик представляет вход по телефону. Команда считает вход по электронной почте. После старта появляются код из SMS, восстановление доступа, защита от подбора кода, вход на втором устройстве и перенос старых пользователей. Слово «авторизация» не изменилось, а работа стала другой.
Не нужно писать многостраничное техническое задание. Достаточно зафиксировать, кто входит, каким способом, что происходит при ошибке, какие системы участвуют и по какой проверке блок считается готовым.
| Формулировка | Что понятно | Чего не видно | Что спросить |
|---|---|---|---|
| Разработка приложения | Нужен цифровой продукт | Пользователи, платформы, данные, границы выпуска | Какой законченный результат входит в этап? |
| Интеграция с учётной системой | Две системы должны обмениваться данными | Объекты, направления, версии, ошибки и повторы | Какие данные идут куда и что происходит при сбое? |
| Тестирование | Продукт будут проверять | Устройства, данные, критические сценарии и допустимые дефекты | Какое доказательство означает «готово»? |
Пять мест, где смета теряет границы
Результат описан действием команды, а не тем, что получит бизнес
«Разработать сервер», «сделать дизайн» и «подключить оплату» описывают занятость. Проверяемый результат звучит иначе: пользователь оформляет заказ, платёж подтверждается, оператор видит статус, а повторное уведомление не создаёт второй заказ. Чем ближе строка к наблюдаемому сценарию, тем легче оценить её и принять.
Внешняя зависимость названа, но не разобрана
Слова «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 называет критерии приёмки списком результатов, по которому команда подтверждает, что сервис выполнил задачу пользователя. Это простой способ отделить дефект согласованного результата от новой идеи, появившейся после демонстрации.
Для изменения нет выбора, есть только новый счёт
Новая функция не обязана увеличивать бюджет. Если срок и сумма ограничены, она может занять место менее важной работы. Если весь прежний состав нужно сохранить, придётся изменить срок, бюджет или задействовать заранее предусмотренный резерв, но только для риска, который был назван до старта.
Фиксированная цена фиксирует границы, а не будущее
Возражение звучит справедливо: «Точную смету всё равно невозможно сделать до разработки. Зачем тогда детализация?» Затем, чтобы отличить уточнение от расширения. Например, цену этапа «вход по телефону» можно зафиксировать, когда согласованы способ входа, восстановление доступа, ошибки и проверка результата. Если корпоративный вход ещё не исследован, его лучше вынести в следующий этап, а не прятать в обещание неизменной цены.
Правила федеральных закупок США, или FAR, также связывают фиксированную цену с достаточно определёнными требованиями. GOV.UK рекомендует при нехватке данных фиксировать цену отдельных этапов или итераций, а не всего неизвестного объёма.
| Что фиксируем | Когда подходит | Что остаётся переменным | Главный контроль |
|---|---|---|---|
| Цена всего результата | Стабильный и проверяемый состав | Только заранее описанные риски | Границы, исключения и приёмка |
| Цена этапа | Неизвестные можно снимать последовательно | Состав следующих этапов | Результат этапа и решение о продолжении |
| Срок и доступная команда | Приоритеты будут меняться по обратной связи | Объём внутри лимита | Очередь задач, демонстрации и потолок затрат |
Если одновременно обещаны неизменные цена, срок и весь пока неизвестный объём, риск не исчез. Он обычно прячется в резерве подрядчика, исключениях мелким текстом или будущих дополнительных работах.
Запрос на изменение: развилка вместо автоматической доплаты
Представьте, что после первой сборки бизнес просит добавить вход по корпоративной учётной записи. Сначала нужно не считать часы, а классифицировать запрос. Был ли этот способ входа частью согласованного результата? Меняет ли он безопасность, сервер, тесты и поддержку? Какую ценность даёт сейчас?
| Тип запроса | Признак | Базовое решение |
|---|---|---|
| Дефект | Согласованный критерий не выполняется | Исправить в рамках принятого результата |
| Уточнение | Смысл и границы результата не меняются | Зафиксировать пояснение и проверить влияние |
| Новый объём | Добавился пользователь, сценарий, правило или система | Убрать или перенести менее важную задачу либо расширить этап |
| Изменилась зависимость | Версия, доступ или поведение внешней системы не совпали с базой | Проверить допущение и выбрать новое техническое решение |
| Явное исключение | Работа заранее отмечена как не входящая | Оценить отдельно, если исключённая работа стала нужна |
Рабочий порядок короткий:
- описать новый наблюдаемый результат;
- показать влияние на системы, срок, бюджет, тесты и поддержку;
- выбрать: заменить текущую работу, расширить этап или перенести запрос;
- зафиксировать решение и новую версию базы оценки до разработки.
Матрица проверки сметы: пять полей для разговора с командой
Эту матрицу можно заполнить для каждого крупного блока. Она не заменяет договор или техническую проработку, но быстро показывает, где цена держится на разных ожиданиях. Начните с трёх самых дорогих или рискованных строк, а не пытайтесь описать весь продукт за один вечер.
| Результат | Зависимость | Допущение | Приёмка | Изменение |
|---|---|---|---|---|
| Покупатель оплачивает заказ и видит подтверждение | Платёжный сервис, база заказов, онлайн-касса | Тестовый доступ и описание возврата доступны до начала | Успех, отказ, повтор уведомления и возврат проходят на тестовых данных | Новый способ оплаты заменяет менее важную работу или получает отдельную оценку |
| Оператор видит актуальный статус заказа | Учётная система и таблица соответствия статусов | Заранее выбрано, в какой системе статус считается верным | После обновления, повторного сообщения и обрыва связи обе системы показывают один статус | Новый статус проходит оценку влияния на обе системы |
| Ваша строка: что получит пользователь или бизнес? | Какие системы, доступы, версии и владельцы нужны? | Что команда считает верным и как это проверить? | Какой наблюдаемый тест означает «готово»? | Кто решает, какую задачу убрать, перенести или добавить? |
Сохраните матрицу и отправьте её вместе со сметой. Попросите несколько команд заполнить хотя бы одну и ту же строку. Сопоставимыми станут не только суммы, но и результаты, условия и риски.
Резерв не должен прятать неопределённость
Универсального «правильного процента» резерва нет. Его размер зависит от названных рисков и того, насколько надёжны исходные данные. Если подрядчик просто добавил запас ко всем строкам, заказчик не понимает, за какой риск платит и когда резерв можно считать неиспользованным.
- Известная работа входит в базовую оценку.
- Для риска, известного до старта, запишите, при каком событии он возникает, что изменит и какой запас предусмотрен именно на этот случай.
- Новая функция проходит запрос на изменение и не списывается на риск задним числом.
Для короткого прототипа или обратимого технического эксперимента тяжёлый комитет по изменениям не нужен. Достаточно одной страницы с результатом, допущениями, лимитом времени и решением в конце этапа. Чем выше цена ошибки, больше систем и участников, тем строже должен быть журнал решений.
Если задача не в разборе уже выросшей суммы, а в сокращении состава первого релиза, используйте отдельный разбор о том, как убрать лишние функции из сметы приложения.
Если разработка уже началась: что сделать до следующего изменения
Не начинайте с поиска виноватого. Сначала восстановите текущую базу проекта. Даже если исходная смета была одной строкой, её можно разложить по фактическим решениям и отделить уже согласованное от нового.
- Соберите версии документов. Смета, договор, переписка с решениями, макеты, список задач и демонстрации.
- Опишите остаток результатами. Не «сервер почти готов», а какие сценарии уже работают и какие ещё нельзя принять.
- Вынесите зависимости и допущения. Доступы, версии, владельцы данных, контент и решения заказчика.
- Разделите дефекты и новый объём. Используйте согласованные критерии; если их нет, сформулируйте сейчас.
- Попросите прогноз до работы. Что меняется в сроке, бюджете, тестах и поддержке; что можно убрать взамен.
Общий маршрут от идеи до выпуска разобран в статье о структуре процесса разработки. Договорные риски, права, доступы и платежи вынесены в отдельный разбор защиты бюджета.
Как мы в 13FOX сохраняем смету проверяемой
На старте мы не просим заказчика угадывать архитектуру и количество экранов. Мы разбираем пользовательский сценарий, границы первой версии, внешние системы и критерии результата. Если информации мало, называем допущение и способ его проверить, а не выдаём догадку за окончательную цену.
Во время разработки связываем изменение с конкретным решением: убрать или перенести менее важную задачу, расширить этап либо отложить идею. Для сложной интеграции полезно отдельно согласовать объекты данных, направления обмена, поведение при повторе и сбое. Как это выглядит на примере конкретной интеграции, показано в материале об интеграции Битрикс24 и 1С.
Если задача связана с собственной CRM, используйте более подробную модульную смету CRM: там роли, данные, миграция и интеграции разложены для этого класса систем.
На чём основан подход
Руководства ниже сходятся в главном: оценке нужны ясные границы, допущения, риски и правило пересмотра при новых данных. Источники проверены 10 августа 2026 года; документы для государственных закупок используются как ориентир по управлению оценкой, а не как правовая норма для российского договора.
- GAO Cost Estimating and Assessment Guide, опубликован 12 марта 2020 года: границы, декомпозиция, допущения, риски и обновление оценки.
- GAO Agile Assessment Guide, опубликован 28 сентября 2020 года: критерии готовности, изменение базовой линии и контроль роста объёма.
- GOV.UK: Writing user stories, обновлено 23 мая 2016 года: наблюдаемые критерии приёмки.
- GOV.UK: Contracting for Agile, обновлено 20 июня 2023 года: переменный объём, фиксированные этапы и модели оплаты.
- FAR 16.202, редакция FAC 2026-01 действует с 13 марта 2026 года: условия применимости фиксированной цены.
- Apple: Upcoming SDK minimum requirements, 3 февраля 2026 года: пример меняющейся внешней зависимости.
- Google Play: требования к целевому уровню API, проверено 10 августа 2026 года: второй пример меняющихся условий публикации.
Частые вопросы
Почему растёт стоимость разработки приложения после старта?
Обычно изменилась база оценки: добавился результат, не подтвердилось допущение, усложнилась внешняя зависимость, расширились критерии приёмки или новая задача не заменила старую. Это не всегда ошибка или обман, но влияние должно быть показано до выполнения работы.
Фиксированная цена защищает от доплат?
Только внутри зафиксированного результата и условий. Если состав проекта меняется, стороны выбирают: убрать или перенести менее важную задачу и поставить новую на её место, изменить срок либо согласовать новый бюджет.
Как отличить ошибку от новой функции?
Сверьте запрос с согласованным результатом и критерием приёмки. Если результат должен был работать именно так, это дефект. Если появился новый пользователь, сценарий, правило, система или состояние, вероятнее всего изменился объём.
Что обязательно должно быть в смете на приложение?
Для каждого крупного блока нужны результат, явные исключения, внешние зависимости, допущения, критерии приёмки и правило изменения. Итоговая сумма без этой базы плохо проверяется.
Нужен ли резерв в смете?
Резерв полезен для названных рисков исходного объёма, но универсального процента нет. Новая функция не становится риском задним числом: для неё нужно отдельное решение об объёме, сроке и бюджете.
Можно ли проверить смету, если разработка уже началась?
Да. Нужны обезличенная смета, состав этапов, известные интеграции, журнал решений и текущая сборка. Проверка покажет неопределённости, зависимости, критерии приёмки и вопросы, которые стоит согласовать до следующего изменения.
Получите второе мнение по смете без смены подрядчика
Пришлите обезличенную смету, состав этапов и известные интеграции. Мы отметим, где не хватает результата, зависимости, допущения, приёмки или правила изменения. В ответ вы получите заполненную таблицу по спорным строкам и список вопросов текущей команде. Передавать нам разработку не нужно.