Карьера
Alexandr Tokmakov
4512

Продуктовый процесс в «Везёт»: как всё устроено

Недавно директор по продукту «Везёт» Анатолий Кульбацкий рассказал о том, какие вопросы он задаёт на собеседовании продакт-менеджеру. Команда собрана, поэтому настало время рассказать, как мы работаем. Меня зовут Александр Токмаков, и в этой статье я подробно опишу, как устроен продуктовый процесс в нашей компании с позиции продакт-менеджера.

В закладки
Аудио

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

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

Про структуру и цели

В нашей компании пять продакт-менеджеров: каждый отвечает за своё направление и имеет свою команду. Я работаю с командой пользовательского приложения, наш продукт — это приложение «Везёт».

Команда, которой я управляю:

  • Два продуктовых дизайнера.
  • Один продуктовый аналитик.
  • Три бэкенд-инженера.
  • Три iOS-инженера.
  • Три Android-инженера.
  • Три QA-инженера.
  • Scrum master — один на несколько команд.

Наша основная задача — это улучшать опыт пользователя с помощью продукта: до, после и во время поездки.

В этой статье будет много ссылок, поэтому не лишним будет показать основные сервисы, которые мы используем работе:

  1. Google Docs.
  2. Jira.
  3. Confluence.
  4. Firebase.
  5. Fabric (сейчас переехал в Firebase).
  6. Amplitude.
  7. Miro.
  8. Figma.
  9. Telegram.
  10. Mattermost.
  11. Braze.
  12. SurveyMonkey.
  13. TestRail.

Весь наш продуктовый процесс состоит из четырех основных блоков:

  1. Поиск проблем/идей/гипотез (Discovery).
  2. Проектирование решений (Define).
  3. Разработка решения (Develop).
  4. Запуск решения (Delivery).

За основу был взят фреймворк Double Diamond или 4D от British Design Council.

Discovery

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

1. Поиск проблем пользователей. Идеи и гипотезы для улучшения продукта

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

Внешние и внутренние исследования. Продакт-менеджер анализирует информацию из следующих открытых источников:

  • Открытые или внутренние исследования, которые проводит отдел маркетинга.
  • Анализ отрасли, вот, к примеру, исследование рынка грузовых перевозок.
  • Документы из других отраслей, например, обзор трендов из банковской и fintech-индустрии.

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

Мозговой штурм в ГК "Везёт" Александр Токмаков

Конкурентный анализ. Полноценно пользуемся сервисами конкурентов и проходим полный путь заказа такси в различных ситуациях: в зависимости от времени суток, дня недели или локации. В прошлом году мы провели несколько смен по 10 часов в качестве водителей в разных такси-сервисах. Это был уникальный опыт, который позволил почувствовать все «боли» пользователей и водителей на себе, а также глубже погрузиться в контекст бизнеса такси.

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

CustDev. Состоит из четырёх этапов:

  1. Скрипт. Вопросы для интервью строятся от обратного, исходя из наших гипотез и идей.

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

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

    Пример вопросов для интервью от наших коллег из JTBD.academy можно посмотреть тут.

  2. Респонденты. Для нас работают несколько подходов. «Везет» — это массовый продукт, и аудитория у него очень широкая. Для определения первичных потребностей и проблем иногда достаточно написать пост в социальных сетях и телеграм-каналах, чтобы таким образом собрать десяток респондентов с релевантным опытом.

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

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

  3. Интервью. В среднем интервью занимает от 20 минут до 1 часа. Здесь важно сонастроиться и установить эмпатическую связь с респондентом, не перебивать, но контролировать ход встречи.

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

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

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

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

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

Опросы. Работают в связке с CustDev и являются количественным инструментом для подтверждения/опровержения инсайтов и сигналов из интервью. Нашим приложением ежедневно пользуется более 100 тысяч пользователей, поэтому за несколько дней можно собрать несколько тысяч ответов, распределение которых также является подтверждением или опровержением гипотез. Для запуска опроса мы используем два инструмента:

  1. Пуши/иннапы через Braze, если нужна тонкая настройка по параметрам пользователя, например, опросить только пользователей, у которых больше шести совершенных поездок за последний месяц.
  2. Внутренняя кнопка, которая переводит на SurveyMonkey, откуда мы после опроса получаем отчет (цифры вымышленные).
