Product

MVP(Minimum Viable Product) или Минимально Жизнеспособный Продукт достаточно популярный термин среди стартапов. Но мало кто знает, что даже успешный MVP может потерпеть крах, поскольку не только качество MVP влияет на успешность проекта, но и ряд других факторов.

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

Успешные примеры использования MVP

Spotify

Создатели проекта изначально разработали приложение с единственным функционалом потоковая передача музыки. Благодаря большому кол-ву пользователей, команда смогла подписать контракты с крупными лейблами и получить финансирование. Сейчас Spotify оценивается в $26.5 млрд.

Wildberries

Татьяна Бакальчук, основательница маркетплейса, начала с закупки женской одежды, затем создала сайт и запустила рекламу своего интернет магазина на платформе Passions.ru, в первый же день получила несколько заказов. Непременно на начальном этапе развития были проблемы, но это совсем другая история. Сейчас Wildberries является самым крупным маркетплейсом в России с оборотом в 223.5 млрд рублей.
К сожалению не нашел фотографии первой версии маркетплейса.

Dropbox

Проверка жизнеспособности продукта это не обязательно готовый сервис. В случае с Dropbox всё началось с демо-видео, в котором всего за 3 минуты была представлена идея. При этом, самого продукта ещё не было. Видео получило положительные оценки, миллионы просмотров, тысячи комментариев, и помогло привлечь инвесторов.

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

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

Когда рынок устоявшийся и на нем уже присутствуют игроки, которые решают данную потребность, вы не можете выйти с тем же базовым продуктом. Для примера можно вспомнить проект Basecamp для работы с проектами: какой вау-эффект был во второй половине нулевых, а теперь это никому не интересно. Сейчас клиентам нужен продукт, которым можно пользоваться. Также, Павел Дуров, выпуская продукт Telegram, запустил быструю версию WhatsApp, со всеми базовыми функциями которые были на тот момент. Он не сделал user experience хуже, чем в современных мессенджерах, которым пользовались многие люди, а это уже не MVP. Данный метод работает во многих сферах бизнеса. Вы не можете запустить MVP и сказать Ребята используйте пока так, но мы скоро допилим продукт и он будет нормальным. Только ваши друзья могут потерпеть, а клиенты запомнят какой плохой продукт и вряд ли вернутся, чтобы протестировать его еще раз после полноценного запуска. Сейчас рынку нужна хотя бы бета-версия на небольшую аудитория, либо совсем небольшой продукт без лишних фич.

Успешные проекты, которые запустились без MVP, но добились успеха:

Beru

Маркетплейс Beru.ru не запускался поэтапно, его выпустили с уже имеющимся продуктами и полезными фичами. Также, сделали крутые маркетинговые акции. Что было бы если бы это был такой же проект, как Wildberries? Или же вообще, с таким же начальным функционалом, с которым начинал Wildberries? Я думаю, проект сразу закрылся бы.

Binance.com

Когда рынок криптовалют начал набирать стремительные обороты, появилась биржа под названием Binance со штаб-квартирой в Гонконге. Благодаря удобному функционалу и доступным инструментам, биржа быстро стала популярной. Спустя 7 месяцев, на платформе было зарегистрировано более 7.5 млн человек.

Но если бы биржа пошла по пути тестирования идеи и ее презентации (как это делали другие биржи), этот рынок мог бы занять другой игрок с более удобным и мощным функционалом.

Яндекс.Такси

Когда Яндекс запустил проект с собственным таксопарком, он разработал полноценный продукт, не хуже конкурентов, которые присутствовали на тот момент. Кроме базовых функций, он смог быстрее всех подавать автомобили и тем самым вытеснил с рынка других игроков.

Zoom

Основатель Zoom Эрик Юань ушел из компании WebEx, чтобы запустить собственный продукт, напрямую конкурирующий с вчерашним работодателем. Когда запускался Zoom, на рынке уже существовали такие игроки как Skype, Google Hangouts и другие. Главным драйвером роста для Zoom были привлекательные условия с заметно лучшим качеством связи. Когда остальные продавали видеоконференции за 30-70 долларов в месяц. Zoom предложил 40 минут бесплатного общения, либо безлимит всего за 15 долларов.

MonoBank

Мобильный банк, созданный бывшими топ менеджерами ПриватБанк. Когда ребята запускали Mono Bank, они по сути создали лучшую версию ПриватБанка. Главной фишкой нового банка стал кэшбек. На данный момент, банк имеет более 1.3 млн клиентов.

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

