Jak zorganizować zespoły IT w dynamicznie zmieniającym się otoczeniu technologicznym? Każda organizacja jest inna i zmienia się. Podążać za tym powinno podejście do struktury i zadań zespołów oraz przewodzących im liderów. Pomimo licznych modeli i frameworków - jak Scrum czy Scaled Agile Framework (SAFe) - żadna struktura nie działa dobrze bez odpowiedniej analizy i zrozumienia szeregu czynników. Kluczem do skuteczności jest świadome projektowanie odpowiedzialności zespołów i liderów w zależności od kontekstu: architektury systemów, tempa rozwoju produktu, dojrzałości technologicznej, celów biznesowych oraz sytuacji na rynku. Pragnę podzielić się z liderami IT, w tym CIO, dyrektorami IT i liderami transformacji cyfrowej, doświadczeniem organizacji zespołów IT, które zdobyłem w firmach różnej wielkości i zróżnicowanej dojrzałości technologicznej. Omawiam również kluczowe wyzwania towarzyszące redefiniowaniu zakresu odpowiedzialności zespołów i liderów. Organizacja IT to złożony ekosystem zależności, historycznych decyzji i różnic w odpowiedzialności, który nie zawsze działa spójnie i efektywnie. Szczególnie w sytuacji, gdy struktura zespołów nie odpowiada architekturze systemów i dynamice decyzyjnej. Struktura organizacyjna wpływa na przepływ informacji, szybkość podejmowania decyzji i zdolność do adaptacji. Powinna ona wynikać nie tylko z modelu pracy, ale też z architektury systemu, kompetencji zespołu i oczekiwanego poziomu zaufania. Przydatna jest tu zasada Conweya, która mówi, że architektura organizacji będzie odzwierciedlona w architekturze budowanego systemu. W praktyce oznacza to, że budowany system będzie uwidoczniał podział organizacyjny, czyli granice odpowiedzialności (silosy) oraz kierunek, w jakim będzie się rozwijał i skalował system. Pracując przez prawie dwie dekady z różnymi firmami miałem okazję budować zespoły i całe organizacje dostarczające i utrzymujące złożone systemy IT. W tym czasie zaobserwowałem funkcjonowanie i ewolucję różnych modeli w rzeczywistych warunkach, doświadczyłem ich wad i zalet. Skalowanie modeli i zespołów Wraz z rewolucją Agile, która miała miejsce w ostatnich dwóch dekadach, standardem stały się małe i zwinne zespoły, dostarczające szybko wartość do klienta. W praktyce przyjęło się kilka uniwersalnych charakterystyk budowania zespołów IT, jak: cross-funkcjonalność – zespół powinien posiadać wszystkie kluczowe kompetencje potrzebne do realizacji celów – tak, aby ograniczyć konieczność angażowania jednostek spoza zespołu; samo-organizacja - rolą menedżera/lidera zespołu jest zadbać o to, aby zespół miał jasno postawiony cel oraz wszelkie potrzebne kompetencje i narzędzia do realizacji celu, a także wspierać zespół przy rozwiązywaniu problemów; mała struktura - zespół powinien liczyć nie więcej niż kilkanaście osób, ponieważ umożliwia to codzienne interakcje pomiędzy wszystkimi członkami zespołu, skupinie się na celu i działanie jak jeden zespół. W przypadku małych organizacji i systemów takie zasady powinny być wystarczające do ustalenia struktury IT. Wraz ze wzrostem skali i złożoności organizacji oraz systemu trzeba wziąć pod uwagę dodatkowe czynniki, takie jak: specyfika i tempo rozwoju produktu, architektura systemów, stos technologiczny, kompetencje i dojrzałość zespołów developerskich. W jednej z mniejszych firm, z którymi miałem możliwość współpracować w roli doradcy i lidera zmian, systemy były na tyle małe, że można było powierzyć odpowiedzialność za cały system jednemu zespołowi. Takie podejście ogranicza zależności pomiędzy zespołami do minimum, co daje dużą swobodę zespołom developerskim w planowaniu i dostarczaniu zmian, oraz utrzymaniu systemów. Dodatkowo, w tym konkretnym przypadku złożoność systemów rosła na tyle wolno, że dany model funkcjonował skutecznie przez wiele lat. Często jednak systemy są na tyle duże, że trzeba podzielić odpowiedzialność za ich rozwój i utrzymanie na kilka zespołów. Na rynku jest sporo narzędzi, które wspierają skalowanie organizacji IT, jak chociażby wspomniany SAFe. Firmy jednak często eksperymentują z różnymi modelami, aby dopasować strukturę do swoich potrzeb. Jednym z kluczowych parametrów, które trzeba wówczas wziąć pod uwagę jest architektura budowanych systemów. Obecnie najważniejszym standardem na rynku jest podział systemów zgodnie z metodą DDD (Domain driven design). Zakłada ona zdefiniowanie domen biznesowych oraz podział systemów na odpowiadające im komponenty. Komponenty powinny mieć jasno określone granice w obrębie jednej domeny i być luźno powiązane. Takie rozwiązanie dobrze wpisuje się w obecne trendy architektoniczne, np. styl architektoniczny oparty na mikro-serwisach. Wraz z podziałem systemów trzeba podzielić organizację na zespoły. Obowiązuje w tym wypadku podobna zasada skalowania, czyli dążenie do ograniczenia zależności pomiędzy zespołami. Takie podejście ułatwia planowanie, dostarczanie i utrzymanie systemów. Z mojego doświadczenia to właśnie zależności pomiędzy komponentami, systemami i zespołami stanowią największe wyzwanie w skalowaniu. To z kolei przekłada się na każdy etap cyklu rozwoju systemu. Co jednak, gdy w projekcie uczestniczy kilkanaście zespołów developerskich z różnych firm? Miałem okazję uczestniczyć w takim przedsięwzięciu w ramach dużej firmy sektora bankowego. Zastosowano tam wówczas podział organizacji na tzw. feature teamy. Zespoły feature – kiedy działają, a kiedy nie Koncepcja feature teamów zakłada podział na określoną liczbę cross-funkcjonalnych zespołów, gdzie każdy z zespołów dostarcza kompletne funkcjonalności systemu mające wartość dla klienta (feature). To podejście skupia się na szybkim dostarczaniu wartości biznesowej. Oznacza zarazem jasną odpowiedzialność za dostarczanie oraz ogranicza współzależności pomiędzy zespołami. Dany zespół ma możliwość modyfikacji każdej części systemu, każdego komponentu tak, aby dostarczyć pożądaną funkcjonalność. Koordynacja dostarczania funkcjonalności jest w tym przypadku prosta, ponieważ zazwyczaj ogranicza się do jednego zespołu. Podobnie jest w przypadku utrzymania, ponieważ błąd zgłoszony w danej funkcjonalności jest rozwiązywany przez zespół, który daną funkcjonalność zbudował. To podejście dobrze sprawdzało się na początku projektu, kiedy system był mały. Szybko jednak zauważono wady tego podejścia. Jedną z nich jest brak jasnej odpowiedzialności za komponenty systemu, czyli architekturę oraz stan techniczny poszczególnych komponentów. Utrudnia to utrzymanie systemu w dobrym stanie technicznym oraz zapewnienie spójności architektury. Te problemy można zniwelować poprzez większą koordynację, na przykład ustalenie struktury architektów wewnątrz projektu i regularne spotkania koordynacyjne. Jednak wraz z rozwojem systemu, wzrostem liczby komponentów i zespołów, koordynacja staje się coraz większym wyzwaniem. Dodatkowo rośnie wówczas także poziom wiedzy biznesowej i systemowej wymaganej do wprowadzania zmian. Wynika to z tego, że zespół feature, aby wprowadzić zmianę lub naprawić błąd, musi dotykać różnych komponentów systemu. Aby to zrobić szybko i skutecznie, musi posiadać wiedzę na ich temat. Problem ten narasta w przypadku wdrażania nowych członków zespołu. Czas wdrożenia wydłuża się a ryzyko błędu rośnie. W naszym przypadku ten problem stał się znaczący ze względu na sytuację na rynku pracy w Polsce. Wobec braku wystarczającej liczby doświadczonych programistów na rynku, rozbudowano program dla utalentowanych juniorów, tzw. talent program. Spowodowało to pojawienie się w zespołach większej liczby juniorów, ale wydłużało czas ich przysposobienia i podniosło ryzyko popełnienia błędów. Postanowiliśmy wówczas zmienić podejście na tzw. zespoły komponentowe. Korzyści i pułapki podejścia komponentowego Podejście oparte na zespołach komponentowych polega na przydzieleniu konkretnym zespołom odpowiedzialności za poszczególne komponenty. W tym przypadku są one możliwie skupione na wybranej domenie biznesowej oraz części systemu i luźno powiązane z innymi domenami oraz zespołami. Podnosi to wiedzę i szybkość wdrażania nowych członków zespołu, a co za tym idzie na szybkość dostarczania zmian i utrzymania poszczególnych komponentów. Dodatkowo, przy zdefiniowaniu zależności pomiędzy komponentami, np. poprzez komunikację REST lub kolejki, poszczególne zespoły mogą korzystać z różnych technologii. Wnosi to oczywiście ryzyko rozrostu stosu technologicznego firmy. Inną zaletą w tym modelu jest sposób utrzymania systemu. Zespoły skupiają się na poprawianiu błędów oraz potencjalnych usprawnieniach technicznych w swojej części systemu. Jak każde podejście, te również ma pewne wady. Planowanie zmian może być trudne w przypadku, gdy procesy biznesowe przechodzą przez wiele komponentów. Trudności występują na etapie planowania, wdrażania jak i utrzymania. Na etapie planowania pojawiły się trudności z definiowaniem wymagań biznesowych (backlogu) w taki sposób, aby każdy zespół miał je zdefiniowane niezależnie. Wymagało to zmiany podejścia do rozumienia produktu i podziału wymagań biznesowych. Równoległa praca w kilku zespołach oraz dostarczanie zintegrowanej funkcjonalności wymagały nieprzerwanej koordynacji zaangażowanych zespołów. Biznes oczekiwał przecież realizacji terminów dostaw. Także utrzymanie systemu i naprawa błędów po wdrożeniu wymagały modyfikacji podejścia. Teraz każdy zespół naprawiał błędy w swojej części systemu, więc potrzebna była koordynacja przydzielania zgłoszonych błędów do odpowiednich komponentów i zespołów. Zostało to rozwiązane poprzez utworzenie pierwszej linii wsparcia, która robiła wstępną analizę błędów. Bardzo pomocne okazało się narzędzie do orkiestracji mikro serwisów i śledzenia transakcji. Inną poważną wadą tego podejścia było nierównomierne rozłożenie pracy poszczególnych zespołów. Często w danym komponencie oraz zespole nie było wystarczająco wartościowej pracy, aby zapełnić cały czas, lub było jej za dużo. Model hybrydowy godzi różne podejścia i potrzeby Ostatecznie, po analizie doświadczeń z różnymi podejściami zdecydowaliśmy się wprowadzić model hybrydowy. Zespoły odpowiadają za komponenty, jego architekturę i kod źródłowy, a jednocześnie mogą pracować nad innymi komponentami, jeśli jest taka potrzeba, np. gdy inny zespół ma za dużo pracy. Zespół, który jest właścicielem komponentu nadal odpowiada za jakość końcową pracy, np. odpowiada za code review oraz zatwierdzenie zmian w architekturze. To podejście łączy zalety obu poprzednich. Ułatwia planowanie pracy, ogranicza zależności pomiędzy zespołami, eliminuje wąskie gardła związane z obłożeniem zespołów i ilością pracy, a zarazem buduje know-how w zespołach i nie rozmywa odpowiedzialności za dany komponent i kod źródłowy. Taki model, jeśli dobrze wdrożony, może być skuteczny nawet w systemach, gdzie dynamika zmian w poszczególnych komponentach jest duża. Liderzy w zmieniających się strukturach odpowiedzialności W firmach obowiązują różne modele przywództwa zespołów IT. W przypadku cross-funkcjonalnych zespołów działających w danych domenach biznesowych, najczęściej stosowane są dwa podejścia. W pierwszym wypadku menedżer jest odpowiedzialny za zespół całościowo (ludzie, rozwój kompetencji, dostarczanie i utrzymanie systemów). Innym rozwiązaniem jest model macierzowy. Odpowiedzialność za zespół jest podzielona na menedżera odpowiedzialnego za dostarczanie i utrzymanie (delivery/developement menedżer) oraz menedżera odpowiedzialnego za ludzi i rozwój kompetencji. Oba modele mają swoje mocne i słabe strony. Wybór modelu przywództwa zależy często do okoliczności, aby wspierać aktualną transformację organizacyjną lub wzmocnić dany obszar działalności. W jednej z firm miałem okazję być uczestnikiem transformacji z modelu menedżerów zespołów na strukturę macierzową a po pewnym czasie powrotu to poprzedniego, ale nieco zmodyfikowanego modelu. Głównym czynnikiem była zmiana sposobu myślenia zarządu, spowodowana rosnącą rolą IT w biznesie oraz zmianami na rynku pracy IT, zarówno w Polsce jak i za granicą. Znaczenie IT w bankowości rośnie szybko, ponieważ technologia leży u podstaw dominującego trendu „Bank tu i teraz, dostosowany do potrzeb klienta”. Dodatkowo, szybki wzrost zapotrzebowania na wykwalifikowanych ekspertów IT powoduje, że coraz trudniej było znaleźć odpowiednich ludzi oraz ich stawki szybko rosną. Firmy inwestują więc coraz więcej w rozwój kompetencji specjalistów IT. Warto dodać, że zmiana miała miejsce jeszcze przed dynamicznym rozwojem narzędzi opartych o AI, które dziś istotnie wpływają na możliwości zespołów i modele pracy. W poprzedniej strukturze, przed zmianą, menedżerowie byli odpowiedzialni za poszczególne działy, zazwyczaj kilka zespołów developerskich. Z perspektywy menedżera działu, priorytetem było dostarczenie zmian oczekiwanych przez biznes oraz utrzymanie systemów i spełnienie SLA. Zarządzanie ludźmi oraz rozwój kompetencji IT zazwyczaj schodziły na drugi plan. Dodatkowo, nie każdy menedżer miał odpowiednie kompetencje, aby kierować rozwojem swoich ludzi. Taka struktura nie wspierała więc rosnących potrzeb technologicznych oraz zmieniającego się rynku IT. Wraz ze zmianą CIO, wprowadzono zmiany w całej organizacji IT. Jedną z głównych zmian było wprowadzenie struktury macierzowej. Wyróżniono dwa rodzaje menedżerów: tych, którzy odpowiadają za dostarczanie i utrzymanie systemów oraz odpowiadających za ludzi i rozwój ich kompetencji. Menedżerowie o profilu bardziej biznesowym lub projektowym odpowiadają za dostarczanie, natomiast menadżerowie o profilu bardziej technicznym odpowiadają za technologię, ludzi i rozwój kompetencji. Największymi zaletami tego podejścia są efektywniejsze podjęcie wyzwania rozwoju ludzi oraz możliwość podziału odpowiedzialności zgodnie z mocnymi stronami menedżerów. Zmiana ta spowodowała znaczny wzrost aktywności w obszarze rozwoju kompetencji i dzielenia się wiedzą, jednak nie obyła się bez przeszkód. Transformacja wymagała odpowiedniego przygotowania i wsparcia. Trzeba było przyjąć, że nie wszyscy menedżerowie odnajdują się w nowych rolach. Dodatkowo, wszyscy menadżerowie tracą część dotychczasowej odpowiedzialności, co może rodzić ich niezadowolenie. Warto jest wesprzeć ich w tej zmianie. Kolejnym wyzwaniem jest podwójne źródło priorytetów dla pracowników. Menedżerowie delivery zwykle posiadają budżet na projekt i decydują o priorytetach zespołów developerskich. Natomiast menedżerowie kompetencyjni są odpowiedzialni za indywidualne cele poszczególnych pracowników oraz za ich ocenę roczną. Wymaga to ustalenia granic i większej współpracy pomiędzy menedżerami delivery oraz kompetencyjnymi. W przypadku dużych organizacji i zachowaniu płaskiej struktury leaderów, jak to miało miejsce w tym przypadku, zespół kompetencyjny może liczyć kilkadziesiąt osób. W efekcie menedżer techniczny musi poświęcać większość czasu na rozmowy z ludźmi, co często nie jest zgodne z jego kompetencjami ani preferencjami. W dłuższej perspektywie może przynieść to zniechęcenie i spadek efektywności. Pomimo wad, model ten utrzymywał się przez kilka lat, z niewielkimi zmianami. Ostatecznie model został zmieniony i powrócono do menedżerów zespołów. Utrzymała się jedynie niewielka grupka grupa liderów kompetencyjnych, którzy dbają o poszerzanie wiedzy w danej dziedzinie, ale już bez bezpośredniej odpowiedzialności za ludzi. Motywacją do tej zmiany była chęć wzmocnienia struktury dostarczania projektów biznesowych, co wpisuje się w obecne ambicje firmy. Próbować, adaptować, zmieniać Zamiast kopiować gotowe modele, warto projektować strukturę organizacyjną w oparciu o konkretne uwarunkowania: architekturę systemu, dojrzałość zespołu, tempo rozwoju oraz cele biznesowe. Modele organizacyjne powinny wspierać sposób pracy i dynamikę zmian, a nie je ograniczać. Każda organizacja IT jest inna. Dlatego kluczowe jest podejście iteracyjne - testowanie rozwiązań, wyciąganie wniosków i gotowość do ich adaptacji. Tylko takie podejście pozwala zbudować strukturę, która będzie nie tylko efektywna, ale też odporna na zmieniające się warunki biznesowe i technologiczne. Dominik Sawicki, Technology & Delivery Leader, Head of Software Development – SME Digital w banku Nordea
