Blog

Wytworzenie i utrzymywanie produktu to prawie zawsze zmaganie się z nieprzewidywalnością i zmiennością. Niewiele jest rozwiązań, które wytworzone raz funkcjonują w pierwotnej formie przez lata. Wynika to ze zmieniających się potrzeb osób, które z produktu korzystają, modyfikacji przepisów prawa, starzenia się technologii (jeśli produkt od niej zależy), trendów na rynku, zmian społecznych, działań konkurencji… długo by wymieniać.

Nadchodzi zmiana…

Zmiana jest nieuchronna, nawet jeśli produkty mają fizyczny wymiar, bo dopóki wytwarzamy nowe egzemplarze, dopóty kolejne wersje mogą podlegać modyfikacji. Czy istnieje produkt całkowicie odporny na zmiany? Cóż, musiałby istnieć w jednym egzemplarzu, który od momentu osiągnięcia docelowej formy ma za zadanie wyłącznie trwać, opierając się upływowi czasu. Do tej kategorii dałoby się zaliczyć piramidę Cheopsa albo słynne dzieła sztuki, choć pamiętać trzeba, że żaden z takich produktów nie powstawał raz-a-dobrze pa podstawie ułożonego z góry planu.

Dominik Jabłoński po przeczytaniu powyższego akapitu dał świetny przykład tego, jak wygląda empiryczne (iteracyjne i inkrementalne) tworzenie dzieł sztuki: w trakcie analizy spektrometrycznej znanych obrazów okazuje się, że autorzy wielokrotnie poprawiali je, przemalowywali, lub tworzyli na początku coś zgoła innego, niż podziwiamy teraz. Ta niezmienność dzieł jest więc pozorna i rozpoczęła się dopiero w momencie ich ukończenia.

Nieuchronności pojawienia się zmiany towarzyszy często kłopot z przewidzeniem, jaki będzie jej charakter i skala, oraz kiedy nastąpi. Im większa złożoność domeny, w której funkcjonuje produkt (przez domenę rozumiem tu zarówno to, czym produkt jest, jak i środowisko, w jakim funkcjonuje), tym przewidywanie staje się trudniejsze. Rośnie liczba czynników, które oddziałują wzajemnie na siebie, powodując, że niewiele da się skutecznie przewidzieć.

Empiryzm

Wiele organizacji odłożyło na półkę tradycyjne metody oparte na analizowaniu, projektowaniu i planowaniu działań z góry (lub z dużym wyprzedzeniem). Wraz ze wzrostem zrozumienia, że zmiana jest nieuchronna, rośnie popularność podejścia Agile, w tym dominującej metody tego nurtu, czyli Scruma. Pociągnęło to za sobą zmianę sposobu, w jaki zarządza się produktami i ich rozwojem: tradycyjny product management, oparty o podejście projektowe, wypierany jest przez iteracyjne i inkrementalne rozwijanie produktu z wykorzystaniem praktyk zwinnych.

Tu uwaga: zarządzanie produktem jako dyscyplina oraz związane z nią role są popularne przede wszystkim za Atlantykiem. W Europie najczęściej mówi się o zarządzaniu projektami lub realizacji projektów – co dużo czytelniej pokazuje, że w centrum uwagi tradycyjnych metod znajduje się zwykle projekt (a więc perspektywa wytwórcy), a nie produkt (perspektywa użytkownika).

Kluczem do radzenia sobie z nieprzewidywalną zmiennością jest empiryczna kontrola procesu: należy rozwijać produkty, dokonując w nich niewielkich modyfikacji, często i regularnie sprawdzając, do jakiego stopnia najnowsza wersja jest zbieżna z potrzebami użytkowników.

Skąd wiadomo jakich modyfikacji dokonać? Cóż, tak naprawdę nie wiadomo, dlatego zmiany są niewielkie i wprowadza się je inkrementalnie, a sprawdzenia, czy przyjęty kierunek jest właściwy, dokonuje się często. Inaczej mówiąc, zamiast tracić czas i środki na próbę ustalenia z góry ze „stuprocentową pewnością”, co warto zrobić, dokonuje się niewielkich zmian w produkcie po to, by empirycznie sprawdzić, czy coś da się zrobić i będzie to korzystne dla użytkowników.

Empiryzm słusznie kojarzy się z eksperymentami naukowymi: uczeni formułują teorię lub jakąś hipotezę, po czym przeprowadzają badania, które mają dostarczyć dowodu na słuszność teorii (hipotezy) albo ją obalić. To drugie, co oczywiste, zazwyczaj jest dużo prostsze… Tak, jak uczeni tworzą różne teorie, tak zarządzający produktem (w świecie zwinnym najczęściej zwani Product Ownerami – właścicielami produktów) prognozują, co przyniesie wartość (można powiedzieć, że formułują hipotezy produktowe) i wraz ze swoimi Zespołami walidują je, dokonując zmian w produkcie.

Zabawa w przewidywanie

Wielu tradycyjnych managerów próbuje z góry przewidzieć wszystko, posługując się metodami analitycznymi i mniej lub bardziej udatnymi modelami, pozwalającymi prognozować przyszłość. Im większa jest ich wiara we własne umiejętności przewidywania, tym bardziej przekonani są, że plan będący produktem tego procesu daje gwarancję sukcesu. Im bardziej są świadomi niskiej skuteczności przewidywania w domenie złożonej, tym lepiej rozumieją, że produktem zawsze jest jedynie hipoteza, którą trzeba sprawdzić. I może okazać się, że jest słuszna lub całkowicie błędna.

Jak potwierdzić hipotezę? Ano, trzeba wykonać jakieś działania (dokonać zmian w produkcie), sprawdzić rezultaty i – o ile eksperyment przeprowadzony był poprawnie – uzyskać odpowiedź prawda lub fałsz. Czasami i to nie jest możliwe, a celem eksperymentu będzie nie tyle potwierdzenie hipotezy, ile dostarczenie danych pozwalających hipotezę zmodyfikować (doprecyzować) i proces powtórzyć (nierzadko takich cykli będzie kilka).

Koszt eksperymentu

Oczywistością jest, że eksperymentowanie kosztuje, zarówno w nauce, jak i przy budowaniu produktów. Jeśli manager produktu ma przekonanie, że wie, co jest wartościowe dla użytkowników na tyle, by za niego zapłacili, może po prostu zlecić realizację takiego rozwiązania. Po zakończeniu prac będzie wiadomo na pewno… Jeśli założenia managera nie potwierdzą się, cała inwestycja okaże się marnotrawstwem. Być może organizację stać na szastanie pieniędzmi, ale straconego czasu nie da się odzyskać. W przypadku niektórych produktów trafienie we właściwy momencie na rynek jest kluczem do sukcesu, więc strata czasu może mieć katastrofalne skutki.

Zwinny manager produktu (Product Owner) nie przyjmie projektowego podejścia opisanego powyżej. Będzie szukał najprostszego (a przez to najczęściej najtańszego i najszybszego) potwierdzenia swoich założeń. W efekcie może okazać się, że zanim zabierze się za budowanie produktu, który wymaga sporych środków i czasu, i który obarczony jest dużym ryzykiem inwestycyjnym, wytworzy zupełnie inny prostszy produkt tylko po to, by poznać rynek i uzyskać twarde potwierdzenie, że rozważana inwestycja ma w ogóle sens.

Nieuchronność zmian, ich nieprzewidywalność i wynikająca z tego konieczność stosowania empiryzmu powoduje konieczność eksperymentowania przy budowaniu produktu. Nie chodzi tu o „zabawę produktem”, ale realne działania, wspierane przez profesjonalne narzędzia, praktyki i ekspertów, które mają za zadanie zwiększyć szanse na powodzenie produktu.

Co warto zbudować?

Niestety, wielu Product Ownerów ma problem z uświadomieniem inwestorów (tych, którzy płacą za wytworzenie produktu i chcą na tym zarobić), że eksperymentowanie nie jest marnowaniem pieniędzy. Na szkoleniach, ale też w dyskusjach na forach internetowych, przewija się często utyskiwanie na interesariuszy napierających, by jak najszybciej przejść do monetyzacji rozwiązań.

Jeśli tworzony jest nowy produkt presja, by zacząć zarabiać na produkcie jest tak naprawdę całkiem sensowna. Nie istnieje lepszy sposób, by potwierdzić, że rozwiązanie jest wartościowe i ma rynkowy potencjał, niż udostępnienie go użytkownikom. Jeśli model biznesowy zakłada, iż pojawią się zyski, potwierdzeniem słuszności hipotez stawianych przez Product Ownera jest uzyskanie pieniędzy z rynku. Co więcej, to nie wyklucza możliwości eksperymentowania – udostępnienie produktu i sprawdzenie, jak radzi sobie komercyjnie, jest przecież eksperymentem. Cała sztuka w tym, by zrobić jak najmniej, ale jednocześnie na tyle dużo, by nie zepsuć wizerunku produktu (w szczególności poprzez dostarczenie bubla).

