Как перевести IT-продукт из пилота в ежедневную работу

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

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

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

У пилота и рабочего дня разные правила

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

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

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

Первый признак проблемы — пилот живёт отдельно от результата

Представьте согласование коммерческого предложения. В пилоте менеджер заносит его в новую систему, руководитель нажимает «одобрить», а статус красиво меняется. Но в реальной жизни предложение начинается с запроса клиента, может несколько раз меняться, требует расчёта, а после согласования должно попасть в договор и план продаж.

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

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

Не расширяйте пилот, пока не назначен хозяин процесса

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

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

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

Проверьте не интерфейс, а момент выбора

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

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

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

Покажите пользователю, что изменится лично для него

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

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

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

Не превращайте первые замечания в голосование

Когда продукт выходит из пилота, обратной связи становится много. Один просит добавить поле, другой — убрать, третий предлагает вернуться к таблице. Было бы ошибкой либо выполнять всё подряд, либо закрываться от замечаний фразой «так предусмотрено».

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

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

Когда пилот действительно можно считать завершённым

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

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

Коротко: что сделать на следующей неделе

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

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

Сделайте первый рабочий контур маленьким

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

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

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

Измеряйте не активность, а исчезнувшую ручную работу

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

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

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

Договоритесь о поддержке до первого сбоя

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

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

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

Вопросы перед переходом от пилота к работе

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

1. Какой законченный рабочий результат теперь должен проходить через продукт?
2. Кто отвечает за правила процесса и спорные случаи?
3. Какие два исключения встречаются чаще всего и как их обработать?
4. По каким признакам через две недели мы поймём, что ручной обходной путь уменьшается?
5. Куда пользователю идти с проблемой и кто принимает решение о следующем улучшении?

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

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