Full Cycle Product Development

Krzysztof Kempiński
Jun 29 · 10 min read

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Mateuszem Rośkiem o full cycle product development.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

Cześć! Gość dzisiejszego podcastu swoją historię z product developmentem zaczął dziesięć lat temu w Boldare, gdzie pracuje zresztą do dziś. Specjalizuje się głównie w technologiach back-endowych, zwłaszcza PHP. Swoje doświadczenie zbudował zarówno na skalowalnych systemach, na przykład dla BlaBlaCar, jak i na szybkich produktach, których celem był time-to-market. Sprawuje rolę software architekta, PHP dewelopera i człowieka do pomocy. Chętnie dzieli się swoją wiedzą zarówno w firmie, jak i poza nią, angażując się w rozwój śląskiego community PHP-ersów. Moim i Waszym gościem jest Mateusz Rosiek.

Cześć, Mateuszu! Miło mi gościć Cię w podcaście.

Cześć, wszystkim! Również miło mi gościć w tym podcaście. Bardzo chętnie porozmawiamy sobie o dzisiejszym temacie.

A tym tematem będzie Full Cycle Product Development, czyli ugryziemy trochę takiego iteracyjnego, agile’owego podejścia do tworzenia produktu, zarówno od strony produktu jako takiego, jak i ról technicznych, które na różnych etapach są potrzebne. Ale rozpocznę standardowym elementem każdego podcastu, czyli zapytam Cię, Mateuszu, czy słuchasz podcastów? Jeśli tak, to może masz listę swoich ulubionych, którymi będziesz w stanie się podzielić.

To jest fajne pytanie. Powiedz mi, czy interesują Cię tylko podcasty IT czy wszystkie?

Nie, absolutnie wszystkie.

Wszystkie. Tak na dobrą sprawę, jeśli chodzi o samą tematykę IT, to mam kilka swoich ulubionych podcastów i jest to na pewno Better Software Design od Mariusza Gila, InfoQ Podcast i tematyki w okolicach Piątków po deployu. Poza IT, w zasadzie lekko stronniczy Naukowy Bełkot i Raport o stanie świata, też trochę naukowy. Natomiast jeśli chodzi o rzeczy stricte związane z IT i biznesem, to bardziej jestem człowiekiem tematu i szukam rzeczy, które są wypuszczane na dany temat. W moim feedzie różnych źródeł wiedzy mam ze czterdzieści, pięćdziesiąt różnych podcastów i po prostu śledzę, co jest w tym momencie na topie albo co mnie się najbardziej teraz podoba.

Świetnie, czyli słyszę, że też jesteś uzależniony, podobnie, jak ja, ale faktycznie nie da się wszystkich odcinków słuchać. Ja podobnie, raczej wybieram sobie tematy, ale dosyć szeroko również wypełniam listę audycjami.

Na początku chciałbym Cię zapytać o definicję albo o różnicę pomiędzy tym, co mamy na myśli mówiąc o produkcie, a co mamy na myśli mówiąc o projekcie. Często w firmach wytwarzających produkty cyfrowe, w szczególności oprogramowanie, mówi się o realizowaniu projektów, to jest takie modne. Mówi się też o produktach, ale bardziej kiedy idziemy w kierunku startupów. Czy te pojęcia są według Ciebie tożsame? Jeśli nie, to jaka jest różnica pomiędzy projektem a produktem?

To jest fajne pytanie, szczególnie w kontekście branży IT, świata deweloperów, gdzie w głównym nurcie konferencyjnym przejawia się obraz Domain-Driven Design, UbiLang i trzymania wspólnego języka komunikacyjnego, a na takich codziennych pojęciach potrafimy sobie robić aż tak duże różnice. I faktycznie czuję też, że w naszym świecie IT pojęcia projektu i produktu bardzo często są traktowane, jak jedno i to samo. Osobiście bardzo lubię sobie spojrzeć na tematy projektów i produktów przekładając to trochę na życie codzienne. Z pewnego punktu widzenia, jak patrzę chociażby na swój dom, to ten mój dom, to jest produkt, który buduję. Buduję ten produkt realizując różne projekty, będące na różnych etapach, zależnie od tego, który element swojego produktu aktualnie rozwijam. Rzeczywiście, z mojego punktu widzenia, są to różne pojęcia.

