Команда несерьёзно относится к ретроспективе – что делать?
– рассказывает Екатерина, руководитель направления QA
Ретро в команде посещают «для галочки». Коллеги не слушают друг друга, каждый параллельно делает второстепенные задачи. Постоянно стандартные фразы: в целом всё понравилось, были небольшие проблемы, будем в следующем спринте работать усерднее… Непродуктивно, неприятно 😖

Что можно сделать
▪️ Обсудить с командой проблемы. Выяснить, что им не нравится в формате проведения: что лишнее, а чего не хватает. Возможно, стоит отдельно поговорить с «лидерами мнений», наиболее опытными специалистами, к которым идут за советами и прислушиваются. И ещё раз объяснить цели.
▪️ Вариант для гибридного посещения – офлайн-ретро. Если у команды принято в какой-то день работать из офиса, можно провести ретроспективу именно в этот день. А остальных участников подключить онлайн. Вовлечённость в таком случае выше.
▪️ Попробовать изменить время. Конец рабочего дня или время перед обедом – это «ленивые» слоты. Все на низком старте, чтобы доделать рабочие дела и пойти по своим)
Заранее узнайте мнения коллег на one-to-one.

Пожелания к любым командным встречам, чтобы они были полезными
▪️ Помогайте коллегам высказаться – пусть встреча для них будет прогнозируемой. Составьте план встречи по обсуждаемым вопросам и придерживайтесь его. Дополнительно можно определить порядок: например, начинают аналитики, следом за ними тестировщики и т.д. Так не будет неожиданностей + объединим коллег из одного направления – а обсуждать вопросы, которые непосредственно относятся к тебе, согласитесь, интереснее. Постепенно привычка говорить закрепится.
▪️ Исключайте лишнее. Контролируйте себя и других – встреча должна соответствовать заявленной повестке. Так легче получить конкретные предложения и, соответственно, проследить изменения по ним. Прививаем мысль, что ретроспектива – это про пользу 🙌
▪️ Включайте коллег в обсуждение. Если разработчик реализовал задачу по её описанию и в итоге пропустил требование – выясните причины и предложения не только у него. Спросите у аналитика, по какой структуре ему удобнее работать – может, требования всегда должны быть в отдельной ссылке? У кого были подобные проблемы?
▪️ Обсуждайте реальные кейсы. Общие слова картину не покажут, а все будут относиться к ретро как к своей курсовой – лишь бы не захлебнуться. Так что мотивируйте коллег говорить реальными примерами.
Не «возможно, нам стоит реже обновлять компоненты», а «постоянные обновления компонентов снижают мою результативность, с понедельника по среду я тратил на это по 4 часа и не смог закончить задачу».

Всем полезных встреч ✌️