Оценка стоимости разработки ПО в 2026: смета без сюрпризов
Главное
• Оценка разработки ПО нужна для решений, а не для дедлайна. Её задача: найти самый дешёвый путь к продукту, который можно продавать. Предсказывать будущее с точностью до второго знака она не обязана.
• Точность даёт не число часов, а чётко описанные задачи. Конус неопределённости (Cone of Uncertainty) показывает, что на ранних этапах оценка может отличаться от факта в диапазоне от 0,25× до 4×, то есть в 16 раз. Разброс сужается только по мере принятых решений.
• Используйте минимум два метода, а не один. На питче хватает аналогового, по итогам discovery нужны оценка снизу вверх (WBS) и трёхточечный PERT, на каждом спринте работает Planning Poker. Одно число от одного метода ещё не оценка.
• Лучший контракт: платный discovery, затем фиксированная разработка. Первые 2–4 недели идут по почасовой оплате (T&M), чтобы сжать конус, остальное по фиксированной цене с правилами change-order. Фиксированная цена на пустом листе ведёт в ту половину проектов, которые выходят за сроки или бюджет (Standish CHAOS 2020: 50% проектов «проблемные»).
• ИИ-инструменты меняют смету неравномерно. Шаблонный код дешевеет на 60–80% часов, продуктовая логика на 40–60%, тяжёлая инженерия на 15–30%, а ревью сторов, лицензии и юристы не дешевеют совсем (0%). Честная смета 2026 года считает каждый тип работы отдельно, показывает рядом цифру рынка без ИИ и сокращает календарь меньше, чем часы.
Обновлено в ноябре 2026: свежие данные Standish CHAOS, DORA, Stack Overflow 2026 и CodeRabbit, сроки и бюджеты с ИИ-инструментами и рядом рынок, шесть шагов оценки, пять новых схем.
Почему Фора Софт написала это руководство
С 2005 года Фора Софт выпустила 250+ проектов, в основном платформы для видео в реальном времени, ИИ и аудио, где один неудачный выбор SDK может удвоить бюджет. За двадцать лет мы писали, подписывали и сдавали оценки любых форматов: от набросков на салфетке для основателей до 40-страничных рамочных договоров (MSA), спринтовых графиков и контрактов на результат. Здесь собрано то, что выдержало проверку подписанными заказами.
Перед каждой фиксированной сметой мы проводим discovery, по каждому проекту сравниваем оценку с фактом и знаем, какие строки подрядчики регулярно упускают: когда-то мы упускали их сами. Если нужна независимая оценка готовой сметы или полноценный discovery вместо цифры, которой вы не доверяете, посмотрите нашу услугу по планированию и аналитике продукта. На выходе будут требования, кликабельный прототип и смета с диапазоном, а не одно число.
Получили смету от другого подрядчика и не уверены в её достоверности?
Пришлите нам PDF — мы укажем пропущенные строки, проверим допущения и вернём второе мнение в течение 48 часов. Без обязательств и презентаций.
Что такое оценка разработки ПО (и чем она не является)
Оценка разработки ПО помогает предсказать, сколько времени, денег и риска потребует проект, чтобы заказчик принимал решения обоснованно. Это не обещание, не дедлайн и не обязательство. Стив Макконнелл, автор канонической книги на эту тему, разводит три понятия: оценка (вероятностный диапазон), цель (бизнес-задача) и обязательство (обещание эту цель достичь). Подрядчик, который сводит всё к одному числу, не оценивает, а называет цену.
Основатель или CTO, который выбирает партнёра, на деле спрашивает себя: «Что самое дешёвое я могу сделать прямо сейчас, чтобы диапазон оценки стал таким, на который можно опереться?» Мы пишем со стороны заказчика: как получить, прочитать и проверить смету подрядчика. Как CTO выстроить собственный процесс оценки в команде, мы разобрали отдельно, в гиде CTO по оценке стоимости IT-проектов.
Как оценить стоимость разработки ПО: шесть шагов
Короткий ответ: точную смету получают не за один звонок, а за шесть шагов, и каждый сужает диапазон. Вот порядок, в котором мы ведём заказчика от идеи к подписанной цене.
- Опишите задачу одной страницей. Кто пользователь, какую проблему решаем, что считается успехом, какие ограничения по срокам, бюджету и данным (152-ФЗ, медицинские или платёжные данные).
- Получите грубую оценку (ROM). За 30–90 минут разговора подрядчик даст диапазон −25% / +75%. Этого хватает, чтобы решить, стоит ли идея discovery.
- Закажите платный discovery на 2–4 недели. Карта пользовательских историй, нефункциональные требования, архитектура и реестр рисков сужают диапазон до −5% / +10%.
- Попросите оценку снизу вверх и PERT. Задачи по 4–16 часов, три точки на каждую, кривая вероятностей P50 / P80 вместо одного числа.
- Сверьте смету с чек-листом из десяти строк. Тестирование, DevOps, безопасность, управление и резерв должны стоять отдельными строками.
- Выберите форму контракта и правила изменений. Discovery по T&M с потолком, затем фиксированная разработка и письменный процесс change-order с пересмотром прогноза каждый спринт.
Сколько это занимает: от первого звонка до подписанной фиксированной цены обычно 3–5 недель, из них 2–4 недели уходят на discovery. Шаги 1–2 укладываются в неделю и ничего не стоят. Дальше за точность приходится платить, но это дешевле переделки на четвёртом месяце.
Почему половина проектов до сих пор выходит за рамки бюджета
Цифры почти не изменились за тридцать лет. По отчёту CHAOS 2020 от Standish Group, в срок и в рамках бюджета сдают около 31% проектов, около 50% выходят за сроки или бюджет либо урезают объём, а около 19% отменяют. В первом отчёте CHAOS 1994 года «проблемных» проектов было 52,7%, и их бюджет в среднем превышал план на 189%. По обзору Джузеппе Арчидиаконо в PM World Journal (январь 2026 года), данные CHAOS за 2020–2024 годы почти не сдвинулись. CISQ оценил годовые потери от низкого качества ПО только в США в $2,41 трлн, а накопленный технический долг примерно в $1,52 трлн (отчёт 2022 года).
Причины провалов в исследованиях повторяются: scope creep (расползание объёма работ), слабый сбор требований, пропущенные нефункциональные задачи (безопасность, доступность, производительность, DevOps) и якорение, когда сроки и ресурсы подгоняют под бюджет, а не под реальные задачи. Почти все эти проблемы появляются ещё до написания кода.
Конус неопределённости — у вашей оценки есть допустимый разброс
Барри Бём первым нарисовал конус неопределённости (Cone of Uncertainty), а Макконнелл сделал его известным. Суть: точность оценки зависит от того, сколько уже решено, а не от того, сколько обсуждено. На стадии первоначальной концепции, после первого 30-минутного звонка, даже строгая оценка может отличаться от итога в диапазоне от 0,25× до 4×, то есть до 16×. Подрядчик, который это отрицает, показывает непрофессионализм.
Рисунок 1. Конус неопределённости: каждая отметка на оси означает подписанное решение, а не дату. Конус сужается, только когда решения приняты.
Эту диаграмму часто понимают неправильно, причём с обеих сторон. Основатели иногда думают, что конус сужается со временем. Это не так: команда, которая четыре недели «скоупит» без письменной карты пользовательских историй, нефункциональных требований и критериев приёмки, всё ещё в диапазоне ±4×. Подрядчики иногда дают фиксированную цену на стадии питча и закрывают неопределённость накруткой в 2–3 раза. Если накрутка оправдана, заказчик переплачивает; если её не хватило, проект умирает на середине разработки.
Вспомните про конус, когда: подрядчик называет точную цену за 6-месячную разработку после одного звонка по discovery. Спросите, на какой стадии конуса он находится и почему.
Три типа оценок — выбирайте подходящий под задачу
Не каждой оценке нужна одинаковая точность. Тратить четыре недели на высокоточную оценку ради решения на 2,2 млн ₽ бессмысленно. Ниже наша рабочая шкала точности (по мотивам классов оценок AACE International и практики PMI) и решения заказчика, для которых подходит каждый класс. Сроки в таблице означают время на саму оценку, а не на разработку.
| Тип | Точность | Сколько занимает оценка | Использовать для | Не использовать для |
|---|---|---|---|---|
| Грубый порядок величины (ROM) | −25% до +75% | 30–90 мин | Решения, стоит ли идея полноценного discovery | Подписания фиксированного контракта |
| Бюджетная | −10% до +25% | 1–2 недели | Одобрения совета, бюджетной строки от CFO, решения go/no-go | Обязательств по календарной дате запуска |
| Определённая | −5% до +10% | 2–4 недели платного discovery | Фикс-цена, обязательства по срокам запуска | Проверки гипотезы «стоит ли вообще строить» |
| Спринтовая | ±10% на спринт (после 3–4 спринтов) | 2–4 часа на спринт | Планирование спринта, прогноз по следующему релизу | Долгосрочные коммерческие обязательства |
Большинство основателей, с которыми мы общаемся, просят определённую оценку на стадии, когда проекту доступна только бюджетная. Помогают не новые встречи, а платный discovery: он сужает диапазон неопределённости и даёт право на большую точность.
Шесть методов оценки, которые до сих пор использует серьёзный подрядчик
Это методы, которые мы реально используем в Фора Софт. Заказчику не нужно уметь считать каждым из них, достаточно знать, что спросить: каким методом получено число и с чем его сверили. Для одной оценки берите минимум два метода и сравнивайте результаты. Подробное сравнение методов с таблицами точности и трудоёмкости есть в отдельном разборе «5 способов оценить разработку ПО».
Аналоговый (экспертная оценка на основе прошлых проектов)
Берёте завершённый проект с похожей архитектурой и его реальные показатели, поправляете на размер, стек и опыт команды и получаете оценку. Дёшево, быстро, допущения видны, а при хороших исторических данных ещё и удивительно точно. Метод не работает, когда в новом проекте есть по-настоящему уникальный компонент, например первая интеграция с LLM или первое FDA-устройство без аналогов в прошлом. Хорошо подходит на стадии питча или концепции.
Top-down (декомпозиция от проекта к эпикам)
Разбиваете проект на 6–10 эпиков, каждому назначаете диапазон по истории похожих проектов и суммируете. Удобно для разговора с CFO. Для планирования спринтов слабо: метод прячет детали 300 пользовательских историй, которые и определяют реальный расход бюджета. Хорош как первый проход в discovery, чтобы потом сверить его с оценкой снизу вверх.
Bottom-up / Work Breakdown Structure
Разбиваете работу на задачи по 4–16 инженерных часов, оцениваете каждую и добавляете накладные расходы на менеджмент, тестирование и DevOps. Самый точный метод, когда уже есть полная карта пользовательских историй, критерии приёмки и архитектура. Он дорогой (мы берём за него деньги в рамках discovery) и сильно ошибается, если на входе неполный объём работ. На нём строится определённая оценка.
Параметрический (COCOMO II, Function Points)
Подаёте в модель размер (в KLOC или function points), факторы сложности и опыт команды и получаете расчётный результат. Полезен как третий голос, когда оценки сверху вниз и снизу вверх расходятся. Оговорка: исходная калибровка COCOMO II опирается на водопадные проекты 1990-х, и академические исследования показывают, что некалиброванный COCOMO может ошибаться в разы на современных облачных, микросервисных стеках и в командах с ИИ-ассистентами. Если подрядчик ссылается на COCOMO, спросите, когда он последний раз калибровал модель на собственных данных.
Planning Poker (оценка в story points по консенсусу)
Классика Майка Кона: вся команда показывает карточки модифицированного ряда Фибоначчи (1, 2, 3, 5, 8, 13, 20, 40, 100) по каждой истории, авторы крайних оценок объясняют свою позицию, команда голосует заново и приходит к консенсусу. Метод ловит скрытую сложность, которую индивидуальные оценки всегда упускают, и делает команду ответственной за план. Через 3–4 спринта скорость стабилизируется, и те же карточки переводятся в надёжные дни. На стадии питча не подходит: команды у вас ещё нет.
Трёхточечный PERT + Монте-Карло
Для каждой строки оценки снизу вверх фиксируем три оценки: оптимистичную (O), наиболее вероятную (M) и пессимистичную (P). Ожидаемая длительность считается как (O + 4M + P) / 6, стандартное отклонение как (P − O) / 6. Метод даёт честные доверительные интервалы вместо чисел с ложной точностью. Монте-Карло прогоняет 10 000+ расписаний по этим распределениям и строит кривую, например «50% шанс уложиться в 14 недель, 90% в 18». О сроке запуска в контракте договариваются именно по этой кривой.
Какой метод подходит для какой стадии — матрица соответствия
Матрица сопоставляет каждый метод с каждой стадией решения; закрашенный круг означает, что метод подходит. Используйте минимум два метода для одной оценки: если результаты расходятся больше чем в 1,5 раза, объём работ ещё не определён.
Рисунок 2. Какой метод оценки подходит к какой стадии решения: закрашенный круг означает «подходит», кольцо означает «по ситуации».
Как этап discovery сжимает оценку, шаг за шагом
Большинство превышений бюджета в данных Standish вызвано одной ситуацией: цену фиксируют на первой стадии конуса, а реальный объём работ становится ясен только на четвёртой. Наш ответ: поэтапный discovery, где каждый артефакт делает оценку точнее.
Рисунок 3. Воронка discovery: каждый артефакт сужает диапазон оценки до подписания фиксированной цены.
Стадии 2–4 обычно стоят 5–8% общего бюджета. Лишний или ошибочный объём, который они срезают, по нашей практике составляет 10–25% исходной оценки разработки: неверные допущения уходят до первой строки кода. Как сжать объём на стадии 2, мы разбирали в статье о том, зачем выпускать продукт раньше и что такое MVP. Подробный план discovery с этапами и ценой есть в руководстве по project discovery. Если нужен готовый результат, у нас есть отдельная услуга, планирование MVP: конкурентный анализ, ядро функционала и оценка до старта разработки.
Что должна включать полная оценка (и что упускают 80% смет)
Чаще всего смету занижают так: строки по функциям посчитаны верно, а всё остальное нет. Ниже полный чек-лист, которым мы пользуемся внутри компании. Попросите любого подрядчика явно показать все десять пунктов.
| Строка | Типичная доля | Часто отсутствует |
|---|---|---|
| Разработка функций (основной сценарий) | 35–45% | — |
| Крайние случаи, обработка ошибок, пустые состояния | 10–15% | Почти всегда |
| QA (ручное + автоматизированное + регрессионное) | 15–25% | Часто занижено |
| UI / UX дизайн и итерации | 8–12% | Учитывают только первую версию экранов |
| DevOps, CI/CD, настройка инфраструктуры | 5–10% | Часто |
| Безопасность и комплаенс (152-ФЗ, GDPR, HIPAA) | 5–15% | Почти всегда |
| Доступность (WCAG 2.2 AA) | 3–6% | Обычно |
| Производительность / нагрузочное тестирование | 2–5% | Обычно |
| PM, архитектор, тимлид и надзор | 10–15% | Спрятано внутри строки «команда» |
| Буфер на риски / резерв | 10–20% | Часто маскируется как «буфер» |
Рисунок 4. Десять строк полной сметы: синим отмечено то, что есть даже в тонкой смете, оранжевым то, что чаще всего выпадает.
Если смета примерно равна стоимости часов на разработку функций, подрядчик оценил 35–45% реальной работы. Дальше он либо заложил разницу в цену часа, либо, что бывает чаще, доберёт её через change-order позже.
Модели контрактов: кто несёт ответственность за риск, если оценка оказалась ошибочной
Оценка кормит контракт, а контракт распределяет риск. Ниже пять форм, которые реально встречаются в наших MSA в 2026 году.
| Модель | Лучше всего для | Предсказуемость цены | Гибкость | Кто несёт риск оценки |
|---|---|---|---|---|
| Фикс-прайс | Зафиксированный, проверенный после discovery скоуп | Высокая | Низкая | Подрядчик (за счёт накрутки) |
| Time & materials (T&M) | Исследования, быстро меняющийся скоуп | Низкая | Высокая | Заказчик |
| T&M с потолком | Discovery, прототипные спринты | Средняя | Высокая | Общий |
| Discovery T&M + фиксированная разработка | Greenfield-продукт — наш дефолт | Средняя, затем высокая | Высокая, затем средняя | Общий |
| На результат (outcome-based) | Измеримые KPI, надёжная база для сравнения | Переменная | Средняя | Общий (с апсайдом для подрядчика) |
Берите «discovery T&M, затем фиксированная разработка», когда: вы основатель и создаёте продукт с нуля. Только при такой схеме оценка успевает стать точной до подписания.
Если объём работ будет меняться годами, а не неделями, часто честнее не фиксированная цена, а выделенная команда разработчиков с прозрачными часами и спринтовым прогнозом: риск оценки остаётся у заказчика, зато он управляет приоритетами сам.
Нужен оплачиваемый discovery, который даст чёткую оценку?
Двухнедельный спринт по фиксированной цене. На выходе — подписанная карта пользовательских историй, архитектура, реестр рисков и оценка разработки с погрешностью ±10%, с которой можно идти к совету директоров.
Как ИИ-инструменты меняют смету в 2026 году
Короткий ответ: ИИ-инструменты сокращают часы неравномерно, поэтому честная смета считает экономию по типу работы, а не одним процентом. Разработка с ассистентами кода и агентами поверх сеньоров (у нас это называется Agent-Engineering) сильно ускоряет шаблонный код, умеренно ускоряет тяжёлую инженерию и никак не ускоряет ревью сторов, лицензии и юристов.
Четыре типа работы. А: шаблонный код (авторизация, CRUD, админки, формы, CI/CD), экономия часов 60–80%. Б: продуктовая логика, клиенты iOS/Android/Web, интеграции средней сложности, 40–60%. В: тяжёлая инженерия (WebRTC и медиасерверы, транскодинг, ML на своих данных, производительность, безопасность), 15–30%. Г: всё, что не зависит от скорости кода (ревью сторов, лицензии, юристы, приёмка у заказчика), 0%. Это калибровка Фора Софт от ноября 2026 года по нашим проектам.
Рисунок 5. Экономия часов с ИИ-инструментами по четырём типам работы, калибровка Фора Софт от ноября 2026 года.
С ИИ уже работает почти вся отрасль. По данным Google DORA (сентябрь 2025 года), ИИ на работе используют 90% специалистов по разработке. По опросу Stack Overflow 2026 года (октябрь 2026-го, более 30 000 ответов) ассистентами кода или агентами пользуются 66% разработчиков, автоматическими агентными сценариями 26,2%. Доверие при этом условное: доверить ИИ важные решения готовы только 6,6%. Публичные исследования эффекта расходятся: в эксперименте METR 2025 года опытные разработчики open-source с ИИ-инструментами работали на 19% медленнее. Поэтому наши коэффициенты взяты из проектов Фора Софт, а не из чужих отчётов.
Что это значит для сметы подрядчика:
- Часы считаются по строкам. Каждая строка сметы получает свой тип (А/Б/В/Г) и свой коэффициент. Типичная смесь даёт экономию часов около 55% для веб-сервиса, около 50% для мобильного приложения и около 43% для видео и real-time.
- Календарь сокращается меньше часов. Ревью кода, интеграция и последовательные зависимости съедают часть выигрыша: срок × (1 − экономия часов × 0,75), а этапы типа Г (сторы, нагрузочные тесты, приёмка) не сокращаются вовсе.
- Ревью нельзя урезать. В отчёте CodeRabbit (декабрь 2025 года, 470 pull request на GitHub) в pull request с участием ИИ находили в среднем 10,83 замечания против 6,45 в написанных людьми, примерно в 1,7 раза больше. Подрядчик, который сократил ревью и тестирование вместе с кодом, переложил дефекты на вас.
- Инфраструктура и лицензии не дешевеют. Облако, CDN, лицензии и сборы сторов остаются в смете без коэффициента.
Подрядчик, который пишет «с ИИ всё на 50% дешевле» одним числом, без разбивки по типам работы, либо не считал, либо закладывает разницу себе в маржу. Как это выглядит на реальном проекте, мы показали в кейсе о том, как ИИ сократил время разработки на видеостриминговой платформе: там выигрыш считали по чистым часам программирования, а не по всему проекту.
Мини-кейс — как discovery помог избежать провала оценки в 31 млн ₽
Ситуация. Американский основатель edtech-проекта пришёл к нам с фиксированной сметой другого подрядчика: около 31 млн ₽ (смета была в долларах) за платформу онлайн-репетиторства с живым видео, общей доской, генерацией планов уроков на ИИ и LTI-интеграцией с дюжиной LMS. В смете было 26 страниц перечня функций, но не было нефункциональных требований, структуры работ и реестра рисков. Разработку планировали на 14 недель.
Что сделали. Мы провели трёхнедельный платный discovery (около 1,3 млн ₽). На выходе получили: карту пользовательских историй (147 историй), реестр рисков из 31 записи, эталонную архитектуру, бриф нефункциональных требований с учётом требований FERPA и SOC 2, а также оценку сроков снизу вверх и трёхточечную оценку PERT с расчётом по методу Монте-Карло. Два решения, которых не было в исходной смете: (а) LTI-интеграции нужно было реализовать для 12 различных LMS, а не для одной платформы, и (б) функция ИИ-генерации планов уроков требует проверки человеком (human-in-the-loop) в округах, где действуют нормы FERPA.
Итог. Реальный объём работ с разбросом ±10% составил 18 недель и около 40 млн ₽, почти на 30% дороже и дольше первоначальной сметы. Первый подрядчик признал, что разницу всё равно пришлось бы добирать через change-order на третьем-четвёртом месяце. Клиент выбрал у нас фиксированную разработку; мы сдали проект за 18 недель, израсходовали 94% бюджета и обошлись без пересогласований посреди проекта. Сроки и суммы здесь фактические, это не оценка, поэтому коэффициенты ИИ к ним не применяем. Похожая edtech-платформа из нашего портфолио: Scholarly, живые уроки до 2 000 учеников одновременно и 15 000+ активных пользователей.
Сколько стоит разработка ПО в 2026 году: ориентировочные диапазоны
Короткий ответ: MVP внутреннего инструмента у Фора Софт с ИИ-инструментами стоит 1,2–3 млн ₽ и занимает 4–8 недель (2,6–6,7 млн ₽ и 6–12 недель у команд без них). Платформа видео в реальном времени: 5,5–13,7 млн ₽ и 12–20 недель (9,7–24 млн ₽ и 16–28 недель по рынку). Это диапазоны нашей воронки, а не бенчмарки, то есть ориентир до discovery, а не цена. Любой, кто называет точное число без исследования, угадывает.
| Форма продукта | MVP: Фора Софт с ИИ-инструментами | MVP: рынок без ИИ | Срок с ИИ | Срок рынка без ИИ | Ключевой риск |
|---|---|---|---|---|---|
| Внутренний инструмент / B2B-дашборд | 1,2–3 млн ₽ | 2,6–6,7 млн ₽ | 4–8 нед. | 6–12 нед. | Интеграции с унаследованными системами |
| Мобильное приложение (1 платформа) | 2,3–5 млн ₽ | 4,5–10 млн ₽ | 6–11 нед. | 8–16 нед. | Итерации дизайна, ревью сторов |
| SaaS с подпиской и админкой | 3–7,4 млн ₽ | 6,7–16,5 млн ₽ | 8–15 нед. | 12–24 нед. | Платежи, роли, мультиарендность |
| Видео в реальном времени / телемедицина | 5,5–13,7 млн ₽ | 9,7–24 млн ₽ | 12–20 нед. | 16–28 нед. | Медиасервер (SFU), комплаенс |
| ИИ-продукт (LLM + RAG) | 3,8–10,9 млн ₽ | 6,7–19,5 млн ₽ | 8–14 нед. | 10–20 нед. | Оценка качества ответов, стоимость инференса |
| Edtech-платформа с живыми занятиями | 7,7–20,5 млн ₽ | 13,5–36 млн ₽ | 15–23 нед. | 20–32 нед. | LMS-интеграции, видео, персональные данные |
Как считали: рынок без ИИ — диапазоны нашей воронки до ИИ-инструментов; часы с ИИ — смесь типов работы по профилю продукта (веб и SaaS ≈ 55% экономии часов, мобильное ≈ 50%, видео и edtech ≈ 43%, ИИ-продукт ≈ 44%; коэффициенты А −70%, Б −50%, В −22%, Г 0%); бюджет пересчитан по часам, середина диапазона экономии; календарь — срок × (1 − экономия × 0,75), 1–2 недели этапов типа Г (ревью сторов, нагрузочные тесты, приёмка) не сокращаются, итог округлён до недели вверх; инфраструктура, лицензии и сборы сторов в диапазоны не входят и не сокращаются; калибровка Фора Софт от ноября 2026 года (версия 2026-11-07).
Подробные разборы по отдельным категориям есть в статьях о стоимости приложения для видеостриминга и о том, что делать, если бюджет проекта превысил план. У видеопродуктов отдельная строка сметы: хранение и трафик. Прикинуть их помогут калькуляторы для видеоинженера (битрейт, стоимость хранения, окупаемость кодеков). Для большинства собственных серверных нагрузок мы берём Hetzner серии AX и DigitalOcean и в каждой смете отдельно указываем допущения по исходящему трафику.
Решение за пять вопросов — как принять смету подрядчика
Прежде чем подписывать смету, получите ответы на пять вопросов ниже. Если подрядчик не может письменно ответить на все пять в течение дня, документ пока не подписывайте.
В1. На какой стадии конуса неопределённости вы выставляете число? Ожидаемый ответ: явная стадия («требования собраны, ±1,5×») и артефакты, которые до неё довели (WBS, карта историй, архитектура).
В2. Каковы топ-5 допущений и что происходит с числом, если каждое из них изменить? Ожидаемый ответ: список с дельтами в часах по каждому допущению. Если допущений нет, оценки тоже нет.
В3. Что явно не входит в скоуп? Ожидаемый ответ: короткий список исключений. Фраза «ничего не исключено» должна насторожить.
В4. Какой интервал доверия — 50%, 80%, 90%? Ожидаемый ответ: пара P50 / P80 из PERT или Монте-Карло. Одно число обычно означает P50, внутри которого спрятана неопределённость.
В5. Как устроен процесс change-order и как отслеживается velocity? Ожидаемый ответ: письменный SLA по change-order, спринтовый план velocity и еженедельный пересмотр прогноза. Открытая velocity позволяет заметить перерасход до четвёртого месяца.
Подводные камни — пять способов, которыми оценка тихо губит проекты
1. Якорение на бюджет. Основатель говорит: «у нас 9 млн ₽». Подрядчик подгоняет объём работ так, чтобы он сложился в 9 млн ₽, а проект в итоге обходится в 14 млн ₽. Ошибка здесь в самом разговоре: не называйте число, пока не определён объём. Назовите решение («готовы вложить 9 млн ₽ в MVP и 15 млн ₽ всего за 18 месяцев») и попросите подрядчика уложить объём в этот конверт.
2. Накрутка без её называния. Скрытый буфер («я просто удвою всё») проверить невозможно. Если проект сдали раньше срока, буфер становится прибылью подрядчика. Если начался перерасход, резерв уже потрачен. Требуйте, чтобы резервы стояли в смете отдельными строками.
3. Игнорирование нефункциональных требований. Усиление аутентификации, логирование, мониторинг, доступность, ревью безопасности, соответствие GDPR / HIPAA, нагрузочные тесты, наблюдаемость, CI/CD не входят в список функций, но занимают недели. Им нужны отдельные строки в плане.
4. Оптимистическая ошибка на интеграциях. «Там есть SDK» почти никогда не вся история. Платёжные провайдеры, SSO-вендоры, LMS-системы, IoT-шлюзы и SIP-стеки добавляют по 3–5 недель по рынку без ИИ, которых нет в документации SDK, и с ИИ-инструментами почти столько же: отладка чужого SDK и ожидание поставщика относятся к типам В и Г. Подробнее в статье о том, как не стоит экономить на IT-проекте.
5. Оценить один раз и больше не пересматривать. Оценка всего лишь предположение. После второго спринта у вас уже есть реальные данные. Если подрядчик не сверяет прогноз с фактом каждый спринт, конус неопределённости не сузится никогда. Тихо меняющаяся оценка без объяснений чаще всего предвещает отмену проекта.
KPI — как измерять качество оценок
Качественные KPI. Коэффициент точности оценки (факт / оценка) по спринту. Цель: от 0,9 до 1,1 после третьего спринта. Если значение два спринта подряд выходит за пределы 0,7–1,3, это тревожный сигнал: скорее всего, объём расползается или оценки занижены.
Бизнес-метрики. CPI (Cost Performance Index) равен освоенному объёму, делённому на фактическую стоимость; цель ≥ 0,95. SPI (Schedule Performance Index) равен освоенному объёму, делённому на плановую стоимость; цель ≥ 0,90. Вместе они показывают, держите ли вы бюджет, сроки или и то и другое.
KPI надёжности. Тренд разброса прогноза. Постройте по спринтам линию «оценка против факта»: если линия ровная, оценкам подрядчика можно доверять, если конус расширяется, нельзя. Частота change-order: больше одного существенного изменения на четыре спринта обычно означает не «требования изменились», а пропущенный discovery.
AI в самом процессе оценки
LLM полезны на этапе discovery. Они делают первую версию карты пользовательских историй из бизнес-брифа, превращают черновые экраны Figma в критерии приёмки, находят пропуски в нефункциональных требованиях и расхождения между требованиями и вайрфреймами за минуты, а не за дни. В Фора Софт мы пользуемся ими регулярно, с проверкой человеком. Discovery в основном состоит из продуктовой работы и согласований (по нашей калибровке смесь типов Б 70% и Г 30%), поэтому часы стадий 2–3 сокращаются примерно на 35%, а календарь меньше: встречи с заказчиком быстрее не становятся.
Чего они пока не могут: заменить экспертное суждение «3 недели или 9 недель на эту задачу». Это по-прежнему аналоговая оценка опытного инженера, который знает предметную область. Как мы встраиваем ИИ в работу, читайте в материалах об ИИ в процессе разработки ПО и об ИИ в проектировании архитектуры.
Когда не стоит запускать тяжёлую оценку
Тяжёлая оценка нужна не всегда. Если вы покупаете двухнедельный прототип для проверки гипотезы, лучше подойдёт T&M-контракт с потолком и письменным условием остановки, чем трёхнедельный discovery и WBS снизу вверх. А для поддержки зрелого продукта стабильной командой история скорости этой команды надёжнее любой новой оценки.
Правило большого пальца: если проект короче ~8 недель или дешевле ~3 млн ₽ по рынку без ИИ (у Фора Софт с ИИ-инструментами это около 5 недель и 1,4 млн ₽ для веб-сервиса), пропускайте тяжёлую оценку и берите спринт с потолком. В остальных случаях discovery окупается.
Оцениваете первую разработку для видео, ИИ или edtech?
Именно этим мы занимаемся с 2005 года — 250+ проектов, 20+ лет опыта в реальном времени и с использованием ИИ. Опишите задачу одной фразой — и мы вернёмся с ROM, на который можно опираться.
FAQ
Насколько точной должна быть смета на разработку ПО?
Зависит от стадии. Грубая оценка на стадии питча — от −25% до +75%. Бюджетная после продуктового брифа — от −10% до +25%. Определённая после 2–4 недель платного discovery — от −5% до +10%. Тот, кто обещает ±5% без discovery, закладывает скрытую накрутку.
Что лучше для MVP стартапа — фикс-цена или почасовая оплата?
Ни то, ни другое в чистом виде. Самая надёжная форма, которую мы видим: оплачиваемый discovery по модели T&M с потолком (2–4 недели, известен максимум), а затем фиксированная разработка с письменным SLA по change-ордеру. Discovery даёт определённость, а согласованный change-бюджет сохраняет гибкость внутри каждого спринта.
Можно ли принять оценку, построенную только на Planning Poker?
Не для коммерческого обязательства. Planning Poker отлично работает в уже сформированной команде для прогнозирования спринтов, но требует наличия бэклога с проработанными историями и измеренной velocity. Для предконтрактной оценки комбинируйте его с bottom-up WBS и трёхточечным PERT: если три метода дают результаты в пределах 1,5× друг от друга — у вас надёжная оценка.
Сколько должен стоить этап discovery?
Примерно 5–8% общего бюджета проекта для нового продукта, 2–4 недели работы аналитика, архитектора и техлида. При бюджете разработки 15 млн ₽ по рынку без ИИ это 750 тыс. – 1,2 млн ₽. На выходе — карта пользовательских историй, архитектура, нефункциональные требования, реестр рисков и оценка разработки с диапазоном. Discovery срезает 10–25% лишнего объёма, поэтому окупается многократно.
Как ИИ-инструменты влияют на смету разработки ПО в 2026 году?
Неравномерно: шаблонный код дешевеет на 60–80% часов, продуктовая логика — на 40–60%, тяжёлая инженерия — на 15–30%, ревью сторов, лицензии и юристы — на 0% (калибровка Фора Софт, ноябрь 2026 года). Для веб-сервиса это около 55% часов, для видео и real-time — около 43%; календарь сокращается меньше. Например, MVP внутреннего инструмента — 4–8 недель с ИИ-инструментами (6–12 недель у команд без них).
Что такое конус неопределённости простыми словами?
Это наблюдение: ранние оценки ПО вполне могут ошибаться в 4 раза в любую сторону, и диапазон сужается только по мере принятия конкретных решений — по скопу, архитектуре, интерфейсу, критериям приёмки. Само время конус не сужает — его сужают решения. Четырёхнедельный неподписанный скоуп так же размытый, как и четырёхдневный.
Можно ли применять COCOMO II или Function Points к современному облачному продукту?
Только как кросс-проверку, не как основной метод. Некалиброванный COCOMO II (чьи референсные данные взяты из водопадных проектов 1990-х) может ошибаться в разы на облачных и микросервисных стеках и в командах с ИИ-ассистентами. Function Points точнее, но всё равно требуют локальной калибровки. В качестве основного используйте bottom-up + трёхточечный PERT, параметрические модели — как проверку.
Какие красные флаги в смете подрядчика?
Одно точечное число, нет списка допущений, нет списка исключений, нет интервала доверия, нет строки на QA или DevOps, нет строки на PM-надзор, нет процесса change-order. Любые два из этих признаков вместе означают, что перед вами не оценка, а цена — и риск приземлится на вас на третьем месяце.
Что читать дальше
Процесс
Этапы разработки ПО: семь фаз от идеи до релиза в 2026 году
Этапы разработки ПО по шагам: discovery, дизайн, архитектура, спринты, тесты, релиз. Сроки с ИИ и без, каскад или Agile, метрики DORA, ГОСТ и FAQ.
Гайд по стоимости
Как CTO оценивать стоимость IT-проектов в 2026 году
28% проектов выходят за бюджет — как избежать ошибок. Практический гид для CTO: 5 методов оценки, реальные кейсы, красные флаги в RFP и скрытые расходы.
Бюджет
Бюджет проекта превысил план: что делать в 2026
Бюджет IT-проекта вышел за план? Шесть причин перерасхода, расчёт CPI на примере, четыре хода спасения и что дорожает в 2026 году. Опыт 250+ проектов.
Кейс
Как ИИ сократил время разработки на 30–40% на видеостриминговой платформе из 1 млн+ строк: кейс 2026
Реальные метрики VALT, видеоплатформы возрастом 12 лет и 1 млн+ строк: где ИИ сжал расследование багов, ревью и контекст на 30–40%, где нет. Кейс Фора Софт.
MVP
Зачем выпускать продукт раньше: что такое MVP
Что такое минимально жизнеспособный продукт — на реальных примерах. Разбираем ключевые моменты планирования, чтобы помочь вам начать.
Готовы превратить шаткую смету в подписанный план?
Оценка ПО, в конце концов, — это дисциплинированный разговор между объёмом работы, уверенностью и риском. Инструменты (аналоговый метод, bottom-up, PERT, Planning Poker, Монте-Карло) важны меньше, чем привычки: называть стадию конуса, оценивать невидимые задачи, держать форму контракта честной и пересматривать прогноз каждый спринт. Сделайте эти четыре вещи — и ваша оценка перестанет быть гаданием и станет планом, который можно показать CFO.
В Фора Софт мы работаем по этому плейбуку каждую неделю, на платформах видео в реальном времени, ИИ-продуктах и edtech, и готовы применить его к вашей смете. Позвоните или напишите: за полчаса пройдём по текущей смете с пятью ключевыми вопросами из этого разбора. Принесите PDF, и мы разберём его с пометками.
Получите второе мнение по вашей смете
Бесплатный 30-минутный разбор — пять вопросов, размеченный PDF, честный вердикт: можно ли защитить вашу текущую смету.
