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

Содержание

Ретроспектива проекта. Как правильно провести и зачем?

Ретроспектива проекта. Как правильно провести и зачем?

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

«Ритал ретроспективы – это больше чем анализ прошедшего. Он позволяет также взглянуть вперед, представить следующий проект, и особенно тщательно проработать, что в следующий раз будет делаться по-другому». Норм Керт (Norm Kerth)

Сколько длится ретроспектива?

Продолжительность зависит от объема и продолжительности проекта и количества участников. Например, если длительность проекта не больше месяца, то на  ретроспективу уходит 3 — 4 часа. В таком же формате можно подводить итоги года, тогда встреча может длиться 1 — 2 дня.

Как часто проводить ретроспективы?

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

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

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

Как провести ретроспективу?

Существует много форматов ретроспектив. Для быстрой ретроспективы непродолжительного проекта или этапа проекта удобно использовать визуальные шаблоны. Хотим поделиться одним из наших любимых шаблонов — “Парусник”.

«Парусник» — простой и эффективный визуальный шаблон, который отлично подходит для проведения ретроспективы проектов.

 Как работает визуальный шаблон:

  • Лодка — команда;
  • Остров — цели для достижения;
  • Ветры — силы, которые нами движут, мотивация;
  • Якорь — тормоза, что не дает идти вперед;
  • Солнце — благодарность, что понравилось в текущем проекте;
  • Скала — препятствия на пути, будущие риски,

 Порядок действий:

  1. У участников есть 5 мин. на подготовку стикеров к элементам рисунка
  2. Каждый член команды наклеивает свой стикер на рисунок, аргументируя каждый пункт. В этот момент каждый высказывается о том, что, по его мнению, было хорошего, что можно улучшить и что бы он сделал по-другому в следующем проекте (на следующем этапе проекта). В момент, когда говорит участник, другие его не перебивают
  3. Участники голосуют за те предложения, которые им кажутся наиболее важными. Так выбираются улучшения, которые команда будет внедрять в следующем проекте (или этапе проекта)
  4. По каждому из предложений составляется план действий, при реализации которого продукт улучшится

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

Примеры “наших” тем для ретроспективы:

  • Коммуникации внутри команды
  • Коммуникация команды с Заказчиком
  • Контроль реализации проекта
  • Методы реализации проекта
  • Производительность команды
  • Затраты времени: как оптимизировать

Ретроспектива проекта, на которую команде захочется приходить / Хабр

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



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



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


Для полезной ретро у вас должны быть:





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

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

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


Лучше всего, если у команды есть общая таблица.

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



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

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



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



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



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



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

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

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


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

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



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

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



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



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

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

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

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

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



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



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



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

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

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

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

Ретроспектива проекта | HighAdvance Consulting Group

Вариации проведения техники ретроспектива проекта

Вариаций проведения ретроспективы несколько — это зависит от количества участников. Если группа небольшая (5-7 человек) можно сделать так, чтобы все писали карточки индивидуально, а затем группа для работы (обсуждения) будет одна, совместная. Если участников встречи не много – повторы на карточках при обсуждении не убираются. Это позволяет увидеть отношение участников к заявленной теме.

Если группа большая, то можно использовать инструмент MeWeAs (смотрите в разделе «Инструменты фасилитации»). Задача в малых группа (5-7 человек) – услышать друг друга и помочь друг другу скорректировать карточки, чтобы не было непонятных карточек, убрать «повторы». Сначала карточки заполняет каждый. Важно (и это прописать в инструкции) — карточку расположить горизонтально. На одной карточке – одна идея. Желательно, чтобы на карточке было три – семь слов. Если на карточке будет одно слово – не совсем будет понятно, что означает это слово. Более семи слов на карточке – это много. Обратите внимание в группе, чтобы то, что написано на карточке было понятно. Группа может предложить сформулировать карточку таким образом, чтобы было понятно всем.

Во время обсуждения могут появиться новые идеи – это так называемые ассоциативные идеи. Их тоже нужно записывать.

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

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

Структуру карточек мы рассказывали выше. В конце работы малые группы выносят результат работы на всеобще обсуждение.

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

После окончания расклейки карточек мы видим визуальную картину отношения участников группы к обсуждаемому вопросу. При планировании пространства желательно предусмотреть, чего будет больше: позитива или негатива, и, соответственно, исходя из этого — сформировать место для карточек. Тоже самое надо учесть при планировании места под период (сколько места выделить под тот или иной период).

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

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

Зачем нужна ретроспектива? Это возможность принимать правильные решения в будущем. Мы анализируем свои ошибки и достижения и делаем корректировки в своей работе.

Что дает ретроспектива проекта?

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

Как проводить ретроспективу проекта?

Теперь давайте разбираться как проводить ретроспективу проекта:

  • соберите всех тех, кому это может быть полезно: менеджера проекта, команду разработки, маркетологов, HR, другие команды;
  • определите повестку и дедлайн сбора;
  • расскажите о достижениях проекта, ошибках, проблемах и способах их решения, инновациях и, самое главное, о результатах. Желательно давайте информацию в цифрах и только конкретику;
  • сделайте выводы из проекта, их должно быть не больше 5;
  • зафиксируйте результаты ретроспективы в логе проекта.

Сначала пробуйте делать это на относительно простых проектах. Ретроспектива проекта – это простой и отличный способ внедрения инноваций. Внедрите это прямо сейчас.

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

P. S. Если вы на пороге создания своего проекта, то рекомендуем сначала ознакомиться с курсом “Как создать программный продукт”, который разработан для планирующих создавать свой продукт и для тех, кто уже столкнулся с подводными камнями реализации проекта на практике.

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

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

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



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


Для полезной ретро у вас должны быть:





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

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

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

Лучше всего, если у команды есть общая таблица.

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



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

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



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



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



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



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

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

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


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

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



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

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



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



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

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

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

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

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



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



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



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

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

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

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

4 шага подальше от граблей

Введение

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

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

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

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

Для начала обозначим краткий план мероприятия:

  • подготовка участников;
  • подготовка ведущего;
  • проведение ретроспективы;
  • контроль выполнения договорённостей.

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

Шаг 1. Подготовка участников

Когда проводить ретроспективу и какие вопросы задавать?

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

Хакатон «Финансы, Банкинг, Страхование»

3–5 сентября, Москва, Санкт-Петербург, Екатеринбург, Нижний Новгород, Волгоград, Саратов, Новосибирск, Уфа, Великий Новгород, Беcплатно

tproger.ru

Следующий момент, требующий внимания до встречи, — это список вопросов. Это могут быть стандартные «что мы сделали хорошо?» и «что мы сделали плохо?» или другие насущные вопросы, которые могут прийти в голову. Например, можно узнать, какая в команде атмосфера. Не исключено, что кто-то ответит «у нас всё круто, твердая пятёрка», а кто-то из этой же команды поставит троечку с натяжкой. Вот вам и повод хорошенько всё обсудить.

Ещё несколько примеров вопросов

Стандартным для нашей команды является вопрос «кто вам помогает в работе?». Вопрос на первый взгляд странный, но он способствует сплочению коллектива, выявлению наиболее инициативных членов команды и их моральной мотивации. Вот только задавая такой вопрос, будьте готовы, что официальный лидер не обязательно будет таковым в глазах подчинённых.

Можно также узнать противоположное мнение: «кто вам мешает в работе?». Тут тоже стоит ожидать разброса в ответах. Это может быть чересчур общительный коллега или непосредственный начальник, который то и дело просит какие-то отчёты, или угрюмый представитель компании-партнёра, с которым, хотите вы того или нет, а надо общаться.

