Opowiem Ci historię. Zdawałoby się codzienną – pewnie sam podobną przeżyłeś/-aś. Jednak taka zwykła historia była dla mnie świetną inspiracją. Zmusiła mnie do przemyśleń na temat tego, co sprawia, że zespół (deweloperski) jest dobry?

Wkurza mnie to – rzekł kolega.

Czemu Cię to wkurza? – zapytałem, chociaż podskórnie wiedziałem, co odpowie.

Bo mi zależy – rzucił.

Może nerwy nie są najlepszym sposobem wyrażania zaangażowania, ale każdemu się zdarza irytować od czasu do czasu. I czasem będą one objawem niezgody na przeciętność, wąskie myślenie i tak dalej. Każdy członek tej ekipy był zaangażowany. I razem robili świetny produkt. Zaangażowanie to jedna z tych cech, która, według mnie, cechuje lepsze zespoły. Zacząłem się zastanawiać, co jeszcze ma ta grupa, a czego nie mają inne? Kilka moich przemyśleń znajdziesz w dalszej części tego tekstu. 

Prawdziwie interdyscyplinarny

Dobry zespół to m.in. taki, który sprawnie rozwiązuje stawiane przed nim problemy (np. jak zbudować aplikację XYZ). Jeśli brakuje mu narzędzi, umiejętności lub uprawnień, to problem będzie rozwiązywał dłużej lub ostatecznie polegnie. Prawdziwie interdyscyplinarne zespoły mają wszystkie narzędzia, umiejętności czy uprawnienia, które mieć powinny do rozwiązania danego problemu. To takie zespoły, które jak najmniej (najlepiej wcale) delegują na zewnątrz i mają jak najmniej (najlepiej wcale) zależności.

Przykłady są najlepsze, więc… Wyobraź sobie zespół Bravo. Zespół wytwarzał aplikację webową, składał się z back-end i front-end deweloperów oraz osoby odpowiedzialnej za jakość (QA). Na papierze i na pierwszy rzut oka miał on wszelkie umiejętności (specjalizacje), które były mu potrzebne do rozwijania aplikacji… Jednak głębsze przyjrzenie się sprawie ujawniło, że w rzeczywistości zawsze czekał kilka lub nawet kilkanaście dni na designy od zespołu projektantów UX/UI. Zamiast współpracować na co dzień z jedną osobą o specjalizacji dizajnera (jako integralną częścią – tak, jak każdy deweloper), zespół delegował tę funkcję na zewnątrz. W efekcie,zawsze musiał czekać w kolejce, wśród innych zespołów. Dodatkowo, co częste w takich sytuacjach, zespół nie miał jednego dedykowanego dizajnera w ekipie projektantów, bo wymieniali się oni zadaniami. Tym samym nie rozumieli tej aplikacji tak, jak rozumiałby ją „wewnętrzny” dizajner, pracujący na stałe w zespole.  

Jeśli jesteś liderem/liderką albo pełnisz inną rolę, która może wpływać na kształt zespołu i procesy, to możesz zadać sobie pytanie: skąd mam wiedzieć, czy zespół jest interdyscyplinarny? Polecam Ci zacząć od prostego ćwiczenia, które możesz na start wykonać samodzielnie. Zbuduj i przeanalizuj matrycę kompetencji. W dużym uproszczeniu: w jednej tabeli zestaw członków zespołu, a na drugiej osi wszystkie umiejętności, narzędzia i uprawnienia, które powinien mieć, aby być prawdziwie interdyscyplinarnym. Pozaznaczaj, które z nich zespół rzeczywiście posiada/potrafi, a następnie zaplanuj, jak uzupełnić braki. Zrobienie już tego pierwszego kroku i zrozumienie sytuacji to niemały krok w dobrą stronę. 

Skoncentrowany

Chcemy realizować wiele fajnych pomysłów. Ciągle dochodzą nowe. To świetnie! Problem w tym, że czasem oznaczać to będzie spory chaos. Jedną z przyczyn źle funkcjonujących zespołów są niejasne priorytety i brak koncentracji na tym, co rzeczywiście najważniejsze. Wiele zespołów się nie może skupić na tym, co ważne, bo ciągle chwytają nowe tematy, a Backlog zdaje się być niepoukładany. Co może z tym zrobić lider albo PM (Project Manager) w takim zespole? Zadbać o cel i priorytety. Brzmi jak banał? Czytaj dalej. 

