Как CTO оценивать стоимость IT-проектов в 2026 году

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

С 2005 года компания Фора Софт реализовала более 625 проектов для 400+ клиентов. Мы оцениваем около 80 новых проектов в год. Примерно в 78% случаев проекты сдаются в пределах 15% от первоначальной оценки — это значительно выше среднего показателя по PMI. Остальные 22% отклонений почти всегда связаны с одной из пяти типичных ошибок в процессе оценки (подробный разбор — в §3).

Знаковые проекты, на которых мы калибруем оценки: BrainCert (e-learning-платформа с годовой выручкой 750 млн ₽), StreamLayer (NBC, CBS, Red Bull), CirrusMED (телемедицина с поддержкой HIPAA), VALT (650+ юридических организаций), TransLinguist (NHS Великобритании), EyeBuild (видеонаблюдение на солнечной энергии с ИИ). По каждому из этих проектов у нас есть post- mortem, который мы используем в дальнейших расчётах.

Если вы CTO, основатель или вице-президент по продукту и сейчас собираете коммерческие предложения от подрядчиков, этот гид подскажет, какой метод оценки подходит для ваших задач, где могут скрываться дополнительные расходы, на какие «красные флаги» в RFP стоит обратить внимание и как составить бриф, чтобы сузить разброс оценок.

Цифра 28 % — что показало исследование PMI

Исследование Pulse of the Profession от Project Management Institute показало: 28 % провалов проектов связаны с неточными оценками стоимости. Отчёт CHAOS от Standish Group называет ещё более жёсткую цифру — около 60 % программных проектов перерасходуют исходный бюджет минимум на 25 %. По данным McKinsey 2020 года (выборка из 5 400 ИТ-проектов), крупные проекты в среднем уходят за бюджет на 45 %, опаздывают на 7 % и приносят на 56 % меньше ценности, чем планировалось.

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

Пять причин, по которым оценки падают

1. Размытые требования (убийца №1). «Сделайте нам приложение как Uber для X» — это не бриф. За такой формулировкой скрыто 50 решений: платежи, KYC, разрешение споров, диспетчеризация, динамические тарифы — и каждое из них даёт десятикратный разброс стоимости в зависимости от выбранного варианта.

2. Якорение на оптимизме. Первая названная оценка становится отправной точкой. Если подрядчик сказал «3 месяца» и ваш CFO это услышал, любая следующая оценка будет сравниваться с тремя месяцами и вызывать вопросы, если окажется больше. Настоящие оценки — это диапазоны, а не одно число.

3. Игнорирование нефункциональных требований. «Сделать функцию» — это только половина задачи. «Обеспечить доступность 99,95 %, соблюдение GDPR, поддержку 100 тыс. DAU и работу на iOS 14+» — вторая половина. Оценки, в которых не учтены нефункциональные требования, могут не учитывать 30–60 % реальной работы.

4. Недооценка рисков сторонних зависимостей. «Мы интегрируемся с API подрядчика X» — это значит, что API имеет документацию, стабильно работает и соответствует требованиям BAA. Однажды мы потеряли шесть недель, потому что сторонний API достиг лимитов, о которых ни в одной документации не упоминалось.

5. «Скидка от основателя». Когда оценку даёт сам основатель, побеждает оптимизм. Основатели не закладывают запас, потому что хотят, чтобы проект стартовал. Поэтому мы всегда отправляем внутренние оценки дороже 7,5 млн ₽ на независимую проверку старшему инженеру.

Пять методов оценки

Bottom-up. Разбейте проект на пользовательские истории или функциональные элементы, оцените каждый отдельно, сложите результаты, добавьте накладные расходы и резерв на риски. Подходит по умолчанию для контрактов с фиксированной ценой. Время на оценку: 1–3 дня для проекта стоимостью 15 млн ₽.

Top-down по аналогам. «Проект X для клиента Y занял 6 месяцев и 18 млн ₽; этот — похожий». Полезно для первых переговоров, но опасно для контрактов. Погрешность ±30 % при оптимистичном сценарии.

Параметрический (COCOMO II, FPA). Оценка строится на модели с весовыми параметрами — строки кода, функциональные точки, факторы сложности, продуктивность команды. Требует исторических данных для настройки. Внутри мы используем упрощённый FPA для быстрой проверки на здравый смысл.

PERT с тремя точками. Оцените оптимистичный (O), наиболее вероятный (M) и пессимистичный (P) сценарии. Посчитайте среднее по PERT = (O + 4M + P) / 6 и стандартное отклонение = (P − O) / 6. Получите доверительный интервал. Используйте, когда есть важные неизвестные, но нет бюджета на полноценный метод Монте-Карло.

