Як в умовах трешевої архітектури та відсутності навичок у Scrum ми створили крос компонентні команди

Привіт!

Мене звуть Олександр, і я керую ІТ розробкою в УБРіР!

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

Найскладніше – змінювати своє мислення та поступово культуру в організації, де прийнято міркувати: «а хто буде начальником у цій команді?», «начальник краще знає, що нам потрібно робити», «ми тут працюємо вже 10 років і знаємо краще за наших клієнтів знаємо, що їм потрібно».

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

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

Ставши на шлях трансформації, ми вибрали перших «досвідчених кроликів» – співробітників retail-напрямку. Насамперед провели редизайн неефективно працюючої структури ІТ. Придумавши цільовий концепт структури, розпочали формування команд розробки.

Як в умовах трешевої архітектури та відсутності навичок у Scrum ми створили крос компонентні команди

Архітектура в нашому банку, як і в багатьох інших, м'яко кажучи "трешева". Величезна кількість програм та компонентів, монолітно пов'язаних між собою DB link, є ESB шина, але вона не виконує своїх призначень. Також є кілька АБС.

Як в умовах трешевої архітектури та відсутності навичок у Scrum ми створили крос компонентні команди

Перед тим, як формувати scrum-команди, постало питання: «А довкола чого має бути зібрана команда?». Поняття, що у банку є продукт, звичайно, витало у повітрі, але на відстані недосяжності. Після довгих роздумів вирішили, що команда має бути зібрана навколо спрямування чи сегменту. Наприклад, "Команда Кредити", яка розвиває кредитування. Визначившись із цим, ми почали вигадувати цільовий склад ролей та набору компетенцій, необхідні ефективного розвитку цього напряму. Як і багато інших компаній, ми врахували всі ролі, крім Scrum Master — на той момент пояснити CIO, яка ж роль цієї чудової людини було практично неможливо.

Через війну після роз'яснень необхідність запуску команд розробки ми запустили три команди:

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

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

  1. Менеджер з розробки (Tech Lead)
  2. Дизайнер
  3. аналітик
  4. Тестувальник

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

Оскільки у процесах кредитування та інших напрямах роздрібного бізнесу було задіяно дуже багато додатків, ми почали думати, хто може підійти ролі? Розробник одного стеку технологій, а там дивишся — і потрібен розробник іншого стеку технологій! І ось ти знайшов тих, хто потрібен, але бажання співробітника теж важлива річ, і змусити людину працювати, там, де їй не подобається, досить складно.

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

Як в умовах трешевої архітектури та відсутності навичок у Scrum ми створили крос компонентні команди

Що далі?

Люди почали ділитися на тих, хто хоче змінюватись, і тих, хто не хоче. Всі звикли працювати в умовах «Мені завдання дали, я його зробив, відчепіться від мене», а командна робота цього не передбачає. Але й цю проблему вирішили. Усього за час змін звільнилося 8 осіб із 150!

Далі почалося найцікавіше. Наші крос-компонентні команди почали розвивати себе. Наприклад, є завдання, для якого потрібно мати скіли в області розробника CRM. У команді він є, але він один. Також є Oracle-розробник. Що робити, якщо потрібно вирішити 2 або 3 завдання у CRM? Вчити один одного! Хлопці почали передавати свої компетенції одна одній, і команда розширювала свої можливості, мінімізуючи залежність від одного сильного фахівця (до речі, у будь-якій компанії є супермени, які знають усі і нікому не розповідають).

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

Наша підсумкова мета: швидко реагувати на зміни продукту, швидко виводити на ринок нові фічі та покращувати сервіси банку!

Джерело: habr.com

Додати коментар або відгук