Tebe.blog

Umiejętność klarownego pisania nie traci na znaczeniu. Jest narzędziem komunikacji, elementem procesu podejmowania decyzji i codziennej dyscypliny. Nawet w erze czatu warto na nią zwracać uwagę.

Dlaczego potrzebne są notatki z ustaleń i spotkań? Ponieważ nasze umysły są zawodne. To co w nich zostaje z czasem coraz bardziej się różni od tego, co ustaliliśmy. Dlatego najlepiej jest spisywać decyzje zaraz po spotkaniu. Zabawne, że często już w momencie gdy przychodzi mail z notatką widzimy jak trudno jednoznacznie je uchwycić.

Pisemne notatki tworzą archiwum danych, do którego można wracać i sprawdzać czy sprawdziło się to, co przewidywaliśmy. Zmuszają autorów do bycia bardziej precyzyjnym niż wtedy, gdy coś mówią. Są środkiem samodyscypliny. Samo zapisywanie ustaleń i zobowiązań powoduje, że stają się ważniejsze. Pisanie jest ważne, czytanie nie zawsze. Sam fakt, że coś jest gdzieś spisane nadaje temu moc.

Myśli z powyższego akapitu zaczerpnąłem z książki „High Output Management” Andy Grove’a, jednego z założycieli Intela, który zmarł w tym roku. Grove był praktykiem, robił wszystko co ma wpływ na powodzenie biznesu i spisał swoje przemyślenia w niezwykle klarowny sposób. Sięgnąłem po tę książkę m.in. po to, żeby pogłębić temat OKR-ów – prostego systemu zarządzania celami. Przy okazji natrafiłem na jedną z najlepszych książek o zarządzaniu. Szczerze polecam.

Potrzebujemy Scrum Mastera czy nie? By dobrze wypełnić tę rolę potrzeba talentów społecznych, umiejętności pracy z grupą, dyscypliny i konsekwencji a to nie są rzeczy dostępne jak ocet. 

Agile nie zniknie z horyzontu. Poczytajcie choćby „Embracing Agile” z kwietniowego Harvard Business Review. Jego opublikowanie można uznać za oficjalne namaszczenie podejścia zwinnego. W „Forbesie” Steve Denning gratulował nawet autorom opublikowania artykułu „w tym Watykanie menedżmentu”. 

Jednym z odcieni agile jest scrum. W tym podejściu nie ma kogoś takiego jak Project Manager. Są za to Produkt Owner i Scrum Master. Tego drugiego najczęściej myli się z pmem, podczas gdy to o pierwszym się mówi, że to „jego projekt”. Po tej zmianie nikt już nie wie o co chodzi.

Scrum Master dużo mniej od pma wie o tym co jest robione, bardziej skupia się na tym, jak przebiega praca. Może nie rozumieć zawartości i robić dobrze to, co robi. Jeśli sięgniemy do źródeł przeczytamy wdzięczne określenie, że Scrum Master jest służącym-przywódcą zespołu. Ma np. chronić zespół przed utrudnieniami. Czasem utrudnieniem może być brak kawy czy miejsca na spotkanie, co daje świetną furtkę do roli sekretarki.

Tymczasem taki zawodnik musi być mistrzem metody, znającym na wylot używane w niej narzędzia oraz sens ich istnienia. Ten sens często miesza się nam ze ślepym stosowaniem formy. Bez względu jakie modne nazwy albo skróty mają podejścia za często skupiamy się w nich na opakowaniu zapominając czemu służą. Tymczasem w większości metodyk pracy zwanej zespołową chodzi w gruncie rzeczy o to, żeby się żółwie nie rozbiegły.

Ta urocza metafora opisuje sytuację, która zdarza się gdy kilka inteligetnych osób pracuje nad czymś razem. Im są bardziej dynamiczne i inteligentne, tym łatwiej im się zagubić w tym, co robią. Wtedy musi wkroczyć ktoś, kto przywróci ich na właściwe tory.

W scrumie takie sytuacje powinien wyłapywać Scrum Master. W ten sposób „facylituje proces”. Żeby było mu łatwiej, może sięgać po różne narzędzia, które poznał na szkoleniach i w manualach. Jednak ważniejsze tu jest zrozumienie procesów, które zachodzą w grupie. Jeśli będzie tylko pilnował procedur i organizował spotkania, łatwo stanie się sekretarką. Natomiast w idealnym układzie powinien być w stanie nauczyć zespół by sam się organizował.

