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