Natłok zajęć

Najpierw jest lista rzeczy do zrobienia. Z czasem robi się bardzo długa, więc wyróżniona z niej zostaje lista rzeczy pilnych. Na ich bazie powstaje wykaz spraw najpilniejszych. Później absolutnie priorytetowych.

A na koniec i tak liczy się, kto akurat zawiśnie na telefonie albo stanie nad głową.

Szeroki front GTD

Podstawy do oceniania GTD mam bardzo słabe - używam tych technik nieporządnie i selektywnie - więc traktujcie poniższą opinię ze sporą dozą krytycyzmu. Mam wrażenie, że z całą techniką podziału na drobne zadania, selekcji następnych akcji, tworzenia idących w poprzek projektów wykazów spraw realizowalnych w danym kontekście, GTD sprzyja pewnemu specyficznemu celowi.

Sprzyja regularnemu popychaniu każdego ze stu projektów do przodu, choć trochę.

W wielu wypadkach jest to dobre. Jest dobre w korporacyjnych sytuacjach, w których właśnie tego - utrzymania wszystkich projektów w ruchu - się od menedżerów oczekuje. Jest dobre, gdy ma się dość czasu na wszystkie zaplanowane zadania a zarządzanie czasem pozwala efektywniej je rozplanować. Jest dobre, gdy projekty polegają głównie na delegowaniu prac i okazyjnym nadzorze. Jest dobre, gdy chodzi o sprawy bez końca (jak różne elementy edukacji i samorozwoju).

Ba...

Uderzyć w punkt

Dawno, dawno temu, kilkanaście lat zanim zaczęły zdobywać popularność słówka iterative czy agile, Tom Demarco napisał:

Your project, the whole project, has a binary deliverable. On scheduled completion day, the project has either delivered a system, or it hasn't. Everyone knows the result on that day.

Albo - albo. Albo aplikacja powstała, jest i można ją uruchomić, albo nie.

To oczywiście nie jest wyłączna cecha informatyki, 73% mostu też się nikomu nie przyda, ale w naszej dziedzinie, operującej niematerialnymi wytworami, zadziwiająco łatwo bywa to kryterium zapominane.

Wniosek? Lepiej zrobić dwa z pięciu projektów do końca, niż każdy z nich dociągnąć do połowy czy nawet do 80%.

Przynajmniej, gdy chodzi nam o coś więcej niż o uzyskanie alibi.

Troszkę mieszam tu oba znaczenia słowa projekt - to indywidualne z GTD i to organizacyjne osadzone w kontekście firmy. Zasada tak naprawdę stosuje się do obydwu przypadków.

Mark Forster

Czytam Do it tomorrow Marka Forstera.

O autorze usłyszałem po raz pierwszy gdy - z drugiej ręki (przeglądając ten ebook - ciekawy, choć będący pod wieloma względami powtórzeniem pomysłów z powyższej książki) - poznałem jego sposób na zalew emaili:

• zajrzyj rano do skrzynki, zaznacz wszystkie czekające listy przenieś je do folderu Do obsługi,
• w wybranym czasie w ciągu dnia przejdź przez folder Do obsługi, normalnie obsługując pocztę (odpowiadając, przekierowując, zapisując do zrobienia, kasując),
• przez cały dzień nie zaglądaj już jednak do skrzynki wejściowej, co przyszło po porannym cięciu, poczeka do jutra.

Okazało się to jednym z bardzo niewielu znanych mi patentów na pocztę, który naprawdę działa, a przy okazji przywraca jej naturalny, asynchroniczny, przemyślany tryb.

Nie mam potrzeby stosować tej techniki stale ale w okresach szczególnego spiętrzenia poczty - pomagało.

Przywołałem ten przykład, bo dobrze ilustruje pragmatyczne podejście autora (powyższa metoda jest elementem szerszej sprawy budowania bufora między cudzymi żądaniami a własną reakcją). Takich wątków jest parę, dobre wyobrażenie o tematyce daje udostępniony w sieci pierwszy rozdział, uwagę zwraca choćby duży realizm w myśleniu o samym sobie (zamiast stawiać wymagania i idealizować możliwości Forster stwierdza: powodzenie projektu bardzo rzadko jest efektem 'siły woli', częściej wynika z ustawienia struktury sprzyjającej jego realizacji i z tej perspektywy szuka właściwych rozwiązań), rozsądne podejście do kreatywności (pytając co można by usprawnić w samochodach dostaniesz trochę ogólnikowych uwag, pytając "co poprawiłbyś w kierownicy swojego auta" masz spore szanse na użyteczne idee) albo - ważna obecnie dla mnie - batalia przeciw chaotycznemu poddawaniu się impulsom zewnętrznym.

To wszystko dygresja. Wyciągam Do it tomorrow, bo jak mało kto, autor mocno mówi: trzeba skreślać (a jeszcze mocniej podkreśla to - i szuka konkretnych sposobów - w swoim najnowszym systemie).

Ciach

Odkrycie, którego wcześniej lub później dokonuje chyba każdy próbujący pracować nad własną produktywnością: żadna z technik nie pozwoli zrobić więcej, niż ... się da. Można wyeliminować trochę luzów. Można nieco zmniejszyć koszty przełączania kontekstu. Można być bardziej świadomym kierunków wyciekania czasu. Ale to wszystko nijak nie pozwoli w ciągu miesiąca zrobić trzech zadań, z których każde wymaga miesiąca.

I kluczową umiejętnością staje się eliminowanie. Wskazywanie rzeczy, które - przynajmniej teraz - nie będą robione.

GTD też chyba może mu sprzyjać ale wyłącznie w powiązaniu z ostrą selekcją projektów w trakcie review. Listy zadań których używam i na które zerkałem wspomagają ten proces słabo lub wcale.

Ja mam tu problem, notorycznie próbuję łapać dziesiątki tematów naraz, nie umiem ich eliminować i ląduję z masą rozgrzebanych spraw. Nie będę więc dawać rozwiązań, dopiero ich szukam (i wcale nie mam pełnego przekonania do Forsterowych skreślanych list, choć zastanawiam się nad ich wypróbowaniem).