W dzisiejszym świecie wytwarzania oprogramowania, coraz częściej mówi się o tworzeniu produktów zamiast o realizacji projektów. Wiele firm rezygnuje w swoich strukturach organizacyjnych ze stanowisk kojarzonych z zarządzaniem projektami a zamiast nich pojawiają się role takie jak Product Owner czy Product Manager. Czym jest podejście produktowe i skąd bierze się jego rosnąca popularność?
Produkt vs. projekt
Zacznijmy od wyjaśnienia na czym polega różnica: według ogólnej definicji, projekt jest to tymczasowe przedsięwzięcie, które ma na celu stworzenie unikalnej usługi lub produktu. Produktem zaś jest wszystko to, co można zaoferować na rynku nabywcom i co jest w stanie zaspokoić ich określoną potrzebę lub pragnienie.
Jak wynika z przytoczonych definicji, pojęcia te nie są przeciwstawne, a raczej komplementarne. Skąd zatem próba odgrodzenia i wydzielenia od siebie tych podejść? Różnica jest subtelna, aczkolwiek zasadnicza: polega ona, przede wszystkim, na podkreśleniu naszego skoncentrowania na kliencie i problemach biznesowych, które nasze oprogramowanie ma rozwiązywać w przypadku tworzenia produktów. Kolejną istotną różnicą jest tymczasowość zawarta w definicji projektu, która często wymusza podejmowanie taktycznych decyzji prowadzących do szybkiego uzyskania korzyści. W niektórych przypadkach takie działanie może prowadzić do sukcesu, natomiast budowanie produktu to proces długotrwały i krótkowzroczne decyzje prędzej czy później odbijają się na jakości, rosnącym długu technicznym czy też spadku poziomu satysfakcji wśród użytkowników.
W podejściu produktowym, kryteria, które zwykle przyjmujemy dla określenia sukcesu projektu również przestają mieć znaczenie, ponieważ w mniejszym stopniu zależy nam na dostarczeniu całego zakładanego inicjalnie zakresu prac. Nie będziemy również starali się utrzymać harmonogram prac za wszelką cenę, ponieważ nadrzędnym celem jest zaspokojenie konkretnej potrzeby klienta oraz jego satysfakcja. Jak wpływa to na poszczególne etapy cyklu wytwarzania oprogramowania?
Planowanie
Jak mawiał Peter Drucker: „Nie ma nic bardziej nieefektywnego niż robienie efektywnie czegoś, co nie powinno być robione wcale”. Odzwierciedlenie tej myśli znajduje się również w jednej z Dwunastu Zasad Zwinnego Tworzenie Oprogramowania: „Prostota – sztuka minimalizowania ilości koniecznej pracy – jest kluczowa”. Brzmi jak oczywista oczywistość, natomiast, w praktyce, cała trudność polega na odgadnięciu, które funkcjonalności oprogramowania zachęcą odbiorców do korzystania z danego produktu i polecania go innym użytkownikom. Zamiast przechodzić od razu do planowania funkcjonalności czy też architektury systemu, w podejściu produktowym staramy się najpierw dobrze zrozumieć: kim będą odbiorcy naszego produktu oraz czemu ma służyć nasze oprogramowanie. W odpowiedzi na te dwa podstawowe pytania mogą nam pomóc dwa artefakty: wizja produktu oraz persona, reprezentująca typowego użytkownika. Dobrze nakreślona wizja opisuje jaki ma być sens istnienia naszego produktu, jest spojrzeniem w przyszłość i pokazaniem, jaki pozytywny wpływ chcemy mieć na otoczenie. Stworzenie wizji produktu pomoże nam zdefiniować, jakie wrażenia chcemy uzyskać u naszych odbiorców w trakcie interakcji z naszym oprogramowaniem.
Idealnym narzędziem do połączenia wizji, persony oraz interakcji może być tzw. Podróż Użytkownika (Customer Journey). Obrazuje ona na jednej linii czasu, jakie funkcjonalności mają wywołać u użytkowników oczekiwane emocje i zachowania na poszczególnych etapach użytkowania oprogramowania. Pomoże nam to również w zbudowaniu mapy drogowej funkcjonalności naszego nowego produktu i sprawi, że wszystkie osoby zaangażowane w tworzenie produktu lepiej zrozumieją kim są odbiorcy danego systemu i jakie są ich potrzeby.
Prototypowanie
Kiedy mamy już zdefiniowaną wizję oraz obraną strategię na podbicie serc użytkowników, nadchodzi czas na zweryfikowanie naszych hipotez.
Obecne narzędzia do prototypowania (jak UXPin, InVsion) pozwalają na stworzenie w pełni funkcjonalnego, interaktywnego interfejsu użytkownika w bardzo krótkim czasie. Dzięki temu szybko jesteśmy w stanie zweryfikować nasze hipotezy (zawarte np. w Podróży Użytkownika) z reprezentatywną grupą odbiorców. Kilka iteracji pozwala określić czy obrany kierunek odnośnie do wyglądu i zachowania poszczególnych funkcjonalności jest zgodny z oczekiwaniami odbiorców. Poprawiamy prototyp zgodnie z uwagami i dopiero gdy zyskamy aprobatę inicjalnych użytkowników, przechodzimy do kolejnej fazy. Dzięki temu unikniemy ryzyka polegającego na zainwestowaniu czasu na budowanie niepotrzebnych funkcjonalności bądź nieintuicyjnych rozwiązań.
Praca z prototypami ułatwia także komunikację z przedstawicielami biznesu i sprawia, że osoby reprezentujące odbiorców są zaangażowane w proces powstawania naszego oprogramowania od samego początku. Dużo łatwiej jest odnosić się do wizualnego prototypu niż, na przykład, do wymagań funkcjonalnych w formie dokumentu tekstowego. Sprawia to, że wartość uzyskanych informacji na temat powstającego produktu jest dużo wyższa. Prototypowanie ma również bardzo pozytywny wpływ na pobudzenie innowacji, ponieważ angażujemy w proces kreowania produktu dużo szerszą grupę ludzi o różnych umiejętnościach, spojrzeniach i doświadczeniu. Osoby te mogą wyrazić swoje odczucia bezpośrednio po interakcji z prototypowym produktem bez potrzeby posiadania wiedzy technicznej czy też umiejętności związanych z zarządzaniem wymaganiami. Wsłuchanie się w bolączki pierwszych użytkowników naszego produktu oraz ich sugestie co do zachowania interfejsu zaoszczędzą nam kosztownych poprawek na późniejszych etapach produkcji oraz zwiększą szanse na rynkowy sukces.
Realizacja
W podejściu produktowym, bardzo często stosujemy podejście Feature Driven Delivery (FDD), czyli przyrostowe wytwarzanie wartościowych biznesowo funkcjonalności systemu. Polega to na dekompozycji produktu na użyteczne z punktu widzenia końcowego odbiorcy funkcjonalności, po czym następuje priorytetyzacja pod względem wartości biznesowej. Co istotne, stworzony w ten sposób rejestr produktu zawierać powinien opis oczekiwanego zachowania systemu, a nie technicznych zadań do realizacji. Powstały we wcześniejszej fazie prototyp również stanowić będzie doskonałą dokumentację, lepiej obrazując oczekiwane zachowanie i wygląd danej funkcjonalności systemu.
Wytwarzanie i dostarczanie oprogramowania również odbywają się na zasadzie dodawania kolejnych, w pełni działających funkcjonalności do tych już istniejących. Zespół (lub zespoły) pracują zwykle w trwających od jednego do czterech tygodni iteracjach, po czym następuje prezentacja i weryfikacja efektów pracy i wydanie nowej funkcjonalności na rynek bądź wyselekcjonowanej grupie użytkowników.
Fot. buildit@wipro digital
Fot. buildit@wipro digital Przykład persony i prototypu interfejsu użytkownika.Organizacja zorientowana produktowo
Aby taki model dostarczania poszczególnych funkcjonalności oprogramowania „w kawałkach” działał sprawnie, niezbędne jest zapewnienie wysokiej jakości (testy automatyczne) i sprawności procesu produkcji oprogramowania (CI/ CD). Transformacja organizacji na podejście produktowe wymusza zwykle zmiany organizacyjne. Konieczne jest zbudowanie trwałych, interdyscyplinarnych zespołów zdolnych do efektywnego dostarczania funkcjonalności, które często będą przechodziły przez wszystkie warstwy oprogramowania i dotykały wielu obszarów biznesowych. W podejściu projektowym, koszty powodowane przez tak daleko idące zmiany byłyby zwykle nie do zaakceptowania, jeśli weźmiemy pod uwagę wspomniany wcześniej tymczasowy charakter projektu.
Zaletą wydawania oprogramowania w podejściu FDD jest możliwość szybszego wejścia na rynek. Ceną jednak będzie nie jakość, lecz zredukowana funkcjonalność dostarczonego produktu. Ograniczymy też marnotrawstwo związane z budowaniem niepotrzebnych funkcjonalności poprzez wyeliminowanie ich na etapie planowania wartości produktu. Wczesne zebranie opinii użytkowników a także wymuszenie wysokiej sprawności procesu produkcji oprogramowania pozwala zrozumieć i odpowiedzieć na potrzeby klientów szybciej, zdobywając tym samym przewagę nad konkurencją.
Podsumowanie
Podejście produktowe z pewnością nie zastąpi całkowicie zarządzania projektami w obszarze wytwarzania oprogramowania. W sytuacjach, gdy budżet i harmonogram są fundamentalne, nadal lepiej sprawdzi się podejście projektowe. Gdy jednak naszym celem jest stworzenie produktu, który pokochają rzesze użytkowników, to warto przestawić organizację na myślenie produktowe i zgłębić narzędzia wspierające budowanie wartości produktów. Co istotne, przedstawione techniki sprawdzą się nie tylko przy wprowadzaniu nowych, innowacyjnych produktów na rynek. Możemy z nich korzystać również, gdy planujemy odświeżyć istniejący system bądź aplikację. Pomoże nam to wyznaczyć najistotniejsze funkcjonalności i aktualizować je jedna po drugiej – mniejszymi środkami i bez konieczności czekania aż cały zakres prac będzie zakończony.
Certyfikowany Project Manager PMP® oraz Scrum Master. Od ponad 10 lat zawodowo zaangażowany w tworzenie oprogramowania. Przez ten czas pełnił role Dewelopera, Testera, Scrum Mastera i Program Managera. Obecnie pracuje jako Delivery Consultant w Buildit@wipro digital, gdzie wykorzystuje swoją wiedzę z zakresu zwinnego zarządzania projektami aby transformować organizacje i pomagać klientom bardziej efektywnie wykorzystywać najnowsze technologie IT. Współtwórca gry symulacyjnej ScrumTale oraz trener i autor szkoleń z zakresu Agile, Scrum i Kanban w AgileBrains.