5 способов оценить разработку ПО: сравнение с реальными данными (2026)

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

Фора Софт оценивает около 80 новых проектов в год и доводит до релиза 50–60. Точность в 78 % (попадание в 15 % от исходной оценки) откалибрована по более чем 625 выпущенным проектам с 2005 года. Закономерности из этого руководства собраны на основе этих данных, а также публичных источников — PMI, исследований McKinsey по ИТ-проектам и модели COCOMO II.

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

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

Почему большинство команд выбирают неподходящий метод

По данным PMI, 28 % ошибок в прогнозах стоимости связаны именно с неточными оценками. Самый частый сценарий: команда использует аналоговую оценку сверху вниз («похоже на тот проект, что мы уже делали») в фиксированном контракте, где требовалась точность снизу вверх. Или применяет оценку снизу вверх к проекту с настолько изменчивым объёмом, что декомпозиция теряет смысл уже через две недели.

Метод должен соответствовать неопределённости. Если объём зафиксирован и команда уже работала над похожими проектами, bottom-up даёт точность ±15 %. Если объём известен, но опыта с такими проектами нет, подойдут параметрический метод или PERT — они позволяют учитывать неопределённость. Если объём постоянно меняется, ни один метод не обеспечит точности — в этом случае лучше использовать T&M с еженедельными контрольными точками, чем фиксированную оценку, которая к третьей неделе уже будет неактуальной.

Метод 1: снизу вверх

Как работает. Разбиваем задачу на user stories или эпики. Оцениваем каждую историю в story points или человеко-днях. Складываем оценки. Добавляем накладные расходы — работу менеджера, тестировщика, ревью кода. Учитываем резерв на риски. Переводим итог в календарные недели, исходя из скорости команды.

Затраты времени. 1–3 дня для проекта на 15 млн ₽. Старший инженер и менеджер проекта прорабатывают истории.

Точность. ±15 %, если объём зафиксирован и команда уже делала похожее. ±30 % — при менее опытной команде или при изменяющемся объёме.

Когда применять. Контракты с фиксированной ценой. Объём работ известен заранее. Вы можете детально распланировать все этапы.

Таблица. Колонки: модуль, user stories, story points, человеко-дни, трудозатраты с учётом накладных расходов (+25 % на QA, +12 % на PM, +8 % на проверку кода), трудозатраты с резервом на риски (+15 %), календарные недели по скорости команды. Внизу — итог; сообщайте диапазон, а не точечную оценку.

Метод 2: Top-down (по аналогии)

Как работает. Берёте 1–3 исторических проекта, похожих по характеру. Корректируете на различия (больше платформ = +30 %, упрощённый процесс = –20 %, другой стек = +15 %). На выходе — диапазон.

Затраты времени. От 30 минут до 2 часов.

Точность. ±30 % в оптимистичном сценарии — достаточно для коммерческого предложения, но не подходит для контракта.

Когда применять. Первый разговор с клиентом. Оценка масштаба инвестиций. Перекрёстная проверка для последующего bottom-up.

Шаблон. «Проект X для клиента Y занял 6 месяцев и стоил 18 млн ₽. Новый проект похож, но добавляется Android (плюс 30 %) и убирается запись (минус 15 %). Диапазон: 19–24 млн ₽, 6–7 месяцев». Обозначайте ±30 % явно.

Метод 3: Параметрический (FPA, COCOMO II)

Как работает. Расчёт трудозатрат через модель со взвешенными параметрами. Function Point Analysis (FPA) считает входы, выходы, запросы, файлы и внешние интерфейсы. COCOMO II вычисляет трудозатраты по оценочному количеству строк кода (или функциональных точек), уровню опыта команды и факторам сложности. Результат — трудозатраты в человеко-месяцах.

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

Когда применять. Повторяющиеся типы проектов, где есть 5 и более завершённых проектов для калибровки. Часто встречается в корпоративном ИТ — например, e-commerce-сайты, CRM, простые SaaS. Реже — в быстро меняющихся сферах, таких как заказная разработка ИИ или видео.

FPA-light. Полноценный ISO/IEC 20926 FPA большинству команд недоступен. FPA-light считает user stories, взвешенные по сложности (простая = 1, средняя = 3, сложная = 5), и применяет множитель «человеко-дней на очко», откалиброванный по истории. Полезен как первичная проверка здравого смысла.

Метод 4: PERT по трём точкам

Как работает. Для каждой задачи задаются три значения: оптимистичное (O — всё идёт хорошо), наиболее вероятное (M) и пессимистичное (P — всё идёт плохо). Среднее по PERT = (O + 4M + P) / 6. Стандартное отклонение = (P − O) / 6. Суммируем по всем задачам; общее отклонение по проекту = sqrt(сумма дисперсий задач).

Результат. Точечная оценка и доверительный интервал. Среднее ± 1 SD охватывает 68 % исходов; среднее ± 2 SD — 95 %.

Когда применять. В проекте 1–3 модуля с высокой неопределённостью. Применяйте PERT к ним, а bottom-up — ко всему остальному.

Разобранный пример. «Интеграция кастомного AI-скрайба: оптимистично 4 недели (API вендора стабилен, дообучение работает с первой попытки), наиболее вероятно 6 недель, пессимистично 12 недель (API вендора меняется по ходу, на дообучение нужно больше данных, появляются крайние случаи (edge cases)). Среднее по PERT = (4 + 24 + 12) / 6 = 6,67 недели. SD = (12 − 4) / 6 = 1,33. 95 % доверительный интервал: 4–9,3 недели»

Метод 5: Симуляция Монте-Карло

