Ретроспектива проекта – Ретроспектива проекта как инструмент управления идеологией компании

Ретроспектива проекта как инструмент управления идеологией компании

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

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

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

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

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

Регулярное проведение ретроспективы помогает:

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

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

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

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

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

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

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

Очень важна роль ведущего. Хотите придать ускорение и качество последующим проектам?

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

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

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

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

Например, это могут быть:

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

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

больше вам потребуется времени.

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

2. Возможный сценарий ретроспективы проекта

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

Шаг 2. Раздайте каждому участнику стикеры (если Вы используете обычную бумагу) или половинки А4 (если используете клейкие стены) и черные маркеры. Попросите записать, какие события общественной и политической жизни оказали влияние на проект, итоги которого Вы подводите. Что влияло на проект? Дайте на эту работу минут 5-7.

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

Шаг 4. Возьмите клейкую стену или рулон миллиметровки или белой бумаги и нарисуйте внизу линию времени.

Обсудите все вместе основные вехи проекта, переломные моменты и ключевые события. Нанесите их на линию времени.

Шаг 5. Далее пройдите все вместе по каждому этапу проекта зафиксировав на линии времени события, людей, знания, полученные в ходе проекта. На отдельных спикерах другого цвета или формы фиксируйте уроки проекта. Дайте каждому участнику по 7 меток (или маленьких стикеров оранжевого цвета) и попросите отметить те события, которые им приятно вспоминать. Затем дайте каждому синие метки для голосования, и попросите отметить то что их расстраивало в ходе проекта. Красными метками попросите отметить события, которые были безумием. Обсудите получившиеся результаты.

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

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

О чём важно помнить?

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

Что почитать?

1. Project Retrospectives. A handbook for team reviews. Norman R. Kerth

2. Agile retrospectives: making good team great. Esther Derby, Diama Larsen

3. Advanced Facilitation Strategies. Ingrid Benz

Декабрь и январь — лучшее время для энергетизации сотрудников подведением итогов и формирования небезразличия к целям следующего года.

Используете ли Вы эту уникальную возможность?

rulesplay.ru

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

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

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

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

Мы подводим итоги во всех сферах жизни. Работа над проектами в компаниях не является исключением. Но вот всегда ли этот процесс проходит правильно? Всегда ли заостряется внимание на положительных моментах работы над проектом?

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

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

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

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

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

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

Команда может практиковать и метод “эстафетной палочки”, когда ведущий меняется от ретроспективы к ретроспективе.

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

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

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

1 шаг: определите цели ретроспективы

Цель должна ответить на вопрос: какую ценность мы должны получить, чтобы оправдать инвестицию времени?

Примерный список целей:

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

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

2 шаг: раздайте стикеры и маркеры

Раздайте сотрудникам цветные стикеры, маркеры и фломастеры. Они должны записать, что повлияло на этот проект из общественной и политической жизни, почему он стал именно таким. На это задание отводится 5-7 минут.

Шаг 3: обсудите ключевых людей

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

Шаг 4: нарисуйте линию времени

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

Шаг 5: Зафиксируйте положительные и отрицательные моменты

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

Шаг 6: подведите итоги

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

О чем стоит помнить:

• • Такой анализ надо проводить после каждого проекта;
  • Материалы бесед становятся ресурсом долговременного и постоянного обучения и корпоративных традиций;
  • Это самый рабочий способ создания корпоративной базы знаний;
  • Хороший способ создать рабочую команду с общим фокусом;
  • Ретроспектива проекта помогает вовлекать и мотивировать;
  • И еще она фокусирует на процессе командного взаимодействия.

Читайте также:

donskih.ru

Гибкие методологии. Ретроспектива / Хабр

Ретроспектива (от лат. retrospectare, «взгляд назад») — взгляд в прошлое, обозрение того, что было в прошлом.

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

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

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

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

