Несколько трансформаций одновременно: не по книжкам, а ровно наоборот

Общепринятые мировые практики против проведения нескольких трансформаций в компании одновременно. И все же они возможны, при соответствующей подготовке, привлечении необходимых ресурсов и правильном мониторинге результатов. Плюсами и минусами одновременных трансформаций на конференции DevOps Live 2020 поделился лидер трайба IT4IT в ОТП Банке Максим Ефимов. 

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

Как происходит любая трансформация в крупной организации?

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

«Впереди перемен» Джона Коттера — мировой бестселлер, который может стать настольной книгой любого лидера трансформации.

«Accelerate» — это произведение о том, как инженерные практики и DevOps культура меняются сами, меняют организации и бизнес, увеличивают performance и profitability любой организации.

«Team topologies» рассказывает о практиках организации взаимодействия между командами.

Основная мысль, которую можно вынести из книги «Впереди перемен», это:

«Никогда нельзя делать несколько крупных глобальных изменений одновременно».

Это анти-паттерн того, как выполняются трансформации, потому что такие действия влекут за собой:

• Гораздо большие риски;

• Размытие фокуса; 

• Выгорание сотрудников;

• Взаимное негативное влияние трансформаций.

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

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

Трансформация в ОТП

Предпосылки для начала трансформации в ОТП были серьезными: процессы критично устарели и усложнились, а TTM был очень низким (4 релиза в год).

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

И в ОТП решили сделать все и сразу:

• Изменить оргструктуру, перейти к  Spotify-модели и внедрить продуктовые трайбы;

• Создать институты чаптеров и гильдий;

• Сфокусироваться на продуктовой разработке и поменять процессы IT;

• Провести редизайн IT ландшафта и модернизацию IT;

• Внедрить DevOps и автоматизацию;

• Кардинально привязать работу к облакам и микросервисной архитектуре.

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

Трайбы и оргструктура

В ОТП запустили трайбы, отказались от линейной подчиненности и ввели матричное подчинение. 

У каждого трайба есть трайб-лидер и трайб-техлидер. Первый отвечает за бизнес-направление и доходность, второй — за IT-составляющую в каждом трайбе.

Трайб состоит из нескольких команд. У каждой из них есть product owner и бизнес-эксперты. 

В ОТП есть своя особенность: в их командах нет выделенных DevOps’ов и QA, это роли, которые выполняют разработчики.

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

Например, есть Java senior бэкенд разработчик Вася. Он бы хотел развиваться в качестве менеджера, а еще не прочь поделиться экспертизой. Вася становится лидером чаптера бэкенд разработки в трайбе №1. Он помогает наращивать экспертизу и повышать профессиональные хардскиллы людям из его трайба, которые занимаются Java бэкенд разработкой.

Важный нюанс: в компании хотели, чтобы люди переопылялись не только внутри трайба, но и кросс-трайбово. Для этого был запущен институт гильдий. Разница между подходами в том, что участие в трайбе условно обязательно. Если вы бэкенд-разработчик, то попадете к сеньору Васе в чаптер бэкенд-разработки, трайба №1. Гильдия — это сообщество, можно сказать, «кружок по интересам».

Например, в ОТП есть гильдия Kubernetes. В ней состоят сотрудники, которым интересна эта технология. В гильдии постоянно идет диалог на профильные темы, сообщество реализовывает автоматизации и лучшие мировые практики, то есть все, что связано с Kubernetes внутри организации. 

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

Продуктовая разработка и изменение IТ процессов

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

Было важно организовать взаимодействие между всеми этими командами так, чтобы: 

1. Продуктовые команды могли вносить изменения в функционал CORE систем;

2. Эти изменения не влияли негативно на стабильность в CORE системах;

3. Сохранялся необходимый темп доработок.

В ОТП распределили функциональность некоторых систем и дали возможность продуктовым командам контрибьютить в них. Конечно, при определенных условиях и наличии договоренностей между платформенными и продуктовыми командами. Эти условия описывают правила совместной работы над кодом, автоматизированные пайплайны сборки, требования к тестированию и т.д. 

