Привет! Я Василий, руководитель отдела тестирования в финансовом маркетплейсе Сравни. Хочу поделиться опытом организации ретроспективных встреч, рассказать, как мы выстраивали процесс, что из этого вышло и какие выводы мы сделали. Этот материал будет полезен для тех, кто еще только планирует организацию ретро и хочет узнать чужой опыт.
Начнем с того, что вся продуктовая часть Сравни делится на кроссфункциональные команды. В каждой продуктовой команде есть свой разработчик, аналитик, тестировщик и тд. Сейчас в разных продуктовых командах работает 21 тестировщик. Вместе с развитием продуктов у нас появилась проблема, которая заключалась в рассинхронизации команды тестировщиков: коллеги не знали, кто чем занимается внутри маленьких команд, каждый тестировщик находился в своем “мире” внутри команды. Мы поняли, что начинать работу по улучшению нам надо с командообразующего инструмента.
Общение между сотрудниками моего отдела в основном строилось за счет личных коммуникаций, при этом так завелось, что у нас не было групповых встреч, где мы могли бы поговорить о своих проблемах, поделится новостями и что-то обсудить. У меня родилась идея, как организовать процесс работы и запустить встречи команды. При этом я принял решение, что эти встречи будут иметь не просто ознакомительную и коммуникационную цель, но и практическую.
Организация ретро началась со встречи с Scrum-мастером. На встрече мы определили этапы для достижения общей цели, выделили темы, по которым мы пройдемся, расписали тайминг встречи, продумали возможные варианты ее развития. Цели встречи мы определяли с помощью правил пяти “П” — когда определяется поставленная цель, продукт, приглашенные участники, проблемы и процесс. Впоследствии мы всей командой проголосовали, какие именно проблемы будем решать в первую очередь. Мы подготовили доски под наши сценарии и организовали зум-встречу.
Поскольку встреча для всей команды была первая, мы начали ее со знакомства: рассказали о себе, хобби, планах и страхах. Как руководитель команды могу отметить, что по итогам обратной связи, которую я собирал после встреч, такая активность ребятам понравилась, и им ее не хватало, после нее стало проще работать и обращаться за помощью к своим коллегам.
Когда мы с командой перешли к практической части, у нас уже был определен пул проблем, которые нам нужно было решить. Наш Scrum-мастер помог провести голосование за наиболее “болезненные места” для всех членов команды. Оценку проводили с использованием модели Health Check, в такой модели команда сама оценивает себя с помощью индикаторов — вопросов или утверждений, на которых команда должна ответить или оценить, а также с помощью Светофора — способа оценки, которую должен дать отдельный участник на определенный индикатор.
После определения наиболее критичных проблем мы разделились на команды по 4-5 человек. Я сам определил, кто с кем будет работать, исходя из принципа распределения тестировщиков из близких команд. Это было сделано, чтобы менее опытные сокомандники не испытывали стеснения и неловкости при обсуждении той или иной проблемы, как если бы они находились в группе с более сильными членами своей же команды. Каждая сформированная команда разбирала проблему и записывала тикеты с ее решением. Затем происходила ротация команд внутри конференции таким образом, что все команды проработали каждую задачу.
Оказалось, что для нас самыми проблемными и актуальными темами стали процессы и рабочие инструменты.
На второй встрече мы разобрали задачи, с которых начнем работу, и решили, что мы можем сделать своими силами, а с чем нам нужна помощь. Также поставили себе дедлайны и определили ответственного за ту или иную проблему.
На примере одной из наших проблемных зон расскажу, какие задачи нужно было выполнить.
Мы с командой выявили проблемы, с которыми сталкиваются новички в команде: они не понимают какой канал в Слаке или какой человек отвечает за тот или иной продукт.
Поэтому было принято решение в каждый канал добавить описание, какие вопросы в нем решаются, за какие продукты он несет ответственность. Навели порядок в нашей wiki. У каждой команды появилась посадочная страница, которая давала бы более подробное представление о том, что это за команда и чем она занимается.
Многие из тех, кто работал с web, хотели научиться настраивать тестовое приложение. Поэтому вторая задача заключалась в том, чтобы предоставить желающим сотрудникам возможность углубиться в практику по проверке приложения на мобильном устройстве.
Была собрана информация о том, кто какие устройства использует и подготовлены инструкции и проведено два воркошопа с записью по iOS и Android.
Мы также решили сделать карту взаимодействия микросервисов — в команде Сравни мы используем достаточно большое количество сервисов, поэтому была необходимость понимать, кто с кем взаимодействует.
Задача была решена успешно и даже спустя год мы пользуемся результатами той работы и собираем благодарности коллег. Важная часть — облегчение онбординга, более эффективная организация общих задач и выявление ответственных. Все новички компании начинают знакомство с наших наработок. На данный момент мы активно внедряем в свои ряды Backstage для автоматизации этой работы, подробнее про наш опыт внедрения будет в отдельной статье.
Все активности мы проводили с трехмесячными интеграциями. Во время проведения третьего этапа встреч мы заметили, что менее приоритетные задачи, которые были выделены в начале года, потеряли актуальность. Уже не было того блеска в глазах в процессе исполнения задач, энтузиазм сильно угас, после чего было принято решение завершить эту большую годовую активность.
Если резюмировать: ретроспективные встречи должны проводиться, но по нашему опыту могу отметить, что оптимальный график проведения — раз в полгода. Однако работать надо только с актуальными проблемами, которые важны в данный период времени, и не возвращаться к проблемам прошлых встреч.
Из плюсов ретроспективных встреч можно выделить их хороший командообразующий формат, с помощью которого сотрудники видят поддержку и одобрение со стороны коллег. Я также заметил, что у тех сотрудников, которые курировали активности, прокачались менеджерские скиллы, поскольку приходилось не только решать свои задачи, но и организовывать других коллег. Еще у сотрудников развилась командная ответственность. К минусам нашего опыта можно причислить то, что мы зря “тянули” менее приоритетные задачи от встречи к встрече, поэтому для себя мы решили, что в дальнейшем будем фокусироваться только на актуальных проблемах.
