To jest 122. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o Full Cycle Product Development. 

Przypominam, że w poprzednim odcinku rozmawiałem o tym, jak zostać i rozwijać się jako inżynier DevOps.

Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/122.

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut.

Nazywam się Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego, jest między innymi ten podcast. Zostając patronem na platformie Patronite, możesz mi w tym pomóc już dziś. Wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły.

Jednocześnie bardzo dziękuję moim obecnym patronom.

A teraz życzę Ci już miłego słuchania.

 

Odpalamy!

 

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.

 

Te narzędzia na poszczególnych fazach mogą być różne, w sensie rozwiązania, tak jak powiedziałeś. W przypadku NVP możemy użyć jakieś low kodowe platformy, żeby szybko coś zweryfikować, ale pewnie takiego dużego skalowalnego produktu nie oprzemy o tego typu rozwiązanie. Czy w związku z tym, że te narzędzia mogą być różnie wykorzystywane, to również różne może być seniority osób pracujących w poszczególnych fazach, czy to u Was jest zupełnie wymienne?

 

Zależy, co rozumiesz pod pojęciem seniority, tak na dobrą sprawę. Czy samo doświadczenie czy ten skillset, bo w każej fazie potrzebujemy troszkę innego skillsetu i troszkę innego mindsetu. Jestem w stanie bez większego problemu wyobrazić sobie człowieka, który będzie miał dziesięcioletnie doświadczenie w WordPressie, będzie takim Senior WordPress Developerem, który mega fajnie będzie w stanie nam pomóc rozwiązać jakieś problemy klienta właśnie przy NVP w jakimś stopniu, jeżeli całość dobrze zaprojektujemy i dobrze tego WordPressa schowamy za czymś, żeby deweloperzy w scalingu nie musieli go dotykać, bo znowu przypuszczalnie nie będzie to dla nich największa radość. Nie wykluczałbym takiego podejścia, więc bardziej staramy się skupić na tym, czy ktoś mindsetowo i skillsetowo jest dopasowany do odpowiedniej fazy, niż skupiać się na tym, że seniority związane z doświadczeniem pchamy do odpowiedniej fazy, bo tutaj tak na dobrą sprawę nie ma większego rozróżnienia.

 

Chciałbym jeszcze chwilę o tych fazach porozmawiać, bo wyróżniliśmy je na początku, powiedziałeś o nich, ale mimo wszystko można by je w taką piękną wstęgę połączyć, muszą się łączyć, jedno z drugim. Powiedziałeś wcześniej, że różne zespoły mogą zajmować się poszczególnymi fazami. Mówiliśmy też o tym, że te różne narzędzia mogą być wykorzystywane na poszczególnych fazach. Chcę Cię zapytać, czym się kierujecie w doborze tych rozwiązań? Czy jakoś zapewniacie, czy to jest w ogóle niezbędne żeby zapewniać, kompatybilność tych rozwiązań? Czyli powiedzmy chodzi mi o taką sytuację, gdzie zakończenie prac nad NVP z pozytywnym wynikiem skutkuje tym, że to NVP wyrzucamy do kosza i zaczynamy pracę z nowym stackiem technologicznym. Czy w jakiś sposób jest to ciąg i ta kompatybilność rozwiązań na poszczególnych fazach jest?

 

To, co staramy się osiągnąć to to, żeby faktycznie ten ciąg został zachowany, żeby mimo wszystko nie wyrzucać całej pracy do kosza, tak żeby dało się to dalej jakoś realizować. Z mojej perspektywy, rzeczy, które w ciągu ostatnich dwóch lat zdarzyło mi się zrobić pomagając w etapie przejścia pomiędzy fazami, to było chociażby wyciąganie WordPressa, o którym wspomniałem, jako całkowicie osobny komponent i schowanie go za jakimś API REST-owym czy GraphQL-owym, zależnie od tego, czego potrzebowaliśmy w danym miejscu i zamknięcie całości w osobnym module, który sobie tam jest. Kiedyś go może zmienimy, kiedyś go może zrefaktorujemy, przebudujemy całkowicie od podstaw, natomiast tak długo, jak on realizuje swoje cele biznesowe, tak jest ok.

