PI-планирование в SAFe: как несколько команд могут вместе работать по Agile над одним и тем же продуктом?

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

 

 

В первую очередь давайте разберемся, что такое SAFe – Scaled Agile Framework. В переводе с английского, это «масштабируемый гибкий фреймворк» – структура, которая позволяет применять принципы Agile сразу для нескольких команд.

Я не случайно добавила на слайд изображение слоеного пирога, потому что, по сути, SAFe объединяет в себе множество техник Agile.

 

 

Кратко напомню, что такое Agile:

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

• Когда мы работаем по Agile, у нас не может быть четкого фиксированного ТЗ – мы строим гипотезы, проводим эксперименты и корректируем содержание задач по итогам этих экспериментов.

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

• Agile предполагает тесное сотрудничество заказчиков и исполнителей – и без этого не работает.

 

 

На практике применение фреймворка SAFe и связанного с ним PI-планирования особенно полезно в следующих ситуациях:

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

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

• Когда взаимодействие между участниками слишком сложное. Мне однажды задали логичный вопрос про PI-планирование: «Зачем собирать в одном помещении сотню человек на два дня, если можно просто собрать руководителей каждой группы, все обсудить и договориться?» Но на практике, когда продукт действительно слишком сложный, простой разговор «по верхам» не решает проблему. Чтобы учесть мнение каждого, требуется множество взаимодействий – в такой ситуации нужны дополнительные процедуры.

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

 

 

Как я уже упоминала, фреймворк SAFe – это своего рода слоеный пирог.

• Сверху находится уровень портфеля предприятия.

• Чуть ниже – уровень крупного решения.

• За ним – базовый уровень, с которым мы сегодня и будем работать.

 

На базовом уровне:

• внизу находятся Agile-команды,

• а над ними – объединение команд или так называемый Agile Release Train.

Именно на базовом уровне вы можете увидеть те самые обещанные техники слоеного пирога Agile: Scrum, Kanban, дизайн-мышление, DevOps и т.д.

 

 

В результате работы над продуктом каждая команда делает небольшой набор спринтов, которые согласуются между собой и объединяются в программный инкремент (PI) – приращение программы.

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

 

 

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

 

 

Начнем мы с так называемой вводной части.

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

• Владелец бизнеса (или представитель топ-менеджмента) представляет бизнес-контекст – что мы делаем и какие цели перед нами стоят.

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

• Архитектор рассказывает о техническом видении и архитектуре решения.

• RTE – Релиз-трейн-инженер (по сути – Скрам-мастер Скрам-мастеров) объясняет, как будет происходить процесс планирования.

 

 

Давайте разберемся, какой продукт нам предстоит создать.

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

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

 

 

Теперь давайте послушаем владельца продукта – что он считает главной целью нашего парка Руслэнд. Есть несколько вариантов тематики будущего парка:

• Просветительская – знакомство с русской культурой.

• Развлекательная – площадка для отдыха и развлечений

• Парк ужасов по русским сказкам.

• Или музыкальный парк, посвященный традиционным инструментам или народной музыке.

Ответ владельца продукта: «Мы хотим зарабатывать много денег. Поэтому наш фокус – семейный развлекательный парк, где будет весело, интересно и увлекательно для всех возрастов. Конечно, элементы просвещения и отдельные фрагменты страшных сказок там тоже будут, но скорее как “встроенные” в развлекательный формат. И музыкальное сопровождение будет – с гуслями и прочими национально узнаваемыми инструментами и мотивами. Но главный фокус все-таки на развлечения».

 

 

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

• Обратите внимание, что территория разделена на зоны с различной тематикой: например, «индейцы», «космическая гора» или «пираты Карибского моря».

• Но при этом есть и общие элементы, которые проходят через весь парк, например:

  • Круговая железная дорога, которая проходит через все зоны.

  • Центральная площадь, к которой ведут дороги из каждой части парка.

  • Река, которая тоже протекает через все территории парка.

То же самое будет и у нас.

Задача каждой команды будет:

• С одной стороны, спроектировать свой кусочек парка – вы выберете определенную русскую сказку и будете ее проектировать. Эту часть задачи команда может сделать более-менее автономно.

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

 

 

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

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

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

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

  • Первая команда будет строить речную систему, проходящую через весь парк.

  • Вторая команда – железную дорогу с декоративными водопадами, соединяющую ключевые зоны.

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

  • Четвертая команда – ресторан с разнообразным меню, подходящий и взрослым, и детям.

