Jak w warunkach tandetnej architektury i braku umiejętności Scrumowych stworzyliśmy zespoły cross-componentowe

Hi!

Nazywam się Alexander i kieruję rozwojem IT w UBRD!

W 2017 roku w Centrum Rozwoju Usług Informatycznych w UBRD zdaliśmy sobie sprawę, że nadszedł czas na globalne zmiany, a raczej zwinną transformację. W warunkach intensywnego rozwoju biznesu i szybkiego wzrostu konkurencji na rynku finansowym dwa lata to imponujący okres. Zatem czas na podsumowanie projektu.

Najtrudniej jest zmienić myślenie i stopniowo zmieniać kulturę w organizacji, w której powszechne jest myślenie: „Kto będzie szefem w tym zespole?”, „Szef wie lepiej, co mamy robić”, „ Pracujemy tu od 10 lat i znamy lepiej naszych klientów.”, wiemy, czego potrzebują.”

Zwinna transformacja może nastąpić tylko wtedy, gdy zmienią się sami ludzie.
Chciałbym podkreślić następujące kluczowe obawy, które powstrzymują ludzi przed zmianą:

  • Strach przed utratą władzy i „pagonami”;
  • Strach, że stanie się niepotrzebny dla firmy.

Wkraczając na ścieżkę transformacji, wyselekcjonowaliśmy pierwsze „doświadczone króliki” – pracowników działu retail. Pierwszym krokiem było przeprojektowanie nieefektywnej struktury IT. Po opracowaniu docelowej koncepcji konstrukcji zaczęliśmy tworzyć zespoły deweloperskie.

Jak w warunkach tandetnej architektury i braku umiejętności Scrumowych stworzyliśmy zespoły cross-componentowe

Architektura w naszym banku, jak i w wielu innych, jest, delikatnie mówiąc, „śmieciowa”. Ogromna liczba aplikacji i komponentów jest monolitycznie połączona łączem DB, istnieje magistrala ESB, ale nie spełnia ona swojego przeznaczenia. Jest też trochę ABS.

Jak w warunkach tandetnej architektury i braku umiejętności Scrumowych stworzyliśmy zespoły cross-componentowe

Przed utworzeniem zespołów Scrumowych pojawiło się pytanie: „Na czym powinien opierać się zespół?” Myśl, że w puszce znajduje się produkt, oczywiście wisiała w powietrzu, ale była poza zasięgiem. Po długim namyśle zdecydowaliśmy, że zespół powinien zostać skupiony wokół kierunku lub segmentu. Na przykład „Team Credits”, który rozwija akcję kredytową. Decydując się na to, zaczęliśmy wypracowywać docelowy skład ról i zestaw kompetencji niezbędnych do efektywnego rozwoju tego obszaru. Podobnie jak wiele innych firm, wzięliśmy pod uwagę wszystkie role z wyjątkiem Scrum Mastera – w tamtym czasie prawie niemożliwe było wyjaśnienie CIO, jaka była rola tej wspaniałej osoby.

W rezultacie po wyjaśnieniu konieczności uruchomienia zespołów deweloperskich uruchomiliśmy trzy zespoły:

  1. Kredyty
  2. Karty
  3. Operacje pasywne

Z zestawem ról:

  1. Menedżer ds. rozwoju (lider techniczny)
  2. Wywoływacz
  3. Analityk
  4. Próbnik

Kolejnym krokiem było określenie sposobu działania zespołu. Przeprowadziliśmy szkolenie zwinne dla wszystkich członków zespołu i umieściliśmy wszystkich w jednym pokoju. W zespołach nie było PO. Chyba każdy, kto przeszedł zwinną transformację, rozumie, jak trudno jest wytłumaczyć biznesowi rolę PO, a jeszcze trudniej posadzić go obok zespołu i dać mu władzę. Ale „weszliśmy” w te zmiany z tym, co mieliśmy.

Przy tak dużej liczbie aplikacji związanych z procesami kredytowymi i resztą działalności detalicznej zaczęliśmy się zastanawiać, kto może być odpowiednim kandydatem na to stanowisko? Twórca jednego stosu technologii, a potem patrzysz - i potrzebujesz programisty innego stosu technologii! A teraz znalazłeś tych, którzy są potrzebni, ale ważna jest także chęć pracownika i dość trudno jest zmusić osobę do pracy tam, gdzie jej się nie podoba.

Po przeanalizowaniu działania procesu biznesowego związanego z pożyczką i długich rozmowach ze współpracownikami w końcu znaleźliśmy złoty środek! W ten sposób wyłoniły się trzy zespoły deweloperskie.

Jak w warunkach tandetnej architektury i braku umiejętności Scrumowych stworzyliśmy zespoły cross-componentowe

Co dalej?

Ludzie zaczęli dzielić się na tych, którzy chcą się zmienić, i tych, którzy tego nie chcą. Wszyscy są przyzwyczajeni do pracy w warunkach „dali mi problem, zrobiłem to, dajcie mi spokój”, ale praca zespołowa tego nie oznacza. Ale i ten problem rozwiązaliśmy. Łącznie 8 na 150 osób odeszło w trakcie zmian!

Potem zaczęła się zabawa. Nasze międzykomponentowe zespoły zaczęły się rozwijać. Przykładowo istnieje zadanie, do którego wykonania potrzebne są umiejętności z zakresu programisty CRM. Jest w drużynie, ale jest sam. Jest też programista Oracle. Co zrobić, jeśli musisz rozwiązać 2 lub 3 zadania w CRM? Uczcie się nawzajem! Chłopaki zaczęli przekazywać sobie nawzajem swoje kompetencje, a zespół poszerzał swoje możliwości, minimalizując zależność od jednego silnego specjalisty (swoją drogą w każdej firmie są supermężowie, którzy wszystko wiedzą i nikomu nie mówią).

Dziś zebraliśmy 13 zespołów programistycznych dla wszystkich obszarów rozwoju biznesu i usług. Kontynuujemy naszą zwinną transformację i wchodzimy na nowy poziom. Będzie to wymagało nowych zmian. Przeprojektujemy zespoły i architekturę oraz rozwiniemy kompetencje.

Nasz ostateczny cel: szybko reagować na zmiany w produktach, szybko wprowadzać nowe funkcjonalności na rynek i ulepszać usługi banku!

Źródło: www.habr.com

Dodaj komentarz