Inżynierski wkład w roadmapę produktu
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:
Inżynierski wkład w roadmapę produktu [TEN ARTYKUŁ]
W poprzednim wydaniu mówiliśmy o tym, jak sprawić by tworzone rozwiązania były ściśle połączone z celami organizacyjnymi. Dziś skupimy sie na tym, jak inżynierowie mogą współpracować z biznesem, aby wspólnie tworzyć lepszą roadmapę. Celem jest szerokie spojrzenie na produkt – zarówno od strony funkcjonalnej, jak i technicznej. Dzięki czemu długofalowo dowozimy lepsze produkty.
Gdy organizacja skupia się na funkcjonalnościach
Jak wiele firm rozumie słowo „roadmapa"?
Lista funkcjonalności do dostarczenia na kolejny rok.
Konsekwencją takiej perspektywy jest sytuacja, w której priorytetem jest wyprodukowanie kolejnych funkcji. W grudniu ustalamy, nad czym będziemy pracować przez cały kolejny rok. Mamy dowieźć X w Q1, Y w Q2, a Z w Q4. Nadchodzi styczeń, jesteśmy gotowi do startu. Biegniemy.
Gdzie tkwi haczyk? Zwykle zespoły zobowiązują się realizacji do zbyt wielu zadań (albo dostają je z góry). Pojawia się presja, by dostarczyć jak najwięcej i jak najszybciej. Zespoły dążą do szybkiego “odhaczania” kolejnych funkcji z listy. Priorytetem staje się więc “wyprodukowanie” kolejnej funkcji, zamiast głębszej analizy jej wartości i wpływu na użytkowników, czy biznes.
Organizacjom działającym w takiej strukturze brakuje długofalowej perspektywy. Zespół rozliczany wyłącznie z ilości dostarczonych funkcji zaczyna iść na skróty, bo w końcu liczy się więcej, a nie lepiej. W konsekwencji dług techniczny rośnie, a architektura systemu dziczeje. Jakość spada na łeb na szyję.
Gdzie tkwi paradoks? Choć tempo pracy jest wysokie, długofalowy wpływ na wskaźniki biznesowe jest negatywny. Coraz częściej zdarzają się awarie, a to przekłada się na odstraszenie aktualnych i potencjalnych klientów.
Im dalej brniemy w podejście oparte na funkcjonalnościach, tym więcej czasu musimy poświęcać na gaszenie pożarów. Tracimy przez to możliwości i zasoby na rozwiązywanie problemów biznesowych. Po jakimś czasie dochodzimy do momentu, gdy, jak mawia mój kolega z branży budowlanej:
„Biegamy z taczką, ale nie mamy czasu jej załadować."
Firmy z wysoką kulturą inżynierską postępują inaczej.
Jeśli nie funkcjonalności, to co?
Obserwując procesy wewnętrzne i u konkurentów, organizacje zaczęły zauważać, że skupienie na funkcjonalnościach jest krótkowzroczne i obarczone licznymi defektami. Zrozumiały, że trzeba postępować inaczej.
Szukając alternatywy, warto zacząć od powodów, dla których wprowadzamy daną zmianę w życie. Chodzi więc o skupienie się na celach biznesowych i produktowych. To one kierują naszymi pracami w ramach postępującego roku i to na ich podstawie możemy dobrać funkcjonalności pomagające je zrealizować.
Wbrew pozorom, na zmianie w kierunku celów skorzystają również inżynierowie. W codziennej pracy o wiele łatwiej jest priorytetyzować zadania techniczne, jeśli wiemy konkretnie, jak wpływają na cele organizacji. Możemy trafniej ocenić na czym najlepiej jest się skupić – dodać X, czy poprawić Y. Nagle pojawia się więcej argumentów pozwalających skupić się na jakości tworzonego rozwiązania.
Roadmapa bierze pod uwagę rzeczywiste możliwości naszego produktu i stara się odnieść do aspektów, które nie są takie, jak powinny. Działając w oparciu o nią, skupiamy się na rozwoju produktu w dłuższej perspektywie. Obejmuje to również część długu (technicznego, ale nie tylko).
W teorii brzmi to świetnie, ale czy ktoś tak w ogóle pracuje?
Przykład z branży
W porządku, chcielibyśmy przejść z podejścia opartego o funkcjonalności, na to koncentrujące się na celach. Pierwszym i najważniejszym krokiem jest stworzenie roadmapy opartej o cele. Więcej o tym jak ją wprowadzić w życie poniżej. Najpierw zapoznajmy się jednak z praktycznym przykładem od Marcina Cholewika – Engineering Managera z eSky.
Q: W jaki sposób pracujecie z roadmapą opartą o cele?
A: Nasza roadmapa zawiera inicjatywy, które są opisane tak, aby można łatwo zrozumieć ich wartość. Zamiast opisywać rozwiązania, wskazujemy cel, np: “zapewnienie wysokiej dostępności obiektów hotelowych” lub “zmniejszenie bounce rate na landing pages”. Następnie osoby biznesowe wspólnie z osobami technicznymi ustalają kroki, które doprowadzą nas do osiągnięcia celu. Dzięki takiemu podejściu zespół developerski jest świadomy jakie cele realizuje budując wybrane funkcje. Sama roadmapa towarzyszy nam podczas spotkań, m.in. prezentujemy i dyskutujemy o jej elementach w trakcie Sprint Review.
Q: Jakie benefity widzisz, w stosunku do roadmapy opartej o funkcje?
A: Dzięki roadmapie opartej o cele, wszystkie osoby biorące udział w wytwarzaniu oprogramowania mają szerszy kontekst. Jeśli któraś z funkcje nie prowadzi do osiągnięcia obranego celu, otrzymujemy feedback jeszcze przed realizacją zadania. Ponadto, roadmapa zawiera wszystkie prace realizowane przez zespół. Wystarczy jeden rzut oka, żeby mieć pełny obraz prac w zespole. W szczególności jest to przydatne do rozpoznania niepożądanych sytuacji, takich jak “wrzutki” prac niezwiązanych z celami, bądź zbyt duża ilość inicjatyw podejmowanych w tym samym czasie.
Ok, a więc jak tego wszystkiego dokonać?
Roadmapa, a plan
Przy każdej rozmowie o roadmapach, nieuchronnie pojawia się kwestia rozróżnienia roadmapy od planu. Te dwa, pozornie bardzo bliskie sobie pojęcia, określają przydatne, ale zdecydowanie odmienne narzędzia. Różnicę między jednym a drugim przystępnie tłumaczy Strategic Roadmap od Pavel A. Samsonov:
Z tą perspektywą zgadzają się autorzy książki Product Roadmaps Relaunched:
At the same time, a product roadmap should not be conflated with a project plan or a release plan (we cannot stress this enough).
Oba narzędzia są ważne i przydatne, ale ich charakterystyka i zastosowanie są zupełnie inne.
Co się dzieje, kiedy mylimy te pojęcia?
Zobowiązujemy się do wykonania zadań ponad nasze zasoby lub możliwości.
Brakuje nam możliwości elastycznego znalezienia lepszej alternatywy i eksperymentów mających na celu poprawę strony technicznej systemu.
Praca zaczyna przypominać fabrykę.
W dzisiejszych czasach organizacje produktowe z silną kulturą inżynierską w dużej mierze rezygnują z tworzenia planów wybiegających daleko w przyszłość. Dynamika wielu branż jest na tyle zmienna, że plany stworzone w grudniu, w marcu już się całkowicie dezaktualizują.
Roadmapa pozwala na większą swobodę w podejmowaniu decyzji już w ramach zapoczątkowanego procesu. W miarę upływu kolejnych tygodni i miesięcy podejmujemy decyzje, które dopiero wtedy zmieniają się w bardziej konkretne, krótkoterminowe plany.
Skupienie na celach
Praca z roadmapą to jedno. Jej format, to drugie. W dobrze skonstruowanej roadmapie, chcemy, aby funkcjonalności były tylko „poprzezem" – narzędziem, za pomocą których osiągamy cele. Albo nawet pozbywamy się ich całkowicie. 😬
Warto zainspirować się słowami Martiego Cagana z artykułu Product Roadmaps:
Product roadmaps … should reflect your current thoughts on which objectives are the most important. The roadmap is not intended to be a spec, and it’s not a laundry list of features.
Ciekawym przykładem takiej roadmapy jest struktura zapożyczona od Pawła Huryna. Można ją znaleźć np. w artykule Roadmaps & Avoiding Product Fiction:
W tym podejściu dzielimy perspektywę na Teraz, Następne i Dalej. Skupiamy się na określonych celach produktowych i możliwościach klienta (kliknij tu by poczytać więcej o celach-możliwościach-rozwiązaniach). To z ich pomocą wyznaczamy priorytety pracy. Czas na wypracowanie funkcjonalności przychodzi dopiero, gdy analizujemy cele do zrealizowania w najbliższej przyszłości.
Dla niektórych, brak informacji o inicjatywach, nad którymi pracujemy w ramach danego celu, może się wydać niepokojący. Aby temu zaradzić, można posłużyć się Theme-Based Roadmap:
W pracy skupiamy się na inicjatywach, które spełniają określone cele biznesowe lub produktowe. Dopiero na ich podstawie definiujemy zgrubnie propozycje rozwiązań. Wypracowywanie szczegółów rozpoczyna się, gdy już zabieramy się do rozpoczęcia pracy.
Jeszcze inną perspektywa dzieli się Radek Orszewski, Lean Agile Coach. W swoim artykule Jeśli mapa to nie rozkład jazdy autobusu, to czym jest roadmapa produktu?, dzieli się następującą roadmapą:
Jak widać, na jednej mapie zmieściło się kilka różnych aspektów pracy produktowej. Oczywiście są tu cele, ale znalazło się też miejsce na zdobywane doświadczenia czy aspekty architektoniczne.
Każda z tych roadmap na pierwszy rzut oka wygląda prosto. Może nawet niepokojąco prosto. 😃 Jednak w tej prostocie tkwi jej prawdziwa siła. Skupienie na celu ma liczne zalety, a dzięki zastosowaniu takiej perspektywy, od razu zobaczymy różnicę w bieżących pracach nad rozwiązaniami.
Jeśli istnieje prostsze rozwiązanie, porzucamy dotychczasową funkcję.
Znika presja dodawania funkcji na siłę — w momencie, gdy osiągamy cel, kończymy pracę.
Każdy nowy feature request jest walidowany w oparciu o nasze cele. Łatwiej unikać scope creep.
Roadmapa oparta o cele jest też bardzo wartościowa dla inżynierów – pozwala porównywać zadania funkcjonalne i techniczne.
Gdy myślimy tylko rozwiązaniami, zadania techniczne naturalnie wypadają gorzej – wykonujemy pracę, ale nie widać „niczego klikalnego".
Gdy myślimy celami, zadania funkcjonalne naturalnie można porównywać do zadań technicznych (i jakichkolwiek innych) – jak bardzo dane zadanie przybliża do celu.
Myślenie pod kątem celów pozwala też na bardziej wyrafinowane sposoby porównywania możliwości np. kosztem opóźnienia, czy pod względem krótko- lub długoterminowego zysku.
Myślenie celami pozwala również lepiej zarządzać długiem (nie tylko) technicznym.
Dług (techniczny?) w produkcie
W wielu organizacjach produktowych pokutują dwa błędne przekonania dotyczące długu w produkcie:
Dług produktu odnosi się jedynie do technicznej części produktu.
Są za niego odpowiedzialni inżynierowie.
Praktyka weryfikuje te stereotypy i udowadnia, że jest przeciwnie. Doskonale pokazuje to przykładowo prezentacja Einara Hosta, Technical debt isn’t technical.
Einar wskazuje na różne kategorie długu w produkcie:
Techniczne – narastające problemy programistyczne.
Biznesowe – zmiany modelu działania firmy, które nie zostały uwzględnione w produkcie.
Organizacyjne – problemy komunikacyjne czy strukturalne, które wpływają na produkt.
John Culter dokłada do tego jeszcze dług użytecznościowy – błędny model działania, do którego przyzwyczaił się klient, przez co zmiana jest problematyczna.
Każdy z powyższych rodzajów długu ma ogromny wpływ na produkt. Jednocześnie niemożliwa jest poprawa sytuacji bez bliskiej współpracy różnych ról w produkcie. Roman Pichler, w artykule Technical Debt and Product Success, pisze:
Intentionally compromising the code quality to get a release out and accepting technical debt is all good and well as long as you actually remove the debt afterwards. Often, however, technical debt is created unintentionally in my experience.
Zespół produktowy musi wspólnie podejmować decyzje kiedy dostarcza pewne rzeczy szybciej, poświęcając inne. Jednocześnie musi efektywnie zarządzać długiem, mając z tyłu głowy konieczność spłacenia go. W przeciwnym wypadku dług narasta i osiąganie celów biznesowych staje się niemożliwe.
Jedną z metod radzenia sobie z narastającym długiem jest jego odpowiednia wizualizacja. Pomaga ona:
Utrzymywać dług w ryzach.
Pokazać wpływ długu na nasze cele.
Świetny artykuł o takim podejściu opublikował Mathias Verraes na swoim blogu - The Wall of Technical Debt. Ciekawie pisze również o tym Pete Hodgson w Tech Debt Walls:
Dzięki wizualizacji długu i jego wpływu na produkt, łatwiej jest rozmawiać z naszymi interesariuszami o priorytetach w naprawie produktu.
Keep the lights on
W roadmapę warto też wkomponować elementy wymagane do utrzymywania całego produktu w ruchu. Ich widoczność służy za przypomnienie, że nie jesteśmy w stanie poświęcać 100% czasu na pracę stricte rozwojową.
Takimi aktywnościami mogą być:
Naprawianie błędów.
Usprawnienia techniczne.
Postępujący refactoring.
Pomysły na innowacje.
Praca z klientem.
Aby wyglądało to mądrze na roadmapie, możemy posłużyć się popularnymi nazwami dla tego rodzaju aktywności 😀:
Warto również wizualizować ogólny status produktu, aby nie wymknął się spod kontroli. Christina R. Wodtke, w książce Radical Focus, wspomina na przykład o Health Metrics:
Pick two to five things you want to protect as you strive toward greatness. What can you not afford to eff-up? Key relationships with customers? Code stability? Team well-being? Now mark when things start to go sideways and discuss it.
Materiały
Powyższy tekst jest tylko pigułką najważniejszych informacji w temacie.
Jeśli chcesz dowiedzieć się więcej, przygotowałem garść rekomendacji materiałów, które przybliżą Ci omawiane tematy:
Webinar “Roadmaps & Avoiding Product Fiction” - Paweł Huryn -
Książka “Product Roadmaps Relaunched” - https://www.amazon.com/Product-Roadmaps-Relaunched-Direction-Uncertainty/dp/149197172X
Artykuł “Engineering Planning” – Will Larson - https://lethain.com/planning/
Artykuł “Own the product, own the technical debt” - https://bootcamp.uxdesign.cc/own-the-product-own-the-technical-debt-4185b9f544a1
Podsumowanie
Największą zaletą wykorzystania roadmapy opartej o cele jest to, że zarówno zadania funkcjonalne, jak i techniczne są równomiernie pozycjonowane w ramach prowadzonych prac. Wtedy my, inżynierowie, jesteśmy w stanie ramię w ramię z biznesem tworzyć produkt. Ponadto jesteśmy w stanie walczyć z długiem w produkcie i długofalowo rozwijać projekt w pożądanym kierunku.
A jakie podejście dominuje w Twojej organizacji? Roadmapa = plan, czy jednak z tyłu głowy zawsze macie cele?
Drivery architektoniczne
W kolejnym wydaniu wydaniu na tapet bierzemy Drivery Architektoniczne. Dowiesz się, jakie problemy rozwiązują i w jaki sposób je definiować, a także wykorzystywać w pracy: