Как обеспечить развитие организации. Часть 2: Роли в SAFe 💎 — OnAgile Consulting

Как обеспечить развитие организации. Часть 2: Роли в SAFe

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

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

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

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

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

В отличие от Scrum, у нас появляются новые роли: Менеджер продуктов, Архитектор, RTE («машинист»), и новые структуры, такие как ART (Agile Release Train), представляющий собой команду команд.

Структура SAFe

Итак, начнем со структуры SAFe в общем виде. Любую организацию можно формально разделить на 3 уровня: 

1. Уровень портфеля 

  • Владельцы бизнеса
  • Владельцы решения

2. Уровень координации (в свое время его было принято считать за уровень программы)

  • Менеджер продуктов (продуктовый офис)
  • Архитектор
  • Машинист (RTE)

3. Уровень команды

  • Скрам-мастер
  • Владелец продукта
  • Разработчики (Специалисты)

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

Менеджер продукта vs Владелец продукта

Один из ключевых каналов взаимодействия в структуре SAFe — разделение зон ответственности между Владельцем продукта и Менеджером продукта:

Как мы видим из таблицы, наш классический Владелец продукта из Scrum был разделен на две роли в контексте SAFe (Владелец продукта и Менеджер продукта), что позволяет обеспечивать масштабируемость на уровне направления. Стоит отдельно отметить, что один Менеджер продукта может качественно взаимодействовать не более чем с четырьмя Владельцами продуктов.

Пример распределения зон ответственности Менеджера продукта и Владельцев продукта

Кроме того, в SAFe появляются роли Архитектор решения, Системный архитектор и Машинист (Release Train Engineer). Поговорим о них в следующем посте.

Опубликовано

Ближайшие тренинги по Agile и Scrum

Еще публикации по Agile в Гибкие организации

Кейс
Банкинг
2 часа вместо 7 суток: внедрение Agile в международном банке
Как оптимизация внутренних процессов помогла в разы увеличить скорость выпуска карт.
Публикация
Гибкие организации
Комплексная Agile-трансформация бизнеса
Комплексная трансформация бизнеса — это трансформация бизнеса целиком, и в первую очередь — это изменение культуры компании или группы компаний.
Интервью
Гибкие организации
Увеличение гибкости (agility) компании
Дэйв Томас, один из авторов Agile Manifesto, в своем интервью раскрывает понятие «гибкости» компании. Вот небольшой отрывок из его интервью.
Публикация
Гибкие организации
Уточнение бэклога в LeSS (PBR) - виды и применение
Product Backlog Refinement в LeSS включает в себя многокомандный PBR (совместная работа всех команд над бэклогом), общий PBR (обзор бэклога всеми командами или их представителями) и однокомандный PBR (работа одной команды над сложной задачей). Эти методы способствуют обмену знаниями, улучшению координации команд и адаптивности процесса.

Мы помогаем организациям с 2004 года

Связаться с нами

Дмитрий Лобасев

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

Наш Telegram канал об Agile и гибких организациях, присоединяйтесь!