Опрос внутри приложения Александр Токмаков

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

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

2. Верификация, приоритизация и оформление идей в проекты

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

Reach и Impact мы определяем по ретроспективным данным или по условной шкале (от 1 до 10), если создаем что-то абсолютно новое в приложении.

Effort считаем в спринтах и оцениваем вместе с инженерами, этот процесс оценки напоминает Planning poker.

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

В итоге получаем таблицу (пример), где сортируем гипотезы по главному коэффициенту и начинаем сфокусировано работать с 3-5 гипотезами.

Создаем под каждый проект отдельный эпик в продуктовом бэклоге в Jira. Расписываем Product Vision Scope, а затем решаем в каком виде будем все это делать: MVP или Версия 1.0, Версия 2.0 и так далее.

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

Define

На этапе проектирования менеджер описывает User Story или JTBD Story того, какие действия/результаты ожидаются от пользователя, системы и других ролей в данном проекте.

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

CJM Александр Токмаков

Аналитик готовит описания событий и пользовательских данных, которые мы хотим залогировать, а также показатели для проведения А/B теста или когортного анализа.

В конце мы собираем всю информацию в эпик в Jira для этапа Delivery и презентуем проект всей команде, обсуждаем возможные риски и маневры.

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

Все, дальше начинается процесс Delivery, где продакт менеджер участвует как куратор и источник информации о целях, логике и приоритетах проекта.

Develop

Мы работаем по Scrum, который дает нам возможность фокусироваться и создавать каждые 2-4 недели версию приложения с новой функциональностью.

Процесс состоит из следующих этапов:

  1. Грумминг.
  2. Планирование.
  3. Разработка.
  4. Ревью.
  5. Тестирование функциональности, визуальных элементов и аналитических событий.
  6. Тестирование Release Candidate.
  7. Создание финальных сборок версий приложений (разработчики собирают конечные версии приложения; менеджер загружает их на бета-тестирование в AppStore и Google Play; финально тестируем версии вместе с командой и стейкхолдерами).

Delivery

Состоит из трёх этапов:

  1. Выкладка происходит после успешного бета-тестирования. Пишем текст «Что нового» в AppStore и GooglePlay, если необходимо, добавляем новые скрины и выкладываем версию уже для пользователей.

    Отправляем релиз ноут всем стейкхолдерам и заинтересованным лицам в компании.

    И финально контролируем динамику раскатки (adoption), кол-во критичных багов в Crashlytics и воронки в Amplitude, на случай просадок между версиями.

  2. А/B тест или когортный анализ.

    Рандомизированную выборку для теста мы формируем с помощью сервисов Remote Config и A/B Testing в Firebase и создаем дашборды экспериментов в Amplitude. Ждем, когда наберется достаточное количество данных для эксперимента. Помним про «проблему подглядывания».
  3. Итоги. Подводим итоги на основе результатов эксперимента. Обязательно доносим итоги до всей команды, обычно это происходит на ретроспективе или грумминге.

    Аналитик отсылает письмо всем заинтересованным.

После этого продакт-менеджер может принять три управленческих решения:

  1. Функциональность улучшает метрики → оставляем функциональность и раскатываем на 100%.
  2. Функциональность ухудшает метрики → убираем функциональность.
  3. Функциональность не ухудшает метрики → либо проводим новый эксперимент с другим решением, либо убираем функциональность.

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

​Схема продуктового процесса Александр Токмаков

