Ретроспектива: как и зачем её проводить

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

Когда команде предлагают провести ретроспективу, часто возникает вопрос: «Зачем? Мы и так можем всё обсудить и решить». Почему нельзя, чтобы какой-то эксперт или начальник просто пришёл, посмотрел и сказал, что надо делать?

Причина 1. Эффект «not invented here». Если решение приходит сверху, у команды нет чувства собственности по отношению к нему. Даже если все понимают, что решение правильное, его будут саботировать. Люди гораздо охотнее выполняют то, что придумали сами.

Причина 2. Сложность разработки ПО. Вряд ли найдётся специалист, который, не зная контекста, сможет расписать, как именно должны работать процессы в конкретной команде. Чтобы понять, что работает, а что нет, надо пробовать, экспериментировать и смотреть на результат.

Даже хорошие практики (code review, парное программирование, тестирование) не универсальны. Одним командам они помогают, другим — мешают. Оценить их эффективность можно только в контексте конкретной команды и ситуации. Ретроспектива как раз и нужна для того, чтобы найти тот самый контекст.

В основе ретроспективы лежит цикл Деминга (PDCA): Plan — Do — Check — Act. Ретроспектива — это этап Plan. Её цель — получить план эксперимента на следующий период. Не план окончательных изменений, а план того, что команда попробует сделать по-другому. А на следующей ретроспективе проверит, сработало ли это.

Если у ретроспективы нет цели — она превращается в болтовню. Люди приходят, обсуждают проблемы, жалуются, облегчают душу — и расходятся. Никаких изменений не происходит.

Задача ведущего — привести команду к конкретному плану. План — это либо действия, либо новые договорённости.

• Действия — конкретные задачи с известными исполнителями. Кто, что и когда делает.
• Договорённости — новые правила, которых все отныне придерживаются.

Итог ретроспективы — не просто список проблем, а список того, что команда реально собирается изменить.

1. Общая ретроспектива (психотерапевтическая). Нацелена на понимание того, что происходит в команде. Начинается с вопроса: «Какие проблемы вы видите?». Помогает снять напряжение и выявить системные боли.

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

3. Ретроспектива по проблемам с заказчиком. Обсуждаются сложности во взаимодействии с заказчиком или владельцем продукта.

4. Ретроспектива по конкретному вопросу. Если есть одна острая проблема — ретроспектива посвящается только ей.

Проблема 1. «У нас нет проблем».

Команда считает, что её рабочий процесс достаточно хорош и улучшать нечего. Это почти всегда не так, но объяснить это команде сложно.

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

Проблема 2. Говорят только несколько человек.

Один-два человека доминируют, остальные молчат. Это плохо, потому что лучшие решения рождаются в групповой дискуссии.

Решение: ведущий должен следить, чтобы все высказались. Можно использовать анонимное голосование: дать каждому написать свои мысли на стикерах, а потом обсудить их.

Проблема 3. Поиск виноватых вместо поиска решений.

Обсуждение превращается в выяснение, кто виноват. Это неконструктивно и демотивирует.

Решение: ведущий должен переводить фокус с «кто виноват» на «что делать дальше».

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

1. Плюсы. Что шло хорошо в прошлой итерации? Какие задачи были выполнены успешно? Что порадовало?

2. Минусы. Какие проблемы возникли? Что пошло не так? Что мешало работать?

3. Идеи. Какие идеи появились в процессе обсуждения? Что можно попробовать изменить?

4. План. Что мы реально будем делать на следующей итерации? Это должны быть конкретные действия или новые договорённости.

Важно: не пытайтесь решить все проблемы сразу. Достаточно 3-6 пунктов в плане. Слишком большой план невыполним и демотивирует.

Пример плана:

• ✅ Провести технический митинг перед началом спринта.
• ✅ Добавить чек-лист перед отправкой кода в ревью.
• ✅ Ввести практику парного программирования для сложных задач.
• ✅ Обсудить с заказчиком приоритеты бэклога.

Как часто проводить ретроспективы?

Для Scrum-команд — в конце каждого спринта (обычно раз в 1-4 недели). Для Kanban-команд — раз в месяц.

Сколько времени должна длиться ретроспектива?

Обычно 1-2 часа. Если меньше — не успеваете погрузиться. Если больше — устаёте и теряете фокус.

Кто должен вести ретроспективу?

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

Что делать, если команда не приходит к единому мнению?

Не нужно добиваться консенсуса по всем пунктам. Выберите те идеи, с которыми согласны все (или большинство). Спорные вопросы вынесите на следующую ретроспективу.

Можно ли проводить ретроспективу онлайн?

Да. Используйте онлайн-доски (Miro, Mural, Эсборд) с теми же четырьмя колонками. Анонимное голосование в онлайне даже проще организовать.

• Ретроспектива — это регулярная встреча для улучшения рабочего процесса.
• Главная цель — получить план эксперимента на следующий период (цикл Деминга).
• Типы: общая, по качеству, по проблемам с заказчиком, по конкретному вопросу.
• Проблемы: «у нас нет проблем», доминирование нескольких человек, поиск виноватых.
• Формат: четыре колонки — Плюсы, Минусы, Идеи, План.
• Результат: 3-6 конкретных действий или договорённостей.

Начни с малого: возьми доску или онлайн-инструмент, нарисуй четыре колонки. Спроси команду: «Что было хорошо? Что было плохо?». Запиши всё. Затем спроси: «Что мы можем сделать по-другому?». Выберите 3-5 пунктов, которые реально можно внедрить в следующем спринте. Назначьте ответственных. На следующей ретроспективе проверьте, что получилось. Удачи.