Как мы трижды меняли формат «Ретро» и какие проблемы хотели решить

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

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

Используйте навигацию, если не хотите читать полностью:
→ Что такое ретро
→ Первый формат, или «нытинг»
→ Второй формат, или «проблемы есть, но решать мы их не будем»
→ Третий формат
→ Заключение

Приглашаем 10 октября на Selectel Tech Day
Расскажем о новинках на рынке и обновлениях в наших продуктах. Вас ждут доклады, нетворкинг, мастер-классы и вечерняя программа. Участие бесплатное, но нужно зарегистрироваться.

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

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

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

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

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

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

Ретро команды клиентских и внутренних сервисов. Источник.

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

Пример первого формата ретро. Все записи выдуманные.

Недостатки

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

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

Второй формат, или «проблемы есть, но решать мы их не будем»

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

Пример второго формата ретро. Все записи выдуманные.

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

Недостатки

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

• Участники заполняли страницу только в начале ретро. Обычно спринт длится две недели, поэтому под конец большинство не могли вспомнить, что было на прошлой.
• Будущие задачи не отслеживались и часто забывались. Придумать решение проблемы — легко, но чтобы его проконтролировать, нужно постараться.
• Сохранялся формат «нытинга». Все приходили на встречу, чтобы пожаловаться, а не получить результаты.

Принципы «здорового» ретро

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

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

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

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

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

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

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

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

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

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

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

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

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

Структура ретро

Этап 1. «Что было хорошо и помогало работе?» и «Что мешало (закрыть спринт) и можно улучшить?».

Этап 2. Анализ проблем и мозговой штурм.

Этап 3. Формируем action items.

Завершение ретро и фидбэк коллег.

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

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

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

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

Заключение

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

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