Я работаю в продуктовой разработке уже 6 лет и считаю, что сейчас мы приблизились к практически идеальному процессу для B2C продукта, и вот почему:

  1. Системность. Каждый этап как маленькая «коробочка», которая имеет понятную информацию на входе, описание действий внутри нее и четкий результат, который ожидается на выходе. Будь то таблица, макет, дашборд, тикет, сборка с новой функциональностью или тест-кейс. Всегда известно, кто лидирует этап, в каком он статусе сейчас и когда будет закончен. Это критически важно для нас, т.к. мы распределенная команда и работаем из офисов в Москве, Краснодаре и Уфе.
  2. Мотивация. Прозрачный процесс, где каждый участник, будь то дизайнер, аналитик или инженер, понимает цели, планы и ожидания от его деятельности, а также их влияние на бизнес-результаты. Все это формирует внутреннюю мотивацию, которая так важна для высокоинтеллектуальных профессий.
  3. Результаты. За 2019 год по этому процессу прошло более 50 инициатив. Большинство из них так и осталось на этапах в Discovery. Но 19 продуктовых проектов прошли весь путь, а 12 из них показали улучшение показателей нашего продукта. А это значит, что мы добились своей цели.

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

Stay tuned!

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

Написать
{ "author_name": "Alexandr Tokmakov", "author_type": "self", "tags": [], "comments": 25, "likes": 35, "favorites": 165, "is_advertisement": false, "subsite_label": "hr", "id": 114445, "is_wide": false, "is_ugc": true, "date": "Tue, 24 Mar 2020 11:54:28 +0300", "is_special": false }
0
25 комментариев
Популярные
По порядку
Написать комментарий...
5

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

Ответить
0

Евгений, добрый день! Написал вам в личку 

Ответить
2

Лол, столько текста о процессах. Да вы красавчики.
По факту:
старое приложение с доисторическим дизайном.
таксисты: 85% из азии
машины: 70% просто ведра (плед на заднем сидении, пленка тонировки развивается на ветру, грязные салоны)
ценовая политика: реально может быть дешевле чем у яши и убера, но если учесть, что ты поедешь на грязном ведре с вонючим салоном, то лучше в другом месте заказать. Года два-три назад ехали загород в отель, заказал заранее минивен. Попросил, по опыту, чтобы была чистая машина. Приезжает челик с опозданием в час, на грязнючей машине, выходит в засаленной футболке и рваных шлепках. Мы семьей на отдых планировали ехать, а не в героиновый трип.
Смешно читать про команду и процессы, когда вы не может нанять себе дизайнера и сделать нормальное приложение.

Ответить
6

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

Ответить
0

Автор несет ответственность за приложение и Кирилл об этом тоже написал: "старое приложение с доисторическим дизайном.".

PS не пользовался "везёт". В статье описываются эффективно выстроенные процессы. Захотелось  установить и посмотреть на приложение. Статья - завуалированная реклама? :)

Ответить
1

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

Ответить
1

Возможно. Кстати в статье очень много рассказано про процесс и очень мало про результат.

"Результаты. За 2019 год по этому процессу прошло более 50 инициатив. Большинство из них так и осталось на этапах в Discovery. Но 19 продуктовых проектов прошли весь путь, а 12 из них показали улучшение показателей нашего продукта. А это значит, что мы добились своей цели." - это совсем не означает, что цели добился сам бизнес. Интересно было бы посмотреть, что за показатели, итоговые p/l и пр.

Ответить
0

Кирилл, мы точно говорим об одном и том же приложении?
В статье речь идет о приложении «Везёт», которое было создано в 2018 году.
 Года два-три назад ехали загород в отель, заказал заранее минивен

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

Ответить
0

По поводу водителя написал вам в личку.

Ответить
0

Привет, Кирилл, меня зовут Эльвира. Расскажите подробнее о вашей поездке нам на orm@vezet.ru. С какого номера телефона вы заказывали автомобиль, почему ждали в течение часа, а не попробовали заказть другой минивен? Так же напишите, пожалуйста, в каком городе произошла эта история, обращались ли вы в нашу службу качества по поводу этой поездки? Очень ждем от вас письмо, чтобы все проверить. 

Ответить
0

И тебе привет, Эльвира, раз мы на ты. Зачем мне тратить сейчас на это время, если это было давно и уже все не актуально? В Спб было.

Ответить
2

Хорошая статься, отдельное спасибо за ссылки!

Ответить
2

В моей локации 4мл населения, сервис такси появился 3 месяца назад. Хочу составить ему конкуренцию со своим самопалом. Приветствую продакта энтузиаста.

Ответить
0

Неужели нет ни одного продакта, который хочет оценить мою локацию и самопал ?

