Что делаешь при проведении ретроспективы?

Мой подход к проведению эффективной ретроспективы

Как IT Project Manager с более чем 10-летним опытом, я рассматриваю ретроспективу не как формальную процедуру, а как ключевой инструмент непрерывного улучшения команды и процессов. Моя практика проведения ретроспектив строится на нескольких фундаментальных принципах и конкретных действиях.

Подготовительная фаза: создание безопасной среды

Перед самой встречей я уделяю особое внимание подготовке:

• Определяю фокус ретроспективы: анализируем ли мы конкретный спринт, релиз или проблемный инцидент
• Выбираю подходящий формат в зависимости от контекста (Start/Stop/Continue, 4L, Mad/Sad/Glad, морская звезда и др.)
• Собираю предварительные данные: метрики спринта (velocity, burn-down), обратную связь от стейкхолдеров, данные мониторинга
• Готовлю визуальные материалы и ретро-доску (в Miro, Mural или физическую)
• Напоминаю команде о правилах: "без обвинений", "активное слушание", "фокус на процессах, а не людях"

Структура проведения ретроспективы

Сама ретроспектива следует проверенному формату:

graph TD
    A[Приветствие и правила] --> B[Сбор данных]
    B --> C[Генерация идей]
    C --> D[Приоритизация]
    D --> E[План действий]
    E --> F[Завершение]

1. Сбор данных и фактов

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

# Пример структурирования данных для анализа
retro_data = {
    "sprint_metrics": {
        "planned_vs_delivered": calculate_completion_rate(),
        "blocker_analysis": identify_main_blockers(),
        "team_sentiment": collect_anonymous_feedback()
    },
    "what_went_well": [],
    "what_can_be_improved": [],
    "action_items": []
}

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

2. Глубокий анализ проблем

Вместо поверхностного обсуждения, я применяю технику "5 почему" для выявления корневых причин:

• Проблема: "Сервер упал во время деплоя"
• Почему 1: "Автоматические тесты не обнаружили проблему"
• Почему 2: "Тесты не покрывают интеграцию с новой библиотекой"
• Коренная причина: "В процесс код-ревью не включена проверка покрытия тестами"

3. Генерация решений и приоритизация

Команда совместно генерирует идеи улучшений, которые мы затем оцениваем по двум осям:

• Воздействие на эффективность
• Усилия для реализации

Ключевые техники, которые я применяю

• Анонимное голосование для приоритизации проблем
• Визуальное управление временем с использованием таймеров для каждого этапа
• Техника "молчаливого мозгового штурма" чтобы избежать доминирования более громких участников
• Ретроспектива ретроспектив - периодический анализ эффективности самих встреч

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

Самая критическая часть - превращение insights в действия:

## Action Plan for Sprint 24
### Высокий приоритет
- [ ] Внедрить checklist для код-ревью (ответственный: Team Lead)
- [ ] Создать шаблон для документации API (ответственный: Senior Dev)
- [ ] Провести workshop по тестированию (срок: до 15.04)

### Мониторинг выполнения
- [ ] Добавить action items в бэклог следующего спринта
- [ ] Назначить регулярные checkpoints по прогрессу
- [ ] Включить обсуждение progress в daily stand-ups

Измерение эффективности ретроспектив

Я отслеживаю несколько метрик, чтобы оценить результативность:

1. Процент завершенных action items (цель: >80%)
2. Улучшение ключевых метрик (velocity, качество кода, удовлетворенность команды)
3. Регулярность проведения и посещаемость
4. Количество повторяющихся проблем (должно снижаться)

Адаптация под контекст команды

Для распределенных команд я использую цифровые инструменты (FunRetro, Retrium), для колоцированных - физические доски и стикеры. В кризисных ситуациях применяю формат "короткой ретро" на 30 минут с фокусом на одну ключевую проблему.

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