Planowanie dat w rozwoju produktów przynosi więcej szkody niż pożytku. Są jednak sytuacje, kiedy nie można terminów uniknąć. Co robić a czego wtedy unikać?

Jak już pisałem, ustalanie terminów w projektach rozwojowych przypomina wróżenie. Czasem jednak nie ma wyjścia i trzeba coś zrobić w określonym czasie. Może to wynikać ze zobowiązań, zmian prawnych lub wydarzenia, którego nikt nie przesunie. Może też wynikać z potrzeby poprawy wydajności.

W pewnych sytuacjach narzucenie terminu mobilizuje. Prawo Parkinsona mówi, że praca wypełnia cały dostępny czas. Można wykorzystać termin, by je złamać. Przypomnijcie sobie jak sprawnie zamykacie sprawy przed dłuższym urlopem. Można posprzątać zaległości robiąc na serio ćwiczenie „co bym zrobił, gdybym w piątek szedł na urlop?”. Podobnie jest, gdy umawiamy się ze sobą na określony efekt np. „zakończę ten dokument dziś do 17stej”. W większej skali można przyjąć np. „do marca 90 proc. użytkowników będzie korzystać z nowej wersji systemu” i odwrócić problem pytając co trzeba zrobić, by to było możliwe.

Wiadomo, że parametry projektu są ze sobą powiązane. Programiści powtarzają chętnie, że nie można równocześnie robić rzeczy szybko i dobrze. Kiedy trzeba czegoś dostarczyć na termin niezbędne jest ograniczenie liczby rzeczy, które zostaną zrobione. Z pewnych elementów – których tworzenie zwykle uwzględnia się budując wielkie harmonogramy – trzeba zrezygnować, w innych pójść na skróty.

Gdy walczymy o termin ofiarą padają rzeczy, które mogą nie być kluczowe. W warunkach bojowych takie decyzje podejmuje się bardzo sprawnie. Lepiej jednak zawsze wiedzieć, co jest ważne. Priorytetyzacja jest kluczem, ale w normalnych warunkach jest trudna, bo wolimy trwać w iluzji, że możemy mieć wszystko. Lepiej jednak się rozwija produkty gdy wdrożenia wynikają z nieustannej priorytetyzacji a miarą powodzenia jest wzrost dostarczonej wartości w czasie. W tym podejściu ważniejszy od terminów staje się rytm pracy.

Dobre zespoły rzadko potrzebują zrywów, stale pracują żwawym tempem. Jeśli jednak działamy na termin, od samego początku warto sobie narzucić tempo. W kulcie daty jest o to trudniej. Wygrywa podejści studencko-amatorskie: zaczynamy powolutku, data wydaje się odległa, pierwsze tygodnie spędzamy w beztrosce, potem zarywamy noce i weekendy. Chwała bohaterom, ale tak nie warto.

Rzadko kto rozumie te wszystkie zależności. Dlatego ważna jest komunikacja z otoczeniem. Od początku warto uświadamiać partnerów i tzw. interesariuszy jak działamy, z czego to wynika i gdzie w danym momencie jesteśmy. Trzeba zarządzać oczekiwaniami, komunikować postęp oraz wyłapywać problemy (które się pojawiły i z którymi się mierzymy). Inna będzie reakcja gdy po 3 miesiącach ciszy przyjdziecie z problemem i wiadomością „prosimy o przesunięcie deadlinu”, inna, gdy od samego początku kluczowe osoby będą wiedziały jak nam idzie. Są przypadki, w których to nic nie da, częściej jednak można uzyskać wsparcie np. w podjęciu trudnych decyzji.

Sama data jest ważnym elementem tej komunikacji. Jeśli nie jest z góry narzucona warto zastosować trick z branży filmowej. Tam dopiero na kilka miesięcy przed finałem podaje się dzień premiery. Wcześniej określa się ją ramowo np. podając miesiąc albo kwartał. Na wczesnym etapie zobowiązania warto podawać orientacyjnie.