Jak stworzyłem zaangażowany zespół programistów?

It doesn't make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do 

- Steve Jobs

Absolutna większość znanych mi programistów to mniejsi lub więksi pasjonaci. Każdy z nich pisze - lub przynajmniej kiedyś pisał - coś dla siebie: zestaw skryptów, aplikację dla dziewczyny, czy projekt open source. Spędza przy tym długie godziny, poprawia, przerabia, szuka lepszych rozwiązań, rozwija, często przy tym uczy się nowych technologii lub narzędzi. Za darmo, bez nadzoru, bez zewnętrznej motywacji.

Z punktu widzenia managera byłoby wspaniale, gdyby z podobnym zaangażowaniem pracownik podchodził od zadań w pracy. Jednak bardzo często pasja zarezerwowana jest dla własnych projektów, a w godzinach pracy trzeba ,,odklepać taski z Jiry”, by potem pójść do domu.

Jak uczynić projekty firmowe tak atrakcyjnymi, by pracownik zaangażował się w nie jak we własne? Czasami dzieje się to samo - projekt odpowiada zainteresowaniom pracownika lub pozwala mu łatwo identyfikować się z użytkownikami. Zdecydowanie częściej jest to jednak niemożliwe. Trudno, by 25-letni programista z Polski wczuwał się w potrzeby użytkowników, jeśli są nimi emeryci z USA albo matki rodzin wielodzietnych ze Skandynawii. Nie wykrzesa też z siebie entuzjazmu, by rozwijać ,,nudny” system księgowy.

Mój sposób na radzenie sobie z tym problemem składa się z dwóch metod, które stosuję jednocześnie:

1. Wartościowe cele 

Szukam elementów lub aspektów tworzonego oprogramowania, które można potraktować jako cele warte identyfikacji. Nie chodzi tu o mityczną ,,jakość kodu”, bo to bardzo rzadko bywa celem biznesowym, ale rzeczy takie jak stabilność systemu, skalowalność, przepustowość już jak najbardziej tak. Każdy duży system da się podzielić lub zdefiniować jego parametry, które będą atrakcyjne dla inżyniera.

Przykładowo: sam system marketingowo-wysyłkowy może być nudny i ,,niefajny”, ale jeżeli za cel postawimy ilość wysyłanych wiadomości na sekundę, zmieniając domenę problemu - z biznesowego na inżynieryjny - o zaangażowanie będzie dużo łatwiej.

2. Wpływ na projekt

Daję ludziom poczucie, że to, co tworzą jest w jakiejś części ,,ich''. Umożliwiam pracownikom jak największą możliwą decyzyjność, bo nic nie buduje poczucia własności i odpowiedzialności (ang. ownership) tak jak możliwość wcielenia w życie własnych rozwiązań - czyli po prostu robienie rzeczy ,,po swojemu”. Staramy się bardziej, gdy działający system udowadnia, że podjęliśmy dobrą decyzję i pracujemy bardziej wytrwale, by naprawić ewentualnie błędną. Decyzje mogą dotyczyć wszystkiego - technologii, architektury, narzędzi, nawet terminów.

Dodatkową zaletą tak zorganizowanych zespołów jest stosunkowo niska potrzeba oversightu. Kiedy ludzie uznają projekt za swój, dużo ważniejsze staje się usuwanie przeszkód, niż dodatkowa motywacja.

Rola managera

W tak zorganizowanym środowisku manager powinien stale czuwać nad tym, by:

• ambicje i cele zespołu współgrały z celami biznesowymi
• zespół lub pojedynczy programiści nie uciekli w ciekawe, ale niepotrzebne zagadnienia inżynieryjne (które nigdy się nie zwrócą)
• zapobiegnać naturalnej tendencji programistów do ulepszania czegoś bez końca (wzmaga się im bardziej czują się związani z produktem lub jego częścią)

Oczywiście, nie każdy programista będzie czuł się dobrze w powyższym środowisku, trzeba więc kształtować zespół mając to na uwadze. Samodzielność, komunikacja, pewność siebie - to cechy, na które warto stawiać nacisk przy rekrutacji i doborze pracowników. Stawia to także dość wysokie wymogi co do poziomu umiejętności, więc jest to metoda raczej dla doświadczonych zespołów - co nie znaczy,  że zupełnie wyklucza juniorów/stażystów. Z mojego doświadczenia wynika, że ludzie bardzo szybko przyswajają umiejętności w tego typu otoczeniu. Bo jeżeli seniorzy czują się dumni z istniejących rozwiązań, szybciej przekazują wiedzę. I łatwiej jest się pochwalić, niż przyznać, że dany system zbudowało się ,,na odczepnego”.

Jak każda metoda, taki sposób organizacji ma też pewne efekty negatywne. Na pewno może powodować zwiększone tarcia wewnątrz lubi pomiędzy zespołami. Chcemy, by osobom w teamie zależało na projekcie, co czyni ich bardziej stanowczymi i mniej skłonnymi do kompromisów. Po drugie, system ten premiuje silne osobowości, a to - w połączeniu z faktem, że programiści zazwyczaj nie są mistrzami w komunikacji i rozwiązywaniu konfliktów - może prowadzić do sytuacji nieprzyjemnych. Trzeba monitorować komunikację i wkraczać, gdy potrzeba. Albo włączać w zespołu osoby o zdolnościach mediacyjnych.

Taka organizacja pracy to też brak możliwości totalnej kontroli nad pracownikami. Jest antytezą micromanagementu, a jej istota to zwiększanie samodzielności pracowników, a nie kontrola nad nimi.

PS:
Ten temat budzi wielkie zainteresowania nie tylko wśród HRowców, ale także Team Leaderów. Zaangażowanie w zespole IT jest niezwykle istotne dla całego projektu. Piotr opowiedział o tym na konferencji Bitspiration, a my mamy to nagranie. Z tego case study dowiesz się, jak zadziałała w praktyce sprawdzona na własnej skórze metoda budowy zaangażowanego zespołu IT. Poznasz jej efekty na przykładzie międzynarodowej firmy z branży technologicznej. Metoda opata na idei odpowiedzialności i poczucia własności ("ownership") tworzonego oprogramowania lub systemu.