Русский
Русский
English
Статистика
Реклама

Ретроспектива проекта

Из песочницы Ретроспектива проекта, на которую команде захочется приходить

03.08.2020 18:13:27 | Автор: admin
Как часто вы скучали на ретроспективе проекта? Как часто вы злились, что тратите на эту встречу целый час своего времени, пока рядом грустно догорает очередная задача? Слушали ли вас на ретро, или каждый ждал своей очереди, чтобы сказать пару формальностей и вернуться к работе? Мне однажды это страшно надоело. В этой статья я буду говорить о том, как с помощью простых правил мне удалось сделать ретро самой теплой встречей команды, не считая корпоратива.



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

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

  • Завершенный проект или большое количество спринтов по проекту в достаточно долгосрочный период. Например, за пару месяцев. Если проект большой, существует выделенная под проект команда и работа над проектом ведется активно, можно проводить ретро раз в месяц. Чаще не стоит.
  • Команда. Желательно, устоявшаяся и внутренняя. Проводить ретроспективу с аутсорсом или в ситуации, когда у вас ресурсы текут сильнее, чем вода из крана бессмысленно и беспощадно.
  • Обратная связь от команды. Будет отлично, если у команды будет возможность подготовиться к ретро. Будет идеально, если у команды будет выделено на это отдельное время в расписании.

В каком формате лучше всего собирать обратную связь


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

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

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

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

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

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

Не пытайтесь решить на ретро все проблемы скопом, это невозможно. Постарайтесь на каждой ретро соблюдать правило:

Три проблемы три решения


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

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

А теперь я хочу сделать вашу жизнь немного проще. Для тех, кто еще ни разу не проводил ретро, ниже есть пошаговая инструкция, как начать такое благое дело>



Шаг 1
Определяем, нужна ли нам ретро. Выделяем на ретро два часа времени. Желательно провести ретро через день после релиза, когда хотфиксы уже накачены, команду отпустило и еще не накрыло новыми задачами с головой.

Шаг 2
Создаем таблицу.

Шаг 3
Собираем команду на пятиминутный стендап. Тезисно рассказываем, что это за зверь такой эта ваша ретро, показываем таблицу.

Шаг 4, который важно не игнорировать
Выделяем каждому члену команды по 30-40 минут из расписания на заполнение таблицы. Пусть они знают, что у них есть на это время. Пусть они смогут спокойно ее заполнить.

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

Шаг 6
Предложите коллегам приходить на ретро с кофе/чаем, задайте традицию сладости на ретро к чаю самостоятельно. Начните с озвучивания негативных и позитивных эмоций. Снимите негатив с команды, посмейтесь и поругайтесь все вместе. Эту часть часто пропускают, так как она малопродуктивна с точки зрения производства. Но для вас и вашей команды она важна. Если команда написала только негатив, предложите свои плюсы, послушайте отклик.

Важное правило ретро:

Не команда слушает вас. Вы слушаете команду.

Шаг 7
После переходите к озвучиванию проблем. Следите, чтобы на этом этапе команда уже вернулась в рабочее состояние и была готова к решению трудностей. Когда вы обсудили все трудности, есть наброски решений или уже сложившийся план решений, зафиксируйте их в таблице.

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

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

Шаг 10
Создайте таски для решения выделенных вами проблем и назначьте ответственных. Убедитесь, что у ответственных есть на это время.

Шаг 11
Будьте последовательны и ритмичны. Раз в месяц (или с иной периодичностью) у вас ретро. Все решения, которые выделены на ретро априори или внедряются, или выносятся на следующее обсуждение, как провалившееся решение, для поиска нового.

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

Сделайте ретро хорошей традицией. Вам окупится.
Подробнее..

Из песочницы Ретроспективы в проектных командах что это, зачем нужно и как эффективно провести

17.11.2020 12:21:43 | Автор: admin
Наша команда разрабатывает большое количество обучающих проектов и собственных продуктов. Мы постоянно анализируем и улучшаем процессы разработки, обмениваемся обратной связью друг с другом и внедряем изменения. Поэтому после каждого завершённого проекта мы проводим ретроспективу с командой, а иногда и отдельно с заказчиками.

