Как и зачем мы трижды меняли формат ретроспективы?

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

Привет! Я — Таня Афанасьева, менеджер продукта в Selectel. Наш отдел занимается разработкой и поддержанием внешних сетевых сервисов, например CDN. Команда состоит из десяти человек, среди них — team lead, product-менеджер, UX-специалист, разработчики, DevOps-инженеры и другие.

Основной состав сформировался два года назад, когда компания объединила несколько продуктов в один сервис. Большинство приходили из других отделов или компаний, поэтому коллеги изначально не были знакомы друг с другом.

Используйте навигацию, если не хотите читать полностью:

→ Что такое ретро

→ Первый формат, или «нытинг»

→ Второй формат

→ Третий формат

→ Заключение

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

Обычно ретро проводят в конце рабочего спринта или проекта. Длительность зависит от количества коллег и масштабности задач, но, в основном, один-два часа. На встрече участники по очереди делятся своими выводами, а после обсуждают идеи друг друга. Также на ретро присутствует фасилитатор, обычно это team lead или product manager.

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

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

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

Мы разделили страницу на три блока: «Что помогало работе?», «Что мешало (закрыть спринт) и можно улучшить?» и «Чему научились новому? Что нового узнали?». В течение спринта коллеги оставляли ответы на вопросы, а на встрече зачитывали их слух. Модератором ретро была я.

Недостатки

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

Новый формат перенесли в Miro, его удобно использовать для брейншторма, планирования и решения совместных задач. На доске разместили три столбца с предыдущими вопросами, только переформулировали в well, sad и new. Каждому участнику раздали карточки для записей.

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

Недостатки

У каждого формата ретро свои недостатки, и это не исключение. Благо, их было намного меньше, чем в первом.

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

Желание и проактивность

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

Командная работа

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

Кроме того, все задачи и решения, которые приняли на встрече, являются ответственностью самих участников, а не руководителя. Это позволяет каждому члену команды чувствовать свою значимость и влиять на эффективность процесса.

Модератор

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

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

Регулярность и постоянство

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

Также важно установить единый формат ретро. Команда должна понимать, зачем мы его проводим и какие у нас цели. Здесь как в игре — правила должны быть известны всем.

Человеческие качества

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

Цель нашей ретроспективы — повысить эффективность процессов в работе, выявить текущие проблемы и сформировать дальнейший план изменений. Чтобы их решить, мы зафиксировали новый регламент: разработали структуру ретро и разделили его на несколько этапов. Рассмотрим их подробнее.

Подготовка к ретро

За день до ретро модератор напоминает участникам заполнить карточки в Miro. Последние пишут заметки в двух колонках «Что мне помогало в работе» и «Что мешало (закрыть спринт) и можно улучшить?». Здесь важно избегать чрезмерной похвалы коллег и очевидных проблем — например, «спасибо UX-проектировщику за то, что нарисовал прототип», или «у меня не получилось выполнить задачу в срок, потому что не было настроения».

Процесс после ретро

Это еще не конец! Team lead или product-менеджер создает задачи в Jira, чтобы организовать работу над текущими проблемами. Далее назначает исполнителей и копирует ссылку задачи на стикер.

Начало следующего спринта

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

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

#selectel #ретроспектива #личныйопыт #коммуникации #управлениекомандой #управлениепроектами #wbarticle