Как работает. Для каждой задачи задаются распределения вероятностей — треугольное, бета или логнормальное. Затем моделируется 10 000 запусков проекта, при каждом из которых берётся случайное значение из каждого распределения. В результате получается кумулятивная кривая вероятности: «У проекта есть X % шансов завершиться к месяцу Y и уложиться в бюджет Z».

Когда применять. Корпоративные проекты от 75 млн ₽ со значимыми рисками. Отчётность для совета директоров, где нужна формулировка «80 % шанс уложиться в 90 млн ₽». Бюджетирование с учётом рисков.

Инструменты. Плагин @RISK для Excel, @RISK Lite или несколько сотен строк на Python (numpy + matplotlib). Наш Python-ноутбук укладывается в <200 строк для проекта из 30 задач.

Стоимость. 4–8 часов работы старшего инженера или PM на правильную настройку под проект. Шаблон модели можно использовать повторно.

Сравнение бок о бок — один проект, 5 оценок

Проект: MVP в телемедицине. 10 врачей, 3000 пациентов, только США, чтение и запись через FHIR R5.

Все пять методов дают в целом согласованные результаты в диапазоне медианы 18–23 млн ₽, а разброс отражает, как каждый из них работает с неопределённостью. Метод снизу вверх (bottom-up) даёт самый узкий диапазон, потому что у него меньше всего неизвестных, способных увеличить погрешность. Метод сверху вниз (top-down) — самый широкий, поскольку опирается на одну точку калибровки. Монте-Карло выдаёт самый информативный результат (полное распределение) при самой высокой стоимости подготовки.

Оценка в story points для гибких команд

Story points — это не оценки. Это данные о относительной сложности задач. Команда оценивает работу в story points (по шкале Фибоначчи: 1, 2, 3, 5, 8, 13…), определяет, сколько очков успевает делать за спринт (это и есть скорость), делит общий объём на скорость и получает примерное количество спринтов. Чтобы скорость стала стабильной, нужно минимум 3–5 спринтов на её выработку.

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

Размеры по футболкам (T-shirt sizing). Грубее, чем шкала Фибоначчи: XS / S / M / L / XL. Полезно на ранней стадии, когда задачи ещё неясны; затем переходите к story points, когда объём станет понятнее.

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

Как выбрать метод под ваши задачи

Фреймворк для выбора — пять вопросов

В1. Фиксированная цена или T&M? Фиксированная цена требует bottom-up. T&M допускает top-down или PERT.

В2. Размер проекта? <3,7 млн ₽: можно top-down. 3,7–37 млн ₽: bottom-up. 37–375 млн ₽: bottom-up плюс PERT на неопределённые модули. От 375 млн ₽: полноценный Монте-Карло.

В3. Делали такой проект раньше? Да → делаем по аналогии, дополняя снизу вверх. Нет → используем PERT или метод Монте-Карло с чётко прописанными резервами на риски.

В4. Кому нужна оценка? Инженерной команде → снизу вверх с детализацией по story points. Совету директоров → диапазон с доверительными интервалами. Обоим → готовьте оба варианта.

В5. Сколько времени на оценку? 1 час: top-down. 1–2 дня: bottom-up. От недели: PERT или Монте-Карло. Подбирайте метод в зависимости от бюджета на оценку.

Чего избегать

1. Точечная оценка без доверительного интервала. «15 млн ₽» создаёт ложное ощущение точности. Всегда указывайте диапазон или явный доверительный интервал.

2. Неверная калибровка скорости. Неопытные команды берут больше задач, чем успевают выполнить, и завышают скорость. Калибруйте по 3–5 реальным спринтам, а не по оценкам.

3. Скрытые резервы на риски. Незаявленный «запас» в смете подрывает доверие, когда проект доходит до 105 %. Прописывайте резервы отдельной строкой.

4. Пропуск нефункциональных работ. NFR (соответствие требованиям, производительность, доступность интерфейсов) — это 30–60 % от общего объёма. Оценки, которые их игнорируют, ошибаются примерно на эту величину. См. наш чек-лист по NFR.

5. Отсутствие пост-мортема. Каждый проект — это опыт для следующего. Без анализа реальных трудозатрат по сравнению с оценками команда не развивается.

KPI для измерения точности оценок

KPI качества. Точность оценки: соотношение факт / план — не более 15 % хотя бы на 75 % проектов. Доля израсходованного резерва на риски (цель — 50–70 %; если всегда ниже 30 % — резервы завышены; если всегда выше 90 % — недостаточно).

Бизнес-метрики. Доля выигранных заявок (цель — 30–45 % по тёплым лидам). Фактическая маржа по сравнению с планом (цель — отклонение не более 5 %).

KPI надёжности. Доля проектов с постмортемом (цель — 100 %, разбор нужен по каждому). Количество запросов на изменения в ходе проекта (большое число говорит о плохо прописанном объёме).

FAQ

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

Готовы оценивать как следует?

Пять методов, пять разных ответов, пять подходящих инструментов под разные неизвестные. Bottom-up — для фиксированной цены. Top-down — для коммерческого предложения. Параметрический — когда модель откалибрована. PERT — при неопределённости. Монте-Карло — для корпоративных проектов от 75 млн ₽. Подбирайте метод под свои неизвестные; коммуницируйте диапазон, а не точку; делайте резервы на риски явными.

Story points — это данные о скорости команды, а не оценки сложности задач. Калибруйте их на основе 3–5 реальных спринтов. Проводите разбор после каждого проекта — сравнение «факт против оценки» — это самый ценный актив для следующего цикла.