Gdy programista zostaje liderem

Napisano już tony książek na temat leadershipu i efektywności, które z pewnością masz gdzieś na dysku. Nie będę się więc silił na sformułowanie ogólnych zasad do wszystkiego, bo albo ktoś to już zrobił albo takowe nie istnieją :) Mam jednak parę spostrzeżeń na temat, tego o czym warto pamiętać, gdy do tej pory byłeś przede wszystkim programistą, a teraz zostałeś liderem programistów.

1. Akcja powoduje reakcję

Bywa, że programista zostający liderem, w przypływie entuzjazmu zaczyna mylić proaktywność z hiperaktywnością. Często myśli sobie: "do tej pory znosiłem ten kod, ale teraz wszystko się zmieni" i zaczyna zmieniać.

Sęk w tym, że każde rozpoczęte działanie, co jakiś czas "domaga się uwagi". Jeśli komuś coś zlecisz, to w końcu przyjdzie on z jakimś pytaniem na temat zadania. Im więcej działań rozpoczniesz, tym więcej aktywności będziesz musiał później podejmować - wykładniczo więcej. Świeżo upieczony lider, próbuje wprowadzić zmiany zakładając, że zmiana jest to proste przeprowadzenie stanu aktualnego w stan docelowy. Tymczasem jest to nieco bardziej złożone. Model wprowadzania zmiany podobny jest do tego przedstawionego na rysunku (w tym poście tylko skrótowo). Zainicjowanie zmiany to tylko początek, po jakimś czasie przychodzi kryzys, przez który należy zespół przeprowadzić. Bez aktywności lidera, zespół wróci do stanu początkowego, gdyż wtedy "jest źle, ale przynajmniej wiemy co trzeba robić". Z tego względu początkowa hiperaktywność prowokuje zbyt wiele kryzysów w zespole. Lider nie jest w stanie ogarnąć wszystkich i zmiana się nie udaje. Młody lider ma zazwyczaj wyrzuty sumienia. Myśli, że się nie nadaje do nowej roli i chce znów być programistą (@see kryzys w zmianie). Problem zazwyczaj nie tkwi w konkretnej osobie, lecz w niewłaściwym działaniu. Zacznij więc od wprowadzenia jednej zmiany, a gdy się ustabilizuje, pomyśl o kolejnych. Zanim zaczniesz jednak zmieniać, zastanów się co? i po co?.

2. Naucz się rezygnować

Tak to już jest, że najchętniej lubimy robić rzeczy, które nam wychodzą. Jeśli jesteś świetnym programistą i uczysz się jak być liderem, to będziesz często odczuwać pokusę, aby osobiście implementować zadania, z którymi nie mogą poradzić sobie programiści albo będziesz przydzielał sobie tyle samo zadań programistycznych co do tej pory. O tym, czy lider zespołu powinien programować i jak to godzić z zadaniami wynikającymi z roli lidera toczy się wiele dyskusji i jest wiele podejść do tego zagadnienia. Ja jestem przekonany co do jednego: niezależnie od tego, czy programujesz, czy nie Twoja optyka powinna być zawsze nakierowana na zespół. Twój sukces nie oznacza już sukcesu indywidualnego, lecz wprost zależy on od sukcesu zespołu, któremu przewodzisz. Możesz mieć co do tego pewne obawy, więc napiszę o nich wprost. Tak, nie będziesz programować tyle, co do tej pory. Tak, będą okresy, że nie będziesz programował w ogóle. Tak, możesz przestać być na czasie z nowinkami technologicznymi. Tak, szczegółowe zagadnienia dotyczące technologii, frameworków, mogą zacząć blaknąć w Twojej pamięci. Nie, nie zapomnisz jak się programuje. Tak, zaczniesz zauważać, że pewne klasy problemów rozwiązuje się w podobny sposób. Tak, jeśli wprowadzisz proces wymiany wiedzy, będziesz korzystał z wiedzy i doświadczenia programistów, aby na ogólnym poziomie być zorientowanym w temacie. Tak, będziesz zauważał, że niektórzy programiści popełniają błędy podobne do tych, które ty popełniałeś. Tak, rozwijanie umiejętności innych jest równie fascynujące jak rozwijanie własnych.

3. Nawyki są ważniejsze niż cele

Żyjemy w obsesji celów. Na każdej rozmowie rekrutacyjnej pytają o największe osiągnięte cele i porażki. Cele same w sobie są nudne. Większość z nas posiada umiejętność "spięcia się w sobie" i osiągnięcia jakiegoś tam celu. Jest jednak coś ważniejszego niż cele - nawyki. Gdyby nawyki i cele położyć na szali, to relacja między nimi jest taka, jak relacja między wartościami po prawej i po lewej stronie w Manifeście Agile. Czyli: wiemy, że cele są ważne i doceniamy je, lecz nawyki cenimy bardziej. Ironia polega na tym, że osiąganie celów bez nawyków (czyli jednorazowe pospolite ruszenie) może być męczarnią. Ale dzięki nawykom cele osiągają same. Jaki z tego pożytek dla lidera programistów? Ano, na przykład taki:

