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

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

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

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

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

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

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

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

Метод 1: Bottom-up

Как работает. Декомпозиция до user stories или эпиков. Оценка каждой истории в story points или человеко-днях. Сумма. Накладные расходы (PM, QA, проверка кода). Резерв на риски. Перевод в календарные недели через скорость команды.

Затраты времени. 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); реже — в сильно изменчивых вертикалях (заказная AI-разработка, видео).

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…), выпускает X очков за спринт (скорость), делит оставшийся объём на скорость и получает количество спринтов. Калибровка скорости занимает минимум 3–5 спринтов.

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

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

Перевод скорости в стоимость. При устойчивой скорости (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. Делали такой проект раньше? Да → по аналогии плюс bottom-up. Нет → PERT или Монте-Карло с явно прописанными резервами на риски.

В4. Кому нужна оценка? Инженерной команде → bottom-up с детализацией по 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 %, слишком тонкие).

Бизнес-KPI. Доля выигранных предложений (цель — 30–45 % по тёплым лидам). Маржа факт vs план (цель — в пределах 5 %).

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

FAQ

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

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

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

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