Пилот с согласованными обязательствами

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

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

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

Сначала сформулируйте решение после пилота

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

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

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

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

Отделите пользу клиенту от собственного обучения

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

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

Если вы пока можете показать только макет и посмотреть реакцию, честнее назвать работу проверкой прототипа. Прототип помогает исследовать решение до полноценного запуска; он не становится готовым сервисом из-за того, что заказчик увидел экран. Именно такое различие проводит руководство GDS по прототипированию.

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

Опишите вклад обеих сторон

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

Для Лены договорённость может выглядеть так:

Что нужно	Кто отвечает	Когда это нужно
Обезличенные примеры обращений	Руководитель подразделения	До настройки
Настройка списка и проверка полей	Лена	До начала работы сотрудников
Внесение новых обращений	Два назначенных сотрудника	В течение пилота
Разбор затруднений	Лена и руководитель	В согласованные дни
Решение о продолжении	Руководитель компании	После итогового разбора

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

Договоритесь о проверке результата до начала работы

Фраза «станет удобнее» оставляет слишком много пространства для разных оценок. Попросите клиента показать исходную ситуацию. Где сейчас хранятся заявки? Какие сведения теряются? Как руководитель обнаруживает проблему? Есть ли сопоставимые данные за предыдущий период?

Если надёжной исходной статистики нет, так и запишите. Можно оценить работоспособность нового процесса, но не стоит изображать точное снижение потерь относительно неизвестной базы.

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

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

Обсудите цену без обещания будущего контракта

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

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

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

Завершите пилот решением

Итоговая встреча нужна не только для демонстрации работы. Сопоставьте ожидания с наблюдениями. Что заработало? Где потребовалась ваша постоянная помощь? Какие условия не удалось проверить? Что изменилось у клиента за это время?

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

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

Что подготовить перед первым пилотом

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

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