Kiedy mamy wystarczającą wiedzę do podjęcia decyzji?
W komentarzu do mojego niedawnego artykułu Łukasz Korulczyk zadał bardzo ciekawe pytanie – kiedy wiemy wystarczająco dużo aby podjąć decyzję? Pytanie pozornie bardzo proste, ale po chwili zastanowienia uderzyła mnie jedna rzecz. Otóż tak na dobrą sprawę odpowiedź na to pytanie w najmniejszym stopniu zależy od samego zagadnienia. W tym artykule postaram się więc usystematyzować kilka przemyśleń, które mi się nasuwają w związku z tym.
Ryzyko.
Wydaje się, że wszystkie czynniki które znajdziesz poniżej na koniec dnia sprowadzają się do bilansu ryzyka. Część z nich pozwala obniżyć ryzyko jakie musielibyśmy podjąć, a druga część pozwala przyjąć większe ryzyko. Oczywiście czym ryzyko niższe, tym bezpieczniej – ale czy lepiej? Sądzę, że nie koniecznie. Musimy pamiętać że w silnie dynamicznym środowisku czas również może grać na naszą niekorzyść, chociażby przez to że każdy dodatkowy dzień spędzony na badaniach przed podjęciem decyzji opóźnia start prac, a w konsekwencji także ich zakończenie. Dodatkowo pozyskiwanie wiedzy to także koszt – czasu, zasobów, odsuniętych w czasie efektów, dlatego też warto nie popadać w skrajność i inwestować w badania więcej niż np. może wynieść potencjalna korzyść ze zrobienia czegoś.
Ograniczenie ryzyka.
Pierwszym i chyba najbardziej naturalnym odruchem w sytuacji podejmowania decyzji jest ograniczenie ryzyka. Myślę, że wiąże się to trochę z tym, że to jest najbardziej w naszej mocy. Alternatywą dla ograniczenia ryzyka jest podniesienie tolerancji na nie, ale to z kolei rzadko zależy od nas samych i nie zawsze jest czymś co możemy dynamicznie kształtować. Skoro więc ograniczamy, to w jaki sposób?
Po pierwsze oczywiście – wszelkie metody badawcze dostępne przed wykonaniem jakiegokolwiek ruchu. Bezpośrednie wywiady z klientami, „głos klienta” przekazywany przez zespół pracujący z klientami, benchmarki rynkowe, analityka, wiedza historyczna obecna w organizacji, czy wreszcie własne doświadczenie lub doradztwo mentorów. Wszelkie tego typu prognozy są na pewno istotną przesłanką, że „gdzieś tam” jest przynajmniej minimalny potencjał lub potrzeba na wdrożenie danego rozwiązania. W ten sposób upewniamy się co do istnienia samej potrzeby.
Dalszym krokiem jaki możemy podjąć są wszelkie eksperymenty sprawdzające skuteczność konkretnego rozwiązania. Niewielkim nakładem pracy można przygotować makietę działającego rozwiązania i zderzyć takie statyczne, lecz klikalne makiety z grupą klientów lub wewnętrznie w organizacji i dowiedzieć się czy idziemy w dobrą stronę. Narzędzie takie jak InVision czy UsabilityHub pozwalają przygotować takie interaktywne prototypy i zebrać informację zwrotną (oczywiście jest ich dużo więcej, trzeba tylko poszukać 😀). W ten sposób pozyskujemy wiedzę, czy nasz pomysł na zaadresowanie potrzeby trafia do użytkowników.
Mając już poprzednie dwa dowody możemy z pewnym przekonaniem przejść do wdrażania pierwszego etapu rozwiązania i gdy już będzie gotowe do wdrożenia zacząć testy w coraz szerszym gronie użytkowników. Zapewne jednym z bardziej popularnych sposobów tutaj będą testy A/B, które pozwolą sprawdzić szerszy wpływ na biznes, choć również stopniowe uruchomienie funkcji coraz większej grupie użytkowników może dać nam wiedzę. W tym etapie wiele zależy od tego, jak postawimy sobie pytanie. Czy celujemy w optymalizację jakiegoś aspektu biznesowego, czy też np. stabilnie wdrożyć nową wersję starego rozwiązania i bardziej zależy nam na stabilności i wykryciu błędów na wczesnym etapie.
Chciałbym zwrócić uwagę na dwa „ukryte” przesłania w tej części. Pierwsze jest takie, że ciekawym sposobem na obniżenie ryzyka decyzji jest podzielenie jej na mniejsze etapy, po którym zawsze możemy zdecydować czy kontynuujemy lub wycofujemy się. Dzięki temu podziałowi tak naprawdę za każdym razem stawiamy przed sobą dużo „mniejsze” pytanie, na które możemy też siłą rzeczy dużo prościej odpowiedzieć i równocześnie zbieramy wiedzę empiryczną z poprzednich etapów. Na przykład zamiast „czy ta funkcja przyniesie filmie milion złotych?” zapytajmy po kolei „Czy nasi klienci mają taki problem?”, następnie „Czy nasza propozycja rozwiązania trafia do chociażby kilku klientów?” i ostatecznie „Czy wszyscy klienci znajdują ta wartość?”.
Drugie przesłanie jest takie, że do każdego „etapu” powinniśmy dobrać odpowiednie narzędzia badawcze i analityczne oraz świadomie podchodzić do uzyskiwanych informacji. Przykładowo sam fakt, że kilku klientom z grupy fokusowej spodoba się nasze rozwiązanie danego problemu, jeszcze nie świadczy o tym że wszyscy nasi klienci oszaleją na tym punkcie. Choć na pewno jest to dobry znak podpowiadający aby kontynuować prace w tym kierunku.
Podniesienie tolerancji ryzyka.
W metodyce prowadzenia projektów PRINCE funkcjonuje pojęcie „tolerancji”. Sprowadza się ono w największym skrócie do tego, jakie odstępstwo od zakładanych parametrów manager projektu może zaakceptować sam, a kiedy konieczne już jest dla niego uzyskanie zgody od przełożonych. Może to być budżet, kryteria jakościowe, terminy. W odniesieniu do własnego przykładu właśnie w ten sposób rozumiem koncepcję decyzyjności.
W sytuacji kiedy mamy do podjęcia decyzję, bardzo ważne jest dobre zrozumienie tego na co możemy sobie pozwolić, a co już leży poza naszym zasięgiem. W pewnym sensie jest to nasz „budżet”, którym możemy dysponować i oczywiście wykazywać się jak najlepszą stopą zwrotu z podejmowanych decyzji.
W jaki sposób więc możemy kształtować tolerancję ryzyka? Dostrzegam dwa główne czynniki. Pierwszy to rola w organizacji. W części organizacji zależność jest prosta – czym „wyższe stanowisko” tym większe ryzyko możemy podjąć. Z kolei w innych organizacjach tolerancja nie rośnie już wraz z „seniority” czy „directority” (😉) ale wraz z podejmowaną odpowiedzialnością, „ownershipem”. Wydaje się sensowne to, że czym bardziej się angażujemy w dany temat i chcemy się nim zająć, zaopiekować to tym więcej swojej decyzyjności przenoszą na nas nasi liderzy.
Warto też wspomnieć, że poza „syntetycznym” określeniem gdzie w organizacji się obecnie znajdujemy, istotną rolę odgrywają też relacje i samo środowisko. Relacje możemy budować realizując z powodzeniem coraz to bardziej złożone zadania, wychodząc z inicjatywą i pokazując zaangażowanie. Jestem niemal 100% pewien że interesariusze będą dużo bardziej chętni dać większy kredyt zaufania komuś, kto ma na swoim koncie 10/10 skutecznych realizacji, aniżeli komuś kto świeżo pojawił się w organizacji i jeszcze nie ma wspólnej historii.
Czynnik środowiskowy natomiast rozumiem w taki sposób, że możliwe jest że w sam sposób działania organizacji są już wbudowane elementy, które nie pozwolą nam popełnić kosztownej pomyłki. Pierwszym z brzegu przykładem może być dział pracujący z grupami fokusowymi, który „z automatu” dla każdego pomysłu przechodzącego przez fazy realizacji zapewnia informację zwrotną od reprezentantów grupy docelowej. W takim środowisku możemy dużo śmielej postępować, bo mamy „wbudowany w proces” bezpiecznik. Jest zapewne całkiem sporo innych możliwych mechanizmów, które mogą dawać nam większą tolerancję na ryzyko przy podejmowanych decyzjach.
Poza zarządzaniem ryzykiem chciałbym jeszcze dodać jedną ważną rzecz – mianowicie elementem każdej decyzji poza ryzykiem jest oczywiście też korzyść czy wartość jaką organizacja może zyskać po zrealizowaniu danego projektu. W tym artykule jednak celowo opuściłem ten czynnik, bo zakładam że ocena potencjalnej wartości następuje zanim w ogóle zaczniemy się dalej zastanawiać czy powinniśmy realizować dany pomysł. Jeżeli dany projekt nie ma potencjału i nie wierzymy w niego, to po prostu odkładamy go do szuflady.
Na koniec wypadałoby więc wprost odnieść się do pytania postawionego w tytule.
Wystarczająco wiemy wtedy, kiedy ryzyko jest akceptowalne.
Oczywiście tradycyjnie już – jeśli przychodzi Ci do głowy inny, ciekawy sposób podejścia do oceny kiedy wiemy wystarczająco to zapraszam do podzielenia się w komentarzu 🙂
Piona!
p. s. Nieco więcej na temat zaufania i jego znaczenia znajdziesz też w tym artykule .
Natomiast jeśli interesuje Cię temat środowiska „safe-to-fail” i jego szerszego znaczenia w organizacji to zapraszam do tego artykułu .
