Привет!

Меня зовут Александр, и я руковожу ИТ разработкой в УБРиР!

В 2017 году мы в центре развития сервисов информационных технологий УБРиР поняли, что пришло время глобальных изменений, а точнее — agile-трансформации. В условиях интенсивного развития бизнеса и быстрого роста конкуренции на финансовом рынке два года – внушительный срок. Поэтому пришло время подвести итоги проекта.

Самое сложное – менять свое мышление и постепенно культуру в организации, где принято рассуждать: «а кто будет начальником в этой команде?», «начальник лучше знает, что нам нужно делать», «мы здесь работаем уже 10 лет и знаем лучше наших клиентов, знаем, что им нужно».

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

  • Страх потерять власть и “погоны”;
  • Страх стать не нужным для компании.

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



Архитектура в нашем банке, как и во многих других, мягко говоря “трэшевая”. Огромное количество приложений и компонентов, монолитно связанных между собой DB link, есть ESB шина, но она не выполняет своих предназначений. Также есть несколько АБС.



Перед тем, как формировать scrum-команды, встал вопрос: «А вокруг чего должна быть собрана команда?». Понятие, что в банке есть продукт, конечно, витало в воздухе, но на расстоянии недосягаемости. После долгих раздумий решили, что команда должна быть собрана вокруг направления или сегмента. Например, «Команда Кредиты», которая развивает кредитование. Определившись с этим, мы начали придумывать целевой состав ролей и набора компетенций, необходимых для эффективного развития этого направления. Как и многие другие компании, мы учли все роли кроме Scrum Master — на тот момент объяснить CIO, какова же роль этого чудесного человека, было практически невозможно.

В итоге после разъяснений о необходимости запуска команд разработки мы запустили три команды:

  1. Кредиты
  2. Карты
  3. Пассивные операции

С набором ролей:

  1. Менеджер разработки (Tech Lead)
  2. Разработчик
  3. Аналитик
  4. Тестировщик

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

Так как в процессах кредитования и остальных направлениях розничного бизнеса было задействовано огромное количество приложений, мы начали думать, кто может подойти на роли? Разработчик одного стека технологий, а там смотришь — и нужен разработчик другого стека технологий! И вот ты нашёл тех, кто нужен, но желание сотрудника — тоже важная вещь, и заставить человека работать, там, где ему не нравится, довольно сложно.

После анализа работы бизнес-процесса кредитования и долгих разговоров с коллегами мы все-таки нашли золотую середину! Так появились три команды разработки.



Что дальше?


Люди начали делиться на тех, кто хочет меняться, и тех, кто не хочет. Все привыкли работать в условиях «мне задачку дали, я ее сделал, отстаньте от меня», а командная работа этого не подразумевает. Но и эту проблему мы решили. Всего за время изменений уволилось 8 человек из 150!

Дальше началось самое интересное. Наши кросс-компонентные команды стали развивать сами себя. Например, есть задача, для которой нужно иметь скиллы в области разработчика CRM. В команде он есть, но он один. Также есть Oracle-разработчик. Что делать, если нужно решить 2 или 3 задачи в CRM? Учить друг друга! Ребята начали передавать свои компетенции друг другу, и команда расширяла свои возможности, минимизируя зависимость от одного сильного специалиста (к слову, в любой компании есть супермены, которые знают все и никому этого не рассказывают).

На сегодня у нас собрано 13 команд разработки на все направления развития бизнеса и сервисов. Мы продолжаем agile-трансформацию и выходим на новый уровень. Это потребует новых изменений. Мы будем редизайнить команды и архитектуру, будем развивать компетенции.

Наша итоговая цель: быстро реагировать на изменения продукта, быстро выводить на рынок новые фичи и улучшать сервисы банка!

Комментарии (10)


  1. WaRm
    27.06.2019 18:34

    Дизлайкнул случайно, промахнулся. Стать норм.


    1. AlexanderMezentsev Автор
      27.06.2019 22:17

      Спасибо!


  1. chilicoder
    28.06.2019 02:22

    > на тот момент объяснить CIO, какова же роль этого чудесного человека, было практически невозможно.
    А кто тогда драйвил трансформацию?


    1. AlexanderMezentsev Автор
      28.06.2019 06:56

      Драйвили мы с лидерами изменений. То есть все кому это было не безразлично.


      1. chilicoder
        28.06.2019 18:44

        > я руковожу ИТ разработкой в УБРиР
        пардон, просмотрел вашу должность.
        А как заручились поддержкой CEO и COO (если заручились)? и какие у вас отношения с CIO (кто кому подчиненный, кто какие задачи выполняет)?


        1. AlexanderMezentsev Автор
          30.06.2019 12:33

          С CIO отношения сугубо рабочие, на момент изменений CIO руководил 2-я направлениями: непрерывность в ИТ и развитие ИТ, если смотреть с точки зрения 5-й уровневой модели управления то CIO это 4-й уровень, я работаю на 3-м.
          Поддержкой заручались как и все наверное в компаниях, долгими обьяснениями необходимости изменений с приведением фактического состояния работы и целевого)


  1. Archi_Pro
    28.06.2019 10:28

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


    1. AlexanderMezentsev Автор
      30.06.2019 12:26

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


  1. szelga
    28.06.2019 11:16

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


    1. AlexanderMezentsev Автор
      30.06.2019 12:29

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