Jak wygrać hackathon, albo realizować projekty pod presją czasu

Jak wygrać hackathon, albo realizować projekty pod presją czasu

(ten artykuł jest częścią książki Bardziej niż Agile, która ukaże się w 2023 roku)

Pierwszy hackathon został zorganizowany w 1999 roku w ramach konferencji OpenBSD. Dzisiaj Hackathon to krótki, zwykle dwudniowy, maraton, w trakcie którego zespoły rywalizują przy tworzeniu różnych rozwiązań technicznych. Najczęściej hackathony dotyczą technologii programistycznych, choć można spotkać również takie, które skupiają się na tworzeniu prototypów urządzeń. Największy w Polsce, a według organizatorów również w Europie to Hackyeah, które miałem okazję być uczestnikiem w 2022 roku jako mentor.

Istnieją hackathony otwarte, w których mogą wziąć udział wszyscy chętni i hackathony zamknięte, organizowane w ramach wybranej korporacji (takie na przykład organizuje ING). Są hackathony zdalne i stacjonarne, te ostatnie w opinii większości moich rozmówców mają gigantyczną przewagę zaangażowania i atmosfery zabawy oraz rywalizacji. 

Hackathony to oprócz zabawy dla uczestników, świetne narzędzie budowania profesjonalnego wizerunku dla patronów fundujących nagrody oraz dla pracodawców osób startujących w nich. Przez duże organizacje te konkursy są również tanią metodą wytestowania różnych ryzykownych koncepcji. Wystarczy zgłosić swoją potrzebę na konkurs, zafundować nagrodę i liczyć na to, że zgłosi się kilka zespołów, które spróbują zmierzyć się z wyzwaniem.

Mały zespół

Typowy zespół na hackathonie ma trzy do siedmiu osób. Ważne jest, aby pokryć kompetencjami wszystkie krytyczne obszary. Na przykład w przypadku hackathonów programistycznych takie obszary to:

  • Przygotowanie prezentacji
  • Grafika i interfejs użytkownika
  • Technologie frontendowe
  • Technologie backendowe
  • Obsługa urządzeń, jeżeli takowe jest konieczne
  • Przygotowanie danych, na przykład w przypadku rozwiązań z zakresu sztucznej inteligencji
  • Koordynacja całości
  • Zdobywanie wiedzy od mentorów i jury

Jeżeli zespół się nie zna za dobrze, to może wypisać na tablicy, co każdy potrafi, w jaki sposób może pomóc w projekcie. 

Jeżeli masz luki kompetencyjne w zespole. Jasno to zapisz na samym początku projektu i przedyskutuj, jak je wypełnić. Naturalnym adresem będą mentorzy krążący po sali. Warto ich eksploatować maksymalnie, jak się da. 

Pewnie temu tematowi warto by poświęcić osobny rozdział, ale efektywność zdobywania wiedzy bardzo podnosi aktywne zadawanie pytań i głośne przyznawanie się do swojej ignorancji. Dopóki otoczenie nie wie, że potrzebujesz pomocy, nie będzie wiedziało, że powinno ci pomóc. Rzadko zdarza się, aby ktoś podszedł i zagadnął: “czy przypadkiem nie jesteś zagubiony i nie trzeba ci pomóc?”. Po prostu pytaj. W najgorszym przypadku ktoś powie, że nie wie, albo nie ma czasu.

Product owner

To, co różni zespoły zmierzające ku klęsce od tych z potencjałem na zwycięstwo był brak lub obecność kogoś, kto pilnowałby wizji produktu.

Product owner dba o to, aby zespół zajmował się właściwymi zadaniami i nie odpłynął zabawy z technologią. Pilnuje też czasu i reaguje, gdy trzeba ciąć zakres, bo inaczej zespół nie zdąży z demonstracją.

Rekrutuj dla motywacji

Ciężko przecenić wagę zgranego zespołu. Motywacja wewnętrzna jest krytyczna dla innowacyjność. Niemal wszyscy rozmówcy podkreślali jej wagę i wskazują na to dziesiątki badań.

Źródeł wewnętrznej motywacji jest kilka:

  • Nauka i poznawanie nieznanego – “Fajne jest wzięcie maczety i pójście przez dżunglę na przełaj”.
  • Atmosfera zabawy i rywalizacji – najlepiej zilustrują tą tezę cytaty uczestników hackathonów: “będzie co opowiadać wnukom”, “można poznać ciekawych ludzi”, “na hackathonach zawsze dają darmową pizzę, a człowiekowi najlepiej się pracuje na darmowej pizzy!”, “spędzić czas razem”, “ znamy i się lubimy, i mamy zajawkę na punkcie robienia hackathonów”.
  • Misyjność, poczucie wpływu na świat – misji poświęciłem następny akapit, ale podsumowując ludzie lubią odnajdywać głębszy sens w tym, co robią. Dotyczy to w większym stopniu aktywności, które nie są wynagradzane czynnikami zewnętrznymi takimi, jak płaca.