Давайте рассмотрим примеры проектов, которые не смогли добиться успеха, так как их продукт проигрывал конкурентам по user experience.

Стартапы с хорошей идей, но с провальным MVP

Социальная сеть Аура

Когда Яндекс объявил о запуске социальной сети Аура, все побежали регистрироваться и тестировать продукт. Фишка социальной сети была в том что сервис автоматически подбирает собеседников и сообщества на основе предоставленной пользователем информации: увлечения, геолокация, лайки и т.п.

В первый месяц проект был достаточно популярным, но, со временем, люди перестали им пользоваться, т.к. социальная сеть работала только в официальном приложении от компании Яндекс. Социальная сеть не имела отдельного приложения и имела ряд проблем, которые усложняли взаимодействие с Аурой. По итогу, в августе 2020 года компания Яндекс объявила о закрытии социальной сети Аура.

Браузер Амиго

Интернет браузер Амиго от IT гиганта Mail.ru был запущен в 2011 году, но так и не добился успеха. Кроме того, что браузер не особо выделялся среди своих конкурентов, так он еще и заработал плохую репутацию за счет агрессивного маркетинга. Пользователи жаловались, что браузер устанавливается без их разрешения. Здесь та же история с user experience.

Мессенджер ICQ

Достаточно популярный мессенджер в начале нулевых со временем стал никому не нужным, т.к. на рынке появились конкуренты, которые предложили решение той же потребности с лучшим user experience и дополнительными фишками.

Flatora

Это российский аналог проекта Airbnb. Проект привлек порядка $750 000 в 2012 году, но закрылся уже в мае 2013 года. Причиной закрытия стал тот факт, что некоторые функции не работали: не было возможности проводить транзакции и ряд финансовых операций. Проект вышел на конкурентный рынок с сырым продуктом, который не смог дать пользователям сервис, решающий хотя бы те же потребности, которые решает Airbnb.

Travelmenu

Онлайн-турагентство Travelmenu получило инвестиции в размере $1.6 млн от фонда Almaz Capital и Runa Capital в мае 2011 года, но не смогло занять свою позицию на рынке и закрылось в апреле 2013. Основными конкурентами, на тот момент, были Anywayanyday и Booking.com. Главной причиной закрытия стало решение отложить выход на B2C рынок, вместо этого сервис начал с B2B.

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

Всем желаю успехов и много денег.

F5 Platform ключевой продукт Factory5 и основа для всех остальных решений компании. Она представляет самостоятельную ценность для интеграторов и делает разработку бизнес-приложений намного легче. Рассказываем подробно о функциональных особенностях Платформы и ее преимуществах для пользователя.



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

• Ожидания быстрых результатов аналитического проекта. Чаще всего это завышенные требования к CDO по разработке решения под конкретные задачи клиента. Это усложняется еще и тем, что ответственные за цифровую трансформацию подрядчики меняются.
• Большое количество данных в многообразии информационных систем. Все они могут стать хорошей основой для принятия решений, но возникают сложности с извлечением знаний из них.
• Недоступность контроля качества данных. Плохие или недостаточные данные негативно сказываются на весь дальнейший процесс, в том числе и на решение, принимаемое на основе них.
• Лоскутная автоматизация и отсутствие единой системы работы с данными. Хотя в организации автоматизированы уже многие процессы, сложность возникает когда необходимо объединить результаты работы этих разрозненных систем.

Чтобы преодолеть эти барьеры, Factory5 создали платформу, в основе которой лежат технологии и программные компоненты для эффективного сбора, обработки и хранения данных. По сути, это преднастроенный набор инструментов, позволяющий обрабатывать большие данные и сокращать трудозатраты на разработку и внедрение бизнес-приложений. Что делает решение эффективным для анализа данных?

1. Коннекторы к основным источникам

F5 Platform предназначена для сбора и обработки промышленных масштабов данных, поэтому принимает данные со основных известных источников: традиционные БД, нереляционные БД и хранилища, облачные хранилища, подключенные устройства и Historian и файловые источники. Данные поступают в платформу тремя способами:

1. Автоматически с датчиков в режиме реального времени.
   Если оборудование оснащено датчиками, передающими телеметрию в режиме реального времени, то через коннекторы она поступает на платформу в режиме реального времени. Также данные могут приходить на сервер ОPC, который является стандартом для обмена данными между промышленным оборудованием и информационными системами.
2. Вручную из файлов.
   Данные копятся на оборудовании, а когда оборудование готово для передачи этих данных, файлы вручную с помощью флешек переносятся в платформу.