Как проходит ретроспектива?
Можно выделить несколько этапов:
1. Опрос мнений(что хорошего и что плохого было в прошедшей итерации?) и фиксирование их на доске
2. Голосование
3. Выделение и обсуждение основных злободневных проблем (Набравших большинство голосов)
4. Определение путей решения выбранных проблем, ответственных за них
5. Фиксирование достигнутых результатов (Обсуждение задач, которые решались по результатам прошлых ретроспектив)

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

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

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

Кстати говоря, количество пунктов, их «серьезность» и превалирование какого-либо раздела, довольно четко показывает «сформированность» команды, «поставленность» процессов и т.п.

Голосование может проходить разными способами. Можно выявлять «приоритерезацию» задачи для человека (поднятие 5, 4, 3 пальцев и т.д.). Наша команда избрала путь ограничения количества голосов. Каждый может голосовать только за треть пунктов. (Если в разделе «хорошо» 12 пунктов, то у человека 4 голоса и значит поднять руку и проголосовать он может за любые 4 пункта из 12).
Ведущий подсчитывает голоса и пишет цифру напротив каждого пункта. Выделяются самые «популярные» темы в каждом из разделов. Обычно их по 3-4, это и есть самые волнующие команду проблемы и отмеченные всеми «приятности».
(Вот тут-то и понадобятся цветные маркеры – отделить цифры голосов от номеров пунктов и для обводки).
Пункты из раздела «хорошо» просто фиксируются в отчете по ретроспективам. (Команда должна помнить свои достижения!)
А вот с пунктами из раздела «плохо» надо еще поработать. Очень хорошо, если команда обсудив, придумает решение этим проблемам, или хотя бы начальный путь, по которому необходимо двигаться для решения. Здесь же выбирается ответственный за задачу, который должен сделать все возможно для ее решения.
Мы для удобства отслеживания задач по ретроспективам заводим их в Jira и поступаем как с обычными задачами по проектам.

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

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

habr.com

Ретроспектива | Agile.by

После Agile Practitioners Gathering я стал более широко воспринимать тему ретроспективы.

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

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

Очевидные цели ретроспективы:

• Собрать информацию, получить обратную связь
• Что-то улучшить на основе полученной информации

Звучит красиво, но на практике это не так легко. Основными проблемами являются:

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

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

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

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

• Преимущества с разных точек зрения
• Как проводить
• Различные инструменты и подходы
• Ретроспектива на более высоком уровне

Преимущества с различных точек зрения

С точки зрения компании:

• Получение информации и обратной связи
• Обучение и улучшение
• Создание открытой атмосферы (хотя не для всех компаний это преимущество)
• Поощрение людей к действию и активности

С точки зрения менеджера проекта:

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

И, наконец, преимущества с точки зрения команды:

• Возможность быть услышанным
• Подстройка процесса под реальные нужды, устранение лишних вещей

Как проводить

Для ретроспективы нужна хорошо продуманная организация. Я бы выделил 3 области:

• Подготовка
• Проведение
• Реализация решений

Подготовка

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

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

Проведение

Для ретроспективы обязательно нужен ведущий (фасилитатор). Это может быть член команды, Scrum master, человек из другой команды или даже профессиональный ведущий. Периодически можно менять фасилитатора.

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

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

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

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

В результате ретроспективы у нас есть:

• Список работающих практик
• Список проблем
• Action log с конкретными действиями и ответственными людьми

Реализация решений

Ретроспектива без реальных изменений – это просто трата времени. Action log помогает сконцентрироваться именно на действиях, а не просто на разговорах.

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

Различные инструменты и подходы

Существует большое количество инструментов и форматов для проведения ретроспективы. Рассмотрим только некоторые:

• What went well/What could be improved
• Keep this/Ongoing problems/Try this/
• Bug fix analysis/Knowledge sharing/Fix process/Roles/Practices
• Starfish
• Timeline

What went well/What could be improved

Это один из самых простых форматов. Вопрос “What went well?” помогает выявить хорошо работающие элементы. А второй вопрос направлен на выявление проблем. Ответами на второй вопрос являются проблемы, но формулировка подчеркивает конструктивный подход.

Keep this/Ongoing problems/Try this

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

Starfish

Этот набор вопросов основан на starfish диаграмме.

Starfish diagram

• Start doing – что нужно начать делать (например, регулярный peer code review)
• Stop doing – что нужно прекратить делать (например, собирать бесполезные метрики)
• Continue doing – это хорошо работает, нужно сохранить
• More – этим вещам нужно уделять больше внимания (времени)
• Less – этим вещам нужно уделять меньше внимания (времени)

Bug fix analysis/Knowledge sharing/Fix process/Roles/Practices

Этот вариант предложил Владимир Лешкевич.

Во время bug fix analysis исследуются допущенные ошибки и как их не повторять. Knowledge sharing – knowledge sharing :-). В рамках фазы Fix process анализируется процесс – убираются или добавляются роли и практики.

Timeline

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

Есть несколько подходов к построению timeline – в течение спринта или в начале ретроспективы. Первый позволяет не забыть события, но второй подход проще.

Борис Лебеда предложил вариант с black box’ом – в комнате команды ставится ящик, в который можно бросать заметки с событиями. На ретроспективе все эти заметки достаются, сортируются, выкидываются малозначительные – и получаем набор фактов.

Ретроспектива на более высоком уровне

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

Можно проводить вертикальную ретроспективу (спасибо Юре Шиляеву за идею), включающую заинтересованных лиц с разных уровней (например, команда + division manager, или менеджеры проектов + несколько разработчиков + division manager + CEO). Это облегчает общение между уровнями. Но стоит учитывать психологический аспект – если команда на уровне «performing», она сможет достаточно эффективно проводить такие ретроспективы, члены менее «зрелой» команды могут просто замолчать проблемы. В случае многоуровневых ретроспектив правильная организация обсуждения еще более важна.

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

Это долговременный инструмент

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

agile.by

как и зачем ее проводить? / Блог компании ScrumTrek / Хабр

Проведение ретроспектив – это активность, которую каждая agile-команда проводит для того, чтобы решать свои проблемы. Что такое ретроспектива? Это регулярная встреча, на которой команда обсуждает свой рабочий процесс и что-то в нем меняет.

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

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

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

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

Тем не менее, существуют такие вещи как good practice или best practice. Это практики, которые многие используют и которые многим помогают. Возьмем, например, code review: хорошая это практика или плохая? Одним командам она помогает. Другие пытаются ее использовать, и ничего хорошего из этого не выходит. Так происходит потому, что эта конкретная практика, не хороша и не плоха как таковая: ее можно оценить только в контексте конкретной команды и ситуации.

Хотя бы поэтому невозможно сказать заранее, даст она какое-то преимущество или нет. Сode review – это один пример. На самом деле этот эффект характерен для любой практики – никогда нельзя знать заранее, насколько она будет эффективна в той или иной ситуации.

Цели и результаты

В основе ретроспективы лежит концепция цикла Деминга, PDCA (англ. Plan-Do-Check-Act). Цель ретроспективы – к ее окончанию получить план изменений. Но важно понимать, что это не план окончательных изменений в процессе – это план эксперимента на ближайший период. Мы что-то пробуем, а потом смотрим, что из этого вышло, и на основании этого принимаем решение.

Цикл Деминга: Plan – запланируй, Do – выполни, Check – посмотри, что получилось, Act – прими какие-то дальнейшие решения, реши, что дальше делать. Ретроспектива должна проходить именно по этому циклу. Собственно, сама ретроспектива – это стадия Plan.

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

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

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

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

Какие бывают ретроспективы?

Вообще ретроспективы разумно подразделять на несколько типов:

• ретроспектива в самом общем смысле слова;
• ретроспектива по качеству;
• ретроспектива по проблемам;
• ретроспектива по какому-либо отдельно взятому вопросу.

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

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

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

В чем проблема?

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

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