Симуляция Монте-Карло. Для каждой задачи задаётся распределение вероятностей, проводится 10 000 виртуальных расчётов проекта, на выходе получается кривая доверительного интервала. Метод применяется только на корпоративных проектах от 75 млн ₽ с высокими рисками.

Разбор примера — MVP телемедицины

Реальный MVP телемедицины, который мы оценивали в начале 2025 года (анонимизировано). Объём: видеоконсультации с поддержкой HIPAA, расписание, портал пациента, портал врача, передача биллинга в существующую PMS. Аудитория: 10 врачей, 3000 пациентов, только США, только английский.

Декомпозиция снизу вверх.

При типичной смешанной ставке среднеценовой команды в США/ЕС это даёт диапазон примерно 18–31 млн ₽ в зависимости от состава команды и доли сениоров. Реальный проект, который мы выпустили, оказался в нижней части диапазона благодаря переиспользованию паттернов Agent Engineering из CirrusMED.

Разбор примера — OTT-платформа стриминга

OTT-платформа с VOD и live-стримингом, с собственными брендированными приложениями для web, iOS, Android и Connected TV (Roku, Fire TV, Apple TV). Стартовый каталог — 10 000 часов, расписание прямых эфиров, рекламная модель и подписочный тариф.

Почему одного bottom-up недостаточно. У OTT сильно плавающие расходы на инфраструктуру (CDN, кодировщик, хранилище), нагрузка на каждую платформу масштабируется по-разному, а работа с правами на контент сложно поддаётся оценке. Мы используем bottom-up для уровня приложений и параметрический метод (на CCU и на час) для инфраструктуры.

Инженерия bottom-up: ~190 человеко-недель на v1 по 5 платформам (web, iOS, Android, tvOS, Roku). С учётом накладных расходов и резерва на риски — около 260 человеко-недель. По типичной смешанной ставке это ~48–82 млн ₽ в зависимости от состава команды.

Инфраструктура (параметрический расчёт). CDN — 1,8 ₽/ГБ × ожидаемые 50 ТБ трафика в месяц = 93 тыс. ₽/месяц. Кластер транскодирования (100 часов нового контента в неделю) — около 112 тыс. ₽/месяц. Хранилище (10 тыс. часов × 1,5 ГБ/час) — около 22 тыс. ₽/месяц. DRM, аналитика, рекламный сервер — около 150 тыс. ₽/месяц. Итого по инфраструктуре: около 375 тыс. ₽/месяц на v1, далее масштабируется по трафику.

Права на контент (вне оценки). Лицензирование на каждый проект сильно отличается; CTO стоит закладывать ноль в инженерное предложение и выделять бюджет отдельно. Включение стоимости прав в инженерную оценку — красный флаг.

Коммуникация диапазона. Диапазон 48–82 млн ₽ соответствует 70%-ному доверительному интервалу. CTO представляет этот диапазон совету директоров вместе с чётким списком допущений, а не одним числом.

Скрытые расходы, о которых никто не пишет в смете

Discovery / фаза погружения (5–15 % от проекта). Полноценный архитектурный дизайн, прототип, план спринтов. Подрядчики, которые пропускают этот этап и сразу начинают писать код, потом вынуждены дорабатывать его через change-orders.

Накладные расходы на управление проектом (10–15 %). Планирование спринтов, ежедневные стендапы, ретроспективы, демо-дни, общение со стейкхолдерами. Типичное соотношение — один менеджер на четверых инженеров; более дешёвые подрядчики зачастую включают эти затраты в ставки инженеров.

Старший ревью кода + архитектурный надзор (8 %). Лид-инженер или архитектор выборочно проверяет PR, проверяет архитектурные решения, помогает младшим и средним инженерам. Постепенно снижает технический долг; редко выделяется отдельной строкой.

Аудиты на соответствие требованиям. Оценка рисков по HIPAA — от 375 тыс. до 1,1 млн ₽. Аудит SOC 2 Type 2 — от 1,5 до 4,5 млн ₽. Пентест — от 750 тыс. до 1,8 млн ₽ за цикл.

Мониторинг в продакшене и дежурства. Datadog или New Relic (от 37 тыс. до 375 тыс. ₽/месяц на старте). PagerDuty — 1 500 ₽ за пользователя. Дежурство старшего инженера (обычно раз в четыре недели).