To jest dosyć ciekawe, bo kiedy mówimy o programowaniu, czyli czymś trochę nieuchwytnym, to ta różnica może się zacierać. Produkt rozumiany jako coś fizycznego, jako dom, jest dużo łatwiejszy do ogarnięcia, do zrozumienia, natomiast projekt jest czymś cyfrowym, trochę ulotnym, mam wrażenie, stąd to się może faktycznie zacierać.

Zależy w jaki sposób ukierunkujemy sobie myśli w głowie. Już jakiś czas temu, we wszystkich swoich rzeczach, które realizuję w firmie, staram się na wszystko właściwie patrzeć jak na produkt i dopasowywać sobie to, co chcę zrobić. Tak, jak rozmawiam z klientami, doradzam im, w jaki sposób można ten produkt budować, tak właśnie też wszystkie rzeczy, które robię, staram się traktować jako produkt, mając kilka różnych projektów, którymi staram się taki produkt zbudować.

Czy któreś podejście jest Ci bliższe? Powiedziałeś, że coraz częściej patrzysz na różne rzeczy jak na produkty. Czy w Boldare realizujecie produkty czy projekty? Dla mnie produkt to jest coś bardziej kompleksowego, całościowego, coś, co można zamknąć i sprzedać, przekazać dalej, a projekt może być na przykład małym zleceniem dla klienta, który potrzebuje dołożenia ficzera. Jestem ciekawy, czy któreś z tych podejść jest Tobie i Boldare bliższe?

Jak najbardziej to, co robimy w Boldare, to faktycznie budujemy produkty. Rzeczywiście naszym głównym celem właściwie chyba nigdy nie było to, żebyśmy wzięli sobie jakieś szybkie zlecenie, odrobili miesiąc, trzy miesiące, zrealizowali dany projekt i na tym zakończyli, tylko faktycznie skupiamy się na tym, żeby pomóc klientowi przejść cały proces. Generalnie staramy się skupiać na dłuższych współpracach ze wszystkimi klientami, przez co faktycznie mamy właściwie jakąś przestrzeń na to, żeby móc razem z klientem zbudować ten produkt, a nie zrealizować kilka projektów wspólnie.

Zanim zaczniemy rozmawiać o tym, jakie może być podejście do realizacji produktów i jak biznes może współpracować z IT (bo kiedy mówimy o produkcie, to nie tylko ta część technologiczna gra rolę), to powiedz proszę, żebyśmy mogli się zakotwiczyć na konkretnych przykładach, przypadkach, jakiego typu produkty realizujecie jako Boldare? Jaka jest skala i czy to jest też kwestia wyboru klienta, dla którego chcecie realizować, czy też może wstępnej filtracji tych rzeczy, które bierzecie później do siebie do realizacji?

Generalnie staramy się faktycznie skupiać na tych klientach, z którymi jesteśmy w stanie budować produkty i są to produkty raczej cyfrowe. Natomiast całkiem niedawno zdarzyło nam się pomóc klientowi w budowie fizycznego urządzenia, przycisku, który był też zintegrowany z jakimś softwarem, który realizował konkretne zadania. Raczej staramy się nie ograniczać, chociaż mimo wszystko nasze główne doświadczenia są związane z aplikacjami webowymi. Generalnie wszystko to, co w Internecie, to jest to, co nas kręci.

Oczywiście tych podejść, różnych metodologii, frameworków, realizacji tego typu produktów cyfrowych, o których tutaj rozmawiamy, w szczególności związanych z oprogramowaniem, jest kilka. Każde ma swoje dobre praktyki, ale Wy wypracowaliście dosyć unikatowe podejście do budowania produktów, które nazwaliście Full Cycle Product Development. To jest temat naszej dzisiejszej rozmowy. Czy mógłbyś powiedzieć, czym jest to podejście, czym ono się charakteryzuje?