Еще одна дисфункция – когда на ретроспективе говорит в основном кто-то один или 2-3 человека, а все остальные сидят и молчат. На самом деле этим людям есть, что сказать. Просто, если все внимание на себя забирает, к примеру, лидер команды, он начинает доминировать, а остальные просто слушают.

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

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

Формат ретроспективы: наши предложения

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

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

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

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

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

После обсуждения плюсов, минусов и идей команда переходит к составлению плана, куда попадают не просто результаты обсуждения, а (как уже было отмечено) конкретные действия («Выполнить…», «Обсудить…», «Сформировать…») или правила («Задачу Х выполнять с использованием подхода Y»). Не стоит при этом пытаться выработать пути решения всех возможных проблем команды – для эффективной работы на следующей итерации достаточно плана из 3-6 пунктов. Слишком объемный план может в итоге оказаться невыполним и только демотивирует команду.

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

habr.com

Ретроспектива проекта. Норм Керт | Жизнь — это движение! А тестирование

Ссылка на книгу (издательство «Альпина Паблишер»).

Мои выдержки из книги:
Если ретроспектива приводит к одним и тем же рекомендациям — выделите больше времени!

Отличная книга о том, как проводить ретроспективу! Единственный минус — описывается ретроспектива, проходящая раз в полгода-год по завершении проекта, а не маленькой итерации. А хочется улучшать ежемесячные ретроспективы, проходящие в Agile-командах. И такая книжка как раз на подходе! Следующая книга от издательства Дмитрия Лазарева — «Agile Ретроспектива», как раз о маленьких и частых встречах. Станьте соиздателем и получите книгу одним из первых!

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

Можно, конечно, фигачить проекты один за другим. «Нам некогда размышлять, что можно сделать лучше, сроки поджимают!»

Стоит ли ожидать от такой команды хорошего качества? Врядли.

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

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

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

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

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

Основная установка Керта

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

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

« … большинство ритуалов ретроспективы, в которых я участвовала, имели один недостаток: они превращались в сессии жалоб, а не в обучающие сессии, и в результате этого новая информация не анализировалась глубоко (а то ею и вовсе пренебрегали) и не было ощущения, что эта информация будет как-то учтена при выполнении последующих проектов» ©

Вот оно! Ретроспектива — это не сессия жалоб! Пожалуй, самая полезная цитата из книжки. Я бывала на «сессиях жалоб», поэтому меня это так затронуло. Вот оно, что самое главное, научиться извлекать пользу, уроки, опыт. Без жалоб и обвинений. Это звучит разумно, но иногда этому сложно следовать. Особенно когда ретроспектива внедряется впервые в компании. Очень важно все сделать правильно, чтобы у участников не осталось негативного впечатления!

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

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

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

• Если кто-то держит кружку, только он может говорить.

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

А еще очень зацепила еще одна история из жизни. Норман Керт рассказывает о том, что тратит на ретроспективу проекта 3-4 дня. Когда-то он пробовал ужиматься до 2 дней, но понял, что это неэффективно, пользы от такой ретроспективы нет. Поэтому он или проводит полную или отказывается проводить вообще.

Так как я работаю в Agile-команде, фраза «3 дня на ретроспективу» вызывает скепсис, раз в год это ок, но раз в месяц… А потом я прочитала этот отрывок и переосмыслила выделяемое время… Пожалуй, иногда лучше немного подольше «покопаться в истоках», чем проскочить дальше, чтобы ретро не занимала много времени.

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

• Конкурс артефактов — каждый член команды приносит некий артефакт и рассказывает его историю. А в конце выдаются призы-шоколадки за номинации «самый необычный артефакт» и «наибольшее количество артефактов». Артефакты бывают самые разные — от первоначального плана работ до коробки из-под пиццы, на которой рисовали диаграммы. Упражнение помогает узнать о проекте то, чего вы еще не знали, посмотреть на него с новой строны.
• Построение линии времени — рисуем линию и каждый участник лепит на ней стикеры о событиях, которые считает значимыми. Тут важно, как во время мозгового штурма — действовать молча и не критиковать. Считает человек исправление мелкого бага значимым — пусть висит!
• Поиск золота — изучаем линию времени, ищем там умные мысли и идеи. Вспоминаем, что было хорошо и закрепляем полученный опыт. Изучаем подробнее, что было плохо.