Jeśli Product Owner usilnie szuka powodów, by „jeszcze dopracować” rozwiązanie, które w ocenie interesariuszy ma już potencjał rynkowy – prawdopodobnie wyświadcza niedźwiedzią przysługę tak produktowi, jak i organizacji (inwestorom). Taki Product Owner powinien dokonać autorefleksji, bo niewykluczone, że mimo deklarowania chęci działania zwinnego, gdzieś w głębi – zakopane pod splątanymi synapsami – mocno trzyma się w jego umyśle dążenie do zrobienia idealnego rozwiązania raz-a-dobrze w ramach tradycyjnego projektu.

Zysk przede wszystkim

Nieco inna jest sytuacja Product Ownera, który pracuje z produktem już obecnym na rynku i zarabiającym pieniądze dla inwestorów. Czasem ciężko przekonać ich o potrzebie eksperymentowania (i ponoszenia kosztów z tego wynikających). Najczęściej kryje się za tym obawa, że zmiany zdestabilizują produkt, ale może to być również chęć maksymalizacji zwrotu z inwestycji, połączona z przekonaniem o tym, że produkt już jest wystarczająco dobry.

Problem w tym, że produkt, którego rozwój uległ stagnacji, nie jest odporny na nieprzewidywalne zmiany rynku, a te mogą spowodować (powoli, lub z dnia na dzień), że możliwość zarabiania na produkcie zacznie się zmniejszać albo całkowicie zaniknie. Nie brakuje w historii firm, które zabiły swoje produkty (a nierzadko i siebie), bo zatraciły zdolność reagowania na zmiany rynkowe. Kto z was używa dziś aparatów fotograficznych Kodaka? Albo ma telefon od Ericssona?

Jak może wyglądać taka prawdziwie katastrofalna polityka produktowa? Wyobraźmy sobie produkt, który jako pierwszy zaistniał na rynku i traktowany był na nim jako objawienie. Wiele lat później standardy się zmieniły, potrzeby użytkowników również, konkurencja wiele rzeczy robi lepiej. Firma jest jednak przekonana, że ma „najlepszy produkt na rynku” i wciąż jest w trybie maksymalizacji zysków, dlatego nawet nie sprawdza, czy użytkownicy wciąż są zadowoleni. Ba, inwestorzy cieszą się z całkiem pokaźnej kwoty, jaką co kwartał wymuszają na użytkownikach za pomoc przy korzystaniu z produktu – to czysty zysk, nieprawdaż? Każdy bez trudu domyślić się może, do czego prowadzi taka strategia i co stanie się, gdy na rynku pojawi się konkurencyjne rozwiązanie…

Jak przekonać inwestorów do eksperymentowania?

Celem inwestorów jest uzyskanie zysków. Wykładają pieniądze, żeby zarobić. Warunkiem kluczowym, by produkt przyniósł spodziewane zyski, jest dostarczenie użytkownikom wartościowego rozwiązania. Zapłacą za nie tylko wtedy, gdy produkt zaspokoi jakąś potrzebę lub rozwiąże istotny problem. Choć też nie zawsze, a jedynie wtedy, jeśli uzyskana wartość uzasadnia zapłacenie ceny, której dostawca produktu zażąda.

Aby możliwe było rozwiązanie jakiegokolwiek problemu lub zaspokojenie potrzeby, twórca produktu musi je poznać. Wiedzę taką zgromadzić można od użytkowników (obecnych lub potencjalnych), można też przeprowadzić badania runku, wbudować w rozwiązanie telemetrię i tak dalej. Technik i praktyk jest wiele, ale wszystkie łączy jedno: wymagają świadomego konstruowania eksperymentu, który pozwoli uzyskać informację niezbędną do podejmowania decyzji produktowych.

Przy czym, dopóki produkt nie zostanie udostępniony użytkownikom, wszystkie założenia biznesowe są jedynie spekulacjami. Tak naprawdę jedynym sposobem, by je potwierdzić, jest zebranie informacji o tym, w jaki sposób produkt jest używany i postrzegany: feedbacku, opinii, miar itd.

Żeby rozwiązanie dało się dostarczyć użytkownikom, trzeba go zbudować – co samo w sobie jest procesem złożonym, obciążonym sporą dozą nieprzewidywalnej zmienności. Dlatego, zamiast budować wszystko na raz, należy skupić się na tym, co w danym momencie najważniejsze: najbardziej potrzebne użytkownikom, obłożone największym ryzykiem, priorytetowe i tak dalej. Kryteriów wyboru konkretnych rzeczy do zrobienia może być wiele i zwykle nie da się stworzyć żadnego „obiektywnego algorytmu”, który zastąpiłby w podejmowaniu decyzji managera produktu (np. Product Ownera).

