лидер трайба что это
Что такое Sbergile и чем он отличается от Agile
Сбербанк работает по Agile. Точнее по Sbergile. Но даже опытные специалисты не всегда улавливают разницу, а новички вообще склонны впадать в ступор. Мы попросили Agile-коучей Сбербанка Анну Родионову и Максима Зотова на пальцах объяснить, что все это значит и зачем нужно.
Много лет сфера IT спокойно жила без Agile. Но со временем программ стало больше, кодовые базы сложнее, пользователи избирательнее, а мир стал меняться так быстро, что цикл разработки в несколько лет перестал быть актуальным. Поэтому в 2001 году был принят манифест гибкой разработки. Он описывает ценности и принципы, которыми руководствуются команды и люди в своей работе.
Agile не включает методов, советов, описаний или точно определенных процессов и ролей. В Agile-манифесте всего 4 ценности и 12 принципов.
Ценности звучат так:
То есть, не отрицая важности того, что написано в каждом пункте справа, мы всё-таки больше ценим то, что слева. Например, последняя ценность о готовности к изменениям не означает, что нужно работать по принципу «на месте разберусь» и не планировать вовсе. Agile не про хаос. Просто при первоначальном планировании большого проекта сложно учесть всю нюансы и непредвиденные обстоятельства. И Agile за то, чтобы вносить адекватные изменения в план, а не просто следовать «духу и букве» плана любой ценой.
C Agile немного разобрались. Теперь давайте о Sbergile.
Для работы команды нужны организационные рамки и описание процесса работы. Для совместной работы нескольких команд должны быть договоренности внутри команд и правила взаимодействия с другими командами. Для большой организации таких договоренностей должно быть ещё больше. Эти наборы договоренностей можно назвать фреймворком.
В отличии от Agile в Sbergile гораздо больше описаний, советов, рекомендаций, процессов и инструментов.
То есть фреймворк — это свод правил, договоренностей и методик, по которым взаимодействуют люди и команды. В отличии от Agile в Sbergile гораздо больше описаний, советов, рекомендаций, процессов и инструментов. Но каждый шаг они не описывают — иначе получился бы многотомник вроде Оксфордского словаря.
Agile-трансформация Сбербанка — одна из самых масштабных в мире, и она была постепенной. В 2016 году первые 600 человек начали работать по Agile. Специально для Сбербанка был разработан свой фреймворк работы — Sbergile. Он основывается на ценностях и принципах Agile, дополненных правилами, которые описывают основные моменты взаимодействия, синхронизации и сотрудничества.
За основу был взят известный фреймворк работы команды — Scrum. О нем мы расскажем в следующий раз, пока можно посмотреть описание.
Суть в том, что каждая команда работает над своим продуктом и старается сделать всю связанную с ним работу сама. Команды объединяются в трайбы, которые отвечают за свою область бизнеса, например, call-центр. Трайбы, в свою очередь объединяются в блоки, например, розничный. А они, в свою очередь, вместе и территориальными подразделениями образуют Сбербанк.
Фреймворк Sbergile развивается с учетом пожеланий сотрудников и отражает изменения в банке, в мире, технологиях и на рынке. С 2016 года количество сотрудников, работающих в соответствии с Agile-принципами, выросло с 600 человек до 25 000. Это позволяет банку выпускать продукты быстрее, делать их более клиентоориентированными и быть хорошим работодателем.
Отметим еще, что Sbergile используется только для изменений в существующих продуктах и создания новых. А территориальные подразделения работают по стандартным процессам с существующими продуктами.
И ещё раз коротко: Agile — это общие рекомендации, Sbergile — конкретные правила, основывающиеся на этих рекомендациях.
Несколько трансформаций одновременно: не по книжкам, а ровно наоборот
Общепринятые мировые практики против проведения нескольких трансформаций в компании одновременно. И все же они возможны, при соответствующей подготовке, привлечении необходимых ресурсов и правильном мониторинге результатов. Плюсами и минусами одновременных трансформаций на конференции 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? Подписывайтесь на рассылку.
HR-СТАТЬИ
Agile-трансформация в Сбербанке
По следам конференции «Команды-2017. Опыт лидеров», которая прошла 29 ноября и на которой побывала Юлия Чемеринская
Agile-технологии в Сбере за год слегка трансформировались и приобрели свой формат, поэтому его называют Sbergile:)
КАК ЭДЖАЙЛ ЖИВЕТ В СБЕРБАНКЕ
УПРАВЛЕНИЕ В СБЕРДЖАЙЛ
1. Владелец продукта.
С ним все более-менее просто. Сложно только, что это роль, а не должность:) Часто воспринимается как руководитель – сложно перестроиться с иерархической культуры. Хотя Владелец продукта может получать меньше участника команды.
Опыт пребывания Владельцем продукта полезен всем, но не всем комфортен.
2 и 3. Лидер чаптера и Лидер компетенции
Лидер области компетенций, к примеру, мастер 80-го уровня в IOS, занимается только развитием этой техкомпетенции у 24 сотрудников, за которых он отвечает. Грубо говоря, учит писать и проверяет их IOS-коды.
4. Agile-коуч
От скрам-мастеров Сбер отказался и передал их роль agile-коучам. Они ребята очень загруженные, коучат по 3-4 команды. Развивают ценностно (в сторону agile) и помогают понять и реализовать потенциал каждого сотрудника.
Кто же принимает решения и несет ответственность?
Решения принимает вся команда, результаты оцениваются общие.
Есть правила работы частично на основании методологии, частично создаются свои законы.
ОЦЕНКА И РАЗВИТИЕ ЛЮДЕЙ В СБЕРДЖАЙЛ
Что является обязательным условием развития? Стимул развиваться, объективная оценка и постоянная обратная связь.
Про развитие по всем фронтам уже написала выше. И бизнес-компетенции тебе развивают, и технические, и человеческие.
Так же происходит и оценка: с разных сторон, разными людьми.
ПРЕМИРОВАНИЕ
До недавнего времени, а именно до октября этого года, в Сбербанке была квартальная система премирования, основанная на целой многоступенчатой системе KPI. С октября от нее отказались, потому что в понимании Наталии (я, кстати, тоже очень поддерживаю) материальное стимулирование не работает на сотрудниках, от которых мы ждем интеллектуального продукта, креативности и инновационности. Оценка по KPI превращается в профанацию, все пытаются «обмануть систему» или «прогнуться» под нее, убивая инновации, риск и творчество.
В результате перевели премирование в оклад и осталась только небольшая годовая премия. Это очень верно. Айтишники не премиями мотивируются.
Кстати, если вы хотите научиться разрабатывать эффективные схемы оплаты, в том числе для айтишников, добро пожаловать к нам на курс Менеджер по компенсациям и льготам.
Ну и в заключении плюсы и минусы.
ПЛЮСЫ AGILE-ТРАНСФОРМАЦИИ
МИНУСЫ AGILE-ТРАНСФОРМАЦИИ
В конце Наталия пригласила всех желающих на экскурсию по Сберджайлу, которая состоится в декабре в офисе на Кутузовском. Следите за нашими анонсами!