Когда я считаю правильным остановить цифровой проект

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

Я предпочитаю возвращаться к вопросу о будущем: какая польза ожидается от следующего этапа и сколько ещё потребуется ресурсов? Уже выполненная работа важна как источник результата и опыта, но сама по себе не объясняет необходимость продолжения.

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

Разделяю трудность и потерю смысла

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

Другая ситуация — когда изменился сам процесс. Например, компания перестала выполнять операцию, ради которой создавался инструмент. Или выяснилось, что нужные данные принципиально недоступны в допустимых условиях.

Поэтому я стараюсь определить, что именно поставлено под сомнение: конкретная реализация, выбранный способ решения или исходная задача. От ответа зависит следующий шаг. Иногда достаточно заменить компонент, а иногда следует завершить весь проект.

Возвращаюсь к критерию результата

Если критерий записан до начала работ, разговор становится предметнее. Можно сравнить ожидание с наблюдением: качество, время, доля ручной проверки, стоимость сопровождения.

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

Это не доказывает, что любой такой помощник бесполезен. Но исходная гипотеза об экономии в данном процессе пока не подтвердилась. Для продолжения нужна новая проверяемая гипотеза, а не обещание, что «после ещё нескольких доработок точно станет лучше».

Мне важно назвать, какое изменение должно дать эффект и как мы его проверим.

Ограничиваю следующий эксперимент

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

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

Я задаю себе вопрос: что мы узнаем после этого этапа, чего не знаем сейчас? Если ответ сводится к «станет чуть лучше», постановка ещё слишком расплывчата.

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

Использую несколько вариантов завершения

Остановка не всегда означает удалить систему и забыть о задаче. Возможны разные решения:

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

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

Сохраняю то, что уже полезно

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

Эти результаты нужно передать в понятном виде. Что можно использовать повторно? Какие доступы следует отозвать? Где остаются данные? Есть ли незавершённые действия или обязательства перед пользователями?

Здесь полезен короткий акт завершения со списком артефактов, ответственными и состоянием системы. Он помогает не оставлять работающий в фоне эксперимент без владельца.

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

Как я формулирую решение

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

Такая формулировка позволяет обсуждать факты без поиска виноватого. Команда может качественно выполнить пилот, который показал невыгодность большого внедрения.

Для собственника полезен именно этот результат: не продолжать проект автоматически, а осознанно распределить будущие ресурсы. Иногда правильное завершение цифровой работы — работающая система. Иногда — вовремя принятое решение заняться другой задачей.