Невозвратные затраты не оправдывают продолжение ИТ-проекта: сравнивать нужно будущие расходы и выгоду

Невозвратные затраты уже понесены, и выбранный сейчас путь их не изменит. Если подрядчику заплатили за сделанную работу и вернуть платёж нельзя, он останется в истории проекта при любом решении.

Ловушка начинается со слов «слишком много вложили, чтобы бросить». Руководитель обосновывает новый расход старым платежом, хотя новый месяц должен дать собственный результат.

Именно эту границу проводит Green Book 2026, методика оценки проектов HM Treasury. Из сравнения будущих вариантов исключают прошлые неизменяемые затраты, но учитывают другое применение уже оплаченных ресурсов.

Готовый код поэтому имеет значение. Если на нём можно довести нужный сервис дешевле, чем собрать заново, это будущая выгода сохранившегося результата. Сам чек за его разработку выгоду не создаёт.

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

ACCA предлагает проверять, какие будущие денежные потоки изменит решение. Платёж, одинаковый при всех вариантах, не помогает выбрать вариант, но деньги на него всё равно понадобятся.

Сотрудник, освобождённый от ручного отчёта, не превращается автоматически в экономию зарплаты. Денежная выгода появится, если исчезнет оплачиваемая работа или сотрудник сделает другую работу с измеримым результатом.

Технический долг учтите как будущую стоимость исправлений. Здесь нужен ответ, сколько исправления добавят к выбранному пути.

В учебном примере на внутренний сервис отчётности потратили 2 млн ₽, а сотрудники им ещё не пользуются. Вернуть прошлую оплату нельзя. Сейчас собственник выбирает, что делать в следующие шесть месяцев.

Продолжение потребует 250 000 ₽ на разработку и 50 000 ₽ дополнительных расходов на внедрение. Работа системы стоит 20 000 ₽ в месяц. За шесть месяцев будущие расходы составят 420 000 ₽.

После внедрения со второго месяца сервис должен заменить оплачиваемую ручную работу на 100–160 тысяч ₽ в месяц. За пять месяцев это 500–800 тысяч ₽ предполагаемой экономии, которую ещё нужно подтвердить.

Продолжение выигрывает у закрытия, если будущая выгода превысит 380 000 ₽ за этот горизонт. Это разница будущих расходов двух вариантов. Прошлые 2 млн ₽ из решения исчезают.

Если реальная экономия окажется 50 000 ₽ в месяц, за пять месяцев получится 250 000 ₽. Продолжение даст минус 170 000 ₽ и проиграет закрытию на 130 000 ₽.

Пауза в таком случае покупает время на проверку ценой содержания системы. Она имеет смысл, когда во время паузы появится новое доказательство пользы. Сама по себе задержка платежа этого доказательства не создаёт.

ИИ-агент может уменьшить объём ручной разработки. Это повод получить новую оценку оставшейся работы, а не довод в пользу проекта без покупателей или пользователей.

Если внедрение ИИ не ускорило выпуск, сначала найдите, где стоит задача. Ещё один оплаченный месяц без изменения причины задержки повторит прежнюю попытку.

На подписке на агентную разработку тариф «Один проект» стоит 250 000 ₽ в месяц на 7 октября 2026. Первый месяц служит пилотом по обычной цене. Его стоит покупать под результат, который поможет решить, платить ли дальше.

Пауза подписки замораживает её и переносит оплаченные дни. Она позволяет остановить новый расход на разработку, но не отменяет расходы самого продукта и не возвращает прежние вложения в проект.

Наш пример относится к машине vibecoding.ru, которую ведёт инженер. В ней уже обработанный материал отбрасывают, если он не прошёл отбор. Расход на подготовку не обязывает выпускать результат.

На живом /open за всю историю склада по 6 октября 2026 включительно учтены 52 104 найденных материалов и 6 844 поданные истории. Страница показывает 87 % в корзину на 7 октября 2026. Это отбор контента, не доля закрытых ИТ-проектов.

Ремонт нашей машины тоже начинается с того, что изменит следующий шаг. Лента ниже показывает, как уже сделанную настройку пересматривали после наблюдения, вместо того чтобы продолжать по привычке.

Решение о продолжении запишите до нового платежа. В записи нужны будущая польза, предел новых расходов и результат, после которого вы выберете следующий шаг.

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

Проверка может закончиться отказом от разработки. Если пользователи не переходят на сервис или денежная выгода ниже выбранного порога, результат пилота уже получен. Повторять его стоит после нового основания, например подтверждённой задачи пользователей.

Постановку задачи и критерий «готово» мы разбираем отдельно.

1. Прошлый невозвратный платёж вынесите из сравнения будущих вариантов.

2. Продолжение, паузу и закрытие посчитайте на одном горизонте с расходами внедрения и эксплуатации.

3. Готовый код учитывайте по будущему применению. Потраченную на него сумму не считайте будущей выгодой.

4. Следующий месяц оплачивайте под проверяемый результат. Заранее запишите, какое наблюдение остановит новые расходы.

5. При паузе назначьте проверку и условие возврата. Без них проект продолжит расходовать деньги на ожидание.