Inżynierski wkład w roadmapę produktu2023-08-02Cześć! W dzisiejszym newsletterze 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. A więc w dzisiaj mam dla Ciebie: Miłego czytania 😀 Przygotowałem też dla Ciebie garść bieżących materiałów, które pozwolą Ci pogłębić swoją wiedzę. Inżynierska PrasówkaDomain-Driven Design w praktyce — bezpłatny kurs DevMentors stworzyli kurs Domain-Driven Design Pragmatycznie. Materiały są dostępne bezpłatnie online. Idealna okazja do poszerzenia swojej wiedzy. Cloud Automation à la DDD: From stringly typed to affordances Gregor Hohpe (Enterprise Strategist z AWS) łączy tematy dookoła Domain-Driven Design i automatyzacji chmurowej. Gelling your Engineering leadership team Will Larson (autor książek o rolach inżynierskich) pisze, w jaki sposób zgrać ze sobą zespół inżynierski. Rzeczowe porady i dużo ciekawych przykładów. How to design software architecture Krótkie, ale treściwe podsumowanie tego, w jaki sposób projektować architekturę. On Becoming a VP of Engineering Emily Nakashima dzieli się spostrzeżeniami o swojej drodze do roli VP of Engineering. Interesujące, nawet w kontekście przechodzenia od roli Senior wyżej.
Inżynierski wkład w roadmapę produktuGdy organizacja skupia się na funkcjonalnościachJak wiele firm rozumie słowo „roadmapa"?
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:
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żyW 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.
Ok, a więc jak tego wszystkiego dokonać?
Roadmapa, a planPrzy 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:
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?
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 celachPraca 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:
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.
Roadmapa oparta o cele jest też bardzo wartościowa dla inżynierów – pozwala porównywać zadania funkcjonalne i techniczne.
Myślenie celami pozwala również lepiej zarządzać długiem (nie tylko) technicznym. Dług (techniczny?) w produkcieW wielu organizacjach produktowych pokutują dwa błędne przekonania dotyczące długu w produkcie:
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:
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:
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:
Ś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 onW 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ć:
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:
MateriałyPowyż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:
PodsumowanieNajwię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? 📧 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 :) |
