Почему стоимость AI- и IT-проекта постоянно растёт
Как разделить неизвестный объём, изменение требований, дефекты, интеграции, эксплуатацию и технический долг, чтобы вернуть управляемый прогноз.
Коротко: Рост оценки становится неуправляемым, когда новая функция, уточнение исходного объёма, исправление дефекта и снятие технической неизвестной считаются одинаково. Нужны baseline, журнал решений и прогноз остатка по классам работ.
Как проверить новую смету, если часть бюджета уже потрачена
Учебный пример: лимит проекта 600 000 ₽, потрачено 240 000 ₽, оценка оставшейся согласованной работы — 420 000 ₽. Новая интеграция предложена ещё за 180 000 ₽. Это три разные величины, а не один «остаток».
Пересчитайте прогноз до завершения
Без новой интеграции прогноз равен 240 000 + 420 000 = 660 000 ₽: превышение исходного лимита уже составляет 60 000 ₽. С интеграцией прогноз станет 840 000 ₽. Попросите показать, какие работы входят в 420 000 ₽, где изменились трудоёмкость или допущения и какие результаты будут приняты. Уже оплаченная сумма сама по себе не делает дальнейшие расходы обоснованными.
Сопоставьте три варианта объёма
Первый — завершить исходный сценарий. Второй — исключить менее ценные функции, сохранив работоспособный маршрут. Третий — добавить интеграцию отдельным этапом. Для каждого нужны результат, зависимости, критерий приёмки и эксплуатационные расходы. Сокращение контроля прав или мониторинга нельзя незаметно выдавать за экономию объёма: это изменение условий запуска.
Зафиксируйте, что изменилось после решения
У новой оценки должны быть версия, дата, автор и перечень допущений. Отдельно отметьте подтверждённый объём, резерв на известные риски и пока неоценённые зависимости. Не складывайте широкий диапазон неизвестности с точной суммой так, будто это согласованная цена. Распределение оплаты исправлений устанавливается по условиям проекта, а не по одному факту роста сметы.
Карточка изменения DEMO-CHANGE-03
Учебный образец. Перенесите структуру в рабочий документ и замените исходные условия своими.
- Исходный прогноз
- 240 000 ₽ факт + 420 000 ₽ остаток = 660 000 ₽.
- Предложение
- Новая интеграция +180 000 ₽; прогноз с изменением 840 000 ₽.
- Нужно объяснить отдельно
- 60 000 ₽ превышения исходного объёма и ценность новой интеграции.
- Решение владельца
- Сначала подтвердить остаток и критерии исходного этапа; новую интеграцию рассмотреть отдельным решением.
Определение
Управляемая оценка проекта — диапазон стоимости и срока с явными допущениями, неизвестными, составом результата и правилом изменения baseline.
Когда это важно
- Каждый этап открывает новый обязательный слой работ.
- Нельзя объяснить, какая часть доплаты связана с изменением объёма.
- Эксплуатация и поддержка впервые появляются после пилота.
Как принять решение
| Ситуация | Что проверяем | Решение |
|---|---|---|
| Новое требование | Было ли оно в baseline и критериях | Отдельное изменение объёма |
| Результат не проходит критерий | Воспроизводимый дефект и принятый стандарт | Исправление исходного объёма |
| Снята неизвестная | Была ли она зафиксирована и как влияет на архитектуру | Обновить диапазон и сценарий |
Реестр изменения стоимости AI-проекта
| Причина изменения | Что подтвердить | Кто несёт стоимость | Решение |
|---|---|---|---|
| Новый источник данных | Почему его не было в исходной архитектуре | Заказчик — если это новый утверждённый объём | Оценить отдельно и изменить baseline |
| Качество данных хуже ожиданий | Профиль данных и критерии, доступные до старта | По договору и распределению диагностического риска | Очистка, ограничение или остановка |
| Модель не держит порог | Версия, выборка, классы ошибок и повторяемость | Не считать автоматически новым функционалом | Смена подхода внутри этапа или stop |
| Интеграция оказалась недоступна | API, права и переписка с владельцем системы | По тому, кто отвечал за проверку зависимости | Альтернатива, перенос или исключение |
| Production-требования появились после демо | SLA, RBAC, мониторинг, backup и поддержка | Отдельный промышленный этап | Не выдавать пилот за готовую систему |
До согласования change request нельзя одновременно считать прежнюю цену действующей, а новый объём — уже обязательным.
Порядок работы
- Восстановить baseline. Собрать исходный объём, допущения и подтверждённые изменения.
- Разделить остаток. Классифицировать функции, дефекты, долг, интеграции и эксплуатацию.
- Снять критичные неизвестные. Провести ограниченные технические проверки.
- Сравнить сценарии. Продолжить, сократить, передать или остановить с последствиями.
Типичные ошибки
- Требовать одну точную цифру при неизвестной архитектуре.
- Оплачивать исследования как готовую функцию без результата этапа.
- Не учитывать поддержку, мониторинг и стоимость модели.
Практические рекомендации
- Ведите журнал изменения baseline.
- Оплачивайте снятие неизвестной как отдельный проверяемый результат.
- Показывайте диапазон и факторы риска.
Вывод: Стоимость возвращается под контроль не фиксацией случайной суммы, а прозрачным разделением объёма, качества, неизвестных и решений владельца.
Частые вопросы
Можно определить окончательную стоимость?
После снятия критичных неизвестных — с разумным диапазоном и правилами изменения.
Кто отвечает за рост?
Технический аудит фиксирует факты; договорную ответственность определяют стороны и юристы.
Когда проект лучше остановить?
Когда ожидаемая ценность не покрывает остаток, риск и эксплуатацию либо результат нельзя безопасно принять.