3. Из внешних систем без ручного участия.
   Платформа интегрируется с внешними системами типа 1С, Галактики EPR. Поэтому данные поступают из внешних систем с использованием REST API запросов или выгружаются, предоставляя REST API для внешних систем.

Это позволяет использовать весь массив данных, циркулирующих в компании. А встроенные в Платформу коннекторы позволяют не тратить время на их разработку и ускоряют процесс работы над данными.

2. Сервис разметки данных

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

Например, приходят данные о температуре с датчика на двигателе. Благодаря созданному двойнику их можно записать в базу данных как датчик 123 передает параметр Х. Для того чтобы можно было писать правила, остается объяснить системе что датчик 123 это датчик на двигателе, а параметр Х это температура. После этого можно будет писать правила вида если температура больше 50 то....

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

3. Сервис создания и библиотека экспертных правил

Для анализа данных используются экспертные правила. F5 Platform дает возможность написания собственных правил на простом языке, понятном инженерам Domain Specific Language. Для этого не нужно знать язык программирования.

Кроме этого, в Платформе есть библиотека экспертных правил для промышленного оборудования, которая содержит около 2 000 заранее написанных правил.

4. МХ-редактор и библиотека математических моделей

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

5. Микросервисная архитектура

Каждый функциональный модуль F5 Platform выделен в самостоятельный сервис, который расположен в своем контейнере, никак не связанном с другими. В контейнерах содержится все, что нужно для работы приложения. Каждый контейнер изолирован и является безопасной основой для сервисов Платформы.

Экспертные правила и математические модели как раз являются такими сервисами. Кроме них есть сервис построения кубов, отчетов, pipeline-менеджер и сервис управления правами пользователей. Микросервисная архитектура F5 Platform позволяет обновлять сервисы в случае их доработки, не трогая остальные. Это упрощает управление Платформой.

6. Масштабирование вычислительных мощностей

На базе архитектуры Платформы есть возможность увеличивать вычислительную мощность под фактические потребности. Это свойства горизонтального масштабирования: идет равномерная загрузка серверов приложений, есть возможность подключать дополнительные сервера, а также распределить данные по разным серверам. Это обеспечивает высокую производительность системы и не приводит к снижению отказоустойчивости.

7. Преднастроенный набор инструментов для создания бизнес-приложений

В F5 Platform собраны и заранее настроены все инструменты для сбора и анализа данных, а также визуализации отчетов:

• коннекторы к различным СУБД: PostgreSQL, ClickHouse;
• коннекторы к промышленным протоколам: OPC-UA, REST API;
• Pipeline Manager для настройки и выполнения произвольных сценариев обработки/анализа данных;
• сервис экспертных правил;
• сервис математических моделей;
• различные виджеты для представления информации;
• конструктор и дизайнер отчетов.

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

Привет!

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

Для всех кто готов мирится с сыроватостью идеи, добро пожаловать под кат)

Введение

Задача определения функциональности MVP появляется еще на этапе планирования разработки продукта и требует обновленного решения по мере развития продукта, вплоть до окончания разработки MVP.

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

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

Критерии

Критериями для задачи определения MVP функциональности являются критерии, взятые из методологии WSJF а также дополнительная декомпозиция Job Duration на составляющие:

Cost of delay

• User-Business Value: Насколько громко просят об это пользователи? Как это отразится в деньгах, если эта штука НЕ будет сделана? Какой потенциально негативный эффект будет, если это выполнить позже, а не раньше?
• Time Criticality: Как это влияет на общий поток поставки? Задерживает ли реализацию чего-то еще? Нужно ли это выпустить к определенной дате? Есть ли риск того, что опоздание с этим умножит на ноль весь смысл проделанной работы?
• Risk Reduction: Снижает ли это какие-то риски? Будет ли это позитивно влиять на качество в других областях? Будет ли эффект сиюминутным или долгосрочным?
• Opportunity Enablement: Откроет ли эта штука новые возможности для продукта или всего бизнеса? Поможет ли выйти на новые рынки сбыта/привлечь других клиентов?

Job Duration

• Job Duration Оценка времени на реализацию, производится по предварительному анализу Features с участием Тех Лидера команды разработки или Архитектора. Выполняется верхнеуровнево, без декомпозиции Features на более низкие уровни
• Job Complexity- Оценка сложности реализации, выполняется совместно с Тим Лидером команды разработки индивидуально, с учетом опыта и навыков команды, которая работает над данным продуктом. Данная оценка также включает в себя оценку степени неопределенности Features, которая в свою очередь прямо пропорционально влияет на сложность этих самых Features.
• Job Cost Оценка стоимости реализации, высчитывается исходя из необходимых человеко-часов на определенную задачу, и перемножения его на стоимость человеко-часа в команде. Данная оценка является относительной и не подлежит для использования в расчетах стоимости реализации продукта, и нужна только для приоритизации бэклога.

