Пилот после хакатона: как проверить проект в реальном процессе

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

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

Сформулируйте проверяемое предположение

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

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

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

Собрать договорённости по пилоту можно в шаблоне ТЗ для партнёра Stavleak: замените поля на процесс, ожидаемый результат и условия приёмки вашего эксперимента.

Найдите владельца процесса

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

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

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

Опишите исходное состояние

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

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

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

Подготовьте продукт к ограниченной работе

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

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

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

Заранее определите условия завершения

В коротком плане пилота зафиксируйте:

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

Отделите результат от следующего обещания

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

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