Привет, Хабр. Меня зовут Костя Шадрин, я ведущий менеджер продукта в Авито, отвечаю за юнит опыта работодателей. Юнит состоит их нескольких дискавери- и деливери-команд, чуть позже я поясню, чем они занимаются и отличаются.

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

Обязанности менеджера продукта

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

В Авито менеджеры продукта — часть кросс-функциональных продуктовых команд. 

Мы используем так называемый dual-track. Весь процесс продуктовой разработки от идеи до выкатки в продакшн идёт двумя параллельными потоками — discovery и delivery. 

Discovery — это проработка инициативы, качественные и количественные исследования, валидация проблем и решений. Этим процессом занимается дискавери-команда. В неё входят менеджер продукта, тимлид разработки, аналитик, bizdev-проджект-менеджер, дизайнер и UX-исследователь. 

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

У нас в юните такой дизайн команд выбран не случайно. Раньше мы пробовали работать одной большой командой, но так как и дискавери и деливери у нас построен по Scrum, встреч становится слишком много: дейли каждый день, product backlog refinement несколько раз в неделю, retro, planning и sprint review. Поэтому оптимальной конструкцией для нас стало разделение на несколько деливери и дискавери команд, которые работают над отдельными продуктами.

Если разработкой управляет тимлид, исследования проводит UX-исследователь, за аналитику отвечает продуктовый аналитик, а за дизайн — продуктовый дизайнер, что же делает менеджер продукта?

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

• Отвечает на вопросы: кто пользователи, зачем им твой продукт, какие у них потребности.

• Постоянно отслеживает метрики успеха и здоровья продукта.

• Генерирует, собирает и приоритезирует гипотезы улучшения продукта.

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

• Формирует бэклог продукта на основе качественных и количественных данных.

• Прорабатывает спеки и истории для продуктовых улучшений.

• Ставит продуктовые задачи команде и объясняет продуктовую логику: зачем, почему, для кого.

• Презентует результаты на командных мероприятиях.

• Проактивно обеспечивает прозрачность целей и результатов для стейкхолдеров.

• Учитывает интересы других юнитов и подразделений, видит картину целиком.

• Страхует тимлида в вопросах управления командой разработки: мониторит проблемы и предлагает решения.

Продуктовые процессы

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

Team Maturity Model

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

Working Backwards 

В прошлом году в Авито пришёл новый СРО — Амит Пурохит из Амазона. Он принёс с собой часть продуктовой культуры компании — фреймворк Working Backwards. Суть подхода заключается в том, чтобы двигаться в обратном направлении. 

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

Дальше к пресс-релизу пишется ещё один документ — FAQ (часто задаваемые вопросы). В нём мы отвечаем на ключевые часто задаваемые вопросы бизнеса и пользователей. 

Набор вопросов в FAQ можно и даже нужно адаптировать под свою компанию. Например, для крупных компаний важны вопросы, связанные с взаимодействием разных подразделений, в примере это FAQ 2 и FAQ 7. Для стартапа же они менее актуальны. 

Фреймворк Working Backwards помогает нам сократить время и количество усилий, необходимых для запуска нового продукта. Раньше нужно было подготовить презентацию, написать детальное текстовое описание и посчитать traction-модель. Модель — это огромная таблица с прогнозом развития продукта по ключевым метрикам на несколько лет вперёд. Теперь же требуется всего пара коротких документов. По моему опыту, пресс-релиз прекрасно укладывается в страницу, а FAQs могут занять ещё 5-6 страниц. 

Я как раз недавно рассказывал на Tinkoff Agile Conference о том, как в Авито прижился подход Working Backwards. Запись можно посмотреть на Ютубе, а презентацию и шаблоны документов скачать здесь.

Scaling Lean

Дальше в развитии продуктов мы используем Scaling Lean. 

Этапы развития продукта разбиваются на стадии — stages. Каждая такая стадия завершается gate. Это встреча, на которой происходит «защита» прогресса по продукту.

Самая первая стадия — New Opportunities Discovery. На ней как раз прорабатывается новая идея и пишется PR и FAQ. Здесь не нужно делать сложные качественные и количественные исследования, разрабатывать прототип и так далее. 

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

