Термин MVP появился почти четверть века назад. С точки зрения технологий это огромный срок. И за это время понимание данного термина приобрело достаточно размытые границы, а область применения существенно расширилась. В этой статье я постараюсь определить границы применения MVP программного продукта исходя из современных технологий.

Сразу оговорюсь, что я рассматриваю вопрос применения MVP в первую очередь с точки зрения менеджмента и применительно только к IT продуктам.

Немного теории и истории

Я считаю, что правильно и логично при использовании какого-либо термина опираться на тот смысл и те идеи, которые вложил в них автор (В начале 2000-х Фрэнк Робинсон предложил этот подход, а позднее уже в начале 2010-х Эрик Райс популяризовал его включив в свою концепцию Lean Startup.). Как показывает мой опыт, концепция из которой возник термин MVP если и известна многим, то до конца понятна не всем.

Эрик Райс дает следующее определение: MVP - “that version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort.”

В сети можно встретить следующее определение - MVP can be considered an early development stage in any product development cycle. An MVP (Minimum Viable Product) is a product that has enough features to attract customers and use their feedback to validate a product idea.

Предлагаю провести мысленный эксперимент - давайте представим, что мы услышали определение MVP в первый раз, и проанализируем его. Уже только из определения MVP мы видим ряд особенностей по его использованию.

• MVP - это бизнес-инструмент. Т.е. это определенное бизнес-решение, но при этом он является инструментом или методикой с точки зрения создания продукта.
• Термин MVP применим только к новому продукту. Ниже я подробнее рассмотрю что может считаться таким продуктом.
• MVP - это версия продукта, которую увидят конечные клиенты, и, возможно, заплатят за нее. Т.е. это не версия для внутреннего использования, не весрсия для демонстрации инвесторам, и не версия для опробования на лояльной аудитории.
• MVP - это гипотеза, воплощенная в виде продукта. Основная цель его создания - получение информации от клиентов. Т.е. MVP - это гипотеза, подтвердить или опровергнуть которую могут конкретные цифры (KPI, которые должны быть определены заранее. О том как их определять мы поговорим в следующей части). Отсюда же следует еще один важный вывод - гипотеза может не подтвердится, и полноценный продукт никогда не будет создан.
• Для запуска MVP необходим механизм сбора и обработки информации (обратной связи) от клиентов. Это значит, что еще до начала разработки MVPмы должны четко определить, как мы будем собирать и оценивать эти данные. Без четких и понятных инструментов для сбора и обработки информации он клиентов запуск MVP теряет всякий смысл, т.к. не отвечает основной задаче его создания.

И еще две характеристики MVP, которые не следуют напрямую из определения, но не менее важны:

• MVP - это лишь часть гипотезы. Необходима еще и бизнес модель или бизнес-план. Без них оценить результаты будет просто невозможно. MVP может проверять лишь наличие рыночной ниши для продукта, но и в этом случае необходимо предварительно определить нижние пороговые значения рентабельности.
• MVP - это элемент гибкой методологии разработки. Т.е. Agile-проект без MVP может существовать, а проект с MVP без Agile теряет смысл. Следовательно, вся разработка продукта и его развитие должны проходить в рамках данной методологии.

Фактически при разговоре об MVP мы говорим не о непосредственном программном решении, а о совокупности компонентов и процессов. Корректнее бы было назвать это циклом или этапом MVP.

Составные части MVP

Говоря об MVP мы зачастую подразумеваем сервис или программу. И с точки зрения члена команды, работающего над проектом, это так. Но с точки зрения бизнеса понятие MVP немного шире, т.к. объединяет в себе ряд параметров, влияющих на успех или провал всего проекта.

• Функциональность. Это те базовые функции, которые мы предоставляем нашим пользователям.
• UI/UX. Первая точка контакта пользователя с нашим продуктом, влияющая на то, воспользуется ли пользователь предложенной ему функцией и будет ли готов пользоваться продуктом постоянно.
• Бэкофис. Не все проекты могут быть ограничены лишь существованием приложения на каком-то маркетплейсе. Зачастую необходимо обеспечить, как минимум, базовую работу службы поддержки .
• Инфраструктура. Сложно найти какой-либо IT продукт, существующий абсолютно автономно. Иногда он зависим от других сервисов и поставщиков услуг. Они тоже влияют на стабильность и качество продукта в целом.
• Рынок, как сегмент. Выбранный сегмент рынка, на который выведен продукт также влияет на его успешность.
• Ценовая политика и бизнес-модель. Выбранные начальные условия могут оказаться решающими при продвижении вашего продукта и тоже могут оказать существенное влияние на судьбу проекта.

Ошибки в понимании концепции MVP

Думаю, что почти все, кто интересовался темой MVP, видели такой или очень похожий рисунок. И, боюсь, что его автор сам не до конца понял, что же такое MVP на самом деле. Из-за этого увидевшие его могли воспринять подход неправильно. Ох уж эта сила искусства :-)

Давайте разберем его и попробуем понять, есть ли в нем ошибка.

Мы видим две интерпретации. Первая - мы создаем колесо, потом еще одно, потом добавляем кузов и потом едем. Таким образом, на первом этапе мы не получаем продукт, если конечно мы не собираемся торговать колесами, а разрабатываем наш автомобиль постепенно. И готовый продукт получаем уже на финальном этапе.

Рисунок нам не говорит, какую задачу клиента мы пытаемся решить. И колеса, и автомобили люди с успехом используют как клумбы. Возможно, мы сможет понять это из второй картинки.

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

Кажется, что эта схема прекрасно описывает MVP - с самого первого шага мы уже можем перемещаться.

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

Отдельно стоит отметить, что очень часто примеры из физического мира, используемые в статьях и презентациях, мешают воспринять информацию или идею, потому что подчиняются другим правилам и законам.

Т.е. продукт не меняется по сути и продолжает выполнять свою основную функцию, но изменяется с развитием технологий и ожиданиями покупателя. Заметим, что в данном случае MVP повозка Бенца первый был технически примитивным, но простым в управлении (по меркам того времени) и визуально привлекательным законченным продуктом.

В попытках донести идею часто использовались совсем утрированные примеры, такие как MVP в виде короткой инструкции, презентации и других подобных решений. Это примеры являются скорее исключением, и в реальности на них не стоит ориентироваться.

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

Команды также могут путать MVP, с минимальной рыночно-пригодной функцией (MMF) или минимальным рыночно-пригодным продуктом (MMP). В этом случае фокус команды смещаются с решения задач пользователя исключительно на получение прибыли, что часто приводит с снижению качества продукта и последующему провалу. Проверку этих гипотез (MVP и MMF) необходимо запускать поочередно.

FAQ

Наверное уже к этому моменту у вас накопились вопросы, касающиеся уточнения или трактовки понятий.

Что можно считать новым продуктом? Для кого-то ответ будет очевидным. Но для компаний_ предлагающих близкие решения на разных рынках и на разных платформах, дать ответ на такой вопрос будет не так-то просто. Естественно, не существует устоявшегося единого определения нового продукта. Можно свести необходимые нам характеристики к двум.

• Новизна - с точки зрения технологий либо дизайна.
• Уникальность - отсутствие на рынке прямого аналога, в том числе и с точки зрения позиционирования.

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

Всегда ли нужно начинать с MVP? Нет, это не обязательный элемент гибкой разработки, а лишь один из возможных подходов.

Должна ли нас интересовать любая обратная связь от клиентов или ограниченный набор вопросов? Нужно ли иметь список вопросов заранее? Концепция Lean Startup однозначно говорит, что да, чем четче мы формулируем вопросы тем однозначнее мы получим ответы. Стоит отметить, что кроме вопросов нам понадобится еще и сформулированная гипотеза, которую мы проверяем выпуская MVP. Дополнительная информация также важна, но лишь как дополнение.

Как систематизировать и приоритезировать полученную информацию? Lean Startup предлагает несколько инструментов, но не ограничивает вас в выборе. Естестественно все должно зависеть от специфики и возможностей вашего проекта.

Agile Alliance напрямую рекомендует в первую очередь ориентироваться на данные метрик. Как правило, первые клиенты характеризуются повышенной лояльностью к разработчикам и то, что они не скажут вам напрямую, вы сможете увидеть в данных аналитики.

Ручной сбор данных допустим, но подойдет лишь для ограниченной группы, и потребует личного общения. Такие индивидуальные интервью хороши, но стоит помнить, что для получения объективной информации вопросы должны строиться по правилам социальных опросов. Т.е. требуют определенного уровня профессиональной подготовленности интервьюера и достаточно больших трудозатрат. Т.е. затраты на такое исследование могут быть существенными и не вписаться в концепцию Lean Startup. Поэтому в первую очередь стоит обратить внимание на системы сбора и анализа данных, а также на онлайн формы опросов.

Приоритет полученной информации определяется по степени влияния на KPI проекта.

