Стиль работы над продуктом и эффективность этой работы во многом зависят от структуры продуктовой команды и взаимодействии между разными ролями. За что отвечает аналитик, какие вопросы берет на себя продакт, что может делегировать другим отделам профессиональный исследователь и есть ли выделенная команда разработки? Ответы на эти вопросы определяют текущее состояние и динамику развития продукта.
Лиза Князева, ведущий менеджер продукта в Авито, на примере команды «Рейтингов и отзывов на модели» объяснила, как устроены их продуктовые команды, кто и за что отвечает и как команда работает над продуктом. Статья будет полезна тем, кто задумывается о формировании продуктовых команд и определяет зоны ответственности разных ролей в управлении продуктом.
У каждого продукта в Авито есть собственная выделенная команда, работа которой строится по принципам triple diamond (теория отлично изложена в примере Zendesk):
Стандартный процесс работы продуктовой команды выглядит так:
- Команда получает сигналы о проблеме
- Формулирует саму проблему
- Проверяет, что проблема действительно существует
- Приоритезирует проблему относительно уже известных проблем
- Придумывает пути ее решения
- Валидирует решения с целевой аудиторией
- После этого стартует разработка и раскатка решения на конечных пользователей.
Для того, чтобы этот процесс работал эффективно и без сбоев, команда продукта должна жить в непрекращающемся цикле «дискавери — деливери», потому что этот цикл помогает сберечь ресурсы и не выкатить в продакшен некорректное решение. Немного расшифрую: из семи пунктов выше видно, что сначала проблему глубоко изучают, потом формулируют решение, тестируют его на небольшом проценте пользователей и если все ок, то раскатывают на всех. Каждый из этих этапов помогает сократить количество ошибок в конечном решении.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах ProductSense и Продуктовое мышление.
Кто входит в команду продукта
Теперь посмотрим, какие конкретные роли и люди развивают продукт «Рейтинги и отзывы на модели». Чтобы было понятнее, расскажем, как наша команда проводила A/B-тест с показом рейтинга на карточке объявления. Небольшое уточнение: мы говорим об отзывах на модели товаров (например, iPhone 11), а не на продавцов (ими занимается отдельная команда). Начнем с дискавери-части команды — она включается в продуктовую задачу первой.
Менеджер продукта
Вот так выглядит автор этой статьи и менеджер продукта «Рейтинги и отзывы на модели товаров». Я формирую стратегическое видение продукта, исходя из этого определяю годовые и квартальные цели, генерирую гипотезы для достижения этих целей, а потом на основе бэклога формирую роадмап.
Иногда, если UX-исследователь занят, я могу самостоятельно провести исследования (но только с его одобрения). И это довольно типичная ситуация для Авито — многие наши продакты не прочь «засучить рукава» и отправиться в поля — к пользователям.
Рейтинги и отзывы – горизонтальный продукт, а значит, с ним сталкивается любой пользователь авито, независимо от того, какой тип товара он покупает: авто, электронику или недвижимость (товарные категории как раз и формируют вертикали). Именно поэтому к нам приходят заказчики из разных вертикалей, а также стейкхолдеры из команд «Покупательского опыта», «Автоматической и ручной модерации», «Поддержки» и т.п.
Солидную часть рабочего времени я трачу на то, чтобы убедиться — у всех заинтересованных сторон одинаковое видение продукта и все понимают, почему мы делаем или, что еще важнее, не делаем определенные фичи. В этом очень помогает система гейтов (наша статья на vc с примером работы по этой системе), по которой принято работать над продуктовыми инициативами в Авито.
Участие в работе над кейсом
Я составляла стратегию развития продукта «Рейтинги и отзывы на товары». Одним из пунктов было повышение видимости продукта на площадке. Сначала мы решили набрать первые несколько десятков тысяч отзывов и быть уверенными, что если покажем их пользователям, то у объявлений будет рейтинг модели; и только после достижения этого показателя стали показывать продукт более широкому кругу пользователей. Причина простая: если бы мы сразу рассказали об отзывах всем пользователям, они не стали бы им доверять — отзывов было бы слишком мало.
Когда отзывов набралось достаточно, мы решили рассказать о них — но все равно осторожно. Плюс в тот моменты мы еще не понимали, где именно на карточке объявления стоит расположить отзывы.
Дальше я расскажу о роли каждого из участников продуктовой команды. Однако перед этим важно упомянуть, что мы работаем именно как единая команда, а это значит, что и аналитик, и дизайнер, и любой другой участник могут присоединиться к решению любой задачи на любом этапе. А все участники дискавери-команды помимо своих прямых обязанностей практически по умолчанию принимают активное участие в обсуждении и выработке конечного решения.
Итак, совместно с дискавери-командой мы составили гипотезы перед запуском эксперимента, выставили желаемые показатели по сдвигу метрик, и я набросала мокапы. Дальше за дело взялся продуктовый дизайнер.
Дизайнер
Алексей руководит командой дизайна продукта в кластере Trust&Safety. Этот кластер занимается безопасностью пользователя на платформе Авито. Помимо того, что Лёша руководит дизайнерами кластера, он еще и совмещает роль дизайнера нашего продукта. В этой роли он делает следующее:
- Полноценно участвует в дискавери процессе.
- Продумывает логику смены экранов и создает прототипы для тестирования.
- Следит, чтобы интерфейс нашего продукта соответствовал дизайн-системе (набор паттернов и элементов интерфейса, которые используются в Авито).
- Участвует в тестировании прототипов, если это нужно.
- Финально корректирует макеты по результатам тестирования.
- Проводит дизайн-ревью перед раскаткой на пользователей. Это процесс, во время которого Алексей проверяет, насколько точно инженеры следовали макетам, не сдвинулась ли кнопка на пару пикселей вправо, соответствует ли цвет на проде цвету макета и т.п.
Благодаря работе Алексея наш продукт хорошо выглядит, понятен пользователям и не вызывает вопросов.
Участие в работе над кейсом
Алексей изучил мои мокапы, дал свою обратную связь и корректировки, предложил оптимальные места в карточке товара для отображения рейтинга, отрисовал макеты для десктопа и мобильных платформ и сделал из них кликабельные прототипы. В результате получились такие макеты:
После дизайнера к задаче подключается UX-исследователь.
UX-исследователь
Настя — старший UX-исследователь. Ее задача — биться за интересы пользователей. Она знает, как быстро протестировать гипотезы, когда провести качественное исследование с помощью фокус-групп, а когда выбрать side-by-side-тесты, как сформулировать вопрос, чтобы не подводить респондента к определенному ответу и выяснить его настоящую позицию.
На вход поступает бриф исследования — документ, который заполняет менеджер продукта и в котором описываются гипотезы, ожидания от исследования, ЦА и прочие детали — а Настя решает, как проверить эти гипотезы максимально точно и дешево.
Она же выступает главным адвокатом пользователей в команде, ведет бэклог пользовательских проблем, настраивает процессы регулярного сбора обратной связи и отслеживает CX-метрики.
Участие в работе над кейсом
До начала A/B-теста Настя изучила бриф на исследование (мы переживали, что придуманные макеты будут непонятны пользователям и поэтому решили проверить две гипотезы):
- Покупатели не поймут, что за рейтинг выведен на карточке, будут путать его с рейтингом продавца или рейтингом конкретного объявления.
- Покупатели не поймут, что их ждет при клике по кнопке «Читать все отзывы».
Изучив бриф, Настя составила скрипт интервью для исследования, организовала рекрут респондентов (в нашем случае это пользователи, которые выбирали на Авито автомобиль за последний месяц, выгрузку пользовательских данных делала я), организовала работу подрядчика, который приглашает респондентов на исследование.
После этого она провела опрос, проанализировала результаты и мы совместно приняли решение о том, какая из гипотез подтвердилась. Спойлер: ни одна из гипотез не подтвердились, так что нам не пришлось дорабатывать макеты.
Аналитик
Саша — наш аналитик. Он проводит аналитические исследования, составляет прогнозы, занимается логированием, дизайнит и проводит A/B-тесты с помощью нашей внутренней платформы A/B-central и анализирует их результаты.
Саша регулярно подходил ко мне с вопросом «А где дерево метрик?» — и благодаря его настойчивости у нас это дерево появилось. А значит, теперь мы понимаем связь между собранными отзывами и конверсией в покупку — не только логически, но и наглядно.
Участие в работе над кейсом
Саша дополнил ожидания по метрикам, формализовал критерии успеха эксперимента, согласовал со смежными командами количество пользователей в тесте, чтобы не пересекаться с другими тестами, которые были запущены примерно в то же время, и не допустить их влияния на результаты нашего теста, отслеживал изменение метрик во время теста и совместно со мной принял решение о группе-победителе (это A или B группа, которая лучше покажет себя в тесте и в последствии будет раскатана на 100% пользователей).
Помимо этого Саша плотно работал с инженерами в части логирования: он проверял, что все необходимые события будут попадать в систему аналитики и по результатам эксперимента мы можем быть уверены, что не упустили какие-то пользовательские действия.
Мы проводили тест около трех недель — пытались понять, стоит ли показывать тексты отзывов на самом объявлении. Забегая вперед скажу, что тексты отзывов на объявлении мы решили не показывать, потому что в этой группе упали критичные бизнес-метрики:
- Просмотр профиля продавца, с которого совершается значительный объем контактов (то есть звонков или сообщений продавцам).
- Просмотр рекомендованных объявлений. Это важная метрика, которая позволяет показать покупателю релевантные объявления, которые в свою очередь могут привести к сделке.
- Подписки на продавца, которые в долгосрочной перспективе генерируют контакты.
При этом в группе-победителе мы вырастили критичные метрики:
- Посещения карточки модели в среднем выросли на 30% на мобильных платформах и в веб-версии.
- Количество оставленных отзывов в среднем выросло на 70% и на мобильных платформах, и в веб-версии.
Все, что было описано выше — работа дискавери-команды. После предварительной проработки задачи и раннего тестирования гипотез, мы рассказываем деливери-команде свои идеи, а они анализируют их с точки зрения архитектуры платформы и технической реализации. Деливери-команда определяет, какие изменения нужно будет внести на бекенде, а какие — на фронтэнде, нагрузка на какие сервисы увеличится в тесте, где стоит заложить рост RPM, а также другие вопросы, которые могут повлиять на техническую составляющую продукта.
В кейсе про тексты отзывов мы сначала сформулировали гипотезы, убедились, что макеты теста понятны пользователям, подготовили дизайн в своей внутренней платформе A/B-central и определили критерии группы (критичные бизнес-метрики остаются без статзначимых изменений, метрики оставления отзывов растут, метрики посещения карточки модели растут), которую покатим на всех пользователей, и уже тогда пришли к деливери-команде и рассказали, какой тест хотели бы провести.
Технический руководитель
Это Тимур — он руководит командой разработки. Менеджер продукта в Авито не управляет разработчиками напрямую: его главный фокус — рост ценности продукта для пользователя. Поэтому для технического развития продукта существует выделенная роль технического лида — человека, который руководит командой инженеров.
Тимур составляет годовой и квартальный технический роадмап, формирует технические OKR (помимо продуктовых OKR команды ставят технические цели, которые позволяют отслеживать прогресс платформы продукта, например, доля тестов, мигрированных из монолита или процент покрытия продукта автотестами), выстраивает процессы в команде (например, фиче-драйвинг — когда инженер из команды назначается ответственным за новую фичу и контролирует все работы по ее запуску), найм.
Тимур — бывший фронтенд-инженер, выросший в техлида, плюс у него есть навыки бэкенд-разработчика. Поэтому если кто-то в команде заболел, а цель спринта критически важна, Тимур может закрыть его задачи.
К Тимуру можно прийти и честно сказать: «Я не понимаю, почему для запроса отзывов в новой категории нужно переписать существующий сервис», — и он очень понятно все объяснит.
Техлид и продакт — настоящие напарники, которые совместно отстаивают интересы команды и решают проблемы из серии «если мы не можем нанять своего андроид-разработчика, давай попросим ресурс у соседних команд».
Участие в работе над кейсом
Для запуска A/B-теста мы с Тимуром провели продуктовый груминг и детально изучили макеты. После этого он организовал технический груминг, где инженеры решали, как задачи по реализации поделятся между фронтендом и бэкендом. По результатам технического груминга Тимур сформировал Definition of Done, который позволил составить график работ. Критерии приемки на мобильных устройствах выглядели следующим образом:
В этом моменте к кейсу подключились инженеры, а Тимур сосредоточился на контроле задач.
Бэкенд-инженер
Игорь создает архитектуру продукта «Рейтинги и отзывы на модели», которая не видна пользователям, однако именно на ней держится продукт.
Его стек: Golang, PHP, есть еще некоторые конфиги на Bash, но в работе использует очень редко. У Игоря даже есть канал на YouTube, где он делится опытом программирования на Go.
Игорь поддерживает работоспособность нашего продукта, формирует архитектуру таким образом, чтобы она была готова к масштабированию и серьезным нагрузкам, проводит интеграцию со смежными сервисами Авито: например, мы плотно взаимодействуем с модерацией, поскольку весь контент, который видят пользователи, проходит автоматическую и ручную проверку перед публикацией на площадке.
Участие в работе над кейсом
При подготовке A/B-теста Игорь залогировал новые события, которые появились в процессе теста (например, переход с карточки объявления на отзывы при нажатии соответствующего блока), чтобы мы могли отследить изменение поведения пользователей и нововведения не прошли мимо. Помимо этого Игорь убедился, что при увеличении нагрузки наш продукт выдержит и не сломается.
Фронтенд-инженер
Слава разрабатывает интерфейсы для десктопной и мобильной версий рейтингов и отзывов на модели. Его основной язык программирования — Java Script. Слава разрабатывает сразу две платформы, в т.ч. мобильный веб, в котором существует куча разных нюансов и особенностей — например, адаптивная верстка, требования к производительности, реализация компонентов из iOS/Android, которые Mobile Avito Version (MAV) нативно не поддерживает.
Слава работает над актуальностью продукта и следит за тем, чтобы интерфейс отображался корректно, не было багов при реализации новых фичей.
Участие в работе над кейсом
Для проведения A/B-теста Слава реализовал вывод отзывов на странице объявления для двух платформ.
IOS- и Android-инженеры
Иван — IOS-разработчик, а Илья — Android-разработчик.
Они знают, как работают карточки модели (страница, на которой отображается вся информация о модели товара — в том числе и отзывы), поскольку технически именно на платформах IOS и Android они реализованы не так, как другие страницы Авито.
Участие в работе над кейсом
При подготовке A/B-теста ребята реализовали отображение отзывов не только на страничке объявления, но и на карточке модели, потому что к моменту вывода на этой платформе еще не было.
Мы заметили снижение метрик перфоманса на платформе IOS (эти метрики описывают скорость загрузки страницы). А если время загрузки критично увеличивается, это может негативно сказаться на CSAT. Выяснилось, что проблема была не только у нас, но и в соседних командах, где для отображения коллекций, на которых построены экраны, использовался определенный класс. Ее быстро пофиксили.
QA-инженер
Вадим — Quality Assurance-инженер. Он отвечает как за ручное тестирование платформ, так и за автотесты. Вадим профессиональный баг-хантер, который успевает отловить ошибки в поведении продукта до того, как это увидит пользователь. Это критически важная функция, потому что в Авито действует zero bug policy.
Вадим покрыл автотестами весомую часть продукта, и теперь мы оперативно можем отслеживать баги.
Участие в работе над кейсом
Когда мы готовились к проведению теста, Вадим вручную проверял работоспособность всех платформ, отлавливал неожиданное поведение страниц и следил за тем, чтобы инженеры исправили все найденные баги.
Вадим проводил ручное тестирование и покрывал автоматическими тестами страницу объявления, на которой проводился A/B-тест. В итоге мы получили следующую картину покрытия автотестами на мобильных платформах:
Что мы узнали по итогам теста
Перед проведением теста у нас было несколько гипотез о том, что произойдет, если мы выведем рейтинг модели на карточке объявления:
✅Увеличится количество посетителей карточки модели;
✅Увеличится количество собранных отзывов;
✅Увеличится количество просмотров блока рекомендаций;
✅Увеличится количество подписок на продавца;
✅Увеличится количество чтений отзывов на продавца;
✅Не уменьшатся критичные бизнес-метрики (например, количество контактов).
Проведение теста от изучения проблем до раскатки на 100% пользователей заняло 3 месяца и выглядело следующим образом:
В итоге мы раскатили на 100% пользователей группу, в которой показывали только рейтинг, но не показывали тексты отзывов, так как эта группа показала положительную динамику по первым двум гипотезам и не показала отрицательных результатам по метрикам из гипотез 3–5 — а это было очень важно, потому что в долгосрочной перспективе могло негативно сказаться на объеме контактов на Авито.
После релиза фичи ежедневное количество оставленных отзывов выросло на 20% в обеих категориях. Для нас это означает прирост органического трафика, увеличение UGC-контента на площадке, что положительно скажется на привлечении SEO-трафика.
Как строится ритм работы дискавери- и деливери-команд
Все команды в Авито живут двухнедельными спринтами, а значит, то, что дискавери-команда изучает в текущем спринте, скорее всего, попадет уже в ближайший деливери-спринт. Такой ритм помогает развивать продукт итерационно и заранее планировать нагрузку.
Но у деления команды на дискавери и деливери есть и потенциальный минус: если команда разработки не вовлечена в продуктовый процесс и просто делает таски из джиры, у нее может пропасть мотивация: когда не виден результат работы, интерес неизбежно падает.
Для того, чтобы у всей команды было одинаковое видение развития продукта и не возникало ситуаций, когда инженер не знает, зачем он выполняет определенную задачу, мы настроили несколько процессов:
- При найме мы обращаем внимание на то, насколько инженеру интересно погружаться в продуктовый контекст, вникать в проблемы пользователей и видеть ценность за задачами, которые предстоит реализовывать.
- Перед началом квартала менеджер продукта после согласования с дискавери-частью рассказывает, какие цели стоят перед продуктовой командой, как они вытекают из пользовательских сценариев, и рассказывает, что нужно от деливери, чтобы сценарий стал реальностью. Например, в прошлом квартале мы работали над увеличением количества отзывов в категориях Авто и Телефоны и сформировали такой OKR: «Рост доли просмотров объявлений по моделям, покрытым не менее, чем двенадцатью отзывами с фото или длиной более 75 символов».
- Менеджер продукта рассказывает всей команде о том, какие UX-тесты планируются в ближайшее время, и любой желающий может в них поучаствовать в качестве слушателя. Общение с пользователями помогает развить эмпатию и усилить желание доставить хороший продукт.
- При планировании спринта мы формируем объем работ исходя из приоритетов на квартал. Это помогает раз в две недели возвращаться к квартальным целям и вообще к смыслу существования продукта, а также помнить, зачем команда все-таки выполняет те самые таски из джиры.
- Любой член команды может предложить фичу, и дискавери-команда проведет исследование, чтобы понять, нужно ли ее реализовать и если да, то когда это лучше сделать — сейчас или через пару кварталов.
- Eat your own food! Мы сами регулярно оставляем отзывы. Это помогает увидеть результат своей работы и еще раз почувствовать, какое классное решение сделала команда.
С вакансиями продакт-менеджеров в Авито можно ознакомиться по этой ссылке.