IT модернизация и редизайн IT ландшафта

Для того, чтобы все вышеописанное стало возможно, в ОТП решили создать слой API вокруг CORE систем.

Например, есть платформенная команда, развивающая сервис В. Она, посредством API, взаимодействует с сервисом А, который развивает продуктовая команда. В ОТП выработали стандарт, проясняющий, каким образом можно делать интеграции, как они должны работать и как организовано синхронное/асинхронное взаимодействие. 

DevOps и автоматизация — IT4IT (enabling team)

Если вспомнить про Team Foundation, IT4IT — та самая enabling team.

Когда-то одной из ключевых задач в ОТП было создание стека централизованных инструментов. Это базис, с которого нужно было начать. Его выбрали совместно с community, внедрили и начали использовать. Естественно, для того, чтобы все это было возможно, пришлось серьезно вложиться в процессы и составляющую DevOps культуры. И сейчас в компании этим серьезно занимаются. 

В ОТП не стали выбирать путь создания пайплайнов за команды. Вы ведь помните, что DevOps’ов в командах нет?:) Эксперты из IT4IT приходят в команду, которой требуется определенная помощь (например, с пайплайном). В этом случае члены команды разбираются в проблематике с девелопером и вместе пишут пайплайн.

Почему был выбран именно этот путь? Есть ведь распространенная альтернатива — создание пайплайна вместо команды. Давайте посмотрим, как бы это выглядело на практике: эксперт из Enabling team делал бы пайплайн, отдавал его в эксплуатацию и уходил из команды. 

Вроде бы, бинго! Продукт активно развивается, меняются конфигурация приложений и инфраструктура, окружение, появляются новые интеграции. Но все это требует доработки и внесения изменений в пайплайн. А экспертиза внутри команды, в случае написания пайплайна, не была бы проведена. И никто в команде не понимал бы, как провести доработку.

Поэтому был выбран путь накопления и наращивания экспертизы внутри команды, достижения нужного уровня DevOps-культуры и технической зрелости, использования лучших инженерных практик. Когда совместная работа продуктовой команды и IT4IT над пайплайном заканчивается, экспертиза остается в продуктовой команде.

Облака и микросервисы

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

В ОТП выбрали подход использования облачной инфраструктуры, заключили договор с провайдером и начали осваивать public clouds. Важный нюанс: речь идет о банке, где очень беспокоятся о безопасности. В публичные облака договорились выносить только то, что не содержит чувствительных клиентских данных.

Сейчас в ОТП идет работа над внедрением Private cloud, которое позволит размещать любые сервисы и даст командам возможность еще более гибко управлять своей инфраструктурой. В дальнейшем public и private будут связаны. Командам не придется ждать, пока будет создана необходимая классическая инфраструктура.  Это положительно отличает ОТП от других банков. 

Все эти изменения произошли буквально за полгода. 

На данный момент в ОТП уже есть:

• 8 трайбов, 60+ команд и продуктовая разработка;

Часть трайбов сфокусирована на определенных бизнес-направлениях, а еще есть три IT трайба, которые поддерживают CORE-платформы, общебанковские сервисы и сервисы для IT. 

• Матричная структура и функционально/административная подчиненность;

• Чаптеры и гильдии по всем трайбам;

• Слой в 60+ API вокруг CORE-систем;

• Большая часть (90%) команд находятся на централизованном стеке CI/CD;

Изначально у всех были и GitLab, и Jenkins, и инстансы Nexus. Однако централизация — важный аспект для банка. Она позволяет ускорить наращивание экспертизы, упрощает обмен опытом и знаниями.

Уроки, вынесенные во время трансформации

Lesson №1. Негативный эмоциональный фон

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

Настолько, что несколько человек решили уйти без какой-то конкретной причины, а просто из-за ощущения неопределенности. Казалось, что ситуация тяжелая, но обратившись к сухим фактам, в ОТП поняли, что даже в самый пиковый по уходам месяц среднегодовой показатель текучки персонала не превысил 13%, при рыночном бенчмарке в 10-15%. То есть происходящее ощущалось страшнее, чем было на самом деле. 

