Delegowanie i uzgodnienia spraw "przy okazji" spotkań

1. Nie każda sprawa wymaga natychmiastowego uzgodnienia face2face lub telefonicznie
2. Nie każdą sprawę efektywnie jest uzgadniać za pomocą emaila
3. Nie zawsze sprawa jest na tyle pilna, aby przerywać pracę (przegląd Inboxa) i delegować ją lub uzgadniać natychmiast
4. Nie każdą sprawę można lub należy od razu uzgodnić

W takich sytuacjach pomaga mi lista spraw do uzgodnienia oznaczona @Agenda. Wpisuję tam wszelkie uzgodnienia, które:

• chcę przeprowadzić z daną osobą osobiście face2face
• chcę przeprowadzić w odpowiednim momencie, gdy będzie tak zwany "właściwy klimat"
• nie są na tyle istotne, aby zakłócać przepływ spraw "najważniejszych"

Jakoś tak dziwnie się dzieje, że wpisanie tych uzgodnień na listę zwiększa prawdopodobieństwo przypomnienia sobie o tej sprawie we właściwej okazji. Jeśli mam wystarczająco dużo czasu przeglądam taką listę w trakcie lub po spotkaniu - pomaga w tym rozpoczynanie wpisów imieniem i nazwiskiem osoby, której dotyczy uzgodnienie.

Poranna lista kontrolna, najważniejsze czynności dnia

Każdego dnia rano staję przed kwestią prawie hamletowską: "planować czy nie planować". A jeśli planować to co i jak? Pomaga mi w tym poranna rutynowa procedura "otwarcia dnia". Po za typowymi dla każdego czynnościami takimi jak poranna toaleta, modlitwa czy śniadanie na swoje liście kontrolnej porannych czynności mam:

1. Uproszczony przegląd "Inboxa" - poczty elektronicznej i szuflady z notatkami - zdarzają się ważne emaile, które ktoś napisze późno w nocy lub wcześnie rano lub notatki sporządzone po wieczornym porządkowaniu Inboxa - warto je szybko przejrzeć nad ranem, gdyż mogą zmienić plan dnia
2. Przegląd kalendarza codziennego Gmail i miesięcznego "rodzinnego" - to pozwala mi zorientować się ile mam czasu, uzupełnić rezerwacje czasu w kalendarzu na przykład na dojazdy i ewentualnie dokonać zmian w typowych czynnościach, na które mam czas zarezerwowany w tych kalendarzach
3. Przegląd czynności terminowych (z ustawionym deadlinem "Due") na najbliższe 7 dni - "Due next 7 days" - pozwala mi to kontrolować ryzyko pozostawiania działań do wykonania na ostatnią chwilę - czasem trzeba coś zrobić wcześniej, a nie "Just-in-time"
4. Sprawdzenie najważniejszego rezultatu tygodnia ("Weekly goal"), przegląd listy planowanych czynności i subrezultatów do osiągnięcia - dzięki temu mogę ocenić czy nie jestem spóźniony z realizacją prac i spokojnie zastanowić się co tym zrobić
5. Sprawdzenie koperty ze sprawami odłożonymi na dziś - znane z metodyki Getting Things Done narzędzie 43 folders

Działania, które chcę wykonać z rana (= plan dnia) - zanim pojawią się zakłócenia - oznaczam gwiazdką w aplikacji MyLifeOrganized - można użyć znacznika priorytetu w innych narzędziach. Zgodnie z radami Leo Babautta w Zen-to-Done unikam oznaczania więcej niż trzech gwiazdek - to praca mniej więcej na 3 godziny (9-12). Później bywa różnie, a nawet jeśli z rana coś pójdzie nie tak te trzy godziny są do wygospodarowania w ciągu dnia. Osobiście nazywam to najważniejszymi czynnościami dnia.

Przejście powyższej procedury zajmuje mi 30 minut i w zasadzie "ustawia" dzień. Nic więcej w temacie planowania na razie nie radzę robić - sytuacja "robocza" zmienia się zbyt szybko...

Okoliczności biurowe czyli grupowanie najbliższych działań w pracy zależnie od kontekstu

