Skip to main content

Czym jest eksperymentowanie w kontekście tworzenia produktów?

August 9, 2024

Kiedy myślisz o eksperymentowaniu, co Ci przychodzi do głowy? Może nieskazitelnie czyste laboratorium, ludzie w białych fartuchach, specjalnych maskach ochronnych, rękawiczkach. A może przypominają Ci się szkolne zadania i projekty naukowe, np. uprawa ziemniaka w doniczce czy hodowla kryształów z soli. Takie działania pomagają nam lepiej zrozumieć otaczający nas świat i uczyć się efektywniej. Zatem wydaje się całkowicie naturalne łączenie eksperymentowania z uczniami, studentami i naukowcami. A co jeśli nie należysz do żadnej z tych grup? Czy temat eksperymentowania powinien Cię w jakimkolwiek stopniu dotyczyć?

I tu pojawia się niespodzianka: uczniów i naukowców łączy uczenie się poprzez działanie i poruszanie się w obszarze niepewności. Nie chcę Cię zachęcić do spojrzenia na siebie jak na uczennicę lub ucznia czy na osobę noszącą biały fartuch i okulary ochronne. Zamiast tego pragnę Ci pokazać, że właściwe podejście do eksperymentowania, dostosowane do Twojej sytuacji, może Ci pomóc w procesie podejmowania decyzji i ograniczyć straty, jakie możesz ponieść. Spójrzmy razem na to, jak eksperymenty wpisują się w kontekst rozwoju produktów.

eksperymentowanie-kobieta-w-laboratorium

Żyjemy w świecie założeń

To może się dla Ciebie okazać kolejną niespodzianką. Bardzo często w różnych sytuacjach przyjmujemy założenia (lub bazujemy na przypuszczeniach). Nawet pokusiłabym się o stwierdzenie, że założenia towarzyszą nam każdego dnia. Spójrzmy na poniższe stwierdzenia.

  • Zakładam, że mój kolega zrozumiał moją prośbę zgodnie z moimi intencjami.
  • Zespół zakłada, że wybrane rozwiązanie rozwiąże problem klienta.
  • Kalkulacja kosztów budowy nowego domu opiera się na założeniu, że ceny nie będą rosły.

Czy udało Ci się dostrzec założenia? Mam nadzieję, że tak, szczególnie że słowa związane z przyjmowaniem założeń pojawiają się wprost w powyższych zdaniach (“zakładam”, “zakłada”, “opiera się na założeniu”). Sprawa nie jest taka prosta w sytuacjach, gdy nie zaznaczamy, że takie czy inne założenie poczyniliśmy. Przed nami kolejne przykłady. Spójrzmy!

  • Zwiększymy zadowolenie użytkowników, jeśli dostarczymy funkcję ABC.
  • Nasz produkt ma niski udział w rynku, ponieważ użytkownikom nie odpowiada nasz interfejs użytkownika.
  • Nie udało mu się ukończyć zadania, ponieważ jest już przytłoczony wszystkimi swoimi obowiązkami.

I jak jest teraz? Czy już dostrzegasz założenia w tych stwierdzeniach? Nie do końca? Wkrótce wszystko stanie się jasne. Zanim przejdziemy dalej, przyjrzyjmy się definicjom:

założyćprzyjąć jakieś twierdzenie lub zasadę za podstawę dalszych wywodów lub dalszego postępowania [1]

przypuścićdomyślać się czegoś lub uważać coś, nie mając pewności [2]

Formułujemy założenia dość często, bo pomagają nam one radzić sobie z niepewnościami. Zakładamy, że coś jest takie, a nie inne i w oparciu o to wybieramy działania. Zakładamy, jakie będą potencjalne konsekwencje naszych działań. Podczas gdy założenia mogą nam pomóc chociażby w zawężaniu pola wyboru i w podejmowaniu decyzji, musimy się zmierzyć z trudną prawdą. Założenia, które nie bazują na faktach i dowodach, a jedynie na przypuszczeniach, mogą nas wyprowadzić na manowce (jest także możliwe, że będziemy mieli rację i założenia finalnie okażą się prawdziwe, jednakże może to przypominać zgadywanie w metodzie dwóch ud; się uda albo się nie uda).

Komentarz: Słowo, które jest motywem przewodnim tego artykułu to w języku angielskim “assumption”. Mam takie poczucie, że aby je dobrze przetłumaczyć, należałoby połączyć (przynajmniej w pewnym stopniu) przytoczone przeze mnie powyżej definicje słów “założenie” i “przypuszczenie”. Zdecydowałam, że będę tutaj głównie używać pierwszego z nich, a Ciebie, Droga Czytelniczko, Drogi Czytelniku, w razie chęci eksplorowania tematu w literaturze anglojęzycznej zachęcam do poszukiwań, korzystając ze słowa kluczowego “assumption”.

Założenie przyjmowane w tworzeniu i rozwoju produktów

