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