Как часто обращаешься за ревью?

Практика проведения ревью в работе PM

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

1. Виды ревью и их частота

Ревью концепции (PRD/Strategy):

• Когда: на этапе, когда гипотеза четко сформулирована, но разработка не началась
• Частота: 1-2 раза на проект/фичу
• С кем: лидер группы, Head of Product, иногда CEO
• Цель: убедиться, что решение выравнено со стратегией

Ревью дизайна (Design Review):

• Когда: когда есть прототип или мокапы, до разработки
• Частота: 1-2 раза на фичу (инициальный и итеративный)
• С кем: дизайнеры, иногда инженеры и PM
• Цель: убедиться, что UX хороший и технически реализуем

Ревью в процессе разработки (Mid-sprint review):

• Когда: в середине спринта или при существенных изменениях
• Частота: еженедельно или по мере необходимости
• С кем: техлид, архитектор, иногда PM
• Цель: убедиться, что разработка идет в правильном направлении

Ревью перед релизом (Release Review):

• Когда: за несколько дней до выката в prod
• Частота: 1 раз перед каждым релизом (обязательно)
• С кем: PM, инженер, QA, иногда технический директор
• Цель: убедиться, что все работает и готово к пользователям

Ревью после релиза (Post-release Review):

• Когда: через неделю-две после выката
• Частота: 1 раз на крупную фичу или изменение
• С кем: вся команда (инженеры, дизайнеры, PM, аналитика)
• Цель: проанализировать, как фича прижилась, есть ли баги

2. Когда ревью критично обязательно

Всегда делать ревью:

• Изменение бизнес-модели или ценообразования
• Изменение архитектуры или инфраструктуры
• Рискованные решения (могут повлиять на performance, retention, revenue)
• Изменения в функционале, которые касаются многих пользователей
• Любые интеграции с внешними сервисами

Можно пропустить ревью:

• Маленькие баги и optimization fixes
• Копирайт/текстовые изменения
• Визуальные полировки без логики
• Задачи, которые явно выравнены с уже одобренной фичей

3. Процесс ревью: как проводить эффективно

Подготовка к ревью:

• Подготовить материалы (PRD, мокапы, тестовый аккаунт)
• Заранее отправить ссылку/документ для ознакомления
• Указать, какой именно фидбэк нужен
• Выбрать подходящее время (не в спешке)

Во время ревью:

• Показать решение (дизайн, прототип или live feature)
• Объяснить, как это решает проблему пользователя
• Ответить на вопросы
• Записать фидбэк (даже если ты не согласен)
• НЕ защищать решение, если видны реальные проблемы

После ревью:

• Документировать все замечания
• Группировать: must-have (блокирует релиз), nice-to-have (можно потом)
• Обновить PRD или дизайн на основе одобрений
• Закоммитить решение, только если критические замечания решены

4. Инструменты и артефакты

Документы для ревью:

• PRD (Product Requirements Document) — текстовое описание
• Design specs — Figma с аннотациями
• Architecture diagrams — диаграммы системы
• User stories — в Jira или Notion
• Risk assessment — потенциальные проблемы

Инструменты для synchronous ревью:

• Zoom/Google Meet для живого обсуждения
• Figma для совместной работы
• Notion/Google Docs для документирования

5. Культура и психология ревью

Почему люди избегают ревью:

• Боятся критики на идее
• Ранят их в ego
• Они интровертированны или боятся конфликтов

Как создать здоровую культуру:

• Ревью документа/дизайна, не человека
• Благодарить за фидбэк, даже если он сложный
• Объяснять, что ревью делает решение лучше
• Не ставить ревью как наказание
• Поощрять разные точки зрения

Правило трех:

• Если трое людей видят одну и ту же проблему — это точно проблема
• Если один видит проблему — обсудить дальше
• Если никто не видит — может быть нормально

6. Частота и баланс

Свежий найденный подход: "регулярное ревью без микроменеджмента":

• Критические ревью (PRD, дизайн, архитектура): 1-2 раза за проект
• Регулярные синхроны: раз в неделю на team meeting
• Release review: обязательно перед каждым выкатом
• Post-release: раз в две недели на retrospective

Признаки избытка ревью:

• Проекты зависают в ревью больше чем на неделю
• Люди боятся предложить идеи
• Очень много микроменеджмента

Признаки дефицита ревью:

• Много багов выходит в prod
• Нет alignment между командами
• Люди удивлены решениями, которые шли параллельно

Заключение

Ревью — это не бюрократия, а инвестиция в качество продукта и alignment команды. Хороший PM балансирует между постоянной обратной связью и скоростью разработки. Частота ревью должна расти пропорционально рискам и масштабу решения.