Часть 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. Звать всех, кто может быть ответственными за реализацию идей, на такие встречи.
Это несколько поинтов для улучшения на будущее и нам в том числе.
Ну а если вы прочли пост, и он ничем не отозвался, или отозвался чем-то другим, что может быть полезно - поделитесь, чем, в комментариях!
