По данным Standish Group, около двух третей IT-проектов выходят за сроки или бюджет. Цифра пугающая, но интереснее другое: почти всегда перерасход закладывается до того, как написана первая строка кода.
Разберём механику — не «7 причин провала», а то, как именно смета теряет связь с реальностью.
Перерасход рождается в момент оценки
Низкая стартовая цена — самая дорогая вещь в заказной разработке. Она почти всегда означает не эффективность исполнителя, а то, что он не увидел объём: забыл интеграции, роли, миграцию данных, отчёты.
Проект при этом не становится меньше. Невидимая работа всё равно выполняется — просто оплачивается она уже сверх сметы, через «доработки» и «дополнительные соглашения». Как отличить настоящую оценку от угаданной цифры, мы разобрали в статье про стоимость до старта.
«Заодно»: как объём растёт незаметно
Scope creep звучит наукообразно, но выглядит буднично: «раз уж делаем заявки, давайте заодно уведомления в Telegram», «а можно заодно личный кабинет для клиентов?».
Каждое «заодно» по отдельности стоит недорого. Проблема в том, что они не проходят через оценку: объём растёт, а смета и сроки остаются старыми — до момента, когда расхождение уже нельзя не заметить. Проекты с размытыми границами опаздывают не на проценты, а в разы.
Невидимая работа
Треть бюджета обычно уходит на то, чего нет ни в одной презентации:
- права доступа и роли;
- обработка ошибок и краевые случаи;
- импорт старых данных;
- отчёты «как в Excel, только автоматически»;
- уведомления, логи, резервные копии.
Если этих пунктов не было в требованиях, они не исчезают — они просто всплывают в середине проекта, когда отказаться уже нельзя.
Нет определения «готово»
Когда критерии приёмки не записаны, финал проекта превращается в переговоры. Заказчик ожидает «как я себе представлял», исполнитель сделал «как было написано». Каждый цикл таких правок — это время, а время в разработке и есть деньги.
Что зафиксировать до старта
Бюджет выдерживает тогда, когда до первой строки кода зафиксированы четыре вещи:
- Сценарии — что система делает, по ролям.
- Границы версии — что входит в неё, а что нет.
- Интеграции и данные — все внешние системы и источники.
- Критерии приёмки — как понять, что готово.
Собрать это можно без бизнес-аналитика — важно не мастерство формулировок, а сама фиксация.
Как с этим работает coob
В coob перерасход лечится структурой процесса: продуктовые требования собираются до старта, оценка фиксируется на версию целиком, а все идеи «заодно» не растворяются в смете — они копятся в бэклоге, оцениваются отдельно и осознанно попадают в следующую версию. Бюджет первой версии при этом остаётся тем, каким был в день старта.