Jednak po wielu rozmowach doszedłem do wniosku, że nie istnieją proste i szybkie metody zbudowania motywacji wewnętrznej. Albo ktoś ją ma na starcie, albo jej nie zbuduje w sobie w trakcie hackathonu i tyle. Z tego między innymi powodu taką przewagę mają zespoły, które wcześniej się poznały i miały szansę współpracować.

Znajdź misję

Dużo przyjemniej buduje się system, który ma zredukować ilość śmieci w środowisku niż system oceny wiarygodności kredytowej klientów. Oba to duże wyzwanie intelektualne, ale ten pierwszy ma dodatkowo misję.

Rozpoznaj kryteria i preferencje jury

Niuanse zapisane są czasem między wierszami. Szczególnie na początku, na etapie analizy wymagań i wymyślania koncepcji, koniecznie zaangażuj członków jury. Gdy porozmawiasz z nimi, dowiesz się więcej niż to, co zostało zapisane w oficjalnych kryteriach konkursowych.

Warto zrozumieć też intencje, które stały za zleceniem danego tematu konkursowego. Skąd on się wziął? Z drugiej strony opłaca się poznać członków jury i zrozumieć ich osobiste preferencje. Czy prezentacja koncepcji jest ważniejsza, czy może proof of concept?

Wracam też do tezy, że pytając, można uzyskać dużo więcej wiedzy, niż pasywnie czekając na pomoc.

Spotkaj się w tym samym miejscu

 “Człowiek przejdzie kółko wokół laptopów, popatrzy w cudzy monitor i powie “hej, ja też miałem taki problem.” – potwierdził jeden z wielokrotnych zwycięzców hackathonów programistycznych.  “Praca zdalna obniża motywację do siedzenia po nocy.”

Moi rozmówcy podkreślali, że nawet gdy hackathon organizowany był w formule zdalnej to i tak zespół spotykał się w biurze lub w jednym mieszkaniu. 

Duża intensywność prac w połączeniu ze zmęczeniem i innowacyjnością rozwiązań i tak stanowią spore wyzwanie. Nie warto dokładać do tego ograniczeń komunikacyjnych.

Poza tym włącza się jeszcze efekt facylitacyjny, albo syndrom “jechania na jednym wózku”. Gdy widzę, jak inni dookoła intensywnie pracują, to samemu mi głupio odstawać. W projekcie Arystoteles Google’a dowiedziono, że był to jeden z najważniejszych czynników efektywności zespołów IT.

Cykl życia projektu

  1. Analiza wymagań konkursowych
  2. Burza mózgów na temat koncepcji – przez około godzinę do dwóch ludzie rzucają pomysły na projekt. “Trzeba wymyślić, coś czego nie ma i bardzo wielu ludzi boli ten brak”. Następnie trzeba zagłosować na najlepszy. Niektóre zespoły przygotowują prosty lean canvas, aby pokazać wszystkie aspekty pomysłu.
  3. Szukanie źródeł wiedzy – jedną z dużych przewag jest ustalenie, czy ktoś, czegoś podobnego już kiedyś nie zrobił. Znalezienie analogii drastycznie redukuje ryzyko projektu. Źródłem może być internet, na przykład serwisy o startupach, poprzednie hackathony, serwisy z fragmentami kodów. Szczególnym źródłem są też mentorzy krążący po sali, bo z reguły mają sporą wiedzę dziedzinową.
  4. Strukturalizacja pomysłu – od jednej do dwóch godzin trwa podzielenie wybranego pomysłu na części problemowe. Kryterium może być podział na eksperymenty do przeprowadzenia, albo główne zadania, albo różne technologie do użycia w rozwiązaniu. Efektem strukturalizacji jest przypisanie zadań do ludzi. Nie chodzi o to, aby mieć plan projektu do końca, tylko chodzi o to, aby zacząć jak najszybciej od najważniejszych rzeczy. Później ten plan będzie co godzinę ulegał zmianie, albo wręcz wyląduje w koszu, gdy pojawi się nowy pomysł. 
  5. Produkcja – w kolejnym akapicie bardziej szczegółowo opisują jak zorganizować ten etap. Należy tylko wspomnieć, że w każdej chwili projekt może zostać zatrzymany i postawiony na głowie. Szczególnie, gdy okaże się, że pomysł jest niewykonalny albo zabraknie czasu.
  6. Przygotowanie prezentacji – jedni mówią, że prezentacja powinna powstawać od samego początku hackathonu, inni, że od połowy prac, jeszcze inni, że poświęcają na nią ostatnie dwie godziny. Tak, czy siak to prezentacja w dużej mierze decyduje o zwycięstwie i nie można o niej zapomnieć.