Точно не стоит спрашивать «кто виноват?». Как бы вам ни хотелось получить ответ на этот вопрос, задавая его вот так напрямую, вразумительного ответа вы не получите. Чего вы точно добьётесь, так это перекладывания вины и ответственности, нездоровую атмосферу в команде и тяжёлый осадок обид. Задавая вопросы, разбирая ответы и проводя саму встречу, стоит настроить себя на то, что все выложились по максимуму и сделали всё, что от них могло зависеть.

Превентивные вопросы

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

Какой от этого профит, спросите вы, если всё равно все соберутся и будут обсуждать то же самое? Не все люди умеют или любят разговаривать с другими. Не все могут сразу сформулировать свою проблему: будут рассказывать длинную предысторию, где в самом конце, возможно, промелькнёт то, что человек хотел сказать. Может случиться и так, что это будет попытка найти фантомную проблему там, где её нет, с аргументацией: «не знаю, что точно, но всё как-то не так». Время — деньги, поэтому я даю шанс людям предварительно высказать все мысли и эмоции на бумаге, сэкономив команде силы на ретроспективе.

Шаг 2. Подготовка ведущего

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

Для проведения вашей первой ретроспективы этой подготовки будет достаточно.

Подготовка второй и последующих ретроспектив

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

Как вспомнить прошедшие ретроспективы и их итоги?

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

Мы её немного доработали, поэтому табличка состоит из пяти колонок:

  1. «Суть» поднятой проблемы. Желательно тезисно, чтобы при беглом просмотре было ясно, о чём идёт речь.
  2. «Plan» — планирование решения или возможные варианты развития событий.
  3. «Do» — что в итоге было сделано из запланированного.
  4. «Check» — здесь мы фиксируем, к чему привели наши действия.
  5. «Act» — есть несколько вариантов перевода этой части цикла, например «воздействие» или «корректировка». Это своеобразный итог всей строки.

Здесь можно писать короче, чем в остальных колонках:

  • если проблема решена, можно написать «Выполнено»,
  • если не решена, но выбранный путь кажется верным, можно написать «Продолжай»,
  • если же вы ни на шаг не приблизились к решению проблемы, пишите «Всё пропало». Эту грустную формулировку можно заменить на локальный мем, мы предпочитаем использовать открытый призыв — «Думай дальше…».

Шаг 3. Проведение ретроспективы

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

Порядок выступающих

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

Итак, все организационные вопросы решены. Давайте начнём ретроспективу.

Как это обычно происходит?

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

Что спрашивать?

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

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

Как фиксировать информацию?

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

Кстати, после того, как вы определились, выбранный вариант тоже нужно зафиксировать. Для этого нам понадобится третий лист ретроспективы — «Регламентируем предложения» («Наши планы», «Сделай так», «Итоги» и тому подобное). Именно сюда выносим согласованные предложения, назначаем ответственного и ставим контрольный срок исполнения.

Не забудьте, что сроки по каждому пункту надо обсудить с ответственным. Даже если речь идёт о разговоре с дизайнером и это дело пяти минут, всё равно ставьте срок. Это позволит не забыть о порученной задаче. Конечно, одной записи на листочке может быть мало. Ведь все люди что-то забывают, но к этому мы ещё вернёмся.

Остались вопросы?

Когда проблемы закончились, и по каждой есть план действий, обязательно спросите: «Кто хотел бы высказаться о чём-то ещё»? Возможно, у человека была мысль, но его перебили, и мысль так и осталась мыслью.

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

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

Шаг 4. Контроль выполнения договоренностей

Ведущий ретроспективы должен отдельно написать себе список и конечный срок выполнения принятых решений. В свой календарь, ежедневник, доску канбан, смотря чем вы пользуетесь. Это нужно для оперативного контроля за решением поставленных задач. За пару дней до дедлайна я уточняю у ответственного, не забыл ли он о своём поручении. Бывает так, что задача уже выполнена, и сотрудник вот-вот собирался рассказать о результате. А бывает, что в ответ вы слышите «ой» и видите сверкающие пятки сотрудника. Значит, вы поступили правильно, спросив заранее и напомнив о задаче.

А что если принятое решение оказалось невозможно выполнить?

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

Выводы

Кому нужна ретроспектива?

Ретроспектива — это важная и нужная часть вашего продвижения на пути к глобальной цели. И тут совершенно не важно, разрабатываете ли вы модное приложение для блогеров или у вас строгий банковский продукт. Особенно на ретроспективу важно обратить внимание тем компаниям, которые выбрали для себя разработку в стиле Agile и двигаются короткими итерациями. Так вы точно не свернёте с намеченного пути и вовремя заметите, если где-то проседаете по срокам и ваш критический путь увеличивается.

Что будет, если не проводить ретроспективу?

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

Есть меткая цитата Сократа, которую любили повторять Ломоносов и Пушкин: «Народ, не знающий своего прошлого, не имеет будущего». Хотите учиться на своих ошибках с первого раза и перестать наступать на одни и те же грабли, ретроспектива — ваш выбор.

Да, возможно, кому-то это покажется скучным и занудным мероприятием. Но в целом, всё зависит от команды. Заодно вы сможете узнать, какая у вас царит атмосфера. Кто с кем больше соглашается, кто кого стесняется, и чем вообще занимаются люди, когда кто-то говорит: внимательно слушают или отстранённо смотрят в окно. Согласитесь, не всегда удаётся вот так собрать всех в одном помещении и заставить говорить на одну и ту же тему.

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

Татьяна Бирюкова, тест-менеджер в «Лаборатории качества»

Ретроспектива в Scrum 🔄 — Как Проводить и Зачем?

За процесс ретроспективы отвечает Скрам–мастер. Именно он следит за качеством процесса работы («как» делается работа, насколько процесс работы эффективен).

Для Agile–подхода к работе характерна фокусировка на человеческие отношения. В связи с этим ключевой принцип ретроспективы заключается в том, что мы по–человечески относимся к любым косякам и ошибкам, при этом обращаем на них внимание.

Для более «классических» форм менеджмента привычными являются такие мероприятия, как оценка, осуждение, порицание, санкции, и даже угрозы. Это все неприемлемо, если мы реализуем agile: ведь «Люди и взаимодействие важнее процессов и инструментов».

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

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

  • Что нужно начать делать? (Start)
  • Что нужно продолжить делать? (Keep)
  • Что нужно прекратить делать? (Stop)

В этим вопросам можно добавить «вариации»:

  • Что нужно делать больше? (More)
  • Что нужно делать меньше? (Less)

Фиксировать итоговые решения можно либо просто вербально (на уровне словесной договоренности), либо можно сделать на отдельной доске / флипчарте. Последний вариант обычно более предпочтителен, так как вы делаете ваши договоренности (commitment) визуализированными и прозрачными.

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

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

Вопрос «Что нужно начать делать?» имеет своей целью внедрение новых полезных особенностей командной работы.

Ситуация постоянно изменяется, как и тип работы, который выполняется в конкретный момент. Возможно, для новой работы или для работы в новых условиях вам нужны совершенно новые способы взаимодействия — между командой, с клиентами, стейкходерами и т.д.

Вопрос «Что нужно продолжить делать?» направлен на выявление хорошо работающих моделей. Это повод для команды зафиксировать, что уже работает хорошо, и каких стандартов работы следует придерживаться.

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

Вопрос «Что нужно прекратить делать?» — очень важный. Он направлен на выявление всего того, что не ведет к ценности и к командному результату.

Это очень важно, потому что — как это не странно — команды и люди в целом всегда склонны делать не только то, что полезно, но и то, что не является полезным. С точки зрения Lean мышления такие действия являются потерями — они не ведут к достижению ценности, а значит, они совершаются «впустую» и даже в минус (потому что та же самая энергия и время могли быть инвестированы в полезные действия).

