SAFe для проектных менеджеров #1

Часть 1: Место проектов в SAFe

SAFe – один из наиболее популярных в мире подходов для организации работы гибкой компании. Его преимущество перед другими методами состоит в следующем:

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

В минимальном виде SAFe выглядит как уровни Team + Program. Уровни Portfolio и Large Solution опциональны в зависимости от потребностей организации. В этой статье мы не будем рассматривать уровень Large Solution и сконцентрируемся на трёх основных.

Командный уровень

На уровне команд SAFe придерживается базовых принципов гибкой разработки, описанных в Agile-манифесте и поддерживает итеративно-инкрементальную разработку по фреймворку Scrum или методу Kanban. Команды итеративно разрабатывают элементы продукта двухнедельными итерациями (спринтами) и проводят демонстрации результатов своей работы и ретроспективу.

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

Программный уровень

Уровень программы является ключевым как со стороны бизнеса, так и с точки зрения координации. На этом уровне все ресурсы, команды, заинтересованные лица кооперируются вокруг одной важной цели, чаще всего представляющую собой поток создания ценности (Value Stream) или продукт. Синхронизируют свою работу команды при помощи совместных сессий планирования (Program Increment Planning) в начале каждого квартала и демонстрации интегрированного инкремента продукта (System Demos) каждые 2 недели и ретроспективы (Inspect & Adapt) в конце каждого квартала.

Соответственно, все роли и процессы ориентированы на поставку ценных элементов функциональности. Метафорой этого процесса является “Поезд” (Agile Release Train).

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

Управляет «Поездом», соответственно, «Машинист» (Release Train Engineer). Он коучит весь «экипаж» поезда для повышения эффективности работы, взаимодействует с заинтересованными сторонами, фасилитирует общие собрания поезда поставки. Он не начальник, он лидер этого поезда. Release Train Engineer больше всего похож на Scrum-мастера, но отвечающего не за одну, а за много команд и их взаимодействие между собой. В терминах PMI «Машинист» соответствует Менеджеру программы по уровню ответственности и исполняемым функциям (The PM role in a lean and agile world).

У поезда также есть главные «пассажиры» –  Представители бизнеса (Business Owners). Это основные заинтересованные лица, которые отвечают за финансовые показатели Поезда. Business Owners – это руководители, которые будут получать выгоду от создаваемого решения, пользоваться им или продавать его.

Управляет продуктом и владеет бэклогом поезда команда Продуктового менеджмента (Product Management). В неё входят Владельцы продуктов отдельных команд, а также Продуктовые менеджеры. Они выявляют потребности клиентов, формируют дорожную карту и приоритезируют элементы функциональности. Говоря простыми словами, Представители бизнеса ставят цели, а команда Продуктового менеджмента стараются их достичь силами команд.

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

Уровень Портфеля

Цель портфельного уровня – согласование стратегии компании с реализацией портфеля за счёт организации процессов вокруг потоков создания ценности. Этот уровень появляется, если у организации несколько потоков создания ценности.

Портфель в SAFe состоит из Потоков создания ценности. Это могут быть продукты или направления деятельности организации. На этом уровне определяется стратегия инвестирования, бюджеты и показатели эффективности. Также на этом уровне реализуется функция принятия решения самого высокого уровня – портфельное управление (Lean Portfolio Management). И хотя глядя на схему может показаться, что Менеджер портфеля  это некая отдельная роль, но это не так. На самом деле это группа функций, исполняемая людьми, которые могут также исполнять другие высокоуровневые роли в организации.

Корпоративный архитектор (Enterprise Architect) принимает решения относительно архитектуры всех систем в компании и их взаимодействия, для их гармоничного взаимодействия внутри организации.

«Проекты» в SAFe

Как можно заметить из схемы, роли проектного менеджера в SAFe нет, как и отдельного уровня проектов. Все бизнес инициативы связанные с созданием ценности реализуются в рамках «Поездов», уже существующих или созданных под инициативу.

Как же тогда в организациях, практикующих SAFe, реализуются инициативы по автоматизации, внедрению новых систем, затрагивающих всю организацию и многие «Поезда»? Для таких случаев в SAFe существует понятие Эпика (Epic). И он больше всего похож на классический проект.

Если возникает такая необходимость, Владелец эпика (Epic Owner) определяет описание Эпика и его Минимальный Жизнеспособный Продукт (Minimum Viable Product). Затем он взаимодействует напрямую с заинтересованными сторонами и «Машинистами» соответствующих «Поездов» для реализации Эпика.

Главное отличие от классического проекта в том, что разработка Эпика ведётся итеративно-инкрементально, а фокус функций Владельца Эпика смещается с управления командой на координацию взаимодействия с командами разных «Поездов». Реализация Эпика, как и у классического проекта, ограничена во времени. В отличие от потока создания ценности, развитие которого, как правило не останавливается.

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

Что делать менеджерам проектов дальше?

Цифровизация, ускорение запуска инноваций, продолжающийся рост роли Интернета привели к тому, что уровень неопределённости бизнеса в целом и проектов в частности вырос. И предпосылок для замедления этого роста не наблюдается. Технологии, потребности, конкурентное окружение и прочие факторы меняются не только постоянно, но и с высокой скоростью. Со временем всё меньше организаций будут предпочитать классическое проектное управление гибким подходам в качестве инструмента развития своего бизнеса. А в большинстве Agile-методологий нет роли менеджера проекта. Увы, но это так.

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

Полезные ссылки:

• Официальный сайт Scaled Agile Framework: https://www.scaledagileframework.com.
• Статьи про SAFe на русском: https://scrumtrek.ru/blog/tag/safe.
• Глоссарий SAFe на русском: https://scrumtrek.ru/blog/glossarij-safe-4-0.