Możliwe, że w pewnym momencie okaże się, że na przykład zaczyna kuleć wydajność w takim miejscu, więc wtedy już zaczniemy przechodzić z klientem do rozmów na temat długu technologicznego i tego w jaki sposób zarządzać tym długiem technologicznym. Generalnie te rozmowy o długu technologicznym powinniśmy prowadzić już od samego początku, żeby wszyscy byli w tym temacie wyrównani. To, że robimy coś szybciej używając jakichś rozwiązań, to nam spowoduje potencjalne problemy w przyszłości i musimy być tego świadomi.

Istotne tutaj jest to, żebyśmy porozmawiali z biznesem, używając wspólnego języka, a w zasadzie nawet trochę bardziej biznesowego języka. To, co zauważyłem dosyć często u siebie i u kolegów deweloperów, to że rozmawiając o takich rzeczach z biznesem, to bardziej jest rozmowa na zasadzie: „Kurde tutaj testów nie ma, jest ciężko ten kod utrzymać” i biznes tego nie rozumie. Tak samo, jak mechanik mi powie, że: „Tam, panie, tutaj jakieś świece, coś tam z nimi jest nie tak”. Ja tego w ogóle nie rozumiem. 

Ale jak ktoś mi zacznie opowiadać to moim językiem, zrozumiałym dla mnie, czyli tak jak my biznesowi zaczniemy opowiadać o długu i zarządzaniu długiem, to biznes w dzisiejszych czasach wie o długu dużo więcej niż my potencjalnie, więc będą w stanie zrozumieć te terminy związane z zarządzaniem długiem i dopasowywaniu tych rozwiązań zależnie od długu. Koniec końców uważam, że to decyzją biznesu jest to, czy ten dług powinniśmy zaciągać czy nie. Naszą odpowiedzialnością jako deweloperów jest to, żebyśmy wsparli biznes w zarządzaniu tym długiem.

 

Oczywiście, ma to bardzo dużo sensu. Przeszedłeś do roli dewelopera, też mnie to interesuje, bo rozmawialiśmy do tej pory o tworzeniu produktów trochę z widoku helikoptera – z braku dobrego odpowiednika po polsku. Na co dzień zaangażowany w to jest poszczególny deweloper. Zastanawiam się, czy u Was ten deweloper to jest tylko taka rola wykonawcza dla zadań, czy też może jest jakoś mocniej zaangażowany w cały ten Full Cycle Development?

 

Mogę odpowiedzieć na to pytanie z dwóch perspektyw. W zasadzie od strony dewelopera w fazie, czyli osoby, która współpracuje z klientem w określonej fazie głównie. Każdy nasz projekt, który realizujemy zaczynamy od warsztatów z klientem, czyli warsztatów Product Discovery, na których odkrywamy, co my tak naprawdę chcemy robić i już od tego etapu nasi deweloperzy współpracują z klientem. Już od tego etapu, na którym role Product Strategista, Technology Strategista czy New Product Guide’a wchodzą i pomagają klientowi, pomagają z klienta wyciągnąć, co my chcemy tak naprawdę zrobić.

 

Każdy nasz projekt, który realizujemy zaczynamy od warsztatów z klientem, czyli warsztatów Product Discovery, na których odkrywamy, co my tak naprawdę chcemy robić i już od tego etapu nasi deweloperzy współpracują z klientem. Już od tego etapu, na którym role Product Strategista, Technology Strategista czy New Product Guide’a wchodzą i pomagają klientowi, pomagają z klienta wyciągnąć, co my chcemy tak naprawdę zrobić. 

 

Na takie same warsztaty bierzemy od razu cały zespół deweloperski, który potencjalnie będzie ten projekt realizował, żebyśmy już w tym momencie byli w stanie wychwycić wszystkie niespójności czy wątpliwe kwestie, żeby po takim warsztacie móc ten zespół dopasować jeszcze bardziej do tego, co faktycznie będziemy chcieli zrealizować. Później, już na samym warsztacie, taki deweloper może rzucić swoim pomysłem, jest na tym warsztacie traktowany tak samo, jak każda jedna inna osoba, nie ma tutaj lepszego, gorszego, wszyscy działamy po to, żeby zbudować jak najlepszy produkt, realizując jakiś projekt. Przechodząc po warsztatach realizujemy cały projekt wykorzystując zwinne podejścia, więc procesy refine’owania, sesje Event Modelingowe, Event Stormingowe to jest dalej coś, co jest realizowane przez ten zespół deweloperski, który realizuje dany projekt. 

