Управление проектами.РУ

Управление проектами.РУ
Сообщество тех, кто умеет или хочет научиться
хорошо управлять проектами
23 июня 2020 Product Management
0

MVP и MMP, и разница между ними

Юлия Бажанова
Редактор проекта, РМР, ICP-PPM

Давайте сегодня про пару популярных ошибку при разработке ИТ-продуктов поговорим, что ли.

Всем, наверное, известно понятие MVP (Minimum Viable Product) – минимально жизнесопособного продукта, или продукта, обладающего минимальным набором функционала, чтобы “закрыть” потребности пользователя.

На втором месте по популярности в продуктовой разработке идет аббревиатура MMP (Minimal Marketable Product, иногда его еще называют Minimal Sellable Product) – продукт, который не просто “закрывает” минимальные потребности пользователя, а за который этот самый пользователь уже готов платить, т.е. в нем есть что-то, чего нет у бесплатной версии или у конкурентов.

Есть еще довольно новое (и довольно размытое понятие) MLP (Minimum Lovable Product) – продукт, который, может, и не закрывает все потребности, но имеет какое-то невероятное преимущество, за которое его пользователи любят настолько, что готовы мириться с остальными недостатками, но это не тема сегодняшнего поста.

Можно попробовать провести аналогию с любым продуктом, например, с кухонными весами (раз уж на глаза попались):

  1. MVP – взвешивают с точностью до 10 грамм, ничего больше не умеют. Для того, чтобы печь пирожки – вполне пойдет.
  2. MMP – взвешивают с точностью до 1 грамма плюс меряют объем воды и молока в миллилитрах (у меня такие, и это очень удобно, можно забыть про чашки и стаканы при готовке), запоминают общий вес взвешенных продуктов.
  3. MLP – не умеют мерять объем, только вес до 1 грамма, но зато – зато! – имеют чашу в форме миски, которая позволяет вообще при готовке другую посуду не пачкать и не сбрасывать вес тары, а насыпать/наливать продукты прямо в эту чашу, тем более, что их 2 в комплекте. За это можно отсутствие остальных опций вполне простить.

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

Ошибка 1 (вижу на практике все чаще) – пользователям отдают самый минимальный MVP, мол, пусть поработают, по ходу дела улучшать будем. Поставьте себя на место этого пользователя – в жизни вы пользуетесь комфортными удобными приложениями (и за какие-то даже платите), а тут вам команда проекта дает неведомую кривую фигню и настаивает, чтобы вы с ней работали. Я вот когда себя ставлю на место заказчика в такой ситуации – понимаю, что потестировать я бы согласилась, а заставлять свой отдел работать “вот в этом” – ни за какие плюшки. Мораль – на тестирование и пробное использование небольшой группе MVP отдавать можно, а вот выпускать его с посылом “начнем использовать масштабно, как раз быстро все проблемы и хотелки соберем” – не стоит. Если, конечно, у заказчика не совсем горит, и он сам не настаивает.

Ошибка 2 – в проекте и в документации есть всего 2 состояния продукта – MVP  и “полная версия со всеми плюшками”, но нет четко оговоренного MMP или состояния, в котором продукт действительно нужно начать использовать в масштабе компании, чтобы развивать его в правильном направлении. В итоге или получаем слабо работоспособный продукт “с плюшками”, или такой, который устраивает маленькую группу тестеров (и потом при продуктивном использовании выявляем, что 90% других пользователей – нет) или постоянно обижаемся и ругаемся, что чудесный MVP не хотят использовать, хотя команда так старалась. Мораль – с заказчиком нужно фиксировать, какой функционал будет достаточен для того, чтобы ехать в продакшен всей компанией, а не группой тестировщиков.

Как-то так.

комментарии

Добавить комментарий

Такой e-mail уже зарегистрирован. Воспользуйтесь формой входа или введите другой.

Вы ввели некорректные логин или пароль

Sorry that something went wrong, repeat again!

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: