Как в условиях трэшевой архитектуры и отсутствия навыков в Scrum мы создали кросс компонентные команды

Привет!

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

В 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-трансформацию и выходим на новый уровень. Это потребует новых изменений. Мы будем редизайнить команды и архитектуру, будем развивать компетенции.

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

Comments 10

    +1

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

    0
    > на тот момент объяснить CIO, какова же роль этого чудесного человека, было практически невозможно.
    А кто тогда драйвил трансформацию?
      0
      Драйвили мы с лидерами изменений. То есть все кому это было не безразлично.
        0
        > я руковожу ИТ разработкой в УБРиР
        пардон, просмотрел вашу должность.
        А как заручились поддержкой CEO и COO (если заручились)? и какие у вас отношения с CIO (кто кому подчиненный, кто какие задачи выполняет)?
          0
          С CIO отношения сугубо рабочие, на момент изменений CIO руководил 2-я направлениями: непрерывность в ИТ и развитие ИТ, если смотреть с точки зрения 5-й уровневой модели управления то CIO это 4-й уровень, я работаю на 3-м.
          Поддержкой заручались как и все наверное в компаниях, долгими обьяснениями необходимости изменений с приведением фактического состояния работы и целевого)
      +1
      спасибо за интересный пост
      Интересно было бы узнать как у вас внутри команд выстроена система постановки задач, приоритезации, трекинга времени на выполнение. Интересует все: кто ставит, какой инструмент используете, как выглядит постановка, что это канбан доска, аджаил доска или что то другое.
        0
        Спасибо за вопрос.
        Думаю про это стоит написать отдельную статью, о сквозной приоритезации, фиксации и трекинге времени, сбору метрик эффективности!
        Совсем скоро напишем про это.
        Но стоит отметить, что не все красиво получается, фэйлов достаточно много, я уже не говорю о сложностях.
        +1
        статья не особенно вдохновила. из положительных изменений сам автор, не я, отметил лишь уменьшение bus factor. остальное выглядит как условная «перестановка кроватей».
          0
          В большинстве выглядит именно так, сама трансформация процесс длительный и не простой, поэтому и результат виден лишь через какой то период времени.
          Хотя и кровати подвигать иногда прям необходимо)

        Only users with full accounts can post comments. Log in, please.