W praktyce oznaczać to będzie pracę na kilku poziomach. Na bardziej ogólnym: zespół powinien zrozumieć wizję produktu, czyli to, po co oni to w ogóle robią i dla kogo jest ten produkt. Tu najczęściej wchodzi PM, bo to naturalnie osoba, która umie zarazić zespół swoją wizją. Jeśli deweloperzy będą znali wizję, to ich działania nabiorą pewnego kontekstu i będzie im dużo łatwiej na co dzień podejmować decyzje techniczne, a także sygnalizować sobie wzajemnie, gdy zadania odbiegają od tej wizji. Czasem proste prezentacje mogą zdziałać wiele – można zacząć od pierwszej, a potem regularnie odświeżać temat. 

Nie lubię mówić o celu czy pracy na celach. To stwierdzenia bardzo korporacyjne i sztywne, z reguły nie kojarzą nam się dobrze. Nie zmienia to jednak faktu, że są bardzo potrzebne: żeby zespół był skoncentrowany, musi wiedzieć, na czym ma się koncentrować. Cele, jakkolwiek sobie je zdefiniujemy, są narzędziem, które pozwala precyzyjniej niż wizja tę koncentrację ukierunkować. 

Całkiem ciekawym konceptem w przypadku zespołów produktowych są OKRy (Objectives and Key Results). Jak każde narzędzie i to ma swoje wady, nie będzie pasowało wszędzie, ale w zaskakująco wielu sytuacjach potrafi być niezłym sposobem ukierunkowywania wysiłków zespołu. Zabrakłoby nam miejsca w tym numerze Product Design Magazine, aby zgłębić ten temat, więc w dużym skrócie: zespół posiada nieco bardziej ogólny cel (np. poprawić wrażenia klientów, którzy korzystają ze strony) i do niego odpowiednio dobrane „kluczowe wyniki” (np. przyspieszenie ładowania strony z 12 do 7 sekund). Zachęcam do zgłębienia tego tematu – nawet jeśli OKRy wydadzą Ci się niewłaściwe, to może zainspirują Cię do tego, jak możesz definiować cele u siebie. Jak wyżej – cele wydają się korporacyjnym wymysłem, ale w takiej czy innej formie będą one potrzebne, aby pomóc kilku osobom obrać ten sam kierunek swoich wysiłków. 

Utrzymanie produktu jest procesem, który też potrafi nieźle dekoncentrować zespół. Obsługa wszelkiego rodzaju błędów, bugów, monitorowanie stanu zdrowia aplikacji – te wszystkie czynności potrafią zjadać sporo energii deweloperów. Można ten proces obsłużyć na kilka sposobów i nie będę ich wszystkich tu opisywał, ale najważniejsze (z punktu widzenia tego tekstu) jest to, żeby w ogóle mieć jakiś pomysł na proces utrzymania. Zbyt często zdarza się, że nie ustalamy, jak chcemy utrzymywać nasz produkt, więc działania deweloperów nie mają ram, każdy robi jak umie najlepiej, a to prowadzi do marnowania energii. 

Odpowiednio zaangażowany (zainteresowany produktem)

Członków naszych zespołów można, z grubsza, podzielić na dwie grupy. Jedną stanowią misjonarze – powiedzmy, że są to osoby bardzo zaangażowane w to co robią w pracy, jest to niejako ich misja. Drugą stanowią najemnicy – oni chcą po prostu robić swoje od 9 do 17 i wrócić do dużo ciekawszych i prywatnych spraw. Dla tej drugiej grupy najczęściej trzeba dostarczać zadania opisane od A do Z, przedstawić bardzo konkretne „wymagania”, bo często nie chcą wychodzić poza ścisłe obowiązki (kodowanie) i mniej angażują się w poszukiwanie usprawnień – mniej z ich strony inicjatywy i tej pasji, która charakteryzuje osoby zaangażowane.

Każda z takich postaw ma swoje wady i zalety. Na przykład najemnicy mogą fajnie pasować do zespołów, w których dużo rzeczy trzeba utrzymywać, a także tam, gdzie znamy dobrze rynek i użytkowników, czyli niewiele nas zaskakuje i chcemy po prostu szybko wykonać zadanie. Jeśli potrzebujemy, aby krążyły kreatywne soki, chcemy odkrywać nowe, tworzyć coś innowacyjnego, to im więcej w nas zaangażowania, tym łatwiej będzie to osiągnąć. Z misjonarzami łatwiej o pasję, pewnego rodzaju ogień, który powoduje, że dyskusje są kreatywne i owocne. Najemnicy nie mają złej postawy – jest po prostu inna, wymagająca innego podejścia, tworząca inną atmosferę.

Jak można zaangażować deweloperów? 

W zespole Charlie, budującym zupełnie nową rzecz na rynku, wszyscy byli zakręceni na punkcie produktu, który tworzą. A to za sprawą bardzo dobrego Product Managera, który świetnie umiał wyjaśnić wizję biznesową, wciągał zespół w dyskusje o problemach użytkowników. Jak to robił? Przede wszystkim zaczął od pokazywania prawdziwych zachowań i opinii użytkowników. To zaciekawiło, pojawiały się głosy, że rzeczywiście klient może mieć problem z obsługą danej funkcji w ich apce, że jest mało intuicyjna. Następnie PM zaczął dorzucać różnego rodzaju dane analityczne, jak konwersja, liczba użytkowników, churn rate (miara tego, ile osób rezygnuje z zakupu lub subskrypcji). Zespół zaczął się wciągać i obserwować wyniki, jak zmieniają się po ich wdrożeniach. Sukcesy i porażki zachęcały ich do dalszych eksperymentów. Mało tego – deweloperzy zaczęli zgłaszać swoje pomysły na odwrócenie niekorzystnych trendów!

Na tym powyższym przykładzie przytoczyłem Ci przypadek, który sam obserwowałem. Zespół zainteresowany produktem i tym, jak bardzo lubią go użytkownicy, będzie działał lepiej. To dla tych użytkowników robimy nasze apki, strony, produkty i jeśli nam nie zależy na opinii użytkowników, to będziemy dostarczali co najwyżej poprawne rozwiązania. Liderzy i PM–owie mogą zatem:

• regularnie opowiadać o wizji produktu,
• zdobywać opinie użytkowników i dzielić się nimi z zespołem,
• dzielić się wynikami biznesowymi,
• wciągać w dyskusje (zamiast przynosić gotowe rozwiązania, podać problem i zadbać o kreatywną wymianę myśli). 

Sprawny (procesowo)

To, jak pracujemy, ma ogromny wpływ na to, jakie uzyskujemy efekty. Zatem? Proces! W przypadku zespołu deweloperskiego mowa m.in. o takich aspektach:

• jak pracujemy z Gitem i innymi narzędziami deweloperskimi (np. jak łatwo cofnąć zmianę produkcyjną, ile czasu trwa wdrożenie zmian na produkcję),
• jak pracujemy z Backlogiem i tablicą,
• skąd bierzemy nowe pomysły i jak je przetwarzamy (np. priorytety),
• jak robimy burzę mózgów.

Takich „procesów w procesie” jest jeszcze więcej. Każdy z nich wpływa na to, jak sprawnie zespół pracuje (niekoniecznie chodzi o samą „szybkość”). Jak to ogarnąć? Uff, nie jest łatwo! Ale damy radę, małymi kroczkami.

Zespół powinien regularnie odbywać Retrospektywy, rozmawiać o tym, co działa i co jest do poprawienia. Retro to narzędzie na poziomie zespołu właśnie, które zapewnia doskonalenie procesu. To minimum. Małe kroki nie kosztują wiele, a zmiany bywają znaczne. Według mnie Retro to rzecz obowiązkowa. Napisałbym „obowiązkowa” wielkimi literami, ale nie wypada.

Można też, i tu najcześciej zainicjują sprawę Scrum Masterzy czy liderzy, zmapować swoje procesy, od pomysłu do wdrożenia. Jak przebiega taka droga? Na podstawie takiej mapy być może uda się zrozumieć, gdzie i dlaczego warto coś zmienić. Mapa taka może być świetnym tematem rozmów w gronie zespołowym, ale też w szerszej strukturze (np. z menedżerami). 

