Ni to agile, ni to klasyczne zarządzanie projektami. Zatem jak pracować?

Reading time 6 minutes




Następna konferencja za mną. Tym razem był to event organizowany przez Production Manager podczas którego miałem okazję wygłosić prezentację oraz wziąć udział w debacie. O czym mówiłem?

Oczywiście, jak zawsze o zarządzaniu projektami (tutaj powinien pojawić się wyraz zaskoczenia bo kto by się spodziewał ;). Ale! Ale! Może efekt zaskoczenia jeszcze uda się wywołać.

Otóż  prezentowałem tzw. “trzecią drogę”, czyli podejście do projektów, które ani nie są AGILE ani KLASYCZNE. Bo tak, poważnie, nie wszystko jest czasami czysto Agilowe, bądź klasyczne.

Ostatnio trochę narzekałem, że żyjemy w czasach ogromnej popularności Agile. Generalnie cieszę się, że ta niezwykle  ciekawa i użyteczna koncepcja (a może już filozofia?) upowszechnia się w naszym pięknym kraju, ale… Nie możemy jej wszędzie wciskać, niekiedy jest lepiej jest być simple classic :) Natomiast co jeśli projekt jest ni to klasyczny, ni to Agailowy?

Wyjaśniając, muszę przejść nieco do podstaw, dlatego wszyscy, którzy doskonale wiedzą czym jest Agile, sugeruję pominąć tę część.

Powyżej widzisz ścieżkę agilową vs. klasyczną. Idea i różnica między jest całkiem prosta. Zamiast skupiać się na stworzeniu precyzyjnych i przewidywalnych planów, tniesz projekt na małe części i dostarczasz kawałek po kawałku. Oczywiście, ma to sens, gdy realizujesz przedsięwzięcia o dużej niestabilności i zmienności zakresu (co życzyłbym wszystkim pamiętać. Przewidywalny projekt, serio nie musi mieć Agile).  To tak w wielkim skrócie i uproszczeniu.

Ale – co ważne, nasz menedżerski (mówiąc w lengłidżu)  “focus”, koncentruje się na drożeniu poniższego sposobu funkcjonowania zespołu:

Przyjrzyj się temu schematowi. Jeżeli zamienię zwrot “product backlog” na listę wymaganych funkcjonalności projektu, a “sprint backlog” na plan wydania konkretnych funkcjonalności w danym i stałym okresie czasu, to podejście powinno być zrozumiałe.

Jakie są główne zalety wdrożenia i posługiwania się Agile?

W mojej ocenia, top 3 korzyści i przewagi tego podejścia to:

  • Szybko dostępny częściowy efekt.
  • Zespół jest przyzwyczajany do uczenia się na własnych błędach.
  • Produkuje się  znacznie mniej dokumentacji (i nie chodzi tutaj tylko o ekologię ;)).

Jednak (tutaj chwila grozy dla bezpamiętnie zakochanych w Agile) – nie wszystkie projekty dowieziemy na wózku agilowym. Tak, nie wszystkie, ponieważ nie możemy pociąć mostu, drogi, ani magazynu na mniejsze kawałki i dostarczać ich klientowi. Co on biedny zrobi z kawałkiem mostu, drogi, czy magazynu? I w tym momencie proponuję simple classic, powrót do tradycji i do klasycznego podejścia. Oczywiście możesz korzystać nadal z elementów Agile, ale raczej z tych “miękkich” np. obsesji zespołu do ciągłego doskonalenia się i poszukiwania usprawnień na podstawie obserwacji wcześniejszej realizacji.

Co natomiast, gdy, projekt ani nie łapie się w kategorie zwinnego zarządzania projektami, ani klasycznego? Co to za projekt? Jak go realizować? Tutaj właśnie pojawia się tzw. “trzecia droga” korzystająca z obu podejść – agile i classic.

Wyjaśniając. Istnieją projekty, które wymagają od nas stałego informowania Sponsora o postępie w realizacji. Równocześnie nie są one na tyle przewidywalne i stałe, aby bazować na rozbudowanym i skomplikowanym harmonogramie. Przykład? Projekt, o którym wcześniej pisałem, czyli budowa tunelu kolejowego w Serbii (a w zasadzie dwóch, równoległych).

Przedsięwzięcie stricte infrastrukturalne, zatem, czy mamy tutaj Agile? Nie bardzo. W końcu, nie mogę powiedzieć “okej Panowie, teraz zbudujemy sobie przejście między tunelami, które nie istnieją. Później zajmiemy się instalacją wsporników, a w zasadzie, to w najbliższych 4 tygodniach skupiamy się na betonowaniu”.

Wobec tego co? Klasyczna kaskada będzie w tym przypadku idealna? A no właśnie również nie bardzo. Warunki geologiczne, głębokość tunelu itd. wymagają od nas ciągłej aktualizacji, a co za tym idzie – zmiany koncepcji.

Wobec tego jak pracujemy?

  • Posiadamy plan. Z tym, że jest on bardzo ogólny,  podzielony na duże zadania. Monitorowanie oraz raportowanie postępu do Sponsora odbywa się co miesiąc. Ta informacja jest tak samo ważna i wymagana od nas jak koszty i nakłady inwestycyjne.
  • Raz na dwa tygodnie dokonujemy szczegółowego planowania konkretnych działań i wybieramy odpowiednią technologię. Postęp w realizacji zadań śledzimy codziennie (każdego poranku).
  • Mamy powołany Issue Resolution Team – zespół osób o określonych kompetencjach, które wymyślają rozwiązania dla wszystkich wyzwań/problemów, które nie wymagają natychmiastowej reakcji. Tych wyzwań nie możemy pominąć, bo nic się jeszcze przez nie nie zawali, ale może w przyszłości, a teraz  możemy stracić szansę na skrócenie czasu realizacji, czy zmniejszenie wydatków.
  • Posiadamy ustawione systemy natychmiastowego reagowania. W każdej chwili, 24h/dobę, pod poniedziałku do niedzieli, w święta i inne ważne dni, jest ktoś, kto podejmie decyzję, dokona interwencji. Dopiero co uczestniczyłem w jednej awarii. Kierownik Projektu przyjechał na budowę o 2.30 nad ranem, bo była taka potrzeba.
  • Mamy uruchomione systemy komunikacyjne, które całkowicie wyeliminowały potrzebę kontaktu mailowego w zespole. Z każdego miejsca na świecie możemy się “połączyć z projektem”, sprawdzić zaawansowanie, przejrzeć ważne kwestie.
  • Raz na dwa tygodnie robimy “lesson learned”.  Członkowie zespołu, faktycznie zgłaszają to, czego się nauczyli i co możemy zastosować. Bardzo to cieszy.

Tak to robimy.  Sześć naszych głównych zasad realizacji projektu zarządzanego nie tylko według Agile i nie tylko według klasycznego podejścia. Czy nam się uda? Liczę na to. Presja jest ogromna, ale dla równowagi wsparcie również.

Jaki jest cel tego tekstu oprócz podzielenie się tą wiedzą? 

Szukajmy rozwiązań hybrydowych, takie jak te, które teraz przedstawiłem. Nie zakładajmy na siłę kapelusza, który jest w tym samym stopniu piękny, co fatalnie do nas dobrany.

Pozdrawiam serdecznie

Tomek Wrzesiewski

author
KOMENTARZE