Multitasking w codziennej pracy programisty

Multitasking w codziennej pracy programisty

Efektywność oraz umiejętne zarządzanie czasem to cechy które każdy ambitny programista chciałby opanować do perfekcji. Wielu z nas – w tym i ja sprzed kilkunastu miesięcy – za cel obiera sobie zapoznanie się z jak największą liczbą książek z dziedziny tzw. “time managementu”. Do tego kilkanaście aplikacji do zarządzania zadaniami, kilka postów z internetu, kilka cytatów i już możemy żonglować kolejnymi ticketami w Jirze. Na wszystko starczy nam oczywiście czasu, ponieważ odkryliśmy, że niczym procesor możemy poszczególne czynności wykonywać równolegle. Jeśli u ciebie tak to wyglądało, to gratulacje. Jeśli nie, to spokojnie – dołączyłeś do grupy ludzi którzy mają szansę zrozumieć, że multitasking dla większości programistów po prostu nie działa.

Koszty robienia kilku rzeczy na raz

Działanie w trybie wielozadaniowym to coś, co niektórzy z nas podświadomie kopiują ze smartfonów i innych podobnych im urządzeń. Skoro o sprawności danego sprzętu świadczy liczba aplikacji które mogą być otwarte jednocześnie i między którym użytkownik może się poruszać, to o mojej sprawności będzie świadczyć liczba prowadzonych równolegle projektów, spraw “do załatwienia” oraz celów do zrealizowania. Pozornie równoległa realizacja zadań ma rzekomo świadczyć o tym, jak dobrze dana osoba porusza się w świecie zawodowym oraz jak bardzo można na niej osobie polegać.

Równoległe przetwarzanie informacji niesie jednak za sobą koszt, którego świadome są te osoby które kiedykolwiek wczytywały się np. w zasady działania systemów operacyjnych. Kosztem o którym mowa jest context switchCzego w codziennym życiu może nas nauczyć zagadnienie z naszego własnego słowniczka pojęć?

Zobaczmy na prosty schemat realizowania kolejnych zadań w zależności od czasu – w przypadku kiedy pracujemy pozornie “jednowątkowo” realizacja zadań wygląda zazwyczaj następująco:

Takim samym kolorem oznaczone są zadania z “tej samej dziedziny” – w programowaniu mogą to być np. kolejne fragmenty tego samego projektu. Bloki w tym samym kolorze nie mają dużych odstępów czasowych, ponieważ w tym czasie kolejne zadania są ze sobą naturalnie powiązane. Przerwy czasowe pomiędzy kolorami są nieco większe, ponieważ tutaj następuje ta wspomniana zmiana kontekstu – to moment przygotowania się do nowej rzeczywistości, zapoznania się z nowymi wymaganiami, itd. – po tym etapie praca znowu idzie płynnie, aż do momentu “przestoju” związanego np. ze zmianą projektu. Czy jeśli zajmiemy się kilkoma projektami jednocześnie to w tym samym czasie sumarycznie zrealizujemy więcej?

W świecie równoległym koszt context switchingu jest dużo większy – założę się, że wielokrotnie znajdywałeś się w takiej sytuacji i wyglądało to podobnie. W poniedziałek trochę pracy na front-endzie, wtorek i środa back-end, czwartek znowu front-end… ale jak się to w tym Angularze… aha no i jutro trochę back-endu – tylko co ja tu ostatnio miałem zrobić… I to wszystko przy optymistycznym założeniu, że na zmianę kontekstu wystarczy nam kilkadziesiąt minut każdego poranka – a w rzeczywistości przy bardziej skomplikowanych i intensywnych zadaniach, które dodatkowo mogą dotyczyć różnych projektów, przypomnienie sobie właściwego kontekstu danego zadania trwa zdecydowanie dłużej.

W rezultacie tej pozornej optymalizacji czasu zaczyna brakować w sposób jeszcze bardziej odczuwalny. Wszystko przez to, że pojawił się narzut w postaci zmiany kontekstu, o którym często zapominamy, a który czasami jest równie czasochłonny co właściwe zadanie które następuje po nim.

Moje spostrzeżenia mogą was co prawda nie przekonywać, ale ludzi zajmujących się tym zawodowo warto posłuchać:

In the mid-1990s, Robert Rogers, PhD, and Stephen Monsell, D.Phil, found that even when people had to switch completely predictably between two tasks every two or four trials, they were still slower on task-switch than on task-repeat trials.

http://www.apa.org/research/action/multitask.aspx

Ale to nie wszystko!

Gdyby zmiana kontekstu była jedynym co może nas spotkać decydując się na równoległe wykonywanie zadań, to być może niektórzy z nas – ci bardziej cierpliwi – mogliby z tym żyć. W rzeczywistości jednak w tym trybie zmienia się też to, ile uwagi poświęcamy na zadanie oraz jak bardzo skupieni do niego przystępujemy. Przypomnij sobie ostatnie zadanie które wymagało od ciebie stuprocentowego skupienia. Założę się, że po kilku godzinach pracy jedyne o czym myślałeś to przerwa, a nie przerzucenie się na coś równie intensywnego. Fizycznych ograniczeń pracy naszego mózgu nie przeskoczymy – tak samo jak zwykłego ludzkiego zmęczenia pracą.

Dlaczego multitasking działa w tym przypadku negatywnie? Ponieważ kiedy przeznaczamy 100% naszych “zasobów energetycznych” na jedno zadanie, to mając je przed sobą w większej ilości, nie przeznaczymy takiej samej uwagi na każdy z tych przypadków. W jednej sprawie będziemy się mogli skupić na 60%, w kolejnej może na 30%, a na dużym zmęczeniu ostatnie zadanie dostanie od nas 10% uwagi. Deep work zamieni się w shallow work. Każdą z tych czynności – np. zadań w projekcie – być może dokończymy, ale rezultaty będą zdecydowanie różne. Różna będzie liczba bugów, liczba skrótów myślowych, komentarzy “// TODO” albo “// Refactor” – a to już nie teoria, a bardzo bezpośrednie efekty równoległego wykonywania zadań.

Założę się, że negatywne skutki multitaskingu, takie jak większe zmęczenie, pozorny brak czasu, czy niska jakość dostarczanego kodu, każdy z nas odczuł chociaż raz na własnej skórze. Dlaczego więc w niektórych sytuacjach zapominamy o doświadczeniach z przeszłości i kolejny raz decydujemy się na takie podejście?

Asertywność i problem oceny wydajności

Dwa najważniejsze moim zdaniem powody to po pierwsze brak dostatecznej asertywności, a po drugie kierowanie się błędnymi przekonaniami co do tego czym jest efektywność.

Asertywność jest umiejętnością o której dowiadujemy się gdzieś w okolicach szkoły podstawowej – odmawiaj nieznanym ci osobom, nie zgadzaj się na wszystko, pilnuj tego co mówili ci rodzice, szanuj własne zdanie… niestety teoria nie zawsze idzie w parze z praktyką. Wypracowana umiejętność trzymania się własnego zdania przydaje się szczególnie wtedy, kiedy pracujemy w jakimkolwiek zespole lub wśród grupy ludzi. “Słuchaj, już dawno myślałem o… może mógłbyś na to spojrzeć?”. Wystarczy tego typu rozmowy i zapytania pomnożyć przez listę ludzi z którymi możemy współpracować i nagle na liście rzeczy do zrobienia mamy już nie tylko swoje zadania, ale i tzw. “wrzutki” z zewnątrz. Nasz wykres pracy bez niepotrzebnych zmian kontekstu w rzeczywistości wygląda tak:

Swoje zadania przewidujemy z wyprzedzeniem. Co jednak robić z tym, co nie należy do nas?

Nawet jeśli pracujemy jako freelancer, to wrzutki z zewnątrz mogą się pojawić w formie przysługi dla znajomego, zapytania o konsultację czy innej aktywności niekoniecznie związanej z naszą pracą. Jasne, w pomaganiu nie ma nic złego, jednak zbierając tego typu prośby i zapytania z tyłu głowy rośnie nam poczucie “spraw które czekają na swoją kolej”. A od myśli o takich sprawach niedaleko do próby zrealizowania kilku w podejściu równoległym.

Jak w takim przypadku uniknąć nieświadomego dążenia do wielozadaniowości? Najlepszym sposobem jest chyba uprzejme odbicie piłeczki do momentu, kiedy faktycznie pojawia się okazja na zrealizowanie czegoś “od zaraz”. Jeśli takiej okazji nie ma, to akceptując daną prośbę dorzucamy niestety kolejną pozycję do magazynu na rzeczy do zrobienia.

Drugim powodem przez który decydujemy się na równoległa realizację zadań jest – co potwierdziła mi jedna z ostatnio przeczytanych książek – brak jasno określonych celów i priorytetów. To przekłada się z kolei na błędne rozumienie tego czym jest efektywność, oraz co zrobić żeby pracować efektywnie.

W przypadku kiedy błądzimy np. po swoim miejscu pracy i nie rozumiemy swojej roli, to bardzo łatwo zacząć łapać do ręki każdą napotkaną okazję na wykazanie się. “Dzisiaj porobię to i tamto, jutro tamto i to, trochę tego, a potem to. No i nie mam czasu na to i na tamto, ale ludzie tacy jak ja tak mają – przynajmniej dużo dzisiaj zrobiłem…”.

