Проведите ретроспективу спринта на фактах

1. Порядок: факты собираются ДО обсуждения

Первое высказанное мнение задаёт рамку всем остальным. Если встречу открывает фраза «мы просели из-за интеграции с 1С», дальше команда спорит с этой рамкой, а не ищет причины: одни защищают интеграцию, другие ищут ей подтверждения. Сильнее всего это работает, когда первым говорит самый старший в комнате.

2. Что собирается машинно

2.1 План против факта по срокам

Через query_tasks подними задачи периода с плановой и фактической датой:

Среднее врёт: одна застрявшая задача создаёт ощущение системного провала. Доля в срок ниже 60% — планирование сломано. Выше 95% — тоже сигнал: оценки с запасом, реальная ёмкость скрыта.

2.2 Число возвратов задачи в работу

Через query_events посчитай переходы назад: «в ревью» → «в работе», «готово» → «переоткрыто».

Возврат дороже, чем видно в отчёте: разработчик уже выгрузил контекст из головы и загружает заново. Выше 25% — критерии готовности не согласованы до начала работы. Задача с 3+ возвратами разбирается отдельно: там расплывчатая постановка или два представления о результате.

2.3 Время ожидания ревью

Разница между «отправлено» и «начато», а не между отправкой и мержем: ожидание, не проверка.

p50 больше 8 рабочих часов — задачи ночуют в очереди, разработчик каждый день начинает с чужого контекста. p90 больше 3 рабочих дней — узкое горло, обычно один человек, к которому сходятся все проверки; лечится вторым ревьюером на область.

2.4 Частота срочных правок

Через git_ops или sandbox_bash по клону репозитория:

Доля срочных правок и откатов от всех релизов — прямой индикатор качества выхода. Выше 20% — приёмка не работает, проверку делают пользователи. Смотри отдельно вечер пятницы: срочные там регулярно — это не про качество, а про календарь релизов.

2.5 Файлы, которые правятся чаще всего

Файл в топе — либо точка роста продукта, либо место, где архитектура сопротивляется изменениям. Различает вторая выкладка: сколько правок были срочными или откатами. Высокая частота И высокая доля срочных — кандидат номер один в техдолг, доказуемый, а не «Петя считает, что там каша».

2.6 Незавершённое из прошлого периода

Через query_tasks — задачи, открытые больше периода назад и не закрытые, с возрастом в днях. Старше двух спринтов почти всегда мертва: либо не нужна, либо её некому начать. Разговор о ней — «закрываем или назначаем владельца сегодня».

2.7 Пакет фактов

Одна страница, через documents:

3. Форматы под ситуацию

3.1 Обычный спринт (45–60 минут)

Решения прошлого раза (5 мин) → факты без обсуждения (5 мин) → три колонки (20 мин) → причины двух самых дорогих проблем (15 мин) → решения (10 мин).

3.2 Провал: сорванный релиз, потерянный клиент, отменённый проект (90 минут)

Три колонки здесь не работают: «хорошо» превращается в вымученное «зато мы сплотились». Вместо неё — хронология: восстанови события с метками времени через query_events и разбирай не «что плохо», а «в какой момент мы ещё могли свернуть и почему не свернули». Почти всегда находится точка, где сигнал был, но его нечем было услышать: не было отчёта, порога, договорённости, кто эскалирует.

Разбор не проводится в день провала: минимум сутки, иначе это выяснение, кто виноват.

3.3 Конфликт в команде

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

3.4 Разбор инцидента

Жёсткое правило: разбор безвиновный. Имена в хронологии допустимы («дежурный применил откат в 14:22»), оценки действий — нет. Разделы: хронология по минутам, время обнаружения, реакции и восстановления, влияние в измеримых единицах (сколько заказов не прошло и на какую сумму), что сработало, решения.

Если время обнаружения больше времени восстановления — чинить надо мониторинг, а не код. Самый пропускаемый вывод постмортема.

4. Безопасность обсуждения как условие правды

Ретро производит только ту информацию, которую безопасно произнести. Иначе встреча идёт, отчёт пишется, знания в нём нет.

4.2 Что даёт правду

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

5. Три колонки: как не получить вату

Хорошо. Не «команда молодец», а действие с последствием: «раннее подключение тестировщика к выгрузке в МойСклад — задача ушла в прод с первого раза». Практику повторяют намеренно, только если понятно, что сработало.

Не так. Обязательно измеримое последствие: «было сложно» → «интеграция с Битрикс24 заняла 9 дней вместо оценённых 2: документация метода не совпадала с фактическим ответом, и это выяснилось на четвёртый день». Не назвал цену в днях, рублях, возвратах — спроси «во что обошлось»; нет ответа — пункт в наблюдения, а не в проблемы.

Улучшить. Только зона влияния команды: «клиент меняет требования» — не улучшаемо, «мы начинаем работу до письменной фиксации требований» — улучшаемо. Разделяй явно, иначе колонка заполняется жалобами на внешний мир.

