Пошаговая инструкция по запуску работающего продукта без опыта

Рассказ о продуктовом дизайне от сооснователей лаборатории Wobot.me Павла Доронина и Максима Терновенко.

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

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

В итоге процесс запуска проекта мог растягиваться на один-два месяца.

Чаще всего под такую категорию клиентов попадают:

И на наш взгляд, в ситуации, когда у вас есть только бизнес-идея, но нет опыта запуска продуктов с нуля, вероятность «свернуть не туда» стремится к 100%. Как следствие:

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

Мы не претендуем на уникальность. Более того, наша методология — это комбинация различных уже известных подходов. Однако мы протестировали её на более чем десяти проектах и помогли таким компаниям, как Viber, Comedy Club, Glamour, Unilever и другим. Разработанный подход помогает и нам, и заказчикам двигаться поступательно от бизнес-идеи до работающего MVP.

Одна из причин успеха — соблюдение принципа «когнитивной простоты», который мы заложили в основу wobot-методологии. Но обо всем по порядку.

В марте 2016 года я запустил проект Chatbots Community — сообщество разработчиков чат-ботов. Через полгода оно стало частью нового сообщества по искусственному интеллекту — AI Community, в котором уже состоит более двух тысяч предпринимателей и инженеров.

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

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

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

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

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

Коллеги из «Рыбаков Фонда» поделились с нами идеей запуска онлайн-платформы в виде агрегатора-поисковика по НКО. Идея нам понравилась, так как почти в любой нише есть успешные агрегаторы и поисковики.

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

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

Мы провели продуктовый анализ третьего сектора в России и США. В результате исследования получилось более 60 слайдов. Но для этого рассказа важны только следующие два.

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

Итак, структура пошаговой инструкции:

Мы взяли в качестве ориентиров несколько известных американских проектов, которые агрегируют разную информацию о некоммерческих организациях в США. Наиболее релевантной оказалась компания GuideStar, которая собирает информацию по более чем 2 млн НКО.

Затем мы изучили проект с разных сторон:

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

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

Вместе с заказчиком мы провели две Skype-сессии, на которых пришли к следующим формулировкам:

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

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

Формулирование видения продукта в виде концепта основных модулей и сервисов позволяет идти «сверху вниз», то есть в сущности здесь применяется «метод прогрессивного джипега».

Как видно на картинке выше, мы приоритезировали два сервиса из пяти, таким образом выделили содержание MVP:

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

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

Далее мы составляем карту путешествия пользователя. Смысл этого пункта в том, чтобы выделить основные этапы потребления продукта: от знакомства с ним до непосредственного использования.

В нашем случае мы выделили следующие пять шагов:

И каждый этап мы описываем по следующей логике:

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

Дальше идет всем знакомая очередность действий. Сначала рисуем Wireframe — «карандашные» скетчи интерфейсов. Затем создаём дизайн, верстаем и разрабатываем.

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

В противном случае:

Обычно работа ведется по однонедельным спринтам. Но в этом проекте мы выбрали двухнедельные циклы. Реже делать не рекомендуем. Этот не означает, что мы пропали на две недели и вернулись с непонятным результатом. Это означает, что мы вместе с заказчиком заранее определили объем задач, над которым работаем в течение спринта.

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

С тех пор на каждой доске у нас висит вот такой фреймворк работы:

Мы попробовали разные сервисы ведения проекта, но в итоге остановились на Realtime Board — «бесконечной» онлайн-доске. Ключевое преимущество этого инструмента в том, что он прост и нагляден в презентации результатов работы, комментировании, добавлении стрелочек или цветного фона, добавлении стикеров с комментариями и так далее. И важно, что всё в одном месте — всё рабочее пространство открывается по одной ссылке.

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

Для ежедневной коммуникации мы используем чат в Telegram, а для созвонов — Skype.

Мы стремимся максимально упростить все рабочие процессы — как внутренние, так и с заказчиком. В том числе это отражается и на нашем фреймворке. Вот, например, оформление спринта.

А вот так мы визуализировали заказчику нашу рекомендацию по выбору Parse — инструмента для парсинга базы данных Минюста.

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

Роль «технологического партнера» возможна только при условии, что заказчик и исполнитель работают в симбиозе, дополняя друг друга:

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

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

#инструкции #разработка