Кто такой лидер трайба сбербанк

Кто же принимает решения и несет ответственность?
Решения принимает вся команда, результаты оцениваются общие.
Есть правила работы частично на основании методологии, частично создаются свои законы.

ОЦЕНКА И РАЗВИТИЕ ЛЮДЕЙ В СБЕРДЖАЙЛ

Что является обязательным условием развития? Стимул развиваться, объективная оценка и постоянная обратная связь.
Про развитие по всем фронтам уже написала выше. И бизнес-компетенции тебе развивают, и технические, и человеческие.
Так же происходит и оценка: с разных сторон, разными людьми.

ПРЕМИРОВАНИЕ

До недавнего времени, а именно до октября этого года, в Сбербанке была квартальная система премирования, основанная на целой многоступенчатой системе KPI. С октября от нее отказались, потому что в понимании Наталии (я, кстати, тоже очень поддерживаю) материальное стимулирование не работает на сотрудниках, от которых мы ждем интеллектуального продукта, креативности и инновационности. Оценка по KPI превращается в профанацию, все пытаются «обмануть систему» или «прогнуться» под нее, убивая инновации, риск и творчество.

В результате перевели премирование в оклад и осталась только небольшая годовая премия. Это очень верно. Айтишники не премиями мотивируются.

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

Ну и в заключении плюсы и минусы.

ПЛЮСЫ AGILE-ТРАНСФОРМАЦИИ

МИНУСЫ AGILE-ТРАНСФОРМАЦИИ

В конце Наталия пригласила всех желающих на экскурсию по Сберджайлу, которая состоится в декабре в офисе на Кутузовском. Следите за нашими анонсами!

Источник

Agile в Сбере: как понять, что происходит?

В декабре 2020 мы провели Sbergile Talks (да, давно это было), нашу первую онлайн-конференцию про Agile в Сбере. Три потока, 31 доклад, спикеры из крупнейших отечественных и иностранных компаний, которые так или иначе связаны с Agile. Нас слушало порядка 10 тысяч человек. Я хочу пробежаться по основным моментам и рассказать, что же там было.

Давно не секрет, что Сбер провёл одно из самых масштабных Agile-преобразований в мире. Об этом неоднократно рассказывали топ-менеджеры в различных СМИ. Итак, что важного в Сбере произошло за эти четыре года? Мы радикально ускорились. А скорость — это один из ключевых факторов развития для Сбера. И он жизненно необходим технологическим компаниям для успешного достижения поставленных целей. Особенно таким крупным компаниям, как наша. И да, Agile действительно ускоряет разработку продукта и даёт возможность компании быть в целом гибче. Поэтому многие так или иначе пытаются внедрить похожие практики у себя, но не у всех получается успешно. Мы и другие игроки рынка каждый год открыто рассказываем о возможных ошибках, накопленном опыте и практических примерах изменений.

Так почему же Agile так интересен российскому рынку?

Agile в России

Ещё пять-семь лет назад в России следовали ценностям, озвученным в Agile-манифесте, в основном ИТ-компании. Перестраивать mindset, тем более в крупных организациях, как наша, никто не спешил.

Тогда решения в Сбербанке принимались медленно, а ИТ-архитектура была монолитной. Это абсолютно нормально для компаний такого размера. И это не российский подход или какие-то особенности менталитета: плюс-минус так выглядят крупные игроки в большинстве отраслей экономики во всём мире. При этом Сбербанк был коммерчески успешным банком.

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

По нашему мнению, Agile — это работающие практики, которые способны запустить процесс изменений в компании. А в бизнесе успешны те компании, которые готовы меняться и подстраиваться под запросы рынка.

Где смотреть доклады?

Какие доклады стоит посмотреть и почему?

В направлении «Организация» — взгляд бизнеса на управление в целом.

Источник

Продуктовая команда

Сегодня постараюсь рассказать, что такое продуктовая команда. Ее состав и роли, на примере большой организации.

ПРОДУКТ — Предмет, являющийся результатом человеческого труда (книжн.).

В IT — продукт это программное обеспечение решающее какие-то задачи или потребности.

