Как определить объём MVP: сократите первую версию до того, что действительно важно

Почти каждый, кто приходит к нам с идеей приложения, уже построил его полную версию у себя в голове. Он может описать дашборд, страницу настроек, реферальную программу, тёмную тему. Чего он обычно сказать не может — это какая единственная часть этой картины, если бы заработала, сделала бы всё дело стоящим. Определить объём MVP — это неблагодарная, слегка болезненная работа: найти ту самую часть и набраться смелости оставить остальное на потом.

Я видел, как рождается множество первых продуктов, и те, что испытывают трудности, почти никогда не проваливаются из-за лени команды. Они проваливаются потому, что объём был задан неверно с первой недели. В первую версию напихали слишком многое, бюджет кончился прежде, чем кто-либо хоть чему-то научился, и к запуску команда потратила всё, лишь чтобы добраться до стартовой черты — без денег, чтобы отреагировать на то, что реальные пользователи на самом деле делали.

Так что это руководство я даю людям прежде, чем будет написана хоть одна строка кода. Речь не об Agile-ритуалах и не о модных фреймворках. Речь об одном честном вопросе — что самое малое мы можем построить, чтобы понять, реальна ли эта идея? — и о дисциплине отвечать на него снова и снова, пока соблазн добавить «всего одну функцию» подкрадывается обратно. А он всегда подкрадывается обратно.

Что такое MVP на самом деле (и чем он не является)

Это словосочетание затёрли до блеска от частого употребления, поэтому будем точны. Минимально жизнеспособный продукт — это наименьшая версия вашей идеи, которая даёт реальную ценность реальному пользователю и учит чему-то, чего нельзя было узнать из презентации. Слово, которое забывают, — жизнеспособный. Он должен действительно работать для кого-то, от начала до конца, даже если делает лишь одно.

А вот чем MVP не является. Это не наполовину готовая версия полного продукта со сломанными углами повсюду. Это не прототип, который выбрасывают. И это уж точно не «дешёвая версия» — дешевизна это побочный эффект хорошего определения объёма, а не цель. Цель — научиться. Вы тратите как можно меньше денег, чтобы ответить на самый дорогой свой вопрос: станет ли кто-нибудь этим пользоваться и будет ли пользоваться так, как я думаю?

Это различие важнее, чем кажется. Установка «первые 20%» приводит к тому, что сломано во всех направлениях и нигде не полезно. «Одно дело, сделанное как следует» приводит к тому, что человек может взять в руки, по-настоящему использовать и составить мнение. Мнения — это весь смысл. На тишине не итерируешь.

Ловушка «построить слишком много» и почему в неё так легко угодить

Никто не намеревается раздувать объём. Это происходит по одному разумному решению за раз. Вы добавляете вход — ведь, конечно, нужны аккаунты. Аккаунты означают сценарий сброса пароля, подтверждение почты и страницу настроек. Настройки означают профиль, а это загрузку изображений, а это место для их хранения. Каждый шаг сам по себе разумен. Сложенные вместе, они стоят двух месяцев и куска бюджета — ещё до того, как часть, делающая вашу идею особенной, вообще начата.

Другая половина ловушки эмоциональна. Урезать функции ощущается как признание, что идея мелкая. Это не так — это признание, что вы пока не знаете, какие функции важны, что попросту правда. Каждая функция, которую вы строите до появления пользователей, — это ставка вслепую. Часть этих ставок окажется ошибочной, и те, что вы убрали из MVP, — самые дешёвые из возможных ставок, в которых можно ошибиться, потому что вы их так и не сделали.

Найдите единственную задачу, которую ваш MVP должен решать

У любого продукта, как бы велик он в итоге ни стал, есть основной цикл — единственная последовательность, которую пользователь повторяет и которая создаёт ценность. Для приложения бронирования это найти слот, забронировать его, получить напоминание. Для маркетплейса — выставить вещь, кто-то её находит, деньги меняют владельца. Для внутреннего инструмента — зафиксировать данные один раз, использовать их везде. Всё прочее в продукте существует, чтобы этот цикл поддерживать, украшать или расширять. Ваш MVP — это цикл. Только цикл.