I teraz idąc dalej, to, z czym eksperymentujemy w tym momencie, mamy te cztery fazy. Załóżmy, że całość trwa dwa lata od prototypu do przejścia w fazę skalowania przy takim bardzo fajnym podejściu. Kiedy mamy tych deweloperów w fazie, a produkty zmieniają fazy, to kończylibyśmy z tym najprawdopodobniej, że mielibyśmy cztery różne zespoły. Co też jest trochę słabe, bo bardzo dużo kontekstu się traci. Można zrobić bardzo dużo dokumentacji  produktowej, można porobić ADR-y, które dokumentują nam całą architekturę, możemy mieć te wszystkie murale z modelami, ale gdzieś ten kontekst pewnego sposobu działania z danym klientem, pewnych decyzji i tak się straci. 

Dlatego na przykład teraz zaczynamy testować to, żeby mieć jakby taką core’ową część zespołu, która będzie potrafiła przejść razem z tym produktem przez wszystkie fazy, też w taki sposób, żeby klient nie tracił kontaktu z ludźmi. Żeby to nie oznaczało w pewnych momentach, że popracował sobie z zespołem trzy miesiące, zbudowali naprawdę bardzo dużą dozę zaufania, bardzo fajną relację i nagle po trzech miesiącach kończymy i całkowicie zmieniamy wszystkich ludzi. Tak z ludzkiego punktu widzenia jest to bardzo niekomfortowe.

 

O to w sumie chciałem zapytać, zastanawiam się też pod kątem doboru do zespołu, weźmy taki zespół w fazie, jak to fajnie nazwałeś. Chciałbym zapytać, jak dobieracie osoby pod względem skillsetu technicznego, mindsetu do poszczególnych faz, czy to się różni? Czy to jest tak, że te osoby mogą też przechodzić? Dajmy na to, że NVP to jest najprostsza – oczywiście możemy podyskutować, natomiast to jest przykład – technologicznie najprostsza być może faza, więc wymaga powiedzmy mniejszych kompetencji, natomiast awansując w firmie ktoś przechodzi do dalszych faz zespołów, które już są bardziej doświadczone, czy też operują na większej skali po prostu.

 

Z jednej strony mamy przygotowaną ankietę, która jest w stanie nam coś podpowiedzieć. To jest pewnego rodzaju Gallup dla deweloperów, jest dopasowania do odpowiedniej fazy i to jest pierwszy punkt informacyjny mówiący o tym, jakie predyspozycje mniej więcej dany człowiek może mieć. Natomiast później i tak staramy się poprzez rozmowę z ludźmi dowiadywać jakie mają ambicje. Na przykład w tym momencie on się czuje w scalingu, czyli takim człowiekiem skalującym aplikacje, a z testu mu wyszło, że powinien być bardziej w fazie NVP, to też się skądś może brać.

Więc też staramy się bardzo mocno podejść z jednej strony systemowo, dając ludziom możliwość przebadania sobie tego aktualnego podejścia, ale też indywidualnie, żeby zweryfikować, że faktycznie ktoś rzeczywiście będzie się dobrze czuł pracując w danej fazie, a nie w innej. Jest jak najbardziej okej,  żeby ludzie pracowali w tylko jednej fazie i skupiali się tylko na jednej fazie, a są takie freaki, które bez większego problemu są w stanie wesprzeć zespoły przy prototypowaniu i dosyć skutecznie działać przy skalowaniu. 

Oczywiście w pewnym momencie zaczyna się kończyć ta zdolność posiadania wiedzy w umyśle, bo przy niektórych systemach skalowanych, żeby utrzymywać niektóre systemy, to pasowałoby mieć zrobiony doktorat z baz danych czy z systemów kolejkowych. Więc ciężko jest osiągnąć ten poziom, żeby ktoś był takim Technology Generalistem, żeby w każdej fazie był w stanie stać się światowym liderem jakichś rozwiązań. Natomiast bez większego problemu można tak pracować bardzo skutecznie prowadząc te zespoły i prowadząc produkty właściwie w tę stronę.

 

