Przez długi czas pracowałem w chaosie, bez ustalonego porządku i planu dnia. Losowo przeskakiwałem pomiędzy pisaniem kodu, reagowaniem na wiadomości na Slacku, czytaniem i odpowiadaniem na e-maile, code review, przeglądaniem newsów i przypadkowymi rozmowami z zespołem oraz przerwami na kawę, obiad, itd.

Podejmowane działania oraz ich kolejność była zupełnie przypadkowa i wynikała głównie z reaktywnego trybu działania. W moim przypadku taki tryb skutkował wyczerpaniem oraz brakiem poczucia jakiejkolwiek produktywności. Byłem cały czas zajęty, ale na koniec dnia nie wiedziałem co tak naprawdę w tym dniu zrobiłem.

Zmęczony taki trybem postanowiłem wypracować sposób pracy, który zamiast chaosu wprowadzi do mojej pracy porządek, ład oraz kontrolę nad tym co i kiedy robię.

Rozpoczęcie Dnia

Początek dnia przeznaczam na pracę głęboką, wymagającą dużego skupienia, ciszy i spokoju. Na ten blok poświęcam 3 godziny w dwóch sesjach po 80-90 minut każda. Podczas tego bloku nie odpisuję na wiadomości, nie czytam maili oraz nie odbieram telefonów.

Rozpoczynając ten blok:

  • przełączam Slack‘a, komputer oraz telefon w tryb Do Not Disturb,
  • wybieram pierwsze zadanie z mojej listy to-do na dzisiaj,
  • uruchamiam Toggl dla wybranego zadania,
  • uruchamiam timer na 80 minut w celu odmierzenia sesji.

Po dwóch sesjach wyłączam tryb Do Not Disturb.

Przegląd aktywności, działań i wydarzeń - komunikacja

Następny blok mojego dnia pracy przeznaczam na wskoczenie w strumień bieżącej komunikacji. Odbywa się ona kilkoma kanałami:

  • GitLab
  • Slack
  • E-mail (należy tu rozróżnić powiadomienia z systemów takich jak GitLab od komunikacji)
  • Telefon - w tym przypadku oddzwaniam na nieodebrane połączenia

W powyższych kanałach pojawiają się wiadomości i dyskusje w wyniku których mogą powstawać zadania.

Jeżeli w jednym z powyższych kanałów pojawi się temat wymagający mojej pracy to umieszczam go w formie zadania w Todoist Inbox. Dodatkowo informuję uczestników wątku, o tym że zapoznałem się z tematem i zajmę się nim w późniejszym terminie.

Dodatkowo stosuję tutaj jedną z zasad znanych z GTD, mówiącą o tym, że jeżeli rozwiązanie tematu zajmie poniżej dwóch minut to najlepiej zrobić to od razu.

GitLab

Powiadomienia e-mail i To-do List

W pierwszej kolejności przeglądam powiadomienia e-mail z GitLab’a. Zazwyczaj dotyczą one aktywności w wątkach w których w jakiś sposób uczestniczę. Może to być na przykład powiadomienie o odpowiedzi na mój komentarz. Wszystkie skierowane do mnie tematy wynikające z tych powiadomień przekuwam na taski w Todoist Inbox dołączając do nich link z maila - “view it on GitLab”. Po utworzeniu taska oznaczam takie issue albo MR’a korzystając z GitLab’owej funkcji “Mark as done” po to, aby ściągnąć taki element z To-Do List‘y do której przechodzę po przejrzeniu powiadomień. Jest to kolejne miejsce w którym znajdują się elementy wymagające mojej uwagi.

Rodzaje zadań, które mogą powstać w wyniku tego przeglądu:

  • odpowiedzieć na komentarze do zadań lub merge requestów,
  • przeprowadzić code review,
  • wprowadzić poprawki po code review,

Merge Requests

Następnie robię przegląd merge request'ów do których jestem przypisany. Zazwyczaj można je zakwalifikować do trzech kategorii:

  • MR oczekujące na moje code review,
  • MR oczekujące na moje poprawki po code review,
  • MR mojego autorstwa oczekujące na code review zespołu.

MR’y z pierwszych dwóch kategorii najprawdopodobniej znajdują się już w Todoist Inbox ponieważ informacje o nich spływają w powiadomieniach e-mail oraz na To-Do List‘ę. Wynika to ze sposobu pracy z GitLabem i mechanizmu działania samej To-Do List‘y, po szczegóły odsyłam do dokumentacji

Merge requesty z ostatniej kategorii, czyli te utworzone przeze mnie, sprawdzam po to, aby wiedzieć czy ktoś rozpoczął code review, na jakim jest ono etapie i ewentualnie podbić temat jeżeli MR czeka już zbyt długo. Zakładam, że jako autor merge requesta jestem odpowiedzialny za dopilnowanie, aby prace nad nim posuwały się naprzód.

Issues

Następnie robię przegląd issues'ów do których jestem przypisany. Te można podzielić na:

  • issues’y nad którymi trwają prace, czyli w statusach typu Doing, Review, Testing;
  • issues’y oczekujące na rozpoczęcie prac.

Podobnie jak przy merge requestach, po etapie developmentu określonych issues'ów nadal dbam o doprowadzenie zadań do końca weryfikując czy dalsze etapy prac przebiegają sprawnie.

Po zweryfikowaniu i popchnięciu do przodu trwających zadań wybieram i umieszczam W Todoist Inbox kolejne zadanie do którego jestem przypisany.

Slack

remind /list

Przegląd Inbox’a

Jak widać w powyższych akapitach, wszystkie tematy i zadania, które pojawiają się w ciągu dnia lądują w inboksie. Następnie przychodzi czas na jego przegląd podczas którego przypisuję poszczególne jego elementy do właściwych projektów.

Przegląd Projektów

Po tym jak wszystkie elementy inboksa znajdą się we właściwych projektach robię ich przegląd podczas którego:

  • sortuję zadania według istotności,
  • oznaczam je odpowiednim priorytetem,
  • w miarę możliwości wyznaczam ich termin.

Planowanie Dnia

Na koniec dnia robię planowanie pracy na dzień następny.

Na ten moment taki workflow w miarę się u mnie sprawdza. Będę aktualizował ten wpis w miarę dalszych usprawnień.