Dev Team Experience. Poznaj framework, który zmieni Twój sposób zarządzania zespołami

Bolączki, z którymi na co dzień zderzają się managerowie i osoby zarządzające zespołami programistów, na koniec dnia odbijają się na zadowoleniu klienta. Niedowiezienie zakładanych rozwiązań na czas, niska jakość, sfrustrowany biznes i odchodzący programiści – te aspekty dają w kość każdej organizacji na którymś z etapów działalności. Czy nie chcielibyśmy, by było inaczej?

Zmotywowany zespół dowożący wysokiej jakości oprogramowanie na czas. Zadowoleni akcjonariusze oraz zadowoleni klienci, otrzymujący to, czego potrzebują. A co, jeśli powiem Wam, że jest to możliwe i wbrew pozorom stosunkowo proste do osiągnięcia? Wystarczy skupić się na ośmiu aspektach wpływających na dowożenie zespołu.

Geneza Dev Team Experience

Pracując z zespołami developerskimi przez ostatnie lata, zacząłem zauważać powtarzające się bolączki i powody, dla których nie mogliśmy dowieźć zamierzonych wartości w czasie. W Business Coders przeanalizowaliśmy doświadczenie każdego z nas i zbudowaliśmy solidny framework, w ramach którego jesteśmy w stanie pomagać naszym klientom znacząco zwiększać wydajność ich zespołów.

Nie od dzisiaj wiadomo, że programowanie to praca zespołowa. Czasy stereotypowego piwniczaka, który mógł ograniczać kontakt z ludźmi do minimum, są już dawno za nami. Współczesny programista jest częścią zespołu i chcąc/nie chcąc musi nauczyć się pracować w zespole. Dlatego w naszym frameworku skupiamy się na zespole jako najmniejszej jednostce organizacyjnej. Oczywiście, część sugestii dotyczy pojedynczych członków zespołu, mając na uwadze to, jak ich zadowolenie przekłada się na sukces całości.

Podejście, które nazwaliśmy Dev Team Experience, zawiera w sobie elementy klasycznego Developer Experience. Skupia się na doświadczeniach programisty w danym środowisku i wpływu różnych czynników na nie. Jednak dzięki spojrzeniu przez pryzmat zespołu zamiast pojedynczego programisty w połączeniu z elementami znanymi z „Team Topologies” Matthew Skeltona i Manuela Paisa oraz wyekstrahowaniu ośmiu aspektów wpływających na dowożenie zespołu, otrzymaliśmy fantastyczny framework dla wszystkich managerów i osób zarządzających zespołami programistycznymi.

Jak działa Dev Team Experience

W pierwszej kolejności wybieramy jeden z ośmiu powodów, dla którego zespoły programistyczne są w stanie dowozić. Weźmy na tapet jeden z prostszych, czyli posiadanie odpowiednich kompetencji. Aby cokolwiek z tym tematem zrobić, najpierw należy zastanowić się, jak możemy mierzyć poziom kompetencji. Nie ma większego sensu próba poprawiania czegoś, czego wartości nie znamy. I tak, w przypadku kompetencji, z pomocą może przyjść nam:

• macierz kompetencji w zespole (ang. competency matrix),
• stack technologiczny projektu (w formie listy, zebrany z diagramów takich jak C4,
• wyekstrahowany z Architectural Decision Record – ADR lub w inny sposób),
• guidelines na poziomie organizacji,
• CV członków zespołu i wiele innych.

Gdy już sprawdzimy, do jakich sposobów pomiarów mamy dostęp, przykładowo w naszej organizacji, mamy aktualne profile członków zespołu, guidelines z zakresem technologii na poziomie organizacji oraz diagram opisujący architekturę naszego rozwiązania. Możemy określić, czy poziom kompetencji jest wystarczający, a następnie sprawdzić, czy suma umiejętności członków zespołu pokrywa w 100% stos technologiczny projektu oraz czy każda technologia jest pokryta przynajmniej przez 2 lub 3 członków zespołu.

Każda organizacja może mieć nieco inny, akceptowalny dla niej stan rzeczy, dlatego nie podam tutaj złotych liczb, które zapewnią sukces. Najważniejsza jest świadomość, która w przypadku kompetencji zespołu może mieć jeszcze dodatkowy wymiar związany z podażą rynkową. Warto więc pamiętać, aby technologie organizacji były również w miarę popularne na rynku, abyśmy byli w stanie pozyskać nowych specjalistów w razie potrzeby.

