Cele -> Możliwości -> Rozwiązania2023-07-05Cześć! Witaj w kolejnym odcinku Najlepszych Inżynierskich Praktyk Firm Produktowych. Dziś na tapet bierzemy: Cele -> Możliwości -> Rozwiązania A więc w dzisiaj mam dla Ciebie: Miłego czytania 😀 Cele -> Możliwości -> RozwiązaniaProblemy rozpoczynania od funkcjonalnościRozwią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 perspektywaOrganizacje 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 🧑💼👷♂:
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żyCiekawym 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):
A więc jak spinać ze sobą rozwiązania i cele biznesowe, aby jedno wpływało na drugie?
Cele / możliwości / rozwiązaniaWarto rozpocząć od dobrych definicji.
Cele Tym, od czego warto rozpoczynać dyskusję, są cele naszej organizacji i naszego produktu. Przykład z obszaru e-commerce:
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:
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ówBardzo 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:
Wyniki biznesowe pozwalają interesariuszom śledzić postępy firmy. Sposobem, aby określić istotne dla nas cele biznesowe jest zadanie sobie następujących pytań:
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:
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:
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ściWiedzą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:
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:
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ązaniaPojawia 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ł:
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:
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. EksperymentyW 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:
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 deliveryMożesz teraz zadać pytanie „Skąd mieć czas na taki wybór analizę? Przecież jest taki nacisk by dostarczać ficzery". Moja odpowiedź jest taka:
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:
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:
Nasze podejście jako inżynierów musi się do tego dostosować. MateriałyPowyż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:
PodsumowanieOrganizacje 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? 📫Poprzednie wydania newsletteraWszystkie archiwalne edycje newslettera trafiły już na moją stronę! Dzięki temu nie musisz już przeszukiwać poczty, aby dostać się do poprzednich materiałów. Bazę wszystkich artykułów znajdziesz tutaj - lista newsletterów. Polecane wydania:
📧 Prześlij dalejDzięki, że doczytałeś(aś) do końca. 😊 Wszystkie poprzednie wydania newslettera są dostępne tutaj. Jeśli spodobał Ci się mój newsletter, prześlij go proszę osobom, którym też mógłby się spodobać. Z góry dziękuję. A jeśli nie jesteś jeszcze w newsletterze, to zachęcam do zapisania się. Polecam się na przyszłość!  "Inżynierskie podejście do produktów cyfrowych." P.S. Co myślisz o tym newsletterze? Odpisz :) |
