Не равняйтесь на Airbnb и Uber — это ловушка. Как придумать свою фишку

Кирилл Гришанин

Партнер WB—Tech

Расскажите друзьям
Виктория Кравченко
Кирилл Гришанин

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

Кирилл Гришанин, партнер WB—Tech, занимается аутсорс разработкой для начинающих стартапов. Он постоянно сталкивается с подобными историями, вот почему решил рассказать, как сделать первый шаг и не потерять свою фишку.

Споры-споры

Гуру русской Темной стороны, многоуважаемый (без шуток) Морейнис [Аркадий Морейнис — прим. Rusbase] недавно посвятил отдельный пост рассужению о разнице прототипа и MVP. По его версии, MVP — это лендинг, предлагающий купить продукт, которого на самом деле еще нет. Он призван определить уровень потребности в продукте. Получается, что MVP — это процесс тестирования идеи, а не тестирования продукта.

На wiki же этому термину посвящена отдельная страница, где написано, что MVP — в первую очередь все-таки продукт, а не процесс (что логично, ведь последняя буква в термине и означает Product). Как вы поняли, разница трактовок присутствует и серьезная.

Не ради академического интереса, а для пользы стартаперов (они и без того много страдают), давайте попробуем разобраться, что же такое этот загадочный MVP. [Мы тоже задавались этим вопросом и выяснили это здесь — прим. Rusbase].

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

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

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


Стартапер не понимает

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

Никто не скажет ему: «Делай раз. Делай два. Делай три. Проект готов!» — это невозможно. Сталкиваясь с понятием MVP, он думает: «О, пожалуй, надо начать с ограниченного набора фич, а не делать все, что я задумал сразу».

Отлично! Но как составить набор фич, когда ты ни разу ничего такого не делал? Как декомпозировать большую-большую задачу на мелкие, когда ты ни разу не занимался разработкой?

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

Разумеется, чаще всего приводят в пример крутые сервисы, забывая посмотреть их длинные таймлайны в Кранчбейсе. В итоге получается, что фаундер, глядя на фишки Uber или Airbnb, пытается собрать свой первый сайт.

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


Устраняем фишки

Я не буду рассматривать такой критерий, как бюджет. Думаю, и без меня всем ясно: чем меньше фич — тем дешевле.

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

Цель этого упражнения — ответить на следующий вопрос: действительно ли вы сможете обеспечить такой бизнес-процесс?

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

Пример 1

Недавно к нам пришел агрегатор поставщиков сложной туристической услуги. Разумеется, что изначально задача звучала как: «Хочу быть booking.com для моей туристической услуги. Хочу, чтобы был личный кабинет поставщика и личный кабинет покупателя. И чтобы поставщики сами могли заносить информацию о себе и бла-бла-бла».

В данной ситуации помогло такое упражнение: а что собственно будет в ЛК поставщика? Стали разбираться и выяснилось, что пока нет четкого понимания, что же именно там будет, да и нет столько поставщиков, готовых самостоятельно вбивать данные. В релизе мы ограничились тем, что сделали роль «Поставщик» в админке сервиса и написали инструкцию по ее заполнению.

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

Пример 2

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

Если включать по-настоящему ненужные фичи в скоуп, то своим наличием они запутывают фаундера, помешают увидеть суть проблем, то есть наносят двойной урон проекту:

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

Итог: нужно постараться убрать все, что можно убрать, оставив лишь самую суть и работать именно с ней.


Добавляем фишки

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

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

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

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


Есть у этого и обратная сторона

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

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

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


Выводы

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

Если у него такой уверенности нет, то как он приведет на такой сервис клиентов? Ведь он не знает, что им сказать, а значит ни сам сервис не нужен, ни его MVP.

  • Чтобы распорядиться ресурсами времени и денег рационально, необходимо расписать бизнес-процесс настолько подробно насколько это возможно. Это поможет выявить те звенья, которые потребуют автоматизации.
  • Обязательно надо попробовать от чего-то отказаться. Постараться не смотреть Uber и Airbnb или смотреть на них, открыв в соседней вкладке Кранчбейс, где будет указано, сколько именно сотен миллионов долларов было в них вложено спустя столько-то лет с первого запуска. Так вы получите бизнес-логику будущего сервиса.
  • Затем вам надо понять, какие данные нужны от ваших пользователей, чтобы созданная бизнес-логика смогла работать. Так можно будет составить список возможностей сервиса. Обязательно нужно проверить список на предмет лишних функций: по каждой возможности задайте себе вопрос «Что я потеряю, если уберу эту фичу».

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

Если у вас есть что добавить по теме, давайте обсуждать в комментариях!


Материалы по теме:

MVP — это не прототип. Прототип нельзя продавать, а MVP — можно

14 венчурных фондов, где можно получить деньги

Что такое MVP? И когда надо начинать делать реальный продукт?

85 важных уроков, которые я извлек на посту директора компании

Эти сигналы говорят о том, что вами манипулируют — подсказка от мастера переговоров

6 признаков того, что у вас хорошее стратегическое видение



Комментарии

  • ZapevalovAnton 08:03, 8.02.2017
    0
    MVP - Minimum Viable Product
  • Asker Askerov 21:04, 12.02.2017
    1
    • Гришанин Кирилл Гришанин Кирилл
    Добротная статья. НО! У меня название, ну совсем не стыкуется с проблематикой. Пришлось додумывать. Хотелось бы более развернутую статью. Для меня проблема актуальная. Основной алгоритм понятен. Можете дать контакты специалиста, от чьего имени описывались кейсы?
  • Гришанин Кирилл
    Asker Askerov Гришанин Кирилл 22:34, 28.07.2017
    0
    Аскер, привет, от моего имени, пишите на ask@wbtech.pro
Комментарии могут оставлять только авторизованные пользователи.
Web Summit 2017
6 ноября 2017
Ещё события


Telegram канал @rusbase