В этом смысле ретроспектива в Скраме позволяет обнаружить эти «потери» и устранить их. В результате — ваша команда будет делать только полезные действия, только то, что является важным и ведет к получению ценности (как бизнесом, так и вашим клиентом).

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

Скрам–команда должна быть единой и целостной системой. Ретроспектива должна развивать и укреплять эту целостность.

Почему и как проходят ретроспективные встречи проектов

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

Что такое ретроспективная встреча?

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

Еженедельная ретроспективная встреча

Зарегистрируйтесь или войдите в систему, чтобы использовать

Почему вы должны проводить ретроспективные встречи по проектам?

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

Вы создадите среду прозрачности и доверия

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

Вы повысите командный дух.

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

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

Вы поможете своей команде учиться и развиваться.

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

Как провести ретроспективу проекта

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

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

Какова была наша цель?

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

Что на самом деле произошло?

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

Почему это произошло?

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

Что мы будем делать в следующий раз?

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

Шаблон для ретроспективной встречи по проекту

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

Project Retrospective

Зарегистрируйтесь или войдите в систему, чтобы использовать

Обновите свою учетную запись

Обновите свою учетную запись до базовой или профессиональной и получите доступ к неограниченным вопросам викторины, неограниченным типам интерактивных вопросов и многому другому! Обновите

Сообщите мне о новых сообщениях в блоге

Ретроспектива «Как запустить убийственный проект»

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

Что такое ретроспектива проекта?

Ретроспектива проекта — это процесс, в котором команда размышляет над проектом и ищет способы стать более эффективной как команда. В Agile Manifesto говорится, : «Команда регулярно размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение. В конечном итоге цель состоит в том, чтобы заставить команду найти способ работать лучше.

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

Провести ретроспективу

При проведении ретроспективы проекта помните, что цель состоит в том, чтобы выяснить основные уроки, извлеченные из проекта.Шаблон ретроспективной повестки дня проекта может фиксировать эти комментарии, чтобы помочь командам применять их в будущих процессах. Имейте в виду, что все члены команды должны присутствовать на ретроспективе проекта. Чтобы команда хорошо работала вместе, нужно пригласить всех поделиться своими мыслями и мнениями. Есть три вопроса, на которые каждый должен быть готов ответить:

  1. Что прошло хорошо?
  2. Что пошло не так?
  3. Что мы можем улучшить в следующий раз?

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

Проект

Ретроспективные идеи

Есть несколько способов сделать ретроспективные программы своих проектов более эффективными. Некоторые из ключевых моментов, о которых следует помнить, включают:

  • Заметки о встречах : взгляните на заметки о встречах по проекту, которые могли иметь место. В идеале у команды было несколько встреч за время совместной работы, и кто-то делал записи.Взгляните на записи и найдите общие темы. (Программное обеспечение для управления встречами, такое как Docket, может помочь в этом!)
  • Использование опроса : Также полезно использовать так называемый ретроспективный опрос проекта. Вместо того, чтобы использовать время во время встречи для сбора идей, заранее разошлите обзорный опрос. Этот опрос можно использовать для сбора всех мыслей и идей перед встречей, особенно для тех членов команды, которые предпочитают думать в письменной форме, а не на месте.Затем, когда команда соберется вместе, они будут готовы начать обсуждение этих идей или их дополнений / расширений.
  • Поделитесь заметками о встрече : Наконец, неплохо также поделиться любыми заметками о встрече из ретроспективного шаблона с руководством компании. Это важно для обеспечения прозрачности. Более того, если компания знает, что команда усердно работает над улучшением, они с большей вероятностью позволят процессу разыграться.

Проведите эффективную ретроспективу

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

Как провести успешную ретроспективную встречу по проекту (обновление 2019)

Мы не учимся на опыте… мы учимся, размышляя над опытом.

Джон Дьюи

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

Что такое ретроспектива проекта?

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

Эти встречи, официально оформленные как обзор действий армии США, гарантируют, что команда быстро извлечет уроки из каждого сражения.

Вот классические вопросы вроде:

  • Что мы намеревались сделать?
  • Что на самом деле произошло?
  • Почему это произошло?
  • Что мы будем делать в следующий раз?
Ретроспективы дают команде время подумать над тем, что они узнали.

Основной процесс

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

1. Просмотрите проект.

Начните с анализа фактов о проекте: целей, сроков, бюджета, основных событий и показателей успеха.

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

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

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

2. Обсудите, что сработало, а что нет.

Это сердце встречи. Все делятся тем, что узнали в ходе проекта: и хорошим, и плохим.

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

3. Планирование действий: определите конкретные способы улучшения будущей работы.

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

Это отстой. Это демотивирует, обескураживает и пустая трата времени.

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

Настоящий прогресс — ооочень хорошо.

Рекомендации по обрамлению

Ретроспективы — это практика.

Проведение действительно великолепной ретроспективы требует навыков, которые можно приобрести только с опытом. Эффективное участие также требует практики.

Эти встречи проходят лучше и приносят лучшие результаты после того, как вы их проведете несколько раз. Людям необходимо почувствовать, какие отзывы окажутся полезными. Им нужно видеть, что их идеи услышаны и что собрание принесет реальные изменения.Практика помогает команде легче подготовиться и быстрее заключать лучшие соглашения. Что еще более важно, хорошо выполненная ретроспектива приводит к изменениям, которые улучшают работу команды в будущем; реальная возможность внести значимые изменения — огромный мотиватор.

Планируйте достаточно времени.

Каждая встреча должна длиться МИНИМУМ 1 час. Практическое правило — 45 минут в неделю работы над проектом. Например, однажды я руководил цифровыми веб-проектами, которые длились от 3 до 6 месяцев. После каждой важной вехи мы проводили более короткие ретроспективы, а в конце — одну большую «Подборку проекта» или «Встречу успеха».Обертывание Project Wrap обычно длилось 3 часа, после чего мы все пошли за начо и пивом.

Требуется подготовка.

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

Не говорите . Составьте план и упростите подготовку команды.

Начните позитивно, сосредоточив внимание в первую очередь на успехе.

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

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

Это ловушка.

Например, встречали ли вы когда-нибудь кого-нибудь, кто был в высшей степени привилегированным, который прошел через детство и колледж на деньги своих родителей, награды за все свои «достижения» висели на стене, только чтобы быть шокированным и разочарованным, когда «реальный мир» этого не сделал. вознаградить своего особенного единорога за то, что он просто появился? Если вам посчастливилось жить в США, конечно же, есть.

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

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

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

См. Эту замечательную статью HBR, чтобы узнать больше об этой:
Почему лидеры не учатся на успехе

Сделайте это безопасным.

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

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

Основная директива говорит:

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

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

Норм Керт, Ретроспективы проекта: Справочник для командного обзора

Маленькие изменения имеют большее влияние, чем хорошие идеи, которых никогда не бывает.

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

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

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

Подробнее: Рентабельность инвестиций в Agile-ретроспективы: как эффективные Rertros могут улучшить вашу прибыль

Пошаговая инструкция: ретроспектива создания вашего проекта

Повестка дня

  1. Добро пожаловать
  2. Обзор проекта
  3. Что мы узнали?
    • Успехов
    • Вызовы
    • Другая информация
  4. Приоритеты: что важнее всего?
  5. Изменения, которые необходимо внести: Планирование действий
  6. Закрытие

