Ручной прототип клиентского результата

Кому подойдёт: новичкам и специалистам в найме, которые думают о продукте, а также фрилансерам, которые хотят превратить повторяющуюся услугу в сервис. Категории Start и System.

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

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

Выберите один результат для одного сценария

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

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

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

Честно опишите процесс работы

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

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

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

Разделите путь клиента и вашу внутреннюю работу

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

Клиент

Выгрузить данные, передать файл, получить отчёт, выбрать, что проверить в закупках.

Исполнитель

Проверить формат, сопоставить названия, найти пропуски, рассчитать показатели, подготовить комментарии.

Два часа клиента на подготовку файла каждую неделю и вечер исполнителя на названия — разные проблемы. 35 минут, два дня ожидания доступа и 20 минут разговора — примеры записей, не норматив.

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

После каждого шага фиксируйте затраченное время и затруднения. Нужны не идеальные секундомеры, а достаточно честные записи: «35 минут искал соответствия», «клиент два дня ждал доступа», «20 минут обсуждали значение столбца». Такие подробности подскажут, что действительно стоит автоматизировать.

Посчитайте стоимость ручного результата

Предположим, в учебном пилоте один отчёт продаётся за 6 000 ₽. На него уходит четыре часа. Для управленческого расчёта вы оцениваете свой час в 1 000 ₽, а прямые расходы составляют 500 ₽. После этих двух статей остаётся 1 500 ₽. Это ещё не чистая прибыль: отдельно существуют привлечение клиентов, общие расходы и применимые налоги.

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

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

Выберите наблюдаемые действия

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

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

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