Как стать автором
Обновить

Большая ретроспектива на несколько команд. Зачем она нужна, и как ее провести с пользой

Время на прочтение7 мин
Количество просмотров2.9K

Часть 1. Вводная зачемная

Привет. Я Лена, скрам-мастер в «Ренессанс страхование». Мы с коллегами в командах реализуем классные фичи в страховании и рады, когда наш функционал действительно получается востребован. Стараемся еще, конечно, чтобы получался он не только качественно, но и быстро, как это обычно требуется в современном мире.

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

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

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

Может возникнуть вопрос, зачем мы в целом решили провести общее ретро. Цели у этой встречи были такие:

  • собрать все произошедшие за год события на одном борде;

  • получить мнения всех участников процесса: и ребят из фиче-команд, и заказчиков, и пользователей продукта;

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

  • определить те проблемы / достижения, которые важны для всех команд в целом;

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

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

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

Часть 2. Как это было

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

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

План на ретроспективу у нас был такой:

  1. Небольшая разминка

  2. Определение хороших сторон работы над продуктом и моментов, которые нужно улучшать / менять

  3. Голосование

  4. Поиск корневых причин выбранных карточек методом "5 почему"

  5. Определение идей по работе с выявленными причинами

  6. Сбор обратной связи по итогам ретро

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

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

Теперь чуть подробнее про каждый из этапов:

1. Небольшая разминка

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

В разминке главное, чтобы участники начали общаться по какой-то общей теме, которая задана, поэтому нужно 2 шага:

* Выбрать тему

* В каждую команду добавить фасилитатора

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

При делении на группы - в нашем случае отдельные комнаты в зуме - в каждой комнате был фасилитатор.

Несколько минут на обсуждение - и далее кто-то от группы рассказывает итог дискуссии.

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

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

2. Определение хороших сторон работы над продуктом и моментов, которые нужно улучшать / менять

Второй этап сразу определялся, как один из самых долгих.

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

В связи с тем, что продукт разрабатывался долго, мы вместе с продакт оунерами еще договорились поделить процесс генерации карточек по кварталам, для этого заранее сформировав timeline такого вида:

 

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

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

3. Голосование

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

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

4. Поиск корневых причин выбранных карточек методом "5 почему"

Обсуждать выигравшие карточки мы решили с помощью метода "5 почему". Про сам метод можно почитать здесь: https://habr.com/ru/company/renins/blog/554896/

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

Изначально выигравшие в голосовании карточки были размещены в 4 блока в отдельной зоне на доске. Далее мы вновь поделили участников ретро на 4 группы. Правило "по одному фасилитатору в каждой группе" осталось неизменным.

Засекли таймер. Несколько раз продлили время (несмотря на то, что у каждой группы было не более 3 карточек для обсуждения, времени заложили маловато). В итоге получили корневые, по мнению ребят, причины возникновения тех или иных ситуаций.

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

5. Определение идей по работе с выявленными причинами

Итак, получили причины. Что же дальше?

А дальше для каждой причины нужно было выработать идеи, как в будущем работать при возникновении подобного поинта, и, самое главное, кто, что и когда должен сделать, чтобы идея была реализована. Для работы с описанием идей и дальнейших шагов по ним выбрали самый простой метод 4 вопросов: Зачем мы что-то делаем, Кто что-то сделает, Как это нужно сделать, Что именно нужно сделать.

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

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

В результате должен получиться список задач, который озвучивается всем, кто присутствует на встрече. По нему можно также задать вопросы / дать комментарии.

На данный шаг нужно заложить много времени, чтобы не доделывать его потом.

6. Сбор обратной связи по итогам ретро

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

Данная итерация - финал большой сложной проведенной работы.

ПЕРЕРЫВЫ

Были. Не упоминала по тексту, так как перерывы стоит регулировать в зависимости от длительности каждого блока. У нас они были запланированы изначально по 10 минут каждые 1 - 1,5 часа.

Часть 3. Результативное "что дальше-то"

Вот мы собрали список проблем, определили их причины, накидали идеи по улучшению процесса, а что дальше?

На самом деле дальше самое интересное - воплощение озвученных поинтов в жизнь.

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

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

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

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

Если вы прочли этот пост, и он у вас отозвался мыслью, что нужно провести подобное мероприятие для вашего текущего продукта (или проекта - ретро нужно и полезно при любом подходе), то вот несколько советов, которые мы вынесли для себя, в том числе после сбора обратной связи от команд:

  1. Не затягивать с ретро на несколько команд.

  2. Делать такого формата ретро долгими, на весь день.

  3. При делении на группы не определять всех специалистов одной роли в одну группу.

  4. Давать больше времени на поиск причин проблем и на генерацию идей.

  5. Звать всех, кто может быть ответственными за реализацию идей, на такие встречи.

Это несколько поинтов для улучшения на будущее и нам в том числе.

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


Теги:
Хабы:
Всего голосов 3: ↑0 и ↓3-3
Комментарии9

Публикации

Информация

Сайт
www.renins.ru
Дата регистрации
Дата основания
Численность
1 001–5 000 человек
Местоположение
Россия

Истории