Подготовка

  1. Определите свою аудиторию .
    Кому вы «передадите» результаты этой встречи? Это поможет вашей команде улучшить внутренний процесс, для команды, унаследовавшей ваш проект, или для отдела или компании в целом?
  2. Составьте отчет по проекту и график , включая основные события и вехи.
    Также просмотрите исходное определение проекта, критерии успеха и все имеющиеся у вас метрики, касающиеся результата проекта.
  3. Уточнить повестку дня .
    Решите, как вы хотите проводить различные части собрания, и соответствующим образом обновите повестку дня.Если это ваша первая ретроспектива, мы рекомендуем придерживаться простого формата, описанного ниже.
  4. Запланируйте встречу по крайней мере за 3 дня до .
  5. Пригласите команду .
    Попросите их подготовить свои ключевые идеи, наблюдения и идеи для улучшения.
  6. Приобрести припасы .
    Некоторые ретроспективные методы требуют дополнительных принадлежностей, таких как стикеры или системы онлайн-голосования. При личных встречах полезны закуски!

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

Проведение собрания

1. Добро пожаловать

Подключитесь друг к другу и к цели.

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

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

Наконец, задайте тон, поделившись Директивой Retrospective Prime или чем-то подобным.

2. Обзор проекта

Затем убедитесь, что у всех есть общее представление о проекте.

Вы можете сделать это одним из трех способов.

Вариант 1. Попросите группу рассказать об этом .

Для более коротких проектов или для ретроспектив в середине проекта вы можете попросить группу обсудить факты.

Вопросы:

Что должно было случиться?
Что на самом деле произошло?

или

Чего вы намеревались достичь?
Каков был ваш план по достижению этого? Как это изменилось по мере вашего прогресса?

Вариант 2: Поделиться отчетом

Руководитель проекта представляет отчет по проекту, а команда по ходу его комментирует.

Вариант 3. Создание общей временной шкалы

Например, см. Упражнение «Пики и впадины»

.

Это один из способов создания общей временной шкалы. Это занимает больше времени, но способствует лучшему разговору и более сильному общему опыту. И это весело!

3. Что мы узнали?

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

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

В нашем онлайн-шаблоне все просто. Спрашиваем о:

Успехи

Что действительно хорошо сработало в этом проекте?
Что мы должны сделать снова в будущем?

Вызовы

Где мы столкнулись с проблемами?

Прочая информация

Где нам повезло?
Что было неожиданного?
Кто вам помогал в этом проекте?

Вопросы для ретроспективы

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

Общие вопросы о проекте

  • Вы гордитесь нашей готовой работой? Если да, то что сделало его отличным? Если нет, что было не так или чего не хватало?
  • Достигли ли мы желаемых результатов и оказали ли они влияние?
  • Какие инструменты или методы оказались полезными? Что нет?
  • Что вы узнали о работе с этим клиентом?
  • Какие важные решения были приняты в ходе этого проекта?
  • Какие компромиссы были сделаны? (То, что могло показаться ошибкой, но было сделано по какой-то причине.)

Вопросы о том, что работало

  • Что было наиболее приятным или профессионально удовлетворяющим частью проекта?
  • Что мы сделали хорошо, что, если не будем обсуждать, можем забыть?
  • Что помогает нам быть успешной в команде?
  • Какие из наших методов или процессов работали особенно хорошо?
  • Где нам повезло? Что мы можем сделать, чтобы добиться успеха, если в следующий раз нам не повезет?

Вопросы о вызовах

  • Что было самым большим препятствием?
  • Какие из наших методов или процессов было сложно или неудобно использовать?
  • Что было больно, но необходимо?
  • Что еще не дает вам уснуть по ночам? Что мы оставили нерешенными?
  • Что до сих пор вызывает у нас недоумение?

Вопросы о выносе

  • Какой совет вы дали бы себе, если бы вернулись к началу проекта?
  • Что мы должны извлечь из этого проекта через год?
  • Есть какие-то уроки лично для тебя?
  • Что еще мы могли бы сделать лучше в следующий раз?

Наборы вопросов

Используйте столбцы или сетку, чтобы систематизировать ответы по категориям.

  • Понравилось, узнал, не хватало и жаждал
  • Отбросить, добавить, сохранить и улучшить
  • Остановить, запустить и продолжить
  • Приятное, разочаровывающее, озадачивающее

См. Дополнительные ресурсы ниже.

4. Приоритеты: что важнее всего?

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

В группе выберите главные идеи (или темы), которые вы хотите обсудить в команде.

5. Изменения, которые необходимо внести: планирование действий

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

6. Закрытие и оценка

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

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

2 простых и быстрых способа получить отзыв о встрече

На вынос

Успешная ретроспектива — это многое. Я много чего поделился здесь, и даже больше в руководстве.

Не позволяйте этому запугать вас. В начале помните:

  1. Все, что изучает ваша группа, что помогает вам совершенствоваться, имеет значение , даже мелочи, о которых было странно говорить.
  2. Это командные усилия. Как лидер вы устанавливаете структуру, но должна получить результат целая группа .
  3. Для начала необязательно знать все хитрости. Некоторые люди проводят ретроспективы, просто задавая вопросы и давая возможность всем высказаться.

Как сказал Конфуций:

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

Конфуций

Ретроспектива — это ваша возможность превратить горечь опыта в благородство размышлений.

Передача этого процесса вашей команде

The Meeting Guide для успешных ретроспектив проектов

И если вы нашли что-то, что работает особенно хорошо для вас, поделитесь этим в комментариях ниже, чтобы будущие читатели тоже увидели.


Учимся руководить? Этот онлайн-курс для вас

Общие вопросы и ответы

Что такое ретроспектива проекта?

Эти встречи бывают разными именами — вскрытия, ретроспективы, обзоры результатов, подведение итогов, встречи «успеха» проекта и многое другое.Ретроспектива проекта посвящает время обзору завершенного проекта и извлечению уроков из успехов и неудач, чтобы команда и организация могли улучшить свою работу в будущем.

Что происходит в ретроспективе проекта?

Группа рассматривает проект, обсуждает, что сработало (а что нет), и определяет конкретные способы улучшения будущей работы.

Как мне провести хорошую ретроспективу?

Запланируйте достаточно времени, чтобы сделать это хорошо (1–3 часа), попросите всех подготовиться заранее, начните позитивно, сосредоточившись в первую очередь на успехе, сделайте так, чтобы люди могли высказать свое мнение, и спланируйте внесение небольших изменений, которые могут соединение с течением времени.

Какие вопросы я должен задать в ретроспективе?

Сосредоточьте свои вопросы на трех основных областях: успехах (например, «что действительно хорошо сработало в этом проекте?»), Проблемах (например, «какие из наших методов или процессов было сложно или неудобно использовать?») И другие идеи. (например, «где нам повезло?» или «что было неожиданным?»).

Что мне делать с результатами ретроспективы?

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

Дополнительные ресурсы

Есть очень много хороших ресурсов для изучения ретроспектив. Многие из них происходят из сообщества Agile-разработчиков, но эти практики применимы независимо от того, какой проект вы запускаете. Это лишь некоторые из наших любимых.

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

4 — Ретроспектива идеального проекта

Простая схема действий и подходов для успешной ретроспективы
Bill Hoberecht — Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра.

В то время как концепцию ретроспективы проекта легко понять, слишком легко потерпеть неудачу при попытке реализовать концепцию. Эстер Дерби и Диана Ларсен буквально написали книгу о ретроспективах — вот их пятиступенчатый подход с некоторыми конкретными советами, которые помогут вашим проектным командам эффективно проводить ретроспективы проектов.

Представляем серию статей об идеальной ретроспективе

Частое выполнение цикла открывает возможности для улучшения У команд

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

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

Что такое ретроспективы?

Считайте, что ретроспективная деятельность сосредоточена вокруг этого вопроса:

«Как мы можем работать вместе, чтобы улучшить ситуацию сейчас, чтобы наш следующий проект был явно лучше?»

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

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

Цель ретроспективы — улучшить работу команды над проектом.

Три важных напоминания для идеальной ретроспективы