Przeprowadzony eksperyment może ujawnić nowe potrzeby użytkowników lub przewartościowanie potrzeb wcześniej istniejących, co wymagać będzie dalszego dostosowania produktu (realizacji kolejnego eksperymentu). W ten sposób cykl się domyka. Przy czym w odróżnieniu od podejścia projektowego (którego wyrazem jest wspomniany już raz-a-dobrzyzm), użytkownik jest cały czas w centrum uwagi. Innymi słowy, jeśli ma być możliwe realizowanie zysków z inwestycji, proces wytwórczy musi być podporządkowany potrzebom użytkownika i nie może skupić się na tworzeniu rozwiązań korzystnych wyłącznie dla wytwórcy (inwestorów).

Zwinny manager produktu (Product Owner) jest tym, który musi pokazać inwestorom wartość eksperymentowania i uświadomić ich, że jest ono niezbędne. Poniżej przedstawiam listę korzyści, które zwykle pojawiają się w organizacjach rozwijających produkt w sposób empiryczny:

• ograniczenie ryzyka inwestycyjnego przy rozwoju nowych funkcjonalności i cech użytkowych produktu,
• możliwość szybszego uzyskania wartościowych rozwiązań dzięki temu, że prace rozpoczynają się wcześniej, niż w tradycyjnych metodach, gdzie sporo czasu spędza się na analizach, planowaniu, projektowaniu itd.,
• uzyskanie i utrzymywanie zdolności do dokonywania szybkich zmian w produkcie, co pozwala szybciej reagować na zmienne potrzeby rynku,
• utrzymanie technicznej zdolności do eksperymentowania, która szybko zostaje utracona, jeśli z niej się nie korzysta, a której odzyskanie jest czasochłonne i kosztowne,
• większa innowacyjność dzięki temu, że Zespoły, które wytwarzają produkt, mogą wspólnie z managerami produktów wypracowywać rozwiązania, zamiast jedynie budować to, co wymyślono w całkowitym oderwaniu od realiów developmentu.

Oczywiście lista ta nie jest kompletna, tylko raczej podstawowa i na pewno da się ją rozszerzyć.

Nie można też zapominać, że eksperymentowanie kosztuje, bo zapewnienie możliwości empirycznej kontroli procesu wiąże się z koniecznością poświęcania czasu, wysiłku i środków na uzyskanie niezbędnej przejrzystości i regularnego sprawdzania stanu spraw (a przede wszystkim produktu).

Opłacalność empirycznego podejścia do rozwoju produktu nie bierze się z tego, że cokolwiek zrobione zostanie taniej lub szybciej niż w metodach tradycyjnych ani że „tego, co robiliśmy do tej pory, uda się zrobić się więcej w krótszym czasie”. Potencjał metod zwinnych kryje się właśnie w eksperymentowaniu, dzięki któremu szybciej udaje się ustalić, co warto zrobić, a jednocześnie skuteczniej odkrywa się, co jest zbędne.

Inaczej mówiąc, empiryczny rozwój produktu to lepsze wybieranie tego, co warto zrobić, dzięki czemu ograniczony czas, środki i możliwości Zespołów używane są na robienie tego, co przynosi wymierne korzyści. Produkt nie rozrasta się szybciej i nie ma w nim więcej funkcjonalności, ale istnieje dużo większa szansa, że będzie zawierał to, czego potrzebują użytkownicy i że najważniejsze rzeczy pojawią się w nim szybko.

Kultura eksperymentu

Jest to fundamentalna zmiana, bo w wielu organizacjach klient lub użytkownik jest pozornie na pierwszym miejscu, ale jeśli spojrzy się w sposób działania (budowania rozwiązań), okazuje się to nieprawdą. Bo choć „najważniejszy jest klient”, badania rynku traktowane są jako nieuzasadniony koszt. Bo choć wszyscy mówią, że „rozwiązujemy problemy użytkowników” – dział marketingu, sprzedaży (lub dowolny inny) jest przekonany, że wie najlepiej, co w produkcie powinno się znaleźć. Wynika to z niewiedzy, czasem z obawy przed zmianą, nierzadko z przerośniętego ego i ambicji decydentów (niestety). A czasami po prostu z głupoty.

Czego potrzeba, by produkt odniósł sukces? Co skutecznie pozwoli działać empirycznie, eksperymentować? W każdej organizacji odpowiedź na te pytania może być nieco inna, ale bez wątpienia przyda się świadomy swej roli zwinny manager produktu (Product Owner), Developerzy (być może wiele Zespołów), umiejący używać technologii i praktyk z nimi związanych oraz świadomość, dla kogo tworzony jest produkt i co stanowi wartość dla jego użytkowników.

Odpowiedź

Na koniec warto przypomnieć tytułowe pytanie: czy stać nas na eksperymenty? Odpowiedź to, niestety, inne pytanie (dużo ważniejsze): a czy stać nas na to, by ich nie robić?