«Эволюция ретро»: зачем трижды меняли формат и какие проблемы хотели решить
Рассказываем, как и почему продуктовая команда стала использовать ретроспективу.
Привет! Я — Таня Афанасьева, менеджер продукта в Selectel. Наш отдел занимается разработкой и поддержанием внешних сетевых сервисов, например CDN. Команда состоит из десяти человек, среди них — team lead, product-менеджер, UX-специалист, разработчики, DevOps-инженеры и другие. Основной состав сформировался два года назад, когда компания объединила несколько продуктов в один сервис. Большинство приходили из других отделов или компаний, поэтому коллеги изначально не были знакомы друг с другом.
Со временем мы начали сталкиваться с типичными проблемами развития проектов, которые негативно влияли на результаты продукта и общую атмосферу в команде. Коллеги не понимали, какая цель у задачи, почему важно выполнить в определенный срок и зачем синхронизироваться с другими. Чтобы решить эти проблемы, нужно было наладить коммуникацию и отрефлексировать предыдущий опыт. Тогда мы и решили использовать ретроспективу. В тексте расскажем, что у нас получилось.
Что такое ретро
Ретроспектива, или ретро — процесс, в котором сотрудники анализируют проделанную работу, выявляют проблемы и способы для улучшения текущих процессов. После саморефлексии коллеги могут быстро достигать поставленных целей и качественно выполнять задачи в спринтах.
Обычно ретро проводят в конце рабочего спринта или проекта. Длительность зависит от количества коллег и масштабности задач, но, в основном, один-два часа. На встрече участники по очереди делятся своими выводами, а после обсуждают идеи друг друга. Также на ретро присутствует фасилитатор, обычно это team lead или product manager.
Весь процесс основан на прозрачности и доверии внутри команды. Это помогает наладить коммуникацию между коллегами и предотвратить проблемы до того, как они превратятся в серьезные барьеры.
Первый формат, или «нытинг»
Единого формата ретро не существует — каждая команда адаптирует его под свои цели и задачи. Например, коллеги из клиентских и внутренних сервисов весело обсуждают «Приколы», «Проблемки» и «Решения», а потом голосуют за самые откликающиеся стикеры. Мы же, наоборот, выбрали стандартизированный формат и стали использовать Confluence — он не требовал значительной подготовки и имел легкий процесс.
Ретро команды клиентских и внутренних сервисов. Источник.
Во внутренней базе знаний можно с легкостью делиться результатами, видеть историю обсуждений и отслеживать прогресс задач. До ретро наша команда использовала Confluence для документации продукта, поэтому на тот момент это казалось логичным решением.
Мы разделили страницу на три блока: «Что помогало работе?», «Что мешало (закрыть спринт) и можно улучшить?» и «Чему научились новому? Что нового узнали?». В течение спринта коллеги оставляли ответы на вопросы, а на встрече зачитывали их слух. Модератором ретро была я.
Пример первого формата ретро. Все записи выдуманные.
Недостатки
Вскоре стало очевидно, что формат обладает существенными недостатками. Нужно было его улучшить, чтобы справиться с рядом возникающих проблем.
- У нас не было четкой цели. Ребята жаловались на рабочие проблемы, но к следующему спринту ничего не меняли. Таким образом, ретро не решало наши проблемы, а служило инструментом для выплескивания эмоций.
- Интерфейс Confluence не подходил для интерактивного взаимодействия, потому что был слишком формализованным и сухим. Возникало ощущение, будто мы заполняли отчет, а не обсуждали проблемы.
- Ребята тратили много времени на подготовку записей. Все сводилось к тому, что участники забывали заполнить страницу. В результате из десяти человек писали только двое.
- Каждый по очереди читал свои записи вслух. Ретро превращалось в монотонную лекцию, на которую участники не хотели ходить.
Второй формат, или «проблемы есть, но решать мы их не будем»
Новый формат перенесли в Miro, его удобно использовать для брейншторма, планирования и решения совместных задач. На доске разместили три столбца с предыдущими вопросами, только переформулировали в well, sad и new. Каждому участнику раздали карточки для записей.
Пример второго формата ретро. Все записи выдуманные.
В первые десять минут участники готовили свои записи, а после — обсуждали вместе с командой. В отличие от предыдущего ретро, в этом формате мы не только рассказывали о проблеме, но и планировали, как ее решить. Из полученных карточек создавали задачи и фиксировали на полях, чтобы не забыть. В результате ретро стало более интерактивным, каждый мог внести свои предложения по решению проблем.
Недостатки
У каждого формата ретро свои недостатки, и это не исключение. Благо, их было намного меньше, чем в первом.
- Участники заполняли страницу только в начале ретро. Обычно спринт длится две недели, поэтому под конец большинство не могли вспомнить, что было на прошлой.
- Будущие задачи не отслеживались и часто забывались. Придумать решение проблемы — легко, но чтобы его проконтролировать, нужно постараться.
- Сохранялся формат «нытинга». Все приходили на встречу, чтобы пожаловаться, а не получить результаты.
Принципы «здорового» ретро
Вновь изменит формат ретро — недостаточно. Нужно было сформулировать принципы, по которым будет функционировать наше «мероприятие». С их помощью можно решить проблемы, которые возникают у команды в процессе работы над общими задачами.
Желание и проактивность
На ретро коллеги могут открыто делиться своими идеями, проблемами и решениями. Никто их не осудит — наоборот, такие инициативы поощряются. Если участники не видят проблемы и не готовы их обсуждать, ретро можно не проводить. Менеджерам стоит пересмотреть задачи и наладить коммуникацию в команде.
Командная работа
Мы проводим ретро для внутренней команды, поэтому на ней должны присутствовать все участники проекта или продукта. Сотрудников смежных отделов и топ-менеджеров не приглашаем. Важно, чтобы коллеги могли чувствовать себя комфортно и открыто.
Кроме того, все задачи и решения, которые приняли на встрече, являются ответственностью самих участников, а не руководителя. Это позволяет каждому члену команды чувствовать свою значимость и влиять на эффективность процесса.
Модератор
В команде должен быть человек, который занимается подготовкой и анализом ретро, чтобы исключать саботаж от коллег. Например, когда специалист утверждает, что у него все в порядке, но на самом деле выполнил спринт за последний квартал лишь на 15%, или когда поставили задачу, но исполнитель о ней забыл и не решил проблему.
При этом необходимо выделить фасилитатора, который будет задавать уточняющие вопросы и направлять участников в процессе обсуждения. Эту роль можно объединить с обязанностями модератора ретроспективы.
Регулярность и постоянство
До сих пор мы не можем определить, сколько времени готовы выделять на ревью. Пока решили остановиться на одной встрече раз в две недели по полтора-два часа. Возможно, в будущем передумаем.
Также важно установить единый формат ретро. Команда должна понимать, зачем мы его проводим и какие у нас цели. Здесь как в игре — правила должны быть известны всем.
Человеческие качества
Конструктивность, открытость, честность и уважение — это базовые принципы, которые применяются во всех процессах. Без них сложно выстроить здоровую коммуникацию и взаимодействие в команде.
Третий формат
Цель нашей ретроспективы — повысить эффективность процессов в работе, выявить текущие проблемы и сформировать дальнейший план изменений. Чтобы их решить, мы зафиксировали новый регламент: разработали структуру ретро и разделили его на несколько этапов. Рассмотрим их подробнее.
Подготовка к ретро
За день до ретро модератор напоминает участникам заполнить карточки в Miro. Последние пишут заметки в двух колонках «Что мне помогало в работе» и «Что мешало (закрыть спринт) и можно улучшить?». Здесь важно избегать чрезмерной похвалы коллег и очевидных проблем — например, «спасибо UX-проектировщику за то, что нарисовал прототип», или «у меня не получилось выполнить задачу в срок, потому что не было настроения».
Структура ретро
| Этап | Время | Описание |
| Разбор задач с предыдущего ретро | ||
| Разбор задач | 5 минут | Ведущий озвучивает статусы задач, которые были запланированы на предыдущем ретро. Нерешенные актуализируются и остаются до следующего раза. |
| Подготовка к ретро | ||
| Сбор данных | 5 минут | Участники выписывают заранее подготовленные карточки на доску в двух колонках «Что мне помогало в работе» и «Что мешало (закрыть спринт) и можно улучшить?». |
| Блок 1. «Что было хорошо и помогало работе?» | ||
| Озвучивание стикеров | 15 минут | Участники по очереди делятся своими карточками и по желанию ставят эмодзи на стикеры. Иногда количество реакций показывает, что озвученная проблема актуальна для многих и точно перейдет во второй этап. |
| Блок 2. «Что мешало (закрыть спринт) и можно улучшить?» | ||
| Озвучивание стикеров | 20-30 минут | Участники повторяют действие с предыдущего этапа: озвучивают свои проблемы и сложности, с которыми столкнулись во время спринта. |
| Спринт | 5 минут | Модератор открывает текущий спринт и задает коллегам открытые вопросы, например «Что помешало выполнить эту задачу?». Полученные ответы также выносит на доску «Что мешало» — они пригодятся на следующем этапе. |
| Анализ | 5 минут | Модератор определяет и переносит важные проблемы на доску для второго этапа — «Анализ проблем и мозговой штурм».Если участник поделился проблемой личного характера или карточка не набрала голосов, то ее решают индивидуально, на one2one. Такие карточки находятся в зоне ответственности прямого руководителя — team lead или product-менеджера. |
| Генерация идей и составление плана действий | ||
| Генерация идей | 30 минут | Команда анализирует выявленные проблемы и начинает генерировать идеи, которые помогут их решить. Как только они останавливаются на конкретном варианте, ведущий фиксирует заметку в action items и назначает ответственного. Когда решение проблемы затягивается, team lead или product-менеджер отдельно выносит ее на доску и обсуждает на one2one. Далее команда переходит к следующей проблемы, и так до тех пор, пока не обсудят все основные. В конце ретро у участников есть action items с конкретными сроками и исполнителями. |
| Завершение | ||
| Фидбек | 3 минуты | Модератор просит оценить ретро по пятибалльной шкале и по необходимости оставить комментарий, например «как все прошло». Обратная связь помогает понять, как ретро решает проблемы и насколько команда довольна текущими процессами. |
Процесс после ретро
Это еще не конец! Team lead или product-менеджер создает задачи в Jira, чтобы организовать работу над текущими проблемами. Далее назначает исполнителей и копирует ссылку задачи на стикер.
Начало следующего спринта
В начале нового спринта команда проводит планирование, чтобы обсудить задачи, которые участники возьмут в работу на этой неделе. Не все решения обязательно внедрять строго до следующего ретро. Важно обозначить только сроки, чтобы не затягивать выполнение и отслеживать свой прогресс. Так мы можем корректировать курс и адаптировать действия к изменяющимся условиям.
Заключение
Ретро позволило нам достичь нескольких ключевых целей, которые мы ставили в начале. В частности, мы смогли вовлечь участников в процесс и решить некоторые проблемы внутри команды. Конечно, третий формат не идеален: иногда приходится «вытягивать» информацию от участников, но мы продолжаем работать над этим.
