Как заказать разработку ПО в 2026 году: как составить точную и обоснованную смету

Почему Фора Софт написала это руководство

С 2005 года Фора Софт выпустила более 625 программных продуктов — в основном это платформы для видео в реальном времени, искусственного интеллекта и аудио, где один неправильный выбор SDK может удвоить бюджет. За два десятилетия скоупинг-звонков мы писали, подписывали и сдавали оценки всех возможных форматов: от быстрых идей на салфетке для основателей до 40-страничных Master Service Agreement для компаний из списка Fortune, спринтовых графиков выполнения задач, контрактов на результат и всего, что между ними. Это руководство — сжатая версия того, что действительно работает и выдержало проверку подписанными заказами.

Мы запускаем discovery перед каждой фиксированной сметой, отслеживаем разницу между оценкой и реальным результатом по каждому проекту и знаем, какие статьи подрядчики регулярно упускают — потому что сами когда-то их упускали. Если хотите получить независимую оценку уже существующей сметы или провести полноценный discovery вместо цифры, которой не доверяете, посмотрите наш сервис планирования и аналитики или узнайте, как Фора Софт ведёт разработку от старта до завершения.

Что такое оценка разработки ПО (и чем она не является)

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

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

Почему половина проектов до сих пор выходит за рамки бюджета

Цифры почти не изменились за тридцать лет. Отчёт CHAOS от Standish Group из года в год показывает: лишь около 31% проектов сдаются в срок и в рамках бюджета, 52,7% выходят за рамки бюджета в среднем на 189%, а около 19% вообще отменяются. Отчёт PMI Pulse of the Profession 2025 даёт глобальный показатель попадания в бюджет на уровне около 50%. CISQ оценил годовую стоимость низкого качества ПО только в США примерно в 180 трлн ₽, а технический долг — ещё примерно в 114 трлн ₽.

Основные причины провалов во всех исследованиях удивительно схожи: scope creep (расползание объёма работ — затрагивает 52–70% проектов), слабый сбор требований (упоминается в ~39% провалов), пропущенные нефункциональные задачи (безопасность, доступность, производительность, DevOps) и якорение — когда сроки и ресурсы подгоняют под бюджет, а не под реальные задачи. Почти все эти проблемы возникают ещё до написания кода.

Конус неопределённости — у вашей оценки есть допустимый разброс

Барри Бём первым нарисовал, а Макконнелл популяризировал конус неопределённости (Cone of Uncertainty): наблюдение, что точность оценки зависит от того, сколько уже решено, а не от того, сколько обсуждено. На стадии «первоначальной концепции» — после первого 30-минутного звонка — строгая оценка вполне может отличаться от итогового результата в диапазоне от 0,25× до 4×. То есть погрешность достигает 16×. Отрицать это — признак профессиональной некомпетентности.

Рисунок 1 — Конус неопределённости. Каждая отметка по оси X — это решение, а не дата. Конус сужается только тогда, когда решения приняты и подписаны.

Эту диаграмму часто неправильно понимают с двух сторон. Основатели иногда думают, что конус сужается со временем — но это не так. Команда, которая четыре недели «скоупит» без письменной карты пользовательских историй, NFR и критериев приёмки, всё ещё находится в диапазоне ±4×. Подрядчики иногда предлагают фиксированную цену на стадии «питча» и поглощают неопределённость, накручивая стоимость в 2–3 раза. Либо накрутка оправдана — и заказчик переплачивает, либо она недооценена — и проект умирает на середине разработки.

Три типа оценок — выбирайте подходящий под задачу

Не каждая оценка требует одинаковой точности. Тратить четыре недели на высокоточную оценку для решения на 2,2 млн ₽ — пустая трата времени. PMI Practice Standard делит оценки по уровню точности, а ниже мы сопоставляем их с решениями заказчика.

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

Шесть методов оценки, которые до сих пор использует серьёзный подрядчик

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

Аналоговый (экспертная оценка на основе прошлых проектов)

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

Top-down (декомпозиция от проекта к эпикам)

Разбиваете проект на 6–10 эпиков, назначаете каждому диапазон по аналоговой истории, суммируете. Прекрасно для взгляда CFO. Слабо для планирования спринтов, потому что скрывает детали из 300 пользовательских историй, которые и определяют реальное сгорание бюджета. Хорошо как первый проход в ходе discovery — для проверки bottom-up.

