Какую гипотезу проверяет MVP
Допустим, мы делаем сервис для ремонтных компаний. Заявки приходят в мессенджеры, диспетчер назначает мастеров в таблице, клиенты звонят узнать статус. В бэклоге уже кабинет, мобильное приложение и дашборд. Начать разработку можно хоть завтра. Но пока непонятно, какую проблему должен решить первый релиз.
Если диспетчер теряет заявки, проверяем, сможет ли он вести их в одном месте. Если заявки в порядке, а день уходит на звонки, пробуем дать клиентам понятный статус. Это разные гипотезы. Смешав их в одном MVP, легко получить пользователей и так и не понять, зачем они приходят.
Для пилота зафиксируем один вопрос: готовы ли диспетчеры отказаться от параллельной таблицы? Пригласим пять компаний на четыре недели и посмотрим, какую долю реальных заявок они доведут до закрытия в сервисе. Пять компаний здесь нужны для конкретного примера. Достаточность выборки зависит от того, какое решение мы собираемся принять и насколько различаются участники.
До разработки полезно посмотреть, как диспетчер работает сейчас. Просим показать последний потерянный заказ, а не оценить будущий интерфейс. В разговоре выяснится, что заявки иногда теряются между ночной сменой и утренним сотрудником. Тогда общий список полезен только вместе с передачей ответственности. Просто собрать сообщения в ещё одну ленту недостаточно.
На этом же шаге отделяем пользователя от покупателя. Диспетчеру важно меньше переключаться между чатами. Руководителю важно не терять выручку и понимать загрузку мастеров. Можно сделать удобный инструмент, который сотрудники полюбят, но руководитель не захочет оплачивать. В пилоте нужно участие обоих, хотя вопросы к ним будут разными.
Выбираем самый рискованный тезис. Например, данные уже доступны, интерфейс технически несложный, а главный риск в том, что сотрудники продолжат вести таблицу. Значит, ещё одна неделя на архитектуру не снизит основной риск. Полезнее дать небольшой группе рабочий сценарий и наблюдать, что они делают без напоминаний.
До запуска записываем возможные исходы. Если компании переносят реальные заявки и возвращаются сами, продолжаем проверку. Если пользуются только после наших звонков, выясняем причину. Если лиды согласились посмотреть, но никто не подключился, пилот пока не начался. Это разные ситуации, и одинаковое решение "добавить функций" для всех будет слишком дорогим.
Важна и исходная точка. Без неё любое улучшение можно приписать продукту. Узнаём, сколько заявок сейчас теряется, сколько времени занимает передача смены и как часто клиенту приходится повторять информацию. Достаточно простого учёта на период до пилота. Точность измерения должна соответствовать решению, которое мы хотим принять, а не превращаться в отдельный исследовательский проект.
Режем фичи, но сохраняем рабочий сценарий
Диспетчер должен создать заявку, назначить мастера, обновить статус и закрыть работу. Если после создания заявки ему снова нужна таблица, мы проверяем форму ввода. Работу компании такой релиз ещё не заменяет. Поэтому сначала собираем путь пользователя, а уже потом считаем экраны и задачи.
На каждом шаге можно срезать сложность: один тип ремонта, одна роль сотрудника, уведомления по почте. Например, вместо отдельного приложения мастер сообщает результат диспетчеру, а тот закрывает заявку. Пользователь получает результат, хотя под капотом ещё нет автоматизации. Главное, чтобы упрощение не убрало то действие, ради которого человек пришёл.
Разложим одну заявку на конкретный день работы. Клиент пишет утром, диспетчер создаёт запись, мастер принимает работу, вечером сообщает результат. Где-то между этими шагами клиент переносит визит. Если сервис не позволяет поменять дату, закончить путь можно только через чат. Значит, перенос относится к ядру сценария, даже если на первом макете его не было.
Теперь смотрим на альтернативы. Диспетчеру необязательно назначать мастера через сложный календарь. В пилоте достаточно списка доступных людей и одного поля времени. Не нужен умный подбор, если нас интересует факт передачи заявки. Такая замена сокращает разработку, сохраняя тот результат, который мы проверяем.
Полезно отдельно отметить редкие ситуации, которые блокируют продолжение. Ошибку назначения нельзя просто назвать редким кейсом и забыть. А вот пакетный экспорт истории может подождать: отсутствие этой функции не мешает довести сегодняшнюю заявку до результата. Приоритет здесь определяется влиянием на путь, а не частотой появления слова в интервью.
Не все участники обязаны получить собственный интерфейс. На первом этапе диспетчер может работать в сервисе, мастер получать уведомление, а клиент открывать ссылку со статусом. Когда появится потребность в частой самостоятельной работе каждой роли, станет понятно, какой отдельный кабинет оправдан. Три роли ещё не означают три приложения.
Проверяем скоуп проходом по сценарию, а не чтением списка задач. Берём реалистичные данные, намеренно ошибаемся в адресе, переносим время и завершаем работу. Если на каком-то шаге нужна необговорённая помощь разработчика, это дырка в сценарии. Её лучше увидеть на прототипе, чем после приглашения первой компании.
Ручная работа: где экономия, а где самообман
Старые заявки можно импортировать скриптом, счета выставлять вручную, первых клиентов подключать на созвоне. Это нормальный способ не тратить недели на обвязку, пока мы проверяем основной процесс. Но только если самостоятельный онбординг или оплата сами по себе не являются предметом проверки.
Если команда каждый день заводит заявки за диспетчера, активность в сервисе ещё не доказывает, что диспетчер готов им пользоваться. Такой пилот показывает, что работает услуга с участием команды. Чтобы не перепутать её с продуктом, записываем, какую работу сделали вручную, сколько времени потратили и где пользователь застрял.
Десять минут помощи на компанию в день могут быть приемлемой ценой обучения. Два часа на каждую заявку уже меняют экономику. После пилота нужно посчитать, что останется без нашей помощи, сколько стоит автоматизация и покрывает ли будущая выручка обслуживание. Само по себе закрытие заявки на эти вопросы не отвечает.
Ручные операции стоит спроектировать так же явно, как функции продукта. Кто подключает компанию, как получает данные, где хранит результат, сколько это занимает? Если ответ "разработчик разберётся по ходу", операционный долг появится раньше пользователей. Для пилота хватит короткой инструкции и ответственного, но они должны существовать.
Отдельно считаем масштабирование этой работы. При пяти компаниях настройка за полчаса занимает два с половиной часа. При ста компаниях это уже 50 часов, причём каждый перенос запуска отнимает время у разработки. Такой расчёт не требует точного прогноза продаж. Он показывает, при каком росте текущий процесс перестанет помещаться в неделю.
Некоторую помощь нельзя убрать сразу, потому что команда ещё учится. Это нормально, если мы различаем обучение и постоянную необходимость. Один раз объяснить статус сотруднику и каждый день исправлять за него статус означают разное. В заметках пилота отмечаем, какая помощь повторяется и почему человек не может выполнить действие сам.
Если ручная работа затрагивает данные клиентов, делаем её через понятный процесс с ограниченным доступом. Не стоит копировать рабочую базу в личные таблицы ради быстрого импорта. Даже у маленького пилота есть владельцы данных и последствия ошибки. Простота реализации не должна означать отсутствие контроля.
Автоматизируем сначала то, что стало частым, понятным и дорогим. Редкий импорт, формат которого меняется после каждого интервью, рано превращать в универсальный конструктор. А ежедневную отправку одинаковых уведомлений уже можно оценить как стабильный процесс. Так следующий релиз опирается на наблюдаемую работу, а не на страх, что когда-нибудь её будет много.
Что нельзя вырезать из MVP
Если сервис теряет заявки или показывает одной компании данные другой, проверить полезность сценария уже не получится. Диспетчер сохранит таблицу на всякий случай. Мы увидим низкое использование, но причиной будет недоверие к сервису. Бэкапы, права доступа и возможность исправить ошибку нужны ровно настолько, чтобы люди могли доверить продукту выбранную работу.
Планка зависит от пилота. Десяти приглашённым компаниям можно вручную восстановить доступ. При открытой регистрации такой процесс быстро станет узким местом. До запуска договариваемся, что обещаем участникам, какие условия поддерживаем и как разбираем сбой. Всё остальное можно обсуждать как следующий этап, но эти обещания должны выполняться.
Для заявок минимальная надёжность проверяется простыми вопросами. Что будет после повторного нажатия "создать"? Видит ли другая компания запись по чужой ссылке? Можно ли восстановить случайно удалённую заявку? Это не абстрактный перечень лучших практик. Каждая проверка защищает конкретное обещание участникам пилота.
Необязательно реализовывать идеальную отказоустойчивость сразу. Можно честно ограничить часы поддержки и объём данных, договориться о ручном восстановлении и протестировать его. Но восстановление должно быть действием, которое команда реально умеет выполнить. Фраза "у нас есть бэкап" без проверки доступа, полноты и времени возврата заявки мало что гарантирует.
Разделяем качество сценария и визуальную полировку. Простая форма может прекрасно решать задачу. Форма без внятных ошибок ввода заставит сотрудника угадывать, сохранились ли данные. Это уже влияет на использование. Поэтому читаемые состояния, подтверждение действия и понятная обработка ошибки часто важнее ещё одной красивой анимации.
Для самого пилота назначаем владельца инцидентов. Участник должен понимать, куда писать, если мастер не получил уведомление. Команда должна понимать, кто проверяет доставку и как помогает продолжить работу. Без этого каждый сбой превращается в длинный поиск человека, который случайно знает систему.
После исправления не смешиваем данные до и после в одно число. Если первая неделя прошла с потерянными уведомлениями, низкое возвращение пользователей нельзя целиком относить к ценности идеи. Отмечаем дефект, период его влияния и повторно проверяем сценарий. Это помогает избежать как ложного отказа от продукта, так и удобного оправдания любой плохой метрики.
Как удержать скоуп после первого созвона
Обычно MVP разрастается по одной вполне разумной просьбе за раз. Чтобы каждую не обсуждать заново, достаточно короткого документа: гипотеза, рабочий сценарий, обязательные условия, отложенные фичи и критерии готовности. Любую новую задачу сверяем с вопросом: что именно мы не сможем проверить без неё?
Отчёт по мастерам подождёт, если сейчас проверяем ведение заявок. Возможность сменить ошибочно назначенного мастера нужна сразу: без неё обычная ошибка остановит работу. Когда обязательная задача всплывает позже, честно пересобираем план: убираем другую фичу, двигаем срок или добавляем бюджет. Молча положить её сверху означает потерять контроль над скоупом.
В документе полезно написать не только что входит, но и как работает выбранная версия. "Уведомления" слишком широкое слово. "Письмо мастеру после назначения, без подтверждения прочтения и без SMS" уже можно оценить. Согласованное поведение снимает больше будущих споров, чем длинный перечень названий функций.
Для отложенных задач сохраняем причину и сигнал возвращения. Например, массовое назначение появится, когда ручное назначение начнёт занимать заметную часть смены. Без такого сигнала список "потом" быстро превращается в обязательства, которые никто не принимал. Дата второго релиза сама по себе не делает задачу нужной.
На встрече по изменениям обсуждаем последствия в одном месте: какую гипотезу затронула просьба, сколько работы добавилось, что снимаем и кто принимает решение. Разработчик не должен в одиночку угадывать бизнес-приоритет. Руководитель не должен узнавать о новом сроке после завершения спринта.
В оценке оставляем место неизвестному. Интеграция с внешней системой может оказаться сложнее документации. Это не повод молча обещать точный срок. Можно выделить короткую проверку доступа и данных, после неё уточнить оценку. В таком случае команда покупает информацию до дорогой реализации.
Скоуп полезно пересматривать, когда изменился сам вопрос пилота. Если выяснилось, что компании уже ведут заявки нормально, а проблема только в статусах для клиента, старый набор функций не нужно защищать ради договорённости. Нужно явно принять новое решение и признать, что прежний эксперимент больше не отвечает задаче.
Что делать после пилота
Смотрим, какая работа завершена, кто вернулся и где людям снова понадобилась таблица. Затем разбираем причины с участниками. Одна компания могла уйти из-за неудобного статуса, другая из-за сезонного спада, третья потому, что закупку решает руководитель, которого мы вообще не подключили к пилоту. Общий процент активности эти причины склеит.
После такой проверки можно продолжить сценарий, поменять аудиторию или закрыть идею. Готовность платить проверяем отдельно: бесплатный пилот не даёт ответа о цене. Следующий релиз должен разбирать конкретную неопределённость, которую мы обнаружили. Отложенный бэклог не становится обязательным только потому, что первый релиз уже состоялся.
Разбор пилота начинается с фактов по каждой компании. Когда подключилась, сколько заявок завела, сколько завершила, где потребовалась помощь и кто пользовался в последнюю неделю. Это не дашборд ради отчёта. По такой истории видно, где красивое среднее скрывает одну активную компанию и четыре заброшенных аккаунта.
Интервью проводим вокруг последних действий. "Почему вы перестали пользоваться?" может дать вежливый общий ответ. "Покажите последнюю заявку, которую закрыли в таблице" возвращает разговор к работе. Возможно, человеку не хватило поля, а возможно, решение вообще не соответствует тому, как компания распределяет ответственность.
Проверку цены строим на понятном предложении. Указываем, за что платит компания, что входит в поддержку и когда начинается оплата. Согласие с фразой "вы бы купили полезный сервис?" почти ничего не стоит. Реальный следующий шаг, например продолжение на платных условиях, гораздо ближе к проверке бизнес-модели.
Решение после пилота связываем с затратами следующего этапа. Есть разница между дополнительной неделей на исправление сценария и полугодом на новое приложение. Чем дороже шаг, тем сильнее должны быть основания. Отказ от большой инвестиции при слабых данных может быть хорошим результатом MVP.
Наконец, сохраняем выводы вместе с ограничениями: кого приглашали, какую помощь давали, какие данные не собрали и что остаётся неизвестным. Через месяц эти детали забываются, а фраза "пилот успешный" начинает оправдывать любое решение. Короткая честная запись помогает следующей версии проверять новый вопрос, не выдавая старую неопределённость за установленный факт.
Как собрать план пилота из этих решений
Вернёмся к ремонтным компаниям и соберём решение целиком. Вопрос пилота: смогут ли диспетчеры вести заявки без параллельной таблицы? В первый релиз входят создание, назначение, перенос времени, статус и закрытие. Один тип ремонта и одна роль сокращают варианты, но не разрывают путь. Мастер отвечает диспетчеру привычным способом, клиент получает страницу статуса.
До приглашения подготовим несколько сценариев: обычную заявку, неверного мастера, перенос и повторное создание. Проверим разделение компаний, восстановление записи и понятные ошибки. Настройку первых аккаунтов делаем вручную по инструкции. В журнале пилота отдельно считаем помощь, чтобы завершённая работа команды не выдавала себя за самостоятельное использование.
Для каждой компании записываем исходный процесс и результаты по неделям. Через четыре недели обсуждаем последние реальные заявки, возвращение и условия платного продолжения. Нет общего обещания, что такой срок всё докажет: он ограничивает конкретную проверку. Если данные противоречивы, выбираем следующий небольшой эксперимент, который различит причины.
Новые фичи проходят через тот же вопрос. Календарь добавляем, если отсутствие календаря действительно мешает назначать и заставляет возвращаться в таблицу. Аналитику откладываем, пока она не нужна для выбранного решения. Выход пилота представляет собой факты, причины и план следующей проверки. Рабочая первая версия полезна именно тем, что позволяет принять более обоснованное решение до большой инвестиции.