image


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

Зачем нужны ретроспективы


Мы шли к ответу на этот вопрос какое-то время и сформулировали для себя следующие пункты:

  1. Закрыть проект эмоционально и перейти к новому. Это важный психологический момент, так как сотрудники параллельно работают над другими проектами. Поэтому желательно не затягивать с проведением ретроспективы, после которой двигаться дальше будет легче.
  2. Увидеть процесс со стороны и понять, что нужно изменить. Если после нескольких рефлексий становится заметным пробел в разработке, то принимаем решение об изменении в процессах или думаем, как внести в них корректировки.
  3. Ещё раз убедиться, что команда делает всё верно. Важно не только искать точки улучшений, но и обсуждать с командой, что процессы разработки идут хорошо и мы продолжаем делать так же в новых проектах.

Проведение ретроспектив с модератором


Изначально мы собирались с командой проекта и руководителем отдела разработки и в свободном режиме обсуждали проект, делали выводы и фиксировали важные инсайты для разработки. Но со временем мы обновили формат ретроспектив и вот уже больше года проводим их вместе модератором. Также с марта 2020 в связи с изменением формата работы мы стали проводить ретроспективы онлайн в Skype, GoogleMeets или Zoom.

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

Что модератор делает на встрече?

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

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

На данный момент у нас сформировалась команда модераторов, которая улучшает форматы и ищет новые инструменты проведения ретроспектив.

Так, в апреле мы с модераторами находили различные решения для совместной работы в онлайн-формате. Для этого мы изучали интерактивные и виртуальные доски и остановились на Miro, подготовили в нём шаблон доски для проведения ретроспективы.

image

image

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

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

Также со временем мы пришли к выводу, что проведение ретроспективы в типовых для нас проектах оставляем на усмотрение менеджера. Как правило, в данных случаях в разработке не возникает новых вопросов, всё проходит стандартно по процессам.

Внедрение изменений по итогам ретроспектив


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

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

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

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

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

Выводы


  1. Если ещё не пробовали проведение встреч после проектов рекомендуем провести. Встретиться с командой, обсудить проект, полученный опыт, поблагодарить друг друга за успехи, но и обсудить неудачи, вопросы, чтобы спланировать изменения.
  2. Классно, если встречу проведёт модератор человек, который не был включён в проект и который обладает компетенциями коуча или фасилитатора. Модератор структурирует беседу, зафиксирует важные выводы и назначит ответственных, чтобы идеи и решения не потерялись.
  3. Если вы проводите ретроспективы постоянно, подумайте о системной работе с накопившимися выводами. Регулярная работа с выводами может привести к вдохновляющим инсайтам.
Подробнее..

Проводим ретроспективы для распределенных команд (и как Trello в этом помогает)

19.04.2021 10:09:21 | Автор: admin

В последнее время я достаточно часто использую Trello, и, должен признаться, выглядит пока Трелло как наилучший инструмент для Ретроспектив и Фидбека по Демо. Так что в этом после попробуем пройтись по теме того, как Trello соотносится с другими аналогичными для этих задач инструментами.

Почему Trello

Я пользовался большим количеством инструментов, из которых можно выделить основные: Miro - как интерактивный флипчарт, с которым может взаимодействовать вся командa; Google Docs с секциями помапанными на стадии ретроспектив; Confluence (так как все мои проекты пронзены Atlassian-стеком); а также, порой, Jira (вау, это была достаточно плохая идея)!

Я думаю что все пытались нащупать тот самый инструмент, который можно применить фактически в любой области!

И вот я бы выделил основными критериями для проведения Ретро и собирания фидбека о Демо в подобных инструментах:

1. Насколько хорошо оно работает на уровне объектов (во время обсуждений). -> в идеале тут хотелось бы видеть карточки (все таки мы в физическом мире работаем со стикерами) :)