Skoro już wiemy, że założenia bywają zwodnicze, wróćmy do naszych wcześniejszych przykładów. Gdzie zostały poczynione potencjalne założenia? Przeczytajmy je jeszcze raz i zwróćmy uwagę na słowa, które opisują przyszłe konsekwencje lub dostarczają wyjaśnień, ale... nie ma jasnych dowodów lub wystarczających danych na ich poparcie.

  • Zwiększymy zadowolenie użytkowników, jeśli dostarczymy funkcję ABC.
  • Nasz produkt ma niski udział w rynku, ponieważ użytkownikom nie odpowiada nasz interfejs użytkownika.
  • Nie udało mu się ukończyć zadania, ponieważ jest już przytłoczony wszystkimi swoimi obowiązkami.

W pierwszym przykładzie zakładamy, że użytkownicy będą zadowoleni z funkcji ABC. Ale skąd to wiemy? Na jakiej podstawie doszliśmy do takiego wniosku? Co skłoniło nas do wyboru tej konkretnej funkcji? W drugim przykładzie zakładamy, że użytkownicy nie lubią obecnego interfejsu użytkownika i że to wpływa na udział naszego produktu w rynku (czy zauważasz, że tak naprawdę mamy tutaj dwa założenia? Jedno może być prawdziwe, oba mogą być prawdziwe lub żadne z nich). W ostatnim zdaniu zakładamy, że ktoś jest przytłoczony obowiązkami i dlatego nie mógł ukończyć swojego zadania. To kolejny interesujący przykład, ponieważ istoty ludzkie są złożone i może być wiele powodów, dla których ktoś nie jest w stanie ukończyć zadania. Co więcej, na sytuację może również wpływać kombinacja różnych czynników.

Konsekwencje ślepego zaakceptowania tych założeń mogą być kosztowne i kłopotliwe. Możemy zbudować funkcję, której nikt nie chce, co prowadzi nie tylko do braku zwiększenia satysfakcji użytkowników, ale także do marnowania czasu i pieniędzy (nie wspominając o tym, że nawet możemy jeszcze bardziej obniżyć tę satysfakcję). Możemy przebudować cały interfejs użytkownika tylko po to, by przekonać się, że poprzednia wersja była wystarczająco dobra, a nowi użytkownicy jakoś tak drzwiami i oknami do nas się nie wpychają po wprowadzonych zmianach.  Możemy nawet zdemotywować kogoś, odbierając mu jego ulubione zadania, podczas gdy tak naprawdę potrzebował on zupełnie innego rozwiązania swojego problemu. Mieliśmy bardzo wartościowego człowieka w zespole, któremu wystarczyło trochę pomóc, a teraz mamy jego wypowiedzenie na biurku i wizję poszukiwania kogoś, kto mógłby go zastąpić.

Przykłady te ilustrują tylko kilka scenariuszy tego, co może się stać, jeśli zignorujemy fakt, że przyjęliśmy założenia bez dowodów jako prawdę. Otwiera to drzwi do różnego rodzaju marnotrawstwa, które może negatywnie wpłynąć na firmę. Dlatego umiejętność pracy z założeniami jest istotna i warto ją rozwijać.

Jak podchodzić do założeń

Czy istnieje więc sposób na skuteczne radzenie sobie z założeniami? Wypróbuj poniższe.

  1. Uczyń je przejrzystymi: Nie mieszaj faktów z założeniami. Wyraźnie rozróżniaj, co jest faktem, a co założeniem w Twoich wypowiedziach. Kiedy zaznaczasz, że “tutaj przyjęliśmy takie założenie, ale nie mamy twardych dowodów, że tak jest” dajesz innym sygnał, jak należy do tego podchodzić.
  2. Kwestionuj je: Szukaj danych lub dowodów, które potwierdzają lub zaprzeczają założeniu. Być może dane gdzieś są i można je (w miarę) łatwo uzyskać. Czy istnieją inne możliwe perspektywy lub wyjaśnienia? Jakie są potencjalne konsekwencje, jeśli się mylisz? Jak ryzykowne jest przyjęcie tego założenia?
  3. Zweryfikuj je: Jeśli twoje założenie wymaga sprawdzenia, znajdź sposoby na jego przetestowanie (uwaga: zwróć uwagę, że nie każde założenie powinno zostać zweryfikowane). Innymi słowy, w przypadku braku informacji, stwórz okazję do zebrania danych lub dowodów, które potwierdzą lub obalą Twoje założenie. Może zrobisz prosty test lub badanie z użytkownikami. Może po prostu zapytasz ich o ich zdanie, przeprowadzając ankietę. Stworzysz rysunki obrazujące pomysł i opowiesz o nim, aby zaobserwować reakcję potencjalnych użytkowników. Wszystkie te działania wchodzą w zakres eksperymentowania.

Eksperymentowanie: sposób na uczenie się i weryfikowanie założeń

