utworzone przez Marcin Żmigrodzki
Udostępniamy wam za darmo prototyp najnowszego symulatora o nazwie Trucks. Symulator uczy, jak zachowują się losowe zjawiska. Zadaniem gracza jest obliczyć, jaki mają rozkład te zjawiska i podjąć decyzję biznesową na tej podstawie.
Gra może pokazywać, w jaki sposób stosować statystykę opisową, jak identyfikować naturę rozkładu, jak analizować zależności między zmiennymi. W końcu można w praktyce stosować metodę Monte Carlo.
Symulowana sytuacja przedstawia niewielką firmę transportową, która realizuje zlecenia za pomocą kilku ciężarówek. Auta mają różny koszt, różną pojemność, różną awaryjność, różne czasy i koszty usuwania awarii. Zmienny jest również popyt klientów w aspekcie ilości zamówień, ich wielkości, wymaganego czasu dowiezienia, odległości.
W symulatorze nie ma samych narzędzi do analizy statystycznej, ponieważ zakładamy, że to będzie w trakcie szkolenia prowadzone w arkuszu kalkulacyjnym lub programie do statystyki, jak Minitab.
Symulator dostępny jest pod adresem: https://sim.octigo.pl/. Aby skorzystać z niego, trzeba wpisać swój pseudonim oraz numer pokoju – 1.
utworzone przez Marcin Żmigrodzki
Co jakiś czas napotykam podobną myśl, choć różnie nazwaną. Sposób podejścia do wymyślania, produkcji i wdrażania innowacji. Na własne potrzeby nazwałem to podejściem eksploracyjnym. Od kilku lat w różnych blokach powracała idea realizacji projektów z perspektywy weryfikacji hipotez. Idea mi osobiście spodobała się na tyle, że namówiłem wydawnictwo Helion do przetłumaczenia książki, która o tym opowiadała. Mowa o Testowaniu pomysłów biznesowych Blanda.
Kiedy jednak Gartner umieścił na swoim raporcie hype cycle koncepcję hipothesis-driven development (HDD), uznałem, że coś się dzieje. Trochę informacji o HDD można znaleźć tutaj. Gdy poczytałem sobie o HDD, uświadomiłem sobie, że idea jest podobna do pewnych aspektów lean startup. Stawianie hipotez korzyści pojawia się również w SAFe. Jest to od dawna charakterystyczne dla projektów Six Sigma na poziomie Black Belt, gdzie częściej stosuje się wnioskowanie statystyczne oparte także na hipotezach H0 i H1. Delikatne nawiązanie do takiego podejścia znajdziemy też w Disciplined Agile, gdzie jeden z cykli życia projektów nazywa się Exploratory (jego schemat macie poniżej w tekście). Delikatne, bo DAD nie mówi wiele więcej o tym podejściu, nie definiuje technik, nie stosuje nawet terminu – hipoteza. W końcu, albo przede wszystkim, stawianie hipotez jest od około stu lat charakterystyczne dla nauki. Dzisiaj trudno wyobrazić sobie badanie połączone z eksperymentem lub obserwacją, w którym nie stawiano by hipotez, nie budowano by z nich modelu i nie weryfikowano by całości.
Z ciekawszych technik warto wspomnieć, że HDD zakłada specyficzny sposób definiowania wymagań zamiast perspektywy roli użytkownika, jego wymagań funkcjonalnych i spodziewanej korzyści:
- We Believe
- Will Result
- We Will Have Confidence To Proceed When
Przykładowo:
- Wierzymy, że – Dodanie powiadomień w grze mobilnej, które wyświetlają się, gdy gracz nie gra w nią
- Da efekt – wzrostu retencji i liczby sesji w grze
- Będziemy pewni, że można potwierdzić hipotezę, gdy – retencja jednodniowa wzrośnie o 5 punktów procentowych a liczba sesji o 10 punktów procentowych liczonych dla kolejnych 10 dni.
Wiele badań pokazuje, że coraz mniej można ufać ocenom eksperckim, czyli pochodzącym z głowy kogoś, kto uważa siebie za mądrego człowieka, czyli często nas samych. Rzeczywistość jest coraz bardziej złożona i dynamiczna, a poczucie pewności siebie bywa coraz bardziej zwodnicze w takich czasach.
Podejścia agile i waterfall mają wiele elementów różnych, ale czymś, co je łączy jest wyjście od wizji przyszłego produktu i dekompozycja jej na mniejsze części reprezentujące funkcje, bądź elementy konstrukcyjne. Zbiór podejść, które zamierzam wrzucić do jednego worka o nazwie eksploracyjne wychodzi natomiast od listy niepewności. Następnie sortuje je albo według skali niewiedzy albo według wartości, którą da wypełnienie ignorancji wiedzą. A następnie z weryfikacji hipotez wynika zakres funkcjonalny.
Podam przykład dla lepszej ilustracji. Załóżmy, że uruchamiamy usługę pisania CV przez internet. Algorytmy AI będą podpowiadały najlepsze sformułowania na bazie tysięcy CV wyciągniętych z Linkedin. W podejściu roboczo nazwanym eksploracyjnym będziemy najpierw zastanawiali się, jakie są kluczowe wskaźniki decydujące o sukcesie serwisu. Załóżmy, że głębokość wizyty, czyli liczba odwiedzonych stron, jest krytyczne, bo użytkownicy, którzy przejrzą więcej niż 5 stron mają większą skłonność do zostawiania swoich danych. Zatem wymyślając funkcję np. generowania seksji w CV dotyczącej edukacji postawimy hipotezę, że wprowadzenie danej funkcji zwiększy głębokość wizyty średnio o 2 strony. Mając tak zdefiniowane propozycje funkcji, można je posortować według jednego z dwóch kryteriów:
- Eliminacji niewiedzy
- Wartości biznesowej
W podejściu zwinnym lub kaskadowym wyjdziemy od wizji końcowego rozwiązania i podzielimy ją na funkcje do implementacji. W obu tych podejściach można wykorzystać wiedzę jednego guru, który całe rozwiązanie ma w głowie lub zorganizować warsztaty z zespołem albo klientami i wykorzystać wiedzę wielu osób. Tak czy siak korzystamy z jakościowych opinii ekspertów opartych na ich poczuciu pewności siebie. W podejściu zwinnym również sortuje się funkcje, ale według ogólnie rozumianej wartości dla product ownera, czyli jego subiektywnej oceny.
Drugą charakterystyczną cechą, obok sposobu planowania zakresu, w projektach eksploracyjnych jest zwinny cykl życia. Dzieli się je na sprinty, ale z jedną różnicą. Poszczególne sprinty mają różną długość, zależną od zdolności do implementacji zmian i weryfikacji hipotez. Czasem po napisaniu funkcji trzeba długo poczekać, aż uzbierają się dane. Przykładowo zmiana nawigacji po gierce mobilnej może zająć dzień, ale stwierdzenie, czy graczom to się bardzo podoba w sytuacji, gdy jeszcze mało ludzi pobiera daną grę, może zająć dwa tygodnie.
Podejście eksploracyjne, z tego co widzę ma też swoje organiczenia. Pierwsze dwa, które dostrzegam już teraz to:
- Koszt nanoszenia zmian na tyle niski, że uzasadniony wartością biznesową lub korzyścią z redukcji niepewności.
- Zdolność do zebrania danych, które zweryfikują hipotezę. Wyobraźmy sobie, że budujemy dom eksploracyjnie. Pomińmy na chwilę kwestie bezpieczeństwa, prawa i kosztów przebudowy. Gdyby postawić hipotezę, że mieszkania w budowanym bloku będą się lepiej sprzedawały, gdy strop będzie wyższy o 10 cm, to mielibyśmy szansę jej weryfikacji dopiero po wielu tygodniach, gdy potencjalni klienci dadzą nam wystarczający feedback na podstawie lektury reklam, witryny internetowej osiedla i rozmów. Zakładam, że nie budowalibyśmy domu na próbę, tylko umieścili informację o wysokości stropu w katalogu. Czas zbierania danych byłby bardzo długi, a jakość responsu być może niska. Przez te kilka tygodni budowa albo by stała, albo szła by naprzód z ryzykiem, że trzeba będzie zmieniać wysokość stropu. 🙂
Podsumowując, wydaje mi się, że rosnąca dynamika zmian oraz niepewność podejmowanych decyzji zachęci firmy do stosowania podejścia eksploracyjnego opartego na weryfikacji hipotez. To oznacza, że w niedługim czasie ktoś wypromuje ideę podejścia eksploracyjnego lub inaczej zwąc podejścia R&D (badawczo-rozwojowe).
utworzone przez Marcin Żmigrodzki
Rok temu napisałem dość ironiczny wpis na temat roboczej wersji PMBOK Guide 7. Możecie go przeczytać tutaj. Teraz do moich rąk trafiła wersja oficjalna i od razu muszę nieco odszczekać moje niektóre zjadliwe komentarze. Podsumowując, PMBOK 7 opowiada o różnych technikach, natomiast PMBOK 6 je głównie wyliczał. Omówię teraz książkę, która jest podstawą najpopularniejszej na świecie certyfikacji krok po kroku.
PMBOK Guide 7 w wersji pdf ma 370 stron. Można ją pobrać z witryny pmi.org. Dla tych, którzy zapłacili składkę jest to darmowe, dla pozostałych kosztuje 78$ na Amazon. To niemal dwa razy mniej stron niż wersja poprzednia i jednocześnie dwa razy drożej niż wersja poprzednia. Narazie wyszedł tylko po angielsku, ale szykowane są przekłady w innych językach, w tym PMI Polska ogłosił, że również w naszym języku. Książka narazie nie jest podstawą do egzaminu PMP, jest nią wciąż wersja 6. Z resztą sami możecie się o tym przekonać, czytając listę pozycji na stronach pmi.org. Zwykle około pół roku po wydaniu książki zmieniany był egzamin PMP, więc możemy się spodziewać, że zdarzy się to na początku roku 2022.
Co znajdziemy w środku? Książka została podzielona na dwie części, w skrócie: standard i przewodnik. Przeskoczę wstęp, bo niewiele wnosi poza deklaracją, gdzie zostały przetransferowane treści z PMBOK 6. Tak więc, gdy wygaśnie PMBOK 6, jego treści będą w PMBOK 7 oraz w portalu prowadzonym przez PMI: Standards+. Przy okazji dostęp do tego portalu jest płatny, chyba, że jest się członkiem PMI i opłaca się składki. Warto pamietać o tym, że treści potrzebne na egzamin PMP przewędrowują do tego portalu, bo łatwo jest coś pominąć, jeżeli nie śledzi się na bieżąco jego zawartości.
Część PMBOK Guide 7 nazwana Standardem jest relatywnie krótka (około 60 stron) i to nad nią pastwiłem się rok temu w innym wpisie na blogu. Z jednej strony dość łatwo ją opanować, bo mówi o wartościach etycznych w pracy kierownika projektu, a z drugiej strony może być pułapką na egzaminie PMP, bo pytania prawie na pewno będą sytuacyjne. W stylu „Jeden z członków zespołu pochodzący z dalekiego wschodu po raz kolejny spędził dzień nie realizując żadnego postępu prac. Ewidentnie zadanie przekracza jego możliwości techniczne. Mimo, że już kilka razy prosiłeś go, aby zgłaszał się po pomoc bardziej doświadczonych kolegów, to ukrywa swoją niekompetencję. Co zrobisz?„. Podchwytliwe, prawda 🙂
Standard zawiera przede wszystkim definicje tego, czym jest projekt, organizacja, portfel itd., co to znaczy nadzorować i koordynować, z jakich wymiarów składa się środowisko projektu, oraz jakie wartości ma wyznawać kierownik projektu. W skrócie podpowiem: uczciwość, szacunek, sprawiedliwość, odpowiedzialność. Są one skorelowane z 12 zasadami. I następnie na około 30 stronach opisane jest, co należy rozumieć pod tymi 12 zasadami. Przykładowo co to znaczy stworzyć kooperacyjne środowisko pracy dla zespołu (tłumaczenie jest moje własne, więc przepraszam za brak stylu), albo na czym polega koncentracja na wartości. Moja osobista opinia jest taka, że nadal nie widzę wielkiej wartości w tej części, choć wyobrażam sobie te dziesiątki pytań sytuacyjnych o wspomniane 12 zasad.
Druga część nazwana Przewodnikiem (Guide) jest dłuższa, bo ma 200 stron. Pisałem na początku, że muszę odszczekać moje ironiczne uwagi sprzed roku. Tamten PMBK Guide nie zawierał rozdziału Guide, stąd moja niewiedza o nim. Faktycznie druga część jest merytoryczna i ma intencję zastąpienia PMBOK 6. Zamiast 10 obszarów wiedzy i 5 grup procesów mamy 8 dziedzin: stakeholders, team, development approach, planning, project work, delivery, measurement, uncertainty. W ramach każdej domeny opisane są dobre praktyki i techniki, ale nie ma już procesów z ich wejściami i wyjściami.
Z nowych technik i zagadnień sporo miejsca poświęcono motywacji i różnym konkurencyjnym koncepcjom na jej temat. Szczególny nacisk położony jest na motywację wewnętrzną, ale wiadomo – agile. Szkoda tylko, że jako autora przywołano Daniela Pinka podczas, gdy on tylko popularyzował tą ideę a nie ją badał. Prawdziwych twórców tej koncepcji, jak Deci i Ryan, pominięto Pojawia się odniesienie do przywództwa sytuacyjnego II, OSCAR, ADKAR, Kottera, Cynefin. Nadal niestety pojawia się cykl życia grupy Tuckmana, szkoda, że w gronie autorów zabrakło krytyków tego podejścia, ale pojawiła się alternatywa dla Tuckmana, czyli model Drexlera/Sibbeta. Wprowadzono nowy typ kontraktu IDIQ – indefinite delivery, indefinite quantity.
Ubyło natomiast mnóstwo technik, które były wymieniane w PMBOK Guide 6. Prawdopodobnie oczekuje się, że kandydat do PMP zapozna się z nimi na PMI Standards+, o czym już pisałem wcześniej.
Jestem pozytywnie zaskoczony, jak w drugiej części książki zgrabnie omówiono aspekty zwinne tak, aby nawet kierownik projektów ze świata tradycyjnego nie poczuł się nimi zaszczuty. Dużo też opowiada się o różnych cyklach życia projektu, co jest fajne dla ludzi nie pracujących w agile. Obok macie przykład objaśnień.
Na plus należy zaliczyć też język objaśnień bardziej podręcznikowy niż leksykonowy. To znaczy, że PMBOK 7 opowiada o różnych technikach, natomiast PMBOK 6 je głównie wyliczał. On nie stał się klasycznym podręcznikiem, ale jest bardziej przystępny niż poprzednia wersja.
Fajnie też, że pojawił się rozdział o wdrażaniu standardu pod nazwą Tailoring. Tego naprawdę brakowało. Konkurencyjny SAFe od razu próbował wypełnić tą lukę, oferując 4 sposoby jego wdrożenia. PMBOK Guide od kilkudziesięciu lat nie proponował w tym obszarze zbyt wiele.
Minusem natomiast jest to, że pełno technik wyleciało z siódemki w porównaniu do szóstki. Domyślam się, że bardziej szczegółowe omówienie zabiera więcej stron, więc trzeba było iść na kompromisy.
Czego brakuje? Nadal pominięty jest aspekt negocjowania kontraktu na projekt, szczególnie z perspektywy sprzedawcy. Uczeniu się w projektach poświęcono jedną stronę, kiedy to w wielu projektach brak uczenia się i radzenie sobie z niepewnością jest najbardziej krytycznym czynnikiem. Zupełnie usunięto cały rozdział o jakości. Nie ma nic za wyjątkiem cost of quality. Mocno to zaskakuje, bo w wielu projektach to jakość jest głównym driverem, np. six sigma, albo projektach produkcyjnych. Tak samo wyleciały techniki zarządzania ryzykiem. Czyli generalnie pozbyto się z książki wszelkich technik ilościowych za wyjątkiem Earned Value. Statystyka w projektach nie jest używana. Szkoda!
Na końcu części o nazwie Przewodnik znajduje się wyliczanka technik projektowych. Bardzo pobieżna i przypominająca praktyki z PMBOK 6. Dobrze zilustruje ją załączony obrazek pokazując, gdzie zwykle stosuje się, które techniki. Czuję mocny niedosyt po lekturze podrozdziału z technikami, bo zostały opisane bardzo lakonicznie. Nie da się z niego nauczyć do egzaminu PMP. Raczej ma on formię syllabusa.
Podsumowując, nie wiem, czy nowy egzamin PMP będzie łatwiejszy, czy trudniejszy. Nie będzie pewnie w nim procesów, inputów i outputów. Będzie jeszcze więcej technik i dobrych praktyk. Będzie też pewnie więcej pytań o postawy lub zasady.
Plusy. Część dotycząca ogólnej wiedzy o zarządzaniu projektami jest opisana bardziej przystępnie. Pojawił się ciekawy rozdział o wdrażaniu standardów projektowych.
Minusy. Brak technik ilościowych. Bardzo pobieżne wymienienie technik i narzędzi. Niezrozumiały dla mnie rozdział z 12 zasadami.
Wszystkie obrazki w tym tekście pochodzą z PMBOK Guide 7.
utworzone przez Marcin Żmigrodzki
Poszukuję chętnych do recenzowania i komentowania mojej najnowszej książki, która właśnie zaczyna się pisać.
Ponad dwa lata temu rzuciłem hasło i zaprosiłem do współpracy chętnych z Linkedin przy pisaniu książki W tym szaleństwie jest metoda. Obawiałem się tej pozycji, bo forma, którą wybrałem, była nietypowa. Była to powieść. Dzięki wsparciu kilku osób, które wyraziły chęć współpracy powstała książka dużo lepsza, niż gdybym sam się z nią mierzył. Jeszcze raz im dziękuję za to. Książka na https://lnkd.in/d25cUuh otrzymuje całkiem niezłe oceny, bo średnio 8.4 / 10, więc chyba nieźle nam to wyszło. (więcej…)