David Allen w swojej metodyce GTD zaleca grupowanie najbliższych działań na listach zależnych od okoliczności (kontekstu). W środowisku biurowym na pewno sprawdzą się następujące listy:

• w biurze (czyli na własnym stanowisku pracy)
• telefon (lista wszystkich telefonów do wykonania skądkolwiek)
• agendy (czyli wszelkie uzgodnienia dokonywane na spotkaniach formalnie organizowanych, prowadzonych ad hoc lub przy okazji n.p. lunchu)

W wersji angielskiej będzie to:

• @office
• @phone
• @agenda

Niestety w praktyce korzystania z GTD okazuje się, że listy rosną w nieskończoność. Osobiście stosuję dwa rozwiązania:

1. Odkładanie spraw na później (43 folders), na tak zwany Święty nigdy, czyli kiedyś/może (Someday/Maybe) lub po prostu wyrzucanie do kosza
2. Drugim sposobem jest podział dużej listy na mniejsze - ułatwia to porządkowanie i przeglądanie. Dla listy w biurze (@office) zastosowałem podział na:
• na komputerze (@pconly) - obejmuje działania, które mogę wykonać poza biurem jeśli mam notebooka przy sobie
• w sieci (@wwwonly) - obejmuje działania, do których wystarczy jakakolwiek przeglądarki

Co zyskałem za pomocą tego dziwacznego sposobu organizacji?

• cotygodniowy przegląd i porządkowanie list jest sprawniejsze
• zdarzają się sytuacje, gdzie mam okazję (i ochotę) popracować na komputerze lub przy sieci i wtedy w/w listy są jak znalazł

Kontrolę długości list przeprowadzam w trakcie cotygodniowego przeglądu stosując zasadę 20/50 - lista dłuższa niż 50 jest niepraktyczna w użyciu - należy ją podzielić lub skrócić do 20. W praktyce sprowadza się to do znalezienia jednej lub kilku najdłuższych list (powyżej 20) i skróceniu ich poniżej 20 pozycji.

Najbliższe działania, czyli od czego zacząć

Witam,

eksperymentując z metodyką GTD organizacji własnej pracy często spotykam się z problemem nazwania działania jakie mam podjąć w związku z daną sprawą. Poniżej przepisałem z własnego MyLifeOrganized kilka przykładów dla ułatwienia innych korzystających z GTD:

• przejrzeć (zwykle jakiś dokument)
• sprawdzić (na przykład w Internecie, we własnych notatkach)
• wyszukać (j.w.)
• uruchomić (program, konto na stronie www)
• obliczyć, skalkulować (koszt)
• napisać (dokument, draft, wersję roboczą)
• zainstalować (oprogramowanie)
• dowiedzieć się (zwykle przez telefon)
• spytać, ustalić, uzgodnić kwestię (j.w.)
• uzyskać, umówić, zarezerwować termin (j.w.)
• przetestować (oprogramowanie, funkcję)

Niestety język polski jest bardziej opisowy niż angielski, więc trzeba się więcej napracować przy pisaniu. Czasem warto coś skrócić pisząc po angielsku z wykorzystaniem cyfrowych skrótów:

• rev (...iew)
• check
• search4
• run
• calc (...ulate)
• write
• install
• ask
• ?
• ?
• test

A może by tak "DevOps" Panie Bartoszu?

Problem pozornie prosty: jak doprowadzić do współpracy dwa skrajnie różne światy IT - operacje zarządzające usługami (ITSM) i rozwój zarządzający projektami (n.p. PMI)? Tak go przynajmniej naszkicował Bartosz Górczyński prezentujący wczoraj zagadnienie Potrzeby ITSM wobec PM. Słuchając wczorajszego wykładu doszedłem do wniosku, że to co w świecie małych organizacji jest trywialne, w rzeczywistości dużych korporacji nie musi być wcale takie oczywiste.

Jak to działa w rzeczywistości małej organizacji? (przykład z praktyki - 2007) Każdy projekt ma swojego kierownika i zespół projektowy. W skład zespołu projektowego wchodzi osoba z operacji (zwykle administrator), który konsultuje wszelkie pomysły zespołu projektowego i wspomaga realizację zadań w części operacyjnej. Na przykład organizuje środowisko rozwojowe tak, aby było identyczne z planowanym środowiskiem produkcyjnym. Mamy zatem ścisłą współpracę pomiędzy operacjami a rozwojem realizowaną przez "oficera łącznikowego" z operacji. Co ciekawe (sprawdzone!) "oficer łącznikowy" często tak utożsamia się z projektem, że "przepycha" pomysły rozwojowe w swoim pionie (operacyjnym) nawet na przekór swoim kolegom.

