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