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

На хакатоне команда показала, что сценарий можно собрать. Пилот проверяет, полезен ли он в реальной работе и что требуется для его применения. Между этими этапами лежат доступ к процессу, подготовка продукта, договорённости с участниками и способ оценить результат.
Не начинайте с обещания внедрить весь проект. Выберите небольшой участок работы, для которого можно получить наблюдения и безопасно вернуться к прежнему порядку. Решение о более широком запуске принимают после проверки, а не в наградной речи.
Сформулируйте проверяемое предположение
Опишите, кто выполняет действие, какую проблему испытывает и какое изменение вы ожидаете увидеть. Например: координатор обрабатывает типовые заявки, а прототип должен уменьшить повторный ручной перенос сведений. Это учебная гипотеза, не заявленный результат продукта.
Укажите, что может её опровергнуть. Возможно, основной объём времени уходит на уточнение данных, а не на их перенос. Тогда автоматизация выбранного шага не решает главную проблему, даже если интерфейс работает быстро.
Отдельно запишите вопросы, на которые пилот не ответит. Небольшая проверка с одной командой не подтверждает пригодность для всех подразделений и не доказывает готовность к большой нагрузке. Граница вывода должна быть понятна до сбора результатов.
Собрать договорённости по пилоту можно в шаблоне ТЗ для партнёра Stavleak: замените поля на процесс, ожидаемый результат и условия приёмки вашего эксперимента.
Найдите владельца процесса
Нужен человек, который знает текущую работу, может согласовать участие сотрудников и примет результат проверки. Контакт со спонсором хакатона не всегда означает доступ к рабочему процессу организации. Подтвердите полномочия и договорённости напрямую.
Согласуйте место проверки, участников, длительность, поддержку и ограничения данных. Назначьте владельца со стороны команды разработчиков. У обоих должна быть возможность остановить эксперимент по заранее понятной причине.
В руководстве GOV.UK о beta-фазе ограниченный запуск с реальными пользователями рассматривается как способ учиться и улучшать сервис перед расширением. Для хакатонного проекта это полезный принцип, но не готовая процедура допуска в чужую организацию.


