Как в условията на кофти архитектура и липса на Scrum умения създадохме екипи от различни компоненти

Привет!

Казвам се Александър и ръководя IT развитие в UBRD!

През 2017 г. ние от Центъра за развитие на услугите в областта на информационните технологии към UBRD осъзнахме, че е дошло времето за глобални промени или по-скоро за гъвкава трансформация. В условията на интензивно развитие на бизнеса и бърз растеж на конкуренцията на финансовия пазар две години са впечатляващ период. Ето защо е време да обобщим проекта.

Най-трудното нещо е да промените мисленето си и постепенно да промените културата в организацията, където е обичайно да мислите: „Кой ще бъде шефът в този екип?“, „Шефът знае по-добре какво трябва да правим“, „ Ние работим тук от 10 години и познаваме нашите клиенти по-добре.” , ние знаем от какво имат нужда.”

Гъвкавата трансформация може да се случи само когато самите хора се променят.
Бих подчертал следните основни страхове, които пречат на хората да се променят:

• Страх от загуба на власт и "еполети";
• Страх да не станеш ненужен за компанията.

След като поехме по пътя на трансформацията, избрахме първите „опитни зайци“ - служители на отдела за търговия на дребно. Първата стъпка беше да се препроектира неефективната ИТ структура. След като измислихме целева концепция за структурата, започнахме да сформираме екипи за разработка.

Архитектурата в нашата банка, както и в много други, е меко казано „боклук“. Огромен брой приложения и компоненти са монолитно свързани помежду си чрез DB връзка, има ESB шина, но тя не изпълнява предназначението си. Има и малко ABS.

Преди формирането на Scrum екипи възникна въпросът: „Около какво трябва да бъде събран екипът?“ Концепцията, че има продукт в кутията, разбира се, витаеше във въздуха, но просто извън обсега. След дълго мислене решихме, че екипът трябва да бъде събран около посока или сегмент. Например „Team Credits“, който развива кредитирането. След като решихме това, започнахме да измисляме целеви състав от роли и набор от компетенции, необходими за ефективното развитие на тази област. Подобно на много други компании, ние взехме предвид всички роли, с изключение на Scrum Master - по това време беше почти невъзможно да се обясни на CIO каква е ролята на този прекрасен човек.

В резултат на това, след като обяснихме необходимостта от стартиране на екипи за разработка, стартирахме три екипа:

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

С набор от роли:

1. Мениджър развитие (технически ръководител)
2. предприемач
3. анализатор
4. Тестер

Следващата стъпка беше да се определи как ще работи екипът. Проведохме гъвкаво обучение за всички членове на екипа и настанихме всички в една стая. В отборите нямаше ПО. Вероятно всеки, който е направил гъвкава трансформация, разбира колко е трудно да се обясни ролята на PO на бизнеса и още по-трудно е да го поставиш до екипа и да му дадеш авторитет. Но ние „влязохме“ в тези промени с това, което имахме.

С толкова много приложения, включени в процесите на кредитиране и останалата част от бизнеса с търговия на дребно, започнахме да мислим кой може да е подходящ за тези роли? Разработчик на един технологичен стек, а след това гледате - и имате нужда от разработчик на друг технологичен стек! И сега сте намерили тези, които са необходими, но желанието на служителя също е важно нещо и е доста трудно да принудите човек да работи там, където не му харесва.

След анализ на работата на бизнес процеса по кредитиране и дълги разговори с колеги, най-накрая намерихме средно решение! Така се появиха три екипа за разработка.

Каква е следващата?

Хората започнаха да се делят на такива, които искат промяна и такива, които не искат. Всеки е свикнал да работи в условията на „поставиха ми проблем, аз го направих, оставете ме на мира“, но екипната работа не предполага това. Но решихме и този проблем. Общо 8 от 150 души се отказаха по време на промените!

Тогава започна веселбата. Нашите междукомпонентни екипи започнаха да се развиват сами. Например, има задача, за която трябва да имате умения в областта на CRM разработчика. Той е в отбора, но е сам. Има и разработчик на Oracle. Какво да направите, ако трябва да решите 2 или 3 задачи в CRM? Учете се взаимно! Момчетата започнаха да прехвърлят компетенциите си един на друг и екипът разшири възможностите си, свеждайки до минимум зависимостта от един силен специалист (между другото, във всяка компания има супермени, които знаят всичко и не казват на никого).

Днес сме събрали 13 екипа за разработка за всички области на развитие на бизнеса и услугите. Ние продължаваме нашата гъвкава трансформация и достигаме ново ниво. Това ще изисква нови промени. Ще преработим екипи и архитектура и ще развием компетенции.

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

Източник: www.habr.com