для чего нужна ретроспектива
Ретроспективы в проектных командах: что это, зачем нужно и как эффективно провести
Наша команда разрабатывает большое количество обучающих проектов и собственных продуктов. Мы постоянно анализируем и улучшаем процессы разработки, обмениваемся обратной связью друг с другом и внедряем изменения. Поэтому после каждого завершённого проекта мы проводим ретроспективу с командой, а иногда и отдельно с заказчиками.
Ретроспектива — встреча команды после завершения проекта для того, чтобы подвести итоги, поделиться полученным опытом и составить план возможных улучшений на будущее.
Зачем нужны ретроспективы
Мы шли к ответу на этот вопрос какое-то время и сформулировали для себя следующие пункты:
Проведение ретроспектив с модератором
Изначально мы собирались с командой проекта и руководителем отдела разработки и в свободном режиме обсуждали проект, делали выводы и фиксировали важные инсайты для разработки. Но со временем мы обновили формат ретроспектив и вот уже больше года проводим их вместе модератором. Также с марта 2020 в связи с изменением формата работы мы стали проводить ретроспективы онлайн в Skype, GoogleMeets или Zoom.
Модераторы — это сотрудники нашей компании LEVEL с бэкграундом психолога, тренера или преподавателя. Также модератором может стать любой сотрудник, у которого есть желание и интерес развиваться в этой роли.
На данный момент у нас сформировалась команда модераторов, которая улучшает форматы и ищет новые инструменты проведения ретроспектив.
Так, в апреле мы с модераторами находили различные решения для совместной работы в онлайн-формате. Для этого мы изучали интерактивные и виртуальные доски и остановились на Miro, подготовили в нём шаблон доски для проведения ретроспективы.
Сейчас мы пришли к тому, что не хватает единого бланка для заполнения по итогам ретроспектив и решили создать его.
По завершении почти каждого проекта мы проводим ретроспективу. Если проект длительный и объёмный, мы рекомендуем менеджерам проводить дополнительные встречи по окончании его отдельных этапов и подводить мини-итоги.
Также со временем мы пришли к выводу, что проведение ретроспективы в типовых для нас проектах оставляем на усмотрение менеджера. Как правило, в данных случаях в разработке не возникает новых вопросов, всё проходит стандартно по процессам.
Внедрение изменений по итогам ретроспектив
Системное проведение ретроспектив позволило нам накапливать данные о разработке проектов. Чтобы ценная информация после ретроспектив не терялась, менеджер проекта заполняет форму по итогам встречи, куда заносит все выводы команды. Далее с этими данными работают руководители отделов и менеджер внутренних проектов.
Например, на этапе сборки мы постоянно сталкивались с одними и теми же вопросами по реализации упражнений в электронном курсе, интерактивов или вёрстки. Поэтому, после анализа одного из проектов мы усовершенствовали технические пояснения в сценарии курса и стали прописывать подробную работу механик для сборщика.
Также мы включили в процесс разработки обязательную проверку методолога и дизайнера на этапе сборки, так как выявили, что этого не хватает.
Выводы и анализ ретроспектив помогают не только найти пробелы в разработке, но и подтвердить, что всё идет хорошо. Например, во время обсуждения одного из проектов мы сделали вывод, что подключение разработчика на этапе написания сценария электронного курса — это успешный опыт, который позволяет уменьшать технические риски реализации проекта.
Процесс ретроспектив в LEVEL отлажен, информация и выводы дают поле для инсайтов и изменений, а это значит, с большей вероятностью мы не допустим пробелы в разработке, сделаем выводы и завтра точно станем лучше, чем были вчера.
Ретроспектива: как и зачем ее проводить?
Проведение ретроспектив – это активность, которую каждая agile-команда проводит для того, чтобы решать свои проблемы. Что такое ретроспектива? Это регулярная встреча, на которой команда обсуждает свой рабочий процесс и что-то в нем меняет.
Зачем нужна ретроспектива?
Это не праздный вопрос, его часто задают начальники, когда им предлагают провести ретроспективу. Они спрашивают: «Зачем? Мы можем сами все решить». Почему же нельзя сделать так, чтобы какой-то начальник или эксперт пришел, посмотрел и сказал, что команде надо делать, а что в рабочем процессе стоит изменить?
Основных причин две. Во-первых, если мы приходим к команде с готовыми решениями, возникает феномен, который называется «not invented here». Даже если члены команды понимают, что это правильное решение и его нужно выполнять, у них нет чувства собственности по отношению к нему. Такие решения, не «выстраданные» самим коллективом, а «навязанные» или предложенные сверху, имеют меньше шансов на реализацию.
Во-вторых, сейчас разработка ПО – настолько сложная и запутанная вещь, что вряд ли найдется специалист, который сможет, не зная контекста, расписать, как на самом деле должны работать процессы в конкретной команде при решении определенной задачи. Чтобы это выяснить, надо что-то пробовать, проводить эксперименты, смотреть, к чему приводят те или иные решения. Только попробовав, можно понять, хороша или не очень та или иная практика в контексте данной команды.
Тем не менее, существуют такие вещи как good practice или best practice. Это практики, которые многие используют и которые многим помогают. Возьмем, например, code review: хорошая это практика или плохая? Одним командам она помогает. Другие пытаются ее использовать, и ничего хорошего из этого не выходит. Так происходит потому, что эта конкретная практика, не хороша и не плоха как таковая: ее можно оценить только в контексте конкретной команды и ситуации.
Хотя бы поэтому невозможно сказать заранее, даст она какое-то преимущество или нет. Сode review – это один пример. На самом деле этот эффект характерен для любой практики – никогда нельзя знать заранее, насколько она будет эффективна в той или иной ситуации.
Цели и результаты
В основе ретроспективы лежит концепция цикла Деминга, PDCA (англ. Plan-Do-Check-Act). Цель ретроспективы – к ее окончанию получить план изменений. Но важно понимать, что это не план окончательных изменений в процессе – это план эксперимента на ближайший период. Мы что-то пробуем, а потом смотрим, что из этого вышло, и на основании этого принимаем решение.
Цикл Деминга: Plan – запланируй, Do – выполни, Check – посмотри, что получилось, Act – прими какие-то дальнейшие решения, реши, что дальше делать. Ретроспектива должна проходить именно по этому циклу. Собственно, сама ретроспектива – это стадия Plan.
Ретроспектива, как и любая командная встреча, должна иметь какую-то цель. Цель ретроспективы – получить план процессного эксперимента. Однако многие команды этого не понимают. Например, на ретроспективе команды порой пытаются придумать какие-то глобальные решения своей проблемы, и упираются в то, что у них не получается этого сделать. Они застревают и в итоге вообще ничего не делают. Если команда с такой проблемой сталкивается, то надо ей объяснить, что двигаться надо маленькими шагами, пробуя разные вещи и проверяя, что из этого выходит.
Если команда просто считает, что ретроспектива – это встреча для того, чтобы обсудить свой рабочий процесс и как-то его улучшить, то, как правило, все сводится к тому, что люди приходят, о чем-то разговаривают, выливают свою боль, облегчают душу – в итоге это ни к чему это не приводит. Так происходит потому, что цель не достигнута, план не получен.
Задача ведущего – привести команду в процессе ретроспективы к конкретному плану. План – это одно из двух: либо действия, либо новая договоренность. Все, к чему ретроспектива сводится – это список из действий, которые надо совершить, и договоренностей, которых отныне нужно придерживаться.
Что такое действия? Это конкретные задачи с известными исполнителями. Причем если выполнить действие должен тот, кого нет сейчас в комнате, из присутствующих выбирается человек, который берет на себя ответственность объяснить отсутствующему, что и как нужно сделать, а также проконтролировать результат. В итоге за каждое действие отвечает кто-то из присутствующих на ретроспективе.
Какие бывают ретроспективы?
Вообще ретроспективы разумно подразделять на несколько типов:
Ретроспектива по качеству обычно сводится к тому, что на ней обсуждаются либо недавно произошедшие инциденты, либо дефекты. Ретроспективу посвящают тому, что обсуждают эти дефекты и анализируют, почему они возникли, то есть строят диаграмму глубинных причин дефектов. Так или иначе, в этом случае работу ведут с конкретными проблемами с качеством.
Есть ретроспективы, на которых работа ведется с проблемами, возникающими у заказчика или у владельца продукта. Это третий тип ретроспективы. Четвертый тип – когда есть конкретная специфическая проблема, и ретроспектива посвящается ее решению.
В чем проблема?
Какие в процессе ретроспективы могут возникнуть дисфункции, и как с ними бороться? Вот одна из дисфункций: команда считает, что у нее нет проблем, ее рабочий процесс достаточно хорош, и не видит смысла в его улучшении. Как правило, это не так. Но команде этого просто так не объяснить.
Для того, чтобы сдвинуть коллектив с этой позиции, полезно пригласить на ретроспективу кого-то из стейкхолдеров – заказчика или пользователей, которые знают, что с командой не все в порядке (заказчики вообще очень редко полностью удовлетворены работой команды). Они могут быть удовлетворены до определенной степени, но, как правило, у них все равно есть какие-то мысли на тему того, «что команда могла бы сделать лучше». Если такой заказчик приходит на ретроспективу и рассказывает это команде, ей уже некуда отступать, она начинает обсуждать направления для дальнейшего роста.
Еще одна дисфункция – когда на ретроспективе говорит в основном кто-то один или 2-3 человека, а все остальные сидят и молчат. На самом деле этим людям есть, что сказать. Просто, если все внимание на себя забирает, к примеру, лидер команды, он начинает доминировать, а остальные просто слушают.
Почему это плохо? Если каждый будет открыто высказывать свои мысли, то вероятность найти лучшие решения намного возрастет. Когда мы участвуем в групповой дискуссии, мы друг друга подстегиваем. Это и помогает придумать лучшее решение.
Часто справиться с этой проблемой помогает ведущий (фасилитатор) ретроспективы, который будет следить за тем, чтобы каждый из присутствующих высказал свою точку зрения. Иногда для того, чтобы участники ретроспективы более свободно выражали свое мнение, полезно давать им возможность не высказывать свои соображения вслух, а записывать их на клейких листках (их обычно прикрепляют на стену или специальную доску, причем это могут сделать как сами участники, так и – для пущей «анонимности» – фасилитатор).
Формат ретроспективы: наши предложения
В литературе описываются различные форматы проведения ретроспективы – от простых до крайне специфических. В одном из материалов в нашем блоге мы предложили свой вариант: его отличительные особенности – простота и эффективность. В основном именно это и требуется от подобных мероприятий.
Вместо того, чтобы выставлять жесткий тайминг и последовательность действий, мы предлагаем просто расчертить доску на 4 основные области и заполнять ее по ходу обсуждения:
Как правило, новые идеи рождаются в процессе обсуждения минусов прошлой итерации, однако ими не ограничиваются: такой формат ретроспективы не препятствует свободному обсуждению. При этом фасилитатор или скрам-мастер должен следить за тем, чтобы обсуждения не перерастали в поиск виноватых: для достижения цели важно не столько то, «кто виноват», сколько то, «что с этим делать дальше». Споры по поводу той или иной идеи на данном этапе тоже бесполезны: в план все равно попадут только те идеи, с которыми согласны все участники ретроспективы.
После обсуждения плюсов, минусов и идей команда переходит к составлению плана, куда попадают не просто результаты обсуждения, а (как уже было отмечено) конкретные действия («Выполнить…», «Обсудить…», «Сформировать…») или правила («Задачу Х выполнять с использованием подхода Y»). Не стоит при этом пытаться выработать пути решения всех возможных проблем команды – для эффективной работы на следующей итерации достаточно плана из 3-6 пунктов. Слишком объемный план может в итоге оказаться невыполним и только демотивирует команду.
Стоит еще раз отметить, что форматы проведения ретроспективы могут быть различными. Важно одно: ретроспективы – это не единичное мероприятие, они проводятся регулярно, и по результатам каждого такого собрания выполняется основная цель – создается план на ближайшую итерацию. Если отнестись к этой процедуре не «формально», понимать ее цели и задачи, заранее знать наиболее типичные проблемы, возникающие в ходе ретроспективы, можно создать благоприятные условия развития настоящей самоорганизующейся команды.
Большая ретроспектива на несколько команд. Зачем она нужна, и как ее провести с пользой
Часть 1. Вводная зачемная
Привет. Я Лена, скрам-мастер в «Ренессанс страхование». Мы с коллегами в командах реализуем классные фичи в страховании и рады, когда наш функционал действительно получается востребован. Стараемся еще, конечно, чтобы получался он не только качественно, но и быстро, как это обычно требуется в современном мире.
Однако в прошлом году мы столкнулись с разработкой довольно сложного продукта по автокаско частных лиц, в реализацию которого оказались вовлечены 4 фиче-команды, множество разных групп пользователей внутри компании и внешние пользователи.
Не все шло гладко, и не все шло быстро, ведь кроме обычных задач и сложностей в работе над продуктами, карантин также внес свои коррективы.
По итогам длительной (практически годовой) работы и после запуска полноценного продукта мы решили провести большое ретро на всех участников, о чем и будет данная статья.
Может возникнуть вопрос, зачем мы в целом решили провести общее ретро. Цели у этой встречи были такие:
собрать все произошедшие за год события на одном борде;
получить мнения всех участников процесса: и ребят из фиче-команд, и заказчиков, и пользователей продукта;
синхронизировать общее понимание участников по тому, какие проблемы у нас возникали, а какие моменты позволяли нам добиться лучшего результата;
определить те проблемы / достижения, которые важны для всех команд в целом;
решить, как мы будем действовать в следующий раз, и что предпримем для избежания выявленных проблем в дальнейшем.
Если у вас несколько команд, работающих с одним продуктом, а вы еще не проводите общие ретро, но хотите провести – в этой статье приведены инструменты, которыми для такого мероприятия пользовались мы.
Отмечу еще, что в каждой команде у нас проходят ретро по итогам спринта. Однако для участников очень полезным оказалось именно большое ретро на все команды, занимавшиеся продуктом. Оно позволило подсветить моменты кросс-командного взаимодействия, проблемы взаимодействия с заказчиком / пользователями, в том числе озвученные ими, и дало возможность выбрать именно те карточки для последующей проработки, которые волнуют большинство ребят, работающих над/с продуктом.
Часть 2. Как это было
После определения, зачем нам нужно ретро в таком большом составе, и прохождения стадий от отрицания до принятия (а точнее, от формирования списка участников до четкого планирования) мы заранее забронировали время в календаре уже со сформированной повесткой и рассказали на ежедневных встречах о том, что планируем.
План на ретроспективу у нас был такой:
Определение хороших сторон работы над продуктом и моментов, которые нужно улучшать / менять
Поиск корневых причин выбранных карточек методом «5 почему»
Определение идей по работе с выявленными причинами
Сбор обратной связи по итогам ретро
При этом все указанные этапы мы проводили удаленно через 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. Сбор обратной связи по итогам ретро
ПЕРЕРЫВЫ
Часть 3. Результативное «что дальше-то»
Вот мы собрали список проблем, определили их причины, накидали идеи по улучшению процесса, а что дальше?
Или поняли, что демо стоит проводить для конечных пользователей в том числе, а не только для заказчиков и стейкхолдеров. Притом демо по продукту, всеми командами, получая полноценную обратную связь от всех ролей, участвующих в процессе, и эту обратную связь используя в будущем.
Есть поинты, с которыми сложно было работать на встрече, типа инфраструктурных проблем или проблем, вызванных интеграциями со сторонними системами. Эти вопросы запарковали и обсудили отдельно.
Кроме трека прогресса по идеям с ретро в экшн-поинтах у нас проведение кросс-командных ретро чаще, чем раз в год. Коллеги позитивно отозвались именно о таком формате ретроспективы. Это одна из причин, почему таким форматом было решено поделиться здесь.
Не затягивать с ретро на несколько команд.
Делать такого формата ретро долгими, на весь день.
При делении на группы не определять всех специалистов одной роли в одну группу.
Давать больше времени на поиск причин проблем и на генерацию идей.
Звать всех, кто может быть ответственными за реализацию идей, на такие встречи.
Это несколько поинтов для улучшения на будущее и нам в том числе.
Ретроспектива: проводим быстро и результативно с помощью funretro
Если ваши ретро не приносят результата, а только тратят время и раздражают команду разработки есть два выхода — отказаться от ретро вообще или сделать нормально. Знакомая боль и выбираете второй вариант? Тогда статья для вас
Советы для проведения продуктивной ретроспективы:
Не углубляясь в Scrum/Agile — ретроспективу проводим в конце каждого спринта (так говорит теория) для того чтобы найти боли команды/блокеры в проекте. На практике можно придерживаться более экономичного подхода — проводим, когда чувствуем что нужно/объединяем несколько спринтов в одно ретро (например, ретро раз в 2-3 спринта)
За несколько лет работы в командах разработки я выделил для себя топ-5 болей ретро, которые превращают его из эффективного инструмента в бессмысленную трату времени, демотивирующую команду:
Давайте посмотрим как убрать эти боли и начать жить счастливо. В любом деле выбор правильного инструмента — половина успеха, поэтому начнем с него
Funretro — сервис создан специально для проведения ретро. Плюсы — решает проблему анонимности, есть механизм голосования, много шаблонов ретро и тд. Из минусов — только 3 доски в бесплатной версии.
Попробовав несколько вариантов, остановился на funretro, он решил почти все боли. Инструмент выбран — начинаем подготовку к ретро
Подготовка — половина успеха в любом деле, ретро не исключение.
Настроили доску? Стартуем
Расскажите о цели ретро, проговорите базовые правила — говорить/писать честно, не винить в ошибках людей и тд
Первый раздел ретро обычно вызывает самые большие затруднения. Чем он проще, тем быстрее команда включится в работу. Например, это может быть описание спринта/проекта/настроения одним словом. Вообщем что угодно, но очень коротко. Ограничение времени — 1 минута. Ставьте таймер и не давайте выйти за лимит.
Когда время закончилось/все участники отписались — откройте карточки и зачитайте их. Поступайте так в конце каждого раздела ретро
Не забываем озвучивать хорошее, но без фанатизма, 3-4 минуты должно хватить
Сделали, зачитали, обрадовались и поехали дальше, к главным разделам
То ради чего все собрались — где можно стать лучше. Самый сложный и важный этап. Все любят говорить о хорошем, а вот о том что не получилось или идет плохо — возникают психологические барьеры. На этом этапе важно:
Анонимность, самостоятельная работа и установленные в начале правила успешно решают эти задачи
Наверняка проблем будет больше пяти. Вероятней всего все сразу решать не нужно, нет смысла их обсуждать. Приоритизация важна, поэтому голосуем за самые важные проблемы.
Не забывайте мержить карточки с одинаковыми проблемами (а они точно будут), иначе голоса размажутся. В funtretro для этого есть механизм drag’n’drop тикетов
Что нам нужно для объективного голосования?
Когда все проголосовали — выбираем топ-3(±1) проблем и начинаем заключительный этап
Переходим от самостоятельного заполнения тикетов к обсуждению голосом. Поочередно берем проблемы из топа и начинаем искать решение
Типичная ошибка формулировки решения:
Проблема — заказчик недоволен скоростью работы команды
Решение — давайте работать быстрее!
Это не конкретное действие, а лозунг. Не надо так
Выделите на этот раздел 35-50% процентов всего времени ретро. Он самый важный для достижения результатов и требует повышенного внимания модератора встречи, так как здесь участники общаются голосом, а не самостоятельно заполняют тикеты
Благодарим участников встречи, проговариваем что нужно сделать и примерные даты следующего ретро.
В идеале можно собрать фидбэк о ретро у команды и попробовать провести его еще лучше в следующий раз
Все перечисленное применялось в проектах, связанных с разработкой, однако ретроспектива — это универсальный инструмент, актуальный в любых проектах
Тратьте время ретро с умом и приносите пользу своей команде
PS если статья получит положительный отклик — я подготовлю аналогичный материал про проведение демо спринта