Отличие продуктовой команды от сервисной

Сервисная разработка заканчивается после запуска проекта.

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

Состав команды

В зависимости от специфики продукта состав команды может меняться. Чаще всего в команду входят Владелиц продукта, Аналитик, Разработчики, Дизайнер, Тестировщик.

Давайте рассмотрим каждого из них и поймем чем они занимаются.

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

Составляет Бэклог Продукта.

В некоторых случаях владелиц проводит командные ритуалы, такие как дейли, ретроспективу и планирование.

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

У дизайнера в команде бывает несколько задач. Проектирование взаимодействия пользователя с системой и отрисовка ui компонентов. На этапе проектирование, он плотно взаимодействует с аналитиком, создает UX карты, вайрфремы сценариев. За тем они превращается в полноценные макеты и связываются в прототипы. После тестирования и доработки, макеты передаются разработчикам

Разработчики это те люди которые превращают идеи и картинки в рабочее приложение с которым в последствии взаимодействует пользователь. Обычно разработка разделяется на серверную и фронтальную часть.

Серверные разработчики пишут программно-аппаратную часть сервиса. Работа с базой данных, API.

Frontend разработчик отвечает за визуальную часть сервиса, с которым взаимодействует пользователь.

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

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

Ритуалы

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

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

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

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

Chapter

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

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

Вся нагрузка ложится на него в дополнение к той которую несет на себе каждый участник чаптера.

Tribe

Когда в компании много команд и подразделений коммуникация между ними может стать проблемой. Здесь и возникают Трайбы.

Трайб — это совокупность команд объединенных одной миссией.

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

Сервисные команды

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

Источник

Agile на 11 000 сотрудников

Сбербанк существует на рынке уже 176 лет. В нём обслуживаются 140 млн физических лиц и 2 млн корпоративных клиентов. Компания представлена в 22 странах, в ней трудятся более 300 000 специалистов.

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

Изучив опыт иностранных финансовых институтов и успешных компаний Кремниевой долины, банк построил собственную модель работы, учитывающую основные принципы гибкой разработки Agile — в банке её называют Sbergile.

«В отличие от технологических гигантов и финтех-компаний, Сбербанк не был компанией, функционирующей по принципам Agile, с самого начала. Однако мы продемонстрировали, что эту философию управления 21 века можно успешно внедрить. И пользоваться её преимуществами для компании и клиентов — независимо от количества работающих сотрудников.

Благодаря этому подходу мы значительно повысили скорость работы: например, путем сокращения времени вывода продукта на рынок до нескольких недель по сравнению с несколькими месяцами ранее. И смогли помочь нашим клиентам сохранить самый драгоценный ресурс — время» — Герман Греф, глава Сбербанка, на Давосском форуме 2018.

С тех пор топ-менеджмент лидирует Agile-трансформацию, а Сбербанк стремится стать ИТ-компанией с банковской лицензией. Продуктовая линейка должна быстро адаптироваться под запросы рынка.

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

Коллектив поделили на племена

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

«Agile-трансформация в Сбербанке сконцентрирована в трех основных областях: удовлетворенность клиентов, продуктивность сотрудников и улучшение ключевых показателей: таких как время, необходимое для принятия решений, вывода продукта на рынок и поставки продукта клиентам» — Герман Греф.

Более 11 000 сотрудников, работающих в Sbergile, поделены на трайбы (от английского tribe — племя).

Каждый трайб — это агломерация команд, объединенных вокруг какой-то общей бизнес-цели, например, развития карточных продуктов.

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

Цели каждого трайба вытекают из стратегии развития банка и формируются лидерами трайбов при участии топ-менеджмента банка.

Каждый квартал кураторы трайбов вместе с лидерами трайбов обсуждают цели на ближайшие три месяца.

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

После этого команды декомпозируют эти цели на конкретные задачи в бэклоге и делят на спринты (такт работы команды, в ходе которого создаётся новая версия продукта).

Примеры трайбов, в каждом из которых работает от сотни до нескольких сотен человек (сейчас более 20 трайбов): «Эквайринг и банковские карты», «Платежи и переводы», «Занять и сберегать» — названия говорят сами за себя, Digital business Platform — «Сбербанк Онлайн», веб- и мобильное приложение для различных устройств.

Это одновременно и самостоятельные продукты, и канал для других продуктов.

Внедрение гибкой разработки — это непрекращающийся эксперимент.

Разные трайбы находятся в разной стадии зрелости с точки зрения использования Agile-практик.

Кто-то в стадии формирования и перехода, а кто-то уже полностью работает в логике Agile.

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

А команды, в свою очередь, из специалистов. В каждой команде работает от 9 до 12 человек, которые в разных пропорциях делятся на категории — бизнес и ИТ.

Прямая коммуникация между ними сама по себе ускоряет работу.

Но объединение разработчиков и бизнеса — недостаточное условие для повышения скорости и качества разработки.

Все сотрудники, переходящие на систему гибкой разработки, проходят обязательное обучение по специальной программе «Основы Sbergile», которую проводят Agile-коучи.

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

«Agile-коуч относительно новая профессия на рынке. В России не так много людей, которые имеют опыт работы в этой роли. Поэтому в банке работают коучи с разным бэкграундом. Кто-то в прошлом скрам-мастер, кто-то имеет большой опыт фасилитации и разработки.

Есть специалисты, которые работали тренерами в Кремниевой долине, спецы с продуктовой экспертизой. Часть коучей — это сотрудники банка, которые прошли специальный отбор и переквалифицировались на этапе перехода в Agile.

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

Все встречаются на церемониях

Команды могут отличаться друг от друга в зависимости от целей и продукта, но в целом все играют по одинаковым правилам.

Эти правила — в том числе обязательные для всех команд церемонии — дисциплинируют и помогают командам двигаться быстрее:

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

Ежедневный стендап. Команда обсуждает планы на день. Каждый участник отвечает на три вопроса:

1. Что я делал вчера для достижения цели спринта?

2. Что я буду делать сегодня?

3. С какими проблемами и препятствиями я столкнулся?

Демонстрация. Презентация результатов двухнедельного спринта, на которой команда собирает независимую обратную связь по своему MVP (Minimum Viable Product — минимальный жизнеспособный продукт).

На встрече присутствует лидер чаптера — человек, который контролирует работу специалистов одной области знаний в разных командах.

Продуктовая синхронизация. Синхронизация бэклогов команд (в том числе из разных трайбов), работающих над одним продуктом.

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

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

Portfolio marketplace. Синхронизация команд и выявление взаимозависимостей на уровне трайба. Присутствуют владельцы продуктов, лидер трайба, лидеры чаптеров, коучи.

Квартальный обзор результатов трайбов. Синхронизация между трайбами, расставление приоритетов. Встречаются лидеры трайбов, руководители ИТ- и бизнес-подразделений.

Культура непрерывно подпитывается

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

Сложнее и важнее — создать среду, в которой все участники процесса обогащают друг друга знаниями и проявляют инициативу.

Общая коммуникация строится через привычные каналы — новости, мероприятия, рассылки, видеоблог.

Внутри каждого трайба для общения выбирается та среда, которую выбирает коллектив.

«У каждого трайба свои особенности — они как отдельные субкультуры. Организовывают свои мероприятия, ездят вместе в горы, путешествуют.

Некоторые трайбы ежемесячно проводят тематические завтраки, например, «Кем я хотел быть в детстве». Это лишний повод пообщаться друг с другом и сблизиться.

Коммуникация строится не только линейно, то есть на уровне трайбов, но и между ними — люди объединяются в сообщества на почве личных и профессиональных интересов.

Такие сообщества называются «гильдиями», где люди, помимо общего досуга, делятся знаниями и обсуждают общие задачи.

Ежедневно в офисе проходят митапы на разные темы: от дизайна до блокчейна. Их инициируют и проводят сами сотрудники».

Пространство офиса подчинено культуре

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

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

У лидеров трайба нет собственных кабинетов — все они сидят вместе с командами.

Источник

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

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

Источник