Как проводить продуктовые ретроспективы и ревью

Главное за 30 секунд

• Ретроспектива и продуктовое ревью — это разные встречи с разными целями: не смешивать
• Ретроспектива проводится в конце каждого спринта после ревью и до планирования
• Цель ретроспективы не выговориться, а договориться о конкретных улучшениях
• Решения с ретро без ответственного и срока — это просто пожелания
• Форматы ретро стоит менять каждые три-четыре спринтов чтобы команда не теряла вовлеченность
• Перформанс-ревью для продактов проводится отдельно, раз в полгода, и оценивает рост человека, а не результат спринта
• Лучший инструмент для ретро тот с которым команда умеет работать, а не самый функциональный

Марти Каган, автор книги Inspired: «Лучшие продуктовые команды не те у которых меньше проблем. А те которые быстрее их находят и исправляют.»

Продуктовое ревью: как оценивать результаты итерации

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

Ревью проводится в конце каждого спринта или раз в две недели, если команда не работает по scrum и agile. В Авито перформанс-ревью для продактов проходит раз в полгода — это оценка роста специалиста. Продуктовое ревью короче и чаще: его цель не оценить человека, а оценить результат работы над продуктом за период.

Структура продуктового ревью

Хорошее ревью строится по четырем блокам.

• Результаты спринта. Команда смотрит что было запланировано и что реально сделано. Не просто список задач, а соответствие целям спринта. Если цель спринта была увеличить activation rate, смотрят именно на эту метрику, а не на количество закрытых тикетов.
• Разбор метрик. Продакт показывает ключевые показатели продукта в динамике. Что изменилось после запуска, что не изменилось и почему. Аналитик может участвовать в этом блоке и помогать интерпретировать данные. Важно обсуждать не только позитивные изменения, но и то что не сработало.
• Демо. Команда показывает что было построено за спринт. Это не презентация для стейкхолдеров, а живая демонстрация для всей команды. Разработчики показывают готовый функционал, дизайнеры — финальные решения. Каждый участник команды видит общий результат, а не только свой кусок работы.
• Решения и приоритеты. По итогам ревью команда договаривается что идет в следующий спринт и почему. Это не планирование спринта, но входные данные для него. Здесь важно зафиксировать конкретные решения письменно, иначе через неделю все вспомнят встречу по-разному.

Кто участвует?

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

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

Продуктовое ревью работает только, если команда относится к нему как к инструменту принятия решений, а не как к отчетной встрече перед руководством.

Ретроспектива: как улучшать процессы, а не просто жаловаться

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

Джефф Сазерленд, сооснователь Scrum: «Ретроспектива — это место где команда берет ответственность за свой процесс. Не менеджер, не скрам-мастер, а вся команда целиком.»

Что такое ретроспектива и зачем она нужна

Ретроспектива спринта — это регулярная встреча команды в конце каждого спринта, на которой обсуждают не что построили, а как работали. Цель ретроспективы одна: найти области для улучшения и договориться о конкретных изменениях. В agile-методология это одна из ключевых церемоний scrum наравне с планированием и daily scrum.

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

Три вопроса, которые работают

Базовая структура любой ретроспективы строится вокруг трех вопросов.

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

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

• Start/Stop/Continue. Самый простой и понятный формат. Команда обсуждает что нужно начать делать, что прекратить и что продолжать. Хорошо работает для новых команд которые только начинают проводить ретроспективу.
• 4Ls: Liked, Learned, Lacked, Longed for. Более глубокий формат который помогает командам обсуждать не только процессы, но и командный опыт. Что понравилось, чему научились, чего не хватало и чего хотелось бы больше. Подходит для команд которые хотят уйти от шаблонного ретро.
• Mad/Sad/Glad. Формат с акцентом на эмоциональное состояние команды. Что расстроило, что огорчило и что порадовало за время спринта. Полезен когда команда переживает сложный период или нужно проверить общий настрой перед важной итерацией.
• Sailboat. Визуальный формат, где команда рисует лодку с парусом и якорем. Парус — это что помогает двигаться вперед. Якорь — что тормозит. Хорошо работает в Miro для распределенных команд.

Как фасилитировать ретро, чтобы говорили все

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

• Первая: анонимный сбор тем до встречи. Каждый участник команды пишет свои наблюдения в общий документ или форму до начала ретро. Это снижает давление группы и дает голос тем кто обычно молчит на встречах.
• Вторая: голосование за темы. Перед обсуждением команда проголосовать за самые важные темы. Время на обсуждение распределяется пропорционально голосам. Так команда не застревает на мелких вопросах и успевает обсудить с командой действительно важное.
• Третья: тайм-бокс на каждую тему. Фасилитатор ставит таймер — обычно 5-10 минут на тему. Это дисциплинирует и не дает одному вопросу съесть все время ретро.

Как фиксировать решения и отслеживать их выполнение

Ретроспективу в конце каждого спринта которая не заканчивается письменным планом действий — можно считать потраченным временем. Каждое решение должно иметь ответственного и срок.

Хороший формат фиксации: конкретное улучшение, ответственный член команды, срок до следующем ретро. Решения хранятся в общем документе и открываются в начале следующей ретроспективы. Команда смотрит что было выполнено, что нет и почему.

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

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

В чем разница понятий и как совмещать

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

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

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

Правильный порядок в конце спринтов выглядит так: сначала ревью, потом ретро, потом планирование следующего спринта. Каждая встреча питает следующую: выводы ревью становятся контекстом для ретро, выводы ретро улучшают планирование.

Перформанс-ревью для продактов

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

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

Как оценивать продакта

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

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

Профессиональный рост. Какие новые навыки освоил продакт за период, какие зоны роста закрыл из прошлого ревью, какие новые вызовы взял на себя. Без этого измерения перформанс-ревью превращается в оценку прошлого без вектора на будущее.

Junior, Middle, Senior: разные критерии оценки

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

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

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

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

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

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

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

Чеклист по готовности

Ретро и ревью работают только когда они регулярный и когда команда относится к ним как к рабочим инструментам а не формальным встречам. Этот чеклист помогает быстро проверить готовность к каждому формату.

Перед продуктовым ревью

• Подготовлены метрики спринта в динамике, а не просто список закрытых задач
• Готово демо для всей командой, каждый участник знает что показывает
• Цели спринта зафиксированы заранее и команда сверяется именно с ними
• Решения по итогам встречи будут записаны и станут входом для планирование следующего спринта

Перед ретроспективой

• Команда знает формат ретроспективы заранее и есть время подготовиться
• Настроен инструмент для совместной работы — Miro, FigJam или хотя бы общий документ
• Первым пунктом повестки стоит разбор решений с прошлого ретро
• Фасилитатор готов держать тайм-бокс и давать слово тихим участникам
• По итогам встречи будет зафиксирован план действий с ответственными и сроками

Признаки что встреча прошла хорошо

• Говорили не только двое, каждый участник команды высказался
• Команда договорилась о конкретных шагах а не просто обсудила проблемы
• Решения записаны и у каждого есть ответственный
• На следующем ретро команда откроет этот список и проверит выполнение

Заключение

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

Проверьте свое ближайшее ретро. Есть ли в повестке разбор решений с прошлой встречи. Если нет, добавьте этот пункт первым. Это одно изменение сразу повышает ценность встречи для всей команды.

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

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

Проводить ретроспективы полезно только, если команда верит что ее голос влияет на изменения. Это доверие строится не за одну встречу, а через последовательное выполнение договоренностей из спринта в спринт. Начните с малого и команда сама начнет ценить этот формат.