Bez jasno określonego celu, wszystko staje się tak samo ważne. Jeśli wszystko jest tak samo ważne, to znaczy, że nie znamy priorytetów którymi powinniśmy się kierować, a tym samym zaczynamy robić dużo. Robienie wielu rzeczy na raz kojarzy nam się jednoznacznie z efektywnością. Niestety, po chwili okazuje się, że na robienie “tylu” rzeczy na ile się deklarujesz, zaczyna brakować czasu. Rozwiązanie? Zrobię kilka z nich jednocześnie! Zacznę od …, w momencie czekania na build przeskoczę do…, teraz lecą testy więc mogę ….. Efekt? Pomijanie detali, brak dostatecznej uwagi, obniżona koncentracja a na końcu pewnie i frustracja (pracę w momencie kiedy “czekam na …” znam patrząc na samego siebie, dlatego staram się z takim podejściem walczyć zawsze kiedy to możliwe, właśnie z uwagi na rozmytą uwagę i koncentrację).

Co polecałbym tym, którzy łapią się na takim podejściu do pracy? W tym przypadku pomaga trudna, ale skuteczna samokontrola, pewnego rodzaju ograniczenia które stawiamy sami na siebie no i oczywiście próba odpowiedzenia sobie na pytania “po co ja tak naprawdę tutaj jestem” i “co przyniesie największą wartość”. Wszystko po to, żeby określić priorytet kolejnych zadań, zrezygnować z podejścia pt. “wszystko jest ważne” oraz na tyle na ile to możliwe, pracować nad nowym zadaniem tylko wtedy, kiedy zakończyliśmy pracę nad poprzednim. Jeśli pracujemy np. w Scrumie lub Kanbanie, czyli metodykach dzięki którym możemy porządkować bieżące zadania, to warto zadbać o to, żeby sprint lub nadchodzący tydzień nie był tylko listą dni od poniedziałku do piątku, ale konkretną ścieżką którą chcemy podążać w danym okresie.

Na koniec tego fragmentu dodam jeszcze, że istnieją oczywiście stanowiska w których robienie kilku rzeczy na raz jest z natury danej roli nie do przeskoczenia. Takimi stanowiskami są np. stanowiska managerskie, gdzie będąc “przekaźnikiem” potrzeb zespołu, rezygnujemy z własnego czasu na rzecz czasu poświęcanego na potrzeby innych. Jeśli jednak nie jesteś w takiej roli, a pracujesz jako programista, to uwierz mi – multitasking nie przyniesie ci niczego dobrego.

Przecież to wszystko oczywiste

O temacie tego posta zdecydowałem w momencie, w którym uświadomiłem sobie, że zakupiona ostatnio aplikacja do zarządzania zadaniami nie była przeze mnie używana od kilkunastu tygodni. Powodem nie jest kupienie tej słynnej cegły zamiast telefonu – aplikacja którą mam na myśli jest świeża, często aktualizowana, z dobrymi ocenami i pozytywnymi komentarzami innych użytkowników. Mimo wszystkich jej zalet leży “zakurzona” i czeka na swoje przyszłe pięć minut. Dlaczego?

Od pewnego czasu staram się podchodzić do realizacji postawionych przeze mnie zadań z większą niż do tej pory uwagą. Szczególnie mocno zastanawiam się nad tym, czy biorąc na siebie kolejne zobowiązanie nieświadomie nie decyduję się na multitasking. Skoro pracy chcę poświęcać tyle samo czasu jak do tej pory, a sumarycznie “robić więcej”, to znaczy to, że albo próbuję coś zrównoleglić, albo z własnej woli zapisuję się na nadgodziny. Innej opcji nie ma. Jedynym logicznym wyjściem jest więc zmniejszenie liczby zadań które mam na swojej liście “todo”. W efekcie tego narzędzia takie jak Things, Evernote czy OneNote przestają być niezbędnym dodatkiem do mojego dnia pracy. Kalendarz, podstawowe notatki i tylko jedna rzecz którą robię w danym momencie.

Już słyszę niektórych z was mówiących, że to same oczywistości i banały. Tak samo powiedziałem kiedyś czytając książkę o wdzięcznej nazwie “Jedna rzecz” – no tak, typowa książka pod tezę, a w środku nic odkrywczego. Przecież potrafię kontrolować mój czas. Ale czy na pewno?

Zobaczcie na rynek aplikacji do zarządzania czasem, książek dotyczących tematu produktywności oraz blogów na temat tego jak być efektywnym. Czy przeważającą poradą jest “rób mniej”? Oczywiście, że nie! Marketingowy przekaz takich materiałów to “rób więcej w takim samym czasie”, “zapanuj nad czasem” albo “efektywności w 60 minut”. Przesłanie jest jasne – istnieje sposób na robienie więcej bez decydowania się na nadgodziny. Owszem, takie rozwiązanie istnieje, ale w rzeczywistości nie jest tak gorące jak magiczne sposoby na efektywność – nazywa się ono wypracowanymi umiejętnościami.

Jestem ciekawy jak to wygląda u ciebie – walczysz z czasem, szukasz nowych sposobów na zarządzanie zadaniami, czy doszedłeś do podobnych wniosków jak te opisane w tym poście?