W zasadzie musiałbym wrzucić trochę więcej genezy. Przez dosyć długi czas działaliśmy bardzo mocno agile’owo, w zasadzie od dobrych dziewięciu, dziesięciu lat faktycznie działamy bardzo mocno w Scrumie. Po jakimś czasie bliskie naszemu sercu stało się podejście Lean Startupu i łącząc trochę te dwa światy, doszliśmy do takiego podejścia, w którym staramy się podzielić tę budowę produktu w sposób iteracyjny, żeby rzeczywiście dało się zaczynać od mniejszych rzeczy, które jesteśmy w stanie rozbijać, analizować i weryfikować jakieś hipotezy i cele dużo szybciej, niż gdybyśmy chcieli od razu budować jakieś wielkie systemy.

To jest bardzo agile’owe podejście, Lean i Agile są mocno zakotwiczone. Wcześniej oczywiście tak nie było. Całe Waterfall, czyli takie podejście upfront, kiedy całość założeń, całość specyfikacji, tych ustaleń musiała być poczyniona wcześniej. Dopiero później odbywała się realizacja. Mam wrażenie, że to już odeszło, przynajmniej w IT. Oczywiście nie we wszystkich gałęziach, bo w niektórych takie podejście jest jedynym dopuszczalnym. Natomiast coraz częściej mówi się o tym i stosuje się Scruma, czy w ogóle takie podejście Agile, takie tworzenie modelu przyrostowego, które pokazało, że tak się da robić produkty, że to się sprawdza, że to ma sens. Chcę Cię zapytać, jakie fazy rozwoju produktu wyodrębniliście w Waszym podejściu do budowania produktów, czy w ogóle jakieś są?

W zasadzie w naszym podejściu wyodrębniliśmy cztery fazy. Jest faza prototypowania, faza NVP, faz Product-Market Fitu i faza skalowania, czyli scaling. Każda z tych faz jest różna w samym założeniu i celu, który staramy się zrealizować. Już na pierwszej fazie bardzo często jesteśmy w stanie zwalidować jakąś hipotezę prototypując rozwiązanie, nawet w ogóle nie dotykając softu, w ogóle nie dotykając kodu. Zresztą bardzo podobnie, jak w podejściach NVP. Tutaj też jesteśmy w stanie zrobić coś, co nie będzie napisanym kodem. Nie będziemy używali super wzorców, ale użyjemy podejścia typu Low-Code czy No-Code, czy chociażby w prototypie po prostu narysujemy na kartce coś, co będziemy w stanie zaprezentować potencjalnym użytkownikom, żeby zobaczyć, czy w ogóle coś takiego będzie się sprawdzało, czy znajdziemy kogokolwiek zainteresowanego takim podejściem.

W zasadzie w naszym podejściu wyodrębniliśmy cztery fazy. Jest faza prototypowania, faza NVP, faz Product-Market Fitu i faza skalowania, czyli scaling. Każda z tych faz jest różna w samym założeniu i celu, który staramy się zrealizować. Już na pierwszej fazie bardzo często jesteśmy w stanie zwalidować jakąś hipotezę prototypując rozwiązanie, nawet w ogóle nie dotykając softu, w ogóle nie dotykając kodu.

W całym tym naszym podejściu to, co jest z mojego punktu widzenia dosyć istotne, to to, że każda kolejna faza zawiera w sobie poprzednią. To nie jest tak, że nagle przechodzimy z fazy Product-Market Fit do scaling, gdzie staramy się już działać na wyskalowaniu tej aplikacji pod każdym względem. Oprócz tego, że biznesowo, to również technologicznie staramy się stworzyć albo dopasować bezpieczeństwo tej aplikacji, albo staramy się dopasować chociażby jej wydajność.