Schematyczna prezentacja przebiegu projektu w trakcie hackathonu.

To co chciałem pokazać to, że pierwsza część projektu nie jest wcale poświęcana na prace. Niektórzy rozmówcy wręcz wskazywali, że nawet połowę czasu zajmuje wymyślanie i strukturalizacja koncepcji. Po drugie prace produkcyjne przebiegają równolegle w zmiennym rytmie. Jedne wątki toczą się w rytmie częstych wydań i krótkich zadań, bo taka jest ich natura. Inne są zupełnie nieprzewidywalne. Czasem przetwarzanie danych może zająć kwadrans, a czasem trzy godziny. To oznacza w konsekwencji, że niemożliwe jest zastosowanie wspólnych sprintów o stałej długości.

Co godzinę przegląd

Zespół co godzinę odkłada zadania dosłownie na pięć minut i omawia stan prac. Jak jest tablica kanban, to przestawia zadania na niej, jak jest Slack to wpisuje ustalenia, a jak nie ma nic, to po prostu dyskutuje. Główny problem przed zespołem to ten, czy zdąży przygotować rozwiązania na czas. I upewnienie się, że tak będzie jest głównym celem przeglądu projektu. “Czy z tym, co macie zrobić zdążycie do końca? Jeżeli nie, to dyskusja o redukcji zakresu i ewentualnie zmianie koncepcji.”.

Jeżeli zidentyfikowano problem techniczny, to dedykowani członkowie zespołu omawiają go, a reszta wraca do roboty. Jeden z rozmówców podrzucił następujący pomysł na podział każdej godziny produkcyjnej: około czterdziestu minut pracy w słuchawkach, wtedy sobie nie przeszkadzamy, a potem wszyscy je zdejmuje i trwa dalsza praca połączona z dyskusją.

Skup się na prezentacji

Daj sobie czas przed końcem hackathonu na doprowadzenie rozwiązania do poziomu, na którym można cokolwiek pokazać. Wielokrotnie zdarzało się, że zespoły najbardziej zaawansowane w obszarze technologicznym nie zdążały na koniec dopiąć rozwiązania i doprowadzić go do stanu, w którym można by cokolwiek zademonstrować.

“Kręcenie filmów jako elementu końcowej prezentacji mocno działa na korzyść.” – podkreślił mój rozmówca. – “Widzieliśmy dużo słabych prezentacji, na przykład gdy ludzie skupiają się na technikaliach (nikogo to nie interesuje), lub pokazują powerpointa z dziesięcioma tysiącami punktów (nie sprzedażowa), albo brakuje treści a jest tylko sama prezentacja, lub prezenter nie potrafi przekazać wartości pomysłu, niekiedy zespół nawet zrobi fajną prezentację, ale nie pokaże głównej idei i korzyści z pomysłu, zakładając, że jury domyśli się szczegółów (tzw. klątwa wiedzy).”

“Prezentacje trzeba robić od początku hackathonu. Nieważne, ile się zrobi przez 24h i tak cała robota sprowadza się do trzech minut prezentacji.”

“Ważne jest też, aby zrobić próby prezentacji.” Sama forma pokazania jest istotna w kontekście oceny rozwiązania przez jury.

Zarządzaj snem i frustracją

Hackathon to przede wszystkim zabawa. Bez dobrej atmosfery nic się nie będzie kleić.

“Gdy raz nie spałem, to prezentacja, którą wówczas przygotowałem była jedną z najgorszych. Trzeba spać w trakcie hackathonu.” “Na początku jest euforia, potem jest dołek, bo nie wychodzi, wszystko leży. Warto mieć świadomość istnienia takiego cyklu emocjonalnego.” “Nie spanie jest największym błędem.”

Warto z góry zaplanować, ile czasu członkowie zespołu poświęcą na sen i wyznaczyć szychty. Ktoś, kto przygotowuje prezentację powinien być wypoczęty na koniec, ktoś kto testuje koncepcję musi od razu być aktywny. Jednak każdy musi w pewnym momencie odpocząć. Im umysł jest bardziej zmęczony, to staje się mniej elastyczny i otwarty na nowe informacje. To prowadzi do konfliktów. 