2. Быстрая и эффективная работа с карточками / объектами

3. Подсветка / теги для карточек / объектив (чтоб все могли), не важно как (цвет, тег, еще какая-то штука позволяющая дифференцировать карточки)

4. Перетасовка / изменение порядка карточек / объектов / айтемов

5. Как можно меньшее время, затраченное на следующую последовательность действий: создание секции (списка) -> добавление в него объектов / карточек -> тегирование / подсветка айтемов (членами команды) -> добавление комментария к айтему.

Miro

Я безумно люблю Miro, и постоянно использую его для воркшопов. Но. использовать в ретроспективе и без подготовки этот сервис не настолько просто, насколько хотелось бы (сам сервис функционала предоставляет ого-го, однако ж формат ретроспектив сильно завязан на карточках, работа с которыми в Miro - не самая сильная его сторона). В самой основе, скелете, так сказать, не заложена поддержка карточек как дефолтного варианта, поэтому эту структуру приходится содержать самостоятельно: создавать колоночку, двигать айтемы аккуратно, чтоб оно все относительно ровно стояло. Это тратит время, это не так просто и быстро работает в браузере. Ну и тегирование - тоже не сказать что сильная сторона Miro.

Google Docs

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

В этом плане, знаете, даже google sheets казалось бы удобно использовать, как инструмент более подходящий для нашей аналогии двухмерной-классической-ретро-доски (ну как двухмерной, скорее именно с точки зрения того, что у нас есть некие секции с контентом для хорошо/не оч/ улучшить). Но и тут нас поджидает неудобство - drag-n-drop для айтемов, и их линкование друг с другом работает ужасно. Я еще пробовал в свое время google slides, с подходом слайд-для-секции (например перечислить все те великие свершения, в которые мы шмогли с прошлого спринта) - но в итоге менеджить это было сложно, ввиду тяжеловесности решения, ну и на одном таком канвасе могло одновременно ну человека два работать может, не больше. Ну и подсвечивать айтемы там конечно можно, но оно для того не очень приспособлено.

Confluence

Ну вот же confluence, там же целый шаблон для ретро есть! Скажете вы. И будете правы!

Но хорош этот шаблон для документирования/стенографирования, для журнала принятия решений. А нам это в ретро не нужно! Нам нужна живая дискуссия где народ таскает карточки по колонкам, клонирует, обсуждает, помечает!

Более того, Atlassian обычно старается сделать confluence неким легковестным решением, если вас кормят всем их стеком. Но по простоте коллаборации там до gDocs как до луны. Возвращаясь к нашему подходу (ищем блочную структуру для карточек) - confluence неудобен. А еще - нестабилен: с потерей контента и его перезатиранием в режиме коллаборации, отвалом соединения и последующими невозможностями сохранить.

Trello

Ну вот а когда мы подходим к Trello - оно просто поддерживает карточки. И голосовалку для этих карточек с помощью power-up'ов (очень просто). Или через тегирование этого дела цветами (что работает просто и быстро).

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

Короче говоря: trello это самый простой в использовании аналог флипчарта со стикерами :)

Подготовка к самой ретроспективе, и ее начало

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

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

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

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

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

Сама Ретроспектива

В зависимости от зрелости и атмосферы в команде можно использовать Ice Breakers (чтобы настроить на легкое взаимодействие и убрать ощущение обязаловки). Ну и не забудьте проверить как команда чувствует себя после спринта (проверка температуры) - не ждите высокой оценки как данности.

Запланированные улучшения с прошлого спринта

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

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

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

Иногда эта стадия может затянуться (планировали улучшение - не смогли достичь - начинаем погружаться слишком сильно в детали почему). Как фасилитатор, ваша задача помочь команде найти продуктивный путь для выявления настоящей причины в достаточно короткий срок (у нас ведь есть таймбокс). Поэтому мы с вами планируем один обязательный пункт улучшения, два уже имеют риск затянуть начало ретроспективы. Также старайтесь просто запарковать это обсуждение на полее поздние части ретроспективы - если нужно действительно разобраться. А возможно это даже не относится к ретроспективе как к событию, а надо проводить RCA / Post-Mortem?

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