Natomiast w takim podejściu, jeżeli zaczynają nam się pojawiać jakieś nowe pomysły związane z kolejnymi, nowymi funkcjonalnościami, to nadal musimy pamiętać, że te nowe funkcjonalności też jesteśmy w stanie w ten sam sposób sobie przebadać. Znowu jesteśmy w stanie przejść przez prototyp, żeby sprawdzić, czy to w ogóle ma jakikolwiek sens. Znowu jesteśmy w stanie przejść przez NVP, żeby sprawdzić, czy znajdziemy potencjalnych odbiorców tej aplikacji faktycznie dopasowując ją do nas. Jesteśmy w stanie przejść przez Product-Market Fit, żeby dopasować kilkoma różnymi NVP tę naszą nową funkcjonalność, ten nasz nowy pomysł do całego konceptu i dalej przechodząc sobie w scaling znowu jesteśmy w stanie skalować to dalej.

W nazwie jest ten cykl, o którym mówiłeś, że to są takie fazy, takie iteracyjne dostarczanie, bardzo charakterystyczne dla podejścia agile’owego. Nie wiem, czy dobrze zrozumiałem, popraw mnie, jeśli się mylę. Mówiłeś, że jeśli jesteśmy już tej fazie skalowania, kiedy aplikacja jest dojrzała biznesowo i technologicznie funkcjonuje i jest pomysł na jakąś nową funkcjonalność, jakiś nowy ficzer, to znowu wracamy do etapu prototypowania. Wszystkie te poszczególne etapy muszą być spełnione, żeby znowu dojść do etapu skalowania, kiedy już wiemy, że ta funkcjonalność jest sprawdzona, dojrzała i dostępna dla rynku. Tak to funkcjonuje?

Generalnie zgodnie z tym założeniem tak to funkcjonuje. To mi się osobiście mega mocno spina z cytatem, który kiedyś słyszałem na temat elevator speecha, podejścia w Scrumie. W tym elevator speechu, który słyszałem padło hasło: „Dlaczego Scrum jest lepszy niż podejścia waterfallowe? Ponieważ w dwa tygodnie dostarczymy Ci coś, czego nie chcesz. A w Waterfallu w ciągu pół roku dostarczymy Ci dopiero coś, czego nie chcesz”. Tak samo tutaj, dokładnie w ten sam sposób na to patrzę. Jeżeli zrealizujemy cykl w ten sposób, to dużo szybciej jesteśmy w stanie dostać odpowiedź od rynku, że nikt tego nie chce, nikt tego nie potrzebuje. Jesteśmy w stanie bardzo mocno ograniczyć koszty stworzenia czegoś nowego na trochę innym poziomie. Nie na tym poziomie realizacji projektu, tylko budowania produktu.

Chciałbym jeszcze lepiej zrozumieć, dlaczego zdecydowaliście się właśnie na podzielenie prac nad produktem na fazy. Jeśli zestawić to na przykład z klasycznym Scrumem, to tam oczywiście rzeczy dzieją się iteracyjnie, dowozimy pewne kolejne ficzery iteracyjnie, ale takich faz nie ma bezpośrednio. W tym frameworku Scrumowym o niczym takim się nie mówi. Czy takie fazy, o których tu mówiłeś, NVP, później pewnej dojrzałości, pewnego skalowania, czy to coś daje temu zespołowi Scrumowemu, który na co dzień pracuje nad produktem? Może jeszcze z drugiej strony — wiem, że dużo pytań, ale może zapamiętasz wszystkie — jakie klient ma z tego korzyści na koniec dnia?

