коротко

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 — это вертикальный срез: тонкий, но сквозной кусок через все слои, который работает целиком, а не «сначала весь бэкенд, потом весь фронт». Тот самокат из 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 и окупаемость: стоит ли проблема этих денег? Это прямая связь с деньгами задачи: фичу за два месяца работы команды, которая принесёт три новых клиента, считают так же трезво, как любую покупку.

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

Где эти методы врут — и почему всё равно их используют

RICE даёт ложную точность. Вы перемножаете четыре оценки, три из которых — Reach, Impact, Confidence — по сути угаданы, и на выходе получаете аккуратное число «2000». Точность тут поддельная: умножение субъективных прикидок маскирует гадание под расчёт. Особенно коварен Confidence — его легко подкрутить задним числом под уже принятое решение: хочется протащить любимую фичу — ставим ей 80%, неудобной соседке — 50%, и формула «сама» выдаёт нужный порядок. Цифра выглядит объективной, а на деле в ней зашит чужой интерес.

MoSCoW без жёсткой руки уезжает в «всё Must». Если никто не держит границу, заказчик объявит критичным каждый пункт — и метод вырождается в плоский список без приоритета. Дисциплина MoSCoW держится не на корзинах, а на готовности кого-то сказать «нет, это Should» и не отступить.

Вывод честный: методы приоритизации дисциплинируют разговор — заставляют проговорить вопросы, сравнить идеи в одной системе координат, явно зафиксировать «это не делаем». Но они не заменяют суждение. Число из RICE — не вердикт, а повод обсудить, откуда взялись оценки. Кто относится к баллу как к истине, тот просто прячет ответственность за формулу.

Откуда это взялось

Термин MVP ввёл Фрэнк Робинсон около 2001 года, а в массы его вынес Эрик Рис в книге «The Lean Startup» (2011) — там MVP стал центральным инструментом подхода «строй — измеряй — учись»: проверяй гипотезу дёшево, прежде чем вкладываться. Заблуждение «MVP = сырая версия» родилось ровно из-за моды на этот термин — словом стали называть любой недоделанный релиз. MoSCoW придумали в методологии DSDM в середине 1990-х (строчные буквы o — просто для произносимости). RICE намного моложе: его описала команда Intercom около 2016 года как свой внутренний способ ранжировать идеи продукта — и он быстро разошёлся по индустрии. Заметьте закономерность: все эти методы — попытка заменить спор «кто кого передавит» на разговор по понятным критериям.

Как это спрашивают на собесе

«Что такое MVP — и приведи антипример». Ждут не заученную расшифровку, а понимание слова viable: MVP — это минимальная версия, которая уже работает и решает проблему, чтобы проверить главную гипотезу дёшево. Антипример, который ставит точку: для задачи «доехать из А в Б» MVP — это самокат, а не три колеса от машины — на трёх колёсах ты никуда не едешь, а значит и гипотезу «нужна ли вообще поездка» не проверишь, люди уйдут из-за того, что не работает, а не из-за того, что не нужно. Кто называет MVP «сырой первой версией» — проваливает вопрос на джуне.

«Чем MoSCoW отличается от RICE и когда что». Граница джун/мидл проходит здесь: джун помнит расшифровки (Must/Should/Could/Won't против Reach×Impact×Confidence/Effort), мидл объясняет назначение. MoSCoW — качественная сортировка для согласования объёма конкретного релиза с заказчиком: что входит, что осознанно не входит. RICE — количественное ранжирование всего бэклога, когда надо сравнить разнородные идеи числом и обосновать порядок. Сильный ответ добавляет, что их сочетают: RICE-ом ранжируют бэклог, MoSCoW-ом нарезают релиз.

«Как обоснуешь, почему фичу А делаем раньше Б». Проверяют, не скатишься ли в «мне кажется». Ждут цифры: балл RICE (охват × влияние × уверенность / трудоёмкость) или позицию на матрице «ценность/усилия» — и явное проговаривание, откуда взяты числа (охват — из аналитики, Effort — из оценки с разработкой). Мидл тут же честно отметит, что число оценочное и спор оно не закрывает, а структурирует — это и отличает зрелый ответ от защиты формулы как истины.

Частые вопросы

Что такое MVP простыми словами?

MVP (minimum viable product) — это самая маленькая версия продукта, которая уже работает, решает проблему пользователя и позволяет проверить главную гипотезу, на которой держится продукт. Ключевое — слово «жизнеспособный»: MVP должен реально работать, просто в самом узком виде. Это не «сырая недоделанная версия» и не «всё сразу, но побыстрее», а самый дешёвый способ убедиться, что вы делаете нужное, прежде чем вкладываться в полный продукт. Метафора: для задачи «доехать» MVP — это самокат, а не три колеса от машины.

MoSCoW или RICE — что выбрать?

Зависит от задачи. MoSCoW берите, когда надо быстро согласовать объём релиза с заказчиком: разложили по корзинам Must / Should / Could / Won't — и сразу видно, что входит, а что осознанно не делаем. RICE берите, когда нужно сравнить разнородные идеи числом и обосновать выбор: он считает балл из охвата, влияния, уверенности и трудоёмкости. MoSCoW — про «что в этот релиз», RICE — про «что важнее из всего бэклога». Часто их сочетают: RICE-ом ранжируют бэклог, MoSCoW-ом нарезают конкретный релиз.

Как аналитик участвует в приоритизации?

Аналитик не принимает финальное решение о приоритетах — это делает продакт, — но поставляет данные, без которых любой метод превращается в «мне кажется». Это охват (скольких пользователей затронет, из аналитики и базы), стоимость (сколько человеко-месяцев, в связке с разработкой) и окупаемость (стоит ли проблема этих денег). Подставив реальные числа в формулу RICE или на матрицу «ценность/усилия», аналитик делает выбор честным и объяснимым, а не основанным на том, кто громче попросил.