Разработка mvp что это
Секрет успешных стартапов. Minimum Viable Product: что это, и как его создают
MVP — это не только лучший игрок в команде (most valuable player). В сфере стартапов это ещё и минимально жизнеспособный продукт (minimum viable product). Сервис, обладающий достаточными качествами для того, чтобы привлечь первых пользователей.
Это очень важно в условиях, например, стартапа — для получения обратной связи и понимания того, в какую сторону стоит двигаться (и стоит ли двигаться вообще, или лучше похоронить идею).
Сбор информации через MVP — обходится намного дешевле, чем разработка полноценного продукта с большим набором функций. MVP позволяет во много раз снизить затраты и риски, и, при грамотном подходе, в итоге выйти на бизнес-идею, которая работает.
Для примера, возьмем онлайн-планировщик. Сразу мечтать о создании конкурента ToDoist или Trello — нет смысла. На такое не хватит никакого бюджета, и даже с неограниченными финансами (см. Google) победа не обеспечена. Поэтому в соответствии с теорией MVP-тестирования нужно создать основу, «костяк» продукта. Например, простой сервис, способный записывать новые задачи и отмечать их как сделанные, с тегами, возможностью фильтрации и выставления приоритетов.
Когда хорошие стартапы задумываются о выпуске планировщика, они обычно начинают с этого короткого списка. А дальше всё зависит от дизайна, маркетинга и пары-тройки выделяющихся функций. Если пользователям понравится — можно развивать идею, добавлять возможности и постепенно становиться одним из главных игроков. Если MVP себя оправдал.
Термин «минимально жизнеспособный продукт» был придуман Фрэнком Робинсом в 2001 году. И популяризован Эриком Рисом, который в 2009-м в деталях описал его в своём бестселлере Lean Startup (на русский его перевели как «Бизнес с нуля»).
Как видим, концепт родился сравнительно недавно. В России о том, что такое МВП, и о его принципах почти не знают. К большому сожалению, у нас больше укрепились модели «выйдем и сразу всё захватим!», где компании прожигают сотни миллионов, стараясь сразу стать монополистом. А также модели «Яндекса», Mail.ru и «Сколково», когда новые идеи подводят под технологические цепочки существующих крупных компаний. Мы в Rubrain занимаемся разработкой MVP для стартапов из США и Британии уже около пяти лет, и знаем, что если у вас мало денег (и они свои) — это единственный путь к созданию успешного проекта.
Почти все успешные стартапы на Западе начинают свой путь к успеху с минимально жизнеспособного продукта. Это наименее опасный и затратный подход, об этом хорошо знают жители Кремниевой долины. Другой вариант — «откол» проекта от более крупной компании, или разработка большого продукта после привлечения солидных инвестиций (зачастую — от сооснователей).
Но всё же большая часть известных в США и Европе стартапов начинали с простой версии MVP, которая позволила им протестировать рынок, набрать базу клиентов, освоиться, доказать инвесторам свою идею, а потом — начать добавлять в продукт новые функции и продолжить развивать успех.
Вот пять характерных примеров:
MVP отличается от раннего релиза проекта с открытым исходным кодом, поскольку релиз учитывает потребности и предпочтения пользователей, но не рассчитан на то, чтобы они напрямую определяли направление развития продукта. Видение проекта зачастую уже существует, и оно будет поддерживаться на протяжении всего жизненного цикла, несмотря на наличие прямой и косвенной обратной связи. MVP призван проверить потребность рынка, а если её нет — попробовать её создать. До вложения большого количества денег и времени.
Dropbox стал одним из характерных примеров MVP
Стив Бланк считает, что стратегия создания минимально жизнеспособного продукта может быть использована как часть методологии custdev (развития клиента). Это один из принципов движения «Бережливый стартап». Ученик Бланка Эрик Рис и сделал MVP частью дискуссии в кругах Кремниевой долины. Это самая успешная стратегия быстрого тестирования идей, получения обратной связи с клиентами и выбора жизнеспособной бизнес-модели.
Кстати, стратегию можно сделать ещё успешнее, если представлять аудитории несуществующие продукты и функции, и проверять свои гипотезы путём A/B-тестирования среди веб-пользователей. В основном стартапы, с которыми сотрудничает Rubrain, до обращения к нам именно так и поступали. А потом приходили к нам с уже оформленным планом: какие возможности должен содержать их MVP, и какие функции (скорее всего) нужно будет добавлять в их сервис или программу по мере получения одобрения от рынка.
Конечно, минимальный жизнеспособный продукт имеет свои недостатки. Первый, очевидный — срезание углов не в тех местах. Конечно, целью является создание сервиса с минимумом затрат, и только самыми ключевыми функциями. Но некоторых затрат всё равно не избежать. А некоторые вещи урезать нельзя.
В первую очередь это касается пользовательского опыта. Хороший UX — вещь обязательная. Без него весь MVP может показывать, что проект «не взлетает» и не оправдывает ожиданий аудитории. В то время как проблема состоит только в UX, а весь остальной продукт работает вполне достойно.
Другая проблема MVP — состоит даже не в таком продукте, а в подходе, который иногда с ним ассоциируют. Рид Хоффман, основатель LinkedIn, как-то сказал: «Запуститесь так рано, чтобы вы были опозорены своим 1.0 релизом». Конечно, он имел в виду, что это потом заставит вас работать сильнее. Но такая стратегия приносит больше вреда и компании, и её пользователям. MVP — это, наоборот, продукт, за который не стыдно. Пусть по нему видно, что он бюджетный, но он показывает потенциал. И не отталкивает, а привлекает аудиторию.
Мы в Rubrain не раз замечали, что для многих команд главная проблема с разработкой MVP заключается даже не в самом проекте, а в отношении к нему. Они используют не тот подход. Идея MVP в том, чтобы это был процесс создания крутого продукта. Первый жёлтый кирпичик по дороге в Изумрудный город. Вместо этого разработчики рассматривают MVP как отдельную цельную вещь, и не уделяют должного внимания сбору данных или анализу аудитории. Которые потом позволили бы скорректировать продукт и сделать его успешным. Они выпускают такие MVP, которые скорее похожи на прототипы или концепты. И слишком сосредоточены на своей изначальной идее, даже если рынок намекает на её несостоятельность.
Из-за ловушек сознания, к которым иногда может привести MVP, в последние годы появилась другая идея. Некоторые стартапы теперь ставят своей целью не Minimum Viable Product, а Minimum Valuable Product (MVaP). Минимальный ценный продукт. Так становится проще напоминать себе и команде, что задача — не выпуск какой угодно вещи при низких затратах. А создание продукта, который несёт в себе какую-то ценность для пользователей. И позволит вам набрать изначальную аудиторию, поведение которой потом можно будет анализировать.
MVaP ставит в приоритет своих пользователей, их потребности и ожидания. Проводит исследования, анализирует юзабилити, оценивает демографию, создает use cases. Всё с целью определения наилучших способов для удовлетворения запросов потенциальных клиентов.
Обычно есть несколько разных идей о том, как лучше достигнуть этой задачи. Здесь на помощь приходит тестирование прототипов. Функциональные прототипы представляются реальным пользователям, чтобы увидеть, какой вариант устроит их лучше всего. Это важный шаг в создании MVaP.
Но минимально ценный продукт должен приносить пользу не только клиентам. Он создаёт ценность и для самого проекта. Как и MVP, он обязан уметь извлекать полезную информацию о том, как продукт воспринимается рынком.
Ценность с MVaP также создаётся для бизнеса в целом. Один из рисков выпуска MVP, минимально жизнеспособных продуктов, — в том, что они могут плохо отразиться на бренде (если сделать это неаккуратно и представить «сырой» вариант). Крупная компания, от которой пользователи ждут определенного уровня, позволить себе такого не может. Поэтому для её лучше выбирать более безопасный путь — MVaP. Такой продукт часто стоит дороже в разработке, зато он гарантированно несёт в себе ценность, и позитивно влияет на имидж бренда, который он представляет. По этой стратегии с нашими программистами сейчас сотрудничают «Яндекс» и Mail.ru.
Если вы не крупная компания, и создаете буквально один из своих первых сервисов, концепт простого MVP для вас вполне подходит.
Для начала нужно определить проблему, которую продукт будет решать. И создать проект с минимальным набором функций, решающих эту проблему. А дальше — начинать учиться понимать пользователей, и улучшать свой продукт в соответствии с реальными требованиями рынка.
Идея в том, чтобы сервис проверил ваши основные предположения. Может ли это быть чем-то, чем люди интересуются? Если да, то дальше стартап может развивать свою деятельность: набирать команду, искать финансирование.
Итак, по шагам, нужно:
Раньше, на «Диком Западе» интернета, всё было попроще. Но сейчас успех стратегии MVP во многом зависит от продуманного бизнес-плана. В США для этого сейчас любят использовать канву бизнес-модели. Этот полезный инструмент был предложен в 2005 году Александром Остервальдером, швейцарским предпринимателем и бизнес-теоретиком. Почитать о нём подробнее можно в интернете, для этого есть десятки специализированных сайтов. Но если вкратце, такая канва позволяет на одной странице описать все основные бизнес-процессы компании. В том числе:
Канва бизнес-модели — простой способ прийти к тому, как должен выглядеть ваш минимально жизнеспособный продукт. В ней есть все модули, необходимые для формирования общей стратегии.
Главное — это позволяет лучше понять, на каких функциях сосредоточиться, в чём основная цель продукта, и что будет отличать его от конкурентов.
Взять, к примеру, первый iPhone. Все телефоны в то время имели ряд функций, которые Apple специально не включила в свой девайс. В нём не было функции копирования и вставки (!), не было SDK, не было 3G-связи. Даже нельзя было отправлять текстовые сообщения сразу нескольким контактам.
Но Стив Джобс знал, на чём сосредоточиться. Он представил MVP, минимально жизнеспособный продукт. С мультитачем и большим экраном. В нём были ровно те основные возможности, которые выделяли его на фоне остального рынка. На отсутствии привычных фич специально не заостряли внимание — ни публики, ни разработчиков. Аудитория этот MVP, как показывает история, приняла, и теперь, на двенадцатой итерации, в смартфоне есть все недостающие функции, и даже более того.
Если вы пока что не Стив Джобс, есть некоторые полезные сервисы для начала работы над своим первым минимально жизнеспособным продуктом:
Можно обратиться к опытной компании, предлагающей свои услуги по разработки MVP для стартапов. У неё должно хватать дизайнеров и программистов с опытом в этой сфере. Заказчики с идеей и определенным количеством денег сейчас обычно так и делают. Не обязательно искать разработчиков, решать легальные вопросы, с нуля создавать команду. Если есть хорошая идея и вариант её продвижения — найдется достаточно опытных фирм, которые возьмутся за работу за вас. Это будет намного дешевле, чем начинать с нуля, а временные затраты несопоставимы.
В следующем материале расскажем о примерах крутых идей для MVP, которые позволили основателям компаний почти из ничего создать бизнесы на несколько миллиардов.
Начинаем с малого: что такое MVP и как это работает?
MVP (от англ. Minimum Viable Product, «минимально жизнеспособный продукт») — это начальный вариант продукта с минимальным набором функций, который разрабатывается для проверки гипотез. С помощью обратной связи можно понять, как развивать проект дальше и какие еще опции в него добавить.
Именно с MVP следует начинать создание digital-продукта. Это поможет уменьшить время, а также снизить затраты и риски на разработку продукта. Например, если ваша цель — сделать интернет-магазин, нужно выбрать для него самые необходимые функции. Именно они войдут в первую версию проекта.
Порядок разработки MVP зависит от различных переменных: вида продукта, ресурсов команды, ситуации на рынке и многих других. Но, даже не зная всех вводных, можно разделить процесс на этапы, которые необходимо пройти.
Когда вы определитесь, какую задачу должен решать конечный продукт, вам будет легче выбрать его необходимые функции. Именно они станут основой MVP.
На этом этапе вам необходимо максимально сузить целевую аудиторию. Именно она сможет дать ту обратную связь о MVP, которая поможет усовершенствовать его впоследствии. Ориентируйтесь на базовые критерии: возраст, пол, семейное положение и интересы клиента. Чем подробнее будет описание клиента, тем проще будет на этапе создания продукта.
Опыт других поможет понять, какие опции действительно нужны пользователям. Допустим, вы собираетесь создать мобильное приложение: изучите варианты, которые есть на рынке, какие функции в них встречаются чаще всего. Нужно ли добавлять в него авторизацию через СМС? Если это реализовано у многих других конкурентов, то стоит подумать над этой опцией.
Постройте customer journey map — историю взаимодействия пользователя с вашим продуктом. Путь не должен быть длинным и содержать множество шагов: добавляйте только необходимое. Например, если конечная цель вашего сайта — это продажа товаров, не превращайте процесс покупки в долгий квест с препятствиями.
Настало время выбрать необходимые опции для своего проекта. Делайте это на основе проведенного анализа и не добавляйте слишком много фич в начальный продукт. Их можно будет реализовать на следующих этапах, когда протестируете начальную версию продукта.
Есть разные подходы к созданию минимально жизнеспособного продукта. Выберите тот, который подходит вашей команде больше остальных.
Когда первая версия продукта готова, перейдите к ее тестированию. Его процесс зависит от подхода к MVP, который вы выбрали. Но даже при различиях в этапах главная цель тестирования — сбор мнений о проекте от реальной аудитории. Именно она поможет вам исправить недочеты и усовершенствовать продукт.
Создание MVP требует времени и ресурсов, но именно оно поможет избежать рисков и обезопасить себя при создании нового продукта. Поэтому мы в ITFactory помогаем клиентам определиться, какой функционал необходим сервисам и на какой стадии его внедрять.
Что такое и зачем нужен MVP
Мы часто говорим об MVP (minimum viable product) когда речь заходит о разработке. О том, что это минимально жизнеспособный продукт знают многие. Но мы решили еще шире раскрыть это понятие и подробно рассказать о значении MVP в процессе создания новых продуктов.
Представим, что у вас есть идея — приложение с полным набором функций и опций, доступное на всех платформах, способное обслуживать миллионы пользователей по всему миру. Отлично!
А теперь давайте переведем разговор в более приземленную плоскость и сделаем вид, что идея вашего приложения — это эклер. Но не просто пирожное, а экстра-эклер в форме таксы, заправленный кремом на основе альпийского масла, со взбитыми сливками и посыпкой из трех видов шоколада. Это вкусный, привлекательный и очень сложный продукт. А еще непонятно, нужен ли он людям.
Здесь-то и пригодится MVP, чтобы проверить идеи. Самая первая версия вашего приложения должна быть больше похожа на простой эклер — тот, что люди знают, любят и хотят попробовать от нового поставщика. MVP приложения должны быть включены только основные функции. Когда будет готов программный продукт, с ним можно познакомить пользователей. Такое решение будет относительно дешевым и быстрым в разработке.
Форма MVP и конечного продукта зависит от технологии разработки. Это могут быть нативные или кроссплатформенные решения, о таком выборе мы уже писали в нашем блоге, загляните.
В любом случае стоит проконсультироваться с разработчиками, с которыми вы решили сотрудничать. Они дадут информацию о сроках, затратах, размере команды и, возможно, предложат новые решения. Например, вместо создания мобильного приложения вы можете начать с PWA (прогрессивное веб-приложение) и собирать отзывы от первых пользователей, прежде чем тратить ресурсы на реальный продукт.
С живым приложением вы можете продолжить разработку, основываясь на фактах, а не на предположениях. Реальные пользователи протестируют продукт и дадут обратную связь: расскажут, что им не понравилось, а что нужно добавить.
Благодаря отзывам вы узнаете, как поживает ваш «обычный эклер» и получите дополнительную информацию о том, как его можно улучшить. Если никто не просит оригинальную форму таксы, возможно, пока нет смысла вкладывать средства в ее разработку.
Подход MVP дает хорошее представление о будущих потребностях в развитии продукта. Вы можете продолжать добавлять сливки и посыпать эклер. Но что, если продукт станет настолько популярным, что люди захотят его повсюду, а не только в одной кондитерской? Тогда будет актуальней задуматься о масштабировании.
Мобильное приложение будет иметь ограничения на количество пользователей, которые оно может обслуживать, не засоряя сервер. У него также есть географические ограничения — язык или страны, в которых оно доступно. Имея данные об использовании приложения, вы теперь можете расставить приоритеты, что делать дальше: совершенствовать рецепт или открывать новые кондитерские.
Причина номер один. Минимально жизнеспособный продукт становится упрощением большого проекта и позволяет узнать, чего хотят пользователи. Становятся очевидны потребности рынка и функции, имеющие решающее значение для успеха продукта. Это идеальный способ проверить предположения и получить четкое представление о пути, по которому должен идти проект.
Причина номер два. Стартапам получить инвестирование с помощью MVP проще, потому что есть прямая презентация действующего мобильного приложения. Это демонстрирует серьезность намерений и укрепляет позиции.
Причина номер три. MVP дает возможность узнать, как компоненты UX и UI способствуют удобству использования и интуитивности мобильного приложения.
Причина номер четыре. MVP также является отличной стратегией для проверки идей монетизации. Гипотезы для заработка лучше протестировать с помощью MVP и определить, какая из них принесет наибольшую прибыль.
Причина номер пять. С помощью MVP можно быстрее выйти на рынок и по-прежнему иметь достаточно пространства для изменений.
Минимальный жизнеспособный продукт дает возможность стать лучше: вы сможете вносить существенные изменения в бизнес-процессы, основываясь на реальном пользовательском опыте. Можно отложить разработку менее важных функций и потратить деньги на срочные задачи.
Предположим, у вашего эклера есть серьезный недостаток, например, плохое качество муки. В таком случае это будет важнее исправить, чем добавлять новые фичи и еще больше усложнять ситуацию.
MVP — это перспективный путь реализации идей с опорой на потребности пользователей и требования владельца.
Если убрать демагогию и манипуляцию с сознанием заказчика, то придется вместо:
«что идея вашего приложения — это эклер. Но не просто пирожное, а экстра-эклер в форме таксы, заправленный кремом на основе альпийского масла, со взбитыми сливками и посыпкой из трех видов шоколада. Это вкусный, привлекательный и очень сложный продукт. А еще непонятно, нужен ли он людям.»
написать:
«что идея вашего приложения — это небоскреб. И не просто небоскреб, а 200-этажный небоскреб в форме летящей чайки и прозрачный после 115-го этажа. Это очень сложный продукт. А еще непонятно, нужен ли он людям. «
Поэтому давайте очень быстро из говна и палок построим сарайчик дачного типа, и расскажем заказчику, что строя сарайчик мы поняли, из КАК и из КАКИХ МАТЕРИАЛОВ строить небоскреб. ))) Идеи в статье применимы, если инфоцыганам нужно тестировать две гипотезы в неделю на маркет фит, или если нужно сделать одностраничник для кофейни. Для чего-то посложнее нужен архитектор, исследование и бэкенд, где сосредоточено 80% системы.
MVP: как создать минимально жизнеспособный продукт
Создание минимально-жизнеспособного продукта — MVP — помогает бизнесу снизить риски при разработке нового продукта и проверить его востребованность. В статье рассказали, как сделать и запустить MVP
Владислав Мокроусов
Представьте: вы потратили много времени на разработку продукта, учли все детали и запустили его на рынок. Но уже в первую неделю после запуска вы понимаете, что продукт не попадает в целевую аудиторию, новые клиенты быстро уходят, а расходы продолжают увеличиваться.
Запуск MVP позволяет избежать этих проблем и предусмотреть возможные решения. Рассказываем, что такое минимально жизнеспособный продукт и как его внедрять.
Что такое MVP
MVP — Minimum Viable Product — ранняя версия будущего проекта, которая позволяет при минимальных затратах собрать максимум практических данных о том, как с продуктом взаимодействуют клиенты.
Компания запускает сервис для совместного поиска жилья и планирует выпустить его на рынок. Она создает одностраничный сайт и предоставляет доступ к нему пользователям. Проектная команда наблюдает за поведением клиентов, обрабатывает информацию, анализирует реакцию, делает необходимые изменения и адаптирует продукт под потребности аудитории.
Создание MVP позволяет протестировать продукт на практике и проанализировать результаты. Это выгодно, когда вы запускаете стартап и хотите понять, в какую сторону лучше развиваться, намерены снизить затраты или не уверены в эффективности бизнес-идеи. MVP применяется для создания любого продукта, но чаще используется в ИТ для разработки программного обеспечения и цифровых сервисов.
Как запуск MVP ускорил развитие WhatsApp
С чего все началось. В мессенджере WhatsApp на момент публикации не было функций для отправки сообщений. Создатели WhatsApp хотели создать мобильную телефонную книгу, которая бы показывала статус контакта: доступен, занят, на совещании, за рулем, в спортзале. Когда пользователи указывали статус, их контакты получали всплывающее уведомление.
Что сделали. Разработчики быстро заметили, что пользователи стали использовать статусы для общения, и выпустили новую версию WhatsApp, в которой было больше функций, связанных с отправкой сообщений. В результате небольшая пользовательская база выросла всего за несколько дней до 250 000 человек.
Результат. К 2015 году сервис стал самым популярным приложением для обмена сообщениями в мире. Сейчас WhatsApp используют более двух миллиардов человек по всему миру, а начался проект с MVP.
Создание MVP: пошаговое руководство
Процесс запуска минимально жизнеспособного продукта включает восемь этапов.
Разберемся, какая задача на каждом этапе и что нужно делать.
Этап 1. Определить проблему пользователя
Задача. Понять, для чего нужен продукт, определить его основную ценность для пользователя.
Клиенты бизнес-центра часто уезжают в командировки, и парковочные места остаются свободными. Бизнес-центр не может привлечь временных арендаторов того, что им негде парковаться, и теряет потенциальный доход.
Бизнес-центр запускает приложение для аренды парковочных мест. Оно позволяет водителям искать свободные места для парковки и арендовать их на время. Теперь у компании появился удобный инструмент для снижения издержек на период командировок постоянных арендаторов. Приложение стало полезным, потому что создатели проекта точно определили проблемы целевой аудитории.
Как действовать. Опросите своих потенциальных клиентов, выявите основные проблемы и боли, с которыми они сталкиваются. Изучите обратную связь от пользователей на сайтах и в социальных сетях конкурентов.
Этап 2. Определить ядро целевой аудитории
Задача. Создать подробный профиль пользователя: возраст, образование, работа, доход, привычки и хобби. Описать все детали, которые могут повлиять на выбор клиента в будущем.
Мобильный оператор хочет расширить клиентскую базу и создает приложение с дополнительными бонусами для активных клиентов. Перед началом разработки компания проводит исследование своей аудитории и определяет конкретные стимулы, которые повышают активность и вовлеченность пользователей. Например, большое количество семейных клиентов позволяет компании сделать специальные скидки для звонков родственникам. Так оператор укрепляет лояльность и привлекает новых клиентов.
Как действовать. Проведите опрос через сервисы по изучению целевой аудитории. Проанализируйте социальные сети клиентов, изучите их предпочтения, проблемы и цели. Используйте данные сервисов веб-аналитики, организуйте глубинные интервью с клиентами.
Этап 3. Изучить конкурентов
Задача. Определить и проанализировать основных игроков на рынке. Изучить основные характеристики конкурентов: их стратегические и финансовые цели, маркетинговые кампании, динамику продаж, прибыль и слабые места.
Банк создает приложение для пользователей с индивидуальным личным кабинетом. Перед запуском разработки он оценивает эффективность подобных приложений у своих конкурентов. Руководители проекта анализируют основные услуги, интерфейс, бонусные программы, клиентский сервис и систему обратной связи — все функции приложений других банков. После этого анализа проектная команда определяет характеристики собственного продукта и переходит к следующему этапу.
Как действовать. Проанализируйте трех самых крупных игроков на рынке, определите их долю, оцените свою способность предложить новый продукт. Изучите сайты, новости, видео, интервью и оценки, посетите презентации и конференции с участием конкурентов.
Этап 4. Провести SWOT-анализ
Задача. Определить сильные и слабые стороны продукта, потенциальные возможности и угрозы.
Например, банк создает сервис по инвестированию для физических лиц. Сервис будет включать обучающие материалы, советы экспертов, программы лояльности и личные счета пользователей. Проектные менеджеры проводят анализ, выделяют сильные и слабые стороны проекта, внешние возможности и угрозы.
На основе SWOT-анализа банк разрабатывает стратегию запуска нового продукта, фокусируется на клиентах с высоким доходом и создает собственные программы лояльности
Как действовать. Соберите все преимущества вашего продукта по сравнению с конкурентами, проранжируйте их от более значимых к менее значимым. Удалите из списка лишние пункты, оставьте только те характеристики, которые повлияют на развитие продукта. Укажите все проблемы, которые имеют ваши бизнес-процессы.
Соберите всю информацию о динамике рынка и поведении конкурентов. Не включайте в список незначительные факторы. Используйте результаты анализа для составления стратегии развития продукта.
Этап 5. Определить путь пользователя
Задача. Сделать простым и понятным путь, который проходит пользователь при взаимодействии с продуктом. Проектная команда проходит все шаги пользователя самостоятельно и определяет моменты, когда пользователь нуждается в подсказке или дополнительной информации.
Логистическая компания создает сервис для привлечения водителей к выполнению грузоперевозок. Водитель пользуется этим сервисом в таком порядке: регистрируется, вносит свои личные данные, выбирает удобную доставку, управляет заказом и получает вознаграждение. После описания всех шагов разработчики могут приступить к определению функций для каждого из них.
Как действовать. Создайте образы разных типов клиентов, определите все этапы и взаимодействия пользователя, обсудите с командой возможные помехи для клиента в процессе достижения его цели на сайте. Устраните помехи с помощью изменения карты пользователя.
Этап 6. Определить основные функции будущего продукта
Задача. Прописать ключевые функции продукта для каждого шага пользователя, определить приоритетность функций и объем минимально жизнеспособного продукта.
В предыдущем пункте мы описали путь водителя на сервисе логистической компании. Теперь для каждого шага проектная команда прописывает конкретные функции. На этапе регистрации водитель может ввести номер телефона или электронную почту.
На следующем этапе он загружает паспортные данные, информацию о своей квалификации и опыте работы. Все основные шаги и функции пользователя разработчики собирают в единую карту для отображения его полного маршрута на сервисе. Карта помогает расставить приоритеты в использовании функций и определить объем MVP.
Как действовать. Составьте карту взаимодействия пользователя с продуктом. Определите функцию для каждого этапа и расставьте все функции по приоритету. Расположите самые востребованные функции в начале списка, редкие — в конце. Приоритетные функции будут формировать минимально жизнеспособный продукт.
Этап 7. Выбрать методологию разработки
Задача. Выбрать один из итеративных способов разработки. Lean, Scrum, Kanban, экстремальное программирование — все эти методологии позволяют дорабатывать продукт на протяжении всего процесса разработки.
Строительная компания оптимизирует процесс закупок. Сотрудники привыкли обрабатывать классические типовые запросы, но они не могут справиться с нетипичными заказами. Методология Kanban позволила разделить все закупки на разные типы и классы. Разработчики добавили дополнительную функцию для нетипичных запросов.
Как действовать. Изучите основные характеристики методологий разработки программного обеспечения. Определите масштаб и стоимость проекта, риски, сложность и скорость реализации. Проанализируйте стратегические цели развития продукта и выберите подходящую методологию для вашего проекта.
Этап 8. Протестировать продукт
Задача. Провести альфа- и бета-тестирование для совершенствования продукта. Устранить все технические проблемы и оценить реакцию рынка.
Банк создает новый сервис для юридических лиц. Новый продукт тестируют внутренние тестировщики, сами члены проектной команды, разработчики, сотрудники банка. После этого реальные клиенты начинают пользоваться сервисом. Банк собирает обратную связь и делает необходимые доработки.
Как действовать. После завершения разработки пользуйтесь продуктом внутри команды на протяжении 3—4 дней. Потом дайте доступ к продукту реальным пользователям на 2 недели. Проанализируйте все полученные данные, доработайте продукт и снова протестируйте
Запуск продукта
После прохождения всех этапов и перед запуском продукта компания устанавливает метрики успеха MVP. Это могут быть финансовые результаты или количество активных пользователей сайта.
После запуска компания измеряет метрики и понимает, дает ли итоговый MVP ожидаемый результат. Дальнейшее развитие продукта зависит от обратной связи со стороны пользователей.
Оценка MVP и доработка продукта
После обработки первичной информации и устранения проблем проектная команда продолжает выполнять новые итерации и улучшать продукт. Менеджеры обрабатывают данные о поведении пользователей, оценивают эффективность продукта и могут вернуться к любому из этапов создания MVP.
Минимально жизнеспособный продукт помогает компаниям минимизировать издержки при запуске новых продуктов. MVP позволяет оценить потенциал проекта, выявить его позитивные и негативные стороны, оценить прогресс в развитии продукта и получить обратную связь от пользователей в короткие сроки.
Сейчас читают
Визуализация юридических данных: что это и как помогает победить в суде
Визуализация данных, или Legal Design, — прием, который помогает донести позицию в суде быстро и понятно. В статье рассказываем, как применять визуализацию в судебных спорах, чтобы выигрывать самые сложные дела
Средний доход на пользователя: что это такое, как и зачем его считать
Рассказываем, чем бизнесу поможет знание ARPU — среднего дохода на пользователя, как его рассчитать и что сделать, чтобы увеличить этот показатель
Преимущества и недостатки каналов прямой коммуникации
E-mail, СМС, мобильные и веб-пуши, мессенджеры, чат-боты — это каналы прямой коммуникации с клиентом. У каждого из них есть свои плюсы и минусы. Описываем особенности каналов во всех подробностях
Рассылка для бизнеса
Получайте первыми приглашения на вебинары, анонсы курсов и подборки статей, которые помогут сделать бизнес сильнее
© 2006—2021, АО «Тинькофф Банк», Лицензия ЦБ РФ № 2673 — Команда проекта
Тинькофф Бизнес защищает персональные данные пользователей и обрабатывает Cookies только для персонализации сервисов. Запретить обработку Cookies можно в настройках Вашего браузера. Пожалуйста, ознакомьтесь с Условиями обработки персональных данных и Cookies.
Чтобы скачать чек-лист,
подпишитесь на рассылку о бизнесе
После подписки вам откроется страница для скачивания