Структура идеальной ретроспективы

Екатерина Чернышева, Group Head AGIMA, предлагает структуру ретроспективы, которая переводит обсуждение прошлого периода в конкретные изменения процесса.

Коротко

Привет! Меня зовут Катя Чернышева, я Group head в AGIMA. По работе мне приходится часто проводить ретроспективы — встречи с командой, на которых мы анализируем, что хорошо в нашем рабочем процессе, а что можно улучшить. Еще чаще я рассказываю о том, как их проводить, начинающим коллегам.

Главный вопрос, с которым они ко мне приходят:

— Как сделать ретроспективу одновременно полезной и интересной?

Я тоже долго искала на него ответ, но в итоге пришла к простому выводу:

я против скучных встреч.

Каждая встреча должна быть наполнена смыслом, и вся команда должна этот смысл понимать. А еще важнее, чтобы встреча была динамичной и яркой. В этой статье расскажу, как сделать ретроспективу как раз такой. Уверена, полезно будет и тем, кто уже давно руководит проектами, и тем, кто делает первые шаги в этом деле.

Поехали.

Карточка действия

Что такое ретроспектива

Ретроспектива — это регулярная встреча, на которой команда обсуждает рабочий процесс и при необходимости что-то в нем меняет. Ретроспектива входит в список регулярных мероприятий почти всех гибких методологий.

Цель ретроспективы — запланировать повышение качества и эффективности, снизить напряжение в команде, подсветить позитивные моменты в работе. В общем, провести рефлексию — понять, какие процессы работают хорошо, а какие нет.

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

Подготовка к ретро состоит из 4 шагов:

• Запланировать время команды.
• Выявить проблемы, которые нужно рассмотреть.
• Придумать тему.
• Продумать тайминги.

Про каждый шаг расскажу отдельно.

Планируем время

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

Если в команде 10 человек, но у двоих отпуск, у одного больничный, а еще у двоих встречи, ретроспективу лучше перенести. В идеале на ретроспективу должны приходить все. Команда должна понимать, что это необходимое и обязательное мероприятие. Пропускать его не стоит.

Под ретро необходимо завести встречу в календаре, чтобы добавить туда всю команду. Тогда каждый будет заранее знать, что у него запланировано и не поставит на это время ничего более важного. Но даже если все подтвердили участие через календарь, можно заранее напомнить о ретроспективе в общем чате.

Плохая практика — отменять ретроспективу минуту в минуту, как и любую другую встречу. Иногда случается, что приходит только часть команды, потому что у остальных внешние встречи или горящие дедлайны. Тут ничего не поделаешь — встречу проводить бессмысленно. Но в этом случае все, кто не смог прийти, должны подтвердить участие в следующей ретроспективе.

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

Выявляем проблемы

На этапе подготовки нам нужно понять, какие темы в команде «наболели». Речь на ретроспективе идет об острых проблемах, которые мешают команде работать.

Например, команда медленно выпускает в прод обновления для iOS. Это вызывает недовольство заказчика, конфликты. Конечно, всем это не нравится. Значит, нужно найти корень проблемы, а затем и ее решение. Под проблемой мы всегда понимаем что-то, что имеет прямое отношение к процессу производства.

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

Если всем кажется, что веб-разработчик плохо работает, то вопрос следует поставить иначе. Почему он плохо работает? Ему не хватает компетенций? Его достижений не замечают? Плохой разработчик — это не проблема всего проекта. Он один не может сломать весь проект. Это проблема процесса, управления или подбора кадров.

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

Узнать, какие проблемы замечает команда, можно разными способами. Например, можно попросить сообщать о таких проблемах вам в личку. Еще члены команды могут записывать в Miro проблемы, которые появляются в процессе работы между ретроспективами. Также можно запустить голосование в чате по проблемным зонам.

Для каждой ретроспективы мы выбираем один самый острый вопрос.

Выбираем тему ретроспективы

Ретроспективу можно проводить и без темы, но, скорее всего, в этом случае она будет безликой и скучной. Поэтому тему желательно выбрать — это расслабит команду, создаст комфортную атмосферу.

Например, у меня темой ретроспективы часто становятся вселенная Гарри Поттера, «Пиратов Карибского моря» или Marvel. В качестве темы лучше выбирать фильмы, книги, сериалы или игры, которые все знают. Наверняка в вашей команде есть точки, в которых пересекаются интересы если не всех, то хотя бы большинства участников.

Между командой и ее проблемами нужно найти связующие элементы, а затем встроить их в новый мир. Это сделает рефлексию не только полезной, но и интересной, вовлечет команду в процесс. А еще тема поможет визуализировать доску.

Например, однажды мы фиксировали плюсы и минусы на доске в стиле Гарри Поттера. Плюсы отправлялись в Гриффиндор, минусы — в Слизерин.

Продумываем тайминги

Каждый этап ретроспективы необходимо спланировать заранее. Нужно понимать не только, что конкретно будет делать команда, но и сколько займет каждый этап. Иначе встреча может длиться вечность. Тут опишу, какого тайминга обычно придерживаюсь.

Командный радар ~ 8 минут

2–3 минуты на сам радар и около 5 — на его разбор. Ниже я расскажу о радаре и его назначении подробнее.

Проблемы команды ~ 30 минут

Выявляем проблемы на этапе подготовки к ретро. Но раскрыть их важно на самой встрече. Тут проблему нужно сформулировать и попросить команду найти решение. На этом же этапе мы генерируем идеи.