Вот несколько напоминаний, которые сделают вашу ретроспективу исключительно эффективной:

  1. Применяйте передовые методы проведения встреч. Основные элементы встречи могут сделать или сломать сбор вашей команды. Разберитесь с ними как следует, и вы начали ретроспективу на положительной ноте. Ваш контрольный список, вероятно, должен включать в себя следующие пункты: обеспечить надлежащее предварительное уведомление о встрече, создать и опубликовать повестку дня с предлагаемыми советами по подготовке, обеспечить хорошее место встречи и планировку комнаты, обеспечить достаточный запас материалов, необходимых для мероприятий (белые доски, липкие ленты). заметки, маркеры) и продвигайте командные нормы, которые каждый участник предложит по прибытии.
  2. Использовать данные проекта. На раннем этапе ретроспективы приходит к общему, общему взгляду на результативность проекта — данные проекта являются одним из ваших самых важных входных данных для этой деятельности. Уделяйте достаточное внимание данным, которые имеют наибольшее значение для команды проекта при точном отображении эффективности проекта с точки зрения членов команды, вашего клиента, других заинтересованных сторон и руководства. Выберите эффективный способ представления данных для удобного использования и использования во время ретроспективы.
  3. Выберите действия по улучшению, которые окажут реальное влияние . Решающим шагом в ретроспективе является выбор действий по улучшению, которых будет придерживаться команда, и ключевые желаемые результаты должны иметь устойчивое и широко распространенное использование ретроспективных результатов. Естественно, вы захотите иметь определения SMART для ваших действий. Попробуйте эти два теста, применяемые к каждому предлагаемому действию улучшения:
    1. Оцените жизнеспособность (действительно ли это действие будет выполнено?) И повлияет на (если мы выполним это действие, действительно ли оно улучшит производительность нашего проекта? производительность любых других проектных групп?) каждого предлагаемого улучшения.Вы можете визуально представить эту оценку, нарисовав эту сетку на белой доске и используя стикеры, чтобы поместить каждое предлагаемое улучшение, чтобы отразить его оценку:
    2. Спросите: «Как это действие по улучшению будет внедрено в другие проекты?» Лучшими действиями по улучшению будут обновления активов проекта или организации (например, учебных материалов, описаний процессов, рабочих инструкций, должностных инструкций), потому что они имеют больше шансов стать частью основной деятельности всей организации.Еще одна очень хорошая категория действий по улучшению — это идентификация и запуск нового проекта / спринта / пользовательской истории, что в конечном итоге приводит к улучшению продукта.

Проведение идеальной ретроспективы

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

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

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

Ниже приведен план / контрольный список мероприятий для ретроспективы проекта, основанный на превосходной работе Эстер Дерби и Дайаны Ларсен в книге Agile Retrospectives: Making Good Teams Great.Я добавил несколько собственных советов, но это пятиступенчатая модель Эстер и Дианы. (Вот несколько похожих статей других авторов — их тоже определенно стоит прочитать: Рефакторинг процесса разработки с помощью ретроспективы, Как мы проводим ретроспективу и Анатомия ретроспективы)

ПЕРВЫЙ: Подготовка к встрече

  1. Кто: Кто должен присутствовать? Обычно все сводится к следующему: следует ли нам пригласить владельца продукта? Как насчет нашего руководства? Делайте выбор в зависимости от того, будет ли их посещение способствовать или мешать достижению целей ретроспективы.Один из участников назначается фасилитатором — обычно это Скрам-мастер.
  2. Продолжительность: в то время как некоторые рекомендуют один час (ретроспективного времени встречи) в неделю во время итерации, я склоняюсь к тому, чтобы ретроспективы были намного короче. Учитесь и адаптируйтесь на опыте вашей команды (например, если 30 минут для предыдущей ретроспективы было недостаточно, попробуйте 45 минут для предстоящей встречи).
  3. Повестка дня: Опубликуйте повестку дня собрания для всех участников
  4. Исследование (необязательно): изучите ретроспективы сопоставимых проектов и найдите сокровища мудрости, которые могут быть полезны для вашей ретроспективы.
  5. Предварительные комментарии к собранию: если у вас есть вики-проект или доска обсуждений, поищите в этом источнике любую информацию, которая будет полезна для ретроспективы. Это один из ваших источников данных для встречи.
  6. Данные о реализации проекта: собрать данные и подготовить материалы для презентации; это будет основанием для оценки выполнения проекта
  7. Предыдущие ретроспективы: найдите результаты предыдущих ретроспектив для этой проектной группы — вы будете использовать их, чтобы проверить эффективность выбранных улучшений и напомнить всем о ранее обнаруженных потребностях в улучшении.

ВТОРОЕ: Проведение собрания — проверка эффективности, изучение мнений, изучение

  1. Установить сцену
    • Объясните цель собрания, просмотрите повестку дня (5 шагов) и формат (очень интерактивный!)
    • Создать новое или просмотреть существующие, соответствующие нормам
    • Если возникает важная необходимость сосредоточиться на конкретной теме, определите эту тему и обеспечьте согласие по этому ограниченному кругу ключевой области внимания (это, вероятно, уже было бы указано в опубликованной повестке дня)
    • Создайте безопасную среду для открытого диалога.
    • Заставьте всех поговорить хотя бы раз с помощью вводного вопроса, на который всем предлагается ответить. Вы находитесь в комнате, чтобы все могли сотрудничать, а растопление льда на ранней стадии собрания позволит всем активнее участвовать.
  2. Сбор данных
    • Укажите данные, которые будут использоваться, согласившись с тем, что они являются достаточными, точными и легкодоступными на этой встрече
    • Представьте данные о выполнении проекта, которые были собраны до встречи
    • Представьте оценку эффективности ранее выбранных действий по улучшению.
    • Собрать дополнительные данные. Делитесь и записывайте мнения и наблюдения с помощью целенаправленного упражнения (например, создание шкалы времени ). Мнения и чувства являются важным фактором при понимании и оценке выполнения проекта.
  3. Создать аналитическую информацию
    • Обсудить и прийти к общему пониманию эффективности проекта . Используйте данные, которые вы только что создали и проверили.Скажите по этому поводу, пока вы не придете к консенсусу — без этой основы согласия у вас могут возникнуть трудности.
    • О чем говорят нам данные? Пришло время проанализировать. Ищите индикаторы серьезных проблем, тенденции с течением времени, если у вас есть исторические данные для анализа, запутанную или непоследовательную информацию (например, качество продукта и скорость доставки повысились, но уровень удовлетворенности клиентов снизился) и важные моменты (например, качество продукта значительно улучшилось. ).
    • Запишите свои идеи. Это могут быть важные наблюдения или предлагаемые действия по улучшению. Мой любимый метод — писать их на больших стикерах.
    • Обобщите свои идеи . Сгруппируйте идеи в группы по интересам — поэкспериментируйте с Mute Mapping (Шаг 3 «Искусство гибкой разработки: ретроспективы»), чтобы создать группы схожих идей; Вот метод: случайным образом поместите свои заметки с мыслями на доску, а затем, по отдельности, беззвучно перемещайте стикеры по группам.Обсудите каждую группу, придя к общему мнению о ключевых идеях каждой группы и названии группы.
  4. Решите, что делать сейчас
    • Оцените каждую группу . Используйте структурированный метод определения значимости выявленных проблем. Вот одна возможность: расположите каждую группу в таблице «Воздействие / жизнеспособность» (описанной и изображенной выше), чтобы помочь вам решить как группу, на чем сосредоточить свои усилия по улучшению.
    • Выберите ровно одну область улучшения для немедленных действий и обязуйтесь выполнить это действие, , используя согласованный метод (например, голосование, консенсус). Это действие по улучшению может исходить из оценки этого завершенного в настоящее время спринта, или вы можете выбрать вариант из своего журнала улучшений. В идеале это действие должно быть полностью выполнено за один спринт. Для крупных действий определите серию более мелких действий, которые необходимо выполнить в нескольких спринтах — они войдут в ваш журнал улучшений.
  5. Закройте ретроспективу
    • Краткое изложение коллективного взгляда на выполнение проекта, основные идеи и выявленные действия по улучшению — дайте возможность для уточнений или вопросов, если отсутствует согласие по любому из этих пунктов. Успешная ретроспектива завершится соглашением по этим пунктам.
    • Подумайте о том, чтобы время от времени проводить небольшое упражнение по построению команды, чтобы подчеркнуть важность сплоченности команды.
    • Сохранить результаты ретроспективного собрания . Это может быть так просто, как сделать цифровую фотографию заметок на доске, или это может потребовать сохранения заметок, сделанных во время встречи.
    • Собрать отзывы о ретроспективе. Предложите каждому участнику выразить свою степень удовлетворения или, возможно, предложите следующую ретроспективу — эта информация иногда приводит к обнаружению сюрпризов, которые могут усилить ретроспективную деятельность.

