Давайте сегодня про пару популярных ошибку при разработке ИТ-продуктов поговорим, что ли.
Всем, наверное, известно понятие MVP (Minimum Viable Product) – минимально жизнесопособного продукта, или продукта, обладающего минимальным набором функционала, чтобы “закрыть” потребности пользователя.
На втором месте по популярности в продуктовой разработке идет аббревиатура MMP (Minimal Marketable Product, иногда его еще называют Minimal Sellable Product) – продукт, который не просто “закрывает” минимальные потребности пользователя, а за который этот самый пользователь уже готов платить, т.е. в нем есть что-то, чего нет у бесплатной версии или у конкурентов.
Есть еще довольно новое (и довольно размытое понятие) MLP (Minimum Lovable Product) – продукт, который, может, и не закрывает все потребности, но имеет какое-то невероятное преимущество, за которое его пользователи любят настолько, что готовы мириться с остальными недостатками, но это не тема сегодняшнего поста.
Можно попробовать провести аналогию с любым продуктом, например, с кухонными весами (раз уж на глаза попались):
- MVP – взвешивают с точностью до 10 грамм, ничего больше не умеют. Для того, чтобы печь пирожки – вполне пойдет.
- MMP – взвешивают с точностью до 1 грамма плюс меряют объем воды и молока в миллилитрах (у меня такие, и это очень удобно, можно забыть про чашки и стаканы при готовке), запоминают общий вес взвешенных продуктов.
- MLP – не умеют мерять объем, только вес до 1 грамма, но зато – зато! – имеют чашу в форме миски, которая позволяет вообще при готовке другую посуду не пачкать и не сбрасывать вес тары, а насыпать/наливать продукты прямо в эту чашу, тем более, что их 2 в комплекте. За это можно отсутствие остальных опций вполне простить.
Так вот, к ошибкам, особенно в корпоративной разработке, на свободном рынке такое, скорее всего, вряд ли получится, жизнь все быстро по местам расставит.
Ошибка 1 (вижу на практике все чаще) – пользователям отдают самый минимальный MVP, мол, пусть поработают, по ходу дела улучшать будем. Поставьте себя на место этого пользователя – в жизни вы пользуетесь комфортными удобными приложениями (и за какие-то даже платите), а тут вам команда проекта дает неведомую кривую фигню и настаивает, чтобы вы с ней работали. Я вот когда себя ставлю на место заказчика в такой ситуации – понимаю, что потестировать я бы согласилась, а заставлять свой отдел работать “вот в этом” – ни за какие плюшки. Мораль – на тестирование и пробное использование небольшой группе MVP отдавать можно, а вот выпускать его с посылом “начнем использовать масштабно, как раз быстро все проблемы и хотелки соберем” – не стоит. Если, конечно, у заказчика не совсем горит, и он сам не настаивает.
Ошибка 2 – в проекте и в документации есть всего 2 состояния продукта – MVP и “полная версия со всеми плюшками”, но нет четко оговоренного MMP или состояния, в котором продукт действительно нужно начать использовать в масштабе компании, чтобы развивать его в правильном направлении. В итоге или получаем слабо работоспособный продукт “с плюшками”, или такой, который устраивает маленькую группу тестеров (и потом при продуктивном использовании выявляем, что 90% других пользователей – нет) или постоянно обижаемся и ругаемся, что чудесный MVP не хотят использовать, хотя команда так старалась. Мораль – с заказчиком нужно фиксировать, какой функционал будет достаточен для того, чтобы ехать в продакшен всей компанией, а не группой тестировщиков.
Как-то так.
Добавить комментарий