Почему IT-проект выходит за бюджет
IT-проект, который уложился в первоначальную смету, сегодня скорее исключение, чем правило. Исследование McKinsey, охватившее 5 400 IT-проектов, показало, что крупные проекты в среднем выходят за бюджет на 45% и дают на 56% меньше ценности, чем обещали (McKinsey).
Больше всего меня пугают эти 56%. Продукт разрабатывают какое-то время, и за это время условия могут измениться, так что бизнесу он уже не приносит прибыли. Либо собственник думал, что определённые функции будут приносить прибыль, а оказалось, что нет.
Я управляю IT-проектами и за последний год увидела, как ИИ меняет эту картину.
1. Планируют по бумаге, а не по продукту
Первая причина перерасхода: смету считают по описанию продукта, а не по самому продукту. Схема знакома всем: несколько созвонов, ТЗ на двадцать страниц, схемы в Miro, оценка по тексту. Заказчик подписывает документ, который читает по диагонали, а результат впервые видит через недели, когда любая правка уже стоит денег.
Данные это подтверждают. По отчёту PMI главные причины провала проектов: смена приоритетов организации (39%), смена целей проекта (37%), неточные требования (35%) и плохая коммуникация (29%). Почти всё это про одно: стороны по-разному понимали, что именно строят. McKinsey назвали механизм прямо: стабильный и точный объём проекта не удавалось определить из-за редкого общения менеджеров с заинтересованными сторонами.
С ИИ планирование изменилось. Раньше для такого результата нередко проводили дизайн-спринт на две-три недели, а теперь прототип собирается за час. Я показываю его заказчику, мы вместе кликаем по экранам и сразу собираем обратную связь.
Главный эффект такой: неясности, которые раньше всплывали на третьей неделе разработки, всплывают на первой встрече, когда исправить их почти бесплатно. Сроки, риски и бюджет считаются по утверждённому прототипу, а не по пересказу, и оценка становится точнее.
У быстрого прототипа есть две ловушки. Первая: красивый ИИ-прототип выглядит готовым почти на 90%, и заказчик логично решает, что осталось совсем немного. Поэтому я сразу проговариваю: прототип отвечает на вопрос «что мы строим», но не на вопрос «как это будет работать, защищаться и масштабироваться». Вторая: когда версию сделать легко, хочется делать их десятки, и обсуждение ходит по кругу. Заранее договариваюсь, сколько кругов правок мы делаем и в какой момент фиксируем результат.
2. Многое упирается в человека, который ведёт проект
Вторая причина неудобнее разговоров о методологиях: на бюджет сильнее всего влияет человек, который отвечает за проект. По моим наблюдениям, два одинаковых проекта у разных менеджеров заканчиваются по-разному.
Данные это отчасти подтверждают. В исследовании PMI 2025 года (опрос 2 841 специалиста) проекты людей с высоким бизнес-чутьём чаще укладывались в бюджет (73% против 68%) и сроки (63% против 59%) и реже заканчивались провалом (8% против 11%). Разрыв небольшой. А по scope creep и по потерянному бюджету PMI значимой разницы между группами не нашёл. Вывод простой: сильный человек важен, но без правил изменений он бюджет не спасёт.
Лучше всего, по моему опыту, работает человек, который понимает четыре вещи:
1. бизнес-задачу: он может сказать заказчику, что конкретная функция не нужна для его цели, и объём сокращается до разработки, а не после;
2. как продукт будет зарабатывать: он расставляет приоритеты по деньгам, сначала делая то, что приносит заявки и выручку;
3. как внедрять ИИ в процессы: рутину вроде статусов, отчётов и черновиков планов он отдаёт ИИ, а своё время тратит на решения;
4. людей в команде: он понимает их, видит, кто в чём силён, и ставит каждого на своё место.
Это направление подтверждает и исследование Project Business in the Age of AI. Его респонденты оценили, что к 2030 году ИИ может взять на себя около половины традиционных задач управления проектами. Людям останутся оценка результатов ИИ, работа с заинтересованными сторонами, суждение и ответственность за решения.
Один человек не обязан закрывать всё. Но если эти четыре роли разорваны между людьми, которые друг друга не слышат, бюджет начинает «плыть» на стыках.
Что проверить до старта проекта:
Шесть вопросов, которые я бы задала любому IT-проекту до подписания договора:
1. Начните с прототипа, а не с ТЗ. Утвердите по кликабельному макету, что именно вы делаете, и только потом просите смету.
2. Назовите бизнес-цель в цифрах: сколько заявок, сколько сэкономленных часов, какая выручка. Каждая функция должна к ней вести.
3. Определите одного человека, который отвечает и за продукт, и за бюджет. Он должен понимать бизнес и говорить с командой на её языке.
4. Договоритесь о правилах изменений: новая функция либо увеличивает бюджет, либо заменяет другую. Без этого объём будет расти молча.
5. Заложите в смету отдельной строкой безопасность, тестирование и поддержку первого года.
6. Спросите у подрядчика, как проверяется код, написанный с помощью ИИ: кто его читает, какие проверки безопасности он проходит до релиза и кто отвечает за уязвимости после запуска.
Итог
IT-проект выходит за бюджет по двум основным причинам: решения принимают по бумаге, а не по продукту, и проект ведёт человек, который не видит бизнес целиком. ИИ помогает с первым, потому что прототип за час делает требования видимыми. Но он не заменяет сильного человека во главе проекта.