🔄 Retrospective, которую не ненавидят

Знаете, какой звук вызывает у проектной команды тихую тоску? «Коллеги, в пятницу в 17:00 ретро». Кто-то закатывает глаза. Кто-то пишет «ок» и думает, как быстрее свалить. Кто-то готовится честно ответить «всё нормально», чтобы поскорее разойтись.
Знакомая картина? Ретроспектива — самый формализованный и самый испорченный ритуал в управлении проектами. По идее — рабочий инструмент улучшения. На практике — пустой обряд, на котором боятся сказать правду. Давайте разберёмся, почему так, и что с этим делать.

Почему ретро превращается в пустой ритуал

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

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

Третья — формат ради формата. «Давайте напишем стикеры: что хорошо, что плохо, что улучшить». Звучит методически грамотно. Но если за этим нет реального разговора, стикеры — это просто бумажки на доске, которые потом никто не читает.

Как сделать ретро, которое работает
Не буду писать, что есть один правильный формат — это враньё. Работает не формат, работает культура и несколько принципов. Вот они.

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

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

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

Действия обязательны к исполнению. 
Это критично. Каждое решение с ретро — это обязательство, за которым кто-то следит. Если вы договорились «внедрить ревью кода» — это должно случиться до следующего ретро. И на следующем ретро первый вопрос: что из договорённого сделано, что нет, почему. Без этого ретро превращается в разговоры.

Меняйте формат, когда он умер. 
Формат «что хорошо/плохо/улучшить» — отличный, но приедается. Если команда отвечает на автомате — меняйте. Иногда берём одну тему и разбираем глубоко. Иногда — «что бы я сказал себе в начале спринта». Главное — чтобы людям было интересно думать, а не заполнять ритуальную таблицу.

И главное — про действия, а не про чувства
Часто ретро путают с групповой терапией. «Давайте поделимся, что чувствуем». Я не против чувств, но если вы обсудили эмоции, но не выработали ни одного изменения — ретро не состоялось. Эмоции — это сигнал, не результат. «Я расстроен, потому что снова переделывали в последний момент» — повод решить проблему поздних правок, а не повод всех обнять.
Ретроспектива — не про прошлое. Про то, что вы сделаете по-другому в будущем. Если из ретро не вышло ни одного конкретного изменения — оно было бесполезно. Точка.

#менеджмент #agile #ретроспектива #проектная_команда #РП #практика