ТРЕТЬЕ: сразу после собрания
  • Добавить выбранное действие по улучшению в список невыполненных работ по спринту следующей итерации.
  • Опубликуйте ретроспективные результаты для команды и других заинтересованных лиц. Вот возможный список информации для публикации ретроспективы на вики-странице проекта или на доске обсуждений:
    1. Данные и аналитическая информация, которые были созданы до и представлены во время встречи
    2. Данные, созданные во время встречи (эта и другая информация, созданная во время встречи, может быть опубликована либо в виде фотографий, сделанных во время ретроспективы, либо в виде расшифровки заметок, сделанных во время встречи)
    3. Группировка идей
    4. Выбранные действия по улучшению и ожидаемые выгоды
    5. Любые обновления, внесенные в список невыполненных действий по улучшению.

Что дальше?

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

Схема выше — довольно хорошая отправная точка для структурирования ваших ретроспектив. (Вы, несомненно, внесете некоторые изменения и добавите некоторые детали в соответствии с вашими потребностями.) Попробуйте ретроспективы. Они вам понравятся.

Как проводить ретроспективу проекта

Что такое ретроспектива проекта?

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

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

Шаг 1. Подготовка к ретроспективной встрече по проекту

  1. На холсте процесса Scrum щелкните рабочий элемент Ретроспективное собрание проекта , чтобы открыть его.
  2. В качестве первого шага вам необходимо подготовить ретроспективную встречу по проекту, определив дату и время, участников и повестку дня встречи.Щелкните артефакт действия Project Retrospective Meeting .
  3. Заполните форму встречи, чтобы завершить этот шаг. Сначала укажите фон встречи, указав дату, время и место встречи. Кроме того, выберите участников, которые будут присутствовать на собрании.
  4. Перечислите темы для обсуждения на собрании в качестве тем повестки дня. Нажмите Введите , чтобы создать новую тему.
  5. Введите другую информацию, например, о наблюдателях и необходимых ресурсах.
  6. По завершении вернитесь на страницу рабочего элемента с помощью навигационной цепочки.
  7. Когда вы закончите, можете переходить к следующему шагу. Для этого нажмите Complete Step в правом нижнем углу, а затем выберите Complete во всплывающем меню.

Шаг 2. Определите ключевые успехи проекта

Теперь вы находитесь на шаге 2. На этом шаге вы зафиксируете ключевые успехи, достигнутые проектом.

  1. Щелкните артефакт действия Project Key Successes , чтобы продолжить.
  2. Заполните эту форму, чтобы завершить этот шаг. Сначала перечислите основные успехи, достигнутые проектом.
  3. Опишите факторы, которые способствовали этим успехам. Вместо того, чтобы просто описывать успехи проекта, более ценно указать факторы, которые способствуют этим успехам, чтобы аналогичные проекты могли повторить успехи.
  4. Когда вы закончите, вернитесь к рабочему элементу с помощью навигационной цепочки.
  5. Завершите этот шаг, чтобы перейти к выявлению проблем проекта.

Шаг 3. Определите проблемы и недостатки проекта

  1. Нажмите на артефакт действия Проблемы и недостатки .
  2. Проблемы проекта относятся к условиям, не находящимся под контролем команды проекта, которые негативно влияют на проект. Сначала завершите эту часть. Обсудите и перечислите основные проблемы одну за другой.
  3. Опишите их и порекомендуйте решения. Рекомендуемое решение может быть реализовано и признано эффективным.Также это может быть лучшая альтернатива реализованному варианту.
  4. Перечислите основные недостатки проекта. Недостатки — это неверно или некачественно выполненные задачи или неверно принятые решения. Иногда его путают с вызовом и трудностью, но это не так. Проще говоря, вызовы и трудности — это неблагоприятные ситуации, которые необходимо разрешить для завершения проекта, а недостатки — это ошибки и неудачи.
  5. Опять же, опишите элементы и порекомендуйте решения.
  6. Задокументируйте, что команда будет / могла бы сделать по-другому в следующий раз, чтобы улучшить или смягчить трудности в целом (более целостный и стратегический характер).
  7. Когда закончите, вернитесь к рабочему элементу с помощью навигационной цепочки.
  8. Завершите этот шаг.

Шаг 4. Завершение встречи

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

  1. Щелкните артефакт действия Ретроспективное собрание проекта .
  2. Заполните форму встречи. Опишите обсуждение и заключение по каждой теме повестки дня.
  3. Когда закончите, вернитесь к рабочему элементу.
  4. Завершите этот шаг.
Шаблон повестки дня ретроспективного совещания

  • Выберите шаблон

    Сэкономьте время с помощью предварительно созданного шаблона с рекомендуемыми темами для начала работы

  • Настройте его

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

  • Воплотите его в жизнь

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

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

Fellow создал шаблон Project Retrospective Meeting, чтобы помочь вам со структурой и содержанием, чтобы облегчить эту ценную встречу. Этот шаблон Project Retrospective Meeting предоставляет прекрасную возможность внести реальные изменения для постоянного улучшения, которые будут мотивировать вас и вашу команду.

«Вы можете провести ретроспективу в любой момент проекта.Если вы практикуете гибкие принципы, вы, вероятно, будете включать ретроспективы после каждой пары итераций (или спринтов). Тем не менее, все выиграют от вскрытия или постпроектной ретроспективы, независимо от вашей конкретной методологии проектирования и разработки ».

Виктор Йокко , автор книги Design for the Mind

Шаблон ретроспективной встречи этого проекта:

1 Обзор проекта:

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

2 Уроки:

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

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

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

Виктор Йокко
3 Что сработало?

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

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

«Опишите факторы, которые способствовали этим успехам.Вместо того, чтобы просто описывать успехи проекта, более ценно указать факторы, которые способствуют этим успехам, чтобы аналогичные проекты могли повторить успехи ».

— Визуальная парадигма

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

4 Возможности для улучшения:

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

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

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

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

5 Предметов для действий:

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

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

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

В заключение вашей ретроспективной встречи по проекту Smashing Magazine выделяет:

«Для любых проблем необходимо найти решения.Никто не должен оставлять ретроспективу с чувством, что у них не было возможности участвовать в полной мере. Ни одна проблема не должна оставаться нерешенной или, по крайней мере, без конкретных сроков, чтобы вы вернулись, чтобы ее решить ».

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

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

Важность ретроспективы проекта (часть 1) — Smashing Magazine

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

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

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

Определение целей и результатов

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

Что такое ретроспектива?

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

Больше после прыжка! Продолжить чтение ниже ↓