Te preferencje są różne. Niektórzy wolą pracować tylko z technologią i tak jak to przywołują, że nie po to studiowali informatykę, żeby rozmawiać z ludźmi, wolą się skupiać na małych dobrze zdefiniowanych zadaniach technologicznych. To też jest ok, takie osoby też są potrzebne. Ale my rozmawiamy bardziej o takim podejściu, czy o tego typu deweloperach, którzy pracują blisko z produktem, blisko z potencjalnym klientem, którzy są zaangażowani w rozmowy z klientem, którzy może widzą nawet też ten feedback od użytkownika końcowego dosyć szybko. Co w Twojej opinii daje deweloperowi taka bliższa praca z biznesem, użytkownikiem, klientem, jakkolwiek to nazwać? Co daje to deweloperowi i też odbiorcy tego produktu, jeśli ma taką możliwość, żeby rozmawiać bezpośrednio z osobą, która buduje ten produkt?

 

Najpierw skupię się chyba na deweloperze i powiem o swoich personalnych odczuciach, co mnie dawało to, że miałem taki totalnie bezpośredni kontakt z klientem i mam nadal. Co mnie daje to, że mam taki bezpośredni kontakt z użytkownikami, bo też robiąc badania na użytkownikach, potrzebujemy znaleźć takich, z którymi jesteśmy w stanie porozmawiać na temat tego produktu. Ja osobiście widzę to jako wręcz natychmiastowy feedback na temat tego, czy pomogłem komuś w rozwiązaniu jego problemów życia codziennego, czy to przy jakichś systemach intranetowych pomagam pracownikowi ogarniać, księgowej pomagam ogarniać zarządzanie fakturami i wiem od razu, że pomogłem komuś w jego codziennym życiu.

 

Co mnie daje to, że mam taki bezpośredni kontakt z użytkownikami, bo też robiąc badania na użytkownikach, potrzebujemy znaleźć takich, z którymi jesteśmy w stanie porozmawiać na temat tego produktu. Ja osobiście widzę to jako wręcz natychmiastowy feedback na temat tego, czy pomogłem komuś w rozwiązaniu jego problemów życia codziennego, czy to przy jakichś systemach intranetowych pomagam pracownikowi ogarniać, księgowej pomagam ogarniać zarządzanie fakturami i wiem od razu, że pomogłem komuś w jego codziennym życiu. 

 

A znowu z punktu widzenia użytkownika to jest takie odczucie bycia potraktowanym serio. W momencie, kiedy mój komunikat jako użytkownika będzie musiał przejść przez dziesięciu różnych proxy, kilkanaście różnych osób będzie to musiało przemielić, to jest duże ryzyko, że ta moja rzeczywista intencja gdzieś się zgubi. W momencie w którym faktycznie będę w stanie porozmawiać sobie mając na jednym spotkaniu Product Ownera, kilku ludzi z naszej strony, mnie dewelopera i tego użytkownika, dużo szybciej będziemy w stanie znaleźć nić porozumienia. Rzeczywiście dużo szybciej będziemy w stanie znaleźć te obszary, które faktycznie są problematyczne dla tego użytkownika, gdzie jesteśmy w stanie pomóc i to mu coś da, a nie będziemy próbowali wymyślać koła na nowo i zastanawiać się: „Dobra, co by mu mogło było pomóc?”.

 

Ja też jestem zdecydowanie z tego zespołu, który preferuje taki bliski kontakt, to mi po prostu daje satysfakcję z codziennej pracy. Myślę sobie, że gdyby popatrzeć na ten rynek rozwiązań cyfrowych, produktów cyfrowych, w szczególności oprogramowania, to w ostatnich latach użytkownicy coraz bardziej doceniają jakość. Jakość tych produktów, mam wrażenie, że rośnie. Oczywiście to jest dobry trend. Pytanie do Ciebie, Mateusz, jak u Was się realizuje takie procesy Quality Assurance? W którym miejscu tego cyklu wytwarzania oprogramowania, czy też właściwie tworzenia produktu, tak to powinniśmy nazwać, pojawiają się testerzy, pojawiają się elementy związane z Quality Assurance?

 

Właściwie od tego momentu, od którego rzeczywiście trzeba takiego człowieka. Czyli w momencie, kiedy faktycznie zaczynamy robić coś, co potencjalnie będzie mogło trafić do ludzi, to już myślę, że to jest dobry moment, w którym to podejście jakościowe powinno zacząć się pojawiać. Mamy w zasadzie dwie różne role związane z jakością. Mamy Quality Assurance inżynierów, ludzi którzy skupiają się troszkę bardziej na automatyzacji i na takim – nie chciałbym tego zamykać faktycznie w słowie inżynierskim – mocno technicznym podejściu i analizie pod kątem tego, czy gdzieś technicznie nie zawalamy jakości. Ale z drugiej strony mamy taki kierunek roli Quality Assurance/Businness Analyst, czyli tych ludzi, którzy na przykład wspomagają nas w zweryfikowaniu tej jakości na poziomie biznesowym i są w stanie nam pomóc zweryfikować ten produkt finalnie, czy rzeczywiście realizuje między innymi te założenia jakościowe po zbudowaniu. 

