Привет! На связи Оля Муттер, руководитель проектного офиса в СберМаркете. Я помогаю выстраивать процессы для эффективной работы команд, развиваю проджект-менеджеров и подходы к управлению проектами. 

Внутри компании мы активно используем ретроспективы: за последние четыре года я провела больше 350 таких встреч. Но не всегда ретроспективы внутри кросс-функциональных команд эффективны против проблем в рамках конкретных функций. Поэтому формат Retro я попробовала адаптировать и применить для функциональных решения проблем. В статье расскажу, как это было и дам шаблоны и рекомендации, как забрать практику к себе.

Представим фронтендера Даню. Он работает в кросс-функциональной команде: с бэкендерами, аналитиками, дизайнерами и т. д. У Дани есть проблемы с рабочим окружением, он не понимает, какую из многочисленных библиотек использовать, как избавиться от постоянного легаси в коде. Он пытается обсудить эти проблемы на ретроспективе внутри команды, но никто из восьми человек не может помочь. Даже если команда и пытается помочь, то ей может не хватить ресурса, чтоб исправить проблему комплексно. Фронтендер Даня страдает.

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

Отличия технической ретроспективы от обычной

Любая ретроспектива — это мероприятие, которое помогает повысить эффективность команды. Но в деталях есть большая разница.

Чего мы добились введением TechRetro

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

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

1. Появились зоны ответственности у всех фронтендеров из доменов, где мы проводили TechRetro.

2. Задачи по избавлению от техдолга собрались в единый приоретизированный список.

3. Ускорился процесс ревью.

4. Сократилось количество чатов. Теперь понятно, куда и за какой информацией обращаться, — не только самим фронтендерам, но и остальным специалистам.

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

6. Создан технический радар, который помог понять, какие технологии у нас используются и от чего мы хотим избавиться.

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

Как собрать техническую ретроспективу

Наконец, переходим к инструкции. Помимо того, что нужно правильно структурировать ретроспективу, к ней нужно правильно подготовиться. Успешно провести TechRetro с налета может только тот, кто провел ее уже много раз.

Как подготовиться?

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

2. Донесите ценность. У каждого мероприятия должна быть адженда: что будем делать, что хотим получить. Покажите, что ретроспектива нужна каждому фронтендеру, потому что он сможет вынести на обсуждение то, что его беспокоит, и получить рабочие советы или помощь.

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

Соберите TechRetro по одному из шаблонов в Miro. У нас в компании есть конструктор шаблонов, который наполняют наши скрам-мастера и любой может собрать ретро из них — делюсь с вами некоторыми из них. Эти шаблоны общие как для командной ретроспективы, так и для технической. Но вопросы и данные, с которыми мы работаем на встречах отличаются.

Этапы технической ретроспективы

Открытие (5-7 минут)

Многие пропускают этот этап, и зря: он позволяет вовлечь в ретроспективу всех участников, переключить их с рутины на вдумчивый разговор.

Если TechRetro проходит впервые, расскажите, что это такое, еще раз проговорите адженду. Попросите участников рассказать, в каких командах и чем они занимаются, где видят слабые места.

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

Другой вариант для старта — провести диагностику отношения к ретроспективе. Пусть каждый участник скажет, кто он:

• исследователь (способен генерировать много проблем и много решений)

• покупатель (принес одну проблему и нацелен ее обсудить)

• отдыхающий (устал, хочет развлечься)

• заключенный (не хочет быть на ретроспективе)

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

Третий вариант — поработать на сплочение и дать возможность участникам познакомиться поближе. Этот вариант подходит лучше всего, когда никто не знает друг друга и нет возможности устроить тимбилдинг.

Сбор данных (15 минут)

На этом этапе мы прорисовываем общий контекст и формулируем проблемы, которые будем обсуждать на встрече.

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

Альтернативный подход — организовать маленький health check. Выберите четыре характеристики и оцените по десятибалльной шкале. Это похоже на колесо жизненного баланса. Характеристики зависят от участников ретроспективы. Можно брать, например, технологии, взаимозаменяемость, коммуникации и экспертизу. 

Третий вариант —  собрать данные через призму абстракции. Вопрос «Какой суперсилы нам не хватает?» помогает растормошить ребят, выводит их на интересные ответы.

Генерация идей (20 минут)

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

Здесь можно оттолкнуться от выявления узких мест в процессе. Какие проблемы уже решают, то итога нет? Участникам нужно подумать, что они уже делают, что еще не пробовали, какие есть препятствия и как их устранить.

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

План действий (10 минут)

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

Если участники сгенерировали слишком много решений, нужно сократить количество, выбрав самые актуальные с учетом ресурсов команды. С выбором поможет матрица с осями «Сложность» и «Ценность». Нужна наибольшая ценность при наименьшей трудоемкости.

Закрытие (5-7 минут)

Это возможность получить обратную связь по ретроспективе, договориться о правилах: будем ли еще проводить техническую ретроспективу, нужно ли что-то поменять, кого-то позвать.

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

Самое главное — закончить на позитивной ноте. Я ввожу этап, когда участники благодарят друг друга за что-то внутри ретроспективы или вообще рабочих процессов.

Что может пойти не так во время TechRetro

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

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

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

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

А что, если…

…нет человека, который будет вести TechRetro? Возьмите инициативу на себя.

…вы никогда не проводили ретроспектив? Еще раз прикрепляю шаблоны.

…у вас больше 10-12 человек? Поделите их на группы: по доменам или поддоменам, по людям, которые как-то соприкасаются друг с другом в рабочих процессах. Иначе вы не сможете услышать каждого участника.

…ваши проблемы нельзя решить? Проверьте, действительно ли это так. Скорее всего, в компании все же есть человек с соответствующими компетенциями, — найдите его.

…сотрудники считают, что это бесполезно? Донести до них ценность вы сможете только с помощью действий. Заберите их проблемы и через какое-то время принесите решение.

Техническая ретроспектива объединяет сотрудников внутри одного направления, позволяет сделать health check текущей ситуации, а затем — наметить конкретные действия. Вы можете сразу решить, что этот инструмент вам не подходит, а можете прийти завтра на работу и провести мини-TechRetro. Скорее всего, вскроются проблемы, о которых вы даже не слышали, и, соответственно, новые точки роста.

Спасибо за то, что дочитали до конца! Сохраните материал, если он показался вам полезным и задайте вопросы в комментариях, если что-то осталось непонятным :)

У Tech-команды СберМаркета появились соцсети с новостями и анонсами. Следи за нами в Telegram и на  YouTube, если хочешь узнать, что под капотом высоконагруженного e-commerce. А также у нас есть подкаст «Для tech и этих». Там наши EM-ы пытаются понять, как крутые IT-компании стали теми, кого мы любим, и чему у них можно поучиться.