[] Большая ретроспектива на несколько команд. Зачем она нужна, и как ее провести с пользой
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Часть 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. Звать всех, кто может быть ответственными за реализацию идей, на такие встречи.Это несколько поинтов для улучшения на будущее и нам в том числе.Ну а если вы прочли пост, и он ничем не отозвался, или отозвался чем-то другим, что может быть полезно - поделитесь, чем, в комментариях!
===========
Источник:
habr.com
===========
Похожие новости:
- [ERP-системы, Agile] Как мы замиксовали Agile для внедрения новой ERP-платформы
- [Компьютерное железо, История IT, Старое железо, Процессоры] Полная история процессоров Pentium — от А до M
- [Высокая производительность, Управление разработкой, Agile, IT-компании] Как масштабировать разработку при 400 000 RPM и не надорваться
- [Мессенджеры, Oracle, API, Голосовые интерфейсы] Как можно запустить MVP личного кабинета в WhatsApp и получить новый инструмент для проверки гипотез
- [Программирование, Управление проектами] Если у вас нашли SCRUM
- [История IT, Настольные компьютеры] The Centre for Computing History in Cambridge
- [Управление разработкой, Управление проектами, Agile, Конференции] 10 июня, 19.00 — онлайн-митап для скрам-мастеров
- [Управление разработкой, Agile, Управление продуктом, Управление персоналом] SCRUM: Развитие сотрудников и продуктовых команд
- [Управление разработкой, Управление проектами, Agile] PSM I от Scrum.org. Личный опыт получения сертификата
- [Управление разработкой, Управление проектами, Agile, Управление продуктом, Карьера в IT-индустрии] Гайд по сертификациям. Часть 1. Agile
Теги для поиска: #_retrospektiva (ретроспектива), #_retro (ретро), #_scrum, [url=https://torrents-local.xyz/search.php?nm=%23_blog_kompanii_«renessans_strahovanie»&to=0&allw=0&o=1&s=0&f%5B%5D=820&f%5B%5D=959&f%5B%5D=958&f%5B%5D=872&f%5B%5D=967&f%5B%5D=954&f%5B%5D=885&f%5B%5D=882&f%5B%5D=863&f%5B%5D=881&f%5B%5D=860&f%5B%5D=884&f%5B%5D=865&f%5B%5D=873&f%5B%5D=861&f%5B%5D=864&f%5B%5D=883&f%5B%5D=957&f%5B%5D=859&f%5B%5D=966&f%5B%5D=956&f%5B%5D=955]#_blog_kompanii_«renessans_strahovanie» (
Блог компании «Ренессанс страхование»
)[/url]
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 26-Ноя 11:21
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Часть 1. Вводная зачемная.  Привет. Я Лена, скрам-мастер в «Ренессанс страхование». Мы с коллегами в командах реализуем классные фичи в страховании и рады, когда наш функционал действительно получается востребован. Стараемся еще, конечно, чтобы получался он не только качественно, но и быстро, как это обычно требуется в современном мире.Однако в прошлом году мы столкнулись с разработкой довольно сложного продукта по автокаско частных лиц, в реализацию которого оказались вовлечены 4 фиче-команды, множество разных групп пользователей внутри компании и внешние пользователи.Не все шло гладко, и не все шло быстро, ведь кроме обычных задач и сложностей в работе над продуктами, карантин также внес свои коррективы. По итогам длительной (практически годовой) работы и после запуска полноценного продукта мы решили провести большое ретро на всех участников, о чем и будет данная статья.  Может возникнуть вопрос, зачем мы в целом решили провести общее ретро. Цели у этой встречи были такие:
 Сначала ПО озвучивали, какие основные моменты происходили за обсуждаемый квартал, чтобы каждый участник встречи мог для себя сориентироваться по времени. Далее выделялось время на непосредственно написание карточек.Зачитывать карточки и объединять их решили после формирования всех поинтов по всем кварталам. Почему так: в разные периоды времени одна и та же проблема могла проявляться в разных командах. Например, ушел ключевой специалист. Или прилетела срочная задача, связанная с надзорными органами. Такие истории объединяли, чтобы оценивать только 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. Звать всех, кто может быть ответственными за реализацию идей, на такие встречи.Это несколько поинтов для улучшения на будущее и нам в том числе.Ну а если вы прочли пост, и он ничем не отозвался, или отозвался чем-то другим, что может быть полезно - поделитесь, чем, в комментариях! =========== Источник: habr.com =========== Похожие новости:
Блог компании «Ренессанс страхование» )[/url] |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 26-Ноя 11:21
Часовой пояс: UTC + 5