Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
По идеологии Agile и Scrum ретроспектива проводится каждые две недели или месяц, а на практике не проходит вообще или промежутки меняются. Это нормально. Мы считаем, важно подстраивать инструменты под себя: кому-то помогают матерные мемы, кому-то удобное голосование в Miro, а иногда отмена ретро. Рассказываем, как с этим у нас.
У нас в каждой команде ретро проходит по-разному, поэтому мы опросили трех менеджеров и одного аналитика. Дальше только личный опыт.
Алина Шарафеева, Project Manager
На моем проекте в команде 15 технократов и несколько сотрудников со стороны заказчика. В начале каждой ретроспективы мы обсуждаем положительные моменты, чтобы забраться на волну позитива, а затем уже отмечаем проблемы, которые возникли за прошедший период. Третий этап мероприятия — придумать решения этих вопросов.
Бывает, команда накидывает 10-15 проблем, но мы ограничены по таймингу: встреча не должна растягиваться на долгое время. Тогда проводится промежуточное голосование: каждая проблема фиксируется на доске, и команда голосует за самые острые вопросы, которые аффектят наибольшее количество участников.
Ретроспективы на нашем проекте — явление редкое. У нас в разработке сложный продукт, какую-то функциональность мы можем создавать больше двух недель. Часто на спринт мы ставим задачу проанализировать что-то, во втором спринте мы готовим дизайн, в третьем — разрабатываем архитектуру, и только в четвертом можно что-то пощупать, посмотреть, как это работает. Поэтому ретроспективу мы могли не использовать на протяжении полугода или года.
Я применяла ретро по годовым итогам. В 2020-м году мы проводили мероприятие в офлайн-формате, несмотря на удаленный формат работы: на него пришли наши сотрудники и заказчики — аналитики и владелец продукта.
Мы получили взгляд с обеих сторон: заказчик ведь тоже видит какие-то успехи, которые мы недооценили — для нас они кажутся нормой. И наоборот, они могут подсветить какие-то проблемы, которые для нас могут быть привычными вещами, а заказчику это будет неприятно.
Мы задали установку, что идем на ретроспективу не с целью выставить друг друга виноватыми, а чтобы найти решения. Важно по фактам расписать, что нравится и что не нравится. Хотя все стикеры вкладывались анонимно, и можно было написать все, что угодно, команда понимала, что это не место для бездумных поступков.
Бывают такие ситуации, когда у кого-то что-то не сработало из-за действий другого члена команды — об этом можно открыто сказать. Другое дело, как заявлять об этом: не оскорблять, а обозначить проблему и попросить проверить, исправить. Никто ни на кого не наезжает, мы все дружелюбные.
На мой взгляд, ретроспективы дают результат, когда они происходят по запросу: у команды что-то накипело, или мы столкнулись с нерешаемой проблемой, нужен командный штурм. Причем если проводить ее условно раз в год, то ежесекундные боли и обиды проходят, и на встрече обсуждаются явные проблемы, которые никуда не деваются.
План ретро Алины:
Обсудить положительные моменты
Отметить проблемы, произошедшие за период. Если проблем много, проголосовать и расставить приоритеты
Продумать решения
Не затягивать ретро надолго
Собираться, когда это действительно важно. Иногда на большом промежутке времени проблемы сами теряют остроту
Энгель Зарипов, Project Lead
Мы берем кусочек работы на две недели, определяем, каковы наши цели и что нужно сделать. По итогам спринта собираемся всей командой и проводим ретроспективу. Обычно она начинается с какого-нибудь лайт-тока – это не основной паттерн, но так сотрудники немного расслабляются, осваиваются и вливаются в обстановку. Спросите, кто с каким фруктом или автомобилем себя ассоциирует.
Дальше – основные вопросы ретроспективы: что в рамках итераций было сделано хорошо, что хотелось бы улучшить и что мы берем в работу. Так можно понять, что изменилось с прошлой встречи, а также выявить проблемы в рамках итераций. После того как мы понимаем, что можно улучшить, нам нужно определить, что у команды болит больше всего. Всему внимание уделить не получится, поэтому проводится голосование на самые острые проблемы.
Отмечу: мы говорим не «что было плохо?», а «что можно улучшить?». По сути, это одно и то же, но у первого вопроса негативный окрас, а у второго – позитивный.
В классическом понимании Agile заказчики не присутствуют, но иногда, когда у них есть проблемы с командой, мы собираем некое ретро. Бывают проекты, в которых часть команды – со стороны заказчика, часть – наши коллеги. Но такой формат считается командой проекта, которая может собирать регулярные ретроспективы.
Стереотипные айтишники — зажатые в себе интроверты, им тяжело выражать свои мысли, выслушивать критику. Среди команды могут быть такие люди, поэтому мы это учитываем: инструменты позволяют провести критику анонимно.
Неважно, кто написал проблему: если она актуальна для других, то многие за нее проголосуют. Но если проблема из ряда вон выходящая — например, человек не смог что-то сделать из-за другого члена команды, скорее всего, PM обратит на это внимание даже при отсутствии голосов. Если по чьей-то вине произошла серьезная ошибка, то ее нужно проговаривать без обвинений, отмечая плюсы и минусы работы сотрудника.
Мы всегда смотрим на прошлую ретроспективу. Когда работа над ошибками проходит успешно, то прошлые ошибки попадают в столбец «что было хорошо». Команду это мотивирует: видно, какие они молодцы, сколько всего они сделали за спринт.
Завершающий этап на ретро — назначить ответственных за каждое решение проблемы: для этого нужно выяснить, как и почему она возникла. Бывают сложные задачи, при которых мы используем метод пяти рычагов: спрашиваем пять раз, почему это произошло. Таким образом можно выстроить последовательность причин.
План ретро от Энгеля:
Переживите две недели спринта и соберитесь на ретро
Начните с лайт-тока — так все привыкнут и втянутся
Переходите к основным вопросам ретро: Что в рамках итераций было сделано хорошо? Что хотелось бы улучшить? Что берем в работу?
Определите самую главную и актуальную боль команды — можно голосовать. Если необходимо собирайте критику анонимно
Не забывайте возвращаться к прошлым ретро и фиксировать прогресс и решенные проблемы
Назначьте ответственных за решение каждой проблемы на следующий спринт
Алексей Аксянов, Data analyst Lead
Раньше мы использовали дощечку в EasyRetro или Trello. Мы заполняли три колонки, и все — в какой-то степени это работало, но процесс был рутинный и скучный. Наш менеджер почитал про лучшие практики гибких методологий и попытался их применять в работе. Мы переехали в другой инструмент — начали проводить ретроспективы в Miro: создали большую отдельную доску, на которой стало гораздо удобнее работать. У нас появились специальные стикеры для хороших и плохих моментов, приятный визуал, таймер.
Вообще желательно, чтобы на ретроспективе был некий фасилитатор или модератор, потому что иногда можно зайти далеко в обсуждениях, и времени не останется ни на что. Но работает и встроенный таймер: мы начали укладываться в полтора часа и успевать обсуждать критично важные вещи.
Также в Miro удобный режим голосования — мы голосовали на стикерах и сразу видели, что вызывает наибольший отклик. Еще заметки можно группировать: каждый человек описывает проблему разными словами — одинаковые по сути формулировки группируются вместе.
Из практик у нас внедрили очень хорошую вещь: перед каждой ретроспективой команда расслаблялась, переходила на позитивную волну. В начале мы прикрепляли стикер, который характеризует эмоциональное состояние на проекте. Участники команды иногда крепили самый треш, все вместе смеялись.
Ретроспективы на нашем проекте проходят не так часто, раз в три месяца. В конце спринта мы проводим мини-ретро, чтобы получить обратную связь.
Подсвечивать недостатки нужно максимально корректно, чтобы никто не ушел со встречи обиженным, не накалялась обстановка. Сейчас общемировая тенденция — не создавать токсичную атмосферу вокруг себя. Сказать, что «Петя – дурак, и он провалил задачу», будет неправильным. Надо сказать, что у нас на проекте был определенный этап, где задачу выполнял Петя, и нужно подумать, что привело к такому результату. Может, это и не его вина вовсе, а у него не было доступа к чему-то, или его подвела смежная команда.
Со стороны мы даем просто поверхностную оценку, а в самой проблеме нужно максимально аккуратно и глубоко разбираться. Мы не токсичные и максимально топим за наших сотрудников.
Если встречи проводятся только ради встреч, то они не эффективны. На ретроспективе мы не просто болтаем, после встречи команда уходит со списком проблем, за которыми закреплены ответственные.
Но есть нюанс: внутри команд наших проектов, например, этот инструмент работает очень хорошо. Однако изредка были прецеденты, что есть некая бюрократия со стороны заказчика: мы заявляем, что у нас нет доступа к чему-то, но с этим ничего не решается. Ретроспектива будет работать только в том случае, если все участники заинтересованы в результате: они должны приходить не с настроением посидеть на очередном совещании, а докопаться до сути проблемы и решить ее.
Рецепт ретро от Леши:
Успешное ретро — когда все заинтересованы
Организуйте большую доску в Miro — стикеры, таймер, голосование
Назначьте фасилитатора или модератора, чтобы сохранить конструктивность
Перед стартом поделитесь настроением. Мы делаем это стикерами
Максимально корректно подсветите недостатки, чтобы никто не ушел обиженным
Не проводите встречу только ради встречи. Команда должна уйти со списком проблем, за которыми закреплены ответственные.
Назначьте ответственных за решение каждой проблемы на следующий спринт
Ксения Хандожко, Project Manager
У меня почти всегда один сценарий проведения ретро: сначала нужно, чтобы команда могла обсуждать проблемы свободно и понимала, что их никто ругать не будет. Для этого мы накидываем какие-то картинки, мемы, гифки — все, что ассоциируется у них с этапом проекта. Я проговариваю, что в мемах можно использовать матерные слова, поэтому ребята могут действительно проявить свои эмоции. У нас на это уходит пять минут, потом команда объясняет, что значит выбранная картинка.
Затем мы расписываем стикеры – что нам понравилось. Обычно ребята хвалят друг друга за работу: хорошая аналитика, тестирование, понятные задачи. Они проявляют друг другу благодарность. Эти стикеры мы не обсуждаем и переходим к следующему этапу ретро – к возникшим проблемам. Заметки с острыми вопросами мы зачитываем, каждый подробно объясняет, что ему не понравилось.
Следующий этап — голосование за проблемы, которые мы будем прорабатывать. Все участники команды пишут по одному стикеру с предложением, что нужно сделать, чтобы задача решилась. Мы объединяем два-три мероприятия, назначаем ответственного и срок выполнения.
Обычно мы реализуем модуль из двух – трех спринтов, в течение которого реализуем большую функциональность. По итогам модуля мы уже проводим ретроспективу, раз в месяц–полтора. Не всегда бывает время, чтобы сфокусироваться на ретро, которое может занять два–три часа: это очень большой объем времени, в течение которого можно реализовать функциональность.
Я считаю, не всегда есть смысл проводить ретро в каждый спринт, потому что не всегда можно успеть устранить повторяющиеся проблемы. Если команда говорит, что не видит эффективности в проведении ретро здесь и сейчас, то лучше пропустить этот этап и работать дальше. Иногда менеджер видит, что в команде есть какая-то дискоммуникация, нужно обсудить ситуацию, и тогда решает провести ретроспективу. Как правило, после таких встреч команда уходит более-менее вдохновленная, они понимают, что их услышали, дали им высказаться.
Мы с командой в начале ретро проговариваем, что мы приложили все усилия на проекте, и сейчас устанавливаем возможность улучшить наши процессы. Все понимают, что если кто-то один не сделал одну задачу, то он выполнял другие. Как правило, источник проблемы — не сам человек, который не выполняет свои должностные обязанности. У него были более приоритетные задачи, или он застрял на каких-то подводных камнях, которые мы изначально не смогли спрогнозировать.
Ретроспектива — это очень важная вещь для IT-компаний, особенно для нашей, потому что у нас все люди ориентированы на то, чтобы давать и получать обратную связь. Начиная со стажировки, сотрудники учатся проговаривать все вслух и обсуждать. Это положительно влияет на процесс, задачи, работу.
Команда Технократии отмечает, что ретроспектива – нужный инструмент, но его нужно применять с учетом специфики проекта, адаптировать практики под себя. В своей компании вы можете обратиться к готовой классической инструкции, или же присоединить элементы нашего опыта. Мы будем рады, если у вас получится успешный результат, о котором вы можете рассказать.
Ретро от Ксении
Этап 0. Если команда говорит, что не видит эффективности в проведении ретро здесь и сейчас, то лучше пропустить этот этап и работать дальше
Если ретро нужно:
Попросите команду накидать мемов, связанных с прошедшим этапом. Эмоций иногда много, поэтому мат на этом этапе разрешен.
Наклейте стикеры с тем, что понравилось. Здесь мы чаще благодарим коллег: хорошая аналитика, тестирование, понятные задачи. Эти стикеры не обсуждаются.
Проголосуйте за самые актуальные проблемы.
Наклейте стикеры с предложениями по решению — сгруппируйте
Назначьте ответственных и определите сроки выполнения
Ретроспектива — нужный инструмент, но важно применять его с учетом специфики проекта, адаптировать практики под себя. В своей компании вы можете обратиться к готовой классической инструкции, или же присоединить элементы нашего опыта. Мы будем рады, если у вас получится успешный результат, о котором вы можете рассказать.
Также подписывайтесь на наш телеграм-канал «Голос Технократии». Каждое утро мы публикуем новостной дайджест из мира ИТ, а по вечерам делимся интересными и полезными мастридами.
