Pracując nad nowym newsletterem, poprosiłem Rafała Makarę o podzielenie się krótkim opisem wykorzystywania techniki Opportunity Solution Tree w praktyce. Rafał zgodził się. Jednak zamiast krótkiej odpowiedzi, otrzymałem dłuższy opis pracy z tą praktyką na wielu płaszczyznach. Zaproponowałem więc zmianę podejścia. Finalny efekt? Poniżej znajdziecie zapis naszej rozmowy w formie wywiadu.
Skąd bierze się potrzeba na Opportunity Solutions Tree?
Zacznijmy od branży. Dawno temu za oceanem, a nie tak dawno, w Europie, zaczęła pojawiać się moda na przenoszenie uwagi zespołów produktowych z samej produkcji funkcjonalności (outputs) na rzecz koncentracji na zmianach które mają wpływ na rezultaty biznesowe (outcomes that drive business results). Książki, jak Outcomes over Outputs, Escaping the Build Trap, Inspired zaczęły zwiększać naszą dojrzałość w sposobie myślenia o tym po co właściwie pracujemy.
Na konferencjach zaczęła się pojawiać tematyka problemu space i solution space. To sprawiło, że w ramach wielu burzliwych dyskusji zaczęło padać pytanie “jaki problem starasz się rozwiązać?" W tym momencie taka osoba wpadała w nieuporządkowane obszary swoich myśli. To, co usilnie starała się zrobić wewnątrz swojej głowy to wyobrażenie powiązania: mierzalnych rezultatów biznesowych (impact), znaczących zmian w zachowaniach (outcomes), realnych potrzeb/pragnień/bolączek użytkowników (opportunities) i rozwiązań (solutions). Często skutkowało to jednak przeładowaniem mózgu nadmiarem informacji.
Opportunity Solutions Tree jest jedną z metod wizualizacji, którą możemy wykorzystać, aby stworzyć efektywniejszą przestrzeń do współpracy dla zespołu zaangażowanego w etap discovery. OST pomoże nam bardziej skupić się na znalezieniu, zrozumieniu i priorytetyzacji problemów. Bez dobrej wizualizacji jest piekielnie trudno zrobić to dobrze. Co więcej, nasze dotychczasowe rozumienie problem space oraz solution space zostanie wzbogacone o dodatkowy krok poprzedzający, w którym zastanowimy się, dlaczego nad danymi problemami chcemy pracować.
Czym jest Opportunity Solution Tree?
Aby zrozumieć, na czym polega OST, najlepiej odnieść się do twórcy tej metody – Teresy Torres i jej artykułu Opportunity Solution Trees: Visualize Your Thinking.
Opportunity Solution Tree to narzędzie, które pomaga zespołom produktowym odkrywać najbardziej obiecujące możliwości do eksploracji i służy do skoncentrowania ich wysiłków na tworzeniu najlepszych rozwiązań.
W jakich sytuacjach stosujemy OST? Metoda ta znacznie ułatwia podejmowanie decyzji. Aby wykorzystać pełen potencjał narzędzia, przechodzimy wraz z nim przez następujący proces:
- Określamy oczekiwaną zmianę (outcome).
- Następnie definiujemy możliwości (opportunities), które zaadresowane mogą wpłynąć na daną zmianę.
- Na końcu wypracowujemy potencjalne rozwiązania.
Technika ta ma na celu ułatwić proces podejmowania decyzji i poprawić skupienie na celu.
Czy ta technika jest dla każdego?
Z perspektywy inżyniera, dwa najpopularniejsze modele pracy nad wytwarzaniem oprogramowania to praca w firmie usługowej lub w firmie produktowej.
W przypadku firmy usługowej zazwyczaj otrzymujemy zakres funkcji do zaimplementowania lub system do utrzymania. W takiej sytuacji jesteśmy odseparowani od wielu metryk którymi posługują się klienci naszej firmy w ramach budowania swojego biznesu. Tutaj może być trudniej wykorzystać OST w pełnym jego zakresie - chyba że współpraca z klientem, dla którego pracujemy jest naprawdę bardzo bliska.
Drugim modelem jest praca inżyniera w firmie produktowej. Wtedy zazwyczaj programista ma bardzo bliską relację z product managerem, a cały zespół ma dostęp do kompletu metryk biznesowych oraz strategicznego kontekstu, który jest wymagany do podejmowania decyzji w zakresie tego co chcemy zbudować. W tym modelu pracy, jako zespół raczej nie otrzymujemy ustalonego zakresu funkcji do implementacji, a otrzymujemy metrykę do optymalizacji. Wtedy zaczyna się najlepsza zabawa i zarazem największe wyzwanie - poszukiwanie i wybór problemów, nad którymi chcemy pracować, aby na konkretne metryki wpłynąć.
OST można wykorzystywać w obu tych środowiskach. Jednak w tym produktowym zastosowań będzie więcej.
W jaki sposób działa u Was praktyka Opportunity Solutions Tree?
W DocPlanner tworzymy rozwiązania cyfrowe, które są wykorzystywane przez pacjentów, lekarzy i kliniki na całym świecie. Skala i różnorodność powodują, że odpowiedź na to co powinniśmy dostarczyć nie należy do najłatwiejszych. Wobec tego jako zespół produktowy pracujemy iteracyjnie.
Nasza grupa, złożona z product managera, researcherów, product designerów oraz inżynierów, spotyka się cyklicznie w ramach discovery. W tym wypadku możemy to nawet nazwać continuous discovery. Mają oni zdefiniowaną metrykę na którą chcą wpłynąć.
Umieszczają całą wiedzę, jaka może im pomóc w znalezieniu sposobu wpłynięcia na daną metrykę, na wirtualnym boardzie w dość chaotyczny i nieuporządkowany sposób. Następnie dyskutują i starają się uporządkować wiedzę. Równolegle do tego procesu rysowane jest drzewo (lub drzewa) Opportunity Solutions Tree.
Pojedyncze drzewo jest skupione na jednym celu (outcome) do osiągnięcia. Analiza i burza mózgów doprowadzają do wylistowania różnych potrzeb, bolączek lub pragnień użytkowników (opportunities).
W tym momencie warto wykorzystać wizualizację drzewa do ustalenia priorytetów. Przesuwając jego elementy w lewo lub w prawo, wypracowujemy wspólne rozumienie tego, które outcome i/lub opportunities oceniamy jako bardziej wartościowe do przepracowania.
Dla nich staramy się wypracować kilka (minimum 2) pomysły na rozwiązania, które względem siebie ponownie priorytetyzujemy.
Wybrane rozwiązania lub eksperymenty stają się elementem backlogu zespołu produktowego. No i w zależności od sytuacji - można już w tym momencie programować lub robić projekt rozwiązania.
Czasami eksperymenty są małe i monitorowane odpowiednią analityką. Czasami od razu implementujemy funkcjonalność. Bywa różnie, jak to w życiu. Perfekcja nie jest drogą do doskonałości. :)
Mając takie drzewo jesteśmy już bardzo blisko osiągnięcia tego co, Marty Cagan nazywa Outcome Based Roadmaps.
Jakie zalety widzicie z korzystania z tej techniki w zespole i organizacji?
OST pomaga nam generować pomysły, szukać powiązań, przerzucać się opiniami, porównywać możliwości, budować wspólne rozumienie i podejmować decyzje. Bez wizualizacji istnieje wysokie prawdopodobieństwo, że proces byłby chaotyczny i pełen błędów poznawczych. Wybieralibyśmy wtedy pierwsze zauważone okazje lub rozwiązania, a najbardziej ekstrawertyczna osoba z łatwością przepychałaby swoje pomysły. Wykorzystywanie wizualizacji OSP pomaga uporządkować ten proces i czyni go dużo bardziej rzeczowym.
Ile osób bierze udział w pracy nad OST?
Zazwyczaj między 3 i 6. W niektórych zespołach łatwiej zachęcić inżynierów do brania udziału w discovery, a w innych trudniej. Jak to zazwyczaj bywa, trzeba walczyć z nadmiarem pracy przy innych tematach. Zaletą uczestnictwa jest większy wpływ na tworzone rozwiązanie. Dzięki wczesnemu zaangażowaniu inżynierów zdecydowanie obniża się ryzyko tego, że odbijemy się od rzeczywistości, która powie nam że realizacja danego rozwiązania zajmie potwornie dużo czasu. Bardzo często to właśnie inżynierzy wpadają na bardzo dobre pomysły na tym etapie.
Planując tego typu spotkania, nie warto przesadzać z ilością osób. Spotkania zdalne mające więcej niż 5 uczestników (w przypadku braku podziału na podgrupy lub dobrej facylitacji) stają się nudne i pozbawione dyskusji, co zmniejsza ich efektywność.
Warto jeszcze dodać, że w związku z tym, że OST to ciągła praca, a nie pojedyncze spotkanie - czasami lista uczestników się zmienia.
Czy OST może działać jako samodzielna technika czy idzie w parze z innymi?
Może działać jako samodzielna technika - podobnie jak Event Storming bez Domain-Driven Design. Zdobycie doświadczenia w wykorzystywaniu OSP docelowo pomoże nam podświadomie myśleć w stylu impact -> outcomes -> opportunities -> solutions-> experiments, nawet gdy nie będziemy rysować drzewa. Taki sposób myślenia często jest przydatny. Przypomina trochę inżynieryjną pracę nad dokumentami RFC (Request for Comments).
Należy jednak pamiętać, że jednym z poziomów OSP jest zapis cytatów usłyszanych bezpośrednio od naszych użytkowników lub interesariuszy. To właśnie te cytaty są podstawą budowania naszego rozumienia, podejmowania decyzji i priorytetyzacji. Dają nam one możliwość bazowania na faktach, a nie wyobrażeniach. Za praktyki bardzo bliskie OSP należy więc w konsekwencji uznać customer interviewing oraz research, czyli prostym językiem - zbliżenie się do użytkowników, rozmawianie z nimi i słuchanie tego, co mówią.
Dlaczego programiści powinni zainteresować się tą techniką?
Niektórzy mogą założyć, że temat OSP jest dedykowany dla product managerów, a przecież seria miała być o praktykach inżynieryjnych.
W książce Continuous Discovery Habits, praktyka ta jest prezentowana głównie na linii między Product Trio (Product+Design+Engineering) oraz klientami/użytkownikami. Warto jednak, aby programista rozumiał, dlaczego implementuje rzecz X, a nie Y z perspektywy produktowej, a nawet powinien być zaangażowany w podejmowanie tej decyzji. Wtedy może mieć większy wpływ na finalny kształt tego, co trafia na środowisko produkcyjne.
Brak zaangażowania inżynierów wobszar discovery może doprowadzać do następującej sytuacji:
- Product i Design dyskutują o najlepszym rozwiązaniu dla problemu.
- Trudno im ocenić techniczną wykonalność różnych rozwiązań.
- Powstają projekty interfejsu użytkownika.
- Propozycja rozwiązania w postaci linku do Figmy trafia do Engineering i tutaj mogą być dwie opcje:
- Lepsza: Na tym etapie pada od inżynierów pytanie, jaki problem rozwiązujemy. Wtedy inżynierowie proponują zmiany do rozwiązania, które potrafią lepiej lub łatwiej zaadresować dany problem. Zmiany są wprowadzane jeszcze na etapie koncepcji.
- Gorsza: Inżynierowie nie zadają pytania o problem. Rozwiązanie jest implementowane zgodnie z pierwotnym pomysłem. Przy wdrożeniu wychodzą trudności. Na końcu wszyscy uznają, że cel można było osiągnąć w inny, lepszy sposób.
W obu przypadkach tracimy czas na powrót do poprzednich etapów procesu, prawdopodobnie wydłużamy czas dostarczenia (time-to-market) i zwiększamy przyszły koszt utrzymania (maintenance cost).
Ponadto, jeżeli opisana wyżej sytuacja ma miejsce, to prawdą jest, że to nie Engineering tworzy techniczną architekturę systemu, a w większej mierze robi to Product i Design - nawet o tym nie wiedząc.
Programista, który zdobędzie umiejętności Product Discovery, zazwyczaj staje się nieprawdopodobnie wartościowym pracownikiem nie tylko na poziomie zespołu, ale i całej firmy. Taki inżynier staje się idealnym materiałem na Staff Engineera. Wymaga to jednak odejścia od myślenia jedynie o taskach, mikroserwisach, kolejkach i refactoringu (przynajmniej na tym etapie).
Czy OST można wykorzystać poza zespołami produktowymi?
Wejdźmy głębiej w strukturę organizacji, gdzie pracują Platform Engineerzy, oraz osoby ulepszające Developer Experience. Wydaje mi się, że najczęstszym błędem popełnianym przez zespoły platformowe i enablingowe jest dostarczanie rozwiązań na samodzielnie zdefiniowanie problemy. Tworzy to olbrzymie ryzyko wytwarzania rzeczy, które może i są fajne do zaprogramowania, ale nie są specjalnie przydatne.
Bardzo podobną sytuację można zaobserwować np. w zespołach frontendowych tworzących UI Design System. Brak regularnych rozmów z użytkownikami, nieumiejętne zadawanie pytań oraz niepoświęcanie czasu na własnoręczne użycie swojego produktu do zaimplementowania realnej funkcjonalności dla użytkownika końcowego sprawiają, że taki Design System jest tworzony bardziej dla siebie, a nie dla programistów, którzy mieliby z niego korzystać.
W 2017 roku w ThoughtWorks Technology Radar pojawił się obszar Applying product management to internal platforms. Wtedy mało kto to rozumiał, a i dzisiaj nie jest to powszechna praktyka. Myślę, że będąc inżynierem Platformy, DevEx lub dowolnego zespołu enablingowego, kolejną rzeczą po nauce technologii, w której się pracuje, powinna być nauka odkrywania potrzeb swoich użytkowników. Techniki przeprowadzania wywiadów, zadawania pytań, słuchania, strukturyzowania wiedzy, a także Opportunity Solution Tree pomogą w odpowiedniej priorytetyzacji tego, co zespoły pracujące na rzecz programistów będą realizować, tak aby ich praca zmieniała świat na lepszy.
Z twojej opowieści wynika, że OST można wykorzystać na bardzo wiele sposobów w swojej organizacji. Dzięki wielkie Rafał za fascynującą rozmowę.
