Бытует мнение, что ретроспектива это скучная встреча без явной пользы. Если ставить цель, фиксировать прогресс и подбирать интересный формат ретроспективы, то польза от этой командной встречи не заставит себя ждать. В статье вы найдете 3 варианта эффективных ретроспектив, проводимых в командах разработки Ozon. Наш кейс Теория ретроспективы Три варианта ретроспективы Колесо фортуны Таймлайн Здоровье продукта Заключение и список источников Команда, состоящая из удалённых специалистов, которые друг друга никогда не видели и приходят на видеозвонки с аватарками, — наш случай. Я думаю, такой кейс знаком многим в IT-индустрии.  Мы проводим ретроспективу в конце каждого спринта, то есть раз в две недели. Сначала участники команды были пассивны, часто отмалчивались — и ретроспектива превращалась в монолог технического лида. Взаимодействие внутри команды было похоже на многоэтажный дом, где никто никого не знает, никто ни с кем не разговаривает, но при этом регулярно возникают проблемы: с верхнего этажа затопили, мусор оставили не там, где надо, в подъезде накурили.  С техлидами мы старались наладить коммуникацию и превратить ретроспективу в открытое общение, поэтому стали экспериментировать с форматами. Некоторые подходы показали хорошие результаты, поэтому я решила ими поделиться. Польза от данных форматов ретроспектив: задействованы все члены команды; атмосфера способствует открытому общению; становится легче разговаривать и понимать друг друга на созвонах; появляется ощущение коллектива и командной работы. Обучение менеджеров под одну копирку Agile, Scrum, Kanban привело к тому, что у многих сложился однобокий взгляд, что такое ретроспектива и как ее проводить. Как правило, на таких встречах обсуждаются три вопроса: Что было хорошо? Что было плохо? Как улучшить то, что было плохо? Описание ретроспективы из Scrum гайда звучит следующим образом: Цель Sprint Retrospective — запланировать повышение качества и эффективности… Участники Scrum Team обсуждают, что прошло хорошо во время Sprint, с какими проблемами они столкнулись и как эти проблемы были (или не были) решены. Напомню, что Scrum в США стали практиковать в 1990-х, а в 2010 году появился альманах Scrum Guide. В то время команды разработки в основном трудились в офисе, много общались и взаимодействовали. Они обедали вместе, пели в караоке на корпоративах и обменивались новостями из личной жизни в курилке. Ситуация сильно изменилась в 2020 году, когда из-за пандемии многие стали работать удалённо. Теперь специалисты IT-компаний не ходят в офисы и не встречаются со своими коллегами вживую. Они практически не знакомы друг с другом, поэтому им сложно открыто и эмоционально выражать свои мысли. Для эффективной командной работы необходимо событие, сближающее людей. Таким образом, целью ретроспективы, помимо обсуждения итогов работы и планов на будущее, становится мини-тимбилдинг, или замещение курилки (где раньше происходило открытое общение, знакомство, обмен взглядами на мир).  Практикующие Agile компании активно развивают церемонии при удалённой работе, создают новые инструменты. На английском языке можно найти множество хороших идей для ретроспектив, в том числе шаблонов для онлайн-досок для совместной работы  (Miro, Figma и т. д.). Список источников я приведу в конце статьи.  Адаптировав для нашей компании несколько идей, я проводила ретроспективы в четырех IT-командах, относящихся к одному продукту. Атмосфера в командах разная, поэтому ретроспективы тоже отличались, однако всегда они проходили активно и помогали людям раскрыться. В процессе у меня появились свои идеи, подходящие под специфику команд. Далее я расскажу про три формата, получивших лучшие отклики от коллег. Это ретроспектива в виде викторины с заранее подготовленными вопросами. Её цели — вовлечь всех членов команды, получить ответы на вопросы и немного повеселиться. Интрига, кому достанется вопрос, помогает удерживать внимание участников на протяжении всей встречи.  Для такой ретроспективы понадобятся: поле, где будут представлены вопросы (редактировать участники команды его не будут — это прерогатива фасилитатора);  онлайн-колесо фортуны, которое нужно заполнить именами участников (пример: Random wheel); вопросы для викторины (их должно быть в полтора—два раза больше, чем участников).  Выберите один вопрос из списка на стикере и поместите его в центр поля. Раскрутите колесо фортуны и определите отвечающего. Отведите максимум три минуты на ответ. Задавайте дополнительные вопросы, если он слишком короткий. Если ответ засчитан, удалите отвечающего из списка отвечающих. Последнему участнику можно дать возможность выбрать вопрос из оставшихся. В процессе ретроспективы формируйте список договорённостей, а в конце — подведите итоги и напомните о планах на следующий спринт. Этот формат ретроспективы спас одну из команд, когда она разрослась до 20 с лишним человек. На другие форматы не хватало времени, либо при дискуссии не было времени выслушать всех участников, желающих высказаться.  В «Колесо фортуны» каждый член команды был минимум 1 раз в роли отвечающего. Плюс, пока крутилось колесо фортуны, все готовились отвечать на вопрос.  Вопросы я формулировала по рекомендациям в интернете, просила технических лидов рассказать, что им важно и интересно узнать у участников команды, чередовала серьёзные болезненные темы и вопросы для веселья и знакомства. Благодаря разнообразным вопросам про работу и личную жизнь удалось узнать много интересных фактов об участниках команды. В ходе ретроспективы было много шуток и обсуждений. Появилось ощущение коллектива и командной работы.  Примеры вопросов: Из того, что ты создал(а) для пользователей, что имеет наибольшую ценность? Расскажи про авторов, блогеров из твоей профессиональной сферы, которых ты читаешь/смотришь/уважаешь. У тебя получается соблюдать баланс между работой и личной жизнью? Что бесполезного тебе приходится делать?  Ретроспектива в этом формате проводится на онлайн-доске для совместной работы (Miro, Figma и др.), которую все члены команды могут одновременно редактировать. Поле представляет собой временную ленту с промежутками. Участники команды делятся воспоминаниями о важных событиях и обсуждают возможные решения в случае трудностей.  Есть два варианта: 1. Обсуждение итогов года: размечаем временную ленту по месяцам (январь—декабрь).2. Обсуждение итогов спринта: временная лента размечается по дням недели.  Предварительно необходимо подготовить поле для ретроспективы и «заморозить» его, чтобы при заполнении членами команды ничего не двигалось. Для команд, состоящих из 6—12 человек, я рекомендую проводить ретроспективы продолжительностью полтора часа.  Предложите членам команды включить камеры, чтобы было комфортнее вести беседу. Продемонстрируйте доску и расскажите о правилах. Покажите пример создания и заполнения стикера.  На стикере напишите значимое событие. Оно может быть как хорошим, так и плохим: повышение, решение сложной задачи, помощь со стороны коллеги, ошибка в разработке, конфликтная ситуация. Стикер поместите в столбик месяца/дня, когда произошло событие.  Порекомендуйте каждому сделать не менее двух стикеров и выделите на это пять—десять минут. Когда все завершат заполнение стикеров, разберите ответы членов команды. Начните с общих итогов, например обсудите, в каком месяце или в какой день произошло больше всего запомнившихся событий. Далее разберите каждый стикер отдельно и попросите его автора пояснить содержание (почему данное событие для него памятно).  В конце ретроспективы попросите участников проголосовать — и выберете самое яркое событие периода. В командах ребята были склонны отмалчиваться и ничего не делать на ретроспективах. Поэтому для каждого участника я заранее готовила стикеры определённого цвета — чтобы на доске сразу было видно, кто вовлечён в процесс, а кто — нет. Также я зачитывала часть текста со стикера и просила его автора прокомментировать её, задавала наводящие вопросы, чтобы человеку было проще делиться воспоминаниями. Примеры таких вопросов: Почему тебе было важно выполнить эту задачу? Как ты себя чувствовал(а) после конфликтного разговора с коллегой? Воспоминания о задачах прошедшего спринта помогали командам прочувствовать результаты своей деятельности. Ушло ощущение, что время пролетело, а ничего не сделали. Стала нагляднее рутина, на которую нужно отводить достаточно большое количество ресурсов при планировании: поддержка, вопросы, встречи, настройка инструментов.  Одной из самых методически продуманных и всеобъемлющих мне показалась ретроспектива «Здоровье продукта» компании Spotify. Она наглядно демонстрирует состояние команды с разных сторон: от качества кода до взаимоотношений в коллективе и времени на обучение. Участники команды ставят цветовую оценку тому, как они себя чувствуют в определённой сфере. Зелёная — «отлично», жёлтая — «средне», красная — «плохо». Из инструментов нужна онлайн-доска (Miro, Figma и др.) с предзаполненной таблицей. Разработчики будут на ней одновременно создавать стикеры, поэтому поле для ответов лучше подготовить заранее и «заморозить». Продемонстрируйте доску и расскажите о правилах. Покажите процесс создания стикеров разных цветов. Подробно разберите каждую область работы, которую нужно оценить. Попросите участников команды оценить своё самоощущение во всех областях.  После заполнения поля стикерами разберите выраженные тенденции: в таблице вы сразу увидите, каких ответов в каких строках (областях) больше. Разберите каждую область отдельно и попросите членов команды прокомментировать свои оценки. Возникающие в процессе ретроспективы договорённости вносите в отдельную таблицу, в которой зафиксируйте также ответственных сотрудников и сроки. Источник: Spotify Health Check: Everything You Need To Know Работа в командеХорошо — вы суперкоманда, у вас отличное взаимодействие. Плохо — вы сборище индивидуалов, которые не знают (и не хотят знать), что делают окружающие. ПоддержкаХорошо — вы всегда получаете необходимую поддержку и помощь, когда о ней просите. Плохо — вы увязаете в задаче, так как никто вам не хочет помочь. Пешка или участникХорошо — вы участвуете в принятии решений по задачам, над которыми работаете. Плохо — вы только пешка в чьей-то игре, никто не интересуется вашим мнением. МиссияХорошо — вы точно знаете, как ваша работа помогает развиваться компании. Плохо — вы не понимаете, зачем решаете свои рабочие задачи и как они влияют на бизнес. Здоровье кодаХорошо — вы гордитесь качеством вашего кода (другого вида работы); всё чисто, ясно, покрыто тестами. Плохо — ваша работа — «куча макулатуры», всё погрязло в техническом долге. Процессы работыХорошо — вас устраивает, как организована работа. Плохо — неоптимизированные процессы мешают нормально работать. ЦенностьХорошо — вы создаёте полезные вещи для заказчиков, гордитесь своей работой. Плохо — вы производите мусор, вам стыдно за свою работу; заказчики ненавидят вас. ОбучениеХорошо — вы постоянно на работе изучаете что-то новое.Плохо — у вас никогда не хватает времени на обучение. Скорость Хорошо — вы делаете свою работу очень быстро, без задержек. Плохо — вы никогда не заканчиваете работу в срок, вас всё время что-то отвлекает. Простой процесс по релизуХорошо — релизить легко, безопасно, безболезненно, многое автоматизировано. Плохо — релизить рискованно, больно, много ручной работы. Удовольствие от работыХорошо — вам нравится работа, вы получаете удовольствие от процесса.Плохо — вам скучно на работе. Ретроспективу «Здоровье продукта» мы проводили в командах несколько раз с промежутками месяц и больше, так как ставить оценку каждый раз одним и тем же сферам утомительно. Заполненное стикерами поле демонстрирует состояние каждого члена команды и общее настроение группы. Нормальная ситуация: больше половины стикеров — зелёные, достаточно жёлтых стикеров, есть красные. В команде, состоящей из живых людей, всё поле зелёным априори быть не может.Количество стикеров на одной из наших ретроспектив из 11 человек: 65 зелёных, 48 жёлтых, восемь красных.Яркие всплески красных стикеров подсказывали нам, в какой сфере и у кого критичная ситуация. Их ребята ставили редко, и это было сигналом того, что всё плохо и требует обсуждения всех членов команды.  Хорошо продуманный список сфер с пояснениями помог подсветить проблемы и положительные стороны нашей команды, что в течение рабочих будней сделать сложно. Например, стало известно, что талантливой разработчице не хватает времени на чтение статей и развитие из-за слишком большого объёма задач. Другой коллега сказал, что, по его мнению, у продукта высокое качество кода (на его предыдущем месте работы уровень разработки был значительно ниже).  Не знаю, как часто и в каких командах проводят данную ретроспективу в Spotify (и проводят ли), но было бы интересно сравнить оценки и комментарии людей из разных IT-компаний. В статье представлено всего три варианта ретроспективы. На самом деле можно найти и придумать намного больше. Буду рада, если вы поделитесь своими идеями или оставите комментарии с фидбэком, когда проведёте какую-нибудь ретроспективу из моей подборки. Для вдохновения скидываю хорошие источники идей ретроспектив (на английском). Успехов вам и продуктивной работы команд! 🖖 12 retrospective game ideas to keep your retros fun 7 retrospective templates we love and use at Miro Spotify Health Check: Everything You Need To Know  9 retrospective techniques that won’t bore your team to death  Diwali Retrospective  How to Run An Effective Sprint Retrospective (Plus 7 Examples and Templates)  Product Manager