Cele -> Możliwości -> Rozwiązania
Praktyki Inżynierskie Najlepszych Firm Produktowych
Aby zebrać w jednym miejscu praktyczną i aktualną wiedzę dotyczącą praktyk inżynierskich, postanowiłem swoje doświadczenia zebrać w serii artykułów pod wspólną nazwą Praktyk Inżynierskich. Mam nadzieję że to kompendium będzie miejscem, do którego możesz wracać po wskazówki i rozwiązania.
W cyklu Praktyk Inżynierskich:
Cele -> Możliwości -> Rozwiązania [TEN ARTYKUŁ]
W poprzednim wydaniu cyklu rozpoczęliśmy temat od samych podstaw, czyli projektowania organizacji. Dziś poruszymy temat przekładania sił na zamiary.
Problemy rozpoczynania od funkcjonalności
Rozwiązania są czymś bardzo konkretnym i nietrudnym do zidentyfikowania. Łatwo się więc o nich myśli i rozmawia. Powoduje to, że większość naszych dyskusji skupia się głównie na funkcjonalnościach. Czy jest to podejście optymalne? Nie do końca. Tego typu polaryzacja rodzi sporo istotnych problemów. Jak to wygląda w praktyce?
W dyskusji na temat zmiany, zwykle pojawia się więcej niż jeden pomysł na to, co powinno zostać wdrożone. Stąd prosta droga do konfliktu. Interesariusze, nie mogą dojść do porozumienia, która z ich funkcjonalności powinna wejść pierwsza. Pojawia się MoSCoW do priorytetyzacji, ale wszyscy rzucają MUST.
Finalnie jeden pomysł wygrywa. Co dzieje się dalej? Rozpoczynamy walkę, by dowieźć daną funkcjonalność I wrzucić ją jak najszybciej na produkcję. Często pojawiają się nadgodziny lub zarwane noce. Dopiero po wielu trudach udaje się dowieźć funkcjonalność. I wtedy oficjalnie ogłasza się sukces. 🎁 Tylko czy na pewno się udało?
Przy wielu takich okazjach okazuje się, że wprowadzona funkcjonalność nie ma sensu. Nie adresuje żadnej potrzeby biznesowej. Nie dowozi celów naszej organizacji. Problem? Okazuje się to dopiero po fakcie.
Tak właśnie sukces w dowiezieniu rozwiązania, staje się porażką dla biznesu. To ostatecznie staje się również porażką inżynierów. 😿
Dzieje się tak, ponieważ po dowiezieniu rozpoczyna się długi proces zmiany rozwiązania. Bolesny szczególnie dla inżynierów – przeważnie trzeba zmieniać istniejące funkcjonalności i kroić wszerz architekturę produktu. Następują brutalne zmiany.
Firmy produktowe z wysoką kulturą inżynierską postępują inaczej.
Szersza perspektywa
Organizacje ze sznytem inżynierskim skupiają się na tym, aby tworzone rozwiązania były ściśle połączone z celami organizacyjnymi. Rozpoczęcie od celów sprawia, że trudniej jest dowozić funkcjonalności, które nie są skoncentrowane na celach organizacyjnych.
Jednak aby tak się stało, muszą się spotkać ze sobą 2 strony – biznesowa i techniczna 🧑💼👷♂:
Organizacja musi jasno komunikować cele produktowe, które mają być realizowane. Wymaga to zrozumienia po co w zasadzie wykonujemy zmiany w produkcie.
Inżynierowie muszą za to przekładać cele na konkretne funkcjonalności, które te cele skutecznie zrealizują. Wymaga to nie tylko umiejętności technicznych, ale także „szerszej perspektywy", obejmującej cały produkt. Zrozumienia pracy danego produktu oraz klientów.
Aby uprościć przeniesienie Cele -> Rozwiązania, firmy inżynierskie skupiają się przede wszystkim na zachowaniach klientów. Starają się określić jakie możliwości posiadamy, aby zmienić te zachowania. Przez dodanie kroku pośredniego Cele -> Możliwości -> Rozwiązania, łatwiej nam jest definiować skuteczne rozwiązania.
Ostatecznie, pracujemy zarówno w części wyboru rozwiązania (Discovery) jak i dostarczania (Delivery), aby dostarczać wartościowe funkcjonalności.
To wszystko wygląda skomplikowanie, ale zapewniam Cię - zaraz to uprościmy. 😃
Przykład z branży
Ciekawym case study pracy od celów do rozwiązań podzielił się Rafał Makara – Senior Engineering Manager w DocPlannerze. Opowiedział o wykorzystaniu techniki Opportunity Solution Tree (opisanej w skrócie w kolejnych punktach):
Q: W jaki sposób wykorzystujecie w DocPlannerze OST?
A: Grupa złożona z product managera, researcherów, product designerów oraz inżynierów spotyka się cyklicznie w ramach discovery. Na wirtualnym white boardzie umieszczają całą wiedzę jaka może im pomóc w znalezieniu sposobu wpłynięcia na daną metrykę biznesową. Podczas porządkowania i analizowania tej wiedzy rysowane jest drzewo (lub drzewa) Opportunity Solutions Tree. Dla możliwości na które postawimy, staramy się wypracować kilka (minimum 2) pomysłów na rozwiązania.
Q: Jakie zalety ma dla was OST?
A: OSP 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 duże prawdopodobieństwo, że proces byłby chaotyczny, pełen błędów poznawczych, wybieralibyśmy 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.
A więc jak spinać ze sobą rozwiązania i cele biznesowe, aby jedno wpływało na drugie?
Cele / możliwości / rozwiązania
Warto rozpocząć od dobrych definicji.
Cele
Tym, od czego warto rozpoczynać dyskusję, są cele naszej organizacji i naszego produktu. Przykład z obszaru e-commerce:
Cele biznesowe – skupione na metrykach organizacji. Np. zwiększenie wolumenu sprzedawanych produktów.
Cele produktowe – skupione na działaniu konkretnego produktu. Np. zwiększenie konwersji w procesie zakupowym.
To jest azymut naszych rozwiązań. Rozwiązania muszą się wpasowywać w te cele. Jeśli nie mamy zdefiniowanych i zrozumiałych celów w zespole, to jest mała szansa, że rozwiązania będą spełniać te cele.
Możliwości
Kolejnym poziomem są możliwości (inną spotykaną nazwą może być wpływ lub cel klienta). Jest to szansa, jaką chcemy wykorzystać, aby zmienić zachowanie naszego ostatecznego klienta. Ta zmiana powinna realizować określone cele produktowe.
Dzięki temu poziomowi oddzielamy:
jaki wpływ chcemy wywrzeć na użytkowniku,
od tego, jakie rozwiązanie dowiezie ten wpływ.
Brak rozróżnienia powoduje, że trudniej nam jest rozmawiać, które rozwiązanie lepiej zaadresuje dany cel. Jeśli mamy rozwiązanie A i B, to potencjalnie każde z nich może pomóc w realizacji celu. Jednak tylko A może zrealizować najważniejszą możliwość.
Rozwiązania
Dopiero na końcu powinny się znaleźć rozwiązania. Jest to techniczna zmiana w naszym produkcie, która sprawi, że klient zmieni swoje zachowanie. Nasze dowożone funkcjonalności powinny realizować najważniejsze możliwości, aby osiągać najważniejsze cele. Tylko jak wybrać te najważniejsze cele i możliwości? 🤔
Rozpoczynanie od celów
Bardzo dobrą sytuacją jest, gdy nasza organizacja już wykorzystuje cele w swojej codziennej pracy. Jednak z mojego doświadczenia to jest rzadkość.
Zwykle dowozimy funkcjonalności, ale nie wiemy dokładnie jakie cele powinny one spełniać. Czas to zmienić.
Wszystko to, co opisuję poniżej, jest czynnością grupową – nie powinniśmy tego wykonywać samemu. Cele warto wypracować wspólnie, z jak największą ilością interesariuszy. Jeśli to nie jest możliwe, to przynajmniej warto ich powiadomić o naszych decyzjach.
Cele biznesowe
Cele biznesowe zwykle są związane z wskaźnikami pracy organizacji. Takim wskaźnikiem może być na przykład:
wzrost przychodów,
niższe koszty eksploatacji,
wzrost udziału w rynku,
zwiększenie marży zysku,
zmniejszenie współczynnik rezygnacji.
Wyniki biznesowe pozwalają interesariuszom śledzić postępy firmy.
Sposobem, aby określić istotne dla nas cele biznesowe jest zadanie sobie następujących pytań:
Na jakich aspektach naszej firmy powinniśmy się skupić najpierw?
Które wskaźniki są kluczowe na kolejny kwartał/rok?
Warto zwrócić uwagę na to, że bardzo trudno jest jednocześnie optymalizować wszystkie wskaźniki biznesowe w ramach naszej pracy produktowej. Wybranie 1 lub 2 priorytetowych celów biznesowych jest kluczowe, aby faktycznie dowieźć zmianę w takim wskaźniku.
Cele produktowe
Jako zespół produktowy, nie powinniśmy pracować bezpośrednio nad celami biznesowymi. Jest to błąd, ponieważ zespoły produktowe mają jedynie pośredni wpływ na cele biznesowe. Jak mamy bezpośrednio wpłynąć przykładowo na wzrost przychodów? Co, jeśli po naszych zmianach przychody spadły, ale nie było to związane z naszymi działaniami?
Nie jest to wyłącznie moje spostrzeżenie. Tak opisuje to również Terresa Torres pisząc, aby skupiać prace zespołu na celach produktowych. Wspomina o tym również Tim Herbig w ramach kaskadowania OKRów:
Dlatego w ramach zespołu powinniśmy mieć zdefiniowane cele produktowe, czyli określone wskaźniki dla zachowań naszych klientów. To jest aspekt, który znajduje się w zasięgu zmiany zespołu produktowego.
Sposobem, aby zdefiniować takie cele, jest zadanie sobie pytania:
Jakie zachowania użytkowników wpływają na cele biznesowe?
To pozwoli nam znaleźć istotne korelacje pomiędzy naszym biznesem, a pojedynczym produktem. W przypadku poprzednio wspominanego poprzedniego przykładu ecommerce, będzie to wyglądać następująco:
Cel biznesowy - sprzedaż produktów zwiększenie zysków o 10% w skali roku.
Cele produktowe - konwersja w procesie sprzedaży:
Zwiększenie zawartości koszyka o 20%.
Zmniejszenie odrzuceń klientów na poziomie procesu zamówienia o 15%.
Nie zawsze musimy mieć tak dokładnie wyznaczone wskaźniki sukcesu naszych celów, ale jest to zdecydowanie wskazane. Inaczej trudno określić, czy to, co dowieźliśmy to jest sukces, czy jednak nie 😃.
Najważniejsze możliwości
Wiedząc, jakie cele chcemy osiągnąć, możemy się skupić na możliwościach. Z czego wynika zastosowanie tego dodatkowego kroku?
Samo rozwiązanie nie realizuj dla nas celu. Ten dostarczają nasi klienci. To oni zmieniają swoje zachowanie, sprawiając, że cel jest zostaje osiągnięty. Rozwiązanie jest tutaj tylko „zapalnikiem" – to klienci „odpalają lont".
W przypadku naszego celu „Zwiększenie zawartości koszyka o 20%" takimi zmianami może być na przykład:
Dodawanie kolejnych produktów do koszyka.
Kupowanie większej liczby produktów już dodanych do koszyka.
Zamiana produktów na droższe odpowiedniki.
Nasze rozwiązania rzadko będą jednocześnie powodowały wszystkie te zmiany zachowania naraz. Kluczowe jest, aby wybrać najważniejszą z nich.
Dlatego warto najpierw skupić się na zmianie zachowania klienta, a później dopiero na rozwiązaniu.
Aby przeprowadzić dyskusję na temat zmiany zachowań klientów mogę polecić 2 techniki:
Opportunity Solution Tree (już wspomnianą przez Rafała)
Obie te techniki określają różnymi słowami w zasadzie to samo – zmianę zachowania naszego aktora, które ostatecznie wpłynie na nasz cel biznesowy. Każdą zmianę zachowania zapisujemy osobno. Następnie dyskutujemy, która zmiana ma największą szansę dowieźć dany cel.
To co jest istotne: nie pracujemy nad rozwiązaniami, dopóki nie wybierzemy najważniejszych możliwości / wpływów. Świadomie opóźniamy tą fazę, aby nie skakać zbyt wcześnie do funkcjonalności.
Po takiej dyskusji powinniśmy mieć 2-3 możliwości, z którymi rozpoczniemy pracę dalej.
Inżynierowie definiują rozwiązania
Pojawia się pytanie – dlaczego inżynierowie mają brać udział w całym opisanym wyżej procesie? . Dlaczego nie dostawać planu rozwiązania do zaimplementowania? Przecież to byłoby o wiele szybsze.
Marty Cagan, autor książki o tematyce zespołów produktowych,Empowered, na prezentacji Product San Francisco powiedział:
Consistently the best single source of ideas is your engineers. It’s because they’re working with technology every day and they’re in the best possible position to see what’s just now possible.
I ja się z tym bardzo mocno zgadzam.
To my jesteśmy najlepszym źródłem pomysłów. Jako inżynierowie rozumiemy, co jest możliwe do wykonania. W 80% wypadków to technologia ogranicza nasze potencjalne rozwiązania. A więc jeśli dobrze rozumiemy:
zarówno cele biznesowe i produktowe,
jak i ograniczenia i techniczne,
to jesteśmy w stanie te dwa światy pogodzić ze sobą.
Dlatego inżynierowie powinni współpracować z ze specjalistami o innych rolach, aby określać najlepsze rozwiązania do dostarczenia.
Eksperymenty
W tym momencie kluczowe jest ograniczanie zakresu dostarczanego rozwiązania. Nie chcemy dostarczać zbyt dużego rozwiązania naraz. Koszt zawracania później będzie zbyt duży. I każdy developer narzeka, że wyrzuca się jego kod. 😅
Popularną techniką, która może posłużyć do sprawdzenia w których miejscach powinniśmy się skupić jest, Assumption Mapping.
Jest to technika, której używamy, by:
Określić jakie mamy założenia dotyczące pracy naszego klienta w naszym rozwiązaniu.
Zmapować je na dwa wymiary – Ważność i Pewność.
Wybrać założenia ważne i nieznane jako pierwsze do sprawdzenia.
Jeśli chcesz zgłębić ten temat, zapoznaj się z ubiegłym wydaniem newslettera - 5 technik podziału funkcjonalności na mniejsze. Moją ulubioną jest oczywiście Event Storming. Za pomocą alternatywnych ścieżek możemy okroić daną funkcjonalnosć do minimum.
Proces discovery i delivery
Możesz teraz zadać pytanie „Skąd mieć czas na taki wybór analizę? Przecież jest taki nacisk by dostarczać ficzery". Moja odpowiedź jest taka:
To właśnie przez zbyt duży nacisk na dowożenie bezużytecznych funkcjonalności, nie mamy czasu dowozić rzeczy sensownych.
Wybór tego, co dowieźć, jest tak samo ważny jak samo dostarczenie finalnego produktu.
W głowie może Ci się pojawić kolejne pytanie: „Czy to nie brzmi jak Waterfall? Najpierw analizujemy bardzo dużo, by później wypluwać rozwiązania?"
Tutaj powołam się na słowa Jeffiego Pattona, twórcy techniki User Story Mapping:
Discovery work happens concurrently and continuously with development work.
Dlatego Continuous Delivery łączy się z Continuous Discovery. Zespół pracuje równocześnie nad analizą rozwiązań do dostarczenia i ich dostarczaniem. Często przybiera to formę Dual Track Developmentu:
Poszczególne pomysły przechodzą z obszaru Discovery do faktycznej realizacji w obszarze Delivery. Skupiamy się na tych pomysłach, które mają dla nas największą wartość biznesową.
Często taka taki proces pracy ma również kształt Upstream/Downstream Kanbana:
Mamy wspólną tablicę zespołową na pracę odkrywania i dostarczania funkcjonalności. Zespół balansuje czas poświęcany na pracę Discovery i Delivery podczas sprintu. Dzięki temu zyskuje stabilne tempo dostarczania.
Warto pamiętać przy tym, że w zależności od sytuacji produktowej możemy położyć większy nacisk na:
Discovery - otwieramy nowy obszar, zmieniły się cele, środowisko biznesowe ewoluowało.
Delivery - optymalizujemy dane rozwiązanie, maksymalizujemy zyski, stabilizujemy procesy.
Nasze podejście jako inżynierów musi się do tego dostosować.
Materiały
Powyższy tekst jest tylko ogólnym wprowadzeniem w pigułce.
Jeśli chcesz dowiedzieć się więcej, zachęcam do sięgnięcia po dodatkowe materiały, które przybliżą Ci omawiane tematy:
Business Outcomes vs Product Outcomes - https://www.linkedin.com/posts/pawel-huryn_everyone-is-talking-about-the-outcomes-activity-7056203382453112832-yWTC/
Opportunity Solution Tree - https://www.producttalk.org/opportunity-solution-tree/
Książka Impact Mapping -
https://www.impactmapping.org/
Książka Continuous Discovery Habits - https://www.amazon.com/Continuous-Discovery-Habits-Discover-Products/dp/1736633309
✂ 5 technik podziału funkcjonalności na mniejsze - https://radekmaziarka.pl/nl/DBF78D05-88C6/
Dual Track Development - https://jpattonassociates.com/dual-track-development/
Podsumowanie
Organizacje produktowe z silną kulturą inżynierską nie marnują czasu na dowożenie byle jakich funkcjonalności. Zamiast tego, skupiają się na osiąganiu kluczowych celów. To sprawia, że dowożą rozwiązania tam, gdzie jest to najbardziej wartościowe dla biznesu. Dostarczają mniej, ale zdecydowanie lepiej.
A jak wygląda sytuacja w Twojej organizacji? Przeważa górka “ficzerów”, czy raczej konkretne cele do realizacji?
Inżynierski wkład w roadmapę produktu
W kolejnym wydaniu wydaniu opowiadam o tym, jak inżynierowie mogą współpracować z biznesem, aby wspólnie tworzyć lepszą roadmapę: