«Да кто такой этот ваш аджайл?! Мы же не продуктовая команда!», «И как меня угораздило в это вляпаться?!» — такие выражения (и много чего еще) я часто слышала на командных встречах архитекторов в роли агента изменений.
Всем привет! Я – Мадина, скрам‑мастер в Департаменте управления технологиями МТС, у нас это подразделение называют Департаментом Technology Governance (TechGov).
Наше подразделение (относительно недавно созданное) занимается управлением технологиями на уровне всей компании. Если коротко – структура Департамента представляет собой Центры компетенций и Центры практик.
Центры компетенций описывают практики, методологии и стандарты, центры практик занимаются внедрением и масштабированием этих практик по всем продуктам компании. Трансформация, а тем более технологическая – дело непростое, и без применения гибких методологий тут не обойтись.
Agile не ограничивается только продуктовыми командами, любое подразделение в компании может получить пользу от внедрения этой методологии. Ведь Agile – это не просто модное слово, это философия работы, которая позволяет улучшить процессы и более эффективно достигать поставленных целей. Тем более, наш департамент занимается Продуктовой трансформацией в том числе, а это значит мы должны следовать принципу Eat your own dog food (практика использования компанией или командой разработчиков собственных сервисов и продуктов).
Но одно дело (тоже весьма непростое) — внедрять скрам или канбан в командах разработки, где есть понятный инкремент и стейкхолдеры. И совсем другое — внедрять гибкие подходы в Центрах компетенций или практик. Таких, например, как архитектура, управление производственным процессом, R&D или даже сам Центр практик Agile.
Мой путь агента изменений был нелегок и тернист, я набила кучу шишек, случались и провалы. Но я извлекла из этой истории много уроков и, кажется, мы с командой смогли нащупать верную дорогу, используя здравый смысл, и начали ощущать пользу от внедряемых изменений.
Итак, от директора по развитию технологий TechGov поступил запрос на скрам-мастера в Центры практик и компетенций управления корпоративной архитектуры. Запрос звучал примерно так: «Нужен гибкий подход к реализации задач. Продуктовые практики при разработке стандартов и методологий».
Ключевые стратегические направления, которыми занимается Центр:
ArchOps;
Бизнес-архитектура;
CloudNative;
Архитектурные стандарты;
Технологический радар;
Open/Inner Source;
и другие направления.
Стоит ли говорить о том, как было тяжело первое время вникать в суть дискуссий и задач на командных встречах? Например, тема встречи такая: «Обсуждение метамодели аналитических и архитектурных артефактов». Я гуглю: «Что такое метамодель?» и получаю ответ: «Метамодель – это модель, описывающая другую модель».
Эммм... спасибо…
Что я увидела на старте: каждый сотрудник занимался своим, на первый взгляд, узкоспециализированным делом и особо не заботился о том, что происходит за пределами своей области ответственности. И да, до меня команда уже работала в спринтах, проходили синхронизирующие встречи.
Было множество митингов, презентаций и писем друг другу, но на практике реализация и внедрение проходили туго. Спринты закрывались и открывались формально, никаких процессных метрик не велось. Во избежание бунта я решила начать процесс изменений поэтапно. Сначала встретилась с каждым членом команды на индивидуальной встрече, и мы заполнили шаблон STATIK.
Основной моей задачей было погрузиться в работу центра и понять, какие проблемы есть на поверхности.
Вот какие проблемы мы вместе обозначили:
много зависимостей, которые очень сложно решаются или не решаются совсем;
непрозрачный канал коммуникации между руководством, смежными подразделениями;
«я не понимаю, чего от меня хотят».
Пообщавшись с директором и каждым участником команды я для себя сделала вывод, что команда находится примерно на красном уровне развития, если оценивать по спиральной динамике:
А значит, нам надо постепенно выходить на синий уровень, а это инструкции, правила, постоянные ритуалы. Если короче – дисциплина.
Этап 1. И тут мы пришли к гигиене Jira…
Что было (тут прошу понять и простить за «англицизмы», но в нашей профессии без них никак:)):
Lead time* задач несколько месяцев, выполнение запланированных задач на спринт только 20%. Задачи и истории не соответствовали объектной модели**, принятой в департаменте.
*Lead time задач — промежуток времени, необходимый для выполнения задачи.
**Объектная модель Jira — это совокупность объектов (epic, story, task) их свойств, параметров и взаимосвязей (звучит почти также как объяснение термина метамодель, знаю
Интересные статьи
Интересные статьи