6. Причины: «пять почему» и её предел

Известный предел: цепочка линейна, а причин обычно несколько. Реальный отказ почти всегда совпадение: не сработал автотест И ревьюер торопился И релиз был в пятницу вечером. Цепочка выберет одну ветку — ту, что назвал первый говорящий, — и остальные останутся неисправленными.

Лечение: на каждом «почему» спрашивай «что ещё». Получается дерево, а не цепочка. Ветку выбирай по критерию: какая причина, будучи устранённой, предотвратила бы больше похожих случаев.

6.1 Как не упереться в «человек был невнимателен»

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

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

Пример. В прод уехала цена с ошибкой в разряде: 1 990 ₽ вместо 19 900 ₽, за 40 минут 60 заказов, потери около 1 140 000 ₽.

• Почему уехало? Менеджер ошибся при ручной правке. (Тупик — дальше «был невнимателен».)
• Переформулируем: почему доехала до покупателя? Нет проверки на резкое отклонение цены от предыдущей.
• Почему нет? Выгрузка идёт из таблицы прямо в маркетплейс, без промежуточного шага — так делали с запуска, когда позиций было 30 и всё просматривалось глазами.
• Что ещё сработало? Отклонение было видно в отчёте продаж, но отчёт смотрят раз в сутки утром.

Две ветки — два решения: блокировка выгрузки при изменении цены больше чем вдвое и оповещение при всплеске заказов по одному SKU. Ни одно не про внимательность.

6.2 Что значит «системная причина» проверяемо

Причина системная, если верно всё из трёх:

1. Не содержит имени человека и не изменится от его замены.
2. Из неё следует изменение процесса, инструмента или договорённости — то, что можно записать и проверить.
3. Объясняет больше одного случая. Если ровно один — возможно, случайность, и чинить процесс под неё дорого.

7. Паттерны: одно и то же в третий раз

Веди список проблем прошлых ретро через manage_memory, поднимай перед встречей через read_memory.

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

8. Решения: два-три, не десять

8.1 Почему не десять

Ёмкость команды — примерно одно-два изменения процесса за период: изменение конкурирует за то же время, что и работа. Список из десяти исполняется на 10–20% и обесценивает жанр. Два выполненных решения лучше десяти записанных. Отбор: причины сортируй по «сколько случаев предотвращает» / «сколько стоит внедрить», верхние две-три — в работу, остальное — в отложенный список без обязательств.

8.2 Формулировка, которая исполняется

Четыре обязательных поля; пункт без любого из них в протокол не попадает:

Двое ответственных — это ноль ответственных. Работу делают двое — один назван владельцем, второй участником.

Признак должен различать «сделали» и «сработало»: «написали регламент» — сделали, «возвраты упали ниже 25%» — сработало. Записывай оба, проверяй второе.

8.3 Невыполненные решения прошлого раза — главный сигнал

Это первый пункт повестки: в конце время кончится и он выпадет — удобно всем присутствующим.

По каждому решению — «выполнено / не выполнено», без «частично» и «в процессе»: «в процессе» на решении с истёкшим сроком означает «не выполнено».

По каждому невыполненному — один вопрос: «что помешало». Не «почему не сделал» — это вопрос к человеку; «что помешало» — вопрос к системе: не было времени (изменение не заложили в план), не было полномочий (приняли не своё решение), забыли (не завели задачу), передумали (решение было слабым).

9. Метрики, которые портят поведение, если сделать их целью

Метрика, ставшая целью, перестаёт быть измерением: оптимизируют показатель, а не то, что он отражал.

Метрики на ретро — индикаторы для разговора, не цели: «доля в срок 54% — повод спросить, что с оценками, а не показатель, который надо поднять до 90%». Держи их парами, где рост одной ограничивает вторую: скорость закрытия против доли возвратов, релизы против срочных правок.

10. Распределённая команда и часовые пояса

Российская команда легко расползается на 10 часов — от Калининграда (UTC+2) до Камчатки (UTC+12): Москва — Новосибирск 4 часа, Москва — Владивосток 7.

Асинхронный формат лучше в одном: молчаливые пишут больше, чем говорят, и первое мнение не задаёт рамку — все пишут независимо. Хуже в другом: нет диалога, где причина всплывает из спора; компенсируй вторым кругом адресных вопросов.

Часть команды в переговорке, часть по одному в звонке — у удалённых нет шансов вставить слово. Хоть один удалённо — все удалённо, каждый со своего устройства.

11. Шаблон протокола

Не стенограмма: страница плюс приложение фактов. Формируй через documents, рассылай через message_compose.

В версии за пределы команды из разделов 3–5 убираются имена: владельцы решений — единственные, которые обязаны там быть.

12. Режимы отказа самой ретроспективы