Co do samego podejścia już stricte wykonawczego, czyli takiego bardziej mięska dla deweloperów, to tak na dobrą sprawę raz, że mając to podejście z Technology Strategistem, z architektami, cały czas wierzymy razem z klientem, że ten produkt kiedyś będzie skalowalny. Więc wiedząc, że ten produkt będzie kiedyś skalowalny, to też od samego początku, pisząc kod do NVP, muszę pamiętać o tym. Trzeba pamiętać też o tym, o czym bardzo często ludzie potrafią zapomnieć przy słowie NVP. W jego definicji nie mamy: „olej jakość”, tylko mamy: „wyciągnij minimalną wartość produktu, którą będziemy w stanie testować coś”. Więc tutaj też musimy się skupić na tym, żeby mimo wszystko te testy sobie móc gdzieś napisać.

 

Jasne. Ta jakość jest ważna i ważne jest to, żeby myśleć o tym na początku. To nie jest tak, że na początku jest proces deweloperski, a dopiero później Quality Assurance, tylko to raczej się spaja w taki jeden ciąg. O to samo w sumie chciałem Cię zapytać w kontekście DevOpsów, bo często widzę, że to jest taka rola pod tytułem: „inżynier, który zajmuje się trochę utrzymaniem aplikacji, trochę infrastrukturą w chmurze”. I to jest oczywiście takie niepełne korzystanie z tego założenia DevOpsowego, jak było ono pierwotnie zdefiniowane. Czy u Was taka kultura DevOpsowa też panuje? W jaki sposób do tego podchodzicie?

 

Staramy się podchodzić do tego rzeczywiście tak, jak to jest z definicji. Mamy też między innymi w firmie rolę DevOps Guide’ów, czyli ludzi, którzy rzeczywiście wspierają zespoły nie w tym, że nam napiszą kilka linijek konfiguracji, których będziemy później używali jako Infrastructure as a Code, tylko którzy nauczą nas tego podejścia i będą wspierali zespoły w tym podejściu. Zależnie od tego, jakie mamy faktycznie potrzeby i jaki mamy mindset zespołu czy klienta, czyli podejście Continuous Delivery czy Continuous Deployment, bo nie wszyscy są gotowi na takie rzeczy i trzeba sobie to dopasowywać do kontekstu. Staramy się bardzo mocno, żeby to wsparcie DevOpsowe było cały czas w zespole, żeby ludzie mieli wsparcie w razie gdyby sobie z czymś nie poradzili. 

Natomiast, jak zawsze u nas, odpowiedzialność spoczywa na zespole, więc ten zespół musi wiedzieć, że potrzebuje takiej wiedzy, to zespół koniec końców utrzymuje ten produkt w miejscu, w którym są, więc też sam musi poczuć to, że to oni są za to odpowiedzialni. Jak coś produkcyjnie się wykrzaczy, to my musimy umieć to zrobić, więc to też nie jest tak, że mamy DevOpsa w zespole i to on będzie robił deploya na produkcję. No nie, ja jako członek zespołu deweloperskiego też muszę to umieć zrobić, bo kiedyś się coś może wykrzaczyć i kogoś może nie być w pracy, a problem trzeba naprawić w miarę od razu.

 

Oczywiście, każdy tam był, każdy to widział. A jeśli mówisz tutaj o odpowiedzialności, to chciałbym Cię na koniec zapytać jeszcze o dług technologiczny. Powiedziałeś o tym, że on zawsze jest, prawie nigdy nie da się tworzyć produktów cyfrowych, oprogramowania bez długu technologicznego, on się pojawia praktycznie na drugi dzień już. To jest ważny aspekt, a zarządzanie nim, to jest jeszcze ważniejsza rzecz. Często, tak jak mówiliśmy, robimy to NVP, świadomie zaciągając ten dług, spisujemy dlaczego podjęliśmy taką decyzję, dlaczego akurat takie rozwiązanie. Być może ustalamy to z użytkownikiem czy klientem końcowym, że taki dług został zaciągnięty, że ten time-to-market jest ważniejszy na przykład niż pewne aspekty. Okej, wszystko jest fajnie dopóki wiemy, że tak robimy i dopóki mamy jakiś plan, że w przyszłości ten dług spłacimy, jeśli to będzie miało sens, bo trzeba też sobie jasno powiedzieć, że nie każdy dług technologiczny wymaga spłacenia, wiadomo. Jakie obserwacje czy jakie dobre praktyki związane z zarządzaniem długiem technologicznym stosujecie w Boldare?

 