Задача участников – придумать, как это сделать максимально антуражно.

 

 

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

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

 

 

Архитектор должен выбрать архитектурный стиль парка. Предлагаются три варианта:

• Деревянное зодчество.

• Фантастические замки.

• Современный техно-стиль.

Очевидно, что мы выбираем первый вариант. У нас – Руслэнд, поэтому отдаем предпочтение деревянному зодчеству.

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

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

 

 

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

• Сначала каждая команда определится с теми фичами, которые будет делать.

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

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

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

• И завершится все кратким подведением итогов и ретроспективой.

 

 

Преимущество PI-планирования в том, что на выходе:

• У каждой команды появится некий набор SMART-целей – понимание того, что конкретно она делает в рамках ближайшего приращения программы.

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

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

 

 

Итого, в процессе PI-планирования каждой команде нужно:

• Сформулировать цели команды на программу.

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

• Убедиться, что в конце каждого спринта у команды получается результат с ценностью для заказчика – так называемый MVP. Например, если нужно построить отель, с точки зрения работы по Agile мы не можем в первом спринте его только спроектировать, во втором – вырыть котлован, в третьем – построить стены, а в четвёртом – заняться внутренней отделкой. При работе по Agile в первом спринте нам уже нужно поставить палатки – чтобы было где остановиться. Во втором – построить временное жильё. В третьем – первый корпус отеля. И так далее. Т.е. задача разбивается на маленькие кусочки, имеющие ценность для заказчика, и в конце каждого спринта выдается результат. Аналогичный подход используется и в разработке.

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

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

• А красные стикеры – это зависимости от других команд. Сессия PI-планирования вообще проводится именно потому, что у каждой команды есть задачи, требующие взаимодействия с другими командами. Если бы вы могли сами спланировать свой уголочек Руслэнда, и никто бы ни от кого не зависел, нам не обязательно было бы собираться и два дня условно проводить PI-планирование.

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

 

 

Приведу пример, чтобы вам было понятнее. Допустим, команда выбрала сказку «Золотая рыбка», и ей дали в работу две фичи:

• Построить бассейн с рыбками – стикеры по этой фиче будут голубого цвета.

• Организовать речную прогулку по Руслэнду – стикеры по этой фиче будут зеленого цвета

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

 

 

Далее нужно разделить фичи на конкретные задачи так, чтобы в конце каждого спринта получился MVP – Minimum Viable Product – минимально жизнеспособный продукт. Тогда четыре спринта по строительству бассейна на программу могут выглядеть так:

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

• Во втором спринте добавляем в бассейн рыбу.

• В третьем спринте организуем в бассейне рыбалку.

• В четвертом – мастер-класс по плетению сетей.

И аналогично с речной прогулкой:

• Сначала канал прокладывается только по зоне сказки «Золотая рыбка» и заодно составляется общая карта канала по всей территории.

• Потом канал расширяется на следующую зону и по нему запускаются лодочки,

• Потом канал расширяется на остальные зоны.

• И к нему добавляются дополнительные ответвления.

 

 

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

 

 

А красным цветом обозначаются пересечения с другими командами.

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

 

 

Получается, что в результате PI-планирования у нас:

• расписаны фичи по задачам;

• обозначены ключевые вехи;

• выявлены зависимости;

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

Проговорим еще раз:

• Определяете сказку.

• Формулируете цель программы.

• Детализируете фичи.

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

• Обозначаете ключевые вехи (желтые стикеры)

• Выявляете зависимости (красные стикеры) – где нужно взаимодействие с другими.

 

 

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

• Скрам-мастер – тот, кто ведет дискуссию. Он не принимает решения, а направляет, модерирует и следит за временем.

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

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

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

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

 

 

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

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

 

 

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

Обратите внимание, что на доске пять итераций:

• Первые четыре – это рабочие спринты, в которых команды планируют выполнение своей работы.

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

Первая команда представляет сказку «Гуси-лебеди»:

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

В первом спринте сделаем фотозону с Бабой Ягой, лес из ив, а также вагон в стилистике сказки. Во втором спринте завершим участок дороги и оформим «Кинотеатр под ивами». А на третьем и четвертом спринте сделаем «Кисельный берег» и «Яблоневый сад».

У нас есть зависимость от команды, отвечающей за питание. Например, есть «Печка», где должны продаваться пирожки. И «Кисельный берег», где должен продаваться кисель. Эти детали важно заранее обсудить с командой, отвечающей за ресторан и приготовление блюд, чтобы избежать несостыковок.

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

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

 

 