Чтобы найти свой, договорите вслух эту фразу: «Пользователь приходит в мой продукт, чтобы ______, и он доволен, если ______.» Первый пропуск — задача. Второй — как вы поймёте, что сработало. Если вы не можете заполнить оба пропуска на одном дыхании, вы ещё не нашли ядро — и не готовы определять объём, тем более строить.

Будьте беспощадны к разнице между основным циклом и вещами, которые кажутся обязательными, но таковыми не являются. Вход кажется обязательным. Обычно в первой версии — нет: множество MVP запускаются с одной общей ссылкой, ручным приглашением или вовсе без аккаунтов и узнают всё нужное, прежде чем строить машинерию авторизации. Аналитические дашборды кажутся обязательными. Они не нужны; базу можно читать вручную, когда у вас одиннадцать пользователей. Обнажите продукт до цикла — и удивитесь, как много отпадает.

Разложите каждую функцию по корзинам: «надо», «следует» и «пока не»

Назвав основной цикл, возьмите большой список функций и разложите каждую по трём корзинам. Корзины намеренно грубы, потому что именно грубость прекращает бесконечные разговоры «но вдруг».

• Надо: основной цикл буквально без этого не работает. Уберите — и продукта нет. Держите этот список шокирующе коротким — обычно от трёх до шести пунктов.
• Следует: делает продукт лучше, но цикл работает и без этого. Всё отсюда ждёт второй версии. Никаких исключений в первой версии.
• Пока не: функции, которые вы сознательно решаете не строить сейчас. Записать их важно — так вы убеждаете себя и команду, что идею не бросают, а лишь выстраивают по очереди.

Хитрость, которая заставляет это работать, — третья корзина. Большинство спорят только о «надо» против «следует», что изматывает и никогда не кончается. Список «пока не» — место, где живёт облегчение: это обещание вашему будущему «я», что классная идея в безопасности и запланирована, просто не сейчас. Как только люди поверят, что ничего не выбрасывают, они перестают сражаться за то, чтобы удержать всё в первой версии.

Определяйте объём по времени и деньгам, а не по списку функций

Вот тихий сдвиг, который меняет всё: перестаньте задавать объём через «чего мы хотим» и начните через «что укладывается в бюджет и срок». Сначала решите, сколько денег и сколько недель вы готовы потратить, чтобы ответить на свой основной вопрос. Затем впишите список функций в эту коробку. Звучит задом наперёд, но это самое полезное ограничение, какое вы можете себе дать, ведь оно вынуждает к приоритизации, которой вы иначе избегали бы.

Фиксированная коробка делает и кое-что психологическое. Когда бюджет открыт, каждая функция спорна, а список только растёт. Когда коробка зафиксирована — скажем, восемь недель и заданная сумма — разговор переворачивается. Он перестаёт быть «добавим ли это?» и становится «что уходит, если это входит?» Именно второй вопрос строит хорошие MVP. Компромиссы видны, а не скрыты, и команда делает их осознанно.

Реальный пример: как мы урезали идею управления заказами

Сделаю это конкретным на примере, над которым мы работали — обезличенном, но верном тому, как всё идёт. Небольшая фирма по отоплению и сантехнике пришла к нам с желанием приложения для своей выездной бригады. Бриф на бумаге был огромен: планирование заказов в реальном времени, GPS-отслеживание фургонов, клиентский портал, автоматическое выставление счетов, учёт деталей в каждой машине, конструктор смет, фотодокументация и набор отчётов для владельца. В итоге — по-настоящему полезный продукт. Как первая версия — гарантированный способ потратить годовой бюджет, прежде чем хоть чему-то научиться.

Так что мы проделали упражнение. Мы задали владельцу фразу: «Пользователь приходит сюда, чтобы ______, и он доволен, если ______.» После некоторого обмена репликами всплыл настоящий ответ. Самой большой ежедневной болью техников было не планирование и не счета — это был бумажный круговорот. Они заканчивали работу, царапали часы и детали на листке, ехали обратно, и кто-то в офисе перепечатывал всё это в бухгалтерскую систему, часто спустя дни, часто с ошибками. Основной цикл был попросту таков: зафиксировать то, что произошло на заказе, один раз, на месте, чтобы никто не перепечатывал.

