Привет, Хабр! Меня зовут Ярослав Станишевский, я DevOps Cluster Lead в МТС Диджитал. На Saint TeamLead Conf 2024 я рассказал свою историю внедрения трансформационных изменений в кластере порядка 600 человек. Это сложная задача, которая требует не только проработки плана действий, но и выстраивания доверия с разными командами, погружения в их работу. Сегодня расскажу, как я по шагам формировал план изменений, шел по нему и как налаживал конструктивное взаимодействие с коллегами.

Начало трансформации: формируем подходы и составляем план

В конце 2021 года в МТС была принята новая стратегия и запущена технологическая трансформация экосистемы. Она подразумевала внедрение общих практик и процессов для DevOps и других направлений. Я пришел в МТС в конце сентября 2022 года, но стал не просто DevOps-инженером, а агентом изменений. Моей задачей было внедрять DevOps-практики у себя в кластере «Бизнес-платформы». Он включает в себя порядка 25 продуктов, из которых 10 объединены в единую платформу, а остальные 15 — самостоятельные.

Мне нужен был список задач по трансформации, и он получился таким:

• изучить практики;

• найти данные команд; 

• провести изменения: 

  • познакомиться с командами;

  • узнать текущее состояние практик;

  • рассказать о новых практиках и изменениях в компании;

  • поставить задачи на изменения;

  • принять работы.

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

Цели изменений прямо вытекали из технологической стратегии: нужно было снизить time-to-market, повысить качество готовых решений. Этими процессами занимается центр практик DevOps: методолог формулирует описание практик, которые уже обсуждаются и принимаются вместе с лидами кластеров. Head of DevOps принимает получившееся решение, и начинается каскадирование практик в продуктовые команды. В соответствии со стратегией на подобные задачи команды должны выделять 25% времени.

До моего прихода для их реализации уже были разработаны базовые практики VCS и CI, расширенная практика VCS. Таким образом, мне нужно было обеспечить:

• переезд в централизованный GitLab: наше единое хранилище исходного кода и CICD-оркестратор. Внедрение практик разработки обеспечит большую безопасность: при любых сбоях у нас в любом случае остается возможность работать с кодом, мы всегда сможем его восстановить;

• настройку CI в GitLab, сборки и деплоя хотя бы на один контур: базовая гигиена, с которой вполне комфортно начать;

• внедрение общих правил разработки: использования master-веток, тегирования, merge request и так далее. До меня уже такие базовые практики частично внедрялись, но не везде, а там, где это было проще всего.

Второй этап. Старт изменений и сопротивление 

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

• знакомство с командой;

• фиксация договоренностей;

• написание писем;

• объяснение ценности;

• работа с замечаниями.

Сначала казалось, что все идет как надо. Первые встречи с командами проходили спокойно. Я рассказывал про практики, которые нужно внедрить. А если вдруг спор все же возникал, объяснял важность того, что мы делаем, зачем это нужно, какие цели преследуем. 

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

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

Работа с сопротивлением 

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

Изменение в моем подходе к коммуникациям

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

Разделение на свой/чужой можно преодолеть, узнав людей. Доверие — ключ ко всему, поэтому так важно его завоевать. Пришел к команде незнакомый руководитель и рассказывает про изменения, которые надо вводить. Но почему кто-то будет это делать, если вам не доверяют? Чтобы что-то получилось, нужно стать своим для людей, больше с ними общаться. Постарайтесь узнать коллег, поговорить с ними, рассказать о себе, выслушать. Общение поможет найти точки соприкосновения, общие боли. Покажите, что вы нормальный и адекватный человек, что с вами можно разговаривать и, главное, продолжать работать.

Хорошее расположение и симпатия завоевываются разговором. Важно вовремя пошутить или просто поговорить. Так мы повышаем доверие и налаживаем контакт с людьми. 

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

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

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

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

Изменения в принципах взаимодействия с командой

Тут тоже не обошлось без тонкостей.

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

Структурирование практик улучшает их восприятие. Наши практики изначально были изложены достаточно сложно. Не всегда понятное описание, информация распределена по Confluence, Jira и другим источникам. DevOps-практики достаточно сложные, поэтому стоит собрать все в одном месте — в FAQ и ценностях.

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

Результаты встреч в мемо воспринимаются лучше протокола. На некоторых созвонах из-за нехватки времени начинались проблемы. Конечно, хочется использовать механизм протокола: вы собрались, о чем-то договорились и записали итоги. Но у людей может сложиться впечатление, что вы хотите перенести ответственность. Подобный эффект возникает при сухом написании протоколов в стиле «решили сделать вот это, в такой срок, ответственный — имя». На самом деле это крайняя мера, к которой не стоит прибегать. 

Договоренности лучше описывать живыми и простыми словами. Ключевое — не перенести ответственность, а решить задачи, заслужив доверие, чтобы и дальше работать с этим человеком. В самих мемо в заметках лучше использовать не сухой текст, а простыми словами описывать договоренности.

Хорошо действует прямое общение с исполнителями. Сначала я встречался с СТО, с руководителями команд, и они ставили задачи нашим DevOps-инженерам. Но я стал сам приходить к исполнителям. Так оказалось гораздо проще — поговорить, рассказать, какие есть проблемы и что нужно сделать. Большинство соглашалось. Так переход к общению с исполнителями в моем случае показал хороший результат.

Третий этап. Фиксация изменений

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

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

→ пройти эскалации, разрешить конфликты, предложить помощь. С другой командой, отказавшей в переезде из-за грядущего вывода в прод, мы договорились, что какое-то время будем коммитить изменения в TFS и GitLab. Нашел в помощь DevOps-инженера, договорился, что он напишет pipeline, и команда полностью переедет в GitLab;

→ принять работы, убрать блокеры и стать в итоге помощником, а не врагом. Спустя время увидел, что изменений у проблемной команды опять нет. Пару раз закоммитили и перестали. Связался с разработчиком, поговорил один на один, объяснил всю важность. Оказалось, слетело тегирование. Обсудил с инженером причину, доработали решение и быстро починили продукт;

→ проработать исключения, перестать «мести всех под одну гребенку» и начать подходить к проблемам индивидуально. Например, одной команде надо было переводить деплои, но было неудобно работать — из Jenkins деплоить на промышленные контуры, а из GitLab деплоить на Dev и устраивать сборки. Договорился, что перенесем сроки, но сразу осуществим деплой до прома. Согласовали, выполнили;

→ добиться изменений и рассказать о них руководству. Коллеги похвалили мои изменения и подтвердили, что такой жесткий режим — временный. Стоит немножко по нему поработать, команды понимают, что ты можешь быть более требовательным, и после этого спокойнее идут на общение;

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

Результаты для компании

За полтора года работы по трансформации мне удалось добиться:

• отладки и запуска корпоративных процессов. Мы сформировали в кластере общие практики и наладили каскадирование задач по технологической стратегии;

• вовлечения команд в процессы изменений. Некоторые продукты начали приходить в начале квартала и спрашивать, что мы будем делать и куда двигаемся дальше. Сейчас кластер вырос — уже более 40 команд, и налаживается линейное масштабирование;

• старта перехода от Push к Pull-модели. В целом в компании мы двигаемся от Push- (постоянно пушить изменения) к Pull-модели. Выстраиваем техзрелость, которую считаем важной, чтобы команды были замотивированы самостоятельно развиваться. 

Что я вынес для себя

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

Изменился мой подход к работе.

Начал запрашивать помощь 

Почти все команды жаловались на нехватку ресурсов: «Много бизнес-задач, бэклог всегда заполнен, на трансформацию просто не остается времени и сил». В этом случае важно посмотреть, чем заняты инженеры, что вообще происходит, какие они задачи решают и действительно ли в дефиците ресурсов дело. 

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

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

Например, у нас был переезд из Jenkins в GitLab, у команды было более 30 сервисов и один DevOps. Просто не хватало рук все перевести: оперативные и стратегические задачи отнимали все время. Осознав это, нашел внутреннюю помощь, договорился с ребятами, они подключились и достаточно быстро и хорошо все сделали. 

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

Был кейс, когда в продукте использовались main-ветка и Trunk-Based Development, что шло вразрез с требованиями компании. Обсудили с центром практик и поняли, что master-ветка — важна. Зоопарк с названиями основных веток усложнит автоматизацию процессов по мониторингу метрик разработки в компании. Поэтому тут отказал в исключении. Написал большое письмо о том, что у нас другая культура, стал описывать нашу и западную культуру, почему у нас нормально использовать master-ветку. Отправил письмо, через какое-то время звонит техлид и смеется, мол, «центр практик не разрешил исключение». Мы вновь обсудили и договорились, что они просто в ближайшее время переименуют master-ветку. А вот по поводу Trunk-Based Development договорились с центром практик сделать исключение, так как это более зрелый подход и он будет примером прогрессивной модели. 

Заменил упрямство упорством

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

Понял и принял неизбежность эскалаций

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

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