MVP (minimum viable product) — это минимальная версия продукта, которая проверяет гипотезу и уже приносит ценность. Ключевое слово — viable, жизнеспособный: MVP должен работать и решать проблему, просто в самом узком виде. Это не «недоделанный продукт» и не «первая сырая версия» — это самый дешёвый способ проверить, что вы вообще делаете нужное. Приоритизация — это выбор, что из списка хотелок делать первым, потому что ресурсы ограничены и всё сразу нельзя. Ходовые методы: MoSCoW (must/should/could/won't), RICE (reach × impact × confidence / effort) и матрица «ценность против усилий». Аналитик в приоритизации — поставщик данных: сколько стоит, скольких затронет, окупится ли.
Я однажды наблюдал, как команда полгода строила «MVP» маркетплейса: каталог, корзина, личный кабинет, программа лояльности, чат с продавцом. Запустили — продавцов на платформе оказалось трое, покупать нечего. Полгода ушло на проверку гипотезы «придут ли продавцы», которую можно было проверить за две недели лендингом и формой заявки. Это был не MVP. Это был полный продукт, который назвали MVP, чтобы оправдать, что делают всё сразу.
Что такое MVP на самом деле
MVP — это самая маленькая версия продукта, на которой можно проверить главную гипотезу и которая при этом уже работает. Расшифровка по словам: minimum — минимум функций, ничего лишнего; viable — жизнеспособный, реально решает проблему пользователя, а не имитирует; product — это продукт, им можно пользоваться. Все три слова важны, и чаще всего теряют именно «viable».
Смысл MVP — не «выпустить поскорее хоть что-то», а проверить рискованное предположение дёшево. У каждого продукта есть гипотеза, на которой всё держится: «людям нужна доставка продуктов за 15 минут», «бизнес готов платить за этот отчёт». Если гипотеза неверна — все красивые фичи поверх неё бесполезны. MVP проверяет именно её, и не тратит деньги на остальное, пока она не подтвердилась.
«MVP = сырая версия» — самое вредное заблуждение
Если под MVP понимать «недоделанный продукт с багами», получится продукт, который не решает проблему, — и гипотезу вы не проверите, потому что люди уйдут из-за того, что он не работает, а не из-за того, что он не нужен. Классическая метафора: MVP для «добраться из А в Б» — это не три колеса от автомобиля (на них не доедешь), а самокат: невзрачно, но едет. Минимальный — да. Нерабочий — нет.
Откуда MVP растёт: дискавери и декомпозиция
MVP не висит в воздухе — он опирается на две вещи, про которые есть отдельные записи. Во-первых, на дискавери: чтобы понять, какую гипотезу проверять MVP, надо сначала эту гипотезу сформулировать и усомниться в ней. MVP — это инструмент дискавери в железе: вместо «спросим пользователей» — «дадим попробовать и посмотрим».
Во-вторых, на декомпозиции и вертикальной нарезке. MVP — это вертикальный срез: тонкий, но сквозной кусок через все слои, который работает целиком, а не «сначала весь бэкенд, потом весь фронт». Тот самокат из callout выше — это и есть вертикальный срез задачи «перемещение»: маленький, но доезжает от А до Б сам. Если вы умеете резать задачу вертикально, вы умеете собирать MVP.
Зачем приоритизировать
Список того, что «хорошо бы сделать», всегда длиннее, чем команда может сделать. Всегда. Ресурсы ограничены — людей, времени и денег конечное количество (про это — в записи о том, зачем аналитику думать про деньги). Значит, выбор «что делать первым» происходит в любом случае: либо осознанно, по критериям, либо стихийно — кто громче попросил или что последним вспомнили. Приоритизация — это просто способ делать этот выбор осознанно и уметь его объяснить.
Методы приоритизации простыми словами
Методов десятки, но в работе аналитик чаще всего встречает три. Они не конкурируют — это разные инструменты под разную ситуацию.
| Метод | Суть | Когда удобен |
|---|---|---|
| MoSCoW | Раскладываем по 4 корзинам: Must / Should / Could / Won't | Быстро, для согласования объёма релиза с заказчиком |
| RICE | Считаем балл = Reach × Impact × Confidence / Effort | Когда надо сравнить разнородные идеи числом |
| Ценность/усилия | Рисуем на матрице 2×2: много пользы — мало труда наверх | Быстрая визуальная сортировка на встрече |
MoSCoW — самый простой. Каждую хотелку кладём в одну из четырёх корзин: Must — без этого релиза нет; Should — важно, но можно чуть позже; Could — приятно, если останется время; Won't (this time) — сознательно не делаем сейчас. Сила метода в последней корзине: явно сказать «это мы НЕ делаем» — половина успеха, как и out-of-scope в спеке.
RICE — когда нужно сравнить идеи числом, а не на глаз. Для каждой считают четыре величины и сводят в один балл:
RICE = (Reach × Impact × Confidence) / Effort
Reach — скольких пользователей затронет за период (например, в месяц)
Impact — насколько сильно повлияет на каждого (по шкале, напр. 0.25 / 0.5 / 1 / 2 / 3)
Confidence — насколько мы уверены в оценках, в процентах (100% / 80% / 50%)
Effort — сколько труда стоит, в человеко-месяцах
Пример. Фича А: 5000 польз/мес × 1 × 80% / 2 чел-мес = 2000
Фича Б: 500 польз/мес × 3 × 50% / 1 чел-мес = 750
Вывод: при ограниченных руках сначала делаем А — балл выше.Главная ценность RICE — не точность чисел (они оценочные), а то, что метод заставляет проговорить четыре вопроса по каждой идее и сравнить идеи в одной системе координат. Знаменатель — Effort — особенно отрезвляет: красивая идея с огромной трудоёмкостью проваливается в рейтинге, и это честно.
Матрица «ценность против усилий» — самый наглядный. Рисуем поле: по одной оси ценность, по другой — усилия, и расставляем идеи точками.
quadrantChart
title Ценность против усилий
x-axis "Мало усилий" --> "Много усилий"
y-axis "Низкая ценность" --> "Высокая ценность"
quadrant-1 "Большие ставки"
quadrant-2 "Делаем первым"
quadrant-3 "Не трогаем"
quadrant-4 "Время-пожиратели"
"Быстрый фикс оплаты": [0.2, 0.85]
"Программа лояльности": [0.8, 0.75]
"Редизайн логотипа": [0.7, 0.2]
"Подсказки в форме": [0.25, 0.5]
Схема делит идеи на четыре угла. Слева вверху — «делаем первым»: много пользы, мало труда, очевидный выбор (быстрый фикс оплаты). Справа вверху — «большие ставки»: пользы много, но и труда много; делаем осознанно и не все сразу (программа лояльности). Слева внизу — мелочи, до которых дойдут руки потом. А справа внизу — «время-пожиратели»: много труда ради малой пользы (редизайн логотипа в момент, когда оплата течёт). Последний угол — главная польза матрицы: он показывает, на что НЕ надо тратить силы, как бы ни хотелось.
Роль аналитика в приоритизации
Решение «что делать первым» принимает продакт или владелец продукта. Но любой из методов выше — это формула, в которую надо подставить числа, и вот эти числа приносит аналитик. Без данных приоритизация превращается в «мне кажется, это важнее».
- Reach / охват: скольких пользователей реально затронет фича? Аналитик достаёт это из аналитики и базы, а не из ощущений.
- Effort / стоимость: сколько это стоит в человеко-месяцах? Здесь аналитик переводит требования в оценку вместе с разработчиками.
- Impact и окупаемость: стоит ли проблема этих денег? Это прямая связь с деньгами задачи: фичу за два месяца работы команды, которая принесёт три новых клиента, считают так же трезво, как любую покупку.
То есть аналитик не выбирает приоритеты, но делает выбор честным: подкладывает под каждую идею цифры, на которые можно опереться и за которые потом не стыдно.
Откуда это взялось
Термин MVP ввёл Фрэнк Робинсон около 2001 года, а в массы его вынес Эрик Рис в книге «The Lean Startup» (2011) — там MVP стал центральным инструментом подхода «строй — измеряй — учись»: проверяй гипотезу дёшево, прежде чем вкладываться. Заблуждение «MVP = сырая версия» родилось ровно из-за моды на этот термин — словом стали называть любой недоделанный релиз. MoSCoW придумали в методологии DSDM в середине 1990-х (строчные буквы o — просто для произносимости). RICE намного моложе: его описала команда Intercom около 2016 года как свой внутренний способ ранжировать идеи продукта — и он быстро разошёлся по индустрии. Заметьте закономерность: все эти методы — попытка заменить спор «кто кого передавит» на разговор по понятным критериям.
Частые вопросы
Что такое MVP простыми словами?
MVP (minimum viable product) — это самая маленькая версия продукта, которая уже работает, решает проблему пользователя и позволяет проверить главную гипотезу, на которой держится продукт. Ключевое — слово «жизнеспособный»: MVP должен реально работать, просто в самом узком виде. Это не «сырая недоделанная версия» и не «всё сразу, но побыстрее», а самый дешёвый способ убедиться, что вы делаете нужное, прежде чем вкладываться в полный продукт. Метафора: для задачи «доехать» MVP — это самокат, а не три колеса от машины.
MoSCoW или RICE — что выбрать?
Зависит от задачи. MoSCoW берите, когда надо быстро согласовать объём релиза с заказчиком: разложили по корзинам Must / Should / Could / Won't — и сразу видно, что входит, а что осознанно не делаем. RICE берите, когда нужно сравнить разнородные идеи числом и обосновать выбор: он считает балл из охвата, влияния, уверенности и трудоёмкости. MoSCoW — про «что в этот релиз», RICE — про «что важнее из всего бэклога». Часто их сочетают: RICE-ом ранжируют бэклог, MoSCoW-ом нарезают конкретный релиз.
Как аналитик участвует в приоритизации?
Аналитик не принимает финальное решение о приоритетах — это делает продакт, — но поставляет данные, без которых любой метод превращается в «мне кажется». Это охват (скольких пользователей затронет, из аналитики и базы), стоимость (сколько человеко-месяцев, в связке с разработкой) и окупаемость (стоит ли проблема этих денег). Подставив реальные числа в формулу RICE или на матрицу «ценность/усилия», аналитик делает выбор честным и объяснимым, а не основанным на том, кто громче попросил.