Как устроена работа над продуктом в Авито

И как распределена ответственность в командах.

Стиль работы над продуктом и эффективность этой работы во многом зависят от структуры продуктовой команды и взаимодействия между разными ролями. За что отвечает аналитик, какие вопросы берет на себя продакт, что может делегировать другим отделам профессиональный исследователь и есть ли выделенная команда разработки? Ответы на эти вопросы определяют текущее состояние и динамику развития продукта.

Лиза Князева, ведущий менеджер продукта в «Авито», на примере команды «Рейтингов и отзывов на модели» объяснила, как устроены их продуктовые команды, кто и за что отвечает и как команда работает над продуктом.

У каждого продукта в Авито есть собственная выделенная команда, работа которой строится по принципам triple diamond (теория отлично изложена в примере Zendesk):

Стандартный процесс работы продуктовой команды выглядит так:

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

Теперь посмотрим, какие конкретные роли и люди развивают продукт «Рейтинги и отзывы на модели». Чтобы было понятнее, расскажем, как наша команда проводила A/B-тест с показом рейтинга на карточке объявления. Небольшое уточнение: мы говорим об отзывах на модели товаров (например, iPhone 11), а не на продавцов (ими занимается отдельная команда).

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

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

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

Иногда, если UX-исследователь занят, я могу самостоятельно провести исследования (но только с его одобрения). И это довольно типичная ситуация для Авито — многие наши продакты не прочь «засучить рукава» и отправиться в поля — к пользователям.

Рейтинги и отзывы – горизонтальный продукт, а значит, с ним сталкивается любой пользователь авито, независимо от того, какой тип товара он покупает: авто, электронику или недвижимость (товарные категории как раз и формируют вертикали). Именно поэтому к нам приходят заказчики из разных вертикалей, а также стейкхолдеры из команд «Покупательского опыта», «Автоматической и ручной модерации», «Поддержки» и т.п.

Солидную часть рабочего времени я трачу на то, чтобы убедиться — у всех заинтересованных сторон одинаковое видение продукта и все понимают, почему мы делаем или, что еще важнее, не делаем определенные фичи. В этом очень помогает система гейтов (наша статья на vc с примером работы по этой системе), по которой принято работать над продуктовыми инициативами в Авито.

Участие в работе над кейсом

Я составляла стратегию развития продукта «Рейтинги и отзывы на товары». Одним из пунктов было повышение видимости продукта на площадке. Сначала мы решили набрать первые несколько десятков тысяч отзывов и быть уверенными, что если покажем их пользователям, то у объявлений будет рейтинг модели; и только после достижения этого показателя стали показывать продукт более широкому кругу пользователей. Причина простая: если бы мы сразу рассказали об отзывах всем пользователям, они не стали бы им доверять — отзывов было бы слишком мало.

Когда отзывов набралось достаточно, мы решили рассказать о них — но все равно осторожно. Плюс в тот моменты мы еще не понимали, где именно на карточке объявления стоит расположить отзывы.

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

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

Этот кластер занимается безопасностью пользователя на платформе Авито. Помимо того, что Лёша руководит дизайнерами кластера, он еще и совмещает роль дизайнера нашего продукта. В этой роли он делает следующее:

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

Участие в работе над кейсом

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

После дизайнера к задаче подключается UX-исследователь.

Ее задача — биться за интересы пользователей. Она знает, как быстро протестировать гипотезы, когда провести качественное исследование с помощью фокус-групп, а когда выбрать side-by-side-тесты, как сформулировать вопрос, чтобы не подводить респондента к определенному ответу и выяснить его настоящую позицию.

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

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

Участие в работе над кейсом

До начала A/B-теста Настя изучила бриф на исследование (мы переживали, что придуманные макеты будут непонятны пользователям и поэтому решили проверить две гипотезы):

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

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

Он проводит аналитические исследования, составляет прогнозы, занимается логированием, дизайнит и проводит A/B-тесты с помощью нашей внутренней платформы A/B-central и анализирует их результаты.

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

Участие в работе над кейсом

Саша дополнил ожидания по метрикам, формализовал критерии успеха эксперимента, согласовал со смежными командами количество пользователей в тесте, чтобы не пересекаться с другими тестами, которые были запущены примерно в то же время, и не допустить их влияния на результаты нашего теста, отслеживал изменение метрик во время теста и совместно со мной принял решение о группе-победителе (это A или B группа, которая лучше покажет себя в тесте и в последствии будет раскатана на 100% пользователей).

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

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

При этом в группе-победителе мы вырастили критичные метрики:

Все, что было описано выше — работа дискавери-команды. После предварительной проработки задачи и раннего тестирования гипотез, мы рассказываем деливери-команде свои идеи, а они анализируют их с точки зрения архитектуры платформы и технической реализации. Деливери-команда определяет, какие изменения нужно будет внести на бекенде, а какие — на фронтэнде, нагрузка на какие сервисы увеличится в тесте, где стоит заложить рост 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 они реализованы не так, как другие страницы Авито.

Участие в работе над кейсом

При подготовке A/B-теста ребята реализовали отображение отзывов не только на страничке объявления, но и на карточке модели, потому что к моменту вывода на этой платформе еще не было.

Мы заметили снижение метрик перфоманса на платформе IOS (эти метрики описывают скорость загрузки страницы). А если время загрузки критично увеличивается, это может негативно сказаться на CSAT. Выяснилось, что проблема была не только у нас, но и в соседних командах, где для отображения коллекций, на которых построены экраны, использовался определенный класс. Ее быстро пофиксили.

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

Вадим покрыл автотестами весомую часть продукта, и теперь мы оперативно можем отслеживать баги.

Участие в работе над кейсом

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

Вадим проводил ручное тестирование и покрывал автоматическими тестами страницу объявления, на которой проводился A/B-тест. В итоге мы получили следующую картину покрытия автотестами на мобильных платформах:

Перед проведением теста у нас было несколько гипотез о том, что произойдет, если мы выведем рейтинг модели на карточке объявления:

Проведение теста от изучения проблем до раскатки на 100% пользователей заняло 3 месяца и выглядело следующим образом:

В итоге мы раскатили на 100% пользователей группу, в которой показывали только рейтинг, но не показывали тексты отзывов, так как эта группа показала положительную динамику по первым двум гипотезам и не показала отрицательных результатам по метрикам из гипотез 3–5 — а это было очень важно, потому что в долгосрочной перспективе могло негативно сказаться на объеме контактов на Авито.

После релиза фичи ежедневное количество оставленных отзывов выросло на 20% в обеих категориях. Для нас это означает прирост органического трафика, увеличение UGC-контента на площадке, что положительно скажется на привлечении SEO-трафика.

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

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

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

Редактор: Тимур Тукаев

Источник