Жалуемся и радуемся: как и зачем мы проводим встречу, на которой обсуждаем «приколы» и «проблемки»?

Обсуждаем, зачем нужно ретро и чем этот процесс может быть полезен в работе.

Привет! Меня зовут Маша Партус, я проектировщик интерфейсов клиентских и внутренних сервисов в Selectel. Хочу поделиться историей, как мы ввели ретро в команде, в которой его никогда не было. Рассказываю, зачем это вообще нужно, на какие грабли мы наступили и чего в итоге добились. Если хотите внедрить ретро у себя и предпочитаете учиться на чужих ошибках, можете воспользоваться нашим опытом.

Используйте навигацию, чтобы перейти к нужному разделу:

→ Как дошли мы до жизни такой

→ Первое ретро

→ К чему пришли

→ Советы ведущему

→ Итоги

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

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

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

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

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

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

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

Во-вторых, мы пытались придумать решения для почти всех поднятых проблем. Фактически только на эту часть мы потратили два часа.

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

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

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

Теперь мы отводим под наше ретро максимум два часа, но укладываемся обычно в полтора.

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

На этом этапе участники по очереди перетаскивают свои стикеры на доски и озвучивают их. Количество стикеров на участника ограничено: два на «приколы» и два на «проблемки».

После того, как все высказались, мы начинаем голосовать за самые откликающиеся стикеры. Количество голосов тоже ограничено: два — для рядового сотрудника и пять — для руководителя. У руководителя больше голосов, потому что он видит общую картину работы отдела и способен лучше оценить, на решение какой из проблем сейчас важнее направить силы. Голосование за «Приколы» помогает понять, что команду больше всего порадовало за прошедший месяц, а лидеров «Проблемок» мы будем разбирать на следующей доске.

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

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

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

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

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

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

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

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

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

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

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

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

А в вашей команде есть ретро? Если да, нравится ли вам такой формат? Поделитесь в комментариях.