Jak stworzyć efektywny zespół programistów? Postawić przed nimi cel, zaangażować ich i zmotywować

Tomasz Krzyżak jako Software Development Manager zarządza 45-osobowym zespołem w warszawskim centrum technologicznym HL Tech, tworzącym rozwiązania IT dla brytyjskiej grupy Hargreaves Lansdown.

Karol Kopańko, Spider's Web: W ciągu dotychczasowej kariery byłeś liderem 6 zespołów. Obecnie budujesz siódmy, największy z jakim do tej pory miałeś okazję pracować. Co twoim zdaniem jest kluczowe w tworzeniu efektywnego zespołu?

Tomasz Krzyżak, HL Tech: Nie ma tu wielkiej filozofii. Odpowiedź na pytanie „co” jest bardzo prosta: cel, zaangażowanie, technical excellence. Jak to osiągnąć to już zupełnie inna sprawa. Każdy zespół i każda firma są inne. Mają swoje dobre strony, ale stoją również przed wyzwaniami. Moim zadaniem jest je zidentyfikować, wskazać cel i pomagać zespołowi do niego dojść. Pracuję również nad tym, aby stworzyć sprzyjające środowisko, w którym ludzie mają przestrzeń do nauki, eksperymentowania i rozwijania swoich umiejętności

Mówisz o dążeniu do celu w zespole. Jeśli nie jest on określony to….?

Jak zespół może być efektywny i wydajny, jeśli nie wie, co ma osiągnąć? Zespół bez celu nie może być ani efektywny ani wydajny – brak kierunku, brak motywacji, nieznany wpływ na otoczenie. Taki zespół może i będzie wykonywał dobrą pracę – jakość, ilość albo jedno i drugie, ale pytanie brzmi: czy jego praca wnosi wartość do organizacji, dla której pracuje?

W jaki sposób wyznaczasz ten kierunek ?

Do stawiania celu podchodzę zazwyczaj dwuwymiarowo. Z jednej strony musimy dostarczyć coś organizacji – w końcu po to jesteśmy zatrudnieni. Z drugiej strony mamy za zadanie wypracować proces częstego dostarczania tej wartości. Jedno i drugie jest ze sobą bardzo mocno powiązane –  częste dostarczanie oznacza częstą informację zwrotną, a to z kolei skutkuje lepszą wartością dla organizacji.

A co z zaangażowaniem? Jak motywować pracowników IT?

Podstawą zaangażowania zespołu jest autonomia i możliwość realizacji zadań w sposób, jaki zespół uzna za najlepszy. Trzeba jednak pamiętać, że każde rozwiązanie powstaje na potrzeby biznesu i ma spełniać określone funkcje. Ważne, aby zespół oraz biznes rozumiały się, a komunikacja między nimi była efektywna. Istotną rolę odgrywają tutaj analitycy IT, którzy są łącznikami między biznesem a zespołem programistów. Dzięki temu biznes otrzymuje produkt, który lepiej trafia w ich potrzeby, a zespół widzi, jak ważna jest ich praca. Dlatego zawsze staram się wciągać biznes w proces budowy.

Przykładowo, zakończyliśmy teraz program praktyk, do którego zgłosiło się blisko tysiąc kandydatów. Do współpracy zaprosiliśmy 10 praktykantów, którzy w ciągu trzech miesięcy mieli zbudować rozwiązanie dla naszej centrali w Bristolu. Istotnym elementem pracy nad aplikacją były regularne spotkania demonstracyjne, w których zespół chwalił się tym, co zrealizował w ciągu tygodnia lub dwóch, a biznes zgłaszał uwagi i zapotrzebowanie na nowe funkcje. Tydzień lub dwa później, przy kolejnym demo, biznes mógł zobaczyć je w praktyce.

I to jest kolejne wyzwanie. W HL Tech wyodrębniliśmy role tzw. Functional Liderów (frontend, backend, qa), czyli osób, których zakres odpowiedzialności wykracza poza pojedynczy projekt. Zadania tej roli to rozwój ludzi, wsparcie techniczne i merytoryczne, propagowanie wiedzy, standardów i konwencji. Lider funkcyjny nie jest przypisany do żadnego z projektów – pracuje ze wszystkimi. Spędza trochę czasu w każdym projekcie tak, aby znać potrzeby i podpowiadać odpowiednie rozwiązanie.

A czy są jakieś praktyki, stricte dla zespołów IT, które pozwalają na rozwój zespołu i podniesienie jego zaangażowania w ramach pracy nad projektem?

W odniesieniu do procesu rozwoju oprogramowania mówimy tu o tzw. continuous refactoring i automatyzacji. Continuous Refactoring to ciągła poprawa struktury/architektury systemu w miarę napływu nowych wymagań. Automatyzacja w każdym moim zespole była traktowana bardzo poważnie. Testy, wdrożenia, cokolwiek. Właściwie to perspektywa, że coś będzie musiało być zrobione więcej niż 3 razy jest poważna przesłanką do tego, żeby to zautomatyzować. Gwarantuję, że do tematu automatyzacji rutynowego zadania zespół podejdzie ze znacznie większym entuzjazmem niż do ręcznego wykonania tego zadania.

Jeśli chcemy coś ulepszyć to musimy wprowadzić zmianę. Mogą one przynieść niespodziewane efekty, więc można powiedzieć, że każda taka zmiana to rzeczywiście mały eksperyment. Ich natura z kolei jest taka, że jedne się udają, a inne nie. Jedne pchają nas do przodu, a inne nie. Nikt nie lubi porażek, a czasami strach przed nimi blokuje wszelką motywację do tego, aby osiągnąć sukces. Dlatego miejsce, gdzie każdy może podzielić się porażkami bez strachu przed konsekwencjami, wyrazić swoją opinię, eksperymentować, jest katalizatorem dla zmian i innowacji. I to jest właśnie zadanie dla managera. Stworzyć takie miejsce i taki zespół.