Вторая команда представляет сказку «Колобок».

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

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

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

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

Третья команда – отвечает за «Сказку о Царе Салтане».

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

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

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

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

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

Четвертая команда представляет сказку «По щучьему велению».

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

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

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

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

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

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

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

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

Как отметил Асхат Уразбаев: SAFe – это принуждение к коммуникации. Пока все команды не согласятся, что план реалистичен – проект не стартует.

Большинство конфликтов возникает из-за недопонимания – из-за того, что информации недостаточно. В большинстве случаев, мы можем разрулить конфликт, просто уточнив ситуацию. А если нет, нужно разобраться, что можно сделать. Конечно, команды сами решают, КАК они будут делать работу. Но ЧТО именно они будут делать, все-таки спускается сверху.

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

 

 

Переходим ко второму обсуждению. На этом этапе команды:

• уточняют цели;

• вносят исправления, если нужно;

• и продумывают риски – во время второго обсуждения команда должна подумать, какие у нее есть риски.

 

 

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

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

 

 

На листах флипчарта разделите пространство на 4 части – по статусу рисков:

• Риск устранён или неактуален – меры уже приняты, вопрос закрыт.

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

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

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

 

 

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

Если рисков получилось много – расставьте приоритеты: что критично, а что можно просто отслеживать.

 

 

Пример анализа рисков из проекта «Золотая рыбка»:

• Риск: дети могут упасть в канал.
  Решение: построить ограждение -> риск снят.

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

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

• Риск: реакция зоозащитников на ловлю рыбы.
  Решение: пока нет -> риск принят.

В результате каждая команда должна:

• Обсудить все выявленные риски.

• Разнести их по 4 категориям: риск устранен (не актуален), у риска есть владелец, риск снижен, риск принят.

• Выделить 1-2 ключевых риска, по которым непонятно, что делать дальше,

• Представить их на общем обсуждении.

Примеры анализа ключевых рисков от команд:

• Риск от команды «Колобок»: в лабиринте ужасов не запланированы туалеты, что может сильно повлиять на удобство гостей. Предлагается устранить этот риск через установку туалетов на входах/выходах в каждой зоне.

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

• Риск от команды «Гуси-лебеди» – высокий поток клиентов на железной дороге. Предлагается передать этот риск на уровень топ-менеджмента.

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

Главная цель упражнения – не детально разобрать каждый риск, а научиться:

• относить их к категориям;

• определять ответственных;

• разделять управляемые и неуправляемые факторы.

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

 

 

Переходим к финальному этапу – оценим реалистичность плана, насколько он выполним.

 

 

Голосуем с помощью поднятых пальцев:

• 5 пальцев – полностью согласен, что реализация возможна, всё понятно;

• 4 пальца – в целом согласен, есть небольшие сомнения, но план рабочий;

• 3 пальца – средняя уверенность, вижу плюсы и минусы, но готов согласиться;

• 2 пальца – скорее не согласен, вижу существенные проблемы;

• 1 палец – категорически не согласен, считаю план нереалистичным.

 

 

Голосование проходит в три этапа:

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

• Чтобы тебя услышали в повторном голосовании, надо уже поднять один палец. Если ты поднял два пальца, значит, ты несогласен, но это терпимо. Если совсем нетерпимо – поднимаешь один палец, и тебе еще раз предоставляется слово, чтобы ты мог озвучить то, что ты думаешь.

• А дальше, если ты никого не убедил, и все считают, что можно идти дальше, проводится последнее голосование – в этом случае решение принимается уже большинством голосов. И даже если кто-то категорически против, но большинство согласно, можно идти дальше.

 

 

У «консенсуса пяти пальцев» по сравнению с обычным голосованием есть два преимущества:

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

• Несколько несогласных не блокируют весь процесс – решение все равно принимает большинство.

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

• 3-4-5 пальцев – концепция реалистична;

• 1-2 пальца – есть серьезные сомнения

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

«Я считаю, что проблема с рестораном не решена, так как парк аттракционов планируется огромных размеров. Голодные люди напишут негативные отзывы, упадет NPS, и бизнес-владелец потратит деньги впустую. Это выглядит как правомерный риск, и пока нет ресторана – запускаться нельзя».

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

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

 

 

Этап называется «Переделка планов, если нужно». Обратите внимание – у каждого этапа PI-планирования заранее предусмотрен тайминг. Но на этот этап тайминга нет – он занимает столько времени, сколько нужно. И действительно возможна ситуация, что после второго обсуждения опять нужно что-то доработать.

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

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

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.