Waterfall больше не работает: как планировать бюджет ИТ-проектов итерациями и сэкономить 15–20%
Классическая схема финансирования ИТ-проекта выглядит так: бизнес формулирует требования, ИТ оценивает объём работ, финансовая служба утверждает бюджет на весь проект, и дальше команда год-полтора реализует то, что было записано в техническом задании. В конце выясняется, что половина функций не нужна, а того, что действительно важно, в задании не было.
Деньги при этом уже потрачены. И именно здесь кроется главная проблема каскадного бюджетирования ИТ-проектов: оно заставляет платить за решения, принятые в момент, когда о продукте было известно меньше всего.
Итеративный подход предлагает другую логику. Бюджет выделяется порциями, каждая итерация даёт работающий результат, и после каждой можно решить, стоит ли продолжать, менять направление или остановиться. В статье разберём, как совместить гибкое управление проектами с корпоративным бюджетным циклом и за счёт чего компании экономят на итеративном бюджетировании.
Содержание
- Почему каскадный бюджет плохо работает в ИТ
- Итеративный подход: что меняется для бюджета
- Как сформировать бюджет ИТ-проекта итерациями
- Как совместить итерации с годовым бюджетным циклом
- Откуда берётся экономия
- Как контролировать бюджет итеративного проекта
- Когда итеративное бюджетирование не подходит
- Частые вопросы
- Итог. Платить за результат, а не за план
Почему каскадный бюджет плохо работает в ИТ
Каскадная модель исходит из того, что требования можно полностью описать в начале проекта, а затем реализовать. В строительстве или производстве это часто справедливо. В ИТ — почти никогда.
Причин несколько:
- Бизнес не всегда знает, что ему нужно, пока не увидит работающий прототип. Фраза «сделайте как у конкурентов» не является требованием.
- Условия меняются быстрее, чем длится проект. За год меняются процессы, регуляторные требования, приоритеты руководства.
- Оценка сложных ИТ-работ на старте имеет большую погрешность. Чем дальше работа от начала проекта, тем менее точна её оценка.
- Ценность выявляется по ходу. Часть функций, которые казались ключевыми, оказываются невостребованными у пользователей.
В итоге каскадный бюджет ИТ-проекта либо постоянно пересматривается через тяжёлые процедуры изменений, либо фиксирует компанию на устаревших решениях. И в том, и в другом случае деньги тратятся неэффективно.
Итеративный подход: что меняется для бюджета
Итеративный подход в Agile строится на коротких циклах: команда за несколько недель создаёт работающий фрагмент продукта, показывает его заказчику, получает обратную связь и планирует следующий цикл.
Для бюджета это означает несколько принципиальных изменений.
| Каскадный подход | Итеративный подход |
| Бюджет утверждается на весь проект сразу | Бюджет выделяется на этапы или период работы команды |
| Фиксируется содержание, сроки и стоимость | Фиксируются сроки и стоимость, гибким остаётся содержание |
| Изменения требований — повод для пересогласования бюджета | Изменения требований — нормальная часть работы внутри бюджета |
| Результат виден в конце проекта | Результат виден после каждой итерации |
| Решение об остановке проекта принимается редко и болезненно | Решение о продолжении принимается регулярно |
Ключевой сдвиг — от вопроса «сколько стоит сделать всё, что написано в ТЗ» к вопросу «сколько мы готовы вложить, чтобы получить определённый бизнес-результат, и как будем проверять, что движемся к нему».
Как сформировать бюджет ИТ-проекта итерациями
1. Начните с цели, а не со списка функций
Вместо технического задания на сотни страниц сформулируйте, какой бизнес-результат должен дать проект. Например, сократить время обработки заявки клиента с трёх дней до одного. Это цель, по которой потом можно оценивать каждую итерацию.
2. Оцените стоимость команды, а не объёма работ
В итеративной модели основной расход — это работа команды. Если команда из семи человек стоит определённую сумму в месяц, то стоимость любого периода работы считается просто: число месяцев на стоимость команды плюс сопутствующие расходы на инфраструктуру и лицензии.
Это гораздо точнее, чем попытка оценить в человеко-часах сотни функций, половина из которых изменится.
3. Определите горизонт первого финансирования
Не просите деньги на весь проект. Попросите на первый этап, по итогам которого будет понятно, верна ли гипотеза. Обычно это три-шесть месяцев работы команды и первый работающий результат, который можно показать пользователям.
4. Сформируйте приоритизированный бэклог
Список доработок ранжируется по ценности для бизнеса. Команда всегда работает над самым ценным из оставшегося. Это главный механизм, который позволяет уложиться в бюджет: если деньги заканчиваются, не сделанными остаются наименее важные функции, а не случайные.
5. Заложите точки принятия решений
Каждые несколько итераций, например раз в квартал, проводится обзор с заказчиком и финансовой службой. На нём смотрят, что сделано, какой эффект получен и что команда планирует дальше. По итогам принимается решение о финансировании следующего периода.
Как совместить итерации с годовым бюджетным циклом
Главное возражение финансовой службы звучит так: «У нас годовой бюджет, мы не можем каждый квартал заново согласовывать деньги». Это возражение снимается, если правильно выстроить модель.
Вариант, который хорошо работает в большинстве компаний:
- На год утверждается лимит финансирования направления или продукта, например под две команды разработки.
- Внутри лимита деньги выделяются поквартально по итогам обзора результатов.
- Если направление не показывает результата, финансирование следующего квартала может быть сокращено или перераспределено на другое направление в рамках ИТ-портфеля.
- Неиспользованный лимит возвращается в общий резерв ИТ-портфеля, а не «осваивается» в конце года.
Для финансовой службы такая модель даже удобнее каскадной. Годовой лимит известен заранее, а контроль за расходованием денег становится регулярным, а не происходит раз в год при сдаче проекта.
Откуда берётся экономия
Цифра в 15–20% не появляется из-за того, что команда работает быстрее. Экономия возникает из нескольких источников, и важно понимать каждый из них.
Не сделанное ненужное. Это главный источник. При каскадном подходе компания платит за все функции из технического задания. При итеративном — команда в первую очередь реализует самое ценное, и в какой-то момент заказчик видит, что оставшиеся пункты бэклога не стоят затрат на них.
Возьмём условный пример. В техническом задании 100 функций, оценка проекта — 50 млн. После первых итераций и обратной связи от пользователей выясняется, что 15 функций уже не нужны, а ещё 10 можно заменить настройкой существующей системы. Если отказаться от них, проект обойдётся примерно в 40 млн при том же или лучшем бизнес-результате.
Ранняя остановка неудачных проектов. Если гипотеза не подтвердилась, итеративный проект останавливают после первого этапа, а не после того, как потрачен весь бюджет.
Меньше переделок. Ошибки в понимании требований обнаруживаются через несколько недель, а не через год. Исправить их на ранней стадии значительно дешевле.
Раннее получение эффекта. Первые полезные функции начинают работать через несколько месяцев, а не в конце проекта. Это не сокращает затраты напрямую, но приближает окупаемость.
Конкретная величина экономии зависит от проекта, качества исходных требований и дисциплины приоритизации. Но сам механизм работает одинаково: компания перестаёт платить за то, что ей на самом деле не нужно.
Как контролировать бюджет итеративного проекта
Итеративный подход не означает отсутствия контроля. Наоборот, контроль становится чаще и предметнее. Для проектного офиса и финансовой службы полезны следующие показатели:
| Показатель | Что показывает |
| Стоимость итерации | Сколько стоит один цикл работы команды, насколько стабильны расходы |
| Плановый и фактический расход по периоду | Укладывается ли направление в выделенный лимит |
| Доля выполненных приоритетных задач | Работает ли команда над самым ценным |
| Динамика бизнес-показателя | Двигается ли проект к цели, ради которой он запущен |
| Прогноз до достижения цели | Сколько ещё итераций и денег нужно при текущем темпе |
Важно, чтобы итеративные ИТ-проекты были видны в общем портфеле компании наравне с остальными. Если ИТ живёт по своим правилам и в своём инструменте, а остальные проекты — в другом, руководство теряет общую картину расходов и не может сравнивать проекты между собой.
Когда итеративное бюджетирование не подходит
Итеративный подход — не универсальное решение. Есть ситуации, где каскадный бюджет оправдан:
- Внедрение типового решения с хорошо понятным объёмом работ, например тиражирование уже настроенной системы на новые подразделения.
- Проекты с жёсткими регуляторными требованиями, где содержание определено законом и не может меняться.
- Договоры с внешними подрядчиками, где заказчик обязан зафиксировать стоимость работ, например по правилам закупок.
Но даже в этих случаях можно использовать элементы итеративности: разбивать проект на этапы с промежуточной приёмкой и принимать решение о следующем этапе по итогам предыдущего.
Частые вопросы
Итог. Платить за результат, а не за план
Итеративное бюджетирование ИТ-проектов — это не отказ от планирования, а смена того, что именно планируется. Вместо попытки заранее купить весь объём работ компания регулярно решает, стоит ли вкладывать в проект дальше, исходя из полученных результатов. Экономия появляется потому, что деньги перестают уходить на функции, которые оказались не нужны, и на проекты, которые не подтвердили свою ценность.
Для такого подхода важно, чтобы гибкие ИТ-проекты и классические проекты компании управлялись в одном контуре. Система управления проектами ADVANTA поддерживает разные методологии в едином портфеле: ИТ-команды могут работать итерациями и по канбан-доскам, а руководство и финансовая служба видят бюджеты, расход и прогноз по всем проектам в общих дашбордах. Это позволяет проектному офису применять итеративное бюджетирование там, где оно даёт эффект, не теряя управляемости портфеля в целом.
