Cześć,
w tym artykule zamierzam skupić się na sześciu najważniejszych lekcjach z zakresu zarządzania sobą w czasie, które są cenne dla programistów (oraz osób wykonujących podobnych zawody). To rozróżnienie jest istotne i wynika z mojego doświadczenia szkoleniowego.
Nie jest to artykuł na zasadzie: „losowo wybrać sześć zasad zarządzania czasem, dopisać <<dla programistów>> i artykuł gotowy”. Powstał on jako wniosek z przemyśleń, dlaczego z wielu wartościowych koncepcji, developerzy wymieniają jako najbardziej przydatne akurat te, które wymienię w artykule. Z początku byłem nieco zawiedziony, że uczestnicy „nie doceniają” tak ważnych aspektów, jak np. konflikty wewnętrzne czy zasoby kognitywne, a skupiają się na bardziej przyziemnych, użytkowych kwestiach. W końcu zrozumiałem, że jeśli szkolenie jest prowadzone w kontekście konkretnej pracy, to uczestnicy będą wybierać te elementy, które akurat w tej pracy, a nie w całym życiu jako takim, przyniosą im największe efekty.
Dlatego wymieniam i krótko opisuję sześć takich wniosków w kolejności od najmniej ważnego (aby budować stopniowo napięcie ;P ).
6. Uzasadnienie oczekiwanego sukcesu projektu jest zwykle niewystarczające
W tym kontekście jako produkt możemy rozumieć również pewną innowację, pomysł na usprawnienie procesu. Jeżeli jest prosty, wymaga zaledwie kilku akcji, wtedy nie ma sensu za bardzo go analizować, bo efekt będzie najlepszą odpowiedzią. Jednak, jeśli zakładamy szereg działań w ramach takiego projektu, a tym bardziej długofalową pracę, to warto nabrać naprawdę konkretnego przekonania, że jego cel zostanie osiągnięty.
Może to dotyczyć planu na automatyzację testów, dodania nowej funkcjonalności do istniejącego produktu, bądź stworzenia całkiem nowego. Każdy przypadek widziałem co najmniej raz w swojej karierze. Nierzadko zdarza się, że rezultaty są dalekie od oczekiwanych. Argument, który często się wtedy pojawia to: „ale jak mieliśmy to przewidzieć na etapie projektowania?”. Otóż tym zajmuje się cała dziedzina, zwana prototypowaniem. Polega właśnie z grubsza na tym, aby odpowiedzieć na pytanie: jak można minimalnym kosztem przetestować dane rozwiązanie? Pytanie to pada zdecydowanie zbyt rzadko, zwłaszcza wtedy, kiedy nie ma na nie oczywistej odpowiedzi. To jest właśnie takie miejsce, gdzie słynna już „kreatywność”, tak często jako słowo nadużywana, mogłaby znaleźć idealne zastosowanie.
Sama metodyka również nie wystarcza, a wręcz może uśpić czujność. Jeśli są regularne przeglądy sprintu, to dlaczego mielibyśmy robić coś nie tak? Pytanie jednak, czy taki przegląd odpowiada tylko na pytanie „czy dana funkcjonalność działa i rozwijana jest zgodnie z planem”, czy też idzie dalej, by zastanowić się, „czy dana funkcjonalność, w formie takiej jakiej powstaje faktycznie realizuje cele biznesowe?”. Może to wynikać np. z braku odpowiednich osób podczas spotkania, lub też ze sprowadzania całego przeglądu sprintu do „demo”.
Nie chcę jednak, by nacisk padł tutaj na metodykę. Przeciwnie, chciałem podkreślić, że nawet jeżeli zgodnie z takową pracujemy (czy aby na pewno zgodnie?), to nie powinno to uśpić naszej czujności. Życzeniowe myślenie w kontekście sukcesu projektu jest częstym problemem; na tyle częstym, że pytanie „jak przetestować to rozwiązanie przyzwoitym kosztem” powinno nam wejść w krew. Również w kontekście projektów nie-informatycznych.
5. Retro jest dobre, kiedy jest dobre
Zdania na temat przeprowadzania retrospektywy są podzielone, co chcę omówić w osobnym artykule. Jednak nie dziwi mnie to, jeżeli weźmiemy pod uwagę błędy, które można popełnić przy tym spotkaniu.
Jeżeli na retro omawiane są ciągle te same kwestie, ale nic się nie dzieje w temacie ich poprawy (np. dług techniczny, zależność od danego klienta itd. i nic się z tym nie robi), to łatwo wyciągnąć wniosek, że nic się nie zmienia, a dyskusje są jałowe i przewidywalne.
Jeżeli zadania z retro nie są nigdzie wykorzystywane i przypisywane, również nie sprzyja to budowaniu poczucia skuteczności tego spotkania i prowadzi do wniosku, że jest ono „sztuką dla sztuki”.
Jeżeli z drugiej strony, z każdej retrospektywy płynie kilkanaście wniosków, które jako „proces improvement” zalegają później w backlogu (lub innym miejscu), to również jest to niejawny komunikat: „nie jest to ważne”.
W skrócie można powiedzieć, że retro powinno się kończyć niewielką liczbą zadań do zrobienia, które następnie są śledzone jak normalne zadania (bo są normalnymi zadaniami). Natomiast za tym, dlaczego tak nie jest, stać może wiele „czynnika ludzkiego”.
Tutaj chciałbym dać krótki wniosek: retrospektywa może być zarówno bardzo potrzebna, jak i kompletnie bezsensowna, w zależności od tego, jak jest prowadzona i (co nieoczywiste) co dzieje się z wnioskami po niej.
4. Żadna informacja nie jest przyswajana za darmo
Zalew maili do przeczytania rano potrafi zepsuć dzień już na starcie. Często maile te dotyczą sharingów, czyli np. co w innej części firmy udało się osiągnąć, jakie nowe narzędzie wykorzystał jeden z programistów albo jakie są cele działu XY.
Wiele osób nie jest zainteresowanych czytaniem takich maili, jednak ma pewną obawę, że jeśli ich nie przeczytają, to przełożonemu (lub komuś innemu) to się nie spodoba. Wiele tych maili ma pewną wspólną cechę: operują na zasadzie „coś takiego jest”. Czyli założeniem nie jest to, żeby zrozumieć, jak dane narzędzie działa, albo dlaczego cel jest taki, a nie inny. Być może wpisy powstają z takim założeniem, ale co się z nimi dzieje dalej, to już inna bajka. A wgłębienie się w temat wymaga czasu i zasobów uwagi.
Owo „coś takiego jest” posiada pewien sens. Jeżeli „czymś takim” jest np. sposób, w jaki ktoś rozwiązał problem, który pojawia się w jednym projekcie, to może i w innym będzie się dało z tej wiedzy skorzystać. Pytanie jednak, czy skoro celem jest „wiedza, że jest coś takiego”, to warto czytać całe artykuły i poświęcać im cenne minuty?
Skoro celem jest powiadomienie o istnieniu czegoś, to można to zrobić w zbiorczym mailu z jakimś zestawieniem?
Problemem jest tu często argumentacja, że przecież lepiej wiedzieć, niż nie wiedzieć. Ta argumentacja jest BŁĘDNA. Zestawia ze sobą sytuację, w której ktoś coś wie z sytuacją, kiedy tego nie wie, ale nie zrobił niczego innego. Tymczasem to jest właśnie problem, bo pozyskanie informacji, zwłaszcza takiej, która w jakikolwiek sposób jest znacząca (meaningful) jest obarczone wysiłkiem poznawczym. Generuje koszty alternatywne, czyli niezrobienie czegoś innego.
Dlatego konkretne akcje, które rekomenduję w takim wypadku to:
- Konkretne zawężenie obszaru maili sharingowych, które dany zespół/przedstawiciel roli ma przeglądać
- Określenie celu przeglądania tych maili, jeśli się tego od podopiecznych wymaga (celem jest wiedza, że coś takiego jest, czy też wiedza głęboka uwzględniająca zrozumienie, jak dany problem jest osadzony w kontekście)
- Zniechęcenie podopiecznych do aktywnego śledzenia nadmiaru maili/wpisów sharingowych, a zachęcenie, by czytać ich mniej, ale zrobić konkretny użytek chociaż z jednego
- Samodzielnie, jako manager rozważenie, jaka część maili sharingowych faktycznie dała wartość i czy wartość ta nie może być przekazana drogą alternatywną (np. podczas prezentacji w firmie).
Oczywiście dla nie-managerów radą może być rozmowa ze swoim szefem lub choćby samokontrola w tym obszarze, jeżeli nie ma nacisków „z góry”.
Dodatkowo apeluję o zauważenie bardzo ważnej rzeczy: przyswajanie wiedzy bez kontekstu rodzi złe nawyki zyskiwania powierzchownej wiedzy, która w wielu wypadkach daje iluzję zrozumienia, ale wysypuje się zupełnie przy próbie zastosowania.
Czyli okazuje się, że ktoś niby sprawia wrażenie, jak dużo wie, ale gdy ma coś zrobić, pojawia się mnóstwo (podobno) niemożliwych do przewidzenia problemów.
A niestety czytanie maili ze zbyt szerokiego spektrum projektowego będzie stawiało czytelników przed wyborem: czytać bez kontekstu, lub znaczącym nakładem sił wyrobić kontekst. Manager w imię wszechobecnego rozwoju może rekomendować wyrobienie kontekstu, ale powinien wtedy zadać sobie pytanie: kosztem czego to rekomenduję?
3. Jawna dekompozycja to przyjaciel Twojego umysłu
W momencie, w którym nasz umysł spotyka się z trudnym zadaniem (zwykle o dużej złożoności), uaktywnia się jego część, zwana jądrem migdałowatym, która odpowiada za reakcje obronne. Reakcje te były adekwatne w czasach, kiedy człowiek hasał jeszcze z dzidą i uciekał przed tygrysami. W kontekście pracy programistycznej wolelibyśmy jednak, żeby jądro migdałowate siedziało cicho. Stan fizjologiczny do ucieczki przed tygrysem nie jest najbardziej potrzebny podczas siedzenia z naszym ulubionym IDE. Zamiast tego wolelibyśmy wyrzut dopaminy, który pojawia się, gdy umysł dostaje sygnał „radzę sobie”. Taki sprawiający, że w praktyce nudne zadania stają się ciekawymi, a trudne – łatwymi.
Ile zapłacił(a)byś za suplement, który pozwala, że praca nad zadaniami będzie wiązać się z tą drugą, a nie z pierwszą reakcją? Czyli suplement, który uaktywnia jedną część mózgu, a ucisza drugą. Tak, mam ten suplement, zaraz podam Ci linka, oczywiście mam program partnerski z jego twórcami …
Stop!
Nie ma żadnego suplementu. I nie musisz za niego płacić. Tym magicznym działaniem jest dekompozycja. Jeśli zabierasz się za duże zadanie, rozpisz je na mniejsze części (często jeszcze zespół będzie Ci wdzięczny, bo od razu pojawią się konkretne zadania, które zwiększą widoczność Twojej pracy), a te następnie na jeszcze mniejsze. Ja osobiście zaczynam pisać kod od komentarzy w sekcjach, co dane kilka linii ma robić. W ten sposób dokonuję dekompozycji. Na każdym szczeblu ta dekompozycja może mieć inny charakter, powinna jednak być jawna (zapisana).
Np. dzieląc dużą funkcjonalność na mniejsze części mogę tworzyć osobne zadania, które idą swoim workflow (nie powinno to rzecz jasna uderzać w metodykę, ale może paradoksalnie ją wspierać, ułatwiając np. testowania zadania). Dekomponując dalej mogę podzielić zdanie na moduły/klasy i zdefiniować jakie są relacje między nimi (mogę to zrobić w kodzie, niekoniecznie robiąc diagram UML, z którego większość z nas śmiała się na studiach). Następnie przychodzi czas na metody, a w ramach nich na sekcje opisane przez komentarze. Przez cały czas umysł dostaje sygnał „radzę sobie”, zarówno przy dzieleniu, jak i później przy wypełnianiu sekcji kodem (bo np. podział powinien uwzględniać też architekturę i wydajność). Oczywiście, tak wygląda to u mnie, u każdego może wyglądać inaczej, chodzi jednak o zasadę.
Dodatkowo, taka dekompozycja powoduje, że umysł skupia się tylko na fragmencie, nad którym obecnie pracuje, a nie przetrzymuje wielu informacji, które wykorzysta dopiero za chwilę, a które w międzyczasie go przeładują.
Tymczasem wielu z nas nadal nie stosuje tego świetnego suplementu dla mózgu, jakim jest dekompozycja. Dlaczego? Spędzając ładnych kilka lat w IT zauważyłem takie problemy jak:
- chęć przyspieszenia procesu poprzez pominięcie tego kroku – jest tak naprawdę spowolnieniem, ponieważ procesy myślowe przebiegają wolniej, gdy muszą wczytać więcej danych
- założenie, że skoro jestem seniorem, to już nie muszę – tutaj po części się zgadzam, że osoby bardziej doświadczone mogą dekomponować „mniej gęsto”, bo ich umysł automatycznie wypełnia większe luki (posiada bogatszą sieć skojarzeń). Nie powinno to jednak stanowić wymówki, by z racji tego, że jestem seniorem, nie robić dekompozycji w ogóle.
- twierdzenie, że ktoś woli programowanie wstępujące – z tym spotkałem się raz. Według mnie, programowanie wstępujące to coś innego niż chaotyczne pisanie różnych fragmentów kodu wskutek braku dekompozycji. To usystematyzowane podejście, które jednak, by mogło się udać, musi mieć u podstaw pewne założenia. Dotyczą one konkretnie tego, by drobne moduły były na samym początku dobrze opisane. Wtedy można zacząć od ich implementacji, by potem łączyć je ze sobą. Jeśli jednak taki opis (modułów na dole) nie istnieje, to skąd mamy wiedzieć, jak taki moduł ma działać?
2. Siła przeciwności nie jest stała/liniowa
Opis problemu jako sprzężenia zwrotnego dobrze przemawia do programistów, ponieważ dobrze rozumieją sens takiej sytuacji.
Ze sprzężeniem zwrotnym mamy do czynienia, kiedy dwa lub więcej elementów wzajemnie oddziałuje na siebie, tworząc pętlę. W praktyce możemy o nim również mówić, kiedy jedne wydarzenia wpływają w jakiś sposób na inne, a tamte znowu na te pierwsze.
Tak jest właśnie w kontekście zarządzania sobą w czasie. Jeżeli zadań jest dużo i ciągle nie udaje się ich zrealizować, pozostają jako pewien dług. (Formą tego może być też dług architektoniczny, czyli sytuacja, gdzie piszemy kod niedokładnie, nie dbając o jego reużywalność czy rozszerzalność, ale chcemy, by powstał szybciej). Dług ten odkłada się w postaci zadań, które wszyscy czują, że powinny być zrealizowane, ale ciągle nie są, bo nie ma na to czasu. Takie poczucie wpływa na obniżenie motywacji i wydajności zespołu, gdyż każdy wynik jest w gruncie rzeczy niewystarczający. To powoduje więcej pozostających zadań i więcej kompromisów z dobrymi praktykami. I więcej długu na końcu.
Jest to tylko jeden z przykładów sprzężenia w kontekście zarządzania sobą w czasie. Inne przykłady sprzężeń mogą być oparte o zwiększanie się stresu, jako efekt niewykonywania zadań, rezygnację z planowania, jako efekt „ścisku czasowego”, czy też obniżony monitoring samego siebie (w tym np. własnego zmęczenia), kiedy pojawia się przysłowiowe „ciśnienie w projekcie”.
W każdym z tych przypadków pierwotne efekty obniżenia efektywności stają się później powodem do dalszych problemów. Najprostszą ilustracją tego zjawiska jest stwierdzenie: „nie mam czasu na zarządzanie czasem”. Czyli sam problem jest częścią tego, że nie sięgam po rozwiązanie.
Cykle sprzężeń zwrotnych powodują, że w zależności od tego, jak bardzo się rozpędziły, wymagać będą różnej siły, by je przerwać. W skrajnym przypadku, kiedy zespół od dawna jest zdemotywowany, pracuje niewydajnie, dług architektoniczny jest ogromny, a klienci ciągle zgłaszają błędy, konieczne może być mocne przeorganizowanie i np. zatrzymanie developmentu nowych funkcjonalności na jakiś czas. Dla odmiany, w przypadkach lżejszych, pomóc mogą proste usprawnienia, jak trzymanie się metodyki czy poprawa środowiska pracy. Jednak dobór rozwiązania powinien zależeć od tego, jak daleko zespół lub jednostka zaszła w cyklu sprzężenia zwrotnego.
Świadomość cykli sprzężeń zwrotnych spełnia jeszcze jedną, być może nawet istotniejszą rolę. Pokazuje, jak warto myśleć o efektywności. Cykl można bowiem przerwać, ale potrzebne jest zauważenie, że zaczyna się rozpędzać. Rolę tą może spełniać wspomniana wcześniej (w części pierwszej artykułu) retrospektywa, ale co ważniejsze dobra komunikacja w zespole.
Może mieć to również znaczenie w pracy indywidualnej. O ile w zespołach często istnieją narzędzia do monitoringu efektywności, które w mniejszym czy większym stopniu pozwalają na uświadomienie sobie problemu, o tyle w kontekście pracy indywidualnej MUSIMY ZADBAĆ O TAKIE RYTUAŁY SAMODZIELNIE.
Istnieje wiele sposobów, jak można to robić, jednak o tym kiedy indziej.
The winner is …
1. Działania „awaryjne” mające na celu podnieść wydajność, zazwyczaj ją obniżają, ale nasze wrażenie mówi inaczej!
Ten problem zasłużył na miano numeru jeden, ponieważ jest zupełnie kontrintuicyjny. Oznacza to, że aby go rozwiązać, musimy nieco wyjść poza swoje postrzeganie racjonalności i uznać własną omylność. W przypadku osób wykonujących pracę uporządkowaną i wymagającą myślenia analitycznego na wysokim poziomie, jest to w szczególności trudne (wiem z własnego doświadczenia).
Co jest tutaj nieracjonalnego?
Gdy okazuje się, że czasu jest mało, albo coś idzie nie po naszej myśli, zazwyczaj sięgamy po pewne rozwiązania. Nie jest to złe, wszak zgodnie z punktem poprzednim jest to przecież dowód na zauważenie problemu, a więc pierwszy krok do jego rozwiązania.
Jednak o ile możemy pogratulować sobie wtedy wczesnej (oby faktycznie wczesnej ?) identyfikacji problemu, o tyle sposób rozwiązania go jest często niewłaściwy – działa nie tylko nieskutecznie, ale wręcz szkodzi.
To tak, jakby złodziej przebrał się za policjanta, a my z chęcią wpuścilibyśmy rzekomego funkcjonariusza do naszego mieszkania. Przyszedł przecież pomóc, czyż nie?
Takim złodziejem przebranym za policjanta może być pomijanie planowania, zwłaszcza kiedy pracując indywidualnie realizujemy kilka projektów. Planowanie zajmuje czas, więc podczas „ciśnienia” może warto z niego zrezygnować i dać sobie więcej czasu na pisanie kodu? Czasem może się to sprowadzać do pomijanie planu dnia, licząc na to, że „jakoś się on ułoży”. To prowadzi do wielu decyzji, które mogą obniżyć naszą wydajność – zjedzenie byle czego i w jednym ogromnym posiłku zamiast w trzech małych, siedzenie bez odpowiedniego nawodnienia, czy też stres z powodu zapomnianego, banalnego, ale pilnego zadania.
Takim złodziejem może też być pomijanie przygotowania środowiska pracy –– czy to fizycznego, czy to technicznego (bo np. nie ma czasu na ich konfigurowanie skrótów klawiszowych, zakładek, itd.)
Wreszcie takim złodziejem jest zajmowanie się wieloma rzeczami na raz, szczególnie dlatego, że miesza w naszym odczuwaniu efektywności. Podczas pracy wielozadaniowej jesteśmy bardziej zajęci oraz bardziej zmęczeni kognitywnie, gdy ją ukończymy. Natomiast miary te, umysł intuicyjnie wykorzystuje jako wskaźnik tego, czy pracowaliśmy efektywnie. Innymi słowy nieefektywna wielozadaniowość skutkuje ciągłą zajętością i wymęczeniem, które następnie interpretujemy jako sygnał (rzekomo) EFEKTYWNEJ pracy. Z tego płyną błędne wnioski, by robić to dalej.
I to tyle na dzisiaj. Mam nadzieję, że te lekcje również dla Ciebie będą wartościowe, szczególnie jeśli już teraz rozpoznajesz u siebie opisane przeze mnie symptomy.
