Очень часто в проекте разработки люди употребляют термин MVP, однако понимают его по разному и применяют с ошибками. Что ведет к тому что образуется много лишних затрат, которые в свою очередь ведут к нарушению сроков проекта, перерасходу бюджета, ну или к полному провалу.

MVP – что это такое?

Термин MVP имеет несколько разных определений, несущих в себе ловушку перфекционизма и ненужную работу.

Что из этого является MVP для вас?

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

Термин Minimum Viable Product впервые ввел Frank Robinson в 2001 году.

We define MVP as that unique product that maximizes return on risk for both the vendor and the customer.

Frank Robinson
2001, MVP – A Proven Methodology to Maximize Return on Risk

В этом определении есть слова:

• «продукт«, что наводит на мысли о необходимости создать классический продукт, пусть и очень скудный;
• «риск«.

Однако в нем ничего НЕ сказано о необходимости:

• разработать минимальный набор функций;
• выпускать формальный релиз;
• публично запускать на открытую аудиторию.

Затем появились определения от Эрика Риса.

The MVP is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.

Eric Ries 2009,
Minimum Viable Product: Guide

The MVP is that version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort.

Eric Ries 2011,
The Lean Startup

Однако, чтобы создать такой продукт, нужно многое узнать и проверить.

Эта статья во многом основана на работе Дмитрия Блинова и его ключевого вывода

Ключевым же в определениях MVP являются снижение рисков и validated learning – подтвержденное знание. Вы делаете предположение (формулируете гипотезу) и проверяете его.

Дмитрий Блинов,
статья — MVP и риски продукта

MVP vs MLP

Есть мнение что Product – тот минимальный, в который люди влюбятся.

Такой продукт будет уже, скорее, Minimum Lovable Product (MLP)

Henrik Kniberg предлагает (article) использовать последовательность этапов разработки:

1. Earliest Testable
2. Usable
3. Lovable Product

Однако многие не могут их отличить, пытаются делать MLP, называют это MVP, и в итоге серьезно выходят за рамки сроков, бюджета или в целом проваливают проект.

RAT vs MVP

Rik Higham предложил вместо MVP использовать термин RAT – Riskiest-Assumption Test (ссылка https://hackernoon.com/the-mvp-is-dead-long-live-the-rat-233d5d16ab02).

Важно сделать акцент на тестировании самого рискованного предположения. Проверка гипотез подробно описана в составе практик «Customer Development» Стива Бланка и «Lean StartUp» Эрика Риса.

Для лучшего осознания, можно привести примеры множества аналогичных понятий:

• ETD — The Easiest Test to Do
• Fail fast, fail safe.
• Fail early and often.
• Prototyping.
• Early and frequent feedback.

Почему термин RAT лучше?

• Есть акцент на снижение рисков
• Нет слова «продукт» И нужно сделать только то, что поможет протестировать самый опасный риск самый простым способом. Не нужно обязательно следовать требованиям к качеству или соглашениям по дизайну, хотя профессионалы внутри нас и хотят этого.
• Нет намека на последовательность Термин MVP как бы предполагает, что MVP2>MVP1 и так далее, последовательно. RAT – это лишь стандартный подход к проактивной работе с рисками. Проверяем гипотезу; она верна – идем дальше; она ложна – ставим крестик и переходим к следующей.

Почему наиболее рисковые задачи надо решать в первую очередь?

Иллюстрация которая хорошо демонстрирует 2 аспекта:

• нарушение правила показывает видимость результата в начале и кажется что все хорошо
• соблюдение правила сначала выглядит глупостью, но к финалу все меняется

Отличать твердое от пустого

Все жизненно важное происходит на грани твердого и пустого. Умение отличать твердое от пустого — важнейшее умение в жизни и бизнесе

Владимир Тарасов, “Технология жизни. Книга для героев”

Твердое — то, на что можно опереться, не провалишься. Это слова или цифры, которым можно верить. Человек, на которого можно положиться — не подведет. Автомобиль, который полностью исправен и заправлен бензином: в нужный момент и заведется, и поедет.

Пустое — то, на что нельзя опереться — провалишься. Информация, которая может оказаться ложной или неполной, неточной. Солдат, который испугается и убежит. Друг, который пообещает и не сделает. Фабрика, которая портит материалы, не производя ничего пригодного.

Комбинация твердого и пустого дает пустое. Если среди двадцати твердых элементов (например, действий) хоть одно оказалось пустым — все усилия пропали зря.

Отличать первостепенное от второстепенного

Подари мне тонкое чутье, чтобы отличать первостепенное от второстепенного

Антуан де Сент-Экзюпери, Искусство маленьких шагов

Все это не будет работать, если будут перепутаны высокорисковые и второстепенные истории.

Люди часто это путают — им кажется что если решение сложное — то значит там высокие риски и потому именно с него надо начать. Но часто бывает так что да это решение сложное, но второстепенное. По факту от него можно просто отказаться или поменять на простое решение с быстрыми результатами.

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

Пример ошибки когда перепутали твердое, пустое, первостепенное и второстепенное

• сайт магазина в котором есть каталог продуктов который можно посмотреть и что то выбрать — это твердое — на это можно положиться
• если на сайте забыли сделать форму заказа (заявки) или она не работает — это пустое — на это нельзя положиться — весь сайт обнуляется
• вместо формы заказа — разработчики сидят и играются с типографикой и шрифтом — это второстепенное, без этого можно жить и запускаться

В команде есть люди — которые путают приоритеты — они начинают впихивать задачи которые не имеют важности. А про важные задачи забывают.

Так проваливаются 90% проектов.

Итоговая схема шагов про MVP+RAT

1. составьте список историй, задач или гипотез с наибольшими рисками
2. выберите те что самые страшные и опасные с точки зрения успеха проекта
3. придумайте наиболее простые решения для проверки и тестов с максимальной эффективностью и точностью что вам доступна
4. спланируйте эти задачи в первую очередь, чтобы проверить риски как можно быстрее
5. повторите шаги с начала

Если проект крупный, то хорошо его разделить на 3 этапа

• этап 1: Альфа версия (PoC + RAT)
  • цель: проверка основных рисков и гипотез по ключевым составляющим
  • тестирование закрытое внутри команды
  • жесткий RAT
• этап 2: Бета версия (MVP + RAT)
  • цель: выйти уже на реальных клиентов как можно быстрее
  • получить первую обратную связь
  • можно сказать что это интеграция MVP+RAT
• этап 3: MLP+ROI
  • возвращаемся к истоку и первому жесткому определению MVP 2001 года от Frank Robinson
  • надо защитить инвестиции и получить возврат потраченных средств (ROI)
  • идем в MLP — привлекаем клиентов, увеличиваем доход и прибыль, развиваем продукт
  • понятно что не все проекты одинаково успешны и иногда тут приходится просто фиксировать убытки

Идеи

Идеи которые были использованы для этой статьи

• MVP и риски продукта https://dblinov.com/post-etd-vs-mvp-and-product-risks
• Искусство маленьких шагов https://aappss.ru/b/iskusstvo-malenkih-shagov/
• Технология “Твердого и Пустого” https://probusiness.io/management/8452-kak-upravlyat-lyudmi-s-pomoshchyu-tekhnologii-tverdogo-i-pustogo-sovetuet-legendarnyy-biznes-trener-tarasov.html