Я не считаю пилот успешным, пока не знаю, какой результат заставит меня остановиться

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

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

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

Почему заранее заданный отказ делает пилот сильнее

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

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

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

Пилот не обязан доказывать всё

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

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

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

Каждое из этих допущений можно проверить, не строя вокруг него весь будущий продукт. И каждое требует своего признака успеха. Если проверять всё одним показателем — например, количеством входов, — получится цифра без смысла. О том, почему клики сами по себе не доказывают ценность функции, я уже писал в материале «Я не считаю клики доказательством ценности новой функции».

Сначала — решение пользователя, потом интерфейс

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

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

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

Каким может быть честный критерий остановки

Критерий не должен быть театрально строгим. «Если каждый пользователь будет заходить каждый день» — плохая формулировка, если действие нужно раз в неделю. «Если все скажут, что им нравится» — тоже плохая: люди часто вежливы и не обязаны быть продуктовыми аналитиками.

Хороший критерий связан с реальной работой. Например:

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

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

Активность — ещё не доказательство

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

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

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

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

Пилот и бета-запуск — не одно и то же

Пилот проверяет право идеи жить дальше. Бета-запуск проверяет, как уже выбранное решение ведёт себя на более широком круге людей. Если эти этапы смешать, у команды появится слишком много объяснений для любого результата.

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

В бета-запуске уместно проверить нагрузку, права, исключения и понятность инструкций. Здесь важнее вопрос: можно ли повторить сценарий без личного участия автора идеи? А полный релиз начинается тогда, когда продукт готов не только показать ценность, но и нести ответственность за неё в обычном ритме.

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

Что я фиксирую до старта

Мне хватает короткой заметки на одну страницу. В ней пять пунктов.

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

Второй — пользователь и момент. Кто окажется в новом сценарии и в какой минуте рабочего дня. Это помогает не сделать пилот удобным только для того, кто его придумал.

Третий — одно предположение. Например: если менеджер увидит возврат заказа сразу, он успеет изменить обещание клиенту до следующего звонка.

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

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

Не прятать отказ в формулировке «пилот завершён»

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

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

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

Пилот нельзя поручить только команде разработки

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

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

Пример без героизма

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

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

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

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

Мой короткий вывод

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

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