Poniżej hackathon o drugiej w nocy, ja idę spać, oni walczą. 🙂

Żaden Scrum, Kanban!

“Scrum nie nadaje się, bo to jest za krótki projekt!” Bo nie ma czasu na sprinty – hackathon trwa od jednego dnia do dwóch zwykle. Sprint musiałby trwać dwie godziny. A organizowanie w jego trakcie planningów, review i retrospektyw stałoby się obciążającą biurokracją.

Bo prace trwają różnych rytmie – jeden obszar składa się z zadań po kwadrans, a w innym przez pół dnia opracowuje się koncepcję.

Bo nie ma inkrementu – jest tylko pomysł, lub kulawe rozwiązanie, które ma błędy, albo jedynie koncepcja w powerpoint. Jakość w hackathon schodzi na dalszy plan, celem jest zademonstrowanie fajnego prototypu.

Bo nie da się estymować – ludzie co najwyżej mówią “zdążę z tym, a z tym to chyba nie zdążę”. Jakakolwiek próba oszacowania wydajności zespołu i pracochłonności zadań mijałaby się ze zdrowym rozsądkiem. Po prostu trzeba zacząć robić i zobaczyć, jak nam wychodzi.

Natomiast pomaga pokazanie zadań na wspólnej tablicy. Ustalenie, które z nich są priorytetowe, bo mają największy wpływ na końcową ocenę rozwiązania, albo bo są najbardziej żmudne lub niepewne i wymagają eksperymentów. Pomaga też przydzielenie najbliższych zadań konkretnym członkom zespołu, aby maksymalnie wykorzystać ich produktywność.

Przywództwo zwinno – autokratyczne

Kiedy nagle ktoś z zespołu, nikomu nic nie mówiąc, wybiera się spać, potrzebna jest osoba z charyzmą, która utrzyma zespół w ryzach. Ten i wiele innych czynników występujących w takim projekcie powoduje, że samo przywództwo zwinne to za mało:

  • Gigantyczna presja czasu
  • Zmęczenie
  • Częste pivoty
  • Niska jakość
  • Braki wiedzy technicznej

Na druga rękę potrzebny jest przyjazny dyktator z wizją całości.

Upraszczając, mamy dwa style liderskie i dwie sytuacje z perspektywy menedżerskiej w trakcie hackathonu:

  1. Wszystko idzie zgodnie z planem – zespół wie, co ma robić, zadania zostały jasno podzielone, wizja rozwiązania jest wykonalna i atrakcyjna, atmosfera pozytywna i nikt stanął pod ścianą braku kompetencji. W takiej sytuacji działa servant leader. Przygląda się, pyta, czy może pomóc, usuwa przeszkody sprzed drogi projektu, upewnia się, że zespół jest zsynchronizowany, ale działa raczej w trybie coachingowym niż dyrektywnym. Na przykład “co sądzicie o takim pomyśle, czy coś jeszcze można tu poprawić?”, a nie “to nie zadziała, ty musisz jeszcze raz na to spojrzeć”.
  2. Projekt stoi na rozdrożu – koncepcja okazała się niewykonalna, albo istnieje więcej niż jedna koncepcja na stole i trzeba wybrać, zespołowi siadło zaangażowanie, ludzie są zmęczeni, pojawiły się konflikty personalne. Wtedy wkracza przyjazny dyktator. Wysłuchuje opinii i przekonuje zespół do jednej koncepcji. Rozprawia się z konfliktami w zespole. Wywiera presję na tych, którym wszystko opadło. Kluczem jest czas reakcji. Zespół musi mieć szybko nową wizję. Jeden z rozmówców wprost mówił o “leciutkiej dyktaturze”: “Jedna osoba powinna mieć wizję i wymuszać ją na zespole do końca. Autokrata, który ma mapę w głowie i pilnuje, aby nie odpłynąć w pomysłach.”

Tu należy tylko uważać, aby ręcznym sterowaniem projektem nie zabić zaangażowania zespołu. Idealnie, gdy zespół jednomyślnie zagłosuje za decyzję o porzuceniu starej koncepcji na rzecz nowej. Jeżeli jednak nie ma zgody, to lider przynajmniej powinien wyczerpująco uzasadnić swoją decyzję. A najlepiej jeżeli dysponuje takim autorytetem, że przekona wszystkich do swojej perspektywy.

Z reguły lider zespołu, ów zwinno – autokratyczny przywódca, jest też odpowiedzialny za komunikację z mentorami i jury oraz przygotowanie prezentacji. Zatem idealnie, gdy lider rozumie technologię, ale i biznes. Wie, jakie wymagania będą krytyczne z perspektywy oceny pomysłu, a jakie mimo technologicznej atrakcyjności, można odłożyć.