Dlaczego nie zastosować tego w dużych organizacjach? (Jeśli ktoś ma czas posłuchać całości podobnego seminarium z Poznania zapraszam na YouTube).

Jest nawet taka inicjatywa o nazwie DevOps, która wygląda dokładnie jak wyżej opisany przykład. Jest nawet "profesjonalna" nazwa naszego oficera łącznikowego pomiędzy operacjami i rozwojem: Release Coordinator.

A co Wy o tym sądzicie?

Big Data Matters

W ostatni piątek odbyło się seminarium Large Data Infrastructures for US Government  and Industry. Oprócz ciekawostek na temat realiów rynku informatycznego w USA jeden ze słuchaczy zadał pytanie: "When we should talsk about BigData?". Odpowiedź prowadzącego prezentację Lee Turnera była zaskakująco szczera: "I don't know!". Podpowiedź organizatora seminarium Pawła Płaszczaka z GridWiseTech była następująca: "BigData to dane, którymi na aktualny stan technologii nie da się zarządzać za pomocą trywialnych narzędzi." Niestety ta definicja mnie nie usatysfakcjonowała. Dlaczego? Ponieważ według niej zawsze mieliśmy i będziemy mieć do czynienia w informatyce z BigData, a jakość jednak aktualnie ten termin się pojawił podobnie jak Cloud!

Na podstawie mojego doświadczenia twierdzę, że BigData wiąże się ze specyficznymi strukturami baz danych, z którymi mamy do czynienia od momentu istnienia "user-generated content". Specyfika tych struktur polega na tym, że baza danych daje się podzielić na dwie części. Jedna z nich ma składa się z kilku tabel (zwykle nie powiązanych kluczami obcymi z pozostałą częścią bazy), które swoim rozmiarem odstają od reszty bazy. Przykładowo:

• średnia liczba wierszy w tabelach 5 mln
• średnia liczba wierszy w 2 wybranych tabelach 100 mln
• średnia wielkość większości tabel kilkanaście MB
• średnia wielkość 2 wybranych tabel 75 GB

Dodatkowo te największe tabele cechuje wysoka dynamika wzrostu. Zarządzanie taką strukturą danych za pomocą tradycyjnych silników relacyjnych baz danych nie jest ekonomiczne. Rozwiązania o bogatej funkcjonalności zaprojektowane do zapewniania transakcyjności obliczeń zatrudniamy do stosunkowo dużej liczby prostych zapytań na ogromnych wolumenach danych. Dlatego powstały rozwiązania (Hadoop, MapReduce), które wykonują operacje na tej części bazy dużo efektywniej niż tradycyjna relacyjna baza danych. Dla mnie to właśnie jest BigData.

IT-Capacity@Oracle Day

Witam,

dzięki uprzejmości Pana Pawła Płaszczaka z GridWiseTech miałem przyjemność uczestniczyć w konferencji Oracle Day w Warszawie. Temat IT-Capacity pojawił się na porywającej prezentacji Pawła jako jedna z metryk biznesowych oferowanych w ramach innowacyjnej usługi Oracle Care. Usługa ma wesprzeć długo oczekiwany przełom w relacjach pomiędzy biznesem a IT. Dzięki niej dyrektor IT może w sposób czytelny dla zarządu firmy przedstawić stan infrastruktury IT i uzasadnić niezbędne inwestycje. Usługa pozwala na gromadzenie i wizualizowanie danych o trzech kluczowych obszarach wyzwalających wydatki na IT:

• poziomie ryzyka
• kosztach
• pojemności infrastruktury IT

Taka informacja pokazana on-line i zrozumiała dla Zarządu powinna pomóc zdobyć finansowanie infrastruktury IT. Zachęcam do zapoznania się z informacjami handlowymi na ten temat - sam jestem ciekawy i nie omieszkam zajrzeć do broszury.