Tworzenie możliwości, przestrzeni do wymiany wiedzy, uczenia się to jedno z najważniejszych zadań managera, poważnie traktującego swój zespół. A możliwości jest wiele, od tych bardziej typowych jak szkolenia czy konferencje, firmowa biblioteka, po utworzenie stanowisk wspierających (wspomniany Functional Lead) czy zorganizowanie – tak jak to zrobiliśmy w HL Tech – wewnętrznych spotkań wymiany wiedzy – TechForum.

Każde takie spotkanie jest prowadzone przez inną osobę, która decyduje, jaką wiedzę i w jaki sposób chce przekazać innym. TechFora cieszą się u nas tak dużym zainteresowaniem, że wkrótce inicjatywę tę otworzymy również dla gości z zewnątrz. Z drugiej strony – trzeba się skupić na sobie i podnoszeniu swoich kompetencji, zwłaszcza miękkich. Zarządzanie zespołem to rzecz, której ciągle się uczę, zarówno poprzez codzienną pracę z zespołem, jak i na szkoleniach. Niestety nie ma tu tak jak jasnych wytycznych jak np. w dobrych praktykach programowania. Każdy zespół jest inny i tworzą się inne relacje, oczekiwania, atmosfera - czyli te niemierzalne aspekty, którymi trzeba zarządzić. Ale jest to wyzwanie, którego warto się podjąć.

Stosując się do tych wszystkich wskazówek – na jaki efekt mamy szansę?

Dam kilka przykładów. Branża hotelarska, system rezerwacji – zespół dostarcza średnio 150 zmian tygodniowo przy prawie zerowej liczbie zgłoszeń produkcyjnych.

Branża finansowa, aplikacja trade’ingowa – zespół dostarcza średnio 30 zmian produkcyjnych tygodniowo, ma możliwość detekcji błędu, naprawy i wdrożenia poprawki nawet zanim użytkownik go zgłosi.

Nie chcę jednak, aby ktoś odniósł wrażenie, że chodzi tu o wygraną w wyścigu o więcej wdrożeń – nie o to tu chodzi. Wysoka częstotliwość wdrożeń to tylko narzędzie, która pozwala nam osiągać kilka rzeczy. Najważniejszą jest to, że ograniczamy ryzyko wdrożeń. Niezgodne z intuicją, prawda?

Jak można zmniejszyć ryzyko przy wdrożeniu, wykonując je częściej, czyli de facto, wystawiając się częściej na to ryzyko? Odpowiedź jest prosta. Duża zmiana oznacza duże ryzyko, że coś zostało przeoczone, niewystarczająco przetestowane, źle zaprojektowane. Małe zmiany znacznie łatwiej jest przeanalizować, przetestować i ocenić wpływ na resztę systemu, przez co prawdopodobieństwo wystąpienie błędu znacząco się zmniejsza. Tym samym maleje ryzyko wdrożenia.

Widzę tylko same plusy!

Tak, korzyści jest wiele i mówić o ContinuousDelivery – bo tak to się nazywa – można by bez końca. Wspomnę o jeszcze jednej zalecie. Częste wdrożenia oznaczają częstą informację zwrotną od użytkowników. Stosowanie się do tych informacji zwrotnych daje nam gwarancję, że projekt idzie w poprawnym kierunku, a zaimplementowane funkcjonalności to rzeczywiście to, co użytkownikom jest potrzebne.

Praktyka ContinuousDelivery jest tak ważna, że w każdej firmie i w każdym zespole, w którym pracowałem, wkładałem wiele pracy, aby stała się rzeczywistością. Osobiście udało mi się wdrożyć CD w sześciu projektach, w branżach takich jak finanse, restauracje, hotelarstwo i kilka innych; w technologiach starych typu: EJB jak i nowych: springboot, kubernetes czy w architekturach mikroserwisowych, monolitycznych, rozproszonych.

Wydawać by się mogło, że idea CD pierwszy raz wspomniana 17 lat temu w Agile Manifesto to obecnie chleb powszedni w świecie IT – niestety tak nie jest. CD jest pierwszą z 12 zasad AgileSoftwareDevelopment, ale firm praktykujących CD jest bardzo niewiele – dlatego cały czas warto o tym mówić.

To skoro już mowa o sukcesach – co uważasz za największy w swoim życiu zawodowym?

W moim przypadku trudno chyba oddzielić życie zawodowe od prywatnego. IT to moja pasja. Obudziłem ją w sobie jako dziewięciolatek, gdy to na Commodore64 pisałem pierwsze programy. Pamiętam magazyn “Bajtek”, z którego przepisywałem kod źródłowy programu wyświetlającego ludzika ASCII, który na dodatek machał rękami. Nie do końca rozumiałem wtedy, co robię ale i tak miałem z tego wiele radości.

Cieszy mnie to, że utrzymałem w sobie tę pasję oraz to, że przez lata pracy w IT udawało mi się łączyć przyjemnie z pożytecznym. To znaczy, kształtować środowisko pracy i proces rozwoju oprogramowania, tak aby jednej strony ludzie byli szczęśliwi, a drugiej strony firma miała z tego ogromne korzyści.

Obecnie pracuję w prężnie rozwijającej się firmie dającej ogromne możliwości rozwoju, ale też stawiającej mocne wyzwania. Jestem dumny z zespołu, z którym obecnie pracuję. To są naprawdę najlepsi eksperci na rynku.

* Partnerem tekstu jest HL Tech.