Podejście kaskadowe (15000 lat testów) oferuje uporządkowanie i przewidywalność, przynajmniej teoretycznie. Z góry przemyślany produkt finalny, dowożony w terminie i koszcie. W praktyce oferuje natomiast inną korzyść – porządek w dużej skali.
Estymacje mogą okazać się błędne, natomiast jeżeli projekt prowadzony jest metodycznie, to wiadomo dokładnie, w którym miejscu znajduje się błąd i jakiej jest skali. To w konsekwencji umożliwia realizację nawet dużych inwestycji bez wpadania w chaos.
Podejście zwinne (30 lat testów) oferują zaś sprawność działania, przynajmniej teoretycznie. Jednak zbudowanie postaw, modelu mentalnego nastawionego na obserwacje i akceptację zmian zwiększa responsywność projektu na nowe pomysły. To w efekcie ma prowadzić do większej wartości, kosztem utraty kontrolowalności projektu. Ta utrata kontroli mści się ze spotęgowaną siłą, gdy skala projektu rośnie. Zaryzykuję tezę, że agile jest raczej dla projektów małych.
Hybrydowe zarządzanie projektami (dalej będę używał skrótu HPM) powinno być hybrydowe w różnych wymiarach. Zatem dalsze rozważania przeprowadzę po kolei według zakresu, czasu, kosztu, jakości i zespołu.
Zakres
WBS kontra Product Backlog. WBS super moce:
Uporządkowanie odgórne.
Możliwość uporządkowanego poruszania się po nawet bardzo dużym zakresie, o ile wprowadzono sensowną strukturę.
Zgodność z metodami ścieżki krytycznej i wartości wypracowanej. Dla projektów kaskadowych dużą wartością jest możliwość precyzyjnej kontroli stanu. Dzięki WBS jest możliwe wykorzystanie precyzyjnych metod kontroli.
WBS słabości:
Odporność na zmiany. WBS zniechęca kierownika projektu do wprowadzania zmian w zakresie.
Konsekwencje zmian w WBS w innych wymiarach. Przykładowo zmiana tylko sposobu poukładania komponentów w WBS może wysadzić w powietrze wskaźniki wartości wypracowanej.
Ryzyko niekontrolowanego pełzania zmian w sytuacji, gdy planowany produkt finalny nie odpowiada potrzebom klienta.
Product backlog super moce:
Niski próg wejścia. Każdy kto miał mamę, pamięta listy zakupów. Backlog to taka lista zakupów tyle, że posortowana według ważności a nie kategorii.
Elastyczność wobec zmian. Gdy pojawia sie nowy, ważniejszy pomysł, po prostu ląduje na górze backlogu.
Zgodność z tablicą Kanban.
Słabości backlogu:
Próbowaliście kiedyś zarządzać backlogiem mającym 200 pozycji? Już przy backlogu długim na dwa ekrany pojawia się problem z utrzymaniem jego aktualności.
Brak wewnętrznej logiki i struktury. Backlog to po prostu worek życzeń. Gdyby święty Mikołaj nie był w stanie zapamiętać wszystkich dzieci na świecie, to pewnie używałby backlogu.
W naturalny sposób pojawia się pytanie, dlaczego nie można połączyć obu podejść. I wybrane systemy do zarządzania projektami czynią w tym kierunku kroki. W Trello można wstawiać podzadania do zadania w formie checklisty, w Proofhub dopuszczalne są dwa poziomy zagłębień zadań, w Teamwork karta wymagania może być zdekomponowana na zadania i dopiero one wędrują po kanbanie.
Sam również pokusiłem się, o takie rozwiązanie i byłem strasznie zadowolony, gdy udało mi się je zaimplementować.
Czas
Kaskadowe projekty zakładają istnienie harmonogramu z datami, miejscami alokacji zasobów ludzkich i nieludzkich. Dzięki temu można identyfikować wąskie gardła, optymalnie przydzielać ograniczone zasoby do wielu projektów naraz, przewidywać przepływy finansowe oraz kontraktowe zobowiązania.
Silne strony podejścia kaskadowego:
subiektywne poczucie władzy nad czasem,
transparentna komunikacja mapy drogowej.
Słabości:
niska wiarygodność estymacji,
skomplikowane zarządzanie, gdy wprowadzimy wiele zależności do ścieżki krytycznej.
Zwinne projekty zakładają istnienie stałego rytmu (iteracji) i niezdeterminowanego końca.
Silne strony podejścia zwinnego:
duża elastyczność zmian wymagań,
przejrzystość zadań,
wsparcie samoorganizacji zespołu,
oparcie na empirycznych czasach a nie teoretycznych estymacjach.
Słabości:
łatwość zabałaganienia w przypadku większych projektów,
nie odzwierciedlenie różnych procesów produkcyjnych zadań.
nie odzwierciedlenie zależności i ograniczeń zadań.
Ta rozbieżność rodzi ryzyka, że projekt kaskadowy zawierający w sobie zwinny rozjedzie się w czasie.
Silne strony filozofii zwinnej:
budowanie motywacji wewnętrznej,
wzmacnianie postaw nastawionych na innowacji i dostarczanie wartości.
Słabe strony:
rozproszenie odpowiedzialności,
chaos komunikacyjny w większych zespołach,
brak twardego rozliczania i narzędzi motywacji negatywnej w przypadku porażek.
W podejściu hybrydowym często obarczamy kierownika projektu ryzyko rozjazdu sprintów z Ganttem. Większość systemu do kanbana pozwala na wprowadzenie dat zadań (co jest w istocie niezgodne z ideą kanbana), a wiele z nich również pozwala na wyświetlenie widoku kanbana na kalendarzu albo na uproszczonym Ganttcie.
Koszt
Tu mam największą zagwozdkę. Bo agile nic nie mówi o koszcie projektu a waterfall dużo.
Jednak mając rozliczone co do godzin zadania (co jest nie do końca zgodne z ideą autonomii zespołu) można śledzić zużycie środków finansowych w czasie i śledzić szansę zmieszczenia się w budżecie. Raportowanie kosztu wspiera większość systemu do kanbana, np. Proofhub, Monday, Clickup, Jira, a nawet Trello po zainstalowaniu odpowiedniego pluginu.
Zespół
I tutaj mamy największy rozjazd stylów współpracy. Kaskada wspiera przywództwo w stylu dziel i kontroluj. PM dekomponuje zadania, deleguje je na członków zespołu, a potem odpytuje, czy praca idzie zgodnie z planem.
Silne strony podejścia kaskadowego:
nieograniczone możliwości skalowania zespołu przez delegowanie i pionizowanie struktury organizacyjnej,
jasny podział odpowiedzialności.
Słabości:
redukcja motywacji wewnętrznej i innowacyjności zespołu,
kierownik projektu może stać się wąskim gardłem.
Natomiast w agile nie ma kierownika projektu. Zespół zbiorowo odpowiada za zadania i autonomicznie je sobie przydziela.
Myślę, że dużo zależy od stylu. Jeżeli mamy kierownika projektu, który z jednej strony potrafi wyciągnąć estymacje czasu i kosztu z zespołu, a z drugiej strony kontroluje postęp prac w sposób nieinwazyjny, wspiera w trudnych momentach i ufa ludziom, to ma to szansę zadziałać. Przyjazna dyktatura jest kwestią stylu.
Podsumowanie
Od kilku lat zaczyna się pojawiać, narazie nieśmiało, hasło hybrydowego zarządzania projektami. Poniżej zamieszczam wykres Google Trends pokazujący jego rosnącą popularność.
Dlaczego HPM może okazać się nowym trendem? Bo ciągle pozostaje problem skalowalności agile’a. SAFe spotyka się dzisiaj z olbrzymią falą krytyki, ale potrzeba organizacji, aby jednocześnie dać autonomię i otworzyć projekty na zmiany oraz zapewnić kontrolę i uzgadnianie z zadaną strategią pozostaje.
Bo projekty kaskadowe lepiej zapobiegają nieprzewidzianym kosztom zmian, a projekty zwinne lepiej odkrywają wartość dla użytkownika końcowego.
Na tytułowym obrazku hybrydowy project manager według koncepcji MidJourney. Żeby nie zostać posądzonym o seksizm, załączam też wersję ilustracji kobiecą.
Przy okazji niedawnego szkolenia w ręce wpadła mi metodyka PRISM przygotowana przez stowarzyszenie Green Project Management. Postanowiłem się podzielić moimi spostrzeżeniami na temat tej metodyki i w ogóle podejścia Green Project Management.
GPM jest stowarzyszeniem przypominającym nieco PMI 40 lat temu. Chyba stowarzyszeniem, bo trudno mi było znaleźć na ich witrynie konkretne dane rejestrowe. Ale odnoszę wrażenie, że grupa woluntariuszy zorganizowała się wokół wspólnej idei uczynienia inwestycji projektowych bardziej zielonymi.
GPM oferuje 3 poziomy certyfikatów, które w formule ich zdobywania bardzo przypominają PRINCE2 Foundation i Practitioner. Krótkie test albo studium przypadku i rozmowa. Szybki test ilości ogłoszeń o pracę wymagających któregoś z tych certyfikatów pokazuje, że jeszcze długa droga przed nimi. Dla porównania PMP w momencie pisania tego tekstu występował w Polsce w ponad 5000 ogłoszeń, GPM-b + GPM-s + GPM-m w żadnym, dosłownie zero ogłoszeń. Rozszerzyłem wyszukiwanie na USA i wyniki były identyczne 347 000 do zera na korzyść PMP. Nie oceniam w żadnym wypadku merytoryki tych certyfikatów tylko popularność wśród pracodawców, ale uważam, że ten wskaźnik jest niestety bardziej pragmatyczny.
Wiedza na certyfikacji bazuje na kolejnym komponencie, czyli metodyce PRISM. De facto nie zdefiniowałbym PRISM jako metodyki, ale raczej nakładki na metodykę, która podkreśla istotność pewnych obszarów. Czyli PRISM nie powie, jak prowadzić projekt, tylko, jakie postawy i zachowania są pożądane w projekcie.
A te postawy należą do trzech grup: środowisko naturalne, lokalna społeczność i prawa człowieka. PRISM promuje prowadzenie projektów zgodne z prawem, promujące lokalną ekonomię, dbanie o interesy lokalnej ludności, poszanowanie praw człowieka takich, jak work-life balance, uczciwa płaca, brak dyskryminacji itp.
Problemem dla mnie jest fakt, że te dobre praktyki są przedstawione na poziomie bardzo ogólnym. PRISM nie mówi, co operacyjnie robić, tylko, co warto mieć na uwadze. Oznacza to, że z dużą łatwością można wdrożyć PRISM bardzo fasadowo. Wystarczy zademonstrować kiika przykładów właściwych starań.
PRISM jest metodyką kaskadową. Promuje się z góry zdefiniowany cykl życia projektu składający się z inicjacji, 4 etapów projektowych i etapu obserwowania korzyści po projekcie. Fajne jest uwzględnienie zarządzania korzyściami, którego brakuje w PMBOK a jest obecne w Standard for Program Management PMI.
Godne uznania jest też ujęcie w cyklu życia etapu eksploracji, w trakcie którego zespół zdobywa wiedzę o możliwych do realizacji koncepcjach. Jak widać eksploracja przebija się powoli do świadomości w różnych inicjatywach.
Za wyjątkiem jednak kilku praktyk brakuje w PRISM konkretów. Brakuje operacyjności, czyli wiedzy jak wdrożyć PRISM w konkretnej sytuacji. Jest to szczególnie istotne, bo GPM proponuje audyt organizacji w zakresie wdrożenia ich metodyki.
Podsumowując, GPM jest mało znaną inicjatywą, która od kilkunastu lat próbuje się przebić na rynek. Przebija się za pomocą certyfikatów, metodyki PRISM oraz audytów organizacji PSM3. Jednak odnoszę wrażenie, że o ile jakaś regulacja unijna nie wymusi malowania projektów na zielono, to długa droga przed GPM, aby osiągnąć status zbliżony do PRINCE, IPMA, czy PMI.
Emilia wysłała mi informacje rejestracyjne GPM, które udało się odnaleźć po rejestracji znaku towarowego. GPM okazuje się być spółką z ograniczoną odpowiedzialnością (LLC) zlokalizowaną w Fort Wayne.
Pojawienie się algorytmów generatywnych języka naturalnego uruchomiło lawinę rozwiązań. Dzisiaj mamy na rynku dostępnych grubo ponad 1000 startupów, które wykorzystują GPT. Za chwilę, gdy Google udostępni swojego Palm, pojawią się dziesiątki rozwiązań opartych na tym algorytmie.
Generalnie traktuję te algorytmy jako „czarne skrzynki” przetwarzające jedne teksty w drugie i to całkiem sprytnie, czyli takie, które człowiek może twórczo interpretować. Dotyczy to wszelkich prac biurowych w sektorze publicznym (decyzje, pisma urzędnicze), jak i prywatnym (komunikacja z klientem, księgowość, ofertowanie, treści marketingowe, dokumenty prawne).
Gdzie sztuczna inteligencja już działa
W aspekcie zarządzania projektami miejsce zastosowania takich algorytmów pojawia się wszędzie tam, gdzie mamy do czynienia z tekstem na wejściu i tekstem na wyjściu. Idąc od początku cyklu życia projektu, takie miejsca można zauważyć na przykład na etapach:
Inicjacji projektu – odpowiednio podrasowany GPT potrafi już tworzyć typowe dokumenty. Brzmią one dosyć generatywnie, jak gdyby pisał je student zarządzania projektami, ale to moim zdaniem kwestia zbioru uczącego. Dobry fine-tuning modelu i karty projekty będą wyglądały, jak złoto. Obok macie przykład project chartera wygenerowanego dla zadanego przykładu. Z resztą możecie sami sprawdzić na GoodBA, jak to działa. Dodam tylko, że GoodBA korzysta z GPT 3, a załączony przykład jest z GPT 4 i widać tu postęp technologiczny.
Analizy wymagań – aby sprawdzić, możliwości automatyzowania analizy wymagań, stworzyłem system GoodBA. W mojej opinii, dla generatywnych aplikacji działa to całkiem nieźle. Więcej o takim podejściu do analizy wymagań przeczytasz tutaj.
Planowania zakresu – mając dobrze opisane wymagania, GPT naprawdę nieźle daje sobie radę ze stworzeniem planu zakresu w formule WBS, czy tez Backlog. Naprawdę niewiele trzeba po nim poprawiać, bo w tym wypadku robi to, co umie najlepiej restrukturyzuje podany mu tekst.
Planowania ryzyk – wyobrażam sobie i chętnie sprawdziłbym to na przykładzie jakiejś firmy, że gdyby wytrenować model GPT na zbiorze danych o ryzykach z przeszłych projektów, to mógłby generować całkiem porządną wstępną analizę ryzyk dla kolejnego. Zakładam, że musiałaby to być baza zawierająca nie tyle przewidywane ryzyka, co rzeczywiście występujące w historycznych projektach.
Przygotowania kontraktów – w tym obszarze pojawiło się wiele startupów, które pozwalają na generowanie pism prawnych, w tym umów. Niech najlepiej o możliwościach automatyzacji obszaru prawnego świadczy olbrzymi spadek notowań giganta prawnego z USA – Legalzoom, który można było obserwować w momencie wydania GPT 3. Obok macie wykres kursów Legalzoom – spadek o 70%!
Komunikacji z interesariuszami – Notion wypuściło moduł AI, a Nuclino – Sidekick. Oba to integracje z GPT mające na celu przyśpieszyć komunikację z użytkownikami. Wystarczy napisać swój komunikat, a potem poprosić, aby automat dodał do tego trochę energii, zmienił klimat na weselszy, wydłużył o dwa akapity oraz przetłumaczył na mongolski. I wszystko to automatycznie.
A gdzie jeszcze nie działa AI
GPT słabo sobie daje radę z wnioskowaniem symbolicznym. Widziałem próby pytania go o działania matematyczne, ale poziom błędowości tutaj jest wciąż wysoki. Jest to algorytm do przewidywania, jaki tekst powinien być napisany po zadanym prompt’cie. W efekcie dopisuje absurdalne wyniki. W przypadku matematyki obejściem tego problemu jest skorzystanie z pluginu Wolfram. Jednak, jeżeli wyobraziłbym sobie wygenerowanie tabeli z kosztami projektu na podstawie opisu wymagań i obciążenia zasobów, to bym poległ.
Pewne nadzieje daje technika pisania promptów zwana chain of thought, czyli tworzenie serii zapytań, w toku których powstaje ustrukturalizowany opis, na podstawie którego z kolei można wygenerować bardziej zaawansowane modele. Sam wykorzystuję to do generowania map procesów w systemie Dot Chart. Obok macie przykład mapy procesu, która została wygenerowana automatycznie na podstawie opisu językiem naturalnym.
Oczami wyobraźni widzę algorytm, który z jednej strony przetwarza teksty pisane językiem naturalnym, ale równolegle z drugiej strony identyfikuje wartości zawarte w tekście i wnioskuje na ich podstawie w sposób bardziej symboliczny tak, jak robią to algorytmy uczenia maszynowego. Taka hybryda GPT i ML.
Kolejny problem związany z brakiem wnioskowania symbolicznego jest słaba jakość rewizji utworzonej dokumentacji. Właściwie zawsze człowiek musi przejrzeć to, co utworzył GPT i przynajmniej lekko zmodyfikować. Algorytm nie potrafi skutecznie wykryć wszystkich luk i niespójności w wygenerowanym tekście na podstawie zadanych kryteriów. Testowałem go na przykładzie studów przypadków biznesowych i osiąga tutaj połowiczny sukces.
Wreszcie GPT słabo sobie radzi z treściami specyficznymi dla konkretnej firmy lub organizacji publicznej. To, co generuje jest raczej dość ogólne. Gdyby chcieć stworzyć opis programu na przykład do obliczania ryzykowności klientów banku detalicznego, to zapewne polegnie. Ale mamy tutaj rozwiazanie pod ręką, a jest nim „fine-tuning”. Jestem po lekturze dokumentacji, jak podkręcać GPT, ale niestety nie mam dostępu do przykładowych treści z jakiejś organizacji, aby przeprowadzić samodzielne testy. Mam nadzieję, że przez wakacje uda mi się wygenerować jakiś prototyp również w tym aspekcie.
Podsumowanie
Całość mógłbym podsumować stwierdzeniem, że zniknie syndrom czystej kartki. Chodzi mi o sytuację, gdy kierownik projektu będzie siadał do planowania projektu z czystą kartką i ją mozolnie wypełniał. Wkrótce będzie siadał z wstępnie wypełnionym dokumentem, czyli zawierającym 80%-90% treści, który będzie musiał sprawdzić, uzupełnić o braki i nadać mu bardziej ludzki ton, np. wprowadzić kilka drobnych błędów. 😉
Ale rewolucja AI w moim przekonaniu oznacza koniec pracy nad czystą kartką. Coś na starcie zawsze będzie na niej wpisane przez algorytmy sztucznej inteligencji.
GoodBA to narzędzie do automatycznego tworzenia dokumentacji wymagań systemu IT.
Użytkownik w pierwszym kroku wprowadza opis swojego pomysłu na system. GoodBA zintegrowana z GPT radzi sobie z opisami w języku polskim, ale lepiej jednak działa, gdy opis jest po angielsku. Dla lepszych wyników opis można uzupełnić o kontekst biznesowy zawierający cele, wymagania biznesowe, ograniczenia prawne itd.
W kolejnym kroku GoodBA generuje listę ról użytkowników, która często może być z marszu wykorzystana do dalszej analizy. Użytkownik może też wyedytować tą listę zanim przejdzie dalej.
Następnie dla każdej roli użytkownik może wygenerować funkcje. GoodBA podpowie, jakie funkcje każda rola może wykonywać. Te funkcje znowu można edytować, dodawać nowe, albo grupować, gdy funkcja się powtarza.
Od tego momentu użytkownik może wybrać dwie ścieżki:
Dalej generować dokumentację wymagań.
Przełączyć się na planowanie zakresu projektu w formie Product Backlogu lub Struktury Podziału Prac (WBS)
W przypadku wybrania ścieżki kontynuowania prac nad dokumentacją użytkownik może stworzyć proces na podstawie funkcji. Aktualnie GoodBA korzysta z GPT 3 i użytkownik samodzielnie musi opisać przebieg procesu językiem naturalnym. Na tej podstawie GoodBA narysuje diagram procesu w dwóch formatach: Dot Chart lub BPMN.
Robiliśmy testy na GPT 4 i okazuje się, że nowsza wersja tego algorytmu radzi sobie z tworzeniem opisów generycznych procesów, więc, jak tylko uzyskamy dostęp do API, rozszerzymy GoodBA o tą funkcję.
W ostatnim kroku użytkownik może wygenerować listę ekranów, które powinny znaleźć się w systemie. Znowu dzieje się to automatycznie, natomiast użytkownik może później edytować listę ekranów po swojemu.
Na koniec całą dokumentację można pobrać na komputer w postaci pliku PDF.
Jeżeli użytkownik przełączy się na funkcje planowania zakresu, GoodBA przygotuje dla niego backlog i wstawi go do prostej tablicy Kanban. Prostej, lecz można z nią normalnie pracować, zapisuje stan zadań, pozwala na edycję ich zawartości i dodawanie nowych.
Backlog można też pobrać do pliku arkusza kalkulacyjnego.
Użytkownik alternatywnie może też wygenerować strukturę podziału prac (WBS), a następnie pobrać ją na swój komputer w postaci arkusza kalkulacyjnego.
Zachęcamy do sprawdzenia możliwości naszej aplikacji: GoodBA. Wierzymy, że może ona wesprzeć zarówno analityków biznesowych, jak i pracowników nietechnicznych, którzy potrzebują zamówić w IT napisanie rozwiązania.
Szczególnie świetnie sprawdza się w przypadku aplikacji tzw. frontendowych, czyli takich, których główną funkcjonalnością jest odczytywanie, edytowanie i dodawanie danych przez użytkownika końcowego za pośrednictwem interface’u WWW, czyli przeglądarki internetowej.
Gorzej radzi sobie z aplikacjami, w których głównym komponentem są algorytmy obliczające zadane równania lub transferujące dane między różnymi systemami. Wynika to prawdopodobnie z tego, że GPT, z którym GoodBA jest zintegrowana został wytrenowany na danych obecnych w internecie, a tam można znaleźć więcej przykładów systemów tej pierwszej kategorii.
PMBOK powstał jako encyklopedia zarządzania projektami, korzystając z której firmy muszą zbudować własną metodykę przez właściwą selekcję i adaptację metod.
Dwadzieścia lat temu pojawiło się kilkanaście metodyk zwinnych, z których świat zdominował Scrum z elementami Kanban i XP. Te podejścia zwane też procesami lub frameworkami mają nieco inną logikę. Przykładowo Scrum Guide prezentuje konkretny zestaw terminów, technik, spotkań, dokumentów, ról, które powinny się pojawić w zespole praktykującym zwinność.
Spójrz proszę na poniższy wykres. Prezentuje trend wyszukiwań dwóch haseł w Google w USA. Zwróciłeś uwagę, jak czerwona linia opada i przecina się z rosnącą linią niebieską? Otóż czerwona linia to hasło „pmbok”, a niebieska to „agile waterfall”.
Wielokrotnie w artykułach na blogu odnosiłem się do analiz firmy Gartner o nazwie Hype Cycle. Jednak dziś po spędzeniu poranka na przeglądania tuzinów wykresów hype’u w różnych kategoriach nie znalazłem odpowiedzi, co będzie trendem w zarządzaniu projektami w najbliższym okresie.
Sięgnąłem więc do drugiego źródła – aplikacji Google Trends. Google Trends pokazuje częstotliwość wyszukiwań wybranych haseł. Choć nie wyświetla bezwzględnej wartości w danym okresie, to pozwala na porównanie różnych haseł do siebie oraz spojrzenie wiele lat wstecz, aby dostrzec trendy.
Uznałem, że dla potrzeb prognoz tego, co się będzie działo w biznesie dobrze jest wybrać duży, dojrzały rynek, który inspiruje często resztę planety, czyli USA.
Oczywiście hasło „agile waterfall” może być użyte w wielu różnych kontekstach. Na przykład dla poczytania o różnicach między tymi podejściami, znalezienie rozwiązania na projekty hybrydowe, dowiedzenia się w ogóle więcej na temat tego, co dzieje się w świecie project management. Podobnie „kanban” może być wyszukiwany w kontekście zarządzania projektami, jak i produkcją lub magazynem. To są dwa różne światy. Ale zaryzykuję stwierdzenie, że ogólna dynamika i wzajemne proporcje popularności tych terminów są symptomatyczne.
Dla porównania kolejny wykres pokazuje takie terminy, jak: „scrum” (niebieski), „kanban” (czerwony), „pmbok” (źółty), „prince2” (zielony). Nie użyłem słowa „waterfall”, bo ma ono jeszcze inne znaczenia, co bardzo zaburzyłoby wykres.
Jak widać w 2004 wszystkie te hasła za wyjątkiem „prince2”, były na tym samym poziomie popularności. Ale… „pmbok” od lat powoli tracił, a „kanban” i „scrum” zyskiwały. Teraz widać, dlaczego PMI tak mocno przebudował PMBOK Guide w kierunku zwinności.
Dla porównania przyjrzałem się jeszcze innym czterem terminom: „pmbok” jako punkt odniesienia (niebieski), „kaizen” (czerwony), „six sigma” (żółty), „scrum” (zielony). Jak widać niesłychanie niegdyś modna Six Sigma w USA, zalicza spadek, choć wyhamowujący. Zgaduję, że odnalazła swoją niszę i tam jest stosowana, ale jest to dużo mniejszy obszar niż niegdyś. Podobnie ma się sytuacja z Kaizenem.
Moja interpretacja
Sądzę, że metody zwinne z sukcesem zdobywają kolejne dziedziny gospodarki i teraz sięgnęły do obszarów, które były zarządzane w sposób tradycyjny. Albo pracownicy z tych obszarów chcą dowiedzieć się, o co chodzi z tym agilem, albo szukają sposobu na wdrożenie go. Jeżeli prawdą jest, że próbuje się go wdrażać w dziedzinach nie związanych z produkcją oprogramowania, to zobaczylibyśmy to na wykresie popularności słów w wyszukiwaniach.
I… ta dam. Niebieska linia to słowo „pmbok”, a czerwona to „hybrid project”.
Widzisz trend opadający tej pierwszej i wznoszący tej drugiej?
Moja teza jest taka, że aktualnie mnóstwo organizacji poszukuje formuły połączenia filozofii kaskadowej ze zwinną. Z jednej strony chcą zachować kontrolę nad kosztami, celami, efektywnością zespołów i całych firm, a z drugiej chciałyby dać zespołom operacyjnym więcej autonomii, bo zauważają, że poczucie sprawczości wzmacnia motywację wewnętrzną, zwiększa reaktywność na zmiany oraz podnosi poziom innowacyjności. Przy okazji organizacją chcą jeszcze załatwić sobie problem skalowania Scruma do dużych struktur.
Jest pewna koncepcja, która obiecuje skalowalność Scruma, poczucie kontroli na poziomie strategicznym oraz pozostawienie zwinności na dole. To Scaled Agile Framework (SAFE). W internecie można znaleźć mnóstwo artykułów o zaletach i być może jeszcze więcej o słabościach tej koncepcji. Jednego nie można jej jednak zabrać, jest coraz bardziej popularna. Kilka lat temu PMI próbował gonić SAFE, nabywając metodykę Disciplined Agile Delivery (DAD). Jednak zobaczcie na efekty.
Żółta linia to właśnie „discipllined agile delivery”, to ta której nie widać. Czerwona to dla porównania „pmbok”, zaś niebieska to „scaled agile framework”.
Widzisz, drogi czytelniku, jak przecięły się w 2016 roku i jaką dynamikę mają teraz?
Nie sądzę, aby SAFE załatwił problem hybrydowości zarządzania. Zbyt wiele jest problemów przy jego wdrażaniu. Jednak jestem bardzo przekonany, że projekty hybrydowe oraz powiązane z tym skalowanie zwinności, będą istotnym trendem w przyszłości. Pewnie pojawią się kolejne koncepcje, aż w końcu znajdziemy coś, co będzie dostatecznie dobre.
Dodam jeszcze mój osobisty wkład w hybrydyzację projektów. Idea połączenia zwinności z kaskadą chodziła za mną od dłuższego czasu. Szczególnie interesował mnie wymiar zakresu. Z jednej strony mamy WBS, czyli hierarchiczną strukturę prac. Jest wygodny, bo zachowuje logikę, pozwala przechodzić od ogółu do szczegółu, a dzięki temu jest skalowalny. Z drugiej strony mamy Product Backlog, którego zaletą jest łatwość zarządzania, przejrzystość oraz prezentacja istotności poszczególnych wymagań.
Jakiś czas temu wymyśliłem koncepcję połączenia tych dwóch technik i wyszło mi coś takiego. Pierwsze wrażenia są bardzo obiecujące, sam własne projekty trzymam w takiej tablicy. Możliwość budowania hierarchii ułatwia utrzymanie porządku na liście zadań, a możliwość automatycznej konwersji do tablicy Kanban pozwala na płynne przejście do zarządzania ich wykonanie. Nie spotkałem takie funkcjonalności w komercyjnych systemach i ciekaw jestem, czy Ty, drogi czytelniku, gdzieś już ją widziałeś. Jeżeli tak, to koniecznie daj mi znać.
Podejście kaskadowe (15000 lat testów) oferuje uporządkowanie i przewidywalność, przynajmniej teoretycznie. Z góry przemyślany produkt finalny, dowożony w terminie i koszcie. W praktyce oferuje natomiast inną korzyść – porządek w dużej skali.
Przy okazji niedawnego szkolenia w ręce wpadła mi metodyka PRISM przygotowana przez stowarzyszenie Green Project Management. Postanowiłem się podzielić moimi spostrzeżeniami na temat tej metodyki i w ogóle podejścia Green Project Management.
W aspekcie zarządzania projektami miejsce zastosowania takich algorytmów pojawia się wszędzie tam, gdzie mamy do czynienia z tekstem na wejściu i tekstem na wyjściu. Idąc od początku cyklu życia projektu, takie miejsca można zauważyć na przykład na etapach:
ygotowania kontraktów – w tym obszarze pojawiło się wiele startupów, które pozwalają na generowanie pism prawnych, w tym umów. Niech najlepiej o możliwościach automatyzacji obszaru prawnego świadczy olbrzymi spadek notowań giganta prawnego z USA – Legalzoom, który można było obserwować w momencie wydania GPT 3. Obok macie wykres kursów Legalzoom – spadek o 70%!
Wielokrotnie w artykułach na blogu odnosiłem się do analiz firmy Gartner o nazwie Hype Cycle. Jednak dziś po spędzeniu poranka na przeglądania tuzinów wykresów hype’u w różnych kategoriach nie znalazłem odpowiedzi, co będzie trendem w zarządzaniu projektami w najbliższym okresie.