Процесс оценки

Оценка выполняется с помощью числового ряда Фиббоначи от 1 до 21. (1, 3, 5, 8, 13, 21). Данный способ оценки универсален с точки зрения использования его при оценке задач в Story Points при планировании, и для групповой оценки критериев также возможно использования Scrum-poker.

Также, оценка с помощью ряда Фиббоначи обусловлена тем, что каждый шаг значений увеличивается не линейно, а значит будет сложнее сложить все в одну оценку. Так же чувствуется разброс, например сразу видна разница в бизнес ценности между задачей в 3 и 21 Story Points.
Оценки по критериям из группы Jobs Duration выполняются командой разработки, а оценки по группе критериев Cost Of Delay только с привлечение бизнес-заказчика и Владельца Продукта.

Итогом оценки будет матрица следующего вида:

Сведение задачи определения MVP к решению задачи многокритериальной оптимизации.

Многокритериальная оптимизация, или программирование (англ. Multi-objective optimization) это процесс одновременной оптимизации двух или более конфликтующих целевых функций в заданной области определения. Наиболее простым способом решения задачи многокритериальной оптимизации является метод Свертывание критериев, для сведения многокритериальной оптимизации к однокритериальной. Метод свертывания критериев предполагает преобразование набора имеющихся частных критериев в один суперкритерий. Т. е. мы получаем новый суперкритерий, который является функцией от частных критериев.

Для свертывания критериев в суперкритерий необходимо также проставить весовые коэффициенты:

Для бизнес критериев и критериев разработки необходимо устанавливать отдельные весовые коэффициенты.

Таким образом свертывание критериев будет выглядеть следующим образом:

Cost Of Delay = User-Business Valuek11+ Time Criticalityk12+ Risk Reductionk13+ Opportunity Enablementk14
Jobs Duration = Job Durationk21+ Job Complexityk22+ Job Cost*k23
K11+K12+K13+K14=1
K21+K22+K23=1
Общий критерий оптимизации (Mutual Criteria) = Cost of Delay/Jobs Duration.

Таким образом мы получаем матрицу следующего вида:

Итоговой целевой функцией является Максимизация по Mutual Criteria.

Определение MVP Функциональности с помощью ABC анализа.

ABC-анализ метод, позволяющий классифицировать задачи по степени их важности. Этот анализ является одним из методов рационализации и может применяться в сфере деятельности любого предприятия. В его основе лежит принцип Парето 20 % всех усилий дают 80 % результата. По отношению к ABC-анализу правило Парето может прозвучать так: 20% функциональности позволяет покрыть 80 % потребностей пользователей.

ABC-анализ анализ бэклога (набора Features) путём деления на три категории:

А наиболее ценные, 20% от количества; 80% удовлетворения потребностей
В промежуточные, 30% от количества; 15% удовлетворения потребностей
С наименее ценные, 50% от количества; 5% удовлетворения потребностей

Группа А является группой функциональности входящей в MVP.

По сути, ABC-анализ это ранжирование бэклога по разным параметрам. Результатом АВС анализа является группировка объектов по степени влияния на общий результат.

АВС-анализ основывается на принципе дисбаланса, при проведении которого строится график зависимости совокупного эффекта от количества элементов. Такой график называется кривой Парето, кривой Лоренца или ABC-кривой. Таким образом, 20% функциональности, закрывают 80% потребностей. Исходя из данного принципа, производим АВС анализ для бэклога, для определения MVP.

Для этого:

1. Определяем цель анализа Ранжирование Бэклога для определения первых 20% функциональности, из которой будет сформирован MVP.
2. Объект анализа Набор Features из бэклога.
3. Берем перечень функциональности, ранжированный по многокритериальной модели (MC).
4. Разделяем ранжир на 2 класса первые 20% (A), оставшиеся 80% (B+C).
5. Первый класс (A) определяет MVP.

Важное замечание: Необходимо также учитывать CORE функциональность. Группа А может совпадать c CORE, но в случае не совпадения, результаты АВС анализа должны быть дополнены Core функциональностью.

CORE функциональность это основа функционирования продукта, которая состоит из функциональности, без которой функционирование продукта невозможно. (Например, авторизации).

Выводы

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