Ретро - это не старость и ностальгия.

Ретро - важный инструмент менеджмента

Вот представьте. Вы едете семьёй (и детьми) в отпуск на машине. Заблудились, разругались в хлам, жена в истерике, дети в слезах, приехали с сильным опозданием. Вечером за ужином у вас есть два варианта. Первый: «а я говорил, надо было налево». Второй:

• навигатор повёл по закрытой дороге,
• маршрут никто не проверил заранее,
• а остановки на отдых не запланированы,
• карту заправок тоже особо не чекали (актуально на октябрь 2026)
• в следующий раз возьмем оффлайн карты, канистру бензина, детские игры, еду с собой и заложим побольше времени.

Первый разговор называется скандал. Второй - вполне приличное ретро.

Ретроспектива вообще - взгляд в прошлое, анализ уже созданных работ, событий или пройденных этапов.

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

В абсолютном большинстве компаний ретро скатывается в первый вариант: пятиминутка ненависти и продолжаем делать все то же самое (в надежде на иной результат).

Как и Когда проводить ретро на самом деле?

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

Кого зовем?

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

Что подготовить заранее

Больше фактов, меньше ощущений.

• Календарь проекта,
• план/факт по срокам и часам,
• себестоимость,
• критерии успеха, которые договаривались в начале.
• итог проекта.

Как идёт сам разбор

1️⃣ разбираем Факты (10 минут).

Смотрим хронологию, цифры, итоги.

2️⃣ Что сработало (10 минут).

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

3️⃣ Что пошло не так и почему (30 минут).

Главный блок. На каждую проблему задаём вопрос «почему» несколько раз подряд, пока не доберёмся до причины, а не симптома. «Сорвали сроки» это симптом. «Задачу поставили без критериев, и пресейл три раза переделывал» это причина.

4️⃣ Решения (15 минут).

Шаги к неповторению косяков . Ставим по смарту: У каждого есть владелец и срок.

5️⃣ Проверка прошлых решений (5 минут).

Что договаривались изменить в прошлый раз и что реально изменилось.

Обязательные Правила, без которых ретро скатывается в скандал 1️⃣Разбираем систему, а не людей.

«Пресейл не проверил архитектуру» это поиск виноватого. «У нас нет шага проверки архитектуры перед отправкой КП» - это полезная находка для исправления.

2️⃣Ведущий не участник разбора. Он не заинтересован в отбелении или утоплении команды, следит за временем и не даёт спору уйти в оборону. Хороший вариант: позвать человека из соседней команды.

3️⃣Всё сказанное остаётся в комнате, в отчёт идут только решения (сухо, без грязи)

4️⃣Если кто-то молчит, спросить напрямую и без нажима: «Что показалось тебе самым неудобным на проекте?» Раз приглашен - значит должен высказаться.

Делаем выводы правильно:

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

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

Артефакты от ретро:

Сделай мини отчет:

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