Навигация часто бывает слишком сложной и сложной в использовании. Давай исправим это! В книге « Designing The Perfect Navigation » Виталий исследует сотни практических примеров улучшенных мега-выпадающих меню , гамбургеров, каруселей, модальных окон и фильтров. Онлайн, а живут .31 августа и 1 сентября 2021 г.

Перейти в мастерскую ↬

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

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

Участие в ретроспективах помогает лучше настроить вашу команду.(Изображение: Викимедиа)

Что не является ретроспективой?

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

  • Ретроспективы не заменяют общение или действия, предпринятые для устранения проблем группы или проекта на момент возникновения.
  • Ретроспективы — не повод потратить час на то, чтобы жаловаться (хотя важно, чтобы во время сеанса кое-что выплеснулось).
  • Ретроспективы — это не возможность рассказать вашей команде, что они могли бы сделать лучше. В идеале вы должны активно тренировать свою команду на протяжении всего проекта.
  • Ретроспективы не должны отнимать у вас время и ресурсы. Я рекомендую от 60 до 90 минут на размышление, если у вас есть команда из 5 или 6 человек. Это дает каждому достаточно времени, чтобы обсудить каждую из общих тем, которые мы рассмотрим позже. Это также заставляет людей мудро распоряжаться временем, которое у них есть во время ретроспективы.

Зачем проводить ретроспективу?

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

Исследователи выявили множество преимуществ от участия групп разработчиков и разработчиков программного обеспечения в ретроспективе проектов (см. Ссылки внизу для ссылок).Некоторые из этих преимуществ включают:

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

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

Планирование ретроспективы

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

Я участвовал в ретроспективах, проводимых менеджерами проектов, руководителями команд или проектов и менеджерами. Назначьте кого-нибудь, кто имеет опыт ведения беседы. Если у вас есть член команды, обученный гибким методам, он, скорее всего, пройдет некоторое обучение по проведению ретроспектив. Независимо от того, кто проводит сеанс, они должны занимать нейтральную позицию по отношению ко всей информации, которую представляют члены команды. Они должны быть справедливыми в том, как проводить собрание.Они не должны быть влиятельными людьми, которые могут запугать любого члена команды, чтобы он не высказался.

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

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


Название и дата проекта
Что хорошо работает? Примечания
Мы все на одной волне с проделанной работой. Мы часто встречаемся внутри компании, чтобы обсудить, кто чем занимается. Мы постоянно обновляем наш список невыполненных спринтов.
Что не работает? Примечания
Клиент пожаловался, что связь не налажена. Нам дали несколько точек контакта (PoC) на стартовом совещании. У нас возникли проблемы с получением ответов от одного из них. Может поэтому.
Как мы можем улучшить? Примечания
Уменьшите количество людей, с которыми мы собираемся получить разрешение. Определите, с кем нужно связаться и о чем нам нужно с ними связаться. Нам нужно определить единый PoC для нашей команды и их команды. Клиент считает, что не вся его команда должна участвовать в нашем общении.

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

Проведение ретроспективы не требует больших ресурсов.(Изображение: StartupStockPhotos) (См. Большую версию)

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

Подготовка в качестве фасилитатора

Определите свой список участников; убедитесь, что все участники приглашены (даже удаленные люди!). Ваша ретроспектива хороша настолько, насколько хороши люди, которых вы включаете. Было бы более эффективно, если бы всех, кто был вовлечен в проект, пригласили присутствовать. Возможно, один дизайнер заменил другого на полпути проекта — пригласите их обоих.Вам будет полезно понять, как прошел переход, с точки зрения как дизайнера, который начал проект, так и того, кто его взял на себя. Более глубокое понимание неровностей на дороге принесет вам пользу, если вы включите людей, которые уникальным образом участвовали в процессе. Однако включение некоторых людей может не потребоваться, если их роль чрезвычайно ограничена.

Удаленный персонал важен для ретроспективы проекта. У этих членов команды уникальное видение.Вы захотите узнать, чувствовали ли они себя вовлеченными и активно взаимодействовали со своими коллегами на месте. Вы также захотите узнать, есть ли у них предложения по облегчению их жизни в качестве удаленного персонала. Точно так же ваш персонал на объекте должен иметь право голоса относительно того, каково это работать с удаленным персоналом, и любых предложений, которые у них есть для улучшения сотрудничества с удаленными членами команды. Мы часто включаем такие варианты видео, как WebEx или FaceTime, на iPad, чтобы наши удаленные сотрудники могли лучше присутствовать на ретроспективах.

Попросите вашу команду просмотреть свои записи и дать следующие данные:

  • Что прошло хорошо
    Например, «Хорошая связь между исследованиями, проектированием и разработкой на протяжении всего проекта».
  • Что не удавалось
    Например, «доработка результатов казалась поспешной на протяжении всего проекта».
  • Как это исправить
    Например, «Четко указывайте сроки на всем протяжении проекта; иметь частые проверки прогресса; вовремя проверять результаты, чтобы можно было внести изменения.”

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

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

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

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

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

Подготовка в качестве участника

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

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

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

Для проведения ретроспективы доступно множество ресурсов. Эстер Дерби предлагает пятиступенчатый подход к ретроспективе в Scrumpedia. Хотя основное внимание уделяется двухнедельной ретроспективе, вы можете использовать те же шаги для ретроспективы после проекта.Шаги Дерби включают в себя: (1) подготовить почву, (2) собрать данные, (3) получить идеи, (4) решить, что делать, и (5) закрыть ретроспективу.

Элиза Кейт представляет в блоге Lucid Meetings трехэтапный процесс: (1) проанализировать проект, (2) обсудить, что сработало, а что нет, и (3) планирование действий: определить конкретные способы улучшения будущей работы.

Справочник Нормана Керта по ретроспективе проектов

содержит четыре вопроса, которые помогут провести ретроспективу: (1) Что мы узнали? (2) Что мы должны сделать по-другому в следующий раз? (3) Что мы сделали хорошо? (4) Что до сих пор вызывает у нас недоумение?

Нет одного правильного способа сделать ретроспективу.Быстрый поиск в Google дает еще десятки статей о том, как проводить ретроспективу. Ниже я обсуждаю некоторые ключевые особенности, которые должна включать каждая ретроспектива.

Управление обсуждением

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

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

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

Создайте безопасную атмосферу для совместного использования

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

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

С другой стороны, если есть проблема, связанная с тем, что человек принимает решения, которые не сработали, ее уместно обсудить в группе. Вы можете, , подойти к таким ситуациям менее угрожающим образом, , обращаясь к группе, а не к отдельному человеку.Например, вместо того, чтобы сказать: «Виктор медлил с началом набора людей для участия в исследовании, поэтому мы отстали от графика», вы можете сказать: «Мы подумали, что было бы неплохо отложить идентификацию участников нашего исследования. , но это привело к тому, что мы отстали от графика ». Это позволяет в ходе обсуждения прийти к выводу, что лицо, отвечающее за набор персонала, должно быть более активным при составлении расписания в будущем.

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

Создать собственность

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

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

Документируйте все, даже если это говорит только один человек

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

Празднуйте добро

Каждый должен сказать что-то хорошее, даже если это просто «Эй, все живы!» В вашей команде наверняка есть разные личности. Вы помогаете создать позитивную атмосферу для всей группы, призывая людей к хорошо выполненной работе и поздравляя тех, кто добился успехов и достижений в ходе проекта. Вы также повышаете восприимчивость членов команды к критике, когда оставляете положительный отзыв в ретроспективе. Кто-нибудь получил повышение во время проекта? Празднуйте это.Кто-нибудь получил новый навык или инструмент? Празднуйте это. Найдите вещи, которые стоит отпраздновать.