По итогам стадии назначается Gate 1 — встреча, на которой собираются СРО, CTO, другие руководители и стейкхолдеры, которые могут быть связаны с реализацией идеи. Все читают PR и FAQ, а потом менеджер продукта отвечает на вопросы. Если все важные вопросы покрыты, и в идее видят потенциал, продукт получает зелёный свет и переходит на следующую стадию.

Stage 2 посвящен Product Discovery. Здесь уже важно подтвердить свои гипотезы через качественные и количественные исследования. На этом этапе продакты проводят CustDev, делают fake door, UX-исследования, опросы. Можно собрать простой прототип и посмотреть, как с ним будут взаимодействовать пользователи. На этом этапе данных уже больше, поэтому можно построить трекшн-модель. Это модель роста продукта, в которую мы закладываем некоторые допущения и прогнозы по росту метрик в зависимости от продуктовых изменений, которые будем делать на следующих этапах. 

По итогам второй стадии проводится Gate 2, на котором обсуждается уже обновлённый PR, FAQ и трекшн-модель. Если результаты Product Discovery успешны, и мы видим потенциал в дальнейшей проработке продукта, то можно переходить на этап Product Delivery.

На третьем этапе появляются Minimum Lovable Product (MLP) и пользователи. Здесь мы уже можем посмотреть на реальных метриках, насколько наши прогнозы оправдались. По итогам проводится Gate 3, где принимается решение о запуске. Здесь как раз пригодится PR, который мы писали до этого: с минимальными доработками документ превращается в реальный пресс-релиз, на основе которого СМИ будут писать о нашем продукте.

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

Подробнее о Scaling Lean можно почитать в одноименной книге Ash Maurya.

Objectives and Key Results

Защищённые на гейтах продукты попадают на планирование и входят в состав OKR. 

Планирование OKR происходит раз в квартал. В нашем юните для приоритизации мы используем ICE (Impact, Confidence, Ease). Про фреймворк уже рассказывали коллеги из другой команды, поэтому подробно на процессе останавливаться не буду. 

Я немного модифицировал фреймворк: Impact мы теперь оцениваем не экспертно, а по специальной шкале, которая помогает оценивать вклад задачи в Revenue и Customer Experience. Важностью каждого из параметров можно управлять через вес. Например, если в каком-то из кварталов мы хотим сделать фокус на Customer Experience, то можем повысить его вес относительно Revenue. 

Confidence стандартно оцениваем по уровню проработки задачи: если она на стадии идеи, Confidence будет 1, если уже есть количественные подтверждения, например зелёный A/B-тест, то это 10. Ease оцениваем по сложности реализации: берём в расчёт не только сложность разработки, но и трудозатраты в дискавери. Отдельно оцениваем необходимые работы на стороне всех функций: продакта, аналитика, UX-исследователя и дизайнера.

В результате мы получаем приоритизированный бэклог и список Objectives & Key Results на квартал. Потом начинаются стандартные SCRUM-процессы. Мы используем стандартный набор встреч: PBR, планирование спринта, ретро и sprint review. 

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

Double Diamond 

После планирования и приоритизации, когда бэклог и список OKR сформированы, мы приступаем непосредственно к продуктовый работе. Здесь мы используем модель Double Diamond. Я думаю, большинство о ней знает, если же вам интересно — вот подробная статья на английском и её перевод. В Double Diamond от симптома мы переходим к проблемам, а от них — к набору решений. После того как из набора решений выбрано фокусное, задача передаётся в деливери-команду.

Зачем нужны процессы

Когда мы рассказываем про свою продуктовую культуру и процессы, у людей нередко возникает вопрос: «А что у вас со сроками и time to market, если вы постоянно пишете документы, защищаете гейты, что-то исследуете и ставите OKR?». Ответ — при отстроенных процессах time to market действительно может увеличиваться. 

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

Обычно результаты каких-то работ бывают двух типов: output и outcome. Output — это непосредственный результат выполнения действий или активностей. Например, новая фича. Outcome — эффект от выполненных действий. Обычно он появляется не сразу после их выполнения и даже может быть эффектом от нескольких outputs. Если ещё проще, output — это то, что сделали, а outcome — это то, что за счёт этого достигли.

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

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