Всем привет! Меня зовут Дарья Томилова, я старший продуктовый дизайнер в СберМаркете. Полтора года назад я пришла в кроссфункциональную команду, которая работает над услугой самовывоза, — клиент делает заказ онлайн и затем забирает заранее собранные товары в магазине. Мы отвечаем за весь флоу таких заказов и разрабатываем новые фичи, чтобы сделать этот сервис лучше.
За время работы в нашей команде, кроме основных задач, я помогла перестроить Discovery-процессы. В статье я расскажу, как с позиции специалиста можно повлиять на процессы в команде и к чему это в итоге нас привело. Так, например, мы собрали CJM — карту пути клиента, а на ее основе сделали много крутых фич. Но обо всём по порядку.
Почему процесс Discovery так важен
Сначала я хочу немного рассказать, почему так акцентирую внимание на Discovery-процессах. Дело в том, что в IT при создании продукта есть два процесса — Discovery и Delivery.
Discovery — это исследование и проверка гипотез, формирование образа продукта. В Discovery участвует продакт-менеджер, дизайнер, аналитик и исследователь.
Delivery — разработка решения, созданного на этапе Discovery. В Delivery участвуют разработчики и тестировщики.
Чтобы создать классное решение, которое будет полезно и удобно пользователям, сначала нужно пройти долгий путь: провести исследования и изучить потребности своих пользователей, сформулировать гипотезы и убедиться, что вы правильно всё поняли, а только потом воплощать идеи в жизнь.
Discovery — это тот самый фундамент, благодаря которому появляются крутые решения. Работать без Discovery — это как идти в темноте без фонарика. Куда-то вы придете, но не факт, что туда, куда нужно.
На Discovery-встречах обсуждали не проблемы, а решения
Полтора года назад Discovery-встречи нашей команды проходили так: раз в неделю собирались продакты и дизайнеры и обсуждали решения, которые нужно взять в работу. Продакт говорил, например: «Давайте сделаем кнопку такую, а текст напишем такой».
В итоге мы выполняли много точечных задач, но глобальное видение продукта у меня не складывалось. Контекста не хватало именно дизайнерам, продакт получал всю информацию от исследователя и аналитика на отдельных встречах. Но раз я пришла в команду и собиралась в ней задержаться, то решила, что могу прокачать этот процесс сама.
Решила улучшить Discovery-процессы с позиции дизайнера
Я пришла к своему руководителю, рассказала, что хочу прокачать Discovery-процессы, и он поддержал меня. Мне подсказали две другие команды с классными процессами, на встречи которых можно сходить. Я пошла — и сильно удивилась, потому что там всё было иначе. Например, я попала на встречу по планированию на следующие полгода: на ней команда обсуждала заранее составленный список фичей, делилась мнением, в какие фичи они верят, и оценивала, сколько времени потребуется на разработку.
В то время в СберМаркете начали внедрять индивидуальные планы развития сотрудников, а так как мне были интересны Discovery-процессы, одну из целей плана как раз связали с этим. Вместе с руководителем мы сформулировали то, как видим удобный и эффективный процесс Discovery:
→ Встреча команды проходит раз в неделю. В ней участвуют аналитик, исследователь, продакт-менеджер и дизайнер. Аналитик и исследователь делятся новостями и инсайтами, когда они есть.
→ Встреча посвящена обсуждению гипотез, а не готовых решений.
→ Между участниками процесса всё прозрачно и понятно.
→ На встречу можно записаться заранее и обозначить тему, которую хочется обсудить.
→ После встречи все понимают, какие задачи нужно завести к планированию, а еще что посмотреть на рынке и какие исследования провести к следующей встрече.
Чтобы выявить проблемы и найти решения, организовали Ретро
После того как мы с руководителем обсудили, каким должен быть удобный и эффективный процесс Discovery, я начала думать, как к этому прийти. И, конечно, пошла обсуждать вопрос внутри команды. Оказалось, мы не понимаем, что именно нужно лечить, а главное — как. То есть в целом проблему видно — мы работаем с готовыми решениями, а не с проблемами пользователей, но как с этим разобраться и улучшить процессы — пока непонятно.
Так решили провести Ретро — чтобы выявить конкретные проблемы и найти способы их решить. Ретро длилось полтора часа. Расскажу по шагам, как это было.
Шаг 1. Оценить Discovery-процессы. Сначала мы оценили текущий процесс Discovery от 1 до 8, где 1 — «абсолютно недоволен процессом», а 8 — «полностью доволен». Средняя оценка получилась в районе 3,5:
Шаг 2. Определить, что работает, а что — нет. Мы поделились своими наблюдениями и на их основе выделили то, что, как нам кажется, работает хорошо:
у команды есть энтузиазм;
проводим брейнштормы с командой раз в квартал для поиска новых болей и проблем.
При этом поняли, что нас не устраивает:
не работаем с гипотезами, а только с готовыми решениями;
не понимаем, что происходит с идеями с прошедших воркшопов;
не знаем, что может нас аффектить.
Кроме этого, были вопросы к организации процесса Discovery. Так, планирование дизайна и Discovery были слиты воедино, а должны быть отдельными, как два разных процесса. На встречах не хватало более подробного обсуждения предыстории исследований, метрик, аналитики, а также инсайтов от аналитиков и исследователя. А еще мы не понимали, как вести встречу, потому что чаще всего это было по принципу «как получится».
Шаг 3. Составить план, как улучшить Discovery. Чтобы успеть обсудить все вопросы за одну встречу, разбились на две группы. Первая группа разбирала одну половину проблем, вторая — другую. Вот что из этого вышло:
Проблема | Решение |
Не работаем с гипотезами, а только с готовыми решениями | — Продакт дает больше предыстории по задачам. — Продакт через метрики формулирует боли и барьеры, которые есть у пользователей, и то, чего хотим достичь. — Продакт может предлагать решения, но за поиском оптимального обращается к дизайнеру. — Дизайнер не берёт в работу задачу, где вместо проблемы сформулировано готовое решение. |
Не понимаем, что происходит с идеями с прошедших воркшопов | — Вести актуальные PROJ и линковать к задачам аналитиков, исследователей, дизайнеров и разработчиков. — Провести ревизию списков планирования аналитики и дизайна. — Информировать участников задачи о результатах — авторизация успеха. |
Не знаем, что делают другие команды и что может нас аффектить | — Дизайнер и продакт синхронизируются с другими дизайнерами и продактами, когда берут задачу в работу. — Discovery-команда обсуждает свежие новости с общих командных встреч. |
Организация процесса Discovery | — Разделить встречи на Discovery и планирование дизайна. — Не размывать фокус каждой из встреч. — Готовиться к Discovery: приходить всем участникам Discovery-команды, делиться новостями и гипотезами; сделать отдельную страницу для каждой встречи в общем пространстве; разбить встречу на три раунда по таймингу: проблемы, новости, идеи от команды. |
Чтобы Ретро не прошло впустую, мы определили ответственных по каждой проблеме и дату выполнения, где это было возможно. Я взяла на себя всё, что касалось организации процесса Discovery. Об этом дальше ↓
Я отвечала за организацию Discovery-встреч
Итак, мы провели Ретро, выявили проблемы и описали, как их решить. Я занималась организационными вопросами. Вот что я сделала:
→ Поставила для Discovery-команды отдельную встречу и написала ее цель. Это было так:
фокус встречи — на Discovery;
обсуждаем гипотезы — насколько они рабочие, какой могут принести профит. Смотрим аналитику и исследования;
приносим сырые задачи и смотрим, что за проблемы решаем, какие метрики есть. Выбираем, что берем в приоритет, и ставим задачу в спринт дизайна на следующую неделю.
→ Создала раздел для Discovery в нашем общем пространстве в Confluence и сделала шаблон для каждой встречи. За основу взяла табличку, которую дизайнеры использовали для Design Demo — презентации результатов работы, но удалила лишнее. Получилась простая, но удобная таблица:
Тема для обсуждения, от кого | Договорённости |
→ Напоминала коллегам, что сегодня будет Discovery. И если у кого-то есть темы для обсуждения, можно и нужно их заранее записать в таблицу.
→ Вела Discovery-встречи. Делилась экраном и записывала в таблицу все договоренности и важные моменты, которые возникали по ходу.
Дальше расскажу, что же из этого получилось.
На встречах стали обсуждать исследования и гипотезы, но договоренности всё еще терялись
После того как выявили проблемы Discovery-процесса, нашли решения и начали их внедрять, мы получили первые результаты:
на встречи стали приходить все участники Discovery-команды и набрасывать идеи и гипотезы, даже самые странные и смелые;
на встречах начали обсуждать результаты А/Б-тестирований и исследований. Продакты больше говорили о проблемах, приносили данные и делились предысторией задач. В целом процесс стал более структурным и прозрачным.
Иногда мы не успевали обсудить всё, что хотели. В этом случае отталкивались от срочности: для какой-то темы ставили отдельную встречу, для другой было достаточно треда в рабочем чате. Что-то переносили на следующую Discovery-встречу.
Результаты через полтора месяца. Вначале всё было хорошо, но спустя полтора месяца вылезла старая проблема: мы теряли некоторые идеи и активности за более важными новостями и задачами.
Тогда в начале каждой встречи мы стали проходиться по старым договоренностям — всем без исключения. Для этого первое время открывали табличку с прошлой встречи, но поняли, что так неудобно. Поэтому для каждой новой встречи копировали таблицу с прошлой и уже в ней обновляли статусы. Со временем договоренности дополнились чекбоксами, ответственными и датами выполнения: в Confluence это легко сделать через символы @ и //.
А ещё спустя некоторое время появились отдельные стримы, например, «Аптеки» или «Авто», за которые отвечали определенные продакты. В итоге табличка стала выглядеть так:
Темы для обсуждения | Договоренности |
Пройтись по договоренностям с прошлого Discovery | Обзвон
Посмотреть аналитику @Кирилл //15.08.2023 Собираем обратную связь от клиентов Отписаться в треде @Петя @Наташа Собрать встречу, чтобы обсудить детально @Петя |
Стримы | Аптеки @Яна
Дождаться результатов //15.08.2023 Собрать контекст для встречи //23.08.2023 |
Авто @Петя Собрать всё, что есть по проблеме с названием @Даша //23.08.2023 Создать тред и позвать маркетинг @Даша //30.08.2023 | |
Новые темы | |
Результаты А/Б новых карточек | |
Сурдж |
Результаты через полгода. Мы стали доводить до конца всё, что начали. Конечно, не все гипотезы оказались на проде и не все исследования были нужны. Какие-то идеи могли выстрелить, но подвисали по не зависящим от нас причинам. Но это был результат, который позволял двигаться дальше и пробовать новые гипотезы. Некоторые оказались ценными, прошли Discovery, Delivery, сделали жизнь пользователей удобнее и принесли выгоду бизнесу.
Благодаря новому процессу Discovery я, прежде всего, собрала CJM — карту клиентского пути. Это очень круто, потому что мы шли по этой карте, добавляли боли с исследований и забирали самое важное в работу:
добавили возможность оставить комментарии сборщику на странице чекаута;
сделали кнопку «Я на месте» более заметной. Это кнопка, которую нажимаешь в приложении, когда приходишь за заказом;
сделали редизайн карточек самовывоза — чтобы их помещалось больше, они в последующих итерациях стали более информативными и помогали быстрее выбирать магазин;
добавили на странице чекаута возможность выбрать опцию «До багажника» — когда заказ выносят прямо к машине и кладут в багажник;
сделали вместе с другой командой новый формат маленьких карточек для главного экрана. Это дало еще одну возможность оформить заказ самовывозом.
Вот как выглядят наши новые фичи:
С обновленным процессом Discovery после внедрения фичей вся команда стала смотреть цифры по пользователям и делать выводы. Мы стали понимать, что функциями пользуются, поэтому их можно докручивать и улучшать дальше.
Пять инструментов, которые помогли улучшить процесс Discovery
И наконец, я хочу выделить пять инструментов, которые помогли улучшить процесс Discovery. Думаю, они подойдут не всем, но что-то может сработать и у вас.
1. Провести Ретро. О нем я рассказывала выше, поэтому детально останавливаться не буду. На Ретро нужно:
оценить текущие Discovery-процессы по шкале от 1 до 8, где 1 — «абсолютно недоволен процессом», а 8 — «полностью доволен»;
выделить то, что работает хорошо, и то, что не устраивает;
обсудить, как можно исправить недостатки. Если вопросов много, разделиться на группы;
выбрать ответственных по каждому пункту и установить дату выполнения;
запланировать следующее Ретро, например, через два месяца, чтобы оценить результаты.
2. Завести в общем пространстве документ для Discovery-встреч. Если встречам не хватает структурности, вы забываете инициативы или гипотезы, можно завести в Confluence или Miro документ для Discovery-встреч. Например, такой:
Discovery Meetings Страница для Discovery-встреч, которые проходят по четвергам в 12:00, ссылка на встречу. Ведущего выбираем перед началом встречи. Обсуждаем: - гипотезы — ценность, аналитику, исследования, бенчмаркинг; - результаты A/B-тестов и выводы; - результаты исследований — решили задачу или нет, нужно ли еще одно исследование; - исследования, которые проходят в данный момент или должны пройти. Например, опросы удовлетворенности, дни эмпатии, юиксы. По итогам решаем, какие из гипотез и задач пойдут в следующий спринт дизайнера, аналитика, исследователя. |
Для встречи можно сделать шаблон. Вот для примера наш:
Тема для обсуждения | Договоренности |
Пройтись по договоренностям с прошлого Discovery | Тема один Нужно сделать @Имя //Дата Нужно сделать @Имя //Дата Нужно сделать @Имя //Дата Тема два Нужно сделать @Имя //Дата Нужно сделать @Имя //Дата Нужно сделать @Имя //Дата |
Стримы | Стрим один Нужно сделать @Имя //Дата Нужно сделать @Имя //Дата Нужно сделать @Имя //Дата Стрим два Нужно сделать @Имя //Дата Нужно сделать @Имя //Дата Нужно сделать @Имя //Дата |
Новые темы |
3. Собрать всю команду. Если у вас нет отдельной встречи для Discovery, соберите её. Для этого нужно:
позвать всех участников — продактов, дизайнеров, аналитиков, исследователей, редакторов;
добавить описание и ссылку на общее пространство, где вы будете фиксировать или уже фиксируете договоренности по встрече;
предупредить всех, а на встрече рассказать, в чем её цель.
Хорошая практика, чтобы каждый участник рассказал, по каким вопросам и с какими задачами к нему можно приходить. Это не всегда очевидно.
4. Выбрать ведущего Discovery. Решите, кто будет вести Discovery, шарить экран и записывать договоренности. Лучше, чтобы эту роль передавали друг другу участники команды по очереди. Не все любят вести встречи, но это увеличивает вовлеченность и не замыкает встречу на одном человеке.
5. Регулярно напоминать о встречах. Первое время напоминайте о Discovery-встречах, например, за несколько часов. Также неплохо повторять, что каждый может заранее записать тему для обсуждения. Напоминать лучше в чате, где есть все участники встречи.
Можно создать Discovery-чат, если его еще нет. Он пригодится для обсуждения задач, новостей и важных вопросов, которые выходят за рамки встречи. А еще можно добавить бота, который будет напоминать о встречах и важных событиях.
Discovery-встречи стали по-настоящему полезными и эффективными
Эта история помогла нашей команде понять, чего не хватает для проверки той или иной гипотезы. Мы стали обсуждать итоги А/Б-тестов и делать выводы, пробовать новые исследования и синхронизироваться с другими командами. В целом проработка задач на Discovery стала более качественной, и всё это сработало благодаря проактивности команды.
В начале статьи я говорила, что улучшение Discovery-процессов стало одной из целей моего плана развития. По итогам Discovery-активности мне поставили А+ — это оценка, которой в СберМаркете выделяют особые достижения ?
Через некоторое время я перешла в другую команду. Прежний опыт помог и там. Не все инструменты оказались нужны: так, Discovery-команда собиралась с нуля, и проводить Ретро не было смысла. Но общая еженедельная встреча, таблица и ведущий сработали и там.
Кроме этого, мы дополнили часть инструментов, придумали новые и стали активнее использовать опыт других команд. Это помогает бороться с багами, проблемами в UX и более осмысленно вести бэклог. В следующей статье я обязательно об этом расскажу.
А как проходят Discovery-встречи в вашей команде? С какими проблемами вы столкнулись и как их решили?
Product&data команда Купера (ex СберМаркет) ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.