При поиске золота создаем 5 флипчартов и заполняем их:

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

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

Хочется еще похвастаться тем, что я — соавтор книги! 

Рекомендуемая литература

Норман Керт в каждой главе рекомендовал литературу. Привожу ее список с комментариями автора:

The Adult Learner: A Neglected Species, Malcolm Knowles— В этом исследовании Ноулз обеспечивает теоритическую основу для упражнения «Конкурс артефактов», которое изучает способы обучения взрослых Creating Community Anywhere, Carolyn Shaffer — В этой книге описывается создание сообщества методом обобщения опыта — с помощью рассказывания историй и обмена артефактами. The Way of the Storyteller, Ruth Sawyer — Сторителлинг во всей его мощи, как проверенный временем способ обучения и обмена опытом. Please Understand Me: Character and Temperament Types, David Keirsey & Marilyn Bates — Теория типов предпочтений является мощным инструментом фасилитатора, и это четко отражено в данной работе.  Gifts Differing, Isabel Briggs Myers — Это основополагающая работа, которую необходимо прочитать всем фасилитаторам. Quality Software Management, Gerald M. Weinberg — В серии книг Вайнберга есть много ценной информации о типах и темпераментах. Особенно рекомендую прочесть приложение F в томе 4, которое кратко, но четко расставляет все по своим местам.

The New Peoplemaking, Virginia Satir — Написанная для ленивых людей, работа Сатир обеспечивает хорошее введение в тему правил м позиции в коммуникации.

The Satir Model: Family Therapy and Beyond, Virginia Satir — Эта книга предназначена для специалистов в области терапии, но она может оказаться весьма полезной и для фасилитаторов. В главах 3 и 4 приводится более подробное описание механизмов достижение конгруэнтности, чем в The New Peoplemaking.

What Did You Say?: The Art of Giving and Receiving Feedback, Charles N. Seashore, Edith Whitfield Seashore, Gerald M. Weinberg — Эта увлекательная книга исследует исскуство давать и получать обратную связь, в ней изгалается теория, на основе которой и разработано упражнение «Сессия без менеджеров».

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

Rules for Radicals: A Practical Primer for Realistic Radicals, Saul D. Alinsky  (Author) — Хотя эта книга не научит человека, как стать активистом, Алински в ней рассматривает способы, как направить группу активистов к общей цели. На протяжении всей своей профессиональной деятельности Алински помогал создавать профсоюзы и имел отношение к разоичным активистким акциям. Его книга содежрит мудрые советы для создания культуры, которая поможет активистам достичь своей цели.

…. И многие многие другие  Там таких книг еще примерно столько же, дальше уже смотрите в оригинале!

PS — Добавила книгу в общий список прочитанных мною книг.

okiseleva.blogspot.com

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

05.12.2018 Автор:Хайруллин Тахир

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

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

Для чего такую сессию проводят?

• Зафиксировать коллективную мудрость: что на самом деле произошло?
• Извлечь уроки: чему мы научились на этом проекте?
• Усовершенствовать процессы: что мы можем сделать в следующий раз по другому, чтобы проект пошел быстрее и/или с меньшими затратами?
• Собрать данные о трудозатратах: сколько времени на самом деле занимают отдельные задачи проекта?

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

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

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

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

Кейс: в декабре/январе многие компании проводят ретроспективы уходящего года и стратегические сессии по планированию года следующего.

Что почитать?

• Книга Норма Керна — Ретроспектива проекта.
• Agile ретроспектива

Мы готовы бесплатно провести для вашей команды диагностическую сессию/тренинг по командообразованию «5 уровней культуры».
Контакты: тел. 8(960)76-444-13, [email protected], https://fb.com/axyst

www.axyst.ru