Bottom-up / Work Breakdown Structure

Декомпозируйте задачи до объёма 4–16 инженерных часов, оцените каждую, добавьте накладные расходы на PM, QA и DevOps. Самый точный метод, когда у вас уже есть полная карта пользовательских историй, критерии приёмки и архитектура. Он дорогой в реализации — мы берём за него деньги в рамках discovery — и сильно ошибается, если на вход подаётся неполный скоуп. Именно на нём строится конкретная оценка.

Параметрический (COCOMO II, Function Points)

Скармливаете модели (размер в KLOC или function points, факторы сложности, опыт команды) и получаете математический результат. Полезен как тай-брейкер, когда top-down и bottom-up расходятся. Оговорка: оригинальная калибровка COCOMO II относится к водопадным проектам 1990-х; академические исследования показывают, что некалиброванный COCOMO может давать ошибку около 100% на современных облачных, микросервисных и AI-ассистированных стеках. Если подрядчик ссылается на COCOMO, спросите, когда он в последний раз калибровал модель на собственных данных.

Planning Poker (оценка в story points по консенсусу)

Классика Майка Кона: вся инженерная команда показывает карточки модифицированного Фибоначчи (1, 2, 3, 5, 8, 13, 20, 40, 100) для каждой истории; те, кто на краях, объясняют свою позицию, команда переголосовывает и приходит к консенсусу. Ловит скрытую сложность, которую индивидуальные оценки всегда упускают, и формирует у команды ответственность за план. Через 3–4 спринта скорость стабилизируется, и те же карточки конвертируются в надёжные дни. Не используйте на стадии питча — команды у вас ещё нет.

Трёхточечный PERT + Монте-Карло

