Русский
Русский
English
Статистика
Реклама

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

Общепринятые мировые практики против проведения нескольких трансформаций в компании одновременно. И все же они возможны, при соответствующей подготовке, привлечении необходимых ресурсов и правильном мониторинге результатов. Плюсами и минусами одновременных трансформаций на конференции 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?Подписывайтесьна рассылку.

Источник: habr.com
К списку статей
Опубликовано: 30.03.2021 12:10:29
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Блог компании конференции олега бунина (онтико)

It-инфраструктура

Конференции

Devops

It-компании

Трансформации

Devopsconf

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru