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:

  1. Eliminacji niewiedzy
  2. 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:

  1. Koszt nanoszenia zmian na tyle niski, że uzasadniony wartością biznesową lub korzyścią z redukcji niepewności.
  2. 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).

Zapisz się na nasz newsletter

Zapisz się na nasz newsletter

Twój e-mail został zapisany

Share This