Для каждой строки при bottom-уп подходе фиксируем три оценки: оптимистичную (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% от общего бюджета — и по нашей практике контрактов мы экономили 30–50% на последующей разработке, потому что ошибочные допущения устранялись ещё до написания кода. Как мы обычно определяем объём работы на стадии 2, можно узнать в статье о том, почему запуск с минимальным функционалом эффективнее разработки полного скоупа.

Что должна включать полная оценка (и что упускают 80% смет)

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

Если смета примерно равна стоимости часов на разработку фич, подрядчик оценил 35–45% реальной стоимости и либо планирует компенсировать разницу, либо — что чаще — доборотать через change-ордер позже.

Модели контрактов: кто несёт ответственность за риск, если оценка оказалась ошибочной

Оценка кормит контракт, а контракт распределяет риск. Пять форм ниже — те, что реально встречаются в наших MSA в 2026 году.

Параллельный взгляд на процесс найма команды — в материале о том, как мы подбираем разработчиков под проект.

Agent Engineering в 2026 году — что это реально меняет в вашей смете

Agentic-инструменты для кодинга изменили соотношение затрат, но неравномерно. Заголовочные цифры обнадёживают: отчёт Anthropic Agentic Coding Trends 2026 оценивает долю AI-инструментов среди работающих разработчиков примерно в 90%, а около 41% нового кода теперь генерируется ИИ. Наша внутренняя телеметрия (по проектам в области видео в реальном времени, ИИ и edtech) показывает сокращение времени на разработку новых функций на 25–40% в «зелёных» проектах, где предметная область хорошо представлена в обучающих данных.

Загвоздка дальше по конвейеру. Исследование производительности GitHub и State of AI 2025 от McKinsey отмечают один и тот же паттерн: AI-сгенерированный код несёт ~1,7× больше дефектов на ревью pull request, если усилия на ревью остаются прежними. Сеньорные инженеры извлекают примерно в 5 раз больше пользы, чем джуниоры. В переводе на смету это значит:

1. Разработка фич сжимается на ~25–40% на greenfield. Привычные стеки (CRUD, API-обвязка, тестовые каркасы, шаблонный код) получают максимальный прирост. Кастомные видео-пайплайны, доменно-специфичный ML, интеграции SDK и работа на стыке с железом — почти не меняются.

2. QA и ревью кода вырастают на ~15–25%. Чем больше кода пишется за час, тем больше ревью нужно за тот же срок. Сокращение ревью — самый быстрый путь к выпуску продукта с дефектностью в 1,7 раза выше нормы.

3. Состав команды смещается к сеньорам. Связка сеньор-лид / мидл / джуниор, которая была выгодной в 2022 году (примерно 1:2:2), сегодня лучше окупается в пропорции ~1:2:1, с одним-двумя сеньорными ревьюерами на под.

4. Чистый эффект на типичной 12-недельной разработке. Наши данные по разрыву между оценкой и фактическими результатами показывают, что реальная экономия по общей стоимости составляет 15–25%, а не 40%, как утверждают маркетинговые презентации. Любой подрядчик, который говорит просто «AI делает это на 50% дешевле», не учитывая затраты на ревью кода, завышает свою маржу.

Реальный случай поставки с цифрами описан в материале о том, как ИИ сократил время разработки на 40% на платформе видеостриминга с кодовой базой более чем в 1 млн строк — эти 40% рассчитываются только по чистым часам программирования, а не по всему проекту.

Мини-кейс — как discovery помог избежать провала оценки в 31 млн ₽

Ситуация. Американский основатель edtech-проекта пришёл к нам с фиксированной сметой от другого подрядчика: 31 млн ₽ за платформу онлайн-репетиторства с живым видео, общей доской, генерацией планов уроков на основе ИИ и LTI-интеграцией с дюжиной LMS. Смета состояла из 26 страниц перечня функций — без учёта нематериальных требований, без структуры работ и без реестра рисков. Разработка планировалась на 14 недель.

План на 12 недель. Мы провели 3-недельный оплачиваемый этап исследования (~1,3 млн ₽). На выходе получили: карту пользовательских историй (147 историй), реестр рисков из 31 записи, эталонную архитектуру, NFR-бриф с учётом требований FERPA и SOC 2, а также оценку сроков снизу вверх и трёхточечную оценку PERT с расчётом по методу Монте-Карло. Два решения, которых не было в исходной смете: (а) LTI-интеграции нужно было реализовать для 12 различных LMS, а не для одной платформы, и (б) функция AI-генерации планов уроков требует проверки человеком (human-in-the-loop) в округах, где действуют нормы FERPA.

Итог. Реальный объём работ с разбросом ±10% занял 18 недель и обошелся в 40 млн ₽ — на 28% дороже и на 29% дольше первоначальной сметы. Основатель вернулся к первому подрядчику, и тот признал, что разницу всё равно пришлось бы дорабатывать через change-ордер на третьем-четвёртом месяце. Клиент выбрал у нас фиксированную разработку, сдал проект в срок — за 18 недель, потратил 94% бюджета и избежал пересогласований в середине проекта, которые обычно срывают большинство edtech-раундов. Похожий edtech-кейс с более чем 500 000 студентов — разработка ALDA, генератора AI-курсов.

Ориентировочная модель стоимости — типичные диапазоны на 2026 год

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

Подробные разборы — в нашем гайде по стоимости мобильных приложений 2026 и в CTO-гайде по ценам на видеостриминг. Под большинство self-hosted нагрузок мы используем Hetzner серии AX и DigitalOcean, а в каждой смете чётко указываем допущения по cloud egress.

Решение за пять вопросов — как принять смету подрядчика

Прежде чем подписывать смету, ответьте на пять вопросов ниже. Если подрядчик не может дать письменные ответы на все пять в течение дня — пока не подписывайте документ.

В1. На какой стадии конуса неопределённости вы выставляете число? Ожидаемый ответ: явная стадия («требования собраны, ±1,5×») и артефакты, которые до неё довели (WBS, карта историй, архитектура).

В2. Каковы топ-5 допущений и что происходит с числом, если каждое из них изменить? Ожидаемый ответ: список с дельтами в часах по каждому допущению. Нет допущений — нет оценки.

В3. Что явно не входит в скоуп? Ожидаемый ответ: краткий список исключений. Фраза «ничего не исключено» — тревожный сигнал.

В4. Какой интервал доверия — 50%, 80%, 90%? Ожидаемый ответ: пара P50 / P80 из PERT или Монте-Карло. Если указано одно число — это P50 с встроенной неопределённостью.

В5. Как устроен процесс change-order и как отслеживается velocity? Ожидаемый ответ: письменный SLA по change-ord’у, спринтовый план 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. Подробнее — в материале о том, чего не стоит делать при сокращении бюджета.

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-ордеров: более одного существенного изменения на четыре спринта обычно говорит не о том, что «требования изменились», а о том, что этап исследования (discovery) был пропущен.

AI в самом процессе оценки

LLM сегодня действительно полезны на этапе discovery: генерируют первую версию карты пользовательских историй из бизнес-брифа, превращают черновые экраны Figma в критерии приёмки, выявляют возможные пропуски в NFR и находят несоответствия между требованиями и вайрфреймами за минуты, а не за дни. В Фора Софт мы используем их регулярно — в связке с проверкой человеком — и сокращаем стадии 2–3 воронки discovery примерно на 30%.

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

Когда не стоит запускать тяжёлую оценку

Тяжёлая оценка — не всегда правильный выбор. Если вы закупаете двухнедельный прототип для проверки гипотезы, лучше подойдёт T&M-контракт с потолком и чётким письменным kill-ключом, чем трёхнедельный этап исследования и построение WBS снизу вверх. А если речь идёт об обслуживании зрелого продукта стабильной командой, то история скорости работы команды надёжнее любой новой оценки.

Правило большого пальца: если проект длится меньше ~8 недель или стоит меньше ~3 млн ₽, пропускайте сложную оценку и берите спринт с потолком. В остальных случаях математика discovery окупается каждый раз.

FAQ

Насколько точной должна быть смета на разработку ПО?

Зависит от стадии. Грубый порядок величины на стадии питча — от −25% до +75%. Бюджетная оценка после продуктового брифа — от −15% до +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% от общего бюджета проекта для greenfield-продукта. На разработке за 15 млн ₽ это 750 тыс. – 1,2 млн ₽ за две-четыре недели сеньорного времени. На выходе — подписанная карта пользовательских историй, архитектура, NFR-бриф, реестр рисков и предварительная оценка разработки. Такие затраты окупаются в 4–6 раз, потому что неработоспособный скоуп отсекается до начала кодирования.

Как AI-кодинг влияет на оценку стоимости ПО в 2026 году?

Чистое сокращение времени на типичной 12-недельной разработке — около 15–25%, а не 40% и более, как утверждают в маркетинговых материалах. Время на разработку новых функций сокращается на 25–40%, но нагрузка на тестирование и ревью растёт на 15–25%, потому что код, сгенерированный ИИ, содержит примерно в 1,7 раза больше ошибок при той же нагрузке на ревью. Опытные разработчики работают заметно эффективнее, чем начинающие.

Что такое конус неопределённости простыми словами?

Это наблюдение: ранние оценки ПО вполне могут ошибаться в 4 раза в любую сторону, и диапазон сужается только по мере принятия конкретных решений — по скопу, архитектуре, интерфейсу, критериям приёмки. Само время конус не сужает — его сужают решения. Четырёхнедельный неподписанный скоуп так же размытый, как и четырёхдневный.

Можно ли применять COCOMO II или Function Points к современному облачному продукту?

Только как кросс-проверку, не как основной метод. Некалиброванный COCOMO II (чьи референсные данные взяты из водопадных проектов 1990-х) может давать ошибку около 100% на облачных, микросервисных и AI-ассистированных стеках. Function Points точнее, но всё равно требуют локальной калибровки. В качестве основного используйте bottom-up + трёхточечный PERT, параметрические модели — как проверку.

Какие красные флаги в смете подрядчика?

Одно точечное число, нет списка допущений, нет списка исключений, нет интервала доверия, нет строки на QA или DevOps, нет строки на PM-надзор, нет процесса change-order. Любые два из этих признаков вместе означают, что перед вами не оценка, а цена — и риск приземлится на вас на третьем месяце.

Что читать дальше

Готовы превратить шаткую смету в подписанный план?

Оценка ПО, в конце концов, — это дисциплинированный разговор между объёмом работы, уверенностью и риском. Инструменты (аналоговый метод, bottom-up, PERT, Planning Poker, Монте-Карло) важны меньше, чем привычки: называть стадию конуса, оценивать невидимые задачи, держать форму контракта честной и пересматривать прогноз каждый спринт. Сделайте эти четыре вещи — и ваша оценка перестанет быть гаданием и станет планом, который можно показать CFO.

В Фора Софт мы запускаем этот плейбук каждую неделю — на платформах видео в реальном времени, AI-продуктах и edtech-разработках — и готовы применить его к смете, которая перед вами прямо сейчас. Позвоните или напишите — за полчаса проведём вас по текущей смете, ответив на пять ключевых вопросов из этого руководства. Принесите PDF — пройдёмся по нему с пометками.