Что вошло в версию, а что нет

Всё разложили по корзинам. Корзина надо свелась к четырём вещам: список сегодняшних заказов для каждого техника, простая форма для учёта часов и использованных деталей по заказу, прикрепление фото и способ для офиса видеть эти данные в момент их отправки. Это и был весь MVP. Ни GPS, ни клиентского портала, ни конструктора смет, ни вычурных отчётов — всё это явно припарковали в списке «пока не» с пометкой, что оно на подходе.

Мы построили это ядро за несколько недель вместо большей части года. И вот часть, оправдывающая весь подход: как только оно заработало, настоящие приоритеты команды оказались не такими, как в брифе. Владелец полагал, что следующим будет GPS-отслеживание; техники едва о нём упомянули. Чего они хотели, и громко, — отправлять клиенту SMS с окном прибытия прямо из приложения, функция, которой даже не было в исходном списке. Поскольку MVP был мал и дёшев, остался бюджет построить то, что им правда было нужно, вместо того, что они угадали месяцами раньше.

Ошибки, которые тихо разрушают объём MVP

Даже команды, принявшие «держи малым», обычно спотыкаются об одни и те же несколько вещей. Ни одна из них не драматична. Это медленные течи, которые снова раздувают объём, пока вы не смотрите, пока однажды «минимальный» продукт опять не обзаведётся тридцатью экранами и полугодовым графиком.

• Золочение краёв: дни напролёт доводить до блеска админ-панель, которую увидите только вы, пока основной цикл всё ещё сырой. Полируйте то, чего касаются пользователи; бэк-офис оставьте уродливым и работающим.
• Строить под масштаб, которого у вас нет: проектировать под миллион пользователей, когда нужно доказать, что вернутся первые десять. Решайте проблему масштаба, когда у вас появится счастливая проблема масштаба.
• Путать «обязательное» с «отраслевым стандартом»: то, что у каждого конкурента есть функция X, не значит, что вашему MVP она нужна, чтобы проверить основную идею. Вы не запускаете готовый продукт, вы ставите эксперимент.
• Проектировать каждый крайний случай заранее: обрабатывать редкие, странные входные данные прежде, чем узнаете, пользуется ли кто-то обычным, нормальным путём. Пусть реальное использование подскажет, какие крайние случаи вообще реальны.
• Нет определения готовности: без записанной строки, описывающей, как выглядит «готово», разработка не кончается никогда. Расползание объёма обожает проект без финишной черты.

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

Простой процесс определения объёма вашего MVP

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

1. 1
   Назовите основной цикл

   Договорите фразу: «Пользователь приходит, чтобы сделать ___, и доволен, если ___.» Если не можете, вы не готовы определять объём — продолжайте разговор, пока не всплывёт настоящая задача.
2. 2
   Выгрузите каждую функцию, затем рассортируйте

   Выньте весь список желаний из головы на бумагу. Разложите каждый пункт по корзинам «надо», «следует» или «пока не». Список «надо» держите беспощадно коротким.
3. 3
   Зафиксируйте коробку

   Решите бюджет и срок прежде, чем доведёте список функций. Пусть список умещается в коробку, а не наоборот.
4. 4
   Напишите определение готовности

   Одна конкретная фраза, описывающая работающий основной цикл. Это ваш щит против расползания объёма до конца проекта.
5. 5
   Постройте, запустите, наблюдайте, затем решайте

   Доставьте ядро реальным пользователям. Смотрите, что они на самом деле делают. Пусть их поведение, а не ваши прежние догадки, выберет, что следующим сойдёт со списка «следует».

Заметьте, что последний шаг возвращает вас к началу. Хороший MVP — не разовое событие, а первый оборот колеса. Вы задаёте малый объём, доставляете, учитесь, и то, чему научились, заново задаёт объём следующей версии. Команды-победители — не те, кто спланировал идеальный продукт заранее, этого не делает никто. Это те, кто достаточно быстро поставил перед пользователями нечто реальное, чтобы реальность ещё могла их направить.

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