Когда пилот не доходит до продакшена, разбор почти всегда показывает одно и то же: технически всё работало. Не было человека, который принимает решение о качестве, и человека, которому запуск улучшает собственные показатели. Команда из трёх инженеров без этих двух ролей делает интересный прототип и останавливается.
Минимальный состав
- Владелец процесса со стороны бизнеса. Отвечает за то, что задача нужна, и за то, что после запуска регламент изменится.
- Эксперт предметной области. Размечает эталонные ответы и решает спорные случаи. Это не разовая работа, а несколько часов в неделю.
- Инженер по ИИ-решению. Поиск, промпты, инструменты, оценка качества.
- Разработчик интеграций. Данные, доступы, встраивание в рабочую систему.
- Аналитик или продакт. Держит метрики и переводит их на язык бизнеса.
В небольшом проекте роли совмещаются: один человек может закрывать инженерию и интеграции. Не совмещается только одно — эксперт и разработчик не могут быть одним лицом, иначе оценка качества превращается в самопроверку.
Три роли, о которых забывают
Первая — владелец данных. Кто-то должен иметь право сказать «эта версия регламента актуальна, а эти три удалить». Без него команда месяцами спорит о том, почему система отвечает по старым документам.
Вторая — ответственный за качество. Не тестировщик интерфейса, а человек, который держит набор эталонных вопросов и прогоняет его перед каждым изменением. Без этого набора любое улучшение промпта — это лотерея: что-то стало лучше, что-то тихо сломалось.
Третья — безопасность и юристы, подключённые на старте, а не за неделю до запуска. Вопросы о том, где лежат данные и что логируется, решаются проектированием. Задним числом они решаются переносом сроков.
Если эксперт не выделил время на разметку, значит, задача не приоритетная. Это самый честный тест на нужность проекта.
Как работать: ритм важнее методологии
Рабочий ритм для пилота — недельные итерации с одним правилом: каждую неделю показывается результат на реальных данных, а не слайд о проделанной работе. На демо присутствуют владелец процесса и эксперт. Раз в две недели прогоняется полный набор эталонных вопросов, и его результаты фиксируются в таблице, где видно динамику.
Передача в эксплуатацию
Продакшен начинается не с деплоя, а с ответов на три вопроса: кто чинит, если система отвечает неправильно; кто обновляет базу знаний; кто решает, что модель пора менять. Пока эти имена не названы, проект остаётся пилотом, даже если он работает на боевых пользователях.