Nie da się przecenić także roli wszelkiego rodzaju list „z blokerami”. Najczęściej inicjują ich powstanie Scrum Masterzy lub osoby w podobnych rolach. Są to tablice kanbanowe lub inne formaty, które zawierają listę problemów, z którymi zespół (lub zespoły) się mierzy. Takie problemy mają najczęściej pozazespołowy charakter (trudno je rozwiązać na sesji Retro czy samodzielnie, bo są to np. zależności między komponentami, wąskie gardła na zewnątrz) i tablica posłuży śledzeniu postępów w rozwiązywaniu takich problemów. Taka tablica może być przedmiotem dyskusji w gronach menedżerskich, między różnymi grupami, i może pomagać rozwiązywać problemy „globalnie”.

Zgrany

Ostatni temat, ale wcale nie najmniej ważny. Chemia. Zgranie. To wszystko, co ciężko zmierzyć, a sprawia, że dobrze się pracuje. Tak, jak wyżej mogłem podać przykłady dość uniwersalnych narzędzi, aby sprawić, że zespoły będą stawały się lepsze, tak w przypadku zgrania sprawa jest nieco trudniejsza. Bo nie chodzi już o rzeczy bardzo twarde, które sobie jakoś nazwiemy, zmierzymy i jednym działaniem rozwiążemy. Co więcej: początki zgrania (lub niezgrania) zespołu zaczynają się już na samym początku. Rekrutacja to pierwszy moment, w którym coś może pójść nie tak. Nowy członek firmy, którego charakter i kultura są niekompatybilne z tymi, które panują wewnątrz organizacji czy grupy, to użo potencjalnych problemów! Czasem sprawdzamy kandydata pod kątem technicznym, jakie ma doświadczenie (ile już zrobił), ale równie często powinniśmy zastanowić się nad tym, czy on będzie pasował do naszego grona.

Pewna firma, zanim powie kandydatom „tak, chcemy z Tobą pracować”, zaprasza ich na 1 dzień wspólnej pracy, poznawania się. Nie tylko kandydaci oceniają przyszłych pracodawców, ale też ekipa w firmie może sprawdzić, czy na pewno dzielą ten sam mindset. Nie wiem, czy to idealny sposób na sprawdzenie tej kompatybilności, raczej nie, ale jest to jakiś sposób – zawsze lepszy niż pozostawienie sprawy samej sobie.

To, co możemy zrobić po zatrudnieniu, jako liderzy lub członkowie zespołów, to budować szanse na to, aby członkowie grupy jak najlepiej się poznawali, mieli okazje się docierać. Bardzo ważne będą narzędzia takie, jak:

• dobry onboarding, wejście do zespołu,
• jasno określone role i oczekiwania,
• regularne integracje (nauka i praca poprzez zabawę),
• dobre Retrospektywy.

Jeśli źle dobraliśmy członków zespołu, to powinniśmy umieć zmienić tę decyzję. Najgorsze, co możemy zrobić, to trwać w sytuacjach konfliktowych, akceptować toksyczne zachowania. Między ludźmi nie musi zawsze być wiosennie, że muszą być kwiaty, słońce. Może być też bardziej pochmurnie i zimowo, ale rzecz w tym, żeby nie pozostawiać tego tematu i reagować, gdy okazuje się, że członkowie nie pasują do siebie. 

Podsumowanie

Liczę na to, że ten tekst zainspirował Cię do refleksji o Twoim zespole. Te 5 cech nie jest oczywiście pełną listą – to po prostu moje subiektywne spojrzenie na temat. Jednak sądzę, że to spojrzenie dość uniwersalne i pokrywa całkiem spory zakres tego, jakie zespoły to dobre zespoły deweloperskie. Zachęcam Cię do świadomego działania w tym temacie. Bo na koniec dnia nie chodzi o to, że zespół musi być dobry, bo to jakiś korporacyjny, biznesowy slogan. W dobrych zespołach lepiej się pracuje, a w pracy, jakby nie było, spędzamy całkiem sporą część życia. Dlaczego zatem nie spróbować na to wpłynąć?