Должен ли MVP быть реализован с помощью тех же технологий, на основе которых будет создан полнофункциональный продукт? Дух Lean Startup четко указывает что нет, не должен. Но стоит помнить, что MVP может не учитывать ограничения, в том числе и связанные с масштабированием основного продукта. В то же время то, что работает как MVP, может быть нереализуемо как полноценный продукт или потребует использования принципиально других технологий. Поэтому я бы рекомендовал, там где это возможно, использовать для создания MVP те же технологические решения, что будут использоваться в дальнейшем. Это позволит как можно раньше определить проблемные места и задачи, которые придется решать в процессе реализации.

Можно ли использовать концепцию MVP отдельно от других элементов Lean Startup? Как мы видим, нет. Сам подход с использованием MVP имеет конкретную цель и предполагает использование других его компонентов.

Экономика MVP

Сколько стоит MVP?

Абсолютных значений нет. Данные по известным стартапам указывают на несколько десятков тысяч долларов. Что именно относится к этой сумме неизвестно. Как мы уже поняли, с точки зрения объема работы и необходимых специалистов - это полноценный IT проект. Продолжительность проекта зависит от того, насколько трудоемко будет реализовать идею, и как сильно вы сможете упростить, сохранив ценность для клиента.

Необходимо помнить, что до старта необходимо иметь прогноз по совокупной стоимости всего цикла MVP. В нем должны быть учтены общие затраты на создание, запуск и поддержку продукта до закрытия проекта или создания полноценной версии.

На чем можно сэкономить, а на чем нельзя?

Получается, что нам нужно создать нормальный продукт, но по существенно сниженной стоимости. Возможно ли это? Да.

На чем не экономим

• Безопасность. Редкий проект обходится без работы с какими-либо данными пользователей. Даже небольшая утечка данных может нанести непоправимый ущерб проекту.
• Функциональность. Постарайтесь определить основную функциональность, которая отражает идею продукта, и сосредоточьтесь только на ней. С остальными функциями поступите в соответствии с принципом Парето. Возьмите свой бэклог и проставьте у каждой функции два критерия - приоритет и трудозатраты относительно общего объема бэклога. Для MVP отберите 20% самых приоритетных задач, и можете дополнить их 20% самых трудоемких задач. Таким образом вы получите формальный оптимальный набор, на который нужно будет посмотреть еще раз и скорректировать, чтобы сформировать окончательный список, дающий законченную функциональность.

На чем можно сэкономить.

• Масштабируемость. Это целый комплекс технологических решений, который всегда требуем много времени и ресурсов. Спрогнозируйте максимальный масштаб проекта, по достижении пределов которого вы сможете перейти на полноценную версию.
• Дизайн (если он не является ключевой фишкой проекта). Как мы уже выяснили, дизайн является важной частью проекта, но же может предложить разные пути решения одной и той же задачи.

• Кастомизация. Это затратная область и с точки зрения UX, и с точки зрения разработки. На этом этапе от нее тоже можно отказаться.
• Капитальные вложения. Всячески избегайте каких-либо покупок или оплаты услуг на срок, превышающий прогнозируемый срок разработки MVP. Отдаваете предпочтение аренде и подпискам с ежемесячными платежами.
• Сбор статистики и аналитика данных. Здесь можно использовать возможности сторонних сервисов, например возможности Google Analytics смогут предоставить вам необходимый минимум информации с достаточной степенью достоверности. Если же по каким-то причинам вы не можете воспользоваться таким сервисом, то сконцентрируйтесь только на сборе данных необходимых для отслеживания значений KPI вашего продукта.

Подходит ли MVP для моей задачи?

Для начала нужно понять, какую конечную цель я преследую, и в зависимости от нее, принимать решение.

Если моя цель - проверить идею и минимизировать издержки при инвестировании в разработку полноценного продукта. И я, или моя команда понимаем, что результат может быть негативным и до разработки основного продукта дело так и не дойдет, то MVP нам подходит.

Могу ли я проверить гипотезу с близкой точностью за то же или меньшее время и с теми же или меньшими затратами. Если нет, то MVP - наш выбор.

И наоборот, если решение о разработке продукта не зависит от вас, или вы хотите лишь быстрее запустить его на рынок или не можете расставить приоритеты реализуемого функционала, то в этом случае MVP не ваше решение.

И последнее. Убедитесь что ваша команда способна и готова обеспечить весь цикл работы с MVP. Это не так просто, как может показаться на первый взгляд.

Итог

Подведем итог - MVP это в первую очередь бизнес инструмент, требующий навыков использования сопутствующих инструментов. Он не является обязательным, и подходит далеко не для всех проектов.

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

Как проходит цикл создания MVP на практике вы узнаете в следующей части.