Стоп-фраза в разработке: как выпустить MVP за 2,5 месяца

Когда рождается идея технологического или цифрового продукта, естественным продолжением становится проверка идеи рынком и получение обратной связи от пользователей. Согласно принципам методологии Lean Startup стадия MVP (minimum viable product) чрезвычайно важна. Она позволяет проверять предположения как можно быстрее и дешевле. Кроме того, MVP может стать буфером безопасности, если есть страх, что идея провалится и продукт не найдет места на рынке. 

Как компания по аутсорс разработке, мы уже 7 лет разрабатываем MVP и полноценные продукты для наших клиентов. В этой статье мы дадим вам представление об этапах разработки MVP, и как мы делаем так, чтобы средний срок выпуска MVP не превышал 2,5 месяца. 

Что такое MVP

Термин «минимально жизнеспособный продукт» был придуман в 2001 году Фрэнком Робинсоном, генеральным директором SyncDev, и предпринимателями Стивом Бланком и Эриком Райсом. MVP помогает оценить потенциал, снизить риски, сэкономить деньги и определить направление для дальнейшего развития. MVP — это проведение реального эксперимента: создали — показали — проанализировали — пошли в рост или отказались от продукта. 

Круг запуска MVP (идея, разработка, мвп, обратная связь, доработка)

Главная ценность MVP — скорость выпуска на рынок. Если продукт будет разрабатываться год-два и провалится, будет грустно потом осознавать объем потраченного времени и денег. Но процесс разработки — это сочетание множества этапов. Чтобы обеспечить выпуск продукта за 2,5 месяца, необходимо, чтобы каждый этап заканчивался в отведенный ему срок. Мы успеваем это делать благодаря внутренней культуре разработки и детальному ресурсному планированию.  

Исследование

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

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

На этом этапе поможет знания различных фреймворков: Value Proposition Canvas, Product Canvas, Jobs To Be Done, RICE prioritization, Customer Journey Map. 

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

Проектирование

За первые две недели проекта дизайнеры и аналитики должны спроектировать ключевые экраны продукта, обычно это 2-3 экрана. Начинать надо именно с них, потому что все остальное является вспомогательным и его можно дорабатывать потом. Параллельно с дизайнерами команда разработки определяется с технологическим стеком и архитектурой продукта. Важно также на этом этапе ограничить круг устройств для продукта, что значительно снизит нагрузку на команду проекта и ускорит процесс разработки. К примеру, можно сконцентрироваться только на мобильной версии или выбрать только один браузер. 

На этапе проектирования всегда возникает огромное количество идей. Удержать все в голове, даже многих головах, невозможно. Очень важно сохранять все идеи и наработки по дизайну в «банке идей», даже если вы отказались от них на первых этапах. Начало работы над продуктом похоже на состояние влюбленности: участники не видят препятствий, все горят энтузиазмом и все кажется возможным. И некоторые такие идеи могут стать мощнейшим источником будущего развития продукта спустя 3-6 месяцев. 

Разработка, 6 недель

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

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

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

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

В последние 2 недели этапа разработки проводится прием продукта и ставится мораторий на нововведения. В это время активно включается отдел тестирования. Его задачей является выявление максимального количества проблем на разных устройствах и в разных краевых случаях. Совместно с командой разработки продукт доводится до итогового состояния готового MVP. 

Внешнее тестирование, 2 недели 

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

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

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

Инструменты для аналитики продуктов:

• Mixpanel.
• Amplitude.
• Hotjar.
• Google Analytics.
• Intercom.

Главные принципы разработки MVP:

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

«Менеджер проектов может казаться команде попугаем, повторяющим одно и тоже, но главное, чтобы все помнили о скорости».

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

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

Маленькая команда — это прекрасно. На этапе разработки mvp большая команда бессмысленна. В начале разработки продукта у него нет никакого скелета, план задач описан широкими мазками и на продукт сильно влияет любое движение команды. Большая команда разработки хорошо работает, когда продукт уже разросся, есть понятный скоуп работ и когда каждому точно есть чем заняться. Мы давно работаем командой не больше 4-7 человек. Такой команде легко распределять задачи, контролировать и синхронизироваться. 

Используйте модель оплаты Time & Material. Разработка MVP обладает самым большим коэффициентом неопределенности. Пытаться зафиксировать список работы и их объем в новом продукте не просто сложно, а почти невозможно. Кроме того, работа по Фикс прайс на этом этапе значительно отдалит точку начала разработки и соответственно дату выпуска продукта на рынок. 

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

Умный вывод в конец 

Если бы нас спросили, что самое, самое главное в разработке MVP, мы бы ответили — дедлайн. Предложение «А давайте мы сделаем это и перенесем релиз на недельку» должно быть стоп-фразой на всех уровнях команды. Можно предлагать отказаться от чего-то, чтобы сдать работу в срок, но двигать дедлайн — нет, никогда, забудьте об этом.