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

Как обеспечить развитие организации. Часть 3: Специфичные роли в SAFe

Итак, пришло время разобраться с нетипичными для Agile ролями, присутствующими в Scaled Agile фреймворке: Машинист (Release Train Engineer), Архитектор решения и Системный архитектор.

Release Train Engineer

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

И как раз в этом нам поможет роль машиниста (RTE) из SAFe, ведь по своей природе он является эволюционным развитием роли Скрам-мастера, но с большим фокусом на уровень программы и межкомандного взаимодействия. RTE предоставляет такие сервисы как: фасилитация ART встреч, идентификация и своевременная эскалация препятствий/ ограничений,  управление рисками и обеспечение непрерывного процесса улучшений. 

Общий список обязанностей содержит более 20 пунктов, но в целях экономии вашего времени мы объединили их в 7 групп:

  • Коучинг стримов (ART) в контексте улучшений, направленных на продуктивность и процесс
  • Результативное и эффективное проведение встреч: PI планирование, системные демо, формирование видения, построение Roadmap, встречи по подготовке к PI, встречи по завершению PI, встречи по синхронизации и другие.
  • Обучение команд в таких направлениях как Продукт, Проект, DevOps, Команда, SAFe, и адаптация Agile ценностей и принципов
  • Проведение внутреннего аудита с целью определения точек роста (Agile зрелость) и дальнейшего построения стратегии развития
  • Определение и настройка структуры ART с учетом  роста организации
  • Обеспечение прозрачности на уровне программы, особенно в контексте установленных целей на PI
  • Обеспечение взаимодействие между продуктовым штабом (PM, Владельцы продукта, Владельцы бизнеса) и продуктовыми командами.

Архитекторы

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

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

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

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

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

Хотите узнать больше о каркасе SAFe, приходите к нам на тренинг Leading SAFe.

Хотите узнать, каких результатов можно достичь с помощью Agile в вашем проекте или компании?
Напишите нам
                                                      
Опубликовано

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

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

Кейс
Гибкие организации
Трансформация HR-сервиса в финтех-компании
Наш клиент — финтех-компания «Профи.Лаб». Компания начала трансформацию HR-сервиса с применением agile-подходов и уже спустя 3 месяца более чем в 2 раза повысила эффективность процесса найма.
Кейс
Банкинг
2 часа вместо 7 суток: внедрение Agile в международном банке
Как оптимизация внутренних процессов помогла в разы увеличить скорость выпуска карт.
Публикация
Гибкие организации
Как обеспечить развитие организации. Часть 1: ошибки роста
Начинаем серию статей, посвященных развитию организации и росту численности команды. Подробно поговорим о фреймворках масштабирования SAFe, LeSS, Nexus, о модели Spotify и других гибридных решениях.
Кейс
Ритейл
Удвоение продаж розничной сети в течение двух лет. Разработка стратегии
Наш клиент, региональная ортопедическая сеть, поставила перед нами задачу разработки стратегии по двукратному росту операционной прибыли в течение следующих двух лет.

С 2004 года мы помогаем адаптировать к изменениям культуру и процессы компании

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

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

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

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