Wędrując jako mentor po sali Hackyeah, gdzie kilka tysięcy inżynierów tworzyło rozwiązania, rzucił mi się w oczy jeden brak. Nigdzie nie było białej tablicy. Ludzie przywozili komputery, wielkie monitory, słuchawki, maskotki jak na przykład średniowieczny szyszak, czy mandolina, ale nikt nie przywiózł tablicy, na której zespół mógłby notować, omawiać i rozbijać problemy na małe części. Uważam, że w trakcie fazy tworzenia koncepcji mogłaby szalenie pomóc skupić uwagę na właściwych zagadnieniach.

Przydatne narzędzia

Tablica Kanban – to może być po prostu tablica, jeżeli zespół siedzi w biurze lub narzędzie typu Trello, Jira.

Lista dyskusyjna – mimo, że ludzie zwykle siedzą koło siebie, to i tak używają oprogramowania do rozmowy, jak Slack, Messenger, Whatsapp, czy Discord. Przewaga polega na tym, że na zadane pytanie mogę odpowiedzieć za dwie minuty, gdy uporam się z jakimś problemem, więc mniej mnie to rozprasza. Poza tym na liście dyskusyjnej zostają zapiski poprzednich ustaleń i można do nich wrócić bez angażowania członków zespołu. Można tam też wrzucać linki, kawałki kodu, obrazki, próbki prezentacji itd. Wszystko w jednym miejscu.

Wspólne repozytorium – w przypadku hackathonów programistycznych dobrze jest trzymać kod w jednym miejscu (Github) i zarządzać wersjami, szczególnie gdy rozwiązanie ma wiele powiązanych modułów. Choć pojawiły się też głosy, że za mało czasu jest na stosowanie repozytorium. Kod po prostu łatwiej jest przesłać na czasie.

Burza mózgów – jedni stosują mapy myśli (np. XMind), inni affinity diagram (np. biała tablica lub kartka), jeszcze inni rysują makiety ekranów (np. Figma) i procesy (np. Draw.io). Ważne, aby dane narzędzie “przykleiło się” do zespołu i faktycznie było użyteczne w danym wyzwaniu.

Typowe błędy

Za duże rozwiązanie

Jeden z uczestników hackathonów napisał, że obowiązuje tu zasada Pi razy oko – wszystkie estymacje musisz pomnożyć razy trzy. To oznacza, że trzeba brać do realizacji koncepcje trzy razy mniejsze niż by się nam wydawało, że damy radę. Lepiej zrobić coś małego niż nie zrobić nic. Na Hackyeah 2022 około dziesięciu procent zespołów nie oddało nic. Absolutnie nic, nawet nie zrobiło prezentacji.

Wystarczy, że zrobisz cokolwiek a już przeskakujesz tych dziesięć procent rywali.

Dla ominięcia tej pułapki kluczowa jest rola product ownera.

Brak czasu na przygotowanie prezentację i jej przetestowanie

Czasem zespół tak mocno wkręci się w produkcję, że albo nie zdąży przemyśleć prezentacji, albo nie przygotuje się do niej.

Tu trzeba sprzedać rozwiązanie. Pierwszym etapem oceny jest zwykle głosowanie jury lub mentorów na podstawie prezentacji w PDF, filmików lub slajdów. A drugim demonstrowanie osobiste rozwiązania.

Juror ma tylko kilka minut na rzucenie okiem na projekt, bo projektów może być nawet sto. Więc prezentację trzeba tak przygotować, aby w kilkanaście sekund człowiek dał radę zrozumieć, o co chodzi, jaka jest wartość, jak to działa i na jakim etapie jest produkcja rozwiązania.

Szczególnie do drugiego etapu oceny trzeba się przygotować osobiście, bo to jest trochę taki teatr. Ważna jest nie tylko treść, ale i sposób przekazania zamysłu stojącego za rozwiązaniem.

Nie przedstawienie w prezentacji, co chodzi w rozwiązaniu

Klątwa wiedzy objawia się tym, że zespół tak dobrze jest zaznajomiony ze swoim rozwiązaniem, że zapomina opowiedzieć o nim jurorom. Zakłada, że wszystko jest oczywiste. Nie jest, szczególnie, jeżeli juror ma tylko dwie minuty na ocenę pojedynczego projektu.

Przy niektórych projektach musiałem zdrowo się nagłówkować, jaką koncepcję miał zespół. Jedyne, co wyczytałem z prezentacji, to że Ziemia jest zaśmiecona, ludziom się to nie podoba i zobaczyłem kilka klimatycznych zdjęć ze stocka.