Сторонние сервисы. Twilio, SendGrid, Stripe, Auth0, Algolia, векторное хранилище. На этапе оценки легко про них забыть; в сумме на v1 это 37–375 тыс. ₽ в месяц.

Поддержка и исправление багов после запуска. Закладывайте 15–25 % от исходного бюджета проекта на год для поддержания системы в рабочем состоянии.

Красные флаги в RFP — 7 признаков плохой оценки

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

2. В разбивке нет NFR. Если в разбивке перечислены функции, но не указаны требования к доступности, безопасности, производительности, масштабируемости и удобству для людей с ограниченными возможностями — подрядчик сочтёт их вне объёма работ, когда эти требования проявятся.

3. Часы, которые округлены до тысяч. «Портал пациента: 200 часов, портал врача: 150 часов». Реальные оценки снизу вверх дают странные цифры (87 часов, 142 часа), потому что складываются из отдельных задач.

4. Discovery не указан в коммерческом предложении. «Мы можем начать кодить со следующей недели» означает, что архитектурный дизайн не проводится. Перепроектирование в середине проекта обойдётся в 3–5 раз дороже, чем стоило бы discovery.

5. Подрядчик принял бриф без вопросов. Сильная команда обязательно уточнит расплывчатые требования, попросит детализировать NFR, предложит альтернативные архитектуры. Если подрядчик ответил: «конечно, сделаем ровно то, что вы написали» — у вас проблема.

6. Разброс предложений между подрядчиками больше 3 раз. Если оценки лежат в диапазоне от 6 млн до 22 млн ₽, бриф слишком расплывчатый. Перепишите его точнее и соберите новые оценки — не усредняйте старые.

7. Фикс. цена без процедуры change-orders. Реальные контракты с фиксированной ценой включают процесс change-orders — то, как оплачиваются изменения объёма работ. Без этого подрядчики будут молча выполнять ваши изменения, пока не достигнут лимита, а потом выкатят шестизначный счёт на 4-м месяце.

Как написать бриф, по которому дают точные оценки

Бриф из 12 разделов сокращает разброс оценок между подрядчиками с пятикратного до полутора. Вот эти разделы:

1. Контекст компании — кто вы, чем занимаетесь, текущий размер команды и стадия финансирования.

2. Проблема и пользователи — какую проблему вы решаете для пользователя, кто эти пользователи и как они с ней справляются сейчас.

3. Функциональный объём — пользовательские истории или эпики с критериями приёмки. Речь не о функциях, а о результатах.

4. Нефункциональные требования (NFR) — производительность (целевая задержка, пропускная способность), безопасность (аутентификация, шифрование, требования регулятора), масштабируемость (DAU, пиковая нагрузка), доступность (целевой SLA), доступность для людей с ограниченными возможностями (уровень WCAG).

5. Технологические предпочтения — либо конкретное указание, либо полное доверие подрядчику. Можно чётко прописать «Node + React + Postgres», если у вас есть позиция; написать «предложите подходящий стек» — тоже допустимо.

6. Сроки и ключевые точки — что является жёсткой датой (запуск, продление контракта), а что — пожеланием.

7. Бюджетные рамки — диапазон, фиксированная сумма, T&M. Говорите о лимитах честно: иначе подрядчики будут тратить и ваше, и своё время на догадки.

8. Критерии оценки — какие факторы влияют на ваше решение (цена, релевантность портфолио, техническая глубина, коммуникация, локация).

9. Условия по интеллектуальной собственности и данным — ваши ожидания относительно прав на код, хранения данных, привлечения субподрядчиков и депонирования исходного кода.

10. Требования к подаче предложения — формат, срок подачи, кто проверяет, сроки принятия решения.

11. Реестр рисков — это известные неизвестные, которые подрядчик должен оценить отдельно. Его наличие — признак зрелого заказчика; он помогает задать честные ожидания.

12. Ожидания по референсам и портфолио — какие предыдущие работы вы хотели бы увидеть.

5-шаговый процесс оценки в Фора Софт

Шаг 1: разбор брифа. Часовой созвон со старшим инженером и руководителем поставки. Подтверждаем объём, NFR и жёсткие ограничения. Подбираем аналоги из нашего портфолио — 625 проектов.

Шаг 2: top-down проверка на здравый смысл. 30 минут. Сравниваем с 2–3 похожими проектами. Получаем оценку-диапазон — это будет верхняя граница для дальнейшей bottom-up оценки.

