Code review, PoC i talenty Gallupa. Jak to się spina w zespole technologicznym?

CliftonStrengths mówi, w czym jesteś dobry. Nie mówi jednak, dlaczego akurat to decyduje o sukcesie projektu IT. Zobacz, jak zderzyliśmy popularny test 34 talentów z realiami dowożenia oprogramowania, code review i komunikacji z klientem.

Test, którego się nie spodziewaliśmy

Talenty w zespole technologicznym spinają się wtedy, gdy przestajemy traktować je jak ładne etykiety, a zaczynamy używać ich jako narzędzi do codziennej pracy. Zrobiliśmy pełny test 34 talentów Gallupa, spodziewając się typowego, korporacyjnego „personality-résumé". Zamiast tego dostaliśmy coś znacznie bardziej użytecznego: język do nazwania procesów, które w zespole robimy odruchowo, tylko wcześniej nikt nie potrafił ich precyzyjnie opisać.

CliftonStrengths dzieli 34 talenty na cztery domeny: Strategic Thinking (myślenie strategiczne), Relationship Building (budowanie relacji), Influencing (wywieranie wpływu) i Executing (wykonywanie). W teorii żadna domena nie jest „lepsza" od pozostałych. W praktyce, w zespole, który ma dowieźć oprogramowanie na czas i w budżecie, to właśnie proporcje między nimi decydują, czy projekt faktycznie się domyka, czy tylko dobrze wygląda na etapie planowania.

Wizjoner, który w rzeczywistości jest egzekutorem

Raport wskazał, że jeden z naszych kolegów prowadzi Strategicznym Myśleniem (Ideation i Strategic to jego top 2). Łatwo byłoby na tym poprzestać i przypiąć sobie w biogramie łatkę „wizjonera". Taka etykieta dobrze wygląda w prezentacji dla klienta, ale niewiele mówi o tym, jak ktoś naprawdę pracuje przy komputerze o dziewiątej rano w środku sprintu.

Gdy jednak spojrzał na pełną dziesiątkę, okazało się, że aż 4 z 10 talentów należą do domeny Executing: Focus, Achiever, Responsibility i Arranger. To znacznie więcej niż samo myślenie koncepcyjne. Innymi słowy: osoba, którą cały zespół intuicyjnie nazwałby „tą od pomysłów", w rzeczywistości jest tą, która te pomysły najskuteczniej zamienia w konkretne zadania z deadline'em.

Co to oznacza w praktyce programistycznej i codziennym delivery?

• Ideation + Strategic + Input – burza mózgów nie kończy się na slajdach w prezentacji, których ostatecznie nikt nie wdroży. Wymiana myśli sprawnie przechodzi w konkretny plan działania, bo ten sam talent, który generuje pomysły, od razu widzi, w jakiej kolejności trzeba je zrealizować.

• Empathy + Developer – code review przestaje być polowaniem na błędy. Staje się merytoryczną rozmową o rozwoju kodu i programisty, w której komentarz „to trzeba poprawić" zamienia się w pytanie „co Cię tu blokowało i jak mogę pomóc to rozwiązać następnym razem".

• Focus + Achiever + Responsibility – to główny powód, dla którego Proof of Concept (PoC) zamyka się w ustalonym terminie, a nie ląduje w szufladzie z etykietą „dokończymy później, jak będzie czas". Achiever nie pozwala uznać dnia za udany bez odhaczonego zadania, Focus filtruje to, co naprawdę ważne, a Responsibility sprawia, że nikt nie musi tego pilnować z zewnątrz.

• Arranger – to talent, który najmocniej widać w chaosie, nie w spokoju. Gdy priorytety w sprincie zmieniają się we czwartek po południu, bo klient zgłosił pilną poprawkę, ktoś z tym talentem naturalnie przekłada zasoby, terminy i osoby tak, żeby nic nie wypadło z kalendarza – zamiast czekać na nowy plan „od góry".

• Communication – klient poznaje ewentualne ryzyka techniczne na etapie planowania, zanim wybuchną one na produkcji. Zamiast maila po fakcie z tytułem „mamy problem", dostaje wcześniej jasną informację, co może pójść nie tak i jaki jest plan B.

Nie tylko jedna osoba – jak to się układa w całym zespole

Ten sam raport pokazał coś jeszcze: zespół, który dobrze ze sobą pracuje, rzadko składa się z ludzi o identycznych profilach talentów. Osoby silne w Strategic Thinking świetnie prowadzą fazę odkrywania i planowania architektury, ale to talenty z domeny Relationship Building i Influencing sprawiają, że ustalenia z tej fazy w ogóle docierają do reszty zespołu i do klienta w formie, która przekonuje, a nie tylko informuje.

Nic z tego nie jest odkryciem. To rzeczy, które w zespole robiliśmy od dawna – ktoś zawsze naturalnie ogarniał logistykę sprintu, ktoś inny zawsze łagodził napięcia po trudnym demo. Test tylko je nazwał i pokazał, że dobra praca zespołowa to konkretny układ talentów, a nie szczęśliwy zbieg okoliczności, który trudno powtórzyć przy kolejnym projekcie.

Zastrzeżenie: test nie zrobi za nas najtrudniejszej roboty

Żaden test nie zastąpi pracy nad tym, żeby się dogadać. CliftonStrengths nie nauczy nikogo empatii, jeśli jej wcześniej nie było, i nie odbędzie za nas trudnej rozmowy po nieudanym sprincie. To narzędzie do nazywania, nie do zwalniania z odpowiedzialności.

Warto też pilnować, żeby wynik nie zamienił się w gotową wymówkę albo stałą etykietę. „Nie mam talentu Focus" nie jest usprawiedliwieniem dla braku terminowości, tak samo jak wysoki wynik w Empathy nie oznacza, że ktoś zawsze będzie miał ochotę wysłuchiwać cudzych problemów. Talenty opisują naturalne skłonności, a nie limity – i zdecydowanie nie powinny być jedynym kryterium rekrutacyjnym ani podstawą do oceny okresowej.

Robiliście kiedyś taki test w zespole? Dajcie znać, czy Wasze wyniki pokrywały się z tym, jak faktycznie pracujecie na co dzień – czy raczej zaskoczyły Was bardziej, niż się spodziewaliście.