Ответить
0

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

Ответить
0

Зачем птицы сбиваются в стаи ? Что бы долететь до цели.
Ссылки пока сырые, поясню кому интересен сам кэйс 4мл без внятных конкурентов в Африке.

Ответить
1

Это все, конечно, классно , но:

1) Не увидел вообще ни слова про метрики.  Дашборды и стикеры это классно, но что отслеживаете и максимизируете? 

2) JTBD и CJM работают хорошо на основе определения нужного JTBD и субсегментов в них же (соцдем, средняя длина поездки, откуда едет и так далее по списку). Опросы полезны при нерепрезантативном наборе транзакций (алгоритмы не поняли ху ис ху), а дальше уже чисто математическая задачка и весь креативный дух вместе со смузи летит как фанера над Москвой, хе-хе.

3) Скорее совет-рекомендация. Добавьте кнопку обратной связи если такой нет и дайте возможность записывать голосом. Алгоритмами выделить текст, семантический анализ и засунуть это все добро в QFD. И сразу полезные гипотезы появяться :) 

P.S. Возможно, вы просто не все рассказали в материале, поэтому вопросы и возникли.  :) P.P.S. Сервисом не пользовался - в моем бульбостане вас пока (вроде) нету. 

Ответить
1

Мiкiта, 
1. Статья была про процесс. Метрики всегда конверсия и ретеншн пользователей новой функциональности к пользователям без этой функциональности на периоде: для нас это 1й, 2й, 3й, 7й, 14й, 30й день.
2. Уходим в частности и автоматизацию. В статье задача была показать каркас. Опросы мы не используем как репрезентативный инструмент, для нас это больше индикатор и проверка частотности проблем и гипотез.
3. Спасибо за фидбек, возьмем на заметку ;)

Ответить
1

Cпасибо за полновесный ответ :) 

Ответить
1

Спасибо, что поделился.

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

Вопросы:
1. Как вы оптимизируете time-to-market?
2. Катите ли вы что-нибудь вне релизного процесса? В статье, к сожалению, про это ни слова.
3. Есть ли у вас «протокол быстрого реагирования»? Процесс, по которому фича выкатывается в максимально короткие сроки в обход стандартного.

Ответить
0

1. Уточни, плиз. Не совсем понял time-to-market в каком этапе? Потому что метрика взята из девелоп. 
2. Есть система приоритетов. Хотфиксы случаются, но не часто (1 раз в полгода). Обычно это или критичная баги или внештатные обновления инфраструктуры (сертификаты, ключи и т.д.). Задача оформляется собирается полный скоп информации и делается релевантным инженером. Тестирование либо быстрая регрессия(очень редко), либо smoke тест и раскатка в прод. Если все ок, то включаем форс апдейт, на тех у кого данная версия.
3. Внутри спринта катим что-то очень редко. Потому что косты на переключения, подготовку помноженную на сырое описание и информационный вакуум будут стоить в итоге дороже, чем докатить нормальный спринт и взять фичу в следующий. 

Ответить
0

Интересная статья. Вопрос к автору 1. Когда появится продукт? 2. Насколько актуально создание продукта, если, по данным из открытых источников, Яндекс.Такси приобретёт активы Везёт?

Ответить
0

Александр,
1. Не понял Вашего вопроса. Везет запущен в 2018 году и работает. Если есть комментарии по работе приложения, то с удовольствием отвечу.
2. Сделка с Яндекс Такси пока только анонсирована. Наша продуктовая команда работает в штатном режиме.

Ответить
0

Поясню. 1. Пользуюсь «красным» ( Новым? ) приложением Везет и «желтым» (старым?) приложением Рутакси. Вижу отличия в дизайне и второстепенных фичах, но какого- то принципиального технологического прорыва ( прогресса) , существенной разницы не наблюдаю. Поэтому и спросил - где продукт? Раз появилась такая амбициозная жизнеутверждающая статья. 2. У Яндекс.Такси хорошая продуктовая команда и хорошее приложение. А зачем в случае слияния два клиентских приложения единовременно?

Ответить

Комментарий удален

Комментарий удален

0

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

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

Ответить

Прямой эфир