Ретроспектива проекта — это встреча команды по итогам завершённого проекта, крупного релиза или фазы: что помогло дойти до результата, что мешало и какие уроки взять в следующий проект. Проводят её один раз, в первые одну-две недели после закрытия — пока команда не разошлась по другим задачам и помнит детали. На выходе — пять-семь записанных уроков и два-три действия с владельцами и сроками. В отличие от ретро спринта, которое чинит процесс каждые две недели, проектная ретро смотрит на дистанцию в месяцы и отвечает на вопрос «что мы теперь знаем такого, чего не знали на старте».
Чем ретроспектива проекта отличается от ретро спринта
Спринтовое ретро и проектное построены на одной механике — молчаливый сбор карточек, группировка, голосование, обсуждение, — но отвечают на разные вопросы. Спринтовое: «что поправить в следующие две недели». Проектное: «что мы теперь знаем и кому это передать».
| Ретро спринта | Ретроспектива проекта | |
|---|---|---|
| Горизонт | 1–4 недели | Месяцы: весь проект или его фаза |
| Повод | Конец спринта, по календарю | Закрытие проекта, крупный релиз, конец фазы |
| Состав | Scrum-команда | Команда проекта плюс смежные роли: поддержка, аналитики, дизайн |
| Результат | 2–3 действия в следующий спринт | 5–7 уроков для следующих проектов + 2–3 действия |
| Частота | Каждый спринт | Один раз; на длинном проекте — по вехам |
| Длительность | Около часа | 90–120 минут |
Главное различие — в результате. Действие из спринтового ретро живёт две недели и закрывается выполненным. Урок проектной ретро нужен людям, которых ещё нет в команде: тем, кто через полгода начнёт похожий проект. Поэтому и записывать его надо иначе — об этом ниже.
Постмортем проекта — третий сосед в этом ряду. Классический постмортем разбирает один инцидент: аварию, сорванный релиз, потерю данных. Ретроспектива проекта разбирает весь путь, включая то, что получилось. Если проект закончился провалом, элементы постмортема в неё войдут, но начинать с «кто виноват в срыве» — верный способ получить обтекаемые карточки. Таблица «ревью, ретро, постмортем» с разбором каждого — в статье «Что такое ретроспектива».
И одна оговорка про ритм. В статье о регулярных ретроспективах сказано: ретро раз в квартал — это уже не ретро, а постмортем. Это про частоту командных ретро — заменить спринтовые встречи одной квартальной нельзя, трение копится быстрее. Проектная ретро ритм не заменяет, она ложится поверх: спринтовые ретро чинят процесс по ходу, проектная в конце собирает то, что видно только с дистанции. У команды, которая вела ретро каждый спринт, проектная проходит легче — половина мелких проблем уже решена, и разговор сразу идёт о крупном. Что такое спринтовое ретро и как уложить его в час — в статье про ретроспективу спринта.
Когда проводить и кого звать
Повод. Закрытие проекта, крупный релиз — выход на новый рынок, миграция, запуск продукта, — конец фазы длинного проекта. Отдельный случай — расформирование команды: если людей переводят в другие продукты, ретро проводится до того, как они уйдут, иначе опыт уйдёт с ними. На проекте длиннее полугода не ждите конца: ставьте чекпоинты по вехам — после каждой крупной вехи короткая проектная ретро на час, в конце — большая.
Срок. Одна-две недели после закрытия. Раньше — команда ещё разбирает последствия релиза и не готова смотреть назад. Позже — детали забываются, и разговор незаметно съезжает на текущие задачи. Если два месяца уже прошли, ретро всё равно полезнее, чем ничего, но начинать придётся с восстановления хронологии по тикетам и логам, иначе половина карточек будет про позавчера.
Состав. Команда проекта целиком плюс те, кто был рядом и видел то, чего не видела команда: поддержка (она первой узнаёт, что пошло не так после релиза), аналитики, дизайн, дежурные на выкатке. Оптимально 6–12 человек. Больше пятнадцати — делите на две сессии по подкомандам и сводите итоги отдельно.
Заказчик и стейкхолдеры. Не в этой комнате. При заказчике команда пишет «в целом всё прошло хорошо», и встреча теряет смысл. Взгляд заказчика ценен, но собирайте его отдельно: 30-минутный разговор через день-два после ретро или отдельный блок в самом начале, после которого заказчик выходит. Его ответы на «что бы вы сделали иначе» — колонка фактов на доске, а не участие в обсуждении.
Правило встречи. Без поиска виноватых. Проговаривается вслух в первую минуту: разбираем решения и обстоятельства, а не людей. Это не вежливость, а условие честных карточек — и единственный способ узнать, почему человек три недели не просил помощи.
Подготовка за неделю
Спринтовое ретро готовится за пятнадцать минут накануне. Проектное — за неделю, и большая часть работы — у ведущего.
- Соберите хронологию проекта. Лента вех на одном экране: старт, ключевые решения, смены состава, инциденты, релизы, сдвиги сроков. Источник — тикеты, календарь, чат. Двадцать точек, не двести. Без ленты первые полчаса встречи уйдут на «а когда это было».
- Выпишите цифры план/факт. Сроки, объём, бюджет — там, где они есть. «Планировали 12 недель, вышло 16» на экране меняет разговор сильнее любого вопроса ведущего.
- Откройте уроки прошлых проектов. Если у компании они записаны — прочитайте и вынесите на встречу те, что относятся к этому проекту. Повторившийся урок — главная тема ретро.
- Разошлите пре-рид за два-три дня. Хронология, цифры и три вопроса для размышления. Люди приходят с готовыми мыслями, а не вспоминают на месте.
- Выберите формат, создайте доску, назначьте таймбокс. 90–120 минут, не час — материала за полгода больше, чем за спринт. Забронируйте время с запасом, а не «до следующей встречи».
В Scruma доску под встречу можно создать заранее на дату и время: участники открывают её по ссылке со страницы команды и накидывают карточки до старта — те, кто читает пре-рид вдумчиво, часто пишут лучшие карточки именно так, в тишине.
Сценарий на 90–120 минут
Ниже — раскладка для команды из 8–10 человек. Механика пяти этапов — сбор, группировка, голосование, обсуждение, решения — описана в пошаговом плане ретроспективы; здесь только то, что меняется из-за масштаба.
| Этап | Минуты | Что происходит |
|---|---|---|
| Хронология проекта | 10–15 | Ведущий проходит по ленте вех, команда дополняет и поправляет. Не обсуждаем — только восстанавливаем, что было |
| Карточки молча | 10–12 | Каждый пишет в колонки формата. Анонимно, если в проекте был конфликт или сменился руководитель |
| Группировка | 7–10 | Похожие карточки — в группы. Дубли не вычищать: семь карточек про одно решение — это вес, а не мусор |
| Голосование | 5 | По 3–5 голосов у каждого. Выбираем 3–5 тем — не больше, иначе ни одну не разберёте до урока |
| Обсуждение | 35–45 | По каждой теме: что произошло → почему → что это значит для следующего проекта. Ведущий следит, чтобы разговор не ушёл в текущие задачи |
| Уроки и действия | 10–15 | Формулируем 5–7 уроков и 2–3 действия с владельцем и сроком. Вслух, при всех |
| Закрытие | 5 | Читаем список, оцениваем встречу, договариваемся, где уроки будут жить |
Сумма по таблице — 82–107 минут, остаток до 90–120 — запас на переходы между этапами и опоздания; на команду больше десяти человек добавьте пятнадцать минут к обсуждению. Хронология в начале — обязательный этап, которого нет в спринтовом ретро: за полгода люди помнят разное, и без общей ленты первые карточки будут спорить не о выводах, а о фактах. Обсуждение здесь длиннее, чем на спринтовом ретро, — темы шире: не «ревью висит два дня», а «мы три месяца не решали вопрос с архитектурой очередей».
Как это в Scruma
Доска в Scruma ведёт встречу по этапам: Размышление → Группировка → Голосование → Обсуждение. Этапы переключает ведущий, у него же таймер — «5 мин», «1 мин», «+1 мин» и сброс; каждый участник отмечается кнопкой «Я готов», и видно, когда пора дальше. Анонимные заметки и лимит голосов на человека задаются при создании встречи, голос за свои карточки по умолчанию выключен. Одно честное ограничение: на бесплатном тарифе на доске одновременно до пяти участников — проектная ретро на восемь-двенадцать человек проходит на платном.
Какой формат брать
Формат — это колонки, в которые команда пишет карточки. Для проектной ретро подходят три, и выбор зависит от того, чем проект закончился и что будет дальше. Полный каталог с таблицей выбора — в обзоре форматов.
Хронология + 4L — для проекта, где команда много училась. Сначала восстанавливаете хронологию по ленте ведущего (первый этап сценария), затем доска 4L: Liked / Learned / Lacked / Longed for. Колонка Learned собирает знания, которые люди уже вынесли, но нигде не записали, — обычные форматы их теряют. Отдельного шаблона «Хронология» в Scruma нет: если хотите вести ленту прямо на доске, колонки по фазам проекта собираются конструктором своих шаблонов (на платном тарифе); проще — держать хронологию в пре-риде и на экране ведущего, а доску брать встроенную 4L. Разбор формата и кейс 4L на закрытии полугодового проекта — в статье про 4L, повторять его здесь не буду.
Ретро релиза — для проекта, который закончился выкаткой: Сработало / Не сработало / Уроки / На будущее. Колонка «Уроки» — прямо то, ради чего проводится проектная ретро, а «На будущее» переносится в чек-лист следующего релиза без переформулировок. Шаблон встроен в Scruma; его методичка советует звать на встречу тех, кто был на дежурстве и на поддержке, и проводить её в течение недели после выката.
Надежды и опасения — не для итогов, а для перехода к следующему проекту: Надежды / Опасения. Если команда после закрытия сразу стартует новый проект, уместно провести короткую сессию по этому формату через неделю после проектной ретро — уже с уроками на руках. Хитрость из методички: по каждому верхнему опасению записывается признак — как вы поймёте, что оно сбывается. «Боюсь, что не успеем» превращается в проверяемое «к середине месяца сделано меньше половины».
Если проект не закрывается, а переходит в следующую фазу и команда спорит, что делать дальше, четвёртый вариант — GROW: Goal / Reality / Options / Way forward, от цели к фактам, вариантам и шагу. Все встроенные шаблоны, включая эти четыре, разложены по группам в окне выбора, у каждого — методичка из четырёх частей: когда брать, как провести, сколько времени, чего опасаться. Как устроена библиотека — в разборе шаблонов Scruma.
Вопросы для ретроспективы проекта
На спринтовом ретро вопросы идут по этапам встречи — шестьдесят с лишком формулировок собраны в статье «Вопросы для ретроспективы». На проектной ретро полезнее вопросы по темам проекта: их удобно разослать в пре-риде, а на встрече — задавать по одной теме, когда карточки уже на доске и обсуждение застряло.
| Тема | Вопросы |
|---|---|
| Цели и результат | Что мы обещали на старте и что получили в конце? Какой частью результата заказчик реально пользуется через месяц? |
| План и сроки | Где план разошёлся с фактом сильнее всего — и когда мы это заметили? Какие оценки оказались самыми неверными и почему? |
| Коммуникации и решения | Какое решение мы откладывали дольше всего и что это стоило? Кто узнавал о важных изменениях последним? |
| Риски и неожиданности | Что из случившегося можно было предсказать на старте? Какой риск из плана так и не сработал — и зря ли мы его страховали? |
| Качество | Где мы сознательно упростили решение ради срока и где потом за это заплатили? Какие технические решения возьмём в следующий проект как есть? |
| Команда и роли | Каких компетенций не хватало и как мы это закрывали? Кто был перегружен, а кто недозагружен — и было ли это видно вовремя? Что бы каждый сделал иначе, начиная этот проект завтра? |
Тринадцать вопросов — это меню, а не анкета. На одну встречу берите те две-три темы, по которым в проекте было больше всего проблем; остальные пойдут в пре-рид как повод подумать.
Как записать уроки, чтобы их прочитали
В PMBOK это называется lessons learned — извлечённые уроки проекта. В большинстве компаний они существуют как раздел протокола финальной встречи, который никто не открывает. Причин две: уроки записаны как лозунги («лучше планировать», «больше общаться») и лежат там, где новые проекты не начинаются.
Формат одного урока. Шесть полей, каждое — одна-две строки:
| Поле | Пример |
|---|---|
| Контекст | Миграция клиентской базы в новую CRM, 4 месяца, команда 7 человек |
| Что произошло | Тестовый прогон на копии базы дал 3% битых записей, боевой — 11% |
| Почему | Копия была месячной давности; за месяц поддержка завела новые типы полей |
| Рекомендация | Финальный прогон миграции — только на копии не старше суток |
| Где применимо | Любая миграция, где источник данных продолжает жить во время проекта |
| Владелец | Андрей, аналитика — вносит пункт в чек-лист кикоффа миграций |
Пара для сравнения. Плохо: «Нужно лучше тестировать миграции». Хорошо: «Финальный прогон миграции — на копии не старше суток; на месячной копии процент битых записей отличался от боевого почти в четыре раза (3% против 11%)». Второй вариант человек, начинающий похожий проект, прочитает и применит; первый пролистает.
Урок и действие — разные вещи. Действие меняет что-то сейчас: у него исполнитель и срок, оно закрывается. «Андрей до 20 сентября дописывает чек-лист кикоффа» — действие. Урок — знание для следующего проекта: срока у него нет, есть владелец-хранитель, который отвечает, что урок лежит там, где его найдут. Смешивать их в один список — ошибка: действия в нём выполнятся и вычеркнутся, уроки останутся висеть и через год будут выглядеть как невыполненные задачи. Как формулировать действия, которые доживают до исполнения, — в статье про action items ретроспективы.
Пять-семь уроков, не тридцать. После обсуждения на доске будет полтора десятка кандидатов. Оставьте те, что пройдут два фильтра: «мы бы приняли другое решение, если бы знали это на старте» и «это повторится в следующем проекте». Список из тридцати уроков не читает никто, включая авторов.
Где хранить. Там, где начинаются проекты, а не там, где они заканчиваются: шаблон устава или плана проекта, чек-лист кикоффа, страница «Уроки проектов» в вики с разделами по типу — миграции, интеграции, запуски. Первые пятнадцать минут кикоффа нового проекта — чтение уроков по своему типу. Пока этого ритуала нет, любое хранилище — архив.
Кто владеет. Один человек — руководитель практики, лид PMO, старший PM, — а не «команда». Он не пишет уроки за всех, он отвечает за то, что реестр не разъезжается: дубли слиты, устаревшее помечено, у каждого урока есть владелец.
Как это в Scruma
Задачи в Scruma заводятся прямо на этапе обсуждения — с исполнителем и сроком — и после встречи живут на странице задач команды: вкладки «Мои / Открытые / Закрытые / Все», просроченные подсвечены, из задачи один клик до ретро. За три дня и за день до срока исполнителю приходит напоминание в центр уведомлений (и пушем, если он включён), а после завершения встречи каждому участнику уходит письмо-отчёт с блоками «Ваши задачи» и «Остальные задачи». Сама встреча сохраняется отчётом — снимок доски с группами и голосами, статистика участия, оценка встречи. В меню «Экспорт» шесть пунктов: Markdown, копировать в буфер, копировать для Confluence, XLSX, DOCX, PDF. Для архива проекта — PDF или DOCX в папку проекта, для вики — «Копировать для Confluence» на страницу уроков.
Частые ошибки ретроспективы проекта
Провели через два месяца. К этому времени команда наполовину в новых проектах, а детали — только в тикетах. Разговор съезжает на текущее, карточки общие. Правило: одна-две недели после закрытия. Опоздали — начинайте с хронологии по логам и тикетам, а не с карточек.
Собирают только после провала. Тогда слово «ретро» в компании означает «разбор вины», и на него идут защищаться. Успешный проект даёт не меньше уроков — и как раз воспроизводимых: что именно сработало и почему. Ретро по итогам удачного запуска — единственный способ повторить удачу осознанно.
Заказчик в комнате. Карточки превращаются в «в целом всё прошло хорошо», обсуждение — в отчёт. Взгляд заказчика собирайте отдельно и приносите на встречу фактами.
Тридцать уроков без владельца. Список, который производит впечатление на презентации и не открывается никогда. Пять-семь уроков с владельцем у каждого работают, тридцать — нет.
Уроки в протоколе встречи. Протокол лежит в папке проекта, а следующий проект начинается в другой папке. Уроки живут в шаблоне устава, чек-листе кикоффа или на странице вики, которую открывают на старте, — иначе они не существуют.
Проектная ретро вместо спринтовых. Накопить полгода трения и разобрать его за два часа нельзя: мелкое забудется, крупное окажется неразрешимым. Проектная ретро работает поверх регулярных, а не вместо них — как удержать ритм, разобрано в статье о регулярных ретроспективах.
Пример: ретроспектива проекта миграции данных
Команда из семи человек четыре месяца переносила клиентскую базу и историю заказов из самописной CRM в новую. Релиз опоздал на три недели, на боевой миграции 11% записей легли с ошибками, поддержка две недели разбирала их руками. Ретро провели через восемь дней после выката: 100 минут, формат «Ретро релиза», ведущая — Лена, руководитель проекта. Хронологию Лена собрала за два вечера из тикетов и чата: четырнадцать вех, среди них две смены состава — ушёл разработчик, единственный знавший схему старой базы. Руководителя отдела продаж, заказчика проекта, на встречу не звали: с ним Лена поговорила отдельно через два дня, полчаса.
Что показала доска. В «Сработало» неожиданный лидер с шестью голосами — «еженедельный прогон миграции на копии базы»: он поймал большую часть проблем за два месяца до релиза, и команда назвала его главной причиной, почему опоздание составило три недели, а не три месяца. В «Не сработало» пять голосов набрала «финальный прогон на копии месячной давности» — отсюда и 3% битых записей на тесте против 11% на боевой. В «Уроках» было девять карточек, после группировки — шесть; одна из них — «поддержка заводила новые типы полей весь проект, а мы узнали в день релиза» — стала уроком про источник, который продолжает жить, пока вы его переносите. В «На будущее» Марина из поддержки написала «заморозка правок в старой CRM за неделю до релиза» — это ушло действием.
Итог встречи: шесть уроков на страницу «Уроки проектов» в вики, раздел «Миграции», и два действия — Андрей до 20 сентября дописывает чек-лист кикоффа миграций (свежесть копии, заморозка источника), Лена до конца месяца добавляет в шаблон плана проекта пункт «источник данных под заморозкой за пять рабочих дней до релиза». Через полгода на следующей миграции чек-лист открыли на кикоффе: финальный прогон делали на копии, снятой ночью перед релизом, ошибочных записей вышло меньше половины процента. Урок сработал не потому, что был записан, а потому, что лежал там, где начинался следующий проект.