Ретроспектива (Retrospective) — регулярная встреча команды, посвящённая не результату работы, а тому, как команда работала: что получилось, что мешало, что стоит изменить в следующем периоде. В отличие от совещания по статусу задач, ретроспектива смотрит на сам процесс работы команды как на предмет улучшения — и именно поэтому она встроена как обязательная церемония в Scrum и большинство Agile-фреймворков.
Происхождение и исследовательская база
Концептуальный фундамент заложил Норм Керт (Norm Kerth) в книге «Project Retrospectives: A Handbook for Team Reviews» (2001) — там же сформулирована знаменитая Prime Directive (Главная директива): "Независимо от того, что мы обнаружим, мы искренне верим, что каждый делал наилучшую работу, какую мог, учитывая то, что он знал в тот момент, свои навыки и способности, доступные ресурсы и ситуацию". Это не просто дружелюбный лозунг, а рабочая установка, которая переключает разговор с поиска виноватых на разбор системы и обстоятельств — именно она делает возможной честность в комнате.
Стандартную методологическую структуру из пяти этапов дали Эстер Дерби и Диана Ларсен (Esther Derby, Diana Larsen) в книге «Agile Retrospectives: Making Good Teams Great» (2006), предисловие к которой написал Кен Швабер, соавтор Scrum — что закрепило ретроспективу как обязательный элемент именно Scrum-цикла, отдельно от общей Agile-философии.
Ключевые идеи и принципы
Принцип: пять этапов, а не один общий разговор
Дерби и Ларсен формализовали структуру: Set the Stage (создать безопасную атмосферу, напомнить Prime Directive) → Gather Data (собрать факты и ощущения о периоде — что случилось, а не сразу оценки) → Generate Insights (найти закономерности и причины) → Decide What to Do (выбрать несколько конкретных действий с владельцем) → Close (подтвердить действия, поблагодарить команду, быстро оценить саму встречу). Пропуск любого этапа систематически ослабляет результат — например, переход сразу к решениям без сбора данных ведёт к спорам мнений вместо фактов.
Принцип: безопасность важнее откровенности "в лоб"
Без ощущения психологической безопасности участники либо молчат о реальных проблемах, либо превращают встречу в поиск виноватого. Prime Directive Керта — не формальность, а предпосылка, без которой все остальные этапы дают искажённые данные.
Принцип: разговор бесполезен без закрытого цикла
Ретроспектива без реального выполнения принятых на прошлой встрече действий превращается в ритуал без последствий — команда фиксирует одни и те же проблемы раз за разом, ничего не меняя. Здоровая ретроспектива всегда начинается с проверки: что из решённого в прошлый раз реально сделано.
Принцип: Start/Stop/Continue — простейший, но рабочий формат сбора данных
Среди десятков форматов этапа Gather Data (4Ls, Mad/Sad/Glad, Sailboat) Start/Stop/Continue остаётся одним из самых быстрых и понятных: что стоит начать делать, что прекратить, что продолжать — три однозначных вопроса без интерпретаций.
Регулярно, но не бесплодно — ретроспектива работает, только если то, что решили в прошлый раз, реально произошло.
Ограничения, слепые зоны и критика
Ретроспектива, проводимая формально "потому что так положено в Scrum", без реальной вовлечённости команды, превращается в потерю времени — 30-60 минут регулярно без ощутимого эффекта на работу команды со временем размывают доверие к самому формату.
Метод предполагает относительно стабильный состав команды на протяжении нескольких итераций подряд — сильная текучка или частая смена состава лишает смысла разговор "как МЫ работали", потому что "мы" каждый раз разные.
В компаниях с высоким уровнем страха перед руководством (низкая психологическая безопасность) формат Start/Stop/Continue легко вырождается в перечисление безобидных мелочей, обходя стороной реальные системные проблемы — форма соблюдена, суть потеряна.
Типовые ошибки
Ошибка 1: пропуск этапа Gather Data — сразу переходят к решениям.
Обсуждение начинается с "что будем менять", минуя сбор фактов о том, что реально произошло — решения принимаются на основе впечатлений, а не общей картины.
Как избежать: выделить отдельное время именно на сбор наблюдений всей команды, прежде чем переходить к обсуждению причин и решений.
Ошибка 2: действия принимаются, но не проверяются на следующей встрече.
Каждая ретроспектива заканчивается новым списком действий, но никто не возвращается к проверке предыдущего списка — реального изменения не происходит.
Как избежать: начинать каждую ретроспективу с явной проверки выполнения действий с прошлой встречи, фиксируя процент выполнения как отдельную метрику.
Ошибка 3: слишком много действий принято одновременно.
Команда формулирует 10-15 пунктов "что улучшить" — в реальности не выполняется почти ничего, потому что фокуса не было изначально.
Как избежать: ограничивать число принятых действий 2-3 на одну ретроспективу — с явным владельцем и сроком у каждого.
Ошибка 4: ретроспектива превращается в разбор конкретных людей, а не процесса.
Обсуждение соскальзывает в "кто виноват в задержке", вместо "что в процессе позволило задержке произойти" — команда теряет психологическую безопасность.
Как избежать: фасилитатору явно возвращать разговор к Prime Directive и переформулировать личные претензии в вопросы о процессе и системе.
Ошибка 5: формат никогда не меняется, и команда выгорает от рутины.
Одна и та же доска Start/Stop/Continue месяцами подряд снижает вовлечённость — участники отвечают формально, не задумываясь.
Как избежать: периодически менять формат этапа Gather Data (Mad/Sad/Glad, 4Ls, Sailboat), сохраняя структуру пяти этапов неизменной.
Главное, что нужно знать
Ретроспектива смотрит на ПРОЦЕСС работы команды, а не на результат конкретных задач.
Пять этапов по Дерби и Ларсен (2006): Set the Stage → Gather Data → Generate Insights → Decide What to Do → Close.
Prime Directive Керта (2001) — рабочая установка психологической безопасности, без которой данные искажаются.
Без проверки выполнения действий с прошлой встречи ретроспектива вырождается в разговор без последствий.
Start/Stop/Continue — простой формат сбора данных, но не единственный; менять формат периодически полезно для вовлечённости.
План внедрения
Неделя 1 — первая ретроспектива. Провести первую встречу по пяти этапам, использовать формат Start/Stop/Continue, зафиксировать 2-3 конкретных действия с владельцами.
Недели 2-4 — регулярность и проверка цикла. Установить фиксированную периодичность (обычно раз в спринт/итерацию), каждую следующую встречу начинать с проверки выполнения действий предыдущей.
Месяц 2 — фасилитация и разнообразие форматов. Выделить постоянного или ротирующегося фасилитатора, начать чередовать форматы этапа Gather Data для поддержания вовлечённости.
Далее: поддержание и обновление. Отслеживать процент выполнения действий как метрику здоровья самого процесса ретроспектив; при устойчивом падении вовлечённости — менять формат или обсуждать саму практику ретроспектив на мета-уровне.
Как реализовать этот план с помощью фрейма «Retrospective» в OrgDevTools
Фрейм «Retrospective» в OrgDevTools напрямую поддерживает ключевые шаги плана внедрения. Начинайте КАЖДУЮ встречу с секции «Замкнутый цикл — выполнены ли действия с прошлой ретро» — введите число принятых на прошлой встрече действий и сколько из них реально выполнено; фрейм автоматически рассчитает процент выполнения и подсветит цветом, если он ниже 40% — прямая защита от Ошибки 2 из списка типовых ошибок выше.
На этапе Gather Data (сбор данных, недели 1+) заполняйте доску «Start/Stop/Continue» — три колонки конкретных наблюдений команды; это структурированная альтернатива свободному обсуждению, которая не даёт разговору соскользнуть в обсуждение отдельных людей вместо процесса.
На этапе Decide What to Do заполните секцию «Действия на следующий период» — конкретный список с ответственным и сроком у каждого пункта; именно эти цифры (сколько действий и сколько выполнено) станут входными данными для расчёта процента выполнения на СЛЕДУЮЩЕЙ ретроспективе, замыкая цикл.