Шаг 3: декомпозиция bottom-up. 1–3 дня. Разбиваем задачу на пользовательские истории или эпики, оцениваем каждую в стори-поинтах и пересчитываем в человеко-недели с учётом скорости команды. Старший инженер проводит ревью.

Шаг 4: реестр рисков и резервы. Выделяем конкретные риски (зависимости от сторонних систем, требования регуляторов, неясная производительность) и оцениваем каждый из них. Добавляем резерв в 10–20 % от общего объёма на случай непредвиденных проблем.

Шаг 5: независимое ревью старшего инженера. Другой старший инженер (не тот, кто оценивал) проверяет разбивку и задаёт вопрос «почему именно такое число?» по каждой строке. Обычно после этого шага оценка корректируется на 5–15 %.

Как выбрать метод оценки за 5 вопросов

В1. Контракт с фиксированной ценой или T&M? Фиксированная цена требует расчёта снизу вверх. T&M допускает расчёты сверху вниз или по методу PERT.

В2. Насколько объём зафиксирован? Жёстко зафиксирован → bottom-up. Существенные неизвестные → PERT с тремя точками. Объём открыт → сначала проведите discovery; оценивать открытый объём безответственно.

В3. Размер проекта? До 3,7 млн ₽: top-down подойдёт. 3,7–37 млн ₽: bottom-up. 37–375 млн ₽: bottom-up + PERT на неопределённых модулях. От 375 млн ₽: полный Монте-Карло.

В4. Делали ли вы (или подрядчик) подобные проекты раньше? Да → оценка по аналогам надёжна. Нет → ждите разброса в 30 % и закладывайте резервы соответствующим образом.

В5. Кто читает оценку? Команда инженеров → снизу вверх с детализацией по стори-поинтам. Совет директоров → оценка в диапазоне с доверительными интервалами и чётким списком допущений. Если оценивают и те, и другие — готовьте оба варианта.

Подводные камни

1. Оценка без архитектора. Старший архитектор замечает риски, которые не видны ни джуну, ни PM — сложности с интеграциями, неопределённость по производительности, особенности сторонних API. Любую оценку должен подписать архитектор.

2. Не различать «идеальную» и «реальную» продуктивность. «Идеальный день» старшего инженера — 5–6 часов настоящей работы после встреч, ревью кода и отладки. Всегда оставляйте запас: не рассчитывайте на 8 часов продуктивности в день.

3. Забывать про интеграционное тестирование. Юнит-тесты обычно оцениваются вместе с функциями. End-to-end тесты, интеграционные тесты, нагрузочные тесты часто упускают из виду — они в сумме составляют 10–15 % от общего объёма работ.

4. Недооценивать миграцию данных. Перенос исторических данных редко бывает «просто скрипт». Маппинг схем, качество данных, крайние случаи, репетиции, откаты — для любой нетривиальной системы это отдельный проект.

5. Игнорировать деплой и DevOps. CI/CD-пайплайны, инфраструктура как код, настройка мониторинга, усиление безопасности — всё это составляет 5–10 % от объёма проекта, но часто не учитывается при оценке.

Какие KPI измерять

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

Бизнес-цели. Конверсия в победу по оценённым проектам (цель: 30–45 % по тёплым лидам, ниже — по холодным). Фактическая маржа по сравнению с планом (цель: отклонение не более 5 % от модели). Среднее время от RFP до оценки (цель: до 7 дней для проектов на 15 млн ₽).

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

Когда не нужно формализовать оценку

Полноценный исследовательский R&D. Если непонятно, сработает ли выбранный технический подход, оценить его невозможно. Запустите спайк на 2 недели в фиксированный таймбокс, а потом уже оценивайте. Не притворяйтесь, что спайка не было.

Глубокая итеративная продуктовая разработка. На раннем этапе MVP следующий спринт зависит от обратной связи. Модель T&M с недельными чекпоинтами эффективнее фиксированной цены — та уже к третьей неделе оказывается ошибочной.

Тактика на бюджет до 750 тыс. ₽. Недельная функция не требует сложного процесса оценки. Оценка старшего инженера «на глаз» с запасом 30 % обычно проходит нормально.

FAQ

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

Готовы запустить проект, который попадёт в оценку?

28 % проектов выходят за рамки сметы, и причины очевидны: расплывчатые требования, излишний оптимизм, упущенные NFR, риски от сторонних зависимостей, «скидка от основателя». Избежать этого — не вопрос удачи, а вопрос правильного процесса. Bottom-up для фиксированной цены, top-down для презентаций клиентам, PERT при высокой неопределённости, Монте-Карло — для проектов корпоративного масштаба.

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