Обсуди, что сработало хорошо

Вы хотите сначала хорошие новости или плохие новости? Я предпочитаю хорошие новости. Мы часто гораздо дольше обсуждаем, что не так хорошо работает в наших проектах. Вы не хотите терять время и не говорить о том, что сработало. Обсудите, что сработало, прежде чем обсуждать, что ваша команда могла бы сделать лучше.

Обсуди, что не сработало

Ты редко бываешь идеальным.Даже в хорошем проекте вы можете найти области, которые нужно улучшить. Часто вы обнаруживаете области вокруг общения, которые можно было бы настроить. В какой-то момент во время работавшего нормально проекта я созвал собрание, чтобы рассмотреть, как мы включаем результаты исследований в наши концепции дизайна. Мой управляющий директор сказал что-то вроде: «А теперь давайте послушаем, что говорит разработка». Я забыл пригласить на встречу кого-либо из разработчиков, поэтому ответа не последовало. На самом деле, я даже не подумал о необходимости включать разработку — мы ведь говорили о дизайне и исследованиях, верно? На этом этапе проекта я успокоился, забыв пригласить на встречу ключевых членов команды.Мы обсуждали, почему это произошло, и необходимость приглашать людей на нашу ретроспективу на протяжении всего проекта.

Определите конкретный путь к улучшению

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

Приходи к заключению

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

Пост-ретроспектива

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

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


Что сработало хорошо? Что не сработало? Конкретные шаги по улучшению

Ретроспективы становятся прекрасным источником данных для отслеживания прогресса команды.Активно напомните членам вашей команды о том, что было согласовано в ретроспективе, и попросите их предоставить доказательства того, что они выполнили все предложенные решения. Отслеживайте свои ретроспективы во времени , чтобы увидеть, переместится ли то, что было в столбце «Требуется улучшение», в конечном итоге или даже в столбец «Что сработало хорошо». Если вы видите, что одни и те же элементы продолжают попадать в столбец «Требуется улучшение», значит, ваши решения либо неэффективны, либо не реализуются.Создайте электронную таблицу с разными вкладками на основе выполненных проектов. Запишите результаты ретроспективы каждого проекта в отдельной вкладке. Это позволяет консолидировать ваши ретроспективы таким образом, чтобы упростить анализ прогресса.

Сохраните электронную таблицу отслеживания в хранилище , доступное для всех сотрудников. Еще одно преимущество отслеживания ретроспективы — это возможность успешно внедрять улучшения во всех проектах. В каждом проекте не всегда будут одни и те же члены команды.Когда вы отслеживаете ретроспективы, вы можете поделиться своими выводами с более широкой командой. Если решение проблемы в проекте A было успешным, вы можете попробовать реализовать то же решение, если увидите, что проблема всплывает в ретроспективе проекта B. Таким образом вам не придется изобретать велосипед. Точно так же вы можете избегать решений, которые не работают, для проблем, которые снова появятся в других проектах в будущем.

Отслеживание ретроспективы позволяет вам наблюдать за работой команды с течением времени. (Изображение: janjf93) (см. Большую версию)

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

Пример использования

: использование ретроспективы одной и той же команды в проектах за один год

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

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

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

  • Что сработало хорошо?
  • Что не сработало?
  • Какие конкретные способы мы можем улучшить нашу будущую работу?

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

пр.А


Что сработало хорошо? Что не сработало? Способы улучшения
Сеанс работы с клиентами в нашей студии Набор участников исследования начался слишком поздно.Мы полагались на клиента при наборе участников из-за деликатного характера их отношений с пользователями. • Подчеркните важность того, чтобы клиенты начинали набор персонала как можно скорее во время ознакомительной встречи.
• Напишите электронное письмо о найме и отправьте клиенту для использования сразу после вступительного совещания.
Результаты исследований легко интегрируются в концепции дизайна. Переход к визуальному дизайну был трудным. Потребности в визуальном дизайне были минимальными; мы ждали, чтобы определить визуального дизайнера, пока проект не был завершен наполовину. Ищите дополнительные возможности для привлечения клиентов в нашу студию.
Результаты оценки технологий и результаты исследований пользователей были представлены в отдельных разделах. (Предпочел бы, чтобы все исследования представлялись безупречно, а темы технической оценки согласовывались с темами исследований пользователей, где это возможно.) Технологии и исследования, чтобы лучше интегрировать результаты в окончательный отчет.

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

Мы также определили три конкретных проблемы, которые можно было бы лучше решить:

  • Мы полагались на клиента при наборе участников исследования из-за типов пользователей, к которым нам нужен был доступ. Когда проект стартовал, наш клиент еще не начал процесс набора участников.Это привело к задержке начала исследования в соответствии с первоначальным графиком.
  • Мы ограничили участие визуального дизайнера до тех пор, пока это не стало абсолютно необходимым. Это было не идеально — визуальный дизайнер не понимал мотивов принятия определенных дизайнерских решений, и чтобы все оказались на одной странице, потребовалось больше времени, что привело к личному разочарованию визуального дизайнера, назначенного для этого проекта.
  • Наша оценка технологии была представлена ​​отдельно от результатов нашего исследования, которые кажутся разрозненными.Это соответствовало тому, как мы традиционно сообщали об этих результатах. Однако мы чувствовали, что можем бросить вызов самим себе, чтобы развиваться.

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

пр.Б


Что сработало хорошо? Что не сработало? Способы улучшения
Сеанс работы с клиентами в нашей студии Набор участников исследования начался слишком поздно.Мы полагались на клиента при наборе участников из-за деликатного характера их отношений с пользователями. • Подчеркните важность начала набора клиентов во время телефонного звонка до начала работы.
• Напишите электронное письмо о наборе персонала и отправьте клиенту до начала встречи.
Плавный переход между всеми фазами и дисциплинами проекта. Результаты оценки технологий и результаты исследований пользователей были представлены вместе, но темы кажутся разрозненными. Технологические и исследовательские группы работают вместе на протяжении всего проекта, чтобы обеспечить согласованность тематик исследований.

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

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

  • Мы полагались на клиента при наборе участников исследования из-за типов пользователей, к которым нам нужен был доступ.Когда проект стартовал, наш клиент еще не начал процесс набора участников. Это привело к задержке начала исследования в соответствии с первоначальным графиком.

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

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

Мы улучшили эту проблему между проектами A и B, но не чувствовали, что решили ее полностью. Результаты оценки технологий были представлены вместе с пользовательскими исследованиями в разделе «Результаты исследований», но темы остались разными.

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

пр.С


Что сработало хорошо? Что не сработало? Способы улучшения
Сеанс работы с клиентами в нашей студии Каникулы сотрудников совпадали с основными встречами и датами. • Избегайте дублирования между отпусками членов команды и ключевыми датами проекта.
• Как можно скорее определите потенциальных заменителей отпуска, желательно в начале проекта или как только станет известно об отпуске.
Плавный переход между всеми фазами и дисциплинами проекта. Создайте и внедрите инструкции по обмену информацией во время предварительных звонков, чтобы будущие проекты принесли пользу.
Телефонный звонок перед стартом позволил решить проблемы, связанные с наймом пользователей. Продолжайте предварительные звонки.
Темы исследований, дизайна и технологий представлены безупречно. С самого начала продолжать привлекать технологическую группу к анализу исследований.

Проект C был тогда, когда наша команда действительно начала превращаться в гель. Это также ознаменовало шесть месяцев совместной работы в качестве стабильной основной команды. У нас было время узнать, как друг друга работают, и лучше друг друга поддержать. Мы смогли переместить обе проблемы, обозначенные как «не очень хорошо» в проекте B, в столбец «хорошо отработаны» в проекте C.

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

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

Заключение

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *