Внедрение по шагам: что сделать, кто отвечает, что на выходе

Работающий проект отличается от затянувшегося наличием артефактов: на каждом этапе появляется документ, который можно проверить и на основании которого принимается решение. Первый артефакт — описание процесса с объёмами и стоимостью единицы работы. Второй — отчёт о готовности данных с оценкой стоимости подготовки. Третий — бизнес-кейс с расчётом эффекта и критериями остановки. Четвёртый — отчёт по PoC с метриками на отложенной выборке. Пятый — итоги пилота с фактическим эффектом против контрольной группы. Шестой — регламенты эксплуатации: мониторинг, разбор спорных случаев, периодичность переобучения.

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

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

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

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

Есть ситуации, в которых правильный ответ — не начинать. Первая: процесс не описан и не измеряется, никто не может сказать, сколько операций в месяц и сколько времени они занимают. Автоматизировать неизвестно что невозможно, а попытка обычно заканчивается проектом, который никому не нужен.

Вторая: задача решается простым правилом. Если логика сводится к «если сумма больше миллиона — отправить на согласование», модель здесь не нужна, нужна пара строк кода. Мы регулярно предлагаем такие решения вместо AI-проекта, и это экономит клиентам значительные суммы.

Третья: данных недостаточно и получить их нельзя ни в обозримом будущем, ни за разумные деньги. Бывает, что нужная история просто не ведётся; тогда честный план — сначала начать собирать данные, а проект отложить. Четвёртая: нет бизнес-владельца и никто не готов менять регламенты. В этом случае техническая часть будет выполнена, а эффект не возникнет, потому что система останется неиспользуемой.