Как обеспечить развитие организации. Часть 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 и Scrum

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

Кейс
Промышленность
Мотивирующий кейс о том, как успешно инициировать изменения в компании «снизу»
Сразу оговоримся, что речь про мидл-менеджмент. Тем не менее, это отличный пример, как инициатива одного человека способна изменить 6 производств внутри огромной международной компании.
Публикация
Гибкие организации
Комплексная Agile-трансформация бизнеса
Комплексная трансформация бизнеса — это трансформация бизнеса целиком, и в первую очередь — это изменение культуры компании или группы компаний.
Публикация
Гибкие организации
Цифровая трансформация организации: новые компетенции, роли, люди
Цифровая трансформация стала частью стратегии большинства традиционных компаний в любой отрасли. Однако часто проходят месяцы с момента запуска инициативы внутри компании, но никакие значимые результаты не достигнуты. Почему так происходит?
Кейс
Гибкие организации
Трансформация HR-сервиса в финтех-компании
Наш клиент — финтех-компания «Профи.Лаб». Компания начала трансформацию HR-сервиса с применением agile-подходов и уже спустя 3 месяца более чем в 2 раза повысила эффективность процесса найма.

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

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

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

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

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