Jedną z rzeczy, którą ja na pewno robię u siebie w zespołach, to jest zarządzanie Architecture Decision Recordami i dokumentowanie tego świadomie zaciąganego długu, tak żebyśmy byli w stanie po jakimś czasie wrócić do tego przy starcie każdego kolejnego projektu, czyli w momencie kiedy nasz produkt przechodzi z fazy do fazy. Startując realizację jakiegoś projektu w kolejnej fazie zaczynamy od warsztatów Product Discovery Workshop, żeby sobie znowu zbadać te nasze potrzeby i to, co robimy po takich warsztatach, to zawsze jest sesja analizy ryzyka. Wtedy na takiej sesji analizy ryzyk jesteśmy w stanie sobie wyciągnąć właśnie z naszych ADR-ów na przykład to, jakie decyzje były podejmowane i jesteśmy w stanie zobaczyć, czy może nie ma jakichś elementów, o których powinniśmy już zacząć rozmawiać, żeby zrealizować nasz cel, to będziemy musieli w jakiś sposób teraz sobie spłacić ten dług. Natomiast przyznam szczerze, ekspertem od zarządzania długiem nie jestem. Mamy u nas w firmie lepszego człowieka Dawida, jakby ktoś kiedyś miał szansę z Dawidem Yerginyanem pogadać na temat długu technologicznego, to naprawdę gorąco polecam.

 

Świetnie, bardzo dziękuję Ci za wskazanie Dawida, być może w linkach uda mi się podpiąć namiar na niego. Nigdy nie wiadomo, kiedy taki ekspert może się przydać. Mateusz, ja Ci bardzo dziękuję za tę ciekawą rozmowę, za pokazanie takiego kompleksowego podejścia, jakie wypracowaliście w Boldare do tworzenia produktów cyfrowych w szczególności oprogramowania. Dzięki Ci za poświęcony czas. Na koniec powiedz jeszcze, gdzie Cię można znaleźć w Internecie, jak się z Tobą skontaktować?

 

Również dziękuję za tę rozmowę. Fajnie było się podzielić tym, co robię na co dzień, mam nadzieję, że będzie to interesujące dla odbiorców. Gdzie mnie można znaleźć na co dzień? Właściwie najlepiej, najszybciej mnie znaleźć na Instagramie i na LinkedInie, to są te dwa źródła, na których rzeczywiście jestem w miarę regularnie. Wszystkie pozostałe mogą zostać bez odbioru. 

 

Jasne, dziękuję bardzo. Oczywiście te linki będą w notatce do odcinka. Cieszę się też, że wspomniałeś o Instagramie, bo to jest w sumie takie nietypowe medium, na którym Polska społeczność IT coraz mocniej się udziela, więc fajnie, że Ciebie też tam można znaleźć.

Dziękuję bardzo wobec tego i do usłyszenia. Cześć!

 

Dziękuję również, pozdrawiam! Do usłyszenia!

 

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Jako branża wyszliśmy już z podejścia typu Waterfall do wytwarzania produktów cyfrowych, w tym oprogramowania. Obecnie proces ten dzielimy na fazy, które zazwyczaj iterują, wymagają osób z różnymi kompetencjami. W ten sposób nie tylko lepiej wpasowujemy się w potrzeby odbiorców, ale i szybciej realizujemy projekty cyfrowe.

Jeśli ten odcinek był dla Ciebie interesujący i przydatny, odwdzięcz się, proszę, recenzją, oceną lub komentarzem w social mediach.

Jeśli masz jakieś pytania, pisz śmiało na krzysztof@porozmawiajmyoit.pl

Zapraszam też do moich mediów społecznościowych.

Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o Full Cycle Product Development.

Zapraszam do kolejnego odcinka już za tydzień.

Cześć!