Tablica zadań inspirowana ideą Kanban niesłychanie rozprzestrzeniła się wśród zespołów projektowych. Oferuje niesamowitą przejrzystość i elastyczność. Przejrzystość wynika z prostoty i tego, że od razu wszystko widać. Kto zajmuje się danym zadaniem, na jakim statusie znajduje się zadanie, ile zadań czeka w ogonku. Elastyczność, bo w kanban obowiązuje tylko kilka zdroworozsądkowych zasad.
Znacznie upraszczając tą metodę można powiedzieć, że:
Zadania płyną z lewa na prawo zgodnie z ustalonym porządkiem kolumn i raczej się nie cofają.
Zespół ustalił jasne kryteria, kiedy zadanie może przeskoczyć między kolumnami.
Zadania posortowane są według ważności z góry na dół.
Członkowie zespołu mają autonomię, jeżeli chodzi o tempo brania zadań do realizacji.
Klient może regularnie dodawać zadania do pierwszej kolumny i zmieniać ich priorytety.
W idealnej sytuacji każdy członek zespołu może podjąć się dowolnego zadania, co zapewnia najoptymalniejszą alokację mocy przerobowych.
Wokół zadań mogą trwać dyskusje, zadania mogą mieć listy kontrolne, można załączać pliki i obrazki do nich.
Jednak jak obserwuję różne zespoły to praktyka stosowania tablicy kanban bywa różna. Za chwilę omówię przykłady, ale najpierw chciałbym rozstrzygnąć powody.
Pierwszym ograniczeniem Kanbana jest liniowość. Zakłada się, że zadania nie wracają i wędrują tą samą ścieżką. Dopóki dla różnych zadań można stworzyć taki sam zestaw etapów, dopóty mogą one być zarządzane wspólną tablicą. Jednak natura prac nawet w jednym projekcie bywa różna. Przykładowo inaczej produkuje się oprogramowanie, inaczej szkoli pracowników, a inaczej projektuje materiały reklamowe. Natomiast wszystkie te zadania mogą być realizowane przez jeden zespół w jednym projekcie.
Drugim ograniczeniem jest bałagan. Kanban dobrze sprawdza się dopóki lista zadań nie przekracza dwóch, trzech ekranów przewijania. Przy dłuższych listach zaczyna się bałagan. Przy większej liczbie zadań pojawia się także potrzeba klasyfikowania, grupowania, zagnieżdżania zadań. Dobrze obrazuje to użycie WBS w projektach budowlanych, albo dzielenie zadań na moduły w projektach typ hardware.
Trzecim ograniczeniem są kompetencje. Bardzo często jednym zadaniem nie może zająć się dowolny członek zespołu, bo się po prostu na tym nie zna. Konkretne zadanie musi trafić do konkretnego eksperta. Wówczas wspólna tablica nie służy balansowaniu zasobów tylko demonstrowaniu bieżących wyzwań i priorytetów.
Czwartym ograniczeniem jest różny cykl produkcyjny. Jedne zadania można machnąć w dzień lub maksymalnie w sprint. Inne jednak wymagają dużo dłuższego czasu, zatem przeskoczą między sprintami. W projektach eksploracyjnych rozwiązuje się to po prost wprowadzając sprinty o nieregularnej długości. Jednak sytuacja, gdy jakieś zadanie wisi na tablicy tygodniami, bo albo zespół czeka na dostawę komponentu z Chin, albo mozolnie zbiera dane badawcze, wprowadza zamieszanie.
Zatem, w jaki sposób zespoły przełamują te ograniczenia kanbana.
Pierwszy z omawianych projektów realizowany był w sektorze kosmicznym. Był to projekt hardware’owy, czyli jego celem było stworzenie urządzenia. Początkowo zespół stworzył klasyczną tablicę z kolumnami reprezentujacymi statusy prac. Tablica była regularnie przeglądana i zadania wędrowały z lewa na prawo. Jednak po kilku miesiącach wykorzystanie tej techniki zaczęło ewoluować. Po ponad roku tablica wyglądała mniej więcej tak:
Jak widać kluczowym wyzwaniem było pokazać stan prac w podziale na główne moduły. Wynikało to z tego, że moduły były różne kompetencyjnie i zajmowały się nimi różne zespoły.
W innym projekcie, tym razem był to startup z obszaru usług internetowych, tablica Kanban wyglądała tak:
W tym projekcie zespół też zaczął od tradycyjnego kanbana, ale po jakimś czasie zaczął modyfikować tablicę. Jak widać ważne dla niego było dodanie trzech kolumn zawierających backlog. Wynikało to z tego, że ów startup miał mnóstwo pomysłów i trzeba było wprowadzić lejek, który porządkowałby ich napływ.
W jeszcze innym projekcie IT wprowadzono kolumny reprezentujące zakresy kolejnych wdrożeń systemu. W innym dodano strumienie prac reprezentujące główne zakresy merytoryczne. W jeszcze innym podzielono prace na eksploracyjne (discovery) i produkcyjne (delivery), dodając odpowiednie kolumny z backlogami.
Czy to źle, że zespoły modyfikują metodyką? Skądże, najważniejsze kryterium to czy dane rozwiązanie działa i przynosi korzyść. Żeby działało, zespół musi się z nim utożsamiać.
Ograniczenia tablicy Kanban dostrzeżono już wcześniej i pojawiło się kilka rozszerzeń.
W niektórych systemach takich, jak Proofhub, Trello można do zadania dodać podzadania. Takie dwa poziomy zadań ułatwiają zarządzanie zakresem, gdy backlog jest bardzo długi.
W innych, jak Teamwork i Productboard, wprowadzono storymap. Jest to tablica Kanban z dodanym wymiarem Y. Zadania są podzielone również na wiersze reprezentujące kolejne etapy lub wdrożenia rozwiązania. Przyklad poniżej:
Wreszcie sam, nieskromnie dodam, również postanowiłem zająć się tym problemem i opracowałem rozwiązanie pozwalające na dowolne zagnieżdżanie zadań. To połączenie logiki WBS i tablicy Kanban.
Wroolo to ciągle jeszcze prototyp, ale starałem się zademonstrować, że możliwe jest dowolnie elastyczne zagnieżdżanie zadań w ramach jednej tablicy. Mimo możliwości przenoszenia ich przez kolejne kolumny, można nie utracić porządku w stworzonej strukturze prac.
Chętnych do sprawdzenia, jak działa filozofia kanban zapraszam do naszych dwóch symulatorów:
Agile Game – gra indywidualna na tablicy Kanban, pokazuje różne wykresy dostępne w ramach tej metodyki.
Scale Agile – gra zespołowa demonstrująca problemy bilansowania zasobów, wielozadaniowości i priorytetyzowania prac między projektami zwinnymi.
Chętnych do sprawdzenia, jak działa system Wroolo, zapraszam pod adres wroolo.com.
Jedno zastrzeżenie chcę zgłosić. Powyższe rozumienie tablicy Kanban jest zupełnie różne od tego stosowanego w zarządzaniu magazynem lub produkcją. Wspomniany w tym artykule Kanban jest znacznie uproszczoną wersją magazynowo – produkcyjnego, który był jego pierwowzorem.
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ą.
Jeżeli podasz kod Octigo10, to uzyskasz rabat w wysokości 10% na wejście na kongres zarządzania projektami.
Poniżej informacja od organizatorów:
Dzień 1 to dzień PMIthonu, czyli pierwszego w Polsce hackathonu dla Project Managerów. Będziecie mogli spróbować swoich sił w rozwiązaniu przygotowanego zadania. Nie zabraknie dyskusji i dzielenia się doświadczeniami. Jesteśmy pewni, że nie będziecie się nudzić.
Dzień 2 i 3 to tradycyjne dni prelekcji i warsztatów, na których nasi prelegenci i prelegentki poruszą tematy dotykające tegorocznego motywu przewodniego Kongresu – Transform | Project | Value
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.
W październiku rusza kolejna edycja studiów Zarządzanie projektem IT oraz Zarządzanie wymaganiami i analiza biznesowa na Akademii Koźmińskiego.
Jak co roku wprowadziliśmy kilka modyfikacji. W przypadku ZPIT to zredukowanie czasu na zarządzanie ryzykiem ilościowe charakterystyczne dla projektów kaskadowych, a rozszerzenie o jeden dzień rozważań na temat zarządzania wymaganiami (BPMN i UML) oraz elementy zarządzania eksploracją.
W przypadku ZWAB dodaliśmy moduł na temat zastosowania sztucznej inteligencji, a dokładnie modeli językowych, w analizie wymagań na bazie naszych doświadczeń zdobytych przy tworzeniu narzędzi takich, jak Dot Chart, GoodBA i Sopulo.
I teraz ważna informacja. Już zrekrutowaliśmy po jednej grupie na ZPIT i ZWAB, ale ponieważ zebrała nam się kolejka chętnych na oba kierunki, to wspólnie z Akademia Koźmińskiego uruchomiliśmy rekrutację na dodatkowe, równoległe grupy, które uruchomią się miesiąc później. Serdecznie zapraszamy wszystkich chętnych.
Postanowiłem zrobić kolejny krok, analizując możliwości sztucznej inteligencji w analizie wymagań. Napisałem system, który na podstawie wczytanej dokumentacji ma zadanie napisać instrukcję stanowiskową.
Prosi o wczytanie dokumentów opisujących dany proces. Następnie je automatycznie analizuje od strony zawartości.
Prosi o wybranie sekcji dokumentu SOP, które mają pojawić się w finalnym dokumencie. Użytkownik może dowolnie poprzestawiać ich kolejność przez przeciąganie i upuszczanie.
Każda sekcja może zostać automatycznie wygenerowana przez algorytm sztucznej inteligencji. Jeżeli użytkownikowi spodoba się rezultat, może przejść dalej. Jeżeli nie, to może ponowić generowanie, albo cofnąć się do kroku wcześniejszego i wczytać więcej dokumentacji.
Na kolejnej zakładce użytkownik może edytować wygenerowane treści według własnego uznania.
Wreszcie całość można pobrać w formacie PDF lub DOC do dalszej obróbki.
SOP (standard operating procedure) to dokument opisujący, w jaki sposób powinien zachować się pracownik w ramach pracy w danym procesie. Z jednej strony ujmuje proces w zawężonej perspektywie wybranej roli/aktora, a z drugiej strony dodatkowo zawiera informacje o oczekiwaniach jakościowych pracy, etykiecie, sposobie rozmowy z klientem, warunkach brzegowych, sposobach poprawnego wykonania zadania itd.
Idea tworzenia SOP powstała w wojsku amerykańskim, a stamtąd przeniosła się do procedur medycznych. Dzisiaj rozlewa się na świat biznesu. Odbiorcą SOP jest konkretny operator w procesie i celem jest zwiększenie jakości i powtarzalności wykonywanej pracy.
To wciąż jest prototyp i ciągle jest poprawiany. Natomiast to, co mnie przede wszystkim interesuje to, czy nawyki i oczekiwania pracowników zmieniają się w kierunku wykorzystywania takich narzędzi jak Sopulo zamiast ręcznego pisania dokumentacji.
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.
Jeżeli podasz kod Octigo10, to uzyskasz rabat w wysokości 10% na wejście na kongres zarządzania projektami.
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 październiku rusza kolejna edycja studiów Zarządzanie projektem IT oraz Zarządzanie wymaganiami i analiza biznesowa na Akademii Koźmińskiego.
To wciąż jest prototyp i ciągle jest poprawiany. Natomiast to, co mnie przede wszystkim interesuje to, czy nawyki i oczekiwania pracowników zmieniają się w kierunku wykorzystywania takich narzędzi jak Sopulo zamiast ręcznego pisania dokumentacji.