Кроме того, оказалось, что всех уходящих объединяло одно желание: они хотели «просто писать код». То есть you build it, you run it, DevOps, автоматизация и прочие штуки были им не интересны. Таким узко-специализированным профессионалам стало сложно продолжать получать удовольствие, когда вокруг наступили всеобщие эджайл и гонка за тайм ту маркетом. Сложившаяся ситуация была взаимовыгодной: уходящие, будучи крутыми профи в своей сфере, нашли себе команду по душе, а в ОТП продолжают развитие культуры, не тратя силы и время на перевоспитание тех, кому это не интересно.

Lesson №2: Внезапный COVID

Следующий важный момент, с которым все столкнулись в 2020 году — это пандемия, которую никто не мог предусмотреть. Любая трансформация — достаточно хрупкая вещь, неустойчивая к внешним изменениям. С учетом количества изменений в ОТП, эта хрупкость была гораздо более заметной. 

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

Lesson №3: Измерения — важная часть DevOps культуры

В ОТП хотели понять, насколько происходящие внутри организации трансформации, успешны, чтобы понимать, правильно ли заданное направление.

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

Поэтому было принято решение запустить ручной assessment и условно измерить, насколько в командах все хорошо с точки зрения:

• Процессов;

• Техники;

• Архитектуры.

Когда assessment был запущен, его показали топ-менеджменту, и все сказали: «Вау! Круто! Давайте это запускать везде, где только сможем». И в этот момент было принято важное решение о том, что полученные оценки не должны стать KPI. Ведь assessment базируется на честности и открытости. И ОТП доверяют своим сотрудникам — какая же DevOps культура без доверия? 

В какой-то момент heatmap выглядел так (это только часть, просто чтобы дать некоторое общее видение):

Есть определенный трайб, в нем команда 1,2,3, а у них — несколько приложений. Базируясь на их ответах, можно понять, что происходит, и построить heatmap вместе с Agile коучами и архитекторами. Здесь можно увидеть интересующие практики, подчеркнуть сильные стороны трайба и команды, наметить основные зоны роста. 

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

Кроме того, принято решение о том, что в ОТП станут опираться на четыре основные метрики DORA, о которых много говорится в «Accelerate». Например, есть идея, чтобы Lead time распадался в дальнейшем на все составляющие SDLC процесса, которые происходят условно от события git push до выкатки в продакшен. Таким образом, его можно будет измерить. А каждая из составляющих второго уровня метрик распадется, в свою очередь, на еще большее количество технических метрик (наличие и использование код-ревью, сколько времени согласовывается pull request и пр.).

И, конечно, этот assessment будущего по-прежнему не будет являться основой для KPI.

Lesson №4 Любая трансформация — это в первую очередь люди

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

Важно управлять ожиданиями со старта трансформации. Сейчас даже на этапе интервью в компании уделяют большое внимание проверке вовлеченности: насколько человек в принципе готов к продуктовой разработке, как относится к T-shape или готов ли он надеть на себя шапочку QA, когда и если это потребуется? 

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

Подытожим

Что в ОТП вынесли для себя:

• Запуск нескольких трансформаций значительно увеличивает риски неуспешности каждой из них.

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

• Важна плотнейшая работа с людьми, в том числе:

— Информационные события и постоянный подогрев информационного поля;

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

— Персональное общение и индивидуальный подход.

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

• Существенные единовременные затраты.

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

• Во время трансформации рекрутменту придется несладко.

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

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

Профессиональная конференция по интеграции процессов разработки, тестирования и эксплуатации DevOpsConf 2021 пройдет 31 мая и 1 июня 2021. Билеты на нее вы можете приобрести уже сейчас, успев сделать это до повышения цены.

С 1 апреля стоимость билетов на наши ближайшие конференции: TeamLead Conf 2021, DevOpsConf 2021 и HighLoad++ Весна 2021 возрастет.

Хотите бесплатно получить материалы предыдущей конференции по DevOps? Подписывайтесь на рассылку.