Цели спринта и метрики

Цели Спринта

Цели спринта это ваш индикатор прозрачности. Достигли ли вы их или нет. При правильном использовании, команда постоянно ориентируется на цели спринта во время каждого события, и поэтому сама должна отлично понимать как она с этой целью справилась. Я считаю что даже если цель обсуждена на Sprint Review, все равно хорошо бы еще раз подсветить причины удачи или неудачи достижения (а это уже непосредственно относится к процессу работы, а значит и к ретроспективе).

Опять же, color-coding предельно простой - зелененький цвет говорит что цель достигнута, красный - нет. Можно добавить комментарий, чтоб дать контекст почему нет или да.

Метрики

Метрики спринта важны и как внутренний-SLA для команды, и как общий индикатор, который в комплексе помогает команде понять динамику.

Обычно команда навскидку придумает с десяток факторов, которые для неё препятствия чтоб быть более эффективной. Если поддерживать ведение такой дискуссии в правильном русле (читай, фасилитировать), и помогать команде наводящими вопросами (читай, коучить), ребята сами соорудят путь к улучшению и как его измерять. Главное чтобы был запрос на улучшение, и была понята сама проблема (нафига оно нам вообще). Еще нюансик: не рассматривайте метрики отдельно друг от друга, и стройте связи между опережающими индикаторами (гипотезами) и запаздывающими индикаторами (результатом). Например, действительно ли увеличение покрытия кода тестами увеличивает уверенность в том, что на проде качество улучшается?

Стандарные метрики, которые я стараюсь использовать:

- Lead Time (время от запроса клиента до поставки)

- Cycle Time (время от начала работы над задачей до поставки). Когда объяснишь на примере донесения ценности до пользователя - как устроен весь пайплайн и где затыки, ребята сами будут мотивированы следить за этими метриками (если, конечно, они у вас общаются с клиентами постоянно),

- Время в Code Review (атож, сколько задача висит и сколько ее проверяют),

- Количество раз тикет был переоткрыт (помогает вместе с определением Definition of Ready),

- Mean Time to Recovery (инцидент-метрика для понимания среднего времени на устранение),

- Bug Escape Rate (сколько багов мы не поймали на тестовых стендах, но поймали после релиза на прод).

В целом все зависит от ситуации, но я считаю Cycle Time и Lead Time тем самым минимумом для всех. Cycle Time в целом дает вам понимание прозрачности и предсказуемости.

Активность на выявление дельты улучшения ~ 'Хорошо-Плохо-Улучшения

Единственное, что как и в локализованных командах, люди в распределенных командах должны "вешать стикеры" с рефлексией заранее, чтоб у всех был контекст. Если таких "стикеров" много - можно организовать голосование, дабы сузить круг обсуждаемого. Не нужно ждать начала самого ретро для сбора обратной связи. Опять же, роль фасилитатора заключается в подсветке конфликтов и проблем когда команда непосредственно с проблемами этими сталкивается. Можно и нужно помогать команде корректно и ёмко отражать саму суть проблемы. Подсвечивать можно по-разному, например отражая что слышишь от команды (я правильно понимаю, что ты имеешь ввиду ....), или беря на себя роль человека, не знакомого с контекстом задачи/проблемы, как-то еще. Самое главное, чтобы команда была вовлечена в процесс инспекции во время самого спринта или каденции, а не только во время ретро.

Собираем фидбек с команды о том, как прошла ретроспектива

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

Референсы и полезности

У Бена Линдерса (Ben Linders) есть хорошая трелло-доска, в которой люди краудсорсят ретроспективные техники для распределенных команд в трелло.

  • https://www.benlinders.com/news/trello-board-retrospective-techniques/ Это, наверное, и разговоры с самим Беном, были огромным подспорьем, чтобы написать этот пост.


Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru