Несколько трансформаций одновременно: не по книжкам, а ровно наоборот
Общепринятые мировые практики против проведения нескольких трансформаций в компании одновременно. И все же они возможны, при соответствующей подготовке, привлечении необходимых ресурсов и правильном мониторинге результатов. Плюсами и минусами одновременных трансформаций на конференции 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 систем.
Было важно организовать взаимодействие между всеми этими командами так, чтобы:
Продуктовые команды могли вносить изменения в функционал CORE систем;
Эти изменения не влияли негативно на стабильность в CORE системах;
Сохранялся необходимый темп доработок.
В ОТП распределили функциональность некоторых систем и дали возможность продуктовым командам контрибьютить в них. Конечно, при определенных условиях и наличии договоренностей между платформенными и продуктовыми командами. Эти условия описывают правила совместной работы над кодом, автоматизированные пайплайны сборки, требования к тестированию и т.д.
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? Подписывайтесь на рассылку.
