Что ИзмерÑть в КонÑьерж-MVP?
ОÑнователи, ищущие валидацию конÑьерж-MVP, обычно пытаютÑÑ Ð¿Ñ€Ð¸Ð½Ñть решение, а не Ñобрать более длинный ÑпиÑок идей. Они хотÑÑ‚ знать, как выглÑдит доÑÑ‚Ð¾Ð²ÐµÑ€Ð½Ð°Ñ Ð¿ÐµÑ€Ð²Ð°Ñ Ð²ÐµÑ€ÑиÑ, какие доказательÑтва важны и что может подождать, пока не будет проверено центральное предположение.
Что ИзмерÑть в КонÑьерж-MVP? наиболее полезно, когда ÑвÑзано Ñ Ð¾Ð´Ð½Ð¸Ð¼ клиентом, одной проблемой и одним измеримым результатом. Ð’ Ñтом контекÑте ручной или предпродажный валидационный теÑÑ‚ должен помочь оÑнователю, ищущему поведенчеÑкие доказательÑтва до полной разработки, получить доÑтоверное подтверждение ÑпроÑа, ценноÑти рабочего процеÑÑа или приверженноÑти клиента. Он не должен имитировать поверхноÑтные функции зрелого продукта, не воÑÐ¿Ñ€Ð¾Ð¸Ð·Ð²Ð¾Ð´Ñ Ð¾Ð±ÑƒÑ‡ÐµÐ½Ð¸Ðµ, которое их оправдывало.
Ðтот гид объÑÑнÑет, как нетехничеÑкий оÑнователь может ответÑтвенно применить тему и превратить её в ÑфокуÑированный Ñледующий шаг.
Ðачните С РешениÑ, Которое Ðужно ПринÑть
Запишите решение одним предложением. Примеры: завершат ли клиенты рабочий процеÑÑ, вернутÑÑ Ð»Ð¸ иÑпользовать его Ñнова, примут ли ручное выполнение, заплатÑÑ‚ ли за результат, или будут ли доÑтаточно доверÑть результату, чтобы иÑпользовать его в реальной работе.
Затем определите неопределённоÑть, мешающую Ñтому решению. Она может каÑатьÑÑ ÑпроÑа, удобÑтва иÑпользованиÑ, техничеÑкой оÑущеÑтвимоÑти, операционных уÑилий, Ñ†ÐµÐ½Ð¾Ð¾Ð±Ñ€Ð°Ð·Ð¾Ð²Ð°Ð½Ð¸Ñ Ð¸Ð»Ð¸ надёжноÑти. Разные неопределённоÑти требуют разных теÑтов. Кликабельный прототип не может доказать удержание, а промышленное ПО может быть не нужно Ð´Ð»Ñ Ð¿Ñ€Ð¾Ð²ÐµÑ€ÐºÐ¸ того, понимают ли клиенты предложенный рабочий процеÑÑ.
ПоиÑковое намерение Ñтой Ñтатьи — определить полезные доказательÑтва валидации. Преобразуйте Ñто намерение в наблюдаемое поведение и правило принÑÑ‚Ð¸Ñ Ñ€ÐµÑˆÐµÐ½Ð¸Ð¹ до выбора функций.
Ðтот ÑвÑзанный гид даёт дополнительный контекÑÑ‚ о продукте или подходе к валидации в рамках Ñтой темы.
ИÑпользуйте Примеры Как Паттерны, Ð Ðе Спецификации
Пример может раÑкрыть полезный паттерн: узкую аудиторию, ручной шаг, один полный рабочий процеÑÑ, или измеримую приверженноÑть клиента. Он не должен превращатьÑÑ Ð² ÑпиÑок функций, Ñкопированный на другой рынок.
При раÑÑмотрении примера Ñпрашивайте:
- Кто первый пользователь, и что вызывает его потребноÑть?
- Что он делает ÑÐµÐ³Ð¾Ð´Ð½Ñ Ð²Ð¼ÐµÑто иÑÐ¿Ð¾Ð»ÑŒÐ·Ð¾Ð²Ð°Ð½Ð¸Ñ Ð¿Ñ€Ð¾Ð´ÑƒÐºÑ‚Ð°?
- Какой единÑтвенный результат даёт Ð¿ÐµÑ€Ð²Ð°Ñ Ð²ÐµÑ€ÑиÑ?
- Какое предположение проверÑет реальное иÑпользование?
- Что оÑтаётÑÑ Ñ€ÑƒÑ‡Ð½Ñ‹Ð¼, и кто Ñто выполнÑет?
- Какое доказательÑтво определÑет Ñледующую инвеÑтицию?
Два продукта Ñ Ð¿Ð¾Ñ…Ð¾Ð¶Ð¸Ð¼Ð¸ интерфейÑами могут проверÑть очень разные риÑки. Одному может понадобитьÑÑ Ð´Ð¾ÐºÐ°Ð·Ð°Ñ‚ÑŒ техничеÑкую точноÑть, а другому — доказать, что покупатели и продавцы завершат Ñделку. Правильный MVP Ñледует за риÑком, а не за визуальным ÑходÑтвом.
Определите Ðаименьший Полный Результат
Минимум не означает неполный. Пользователь должен иметь возможноÑть перейти от ÑÑной отправной точки к ценному результату, даже еÑли чаÑть работы выполнÑетÑÑ Ð·Ð° кулиÑами людьми.
Ð”Ð»Ñ Ñтой темы планирование должно учитывать:
- точное предположение и целевого клиента
- чеÑтное опиÑание того, что ÑущеÑтвует ÑегоднÑ
- ручное выполнение или ÑимулÑцию за опытом
- правило принÑÑ‚Ð¸Ñ Ñ€ÐµÑˆÐµÐ½Ð¸Ð¹ на оÑнове поведениÑ, оплаты или повторного иÑпользованиÑ
СоÑтавьте карту нормального пути и важных иÑключений. Включите админиÑтрирование, права доÑтупа, коммуникацию и обработку ошибок, нужные Ð´Ð»Ñ Ð½Ð°Ð´Ñ‘Ð¶Ð½Ð¾Ñти опыта. Отложите функции, увеличивающие объём без уÑÐ¸Ð»ÐµÐ½Ð¸Ñ Ð´Ð¾ÐºÐ°Ð·Ð°Ñ‚ÐµÐ»ÑŒÑтв.
Ручные операции приемлемы, когда они намеренны и измеримы. ФикÑируйте требуемое времÑ, иÑÐ¿Ñ€Ð°Ð²Ð»ÐµÐ½Ð¸Ñ Ð¸ поддержку. Ðти Ð½Ð°Ð±Ð»ÑŽÐ´ÐµÐ½Ð¸Ñ Ð¿Ð¾ÐºÐ°Ð·Ñ‹Ð²Ð°ÑŽÑ‚, какой шаг Ñоздаёт ценноÑть Ð´Ð»Ñ ÐºÐ»Ð¸ÐµÐ½Ñ‚Ð° и какую автоматизацию Ñтоит поÑтроить Ñледующей.
СвÑжите Каждую Функцию С ДоказательÑтвами
Ð¤ÑƒÐ½ÐºÑ†Ð¸Ñ Ð·Ð°Ñлуживает меÑта в MVP, когда она обеÑпечивает оÑновной результат, защищает пользователÑ, или помогает измерить главное предположение. УдобÑтво Ñамо по Ñебе обычно более ÑÐ»Ð°Ð±Ð°Ñ Ð¿Ñ€Ð¸Ñ‡Ð¸Ð½Ð° при первом релизе.
| Ð’Ð¾Ð¿Ñ€Ð¾Ñ Ð¾ продукте | ДоказательÑтва Ð´Ð»Ñ Ñбора | Возможное Ñледующее решение |
|---|---|---|
| ДоÑтигает ли пользователь предполагаемой ценноÑти? | Завершение рабочего процеÑÑа и наблюдение | Сохранить, упроÑтить или переÑмотреть путь |
| ДоÑтаточно ли надёжен результат? | Сбои, иÑÐ¿Ñ€Ð°Ð²Ð»ÐµÐ½Ð¸Ñ Ð¸ Ñлучаи поддержки | Улучшить качеÑтво или добавить контроль |
| ДоÑтаточно ли заботит Ñто клиента, чтобы дейÑтвовать? | Повторное иÑпользование, приверженноÑть или оплата | Продолжать инвеÑтировать или переÑмотреть проблему |
| Может ли команда управлÑть продуктом? | Ручные уÑилиÑ, ÑтоимоÑть и иÑÐºÐ»ÑŽÑ‡ÐµÐ½Ð¸Ñ | Ðвтоматизировать, укомплектовать перÑоналом, или Ñузить объём |
Определите ÑÐ¾Ð±Ñ‹Ñ‚Ð¸Ñ Ð¸ пороги до проÑмотра результатов. Иначе команда может переоÑмыÑлить Ñлабые доказательÑтва, чтобы защитить уже предпочитаемую идею.
Ð”Ð»Ñ Ð¼Ð°Ð»Ñ‹Ñ… выборок изучайте отдельные пути нарÑду Ñ Ð¸Ñ‚Ð¾Ð³Ð°Ð¼Ð¸. ДеÑÑть релевантных клиентов, завершивших ценный рабочий процеÑÑ, могут научить большему, чем большое чиÑло поÑетителей, никогда не предÑтавлÑвших целевой рынок.
Приоритизируйте По РиÑку, ЦенноÑти И УÑилиÑм
ÐŸÑ€Ð¸Ð¾Ñ€Ð¸Ñ‚Ð¸Ð·Ð°Ñ†Ð¸Ñ Ñ„ÑƒÐ½ÐºÑ†Ð¸Ð¹ должна начинатьÑÑ Ñ Ñ€Ð¸Ñка клиента и продукта, а не Ñ Ð³Ð¾Ð»Ð¾ÑÐ¾Ð²Ð°Ð½Ð¸Ñ Ð¿Ð¾ бÑклогу. Определите, что должно быть верным, чтобы продукт работал как бизнеÑ, затем ранжируйте работу по тому, наÑколько напрÑмую она проверÑет Ñти предположениÑ.
Оценивайте уÑÐ¸Ð»Ð¸Ñ ÑˆÐ¸Ñ€Ð¾ÐºÐ¾. Включите дизайн, реализацию, данные, интеграции, теÑтирование, развёртывание, операции и будущее владение. ФункциÑ, кажущаÑÑÑ Ð½ÐµÐ±Ð¾Ð»ÑŒÑˆÐ¾Ð¹ на Ñкране, может ввеÑти неÑколько ролей, ÑоÑтоÑний ÑбоÑ, или Ñторонних завиÑимоÑтей.
ÐŸÑ€Ð°ÐºÑ‚Ð¸Ñ‡Ð½Ð°Ñ Ð¿Ð¾ÑледовательноÑть:
- Сохраните возможноÑть, Ñоздающую оÑновной результат Ð´Ð»Ñ ÐºÐ»Ð¸ÐµÐ½Ñ‚Ð°.
- Сохраните контроль, необходимый Ð´Ð»Ñ Ð±ÐµÐ·Ð¾Ð¿Ð°ÑноÑти, приватноÑти и надёжноÑти.
- Сохраните измерение, необходимое Ð´Ð»Ñ Ð¸Ð½Ñ‚ÐµÑ€Ð¿Ñ€ÐµÑ‚Ð°Ñ†Ð¸Ð¸ ÑкÑперимента.
- УпроÑтите или выполнÑйте вручную вÑпомогательную работу Ñ Ð½Ð¸Ð·ÐºÐ¸Ð¼ объёмом.
- Отложите функции, обÑлуживающие будущие Ñегменты или редкие Ñитуации.
Ðтот гид по приоритизации может помочь оÑнователÑм отличить полезную Ñтруктуру принÑÑ‚Ð¸Ñ Ñ€ÐµÑˆÐµÐ½Ð¸Ð¹ от ÑƒÐ¿Ñ€Ð°Ð¶Ð½ÐµÐ½Ð¸Ñ Ð¿Ð¾ оценке, Ñоздающего ложную точноÑть.
Планируйте Бюджет Вокруг Рабочего ПроцеÑÑа
ДоÑтоверный бюджет охватывает больше, чем чаÑÑ‹ разработки. Он включает доÑтаточно иÑÑледований Ð´Ð»Ñ Ð¾Ð¿Ñ€ÐµÐ´ÐµÐ»ÐµÐ½Ð¸Ñ Ñ€Ð°Ð±Ð¾Ñ‡ÐµÐ³Ð¾ процеÑÑа, дизайн Ð´Ð»Ñ ÑƒÑÑ‚Ñ€Ð°Ð½ÐµÐ½Ð¸Ñ Ð½ÐµÐ¾Ð´Ð½Ð¾Ð·Ð½Ð°Ñ‡Ð½Ð¾Ñти, инженерию, теÑтирование, развёртывание, мониторинг, документацию и ответÑтвенный период итераций поÑле запуÑка.
Включите Ñторонние ÑервиÑÑ‹ и операционный труд. Платежи, коммуникации, картографиÑ, иÑпользование моделей, аналитика и поддержка могут Ñоздавать регулÑрные раÑходы. Ручное выполнение также имеет ÑтоимоÑть, даже когда его выполнÑет Ñам оÑнователь.
ИÑпользуйте диапазоны, пока важные Ð¿Ñ€ÐµÐ´Ð¿Ð¾Ð»Ð¾Ð¶ÐµÐ½Ð¸Ñ Ð¾ÑтаютÑÑ Ð½ÐµÑ€ÐµÑˆÑ‘Ð½Ð½Ñ‹Ð¼Ð¸. ПопроÑите каждый вариант разработки оценить один и тот же объём и критерии приёмки. РаÑценки неÑравнимы, когда одна включает теÑтирование и владение, а Ð´Ñ€ÑƒÐ³Ð°Ñ Ð¾Ñ…Ð²Ð°Ñ‚Ñ‹Ð²Ð°ÐµÑ‚ только начальную реализацию.
Избегайте иÑÐ¿Ð¾Ð»ÑŒÐ·Ð¾Ð²Ð°Ð½Ð¸Ñ Ð¿Ñ€Ð¾Ð¸Ð·Ð²Ð¾Ð»ÑŒÐ½Ð¾Ð³Ð¾ минимального бюджета как доказательÑтва жизнеÑпоÑобноÑти продукта. Меньший валидационный теÑÑ‚ может быть правильным Ñледующим шагом, еÑли доÑтупное финанÑирование не может поддержать полный и надёжный результат Ð´Ð»Ñ Ð¿Ð¾Ð»ÑŒÐ·Ð¾Ð²Ð°Ñ‚ÐµÐ»Ñ.
Проведите ТеÑÑ‚ Без Излишних Обещаний
ОÑнователи должны быть ÑÑны в том, что получают клиенты. Прототип — не промышленный продукт, предзаказ — не Ð½ÐµÐ¼ÐµÐ´Ð»ÐµÐ½Ð½Ð°Ñ Ð´Ð¾Ñтавка, а уÑлуга Ñ Ñ€ÑƒÑ‡Ð½Ñ‹Ð¼ выполнением не должна предÑтавлÑтьÑÑ ÐºÐ°Ðº полноÑтью автоматизированнаÑ, еÑли Ñто различие влиÑет на решение клиента.
УÑтановите границы теÑта: кто может учаÑтвовать, что включено, как долго он длитÑÑ, ÐºÐ°ÐºÐ°Ñ Ð¿Ð¾Ð´Ð´ÐµÑ€Ð¶ÐºÐ° доÑтупна, и что проиÑходит Ñ Ð¿Ð»Ð°Ñ‚ÐµÐ¶Ð°Ð¼Ð¸ или данными, еÑли продукт не будет продолжен. Чёткие Ð¾Ð¶Ð¸Ð´Ð°Ð½Ð¸Ñ Ð·Ð°Ñ‰Ð¸Ñ‰Ð°ÑŽÑ‚ доверие и улучшают качеÑтво обратной ÑвÑзи.
Спрашивайте о поведении, а не об общих мнениÑÑ…. Ðаблюдайте, где пользователи колеблютÑÑ, ÐºÐ°ÐºÐ°Ñ Ð¸Ð½Ñ„Ð¾Ñ€Ð¼Ð°Ñ†Ð¸Ñ Ð¸Ð¼ нужна, завершают ли они рабочий процеÑÑ, и что делают поÑле. Сильные доказательÑтва иÑходÑÑ‚ из дейÑтвий в реалиÑтичном контекÑте.
Изучите Результаты Перед РаÑширением Объёма
Ð’ конце теÑта объедините поведенчеÑкие данные, объÑÑÐ½ÐµÐ½Ð¸Ñ ÐºÐ»Ð¸ÐµÐ½Ñ‚Ð¾Ð², результаты качеÑтва, операционные уÑÐ¸Ð»Ð¸Ñ Ð¸ ÑтоимоÑть. СпроÑите, что изменилоÑÑŒ в понимании команды и ÐºÐ°ÐºÐ°Ñ Ð½ÐµÐ¾Ð¿Ñ€ÐµÐ´ÐµÐ»Ñ‘Ð½Ð½Ð¾Ñть ÑÐµÐ¹Ñ‡Ð°Ñ Ð½Ð°Ð¸Ð±Ð¾Ð»ÐµÐµ важна.
Ðе реагируйте на каждый Ð·Ð°Ð¿Ñ€Ð¾Ñ Ð´Ð¾Ð±Ð°Ð²Ð»ÐµÐ½Ð¸ÐµÐ¼ функции. Ð—Ð°Ð¿Ñ€Ð¾Ñ Ð¼Ð¾Ð¶ÐµÑ‚ раÑкрыть нечёткое позиционирование, Ñлабую адаптацию, недоÑтающую информацию, или неверный Ñегмент клиентов. ИÑÑледуйте причину, прежде чем раÑширÑть бÑклог.
Следующим шагом может быть другой прототип, более ÑƒÐ·ÐºÐ°Ñ Ð°ÑƒÐ´Ð¸Ñ‚Ð¾Ñ€Ð¸Ñ, ÑƒÐ»ÑƒÑ‡ÑˆÐµÐ½Ð½Ð°Ñ Ð½Ð°Ð´Ñ‘Ð¶Ð½Ð¾Ñть, платный пилот, или рабочий MVP. Ðто также может быть решение оÑтановитьÑÑ. Ð’Ð°Ð»Ð¸Ð´Ð°Ñ†Ð¸Ñ Ñоздаёт ценноÑть, когда менÑет инвеÑтиционные решениÑ, Ð²ÐºÐ»ÑŽÑ‡Ð°Ñ Ñ€ÐµÑˆÐµÐ½Ð¸Ñ Ð½Ðµ Ñтроить.
Ðта ÑопутÑÑ‚Ð²ÑƒÑŽÑ‰Ð°Ñ ÑÑ‚Ð°Ñ‚ÑŒÑ Ð¸ÑÑледует другое практичеÑкое решение, Ñ ÐºÐ¾Ñ‚Ð¾Ñ€Ñ‹Ð¼ ÑталкиваютÑÑ Ð¾Ñнователи при переходе от ранних доказательÑтв к разработке.
Превратите Тему Ð’ План ДейÑтвий Ð”Ð»Ñ ÐžÑнователей
Что ИзмерÑть в КонÑьерж-MVP? должно привеÑти к конкретному дейÑтвию. Определите клиента и результат, назовите Ñамое риÑкованное предположение, выберите Ñамый лёгкий доÑтоверный теÑÑ‚, и решите, какое доказательÑтво оправдает Ñледующий Ñтап.
Результат — Ñто не проÑто меньший продукт. Ðто ÑфокуÑÐ¸Ñ€Ð¾Ð²Ð°Ð½Ð½Ð°Ñ ÑиÑтема обучениÑ, ÑвÑÐ·Ñ‹Ð²Ð°ÑŽÑ‰Ð°Ñ Ð¾Ð±ÑŠÑ‘Ð¼, бюджет, поведение клиента и продуктовые решениÑ. Ðта диÑциплина делает примеры более полезными, приоритизацию более обоÑнованной, бюджеты более реалиÑтичными, а ручную валидацию более чеÑтной.
Превратите Своё Продуктовое Предположение Ð’ ПроверÑемый План
MVPHUB помогает оÑнователÑм выбрать правильный подход к валидации, определить ÑфокуÑированный объём MVP, и Ñпланировать Ñледующую ответÑтвенную инвеÑтицию на оÑнове доказательÑтв.
ЗапишитеÑÑŒ на беÑплатную конÑультацию Ñ MVPHUBЧасто Задаваемые Вопросы
Что оÑнователи должны решить в первую очередь о валидации конÑьерж-MVP?
Определите целевого клиента, текущую проблему, желаемый результат и главную неопределённоÑть. Выбирайте пример, набор функций, бюджет или метод валидации только поÑле того, как Ñти моменты проÑÑнены.
Как Ñтартапу применÑть валидацию конÑьерж-MVP?
СоÑредоточьтеÑÑŒ на одном полном результате и иÑпользуйте наименьший доÑтоверный теÑÑ‚, ÑпоÑобный дать поведенчеÑкие доказательÑтва. Включите контроль и операции, нужные Ð´Ð»Ñ Ð½Ð°Ð´Ñ‘Ð¶Ð½Ð¾Ñти опыта.
Когда Ñтартапу Ñтоит инвеÑтировать в Ñледующий Ñтап?
ИнвеÑтируйте дальше, когда релевантные клиенты демонÑтрируют нужное поведение, а команда понимает качеÑтво, ÑтоимоÑть, операционные уÑÐ¸Ð»Ð¸Ñ Ð¸ оÑтавшиеÑÑ Ñ€Ð¸Ñки.