Wiesz co, oprócz tej korzyści, o której właściwie przed chwilą wspomniałem, ograniczenia kosztów, ograniczenia ryzyka w trakcie budowy tego produktu, to na przykład to, co my proponujemy klientom, czyli zespół dopasowany do danej fazy. Zespół produktowy budujący ten produkt razem z nimi, czyli właściwie zespół deweloperski, który realizuje jakiś projekt jest dopasowany do fazy. Więc jesteśmy w stanie rzeczywiście wykorzystywać najsilniejsze strony ludzi do tego, żeby zbudować ten produkt. Nie staramy się zmuszać ludzi, którzy zjedli zęby na systemach kolejkowych do tego, żeby nagle mieli postawić jakiegoś WordPressa, wyklikalnego e-commerca, żeby tylko zwalidować jakieś hipotezy. To jest po prostu naturalne wykorzystanie mocnych stron wszystkich członków zespołu, całej ekipy.

Chciałbym Cię jeszcze zapytać o zyski też dla klienta ze stosowania takiego iteracyjnego, cyklicznego podejścia, o którym tutaj mówimy. Co dostaje klient decydując się na realizację produktu według tego podejścia?

Myślę, że najważniejszą rzeczą, jaką klient dostaje, oprócz ludzi, oprócz zespołu dopasowanego do danej fazy, to jest bardzo ograniczone ryzyko i ograniczone koszty wynikające z tego, że zrealizowanie projektu rozpoczynającego budowę produktu od prototypu, który trwa powiedzmy od pół godziny do maksymalnie dwóch tygodni i pozwala dużo szybciej dopasowywać swój pomysł do tego, czego faktycznie ludzie na rynku potrzebują, do tego, czego biznes potrzebuje, za co ludzie będą chcieli w ogóle zapłacić jakieś pieniądze, bądź czego ludzie będą chcieli używać. To na pewno bardzo mocno redukuje koszty i przyspiesza wystartowanie tego produktu w takim kształcie, którego rzeczywiście ktoś będzie oczekiwał.

Rozumiem. Mówiłeś o tym, że zespół jest dopasowany, mówiłeś też, że są różne fazy, które, tak przypuszczam, wymagają udziału różnych ról, żeby te fazy zrealizować — tak to przynajmniej sobie wyobrażam. Czy byłbyś w stanie opowiedzieć nieco więcej o tych poszczególnych fazach, też z takim nastawieniem, jaki jest udział zespołów techniczno-deweloperskich w poszczególnych fazach?

Pełen ownership za realizację danego projektu zostawiamy faktycznie na zespole deweloperskim. Koniec końców to zespół deweloperski będzie dobierał odpowiednie narzędzia do tego, żeby zbudować dany produkt. Natomiast oprócz samego zespołu deweloperskiego oferujemy naszym klientom między innymi role na przykład Product Strategista, czyli człowieka który rzeczywiście jest w stanie wspomóc klienta w przygotowaniu odpowiedniej strategii na zbudowanie takiego produktu. Nomenklatura jest jeszcze mocno podzielona, natomiast na rynku spotykamy się z pojęciem architektów.

U nas również mamy mocno aktywne pojęcie architektów, natomiast to, co staramy się dodać jeszcze poziom wyżej, to są podejścia Technology Strategista czy czegoś w stylu CTO as a service. Człowieka, który będzie w stanie na podstawie wymagań, na podstawie oczekiwań klienta dopasować odpowiednie rozwiązania technologiczne, zaproponować odpowiednią strategię na dalszy rozwój danego produktu, wykorzystując odpowiednie narzędzia technologiczne i wspomagać zespół w tym, żeby faktycznie koszt budowy takiego produktu był w stanie rosnąć w miarę spójnie ze wzrostem samego produktu. Żeby to nie było nagle tak, że mimo wszystko przy fazie prototypowania czy NVP startujemy od razu z trzystuprocentowym coveragem, wielkimi kolejkami, bo to w tym momencie nie pozwoli nam zrealizować naszych celów w żaden sposób.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-122-full-cycle-product-development/

kkempin’s dev blog

Dev and life blog. Thoughts about programming, design patterns, Ruby and life.

Krzysztof Kempiński

Written by

IT expert. Ruby on Rails/iOS/Elixir programmer. Blogger. Podcaster.

kkempin’s dev blog

Dev and life blog. Thoughts about programming, design patterns, Ruby and life.