Например, у вас есть проблема: никто не выступает в группе, хотя вам важно делиться опытом внутри отдела. Предположим, сама команда не очень большая — 5 человек. В этом случае можно выписать сильные стороны каждого. Предложить всем проголосовать. Так мы выберем основную сильную сторону каждого человека. Кто-то хорош в общении с заказчиком, а кто-то круто ведет ретро. Теперь каждый должен выступить с докладом о своей суперсиле.

Анализ отчетного периода ~ 1 час

Это классический блок — доска с плюсами и минусами. Фиксируем, что хорошего и что плохого произошло. Заодно решаем, как сохранить хорошее и как не допускать плохого впредь. По итогам этого блока делаем Action-план — план по усовершенствованию процессов.

Например, мы всей командой не понимаем, где и какие документы лежат. Кто-то вынес это в минусы, остальные подтвердили. Сообща решили, что нужно разобраться в документах, разложить всё по полкам и папкам, все папки подписать. Фиксируем это решение в Action-плане и выбираем ответственного.

Золотое правило №1

Чем реже ретроспектива, тем она дольше.

За большой период у команды накопится достаточно напряжения, проблем и тем, которые стоит обсудить. А значит, и времени на ретро уйдет больше. Поэтому ретро не стоит пропускать. Проводить его нужно так часто, как требуется.

Понять периодичность просто: сначала проводите ретроспективу раз в полтора месяца. Первая будет долгой — это нормально. Но посмотрите, как долго будет длиться вторая или третья. Если уложитесь в полтора часа, можно ставить встречу реже — например, раз в 2 месяца. Если не уложитесь в 2–3 часа, стоит проводить чаще — раз в 2 недели или в месяц.

Если время на встречу истекло, а карточки еще остались, то просто запланируйте вторую встречу. Пропускать и забивать на чьи-то карточки нельзя.

Ретроспектива по итогам года проходила в стиле церемонии вручения «Оскар».

Готовим доску для ретроспективы

Доска должна быть готова заранее. Оформить ее важно аккуратно и грамотно, чтобы ничто не отвлекало команду. Все блоки должны быть разумными и логичными, должны соответствовать вашему плану. Не стоит добавлять поля, которые вы не успеете заполнить.

То есть если у меня по плану сначала идет командный радар, потом обсуждение проблем, потом плюсы-минусы и Action-план, то соответствующие поля на доске должны идти в той же последовательности.

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

Для ретроспективы подойдёт общая онлайн-доска, доступная всем участникам команды.

Проводим ретроспективу

Доска готова, тайминги отмечены, люди в сборе. Пора начинать.

В первую очередь проводим командный радар или что-то наподобие. Так мы снимаем напряжение и понимаем, что беспокоит команду.

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

Командный радар помогает быстро понять общий эмоциональный фон команды.

Затем мы переходим к блоку, посвященному той самой проблеме, которую выявили заранее. Ищем ее решение и обсуждаем, как будем исправлять ситуацию. Примеры я приводила выше.

Дальше приступаем к блоку плюсов-минусов. Здесь мы говорим не только о плохом, но и о хорошем. Не бывает, что плохо всё — нужно находить поводы похвалить себя и друг друга.

Проведение ретроспективы — это деликатный процесс. Тут нужно быть немного психологом, немного модератором. Важно услышать всех, дать понять, что их мысли поняты, ни с кем не спорить. Нельзя сказать кому-то из команды, что его идеи так себе. Больше того, нельзя допускать, чтобы кто-то другой так говорил. Пусть люди высказываются. Это их время.

Золотое правило №2

Всегда ставьте ответственных за задачи, которые вы берете в работу.

По итогам ретроспективы составлен Action-план. Обязательно нужно понять, кто будет отвечать за каждый его пункт. Сначала спрашиваем, есть ли желающие. Если нет, то назначаем ответственного сами.

Золотое правило №3

Нельзя никого критиковать: каждая идея имеет право на существование.

Вот так может выглядеть Action-план — тут мы назначаем ответственного по каждому вопросу.

Выполняем Action-план

Про этот пункт часто забывают, хотя во многом ретроспектива проводится именно ради Action-плана. Фактически Action-план — это митинг-репорт. После встречи мы пишем всем письмо, в котором напоминаем, какие задачи взяли в работу. Убеждаемся, что все понимают свои задачи и готовы над ними работать. Также Action-план можно закрепить в чате или занести в общую базу знаний.

Про выполнение задач из Action-плана нужно напоминать. Это может всех раздражать, но что делать? Если Action-план не будет выполняться, то ретроспектива будет чем-то вроде сеанса у психолога. А она должна менять производственный процесс к лучшему.

Чтобы задачи выполнялись, они должны быть разумными. Например, у команды проблема: не хватает Камерон Диаз в офисе. В Action-план я внесу следующее: пригласить Камерон Диаз. Написать я ей могу, но вряд ли она приедет. Значит, эта задача обречена, добавлять ее в план не стоит. Если вы берете в работу невыполнимые задачи, они висят мертвым грузом и всех бесят.

Ретроспектива — это мощный инструмент, который может закрыть несколько задач: сплотить команду, решить проблемы, улучшить процессы и взаимоотношение в команде. Поэтому пренебрегать этим форматом не стоит. Наоборот, чем интереснее вы его сделаете, тем больше пользы он принесет.