Ретроспектива проекта: вопросы, сценарий и шаблон

Что такое ретроспектива проекта

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

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

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

Как подготовить команду

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

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

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

Сценарий ретроспективы и вопросы

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

Если обсуждение превращается в спор «кто обычно делает не так», верните его к эпизоду. Вместо «нам никогда не дают нормальные материалы» спросите: «Какого материала не хватало в этот раз и в какой момент это стало заметно?»

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

От жалобы — к проверяемому изменению

Команда готовила вебинар. За день до запуска выяснилось, что часть согласованных исправлений не попала в презентацию. На ретроспективе прозвучало: «Опять всё пришлось переделывать в последний момент». Само по себе это недовольство ещё не подсказывает решение.

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

Договорились проверить это на следующем учебном вебинаре. Координатор Марина создаёт список до начала подготовки; каждое замечание получает статус «принято», «в работе», «проверено» или объяснение отказа. За день до запуска редактор сверяет список с финальной презентацией.

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

Шаблон итогов ретроспективы

Проект и период:
Участники:
Что помогло и что сохраняем:

Выбранная проблема:
Наблюдения и конкретные примеры:
Предполагаемая причина:
Что пока неизвестно:

Какой эксперимент проводим:
Кто отвечает:
Срок подготовки:
Где фиксируем выполнение:
По какому признаку проверяем результат:
Когда обсуждаем результат:
Что решаем после проверки: [сохранить / изменить / прекратить]

Другие вопросы для следующего обсуждения:

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

• Границы обсуждения понятны.
• Факты отделены от предположений.
• Есть то, что команда хочет сохранить.
• Выбрано выполнимое изменение.
• Ответственный согласовал задачу.
• Назначен момент проверки результата.