Zaprezentowanie tylko slajdów bez rozwiązania

Wcześniej wspomniałem o konieczności przygotowania się do prezentowania przed jury. Na drugim końcu osi pułapek jest zrobienie samej prezentacji bez rozwiązania. Około dwudziestu procent projektów nie pokazało samego projektu. Mogliśmy tylko poczytać o tym, jak to zespół wyobraża sobie rozwiązanie w przyszłości i jakie mógłby mieć zamierzenia. To nie buduje wiarygodności.

Skupienie się na drobiazgach

Wiecie, jaka była najczęściej implementowana funkcjonalność aplikacji na Hackyeah? Ekran logowania! Coś, co nie zmienia wartości pomysłu, nie wyróżnia i jest całkowicie oczywiste. Inny przykład to formularz rejestracyjny. Po co do oceny koncepcji prototypu produkować stronę z rejestracją użytkownika? Wystarczy przecież jeden testowy użytkownik do zademonstrowania rozwiązania. Jeszcze brakuje tylko funkcji “przypomnij hasło”.

PMBOK 6 czy PMBOK 7 na egzamin PMP a może oba

PMBOK 6 czy PMBOK 7 na egzamin PMP a może oba

Od dwa lat PMI postawił kandydatów do PMP w niezręcznej sytuacji. Opublikowano PMBOK Guide 7 (tu możesz przeczytać jego recenzję), który został tak naprawdę napisany od nowa. Jednocześnie nie anulowano oficjalnie poprzedniej wersji PMBOK 6. Wersja 7 zmieniła się kompletnie, największą zmianą były usunięcie procesów projektowych i ITTO, czy samego nadzienia wersji 6.

Natomiast na egzaminie obowiązywała wiedza z obu książek. Intensywnie przeglądałem witrynę pmi.org, zapytywałem na grupach dyskusyjnych PMI i nigdzie nie mogłem dostać oficjalnej odpowiedzi. PMI na swojej stronie sprytnie informuje do dzisiaj, że obowiązuje PMBOK Guide ale bez podania wersji (sami zobaczcie). Natomiast przedstawiciele firm szkoleniowych mówili, że najlepiej uczyć się z obu. Mocno niekomfortowa sytuacja zważywszy, że wersja 6 ma ponad 600 stron, wersja 7 – ok. 400 stron, załącznik agile ponad 300 stron. Takim stosem książek można wykoleić tramwaj.

Jednak sytuacja zmieniła się na lepsze. W październiku wyszedł Proces Groups Practice Guide (tu można go pobrać), który ma zastąpić PMBOK 6. Zawiera on wszystkie procesy z PMBOK 6 z inputami, outputami i technikami, ale usunięto opisy technik oraz wstęp. Z tego powodu książka z 600 stron schudła do 390 stron. Ewidentnie skopiowano rysunki i spis treści z PMBOK 6, tylko pousuwano niektóre sekcje.

Na dowód załączam fragment opisu jednego z procesów z tej książki.

Na stronie na temat nowości w standardach PMI informuje co prawda, że kandydaci do CAPM nadal mogą uznać PMBOK 6 za użyteczny, ale jego koniec jest już bliski.

W pliku z FAQ dotyczącymi PMBOK 6 napisano: It is important to remember that the PMP® exam is not based on the PMBOK® Guide.

Pamiętajcie, że „na egzaminie PMP może znaleźć się dowolne pytanie z dziedziny zarządzania projektami, o ile można znaleźć do niego odniesienie w conajmniej dwóch książkach z tego obszaru”, czyli np. PMBOK 6 i 7 :D.

Także ten tego… powodzenia na egzaminie robaczki! 🙂

 

 

Trendy w zarządzaniu projektami

Trendy w zarządzaniu projektami

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ć.

 

 

 

Niepewność, czy pracochłonność

Niepewność, czy pracochłonność

Mam wrażenie, że jedną z najważniejszych strategicznych kompetencji jest umiejętność rozróżnienia tego, co jest tylko pracochłonne od tego, co totalnie niepewne. Korzyść ucieczka ze ślepej uliczki zanim zmarnujemy w niej lata naszego życia i furmanki pieniędzy.

Od kilku miesięcy siedzę w wolnym czasie nad serwisem, który wspiera tworzenie map procesów (https://dotch.art). Początkowo nie miałem pojęcia jak rysować wektorowo na stronie HTML, jak animować obiekty, jak wyliczać kąty krzywych Beziera, czy wreszcie jak stworzyć plik XML, który będzie rozumiany przez Draw.io, czy Cawemo. Ale… to wszystko nie miało znaczenia. Wystarczy skończona liczba godzin, dostęp do stackoverflow, czy innej dokumentacji i wcześniej, czy później te wyzwania technologiczne staną się banalne. To nie było niepewne tylko pracochłonne.

Najważniejszym problemem i główną hipotezą było i nadal jest to, czy serwis Dot Chart dostarcza jakąkolwiek wartość użytkownikom. Czy ludzie będą do niego wracać, polecać znajomym i wreszcie płacić za korzystanie? To jest właśnie niepewność. Wątpliwość jest nie bez podstaw, bowiem jeden z moich znajomych o olbrzymim doświadczeniu biznesowym wprost zadał pytanie: „Marcin, a po co ty to robisz? Nie lepiej zająć się czymś sensownym?”.

Stwórzmy w głowie tabelę o dwóch wymiarach: niepewność i pracochłonność. Z takiej tabeli 2×2 możemy uzyskać cztery podstawowe sytuacje. Oczywiście jest to olbrzymie uproszczenie, które wprowadzam na potrzeby tego wpisu. Projekt, zadanie, inwestycja jest:

  1. Tani i pewny
  2. Tani i niepewny
  3. Pracochłonny i pewny
  4. Pracochłonny i niepewny

W pierwszym przypadku po prostu warto coś zrobić. Przykładowo bank posiadający tysiące klientów może mieć pewność, że 2% klientów skusi się na nową usługę, co daje bardzo przewidywalny wynik. Albo producent gry mobilnej z 100 tysiącami aktywnych graczy wie, że dodanie nowej mikrotransakcji sprowokuje do konwersji 0.5% graczy. W takim projekcie po prostu trzeba coś policzyć i zrobić.

W drugim przypadku na horyzoncie jawi się okazja. To, czy zaklasyfikujemy ją jako niepewną lub pewną zależy od subiektywnego odbioru sytuacji. Jednak mam wrażenie, że biznesmeni mają tendencję do przeceniania swojej wiedzy i przesadnego kwalifikowania rzeczy wątpliwych jako pewne. W takiej sytuacji niska pracochłonność może uzasadniać podjęcie ryzyka i po prostu zrobienie projektu. Trochę tak jest z pewnym systemem społecznościowym, przy którym dzisiaj pomagam. Postawienie go zajmuje mojemu koledze godzinę, a nie wiemy, czy uda się przekierować darmowy ruch użytkowników. Jeżeli się uda, to jesteśmy bogaci, a jak nie to zmarnowaliśmy parę godzin. Co w takiej sytuacji? Po prostu to zrobić i zobaczyć, jak wyjdzie. Minusem jest to, że według analiz trzeba poczekać 3-6 miesięcy na zebranie danych. A ponieważ koszt jest tak niski, to można dodatkowo jeszcze odpalić 10 takich systemów na różne tematy, aby zdywersyfikować wyniki.

Albo inny przykład. Jak ustalić, czy usługi weterynaryjne online mogą być rentowne? Dwa dni na postawienie strony i linka do płatności, tydzień na kampanię, współpraca z weterynarzem i tadam! Mamy realne dane o elastyczności cenowej, koszyku, konwersji itd.

Trzecia z tych sytuacji to obszar tradycyjnych projektów kaskadowych lub zwinnych. Mamy coś dużego do zrobienia, znamy rezultat oraz dysponujemy w zespole kimś, kto już to robił, to po prostu wdrażamy, konstruujemy, produkujemy. Jakbym miał wdrożyć system CRM w firmie, która ma kilkadziesiąt tysięcy transakcji miesięcznie, to pewnie byłbym w takiej sytuacji.

Wreszcie czwarty obszar jest najgorszy. Duża niepewność i spory koszt, aby zweryfikować ją, aby zdobyć wiedzę. Tutaj najbardziej moim zdaniem przydać się może podejście eksploracyjne, o którym już wielokrotnie pisałem i któremu poświęcam wolny czas w tym roku. Problem trzeba pociąć na małe części, zebrać zaangażowany zespół unikalnych fachowców, zaakceptować brak kontroli nad wydatkami, by krok za kroczkiem przekonywać się, czy inwestycja miała sens. W ten sposób rozwijane są przez lata startupy, nowe urządzenia, czy opanowywane nowe technologie. Tu ważna jest wiara oraz dzielenie tej niepewnej drogi na małe odcinki i ich ciągła racjonalizacja.

Problem z niepewnością komplikuje jeszcze jedna rzecz. Brakuje mi dobrego terminu, więc nazwę to niepewnością ukrytą pod płaszczem przekonania o swoim geniuszu. Niepewność zaskakuje. To wynika z jej definicji. Jednak to, że może zaskakiwać jest regularnie ignorowane przez biznesmenów. Często widzę arkusze kalkulacyjne wyliczające sprzedaż nowej usługi na miliony, a po wdrożeniu okazuje się, że nikt tego nie chce.

Często na starcie nie wiemy, że coś jest niepewne. Ukryte są konflikty techniczne, których nie da się obejść, ukryte jest niska jakość rozwiązania, której nie ma sposoby podnieść, ukryty jest brak popytu klientów na usługę, ukryte są wysokie koszty pozyskania klienta itd. Niepewność ukryta ujawni się w trakcie, bo ona tam siedzi, ale wprowadza nas na starcie w błąd. Zamiast sądzić, że mamy do czynienia z projektem ryzykownym, to wydaje się nam, że może i jest pracochłonny, ale przewidywalny. Da się go zatem zbudować krok po kroczku i na pewno osiągniemy sukces.  A jak jeszcze dopiszemy do tego projektu termin końca i całkowity koszt, to wszystko stanie się bezpieczne. Co może pójść nie tak? Zupełnie jak w przypadku nowego bloku elektrowni w Ostrołęce. Wszystko!

 

montecarlo

Szacowanie trendów

https://docs.google.com/spreadsheets/d/19WOda89SDjHzeXIMZjRljgMzslCokRKqaBTg-e71p0U/edit?usp=sharing

Porównanie zespołów sprzedażowych

https://docs.google.com/spreadsheets/d/1Vtn-cWqzr8_cMOWNHqc_ClZpoNTpSrIDZEbM6W8jz_4/edit#gid=0

Liczenie korelacji

https://docs.google.com/spreadsheets/d/1sIf4pfFKEv7kqWVfQv_66u2t0-9i63wsPWw0V7c8LdU/edit#gid=0

Czyszczenie danych

https://docs.google.com/spreadsheets/d/154unnW_Y8OX-2vkzb63p7_aiLwp3A8mq3jGk9fzAxo4/edit?usp=sharing

Model dla reklamacji

https://docs.google.com/spreadsheets/d/1ksFUeJnjwmHt4XTLlf1IX8Hu4i0BF6qp0MgtPByDwoo/edit?usp=sharing

Funkcje Dot Chart

Funkcje Dot Chart

System Dot Chart oferuje wiele funkcji, których cel jest jeden. Przyśpieszyć rysowanie mapy procesu.

Potrzebujesz szybko narysować przepływ pracy? Stwórz diagram dot chart. Możesz:

  • Dodawać role w procesie
  • Dodawać zadania w procesie
  • Wstawiać „kółka”, które pokażą, kto zajmuje się, czym
  • Połączyć „kółka” strzałkami, aby uwidocznić logikę
  • Dodawać komentarze do poszczególnych „kółek”
  • Możesz to wszystko edytować, zmieniać i przestawiać
  • Możesz tworzyć mapę w grupie w formule zdalnej. System na bieżąco będzie aktualizował stan mapy.
  • Jeżeli mapa ma służyć do optymalizacji procesu, możemy zapisać problemy, pomysły na usprawnienia i w miarę ich realizacji zmieniać ich status.

Możesz automatycznie skonwertować dot chart na mapę w formacie swimlane. Wystarczy nacisnąć jeden przycisk. Mapa wyświetla start, koniec, zdania, tory pływackie, bramki. Możesz następnie wyeksportować mapę do pliku graficznego, PDF, XPDL.

Ponowna edycja dot chart powoduje automatyczną aktualizację swimlane.

Kolejna możliwość to wygenerowanie tabeli RACI. Możemy przypisać „kółka” na dot chart do poszczególnych zakresów odpowiedzialności. Zostanie to pokazane za pomocą kolorów. Następnie wystarczy nacisnąć przycisk, aby automatycznie wygenerować tabelę RACI.

Następnie możemy zapisać ją w postaci obrazka lub PDF.

Możemy wreszcie zacząć rysowanie mapy od stworzenia tablicy z rolami i ich zadaniami w procesie, a dopiero później zrobienie. Można sobie wyobrazić, że najpierw uczestnicy procesu samodzielnie wypełniają tabelę ról, a potem analityk wspólnie z nimi tworzy dot chart, który na koniec zapisuje w postaci BPMN.

Wejdź na https://dotch.art, aby zacząć korzystać z systemu.

Zapisz się na nasz newsletter

Zapisz się na nasz newsletter

Twój e-mail został zapisany