Potrzebujemy sposobu skutecznej weryfikacji założeń, zwłaszcza tych, które niosą ze sobą znaczące ryzyko. Innymi słowy, jeśli przyjmiemy jakieś założenie za prawdziwe, a okaże się ono błędne, może to prowadzić do kosztów i niepożądanych konsekwencji, których wolelibyśmy uniknąć. W takiej sytuacji wchodzi nam eksperymentowanie, całe na biało!

W kontekście rozwoju produktu eksperymentowanie może być postrzegane jako sposób na weryfikację naszych założeń przy jednoczesnym ograniczeniu naszych inwestycji w proces uczenia się. Innymi słowy, jest to (stosunkowo) szybki sposób na określenie, czy warto podążać określoną ścieżką, na przykład podjęcie decyzji, czy powinniśmy zbudować funkcję ABC. Czekanie, aż zostanie nowa funkcja całkowicie opracowana i wdrożona, aby zweryfikować nasze założenie, to już może być stanowczo za późno. Zamiast tego eksperymentowanie pozwala nam zebrać informacje - dowody i dane - znacznie wcześniej, zamykając pętlę sprzężenia zwrotnego (pętlę uczenia). Ta informacja zwrotna może sugerować kontynuowanie obecnej ścieżki i potencjalne wykonanie następnego kroku lub zatrzymanie się w celu zebrania większej ilości informacji lub zbadania innych opcji.

Na przykład, zamiast podążać za królem Julianem [3], moglibyśmy poszukać sposobów na przetestowanie naszego założenia: czy rzeczywiście satysfakcja użytkowników wzrośnie, kiedy wdrożymy funkcję ABC? Pomocne może być zadanie sobie kilku pytań:

  • Jaki jest najszybszy, najprostszy, najskuteczniejszy sposób na sprawdzenie naszego założenia?
  • Jak możemy dowiedzieć się jak najwięcej bez pełnego stworzenia funkcji ABC?
  • Jak silnego sygnału potrzebujemy (jak silnego dowodu potrzebujemy)? Jaki jest wymagany poziom pewności?

Możemy przeprowadzić wywiady z grupą użytkowników lub wykorzystać obserwacje, aby zidentyfikować momenty niezadowolenia, które są zgodne z pomysłem na nową funkcję. Czy funkcja odnosi się do co najmniej jednego punktu bólu użytkownika (ang. pain point)? Możemy również stworzyć prototyp funkcji i zobaczyć, jak użytkownicy wchodzą z nią w interakcję, aby zebrać feedback. Jeśli nasze założenie jest błędne, eksperymentowanie pomaga zmniejszyć potencjalne straty i może ujawnić nowe ścieżki i pomysły, których wcześniej nie braliśmy pod uwagę. Świat eksperymentów oferuje techniki o różnych poziomach wiarygodności, które wymagają różnych nakładów inwestycyjnych. Możesz wybrać podejście, które najlepiej sprawdzi się w Twojej obecnej sytuacji.

Czy to dla mnie?

Jeśli stoisz przed złożonymi wyzwaniami lub rozwijasz produkty, eksperymentowanie może być potężnym narzędziem! Wierzę, że szybkość jest kluczowym aspektem naszej pracy - nie tylko pod względem dostarczania (co, z mojego doświadczenia, jest głównym celem w wielu firmach), ale co ważniejsze, pod względem uczenia się i podejmowania świadomych decyzji opartych na dowodach. Przewodnik po Scrumie wymienia eksperymentowanie wśród przykładów działań związanych z produktem [4]:

"Scrum Team ponosi odpowiedzialność za wszystkie działania związane z produktem obejmujące współpracę z interesariuszami, weryfikację, utrzymanie, obsługę, eksperymentowanie, badania i rozwój oraz wszelkie inne działania, które mogą okazać się konieczne."

Jest to dla nas ważne przypomnienie. Eksperymenty mogą być uważane za istotny element naszych Backlogów Produktu. Kiedy decydujemy się eksperymentować, niekoniecznie stajemy się naukowcami w laboratorium; raczej stosujemy naukowe myślenie, aby lepiej radzić sobie ze złożonością pojawiającą się w tworzeniu i rozwoju produktów.

 

[1] https://sjp.pwn.pl/sjp/zalozyc;2542999.html

[2] https://sjp.pwn.pl/sjp/przypuscic;2512474.html

[3] “Teraz prędko, zanim dotrze do nas, że to bez sensu”, król Julian jest postacią z filmu Madagaskar

[4] Przewodnik po Scrumie, wersja z 2020 roku

artistic_line

Cześć! Mam na imię Joanna (wiele osób zwraca się do mnie po prostu: Asia). Pracuję jako trenerka, konsultantka, mentorka i specjalistka uczenia w podejściu Action Learning. Pasjonuje mnie pomaganie osobom, zespołom i organizacjom w radzeniu sobie ze złożonymi wyzwaniami. Podobają Ci się moje treści? Chcesz dowiedzieć się więcej? Napisz do mnie: 

joanna@joannaplaskonka.com  

https://www.linkedin.com/in/joanna-plaskonka/

https://www.youtube.com/@scrum-with-joanna


What did you think about this post?