utworzone przez Marcin Żmigrodzki
W tekście sprzed kilku tygodniu postawiłem tezę, że krystalizuje się nowa metodyka (tutaj ten artykuł) – nazywam ją eksploracyjną. Jednym z kluczowych jej komponentów jest stawianie hipotez i na tej podstawie planowanie zakresu.
Aby samemu przetestować to podejście w mojej grze mobilnej postawiłem hipotezę, że implementacja notyfikacji typu push podniesie retencję o 5 punktów procentowych. Retencja w grze była moim głównym problemem i poradzenie sobie z nią determinowało, czy jest sens dalej grę rozwijać, czy też projekt trzeba zamrozić. Retencja jednodniowa w okresie porównawczym wynosiła 15%, co jest wynikiem wyjątkowo słabym. Moim celem było podniesienie jej do poziomu przynajmniej 40% w długofalowej perspektywie. Ale teraz postawiłem hipotezę, że za pomocą notyfikacji push da się podnieść do poziomu 20%.
To jest cytat z tamtego artykułu:
- 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.
Zabrałem się od roboty. Kilka releasów zawierajacych kolejne notyfikacje odpalane w różnych okresach, po drodze usunięcie serii błędów destabilizujących grę. Okazało się też, że aby notyfikacje miały sens dla gracza, gra musi działać w tle. To znaczy, że mimo iż gracz nie gra, to w grze jest mierzony upływ czasu tylko 200 razy wolniej. Po dodaniu tych rzeczy z dumą donoszę, że cel 25% został osiągnięty z górką. Retencja jednodniowa za ostatnie 10 dni to 25,3%. Zakres okazał się tylko nieco większy, bo trzeba było usuwać błędy i dodać granie w tle (łącznie ok. 2 dni pracy dodatkowo).
Czego to uczy? Po pierwsze odkryłem jaka jest wartość notyfikacji push. Jestem w trakcie odkrywania, że gracze mają chyba nieco inny styl grania niż zakładałem. Poza tym dzięki postawieniu hipotezy na temat krytycznego parametru mogłem się skupić na właściwej funkcjonalności. Twórca gry pomysłów na rozwój ma tysiące. Coraz wyraźniej widzę, że sztuką jest odgadnąć, czego chcą gracze. Ostatni wniosek jest taki, że zmienność obserwacji jest duża (od retencji 0% to ponad 60%), bo mam małą dzienną próbę graczy. Im większa dzienna próba, to tym bardziej wykres się wyrównuje. Żeby upewnić się, że zmiana nastąpiła, policzyłem średnią kroczącą. Zmiana jest znaczna, więc nie czułem potrzeby robienia testów statystycznych, ale zgodnie z metodyką powinienem.
Drugi wskaźnik w hipotezie mówił o liczbie sesji i okazuje się, że był źle dobrany. Dlaczego? Bo za liczbę sesji w dużej mierze odpowiada, to czy AppStore będzie promował grę, czy nie. Częściowo zależy to od atrakcyjności gry, ale częściowo od magicznych czynników, na które nie mam wpływu. Dla porządku jednak pokazują też liczbę sesji. Zmiana nastąpiła nawet powyżej oczekiwań w okresie porównawczym było 10,5 sesji dziennie, w okresie ostatnich 10 dni 24,9 sesji dziennie.
Kolejna hipoteza, która sobie stawiam to, że:
- Wierzymy, że – Dodanie modułu produkcji fabryk do gry mobilnej z funkcją produkowania w tle i notyfikacji push
- 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 do 30% liczonych dla kolejnych 10 dni.
utworzone przez Marcin Żmigrodzki
Miesiąc temu zaprosiłem do współpracy przy pisaniu nowej książki w dość nietypowej formule. Po pierwsze książka ma mieć formę kryminału, który przy okazji opowiadania historii wprowadza w tajniki zwinnego prowadzenia projektów. Po drugie zapytałem, czy ktoś byłby chętny, aby komentować rozdziały na etapie prototypu. Po trzecie pojechałem na miejsce przestępstwa zaplanować zbrodnię.
Bałem się, że utknę na starcie. Formuła nietypowa, w sumie to nie wiem, jak wydawnictwo dało się przekonać do tego pomysłu. Ale pisanie posuwa się naprzód. Już powstały pierwsze trzy rozdziały, kolejne dwa są w trakcie. Dzisiaj szacuję, że będzie około 15-20 rozdziałów. Zobaczymy.
Zgłosiło się niemal trzydzieści osób. Do pierwszych części otrzymałem dosłownie kilkaset komentarzy, uwag i propozycji. Dotyczyły błędów językowych, stylu, niezrozumiałych fragmentów tekstu, ale też merytoryki, czy zachowań bohaterów powieści. Do większości zdążyłem się odnieść, część odłożyłem na później, bo muszę sobie je przemyśleć.
Przede mną parę problemów związanych z fabułą. Trochę jeszcze sprawdzania faktów. W tym celu kupiłem kilka książek o historii dzieł sztuki i renowacji zabytków. Trzymajcie kciuki, żeby do listopada udało się skończyć.
Narazie nie mam tytułu, ale jeśli ktoś miałby ciekawą propozycję, to chętnie posłucham. Tytuł poprzedniej mojej powieści zainspirowali również czytelnicy.
Co to za zdjęcie i dlaczego znalazło się w tym wpisie? Drodzy recenzenci, powinniście się domyślić… To jest właśnie ten pomnik.
utworzone przez Marcin Żmigrodzki
Wiedzieliście, że Komisja Europejska rozwija własną metodykę prowadzenia projektów w duchu agile? Okazuje się, że tak.
Efektem prac tego zespołu jest stworzenie dwóch książek, które za darmo można pobrać ze stron Unii Europejskiej. Metodykę opracowała organizacja pod nazwą PM2 Alliance. Ku mojemu zaskoczeniu, bo nie wiedziałem do niedawna o jej istnieniu, PM2 Alliance oferuje sześć certyfikatów, członkostwo i własne standardy, a nawet program afiliacyjny dla firm szkoleniowych. Sprawdziłem jednak, czy są jakieś oferty pracy wymagające tych certyfikacji i na terenie EU nie znalazłem żadnej (szukałem w Linkedin). Więc chyba organizacja nie jest jeszcze zbyt rozpoznawalna. Ciekawe, jak się rozwinie.
PM2 Alliance prowadzi działalność również przez regionalne oddziały, organizując konferencje i seminaria. Jednak nie znalazłem żadnej aktywności w Polsce. Nie ma też oddziału w Polsce. Może to jest dobry moment, aby grupa wolontariuszy przejęła inicjatywę i ściągnęła PM2 Alliance do Polski? Trzecia konkurencyjna organizacja do IPMA i PMI? Czemu nie 🙂
Książka pierwsza to zwinne projekty. Podręcznik do zwinnego prowadzenia projektów ma 114 stron i jest za darmo do pobrania z pm2alliance.eu. Nazywa się PM2 – Agile Guide 3.0.1. Napisano go w formule tzw. body of knowledge, czyli leksykony zawierającego omówienie najważniejszych zagadnień z zarządzania zwinnego projektami. Nie jest to zatem metodyka tylko opis różnych podejść wrzuconych do wspólnego worka pod nazwa agile. Treści podzielono rozdziały o różnych metodykach zwinnych, rolach, ceremoniach (głównie chodzi o spotkania), dokumentach i technikach. Aby nie był to tylko spis zagadnień, autorzy dodali wstęp omawiający, czym jest agile i jak go stosować. Do poszczególnych technik dopisano też tabelki RAM, aby pokazać, jakie role są zaangażowane w daną technikę.
Książka druga to kaskadowe. Podręcznik do kaskadowego prowadzenia projektów ma 147 stron i napisano go w bardzo podobny sposób do PMBOK Guide. Nawet układ rozdziałów przypomina tą książkę tyle, że podziału dokonano nie na obszary wiedzy a na grupy procesów: inicjacja, planowanie, kontrola, koordynacja, zamykanie. Zaś podrozdziały z kolei przypominają procesy PMBOKowe. Mają inputy, role, kroki, outputy. W książce proponuje się całą listę nowych dla mnie ról, np. User Representative, Project Owner, Solution Provider, Business Implementation Group. Mam wątpliwości, czy to nazewnictwo się przyjmie, bo w projektach raczej zadomowił się Sponsor. Mam też spore wątpliwości, gdy metodyka oferuje dużo predefiniowanych ról. Pachnie mi to wówczas Prince2 lub AgilePM, czyli malowaniem strusia w barwy kolibra.
Książki są dość obszerne i są za darmo. To ich niewątpliwa zaleta. Jednak układ treści przypomina nieco PMBOK Guide, co utrudnia uczenie się z nich od deski do deski. Raczej mogą pełnić rolę reference book, czyli pozycji, które otwiera się na właściwej stronie, gdy ma się konkretny problem. Mi bardzo brakuje w nich przykładów zastosowania. W książkach pojawia się mnóstwo terminów, np. ArOw (architecture owner), ale brakuje pokazania, jak dany termin w praktyce ma funkcjonować. Wrzucenie tabelki RAM to za mało moim zdaniem, aby dobrze to zrozumieć. Książki natomiast mogą się sprawdzić przy podejściu do certyfikacji oferowanych przez PM2 Alliance, podobnie jak PMBOK Guide pomaga w egzaminie PMP. Wadą obu pozycji jest jeszcze pominięcie opisów technik. Uważa, że właśnie techniki najlepiej jest przedstawić w formie takiego body of knowledge / leksykonu, bo czytelnik może sobie z nich sam dobierać, co mu pasuje do sytuacji.
Ta inicjatywa przypomina inicjatywę, w której sam brałem udział w Polsce. Jej celem było stworzyć podręczniki, rekomendacje i program rozwoju kompetencji zarządzania projektami dla sektora publicznego. Była ona prowadzona pod egidą KPRM. Więcej informacji o niej znajdziecie tutaj.
Więcej informacji o inicjatywie Komisji Europejskiej znajdziecie tutaj. Natomiast samą książeczkę możecie pobrać tutaj i tutaj.
utworzone przez Marcin Żmigrodzki
Uruchamiam grupy na dwóch kierunkach Zarządzanie projektem IT oraz Zarządzanie Wymaganiami i Analiza Biznesowa.
Zarządzanie projektem IT wprowadza w aspekty zarówno zwinnego, jak i kaskadowego prowadzenia projektów. Program został zaprojektowany tak, aby przybliżyć PMBOK Guide i ułatwić przygotowanie się do egzaminu PMP i równolegle przybliżyć Scrum Guide, manifest Agile i inne metodyki zwinne i wesprzeć przygotowanie się do egzaminu ACP, CSM, PSM.
Ponadto w programie tych studiów poświęcamy około 50% czasu na symulacje klasyczne, jak Massawa, Mayday, Scrum Droid i komputerowe: Kanban, Monte Carlo, Trucks, Earned Value. Dodatkowo oferujemy dzień szkolenia na temat MS Project i dzień o frameworkach skalujących agile.
Więcej o studiach zarządzania projektem IT przeczytasz na stronach WSB.
Studia Zarządzanie Wymaganiami wprowadzają w aspekty pracy analityka biznesowego. Ten zawód rozumiemy szeroko od analizy sensowności ekonomicznej pomysłu, przez działania kreatywne, przez gromadzenie wymagań funkcjonalnych, po modelowanie systemów informatycznych. W ramach studiów oferujemy symulacje zaprojektowane specjalnie dla tych studiów, jak Floryda i Korea Północna.
Więcej o studiach zarządzanie wymaganiami też przeczytasz na stronach WSB.
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).