• nie zmuszaj ludzi, aby wymienili się wiedzą i za dwa miesiące byli zespołem cross-functional (jak to zmierzyć?), zamiast tego wprowadź zwyczaj regularnych (dobrze określonych w czasie) spotkań i dyskusji na tematy techniczne
• nie baw się w strażnika, który zagania ludzi do pracy, zamiast tego rób codzienne stand-up meetings
• nie ogłaszaj, że za pół roku system ma być zrefaktoryzowany w całości, zamiast tego wprowadź zwyczaj code review.

4. Wielkie problemy biorą się z małych zaniedbań

Nie chodzi o pedantyzm graniczący z obsesją. Chodzi o świadomość, że nasze działanie to niezliczone ilości ciągów przyczynowo-skutkowych, a końcowy skutek może stać się przyczyną dla kolejnych ciągów przyczynowo-skutkowych. Zupełnie jak to domino. Kiedyś napisałem wpis o refaktoryzacji "Myjcie swoje kubki", w którym chodziło o to, że lepiej regularnie robić drobne refaktoringi (@see nawyk), niż raz na jakiś czas wybebeszać pół systemu (tak, wiem, czasem jest to nieuniknione). Z perspektywy lidera jest podobnie. Jeśli coś Ci się w funkcjonowaniu zespołu rozstraja, reaguj od razu. Nie zwlekaj do momentu, aż drobny kłopot stanie się przyczyną kolejnego ciągu, i kolejnego, i kolejnego, aż możliwość reakcji przekroczy Twój zakres kompetencji.

5. Wielkie osiągnięcia biorą się z małych ulepszeń

Lider często ma marzenie, aby poustawiać wszystko tak, aby było dobrze i niech to to tak już zawsze działa. Po pierwsze nie ma żadnego "dobrze" i nie ma żadnego "na zawsze". Próba zorganizowania pracy zespołu tak, aby potrafił wykonać każde zadanie przypomina trochę implementowanie superelastycznych rozwiązań "na wszelki wypadek". Rzeczywistość tak niestety nie funkcjonuje, co nie oznacza, że jesteś tu bezradny. Pilnuj dwóch głównych zasad:

1. Szybko rozwiązuj problemy lokalnie
2. Lokalne rozwiązania standaryzuj tak, aby stały się częścią całego procesu

6. Wprowadzaj FRAMEworks i workFLOWs

(Nie mówimy teraz o bibliotekach programistycznych) Główną perspektywą patrzenia na zespół są procesy w nim działające. Słowa "framework" i "workflow", których częścią jest słowo "work" elegancko oddają, jak lider powinien organizować ową "work" w zespole. Przede wszystkim dla pracy powinien być zdefiniowany "frame". Ludzie muszą widzieć, że coś się dzieje według jakiegoś schematu. Na przykład tablica scrumowa nadaje "frame" pracy zespłu - "coś (karteczka) gdzieś musi się znaleźć (tablica), to coś na jakiejś podstawie (definition of done) przechodzi do kolejnego etapu (done), itd". Ludzie wiedzą: co mają zrobić, jak mają robić i kiedy skończyli.
Drugie słowo uwypukla "flow" procesu. Proces ma być płynny, bez zbędnych przestojów, bez zatorów, z optymalną ilością wykonywanej pracy. Na przykład "flow" w Scrumie stymulowane jest poprzez narzucenie stałych iteracji, mierzenie prędkości zespołu, nacisk na regularność, rytm, szybki feedback.

7. Działa tylko to, co robisz

Na koniec najcenniejsze, ale jak to zazwyczaj bywa - najbardziej oczywiste spostrzeżenie - żeby coś zadziałało, musisz to robić. Zadziwiające, że czasem gdy pracuję z zespołem omawiamy konkretne techniki, to wszyscy kiwają głowami - tak to jest ok, to jest ważne, a potem nikt nic nie robi i jednocześnie wszyscy są przekonani, że nie działa. Entuzjazm po szkoleniu trwa jakiś tydzień, potem się kończy i często kończy się noworozpoczęte działanie (@see kryzys w zmianie). Pamiętaj, konkretne techniki działają jeśli je robisz. Jeśli ich nie robisz, nie będą działać. Na przykład Daily Scrum. Zespoły, często robią, potem trochę im się spotkania przeciągają, czasem spotkanie odwołają, a w końcu stwierdzają, że wystarczy jedno w miesiącu. Jednocześnie wszyscy mają miliony racjonalizacji dlaczego to jest ok. Owszem, powody są nieraz ważkie, ale powiedzmy jasno: nie, nie, nie i jeszcze raz nie. W ten sposób Daily Scrum nie będzie działał. I to nie Scrum jest zły, tylko ktoś przed zastosowaniem nie przeczytał ulotki i teraz jest zaskoczony, że pojawiły się skutki uboczne. Myśl długo nad wprowadzeniem danej praktyki do zespołu, ale jeśli już wprowadzisz, to konsekwentnie ją kontynuuj i daj jej szansę zadziałać.