Wracając do samego frameworka – gdy już znamy obecną wartość metryki związanej z kompetencjami zespołu i wartość, którą chcielibyśmy jako organizacja mieć, możemy zabrać się za dobór sposobów na jej zmianę. I tak, w przypadku kompetencji zespołu, aby zapewnić jego dowożenie, mamy kilka opcji:

• podnoszenie kompetencji istniejących członków (tutaj wchodzą wszystkie formy edukacji, jakie tylko mamy w głowie),
• restrukturyzacja zespołu (dodanie osób o innych umiejętnościach),
• zmiany technologiczne projektu – może warto dostosować tech stack pod
• zespół, jeśli obecny jest przestarzały lub trudny w utrzymaniu?

Wdrożenie

Po wybraniu zmian, które chcemy wprowadzić, możemy zabrać się za ich iteracyjne wdrażanie i monitorowanie skutków. Iteracyjne, ponieważ gdy zaczniemy modyfikować zbyt wiele, ciężko będzie ocenić wpływ jednego czynnika na efektywność i dowożenie zespołu.

W sposób, który opisałem – podejście do problemu braku kompetencji w zespole jako czynnika wpływającego na dowożenie – możemy spróbować rozwiązać pozostałe z ośmiu zdefiniowanych przez nas powodów. Wśród nich znajdziemy aspekty takie jak autonomia, wynagrodzenie, cel i inne. Dla każdego z powodów posiadamy szereg metryk, które możemy wykorzystać, aby określić stan dzisiejszy i ten, który chcielibyśmy osiągnąć.

Przyjrzyjmy się jeszcze kwestii autonomii. Bez odpowiedniej swobody, zespół ma związane ręce i nie może pracować wydajnie. Przyczyną tego mogą być różne podmioty, takie jak:

• bezpośredni przełożony,
• inny zespół,
• przełożony przełożonego,
• HR.

Problem z autonomią można odkryć, analizując zadania zespołu i ich zależności. Dodatkowo, informacje uzyskane od zespołu podczas retrospektyw lub spotkań 1:1 mogą również ujawnić ten problem.

Metryki związane z autonomią mogą obejmować:

• mapę zależności zespołów – a dokładniej ilość zależności wchodzących i wychodzących z analizowanego zespołu,
• ilość zadań w statusie „blocked” na tablicy zespołu,
• statystyki z rozmów 1:1 z managerem lub ankiet – ile osób z zespołu wskazuje brak autonomii jako problem.

Powyższe punkty również wskazują na sposoby mierzenia tych metryk: spotkania 1:1, ankiety w zespole oraz analiza mapy zależności zespołów.
Zgodnie z podejściem Dev Team Experience możemy teraz określić, do jakiego poziomu dążymy w kontekście tych metryk. Na przykład, musimy ustalić, ile zablokowanych zadań będzie dla nas akceptowalne oraz jak długo taka blokada może trwać. Mając te wartości, możemy przejść do sposobów rozwiązania problemu.

W przypadku braku autonomii związanej z ilością zablokowanych zadań, należy dodatkowo zweryfikować, co lub kto jest źródłem tych blokad. Jeśli są to inne zespoły, warto rozważyć:

• zmianę odpowiedzialności zespołów – przejęcie lub przekazanie odpowiedzialności może odblokować zablokowane zadania,
• zmianę struktury zespołu – połączenie dwóch zespołów w jeden może uspójnić cele i odblokować zadania.

W ten sposób, definiując problem autonomii, metryki z nim związane oraz ich docelowe wartości, możemy zacząć wdrażać powyższe rozwiązania stopniowo i monitorować ich wpływ na ilość zablokowanych zadań.

Zainteresował Cię temat Dev Team Experience? Skontaktuj się ze mną – opowiem więcej, a może uda się nam wspólnie poprawić działanie Twojego zespołu. Praca nad doświadczeniem zespołu programistycznego to inwestycja, która przynosi wymierne korzyści. Lepsza autonomia, zmniejszenie zależności i blokad, a także dbałość o metryki Dev Team Experience mogą znacząco podnieść efektywność zespołu, poprawić jakość dostarczanego oprogramowania oraz zwiększyć satysfakcję z pracy.

Nie czekaj, aż problemy narosną – zainwestuj w Dev Team Experience już teraz, a przekonasz się, jak pozytywny wpływ może to mieć na Twoją organizację.

Zdjęcie główne artykułu pochodzi z envato.com.