Вариант ретроспективы для ИТ команд (postmortem)⁠⁠

В прошлых статьях я уже рассказывал о Andon Cord, который реализует Continuous Service Improvement (CSI) почти в реальном времени: если что-то идёт не так, мы можем остановить процесс и исправить проблему на месте. Но не всегда это возможно. Поэтому я применяю CSI в ретроспективе — через так называемые Postmortem сессии.

Считаю этот подход своим: он родился из практики RCA (Root Cause Analysis) в рамках Problem Management по ITIL. Возможно, в учебниках есть похожие идеи, но к этому формату я пришёл сам — через реальные кейсы, эксперименты и внедрения под конкретные ограничения команды и продукта.

Когда и как мы это делаем📅

Каждую пятницу, в конце рабочего дня, команда кратко разбирает только закрытые кейсы недели: инциденты, запросы, задачи. Формат — спокойная беседа без поиска виноватых (blameless postmortem), с акцентом на ощущения людей, которые делали работу.

Как проходит сессия🕵️‍♂️

• 🗣️ Кейс рассказывает тот, кто делал. Узнаём, в чём была задача и что было фактически сделано.

• 💬 Свободный обмен ощущениями. Делимся, где было неудобно/долго/дублировалось и что вызывало сомнения или напряжение.

• 📝 Фиксируем наблюдения и маленькие улучшения. Записываем 1–3 конкретные идеи в CSI-бэклог — что убрать, объединить, автоматизировать.

• 🛠️ Архитектурные сигналы. Отмечаем признаки проблем на уровне архитектуры (узкие места, масштабирование, и пр)

• 🔄 Границы ответственности. Понимаем, что можно делегировать/передать заказчику и где стоит мягко обновить RACI.

CSI-бэклог: фиксируем идеи сразу💡

Важный результат постмортема — оперативное формирование CSI-бэклога прямо на встрече. Даже в сыром виде, любая идея фиксируется в JIRA — от «галочки» в конфиге до архитектурного рефакторинга.

Принципы:

• 📝 Записываем всё: Нет «слишком мелких» идей.

• 📂 Отдельный бэклог: CSI живёт в стороне (отдельный проект/доска), чтобы не портить продуктовые/проектные бэклоги — «не отсвечивает».

Что дальше происходит с CSI-бэклогом 🔄

• 🔄 Обычный Agile-ритм: Идёт бесконечный refining: уточняем формулировки, укрупняем/дробим, переоцениваем.

• 📊 Capacity под улучшения: В каждый спринт закладываем 20–30% ёмкости под CSI-задачи. Это дисциплина, а не «по остаточному принципу».

• 🔁 Многоразовое возвращение: Одни и те же сторис могут обсуждаться на нескольких postmortem и refining сессиях подряд — мы спокойно расширяем, сужаем и шлифуем решение.

• 🔗 Объединения: Родственные карточки склеиваем в один тикет, чтобы не плодить сущности.

• ♟️«Ход конём» через проекты: Когда стартует крупная инициатива (например, миграция с on-prem в облако), часть CSI-бэклога можно перенести в проектный бэклог как фичи — если это вписывается в бюджет и расписание. Так технический долг уходит «пакетом», а не годами висит в стороне.

Завершение 🎯

Postmortem-сессии дополняют Andon Cord: первый даёт реакцию «здесь и сейчас», второй — спокойный разбор по горячим следам и системные улучшения. Вместе они замыкают цикл CSI: наблюдаем → обсуждаем без обвинений → фиксируем идеи → превращаем их в работу через отдельный CSI-бэклог и обычный Agile-ритм.

Главная ценность — в дисциплине маленьких шагов. Мы не охотимся за «большим ремонтом», а каждую неделю снимаем трение: убираем лишнее, автоматизируем ручное, уточняем границы ответственности и заранее замечаем архитектурные сигналы. От этого растут предсказуемость, скорость потока и спокойствие команды.

Если хотите начать просто: уже в эту пятницу разберите 2–3 закрытых кейса, зафиксируйте 1–3 идеи в CSI-бэклог и заложите 20–30% capacity следующего спринта под эти улучшения. Всё остальное приложится.

Читайте мою серию: Усталый Босс

Прошлые статьи:

• Andon Cord (вторая серия) Как Andon Cord помогает даже там, где никто об этом не думал

• CMM (Capability Maturity Model) Модель зрелости потенциала компании и как по кредитному рейтингу понять с кем имеем дело

• Andon cord

• Люди которые сделали современный менеджмент