Coffee Coffee #80
Nowoczesny proces developerski
O odcinku
Transkrypcja
Brak wyników.
O, background nasz wewnętrzny wyszedł na na żywo. Dzień dobry. Ja będę sprawdzał technicalia. Przyznam wam się szczerze, zanim Sebastian zacznie, dla tych, którzy oglądają, że prawie zapomnieliśmy wejść online, bo się zagadaliśmy. Dobrze, teraz się dobryp jest od rana. Pewien pełen profesjonalizm. Jeszcze niektórzy rzucają czerstwe dowcipy i to nie jest ani Sebastian, ani Wojtek. Dobra, mam nadzieję, że ktoś nas widzi. I mam nadzieję, że jesteśmy online. Będziemy sprawdzać w tak zwanym międzyczasie, bo teoretycznie powinniśmy być w tym samym czasie, tak i na Riverside, i na YouTubie, i na LinkedInie, i na Xie, i wczoraj to wszystko sprawdzałem od zera, więc jak to teraz nie działa, to się naprawdę wkurzę. Ale mnie o tym. Słuchajcie, to jest City Morning Coffee, nasza sesja live. Niektórzy może w ogóle zdążyli zapomnieć o co w tym biega i co to jest i dlaczego, jak i kiedy. Więc krótkie przypomnienie. City Morning Coffee to jest w ogóle mała społeczność. Senior Technical Leaders i tych obecnych i tych aspirujących, gdzie rozmawiamy sobie o tematach istotnych właśnie dla czy to architektów, menedżerów, VPS, CTOs, takiego tematach dotyczących ich pracy na co dzień, tematach czy to organizacyjnych, technologicznych, architektonicznych, a czasami instrykty nawet biznesowych. Także jeżeli
należycie do tej grupy, jeżeli chcielibyście należyć do tej grupy, macie takie aspiracje, to jest prawdopodobnie miejsce dla was. I my jako City Morning Cofi rozmawiamy sobie, a zwykle zwykliśmy rozmawiać sobie co dwa tygodnie właśnie w Form Your Life na jakiś jeden konkretny temat. Idea była od zawsze taka, żeby każdy mógł zabrać głos. I dzisiaj jest podobnie, aczkolwiek nie aż tak łatwo, dlatego że jeżeli słuchajcie wejdziecie na nasz link reversiteowy i mogę go nawet w tym momencie wyszerować. Nie wiem czy nie nakłamałem. O teraz wszyscy go powinni widzieć na ekranie. Jeżeli dołączycie do nas przez ten link, to nawet będziemy mogli was doprosić do sesji live na żywo, czy to audio, czy to wideo, więc będziecie mogli pokazać swoją twarz wszystkim dookoła i mamie, i cioci, i wujkom i wszystkim innym. Waszą twarz, ale będziecie mogli wyrazić opinię i zadać pytanie i w ogóle wszystko co tylko. Natomiast jeżeli aż tak bardzo się nie chcecie zaangażować, to zawsze możecie walić w komentarzach. My będziemy widzieli komentarze na Riverside, będziemy pewnie widzieli komentarze chyba na YouTubie tych z LinkedIna. To tylko jak tam zajrzymy, bo one się chyba nie synchronizują. Ale dobra, a ja zaglądam.
A dobra, rozgadałem się trochę i generalnie idea jest taka, że zachowujemy pewną temperaturę pewną temperaturę dyskusji i kulturę dyskusji. To znaczy oczywiście jeżeli krytykujemy, to krytykujemy nie jakieś nowe osoby czy firmy, tylko jakieś konkretne postawy. I chyba powiedziałem wszystko co najważniejsze. Na city ofmorning.cofe można znaleźć wszystkie nasze linki łącznie z archiwum odcinków. Oczywiście jak będziecie śledzić nas na socialach, czyli przede wszystkim na Xie, LinkedInie i YouTubie, to będziecie też to archiwum widzieć. I chyba to powiedziałem co najważniejsze poza tytułem dzisiejszego odcinka. Słuchajcie, dzisiaj chcielibyśmy sobie pogadać o nowoczesnym procesie wytwarzania, oprogramowania. Dlatego, że wszyscy się naczytali mądrych książek, wszyscy wiedzą jak to powinno wyglądać kanonicznie, ale jak to wygląda w praktyce? To znaczy jak powinno się dzisiaj zastopować taki proces wytwarzania oprogramowania end to end od początku do końca, żeby było to zgodne z nowoczesnymi praktykami i z tym czego nasza branża nauczyła się na własnych błędach przez te wszystkie lata.
Dobra, nagadałem się tyle, że w sumie chyba mogę być cicho do końca odcinka. Tomek, powiedz jaki tam raport z frontu. Ty będziesz dużo mówił, a ja zacznę puę. Wystarczy odpalić agenta AI. Hell yeah. I on nam wszystko powie. Raport z frontu jest taki, że wszędzie działa, więc lecimy. Cudnie jest. Cudnie jest. Dobra, to to co trzeba byłoby trzeba dobrze zagaić jakimś pytaniem na początek. Jeżeli mówimy o procesie wytworzenia programowania, to gdzieś na jego samym początku to jest jakiś scoping i planowanie, no bo trzeba wiedzieć co się w ogóle robi. A więc Wojtek może zaatakuję najpierw ciebie, a potem rozszerzmy dalej. I by the way tam ytoś właśnie chciał na czacie czy coś to tam się też włączajcie, sygnalizujcie, że macie pytania albo chcecie dołączyć. No więc Wojtek, a na podstawie twoich doświadczeń, firm, które znasz, firm, w których pracowałeś, ten pierwszy styk, czyli dowiadywanie się, co my w ogóle mamy zrobić, e, jak to, jakie byś podał paterny, antypaterny, co dobrze działa, co źle działa z perspektywy inżynierów.
E, dobra. To ja bym powiedział tak, że to co z mojego doświadczenia w wielkim skrócie dobrze działa, to jest w momencie w którym mamy do czynienia faktycznie z product engineeringiem. A i dla mnie to jest różnica takaż przede wszystkim, że faktycznie inżynierowie są zaangażowani w tworzenie produktu od samego początku, a nie są wiesz wykonawcami przysłowiowych tasków w GZE. Yyy, więc pierwsza rzecz, którą yyy, którą zachęcam yyy spróbować, to faktycznie yyy zaangażować inżynierów od samego początku, zarówno w metryki biznesowe, czyli dlaczego coś robimy, yyy w procesowy yyy projektowania zarówno yyy zarówno funkcjonalności jak i często UXowy. My jako programiści nie jesteśmy niedoceniani. Tutaj mam na przykład wielki wielką prośbę. Pamiętajcie, że UX to przede wszystkim też backend, więc backendowcy bardzo często potrafią niesamowicie poprawić UX i skomentować niektóre pomysły.
No dobra, to ja dzisia będę miał tylko rulę challengeującą, będę challengeował. A powiedz mi, a dawaj, bo wiesz, bo tak jak powiedziałeś, ja się generalnie z tym zgadzam, natomiast to jestż ten moment, kiedy my rzeczywiście ci przynajmniej ci ludzie biznesowi, produktowi wiedzą co robić, ale to jest tak, że tam pewnie pomysłów lata dużo w organizacji. Dokładnie tak. I te pomysły latają ze strony jakichś biznes unitów, sprzedaży jakiejś, jakiegoś wsparcia klienta i tak dalej, i tak dalej. I czy naprawdę chcemy mieć dewelopera od samego początku, żeby uczestniczyć w tych wszystkich brainstormach? Dlaczego nie? Ja bym to powiedział też z mojego doświadczenia. y może wiesz od samego początku zależy co, co to co rozumiemy przez początek pewnie i tutaj się aż czekam, aż Tomek się wyrwie, żeby skomentować, bo w niektórych organizacjach przychodzi y Wielka Czwórka i mówi: "Macie zrobić to, to i to". E i tak się zaczynają projekty, prawda? Więc wszelkie transformacje od tego się zaczynają. Natomiast y jeżeli faktycznie mówimy o rozwoju produktu, to dlaczego nie? Dlaczego właśnie inżynierowie nie mają być zaangażowani?
Wiesz, dobra, to teraz jeszcze wracam do samego początku. Ja mogę ci pojechać też. Dzisiaj będzie dwóch na jednego, bo on robi software, a my gadamy. To ci pojadę takim stereotypem. Dlaczego nie? Bo oni tego nie lubią i nie chcą. I drodzy są. To ja to skomentuję tak, że w momencie kiedy zamykamy przed A możemy to poczekaj to jest dokładnie tak jakby jakby powiedzieć, że wiesz tworząc samochód nie masz inżynierów, którzy potrafią ci pewne rzeczy powiedzieć od samego początku, że nie zadziałają, jeżeli go tworzysz. To dokładnie tak samo może być z oprogramowaniem. A nie mówię oczywiście, że całe zespoły, to też nie o to chodzi, ale na przykład doświadczone doświadczone osoby jak najbardziej. Tak. A mogę opowiedzieć jak to działa w w firmie, w której pracuję teraz?
A jakie też poaliście o antypaterny? Chyba jednym wielkim antypaternem, z którym ja się spotkałem, to było hippo tak zwane, czyli the highest paid person opinion. e, przychodzi na przykład członek zarządu i mówi, że mamy to zrobić tak i koniec. Oczywiście jest jest to jego prawo, szczególnie jeżeli jest founderem i ma widzi widzi coś, czego możemy niekoniecznie widzimy. Ale bardzo często zdarza się tak, że osoby chcą pokazać swoją przydatność w organizacji poprzez wiecie zainicjalizowanie backloga w taki lub inny sposób. Niekoniecznie ma to sens. No dobra, a powiedz mi Wojtek jakby okej, trochę cię znowu skontruję, rozmawiamy sobie z tą osobą produktową i ta osoba produktowa przynosi tam jakieś pomysły, ale na na sam ten styk z tą osobą produktową to jakie ty masz paterny na przykład czy z taką osobą zwykle pracujesz bezpośrednio czy według ciebie pomaga jeżeli są jakieś project managerowie którzy na przykład prowadzą a ewentualnie jeżeli są analitycy albo jeżeli są pośrednicy typu product owner managerowie backloga to w tym momencie być Może bardziej to streamluje taką taką taką współpracę. A może w ogóle z
twojej praktyki to wynika tak, że tematy zwykle nie wpadają do pojedynczych zespołów, tylko są pewnymi programami. One angażują wiele zespołów, więc bez program managera ani róż. Mhm. Dobre pytanie. To to mogę powiedzieć jak to na przykład działa w w firmie, w której teraz jestem. Czyli w rewolucie jest tak, że faktycznie każdy zespół jest produktowy. [Aplauz] Są też zespoły serwisowe, ale zakładam, że mówimy o inżynieringu, to faktycznie każdy zespół jest produktowy, czyli każdy feater, który widzicie w aplikacji lub go nie widzicie, bo jest na przykład niżej w staku, jest produkowany przez zespół produktowy. Każdy zespół produktowy będzie miał product managera. W niektórych przypadkach, w wielu przypadkach tak naprawdę product managerem może być osoba techniczna. yyy zarządzanie yyy taka administracja powiedzmy zadaniami, jak to powiedziałeś, taskami i tak dalej, to jest część obok tego. Może być w tej roli, nie musi. Więc to jest troszeczkę coś y coś innego. A natomiast w wielu zespołach faktycznie jest dedykowany product manager i on zarządza tak jakby zarówno tym backlogiem, taskami i tak dalej.
Teraz skąd się biorą priorytety dla zespołu? priorytety dla zespołu biorą się po pierwsze yyy jest y w wielkim skrócie roczna strategia dzielona na kwartalne cele. Yyy cele kwartalne są dzielone na projekty yyy produktowe i one są y brane przez zespoły. Zespoły się komitują na nie i faktycznie są wytwarzane w danym kwartale. Dany projekt reguła jest taka, że nie może zabierać więcej niż kwartał. Taka ciekawostka. To pewnie odpowiedziałem na pytanie y dosyć dosyć już z przodu listy. A i oczywiście w rewolucie jest tak, że wszystko musi być mierzone, więc product manager odpowiada też za stworzeniem metryk odpowiednich do tego produktu. Czy jedna osoba to daje radę? Bo stąd wiele osób, wiele firm wprowadza właśnie tego typu haki organizacyjne, że dodaje dodatkowe role. Czyli na przykład product manager ma tego swojego product wera jako swoje proxy albo tych analityków albo jeszcze jakieś inne role associate product manager też się spotkałem z czymś takim czyli wiecie pod y giermek który zarządza girom więc takie role faktycznie się zdarzają bo ja ci powiem jak to wygląda trochę z mojego doświadczenia z mojego doświadczenia to ja naprawdę widziałem bardzo mało organizacji które mają dobrze ogarnięty podział produktowy
zazwyczaj podział produktowy to jest podział na systemy tak jak powstawały w czasie. To jest trochę historia błędów albo eksperymentów organizacji, gdzie organizacja myślała, że zainwestuje gdzie pójdzie. I teraz w związku z tym te produkty są budowane dookoła, nazwijmy to, ognisk wiedzy, że tam jest potrzebna specyficzna wiedza dotycząca na przykład implementacji tego systemu albo integracji tego systemu albo jakiekolwiek specyfiki tego systemu. Być może ten system nawet to jest jakaś grupa interakcji użytkownika, ale koniec końców jest ciężko go zamknąć jako taki prawdziwy produkt. No więc tak wygląda zdecydowana większość firm, które ja widziałem. Co więcej, zdecydowana większość, znaczy jakaś tam część tych firm zdaje sobie sprawę z tego, że to tak działa, ale nie umie z tego wyjść. Więc jest to stan, który jest trochę zabetonowany. I teraz w związku z tym proces deweloperski zazwyczaj obchodzi trochę ten problem i właśnie po to powstają role typu program manager na przykład. Albo jest jeszcze jeden taki mały hak, który bardzo często się pojawia. Trochę powiedziałeś o tym paternie Hippo, że jest osoba, która yyy jest najwyżej płatna w pokoju i w związku z tym ona decyduje. Powiem ci, że czasami nie jest to antypatern. Dlaczego nie jest to
antypatern w sytuacji powiedziałeś tak kiedy to jest jedyna osoba, która ma stak, to jest jedyna osoba, która ma skin in the game, to jest osoba, która tak naprawdę jest wizją, a na przykład product manager jest pracownikiem. Poza tym to jest czasami obejście kolejnego fundamentalnego problemu, który mamy zwłaszcza na naszym polskim rynku, czyli że jest strasznie mało dobrych product managerów z doświadczeniem. Czyli znowu łatwiej jest znaleźć kogoś, kto będzie menadżerem backloga, podczas gdy wizjoner wizjonerem ciągle jest CEO na przykład, który pracuje na dwa etaty, wręcz siedzi 16 godzin dziennie, zapierdziela i staraj się tą swoją wizję przekazywać. A już ten nie rób męczennika z tego tam CTO. Dobrze, ja wejdę na chwilę. Tak, jedna rzecz. Muszę zrobić to publicznie, technicznie poproszono, żeby mnie i Sebastiana, żebyśmy podbili mikrofony, ale nie wiem czy to się da zrobić, ale ja podbiję to jest taki problem, tylko wam powiem, że dla nas wszystko jest okej, czyli my słyszymy siebie bardzo dobrze, ale podobno ja i Sebastian jesteśmy cicho.
Publiczność tam możecie przejrzeć, komentarze się z nami z wami zgadza albo i się nie zgadza, ale ogólnie raczej się zgadza. A ja tylko dodam, że tam trochę wszedłem jako adwokat Diabła na początku, ale ja się na przykład z Wojtkiem zgadzam, nie? To tylko teraz tak, ja mam tak jak wam mówiłem przed odcinkiem inny background, więc dzisiaj więcej będziecie mówić wy. No ale nawet takim jak my robiliśmy usługi i dla nas software to było pisane zawsze dla klienta czy coś takiego, czy robiona usługa, nie? To ja byłem zwolennikiem wciągania ludzi wcześnie, nie? W szczególności w estymacje, takie rzeczy, nie? Yyy, dlaczego jeden yyy no bo oni wiedzą jak to się robi, więc generalnie są w stanie wyłapać jakieś rzeczy, które są głupimi pomysłami po prostu na dzień dobry albo zwalidować coś się nie da, coś się da, to zrobimy tak, to zrobimy inaczej. E, dwa to jednak jest dobry input, w szczególności, jeżeli chodzi o estymację, czyli ludzie po prostu wiedzą ile to działa. I teraz tutaj jest kwestia jak to zrobić, żeby oni nie budowali sobie safety net mówiąc, że coś zajmie miesiąc, jak powinno zająć dwa dni i tak dalej i tak dalej. I tutaj jest właśnie dobra rola. Znaczy wiesz, product manager u nas to było trochę inaczej, bo to by taki trochę no dla nas projekt był projektem, nie? My nazwaliśmy to project owner, że on musi umieć to zwalidować, więc to powinna być trochę techniczna osoba albo jakiś techniczny background albo ten, bo on powinien być w stanie być interlokutorem dla swojego zespołu, nie?
A trzeci element to tak trudne słowo. Starałem się, wiesz, słowniki czytałem wakacje. A trzecia rzecz, którą dodam, to trochę jest to, co ty powiedziałeś teraz, Sebastian o tym Founderze, ale skin the game, nie? Czyli generalnie jak zespół bierze udział w planowaniu tego i tak dalej, to nie może powiedzieć potem, że ktoś to głupio wymyślił. Znaczy może, ale wtedy mówią o sobie może, nie? Tak więc to taki punkt widzenia mój, że ja bym powiedział czasami chwała im za to, jeżeli sami wymyślili, a później stwierdzą, że to nie miało sensu. Im szybciej, tym lepiej. Dobra, słuchajcie, to jeszcze odnośnie planowania jeszcze jedno pytanie. No to a co jest z kolei też dobrym patternem? Planowanie w trybie ciągłym czy planowanie na przykład kwartalne albo roczne? Ja bym powiedział, że z mojego doświadczenia nie ma jednego, nie ma jednego pomysłu na to, który działa wszędzie, bo mamy różnego rodzaju zespoły. Będziemy mieć zespoły na przykład wiesz jak o CTO, o firmie produktowej, będziemy mieć zespoły na przykład odpowiadające za infrastrukturę utrzymanie i te zespoły raczej świetnie będą działały w trybie ciągłym.
Oczywiście mając pewne cele też do dowiezienia, ale bardzo znaczna część backloga będzie w trybie ciągłym. E, oczywiście będą projekty typu obniżenie kosztów infrastruktury o 20% i to jest projekt, który robimy na przykład na 40% capacity tego zespołu, tak? A natomiast tworzenie w ten sposób produktu może niekoniecznie jest dobrym pomysłem. Tutaj Przemek skomentował, że bardzo trudno jest pracować na celach rocznych. Ja rozwinę swój komentarz, czyli z mojego doświadczenia dobrze sprawdzają się cele typu Northstar, czyli mamy mamy konkretny cel, do którego dążymy, natomiast on jest wyznacznikiem kierunku, nie powinien być czymś, co nas zamyka. I teraz mój komentarz dodatkowy do tego, a co czymś, co nas zamyka może wiesz na takie jakieś podejmowanie właściwych decyzji, jeżeli dostajemy sygnały wtórne z rynku. Problem jaki jest z mojego doświadczenia jest taki, że na przykład jeżeli mamy do czynienia z startupami, które mają podpisane umowy WC, bardzo często mamy z góry na d trzy lata podpisaną roadmapę.
I to co się bardzo często w tego typu firmach będzie działo to jest to, że bez względu na ruchy rynku ta roadmapa musi się wydarzyć, bo transze są uruchamiane ze względu na na przykład osiągnięcie roadmapy. Więc jeżeli jest tak zbudowana umowa z WC, że jest roadmapa ponad metryki biznesowe, no to faktycznie wtedy ma możemy stwierdzić, no cele, wtedy cele roczne bardzo często mogą się okazać po dwóch latach nietrafione i to mocno. Mhm. Ja piję trochę do tego, że takie preczowane, jak to powiedzieć, ewangelizowane przez jakiś tam powiedzmy dailowych ewangelistów, planowanie w trybie ciągłym, zarządzanie bekologiem i tak dalej jest po prostu cholernie drogie ze względu na to, że samo planowanie jest drogim procesem. Więc ja wiem, że im więcej się coś robi, to tym tym większy się muscle buduje dookoła tego i to już jest łatwiejsze. Natomiast mimo wszystko planowanie w trybie ciągłym przy jakiś jakichś zależnościach, przy właśnie jakiś zarządzaniu zewnętrznymi oczekiwaniami i tak dalej, to jest nietrywialne i się po prostu większość nie opłaca.
Wiesz co, ja bym powiedział znowu inne doświadczenia, nie, ale że trochę znaczy podejście dogmatyczne jest złe, nie? Czyli że musimy wszystko robić tak albo inaczej. No bo [Muzyka] musisz mieć jakiś Nordstar, tak jak ktoś tam napisał albo któryś z was powiedział. I ten Nordstar, no to jest właśnie, wiesz, ktoś na rok ustawia co chcemy dowieźć, nie? Ale no na rok, nie wiem, na ileś nie mówi, chcemy wylądować tu, nie tuk, nie. I na tym się by the way wywala wiele organizacji organizacyjnie, że ustawia to nie wiem jakoś tam, nie? Ale i teraz ludzie muszą wiedzieć, że tam trzeba dowieść, nie? Mamy dowieźć 100 milionów użytkowników, nie? Okej. I teraz to kaskaduje w dół, ale ustawianie tych, wiesz, cel i to jest na następne trzy lata, nie? Ale wtedy ktoś, ja nie wierzę, że ktoś jest w stanie ustawić roadmapę produktową taką fixed na następne trzy lata, więc jakieś korekty kursu muszą być po drodze, nie? Więc teraz jest pytanie, czy te korekty kursu wykonujesz co miesiąc, co kwartał, co tydzień, codziennie i tak dalej. Nie, no i tu jest balans pomiędzy chaosem a zdrowym rozsądkiem. Nie wierzę, że można co tydzień robić korektę kursu, która wywala wszystko. Nie, no i tutaj Tomek w 100% się zgadzam.
Czyli na przykład w wypadku Revo to jest faktycznie wiecie roczny roczny kurs z celem. Oczywiście on jest do dowiesz, ale ty jako produc menagżer, jako zespół co kwartał walidujecie jak dojść do tego celu i z tego jesteście też rozliczan. Ja tutaj y przyznaję się szczerze, że nie wdrożyłem tego, bo nie miałem okazji, nie, ale do mnie na przykład przemawia to, co tam Basecamp w Shape Up napisał, nie? że jest jakiś czank czasu na dowiezienie i on musi być skwantyfikowany, żeby był skończony, bo trzeba coś dowieźć, nie? I to dobrze ustawia ten i oni mówią i dla nas ten czank czasu to jest sześ tygodni, nie? Bo to jest akurat tyle, żeby coś zrobić, nie jest to tak długo i tak dalej, nie? Więc myślę, że to trzeba po prostu wypracować. Tak, nie wierzę w jakie, znaczy uważam, że overhead związany na przykład z co dwutygodniowym jakimś przeglądem backlogu, decyzjami i tak dalej będzie za duży, nie? Więc to jest pytanie jaki jest ten czank czasu, który jest dobry. A ty pociągnijmy ten temat tego czanku czasu, bo to jest to się wiąże trochę z wycenami, bo miałem was zapytać według was podejście do samego wyceniania, bo to też jest wiele różnych podejść. To co powiedziałeś Tomek, to mi kojarzy mi się z powiedzenia podejściem pulowym, że mam jakąś pulę czasu, czyli okej, dobra. W ramach tego
na przykład kwartału mamy nazwijmy to sześć jednostek. Alokujemy te alokujemy te sześć jednostek. Na przykład to trzy alokujemy na produkt jak w przypadku 37 signals, nie wiem, hej. Dwie alokujemy na przykład na, nie wiem, nową wersję base campa, a jedno alokujemy na Omar albo cokolwiek innego. I teraz idea wtedy jest taka, że do as much as you can, zainwestuj. Tak. Zrób tyle nowych rzeczy z samej góry, jak ile tylko będziesz w stanie w ciągu w ramach tej puli czasu. Alternatywą jest wycenianie dokładne i w tym momencie budowanie faktycznie takiej road mapy, że to potrwa 5 dni, 7 dni, 8, 14, ale jeszcze inną alternatywą jest po prostu wrzucanie, ustawienie deadlineu i nie martwienie się jaka jest wycena, tylko na zasadzie, że te rzeczy mają dojechać przynajmniej hasłowo do daty takiej a taki. Co się u was najlepiej sprawdzało? Yyy, no i znowu specyfika, nie? Yyy, bo ja nie robiłem produktów, więc Wojtek odpowie z produktu, ty może jeszcze coś dorzucisz. Ja mogę powiedzieć z punktu widzenia naszego mieliśmy do dowiiezienia coś, nie? Czyli był zdefiniowany yyy znaczy inaczej na początku jest, no bo to jest produkt.
Mieliśmy do dowieszienia projekt. Projekt miał swój outcome. My nie robiliśmy głównie nie robiliśmy typu dostarczamy czas, tylko dostarczamy outcome, nie? No i teraz musisz przybliżyć realność wykonania tego produktu w czasie, który masz założony. No to dla nas to był deadline projektu, dla kogoś, kto robi produkt musi być szybyt, nie? Teraz skąd to się bierze? No biznes. Po prostu trzeba albo dowieźć i sprawdzić czy coś działa, nie? E, też i tutaj zaraz wjadę z Watleem, ale to za chwilę i wiesz i pierwsze jakby estymowanie czy planowanie jest po to, żeby zobaczyć czy w ogóle to co chcemy dowieźć nie mieści się realnie w tym co w jakimś przybliżeniu, w tym co mamy, jaki mamy czank czasu, budżetu, czegokolwiek, nie? No i to musi zostać w jakiś sposób wykonane, czy to zrobi jedna osoba, dwie i tak dalej. To jest nawet, możesz powiedzieć kawałek zarządzania ryzykiem, nie? Czyli czy to co mamy jest w ogóle realizowalne, nie? I teraz ja ci mogę powiedzieć jak to u nas działało, co najlepiej się sprawdzało. Potem kilka mieliśmy trochę mieliśmy dewiacji od tego, potem wracaliśmy i tak dalej, nie? Ale najlepiej się sprawdzało u nas e rozbicie tego, co mamy dowieźć na jakieś grube kawałki, nie za niskie. Ja w ogóle uważam, widziałem ludzi, którzy estymują
rzeczy poniżej jednego dnia. To jest bez sensu, nie? że coś zajmie im dwie godziny. To w ogóle jest aberacja, nie? Jak byłem młodym architektem, znaczy wtedy konsultantem jeszcze, to jeden młody architekt powiedział mi przy pierwszym przybliżeniu w ogóle ten jakby projektu, produktu, cokolwiek, wypisz wszystkie elementy, które wpływają 10% na zmianę albo zakresu, albo pieniędzy, nie? Czyli wypisz po prostu rzeczy, które mają 10% impakt i zaplanuj, czy jesteś, ile ich w stanie jesteś wstawić, nie? I nam się sprawdzało po prostu bardzo grubo, że mamy rzeczy, które zajmują jeden, tak to nie jest dokładnie, ale powiedzmy 1 d tr dni, nie? E ich koszt, ale bardzo grubo i trzy rozmiary tylko i wypisanie ile ich mamy i przypisanie im rozmiaru. I to było pierwsze przybliżenie i się okazywało, że to jest dobre ćwiczenie, nie? Yyy, bo po prostu ludzie musieli się zastanowić, czy to jest duża rzecz, średnia, czy mała, ale bez wchodzenia w szczegóły, nie? Czyli ktoś opisywał ten yyy user story, rozbijał je, nie? I potem zespół przypisywał do tego rozmiary po prostu albo ten, kto wyceniał projekt, nie, i patrzył, czy mu się w ogóle jakby zadanie mieści w kubełek.
Mhm. Nie. I to jest pierwsze przybliżenie tego, nie? Wojtek, jaka jest do ciebie preferowana taktyka, jeżeli chodzi o takie wycenianie i planowanie szczegółowe? z czasem nie ma chyba nie ma jednego, wiesz, bo tak naprawdę mamy różnego rodzaju projekty, różnego rodzaju zespoły, więc ja akurat jestem zwolennikiem tego, żeby każdy zespół i tu miałem wjechać z Worldleem, żeby każdy zespół miał kontrakt publiczny, można by powiedzieć, na którym się wszyscy jesteśmy kompatybilni, czyli na przykład właśnie planowanie kwartalne i jakaś weryfikacja w trakcie kwartału. To jest co dwa, co cztery, co sześć tygodni to już mniejsze auto. Natomiast jak panuje, jak wewnątrz panuje zespół, według mnie to jest już do yyy do dla zespołu yyy coś co yyy wiesz yyy bardzo bardzo wiele rzeczy y myślę, że widziałem a i ciężko mi powiedzieć jedną rzecz, która absolutnie zawsze działała. To na 100%. Natomiast to, co mogę powiedzieć antypaternem na pewno jest, że bardzo często yyy jeżeli chcemy stworzyć yyy estymaty a to tworzymy je na na poziomie niesamowitej szczegółowości.
Według mnie do do planowania wstępnego powinny być Gulinaf. Takie wiesz o w 80% mamy powiedzmy jesteśmy mniej więcej tak jak powinno być. a że to się będzie zgadzało, a później doszlifowujemy i jesteśmy otwarci na zrobienie tradeoffu. Wiecie, bo to jest tak, że każdy projekt w momencie, kiedy nad nim zaczynamy pracować, mamy wymagania funkcjonalne, niefunkcjonalne, ale nie wiem czy kiedykolwiek robiliście sobie ćwiczenia architecture cata albo porządny system design interview. Specjalnie przed kandydatem chowa się około 50% wymagań i to kandydat ma się dopytać o nie, bo to symuluje też prawdziwą sytuację biznesową. Czyli tak, przetłumaczę to na troszeczkę bardziej naukowy język. Naukowy język, czyli mamy to, co nam normalnie dostajemy w briefie projektu, jakkolwiek to zwał, to jest non knowns. Mamy oprócz tego unnown, un i unnows, prawda? Czyli coś, co unknown uns, czyli coś, czego nikt nie wie, że nie wiemy, a yyy yy dodatkowa rzecz to jest nikt nie wie, że wszyscy wiemy. Przykładowo to jest jakiś implite, przepraszam, y rzeczy, które y wiemy na przykład, że
Google Cloud może mieć, czy tam AWS może mieć jakieś ograniczenia i w przyszłości się ich dowiemy, żeby zobaczyć jak to wpływa dokładnie na nasz projekt. Więc tworzenie pełnych estyma do samego początku a jest po pierwsze jest praktycznie niemożliwe. Po drugie tak jak Sebastian kilka razy powiedziałaś jest bardzo drogie i pytanie czy daje nam to co to co powinniśmy dostać więc ja bym sugerował żeby zrobić estymację good enough być mieć priorytety i faktycznie zacząć od tych rzeczy które są najważniejsze na przykład w danym kwartale. być gotowym na tradeofy, jeżeli chodzi o rzeczy, które się dopiero dowiemy. Ja mogę powiedzieć czego nie robić, nie nowa trochę. Znaczy tak, po pierwsze to y mamy trochę komentarzy, to możecie sobie je przejrzeć, jak ja będę mówił i Przemek Kurczyński, musimy go zaprosić, może jakoś, bo on mówi, że u niego Shape Up bardzo dobrze działa i że tutaj jest właśnie to, co fajnie przedstawia Shape Up jest podejście z apetytem biznesu sytuacja zdania i że to dobry mindset.
Swoją drogą pytanie, jeżeli ktoś wie, dlaczego macie niektórzy takie koronki yyy z numerkami, jeżeli to oznaczy, że płacicie nam za tą rozmowę, to już w ogóle super. [Muzyka] Boże, to jest birthday party, to jakoś nie wierzę. Dobrze powiem. Y teraz wjadę z Wleyem na chwilę. To jest to, co Wojtek powiedział. Y różne zespoły mogą mieć różny tryb estymowania, nie? Bo to jest właśnie prędkość ruszania się też, nie? Jak masz operations, to oni na co innego patrzą, jak masz produkt, to masz coś innego i tak dalej. Jak masz takie estymowanie to jest budowanie oczekiwań. To nie to, że zespoły se mogą mieć. To jest kwestia współpracy, że to jest bardziej planowania i pokazywania oczekiwań właśnie, bo to jest ustawienia oczekiwań na zewnątrz tak naprawdę, kiedy coś dowieziemy, nie? No duży błąd, który ja tu widziałem za i go ten to jest właśnie to, co powiedziałem wcześniej, że po prostu jak ludzie podchodzą do tego pierwszy raz albo nawet nie pierwszy raz, to bardzo często idą za bardzo w szczegóły, nie? Czyli zaczynają się skupiać na rzeczach, które po prostu nie mają jakby yyy przełożenia tak naprawdę na outcome, są jakieś, że coś konkretnego zrobią, planują konkretne działania, nie? I teraz na tym etapie ty nie planujesz konkretnych działań, tylko patrzysz na to, czy dowieziesz to, co ma być dowiezione, żeby biznes działał, nie? E,
i ale musisz sobie to rozbić na zadaniach, to jesteś w stanie zaplanować, ale zadania sobie potem ludzie rozbiją. Wiesz co? I dlatego właśnie ja uważam, że ten trochę jak Wojtek powiedział i kilku ludzi też w tym, że granularność jakaś pod tytułem tyle zmieścimy w tym jest okej, bo potem ludzie sobie rozbijają te zadania i tak nie jesteś w stanie upfront tych zadań rozpisać, nie? Dopiero potem ktoś na pew do pewnego poziomu mecia, hierarchia, outline. Okej, ale wiesz, bierz zadanie i pisz i wiesz w Pireko potrzebuję zrobić to, to to i to. Ale ja bardzo często widziałem, gdzie ludzie wchodzili już wiesz typu zdeplojuję to, zrobię to, zrobię to i zrobili taki to listę z tego, nie? I pójście w to listy na etapie jakiegokolwiek planowania co dowieziemy jest bez sensu, nie? Bo to po prostu nie do tego służy. Jeden komentarz, bo jesteśmy już w połowie czasu, a jesteśmy ciągle na planowaniu, a ja mam jeszcze ciągle dużo pytań, więc pewnie nam się to rozciągnie na na ten na dwa odcinki przynajmniej, dlatego że ja nie zrezygnuję z tych pytań. Dobra, słuchajcie, teraz ciężki temat i on jest związany z jednym z pytań, które było na czacie, ale potrzebuję zadać nap swoje pytanie, żeby potem przejść do tamtego.
Dobra, jak już współpracujecie z tymi product managerami, program manager kimkolwiek, żeby się dowiedzieć co tam tak naprawdę mamy zrobić, to kiedyś w starych dobrych czasach albo starych złych czasach to się robiło jakieś zbierały się wymagania, dokumenty się z tego robiło. Oczywiście wszyscy, nazwijmy to propagatorzy agile twierdzą, że dokumentacja jest zła. Ewentualnie jakieś prototypy, i tak dalej. Nie mam żadnego. No więc pytanie, co się u was sprawdza? Czy tworzycie dokumenty typu PRD? Macie jakiś swój własny format, czy działacie w jakimś innym trybie? Jak to działa, żeby żeby ta wiedza jest skonkretyzowana? Co ma zostać zbudowane? Znaczy ja szybko wejdę tylko, bo ja teraz to wszyscy wiedzą, że mało takich rzeczy robię. A jak ktoś nie wie, to otwarcie o tym mówię w tej chwili, że ja teraz mało takich rzeczy robię, ale yyy Ale robiłeś, y robiłem. Yyy i to robiliśmy w różny sposób. I teraz yyy jakbym miał zsumaryzować swoje doświadczenia dobre i złe, dokumentacja w jakiś sposób jest potrzebna. Tak. Teraz zły sposób to jest bardzo statyczny, czyli duży dokument, w którym to jest opisane i tak dalej, i tak dalej, nie?
Znaczy inaczej moje doświadczenie mi mówi dlaczego, bo dużo rzeczy się zmienia. To co nam najlepiej działało, a potem niestety to zarzuciliśmy z różnych powodów to było, bo to wiesz taka trochę retrospekcja, nie? To było zbieranie tych czanków w jakimś systemie. My akurat używaliśmy, nie wiem, Visual Studio Code, znaczy tam wiecie czego, DevOpsów, przepraszam. No, no, no ale i potem automatyzowanie, wyrzucanie tego dokumentu, czyli był dokument, ale ten dokument był w standardowym formacie i on zawierał konkretne rzeczy i one były na podstawie repo, nie? Yyy, więc potem jakbym miał powiedzieć, to dla mnie to nie musi być, znaczy zbieranie wymagań i ich opisywanie jest potrzebne. One powinny być yyy w jakiś sposób najlepiej wersjonowane, żeby dało się zobaczyć, dlaczego coś się zmieniło, ktoś opisał i tak dalej, nie? i powinny żyć tam, gdzie ze współpracuję i dlatego te Wordy, czy jakiekolwiek inne dokumenty często czy confluencey twój twój sorry Atlasen musiałem przez chwilę pracować z konfluensem i to był zwyczaj te dokumenty to masz powinien spisywać.
E, zależy na jakim etapie. Nie, nie wiesz co, u nas robił to tak zwany produkt owner na pierwszym etapie, bo czy bo on po prostu brał dokument, który mieliśmy, czy ofertę od klienta. On rozmawiał z klientem, nie? I on przekładał to, co usłyszał od klienta na to, co powinno być zrobione. Czyli system ma robić to, system ma robić to, system robić to, nie? A potem ludzie, którzy już brali się za robienie tego, rozpisywali to niżej jeden level, czyli epiki i tak dalej w dół, nie idąc, a potem ludzie już sobie ten, więc no bo człowiek, który dostaje to, powinien być w stanie przeczytać i dowiedzieć się, co ma zrobić, żeby sobie zaplanować pracę. A jak nie wie i to było na przykład dla mnie dobre doświadczenie, to w tym samym systemie zadaje pytania i tak dalej, czyli to żyje tam, gdzie oni pracują, nie? No dlatego te wordy i tego typu rzeczy dla mnie według mnie one znaczy duży jeden dokument źle żyje, nie? O tak bym powiedział. To duż jeden dokument jest abstrakcją, bo wiesz wystarczy jest wiki notion czy coś są polinkowane dokumenty i co i masz polinkowaną chmarę dokumentów i to niewiele zmienia.
Ale każdy pracuje nad swoją częścią, a może pójść i sprawdzić dlaczego co się wzięło, nie? A nie, że wydostajesz jeden monolity dokument, który był bardzo często w przyszłości dla mnie praktyką, że wydostawałeś jeden monolit, nad którym potem, żeby ktoś coś zmienił, to zajmowało dwa tygodnie, bo wersjonowania tego typu rzeczy i tak dalej, i tak dalej. Nie. Wojtek, a jakie ty masz dobre doświadczenia z tym związane? Mogę powiedzieć coś, co nam się teraz bardzo dobrze sprawdza przy tej ilości projektów i tym tempie, które mamy, to jest coś takiego, że każdy projekt, który zajmuje przynajmniej tam powiedzmy więcej niż jakąś jednostkę czasu, you name it, tak, czasami miesiąc, czasem powiedzmy do kwartału, tworzymy tak zwanego one pagera, czyli co pewnie coś, co Tomek ty spełniałeś, czyli dlaczego to robimy i wytłumaczenie wiecie, takich podstawowych rzeczy i linki do kolejnych dokumentacji. Tutaj wspomniano ADR i RFC. I teraz nie wiem czemu, bo to trochę inny temat, nie do końca, bo na przykład coś co nam się sprawdza, jeżeli są zmiany architektoniczne, to faktycznie robimy system design document na zasadzie właśnie RFC, czyli jest mamy dokumentację wcześniej
oczywiście do tego dodam, mamy prawdopodobnie już jakieś flow w produkcie mamy, mamy zrobione design w figmie. i siadamy do architektury i to jest na zasadzie właśnie RFC. A dosyć takiego chodzi o to, żeby to było jak najlżejsze. Prośba o skrytykowanie, wiecie, dlaczego to może nie działać. Słuchajcie, gdzie to mi może wybuchnąć? Może na tej zasadzie albo czego co coinąłem. Z tego mogą faktycznie wziąć się ADRy, ale dla mnie ADR to jest konkretne podjęcie decyzji na poziomie na przykład całego dużego zespołu, która jest w przyszłości może nawet wiążąca dla tego zespołu. Czyli wiecie, jakiś techniczny problem od tego momentu rozwiązujmy w ten sposób. Więc coś takiego. I teraz mając mając to zespół też ma możliwość do tworzenia dokumentacji jaką potrzebuje. Coś co z mojego doświadczenia się bardzo dobrze słuchajcie sprawdza, to jest decision log.
I już wytłumaczę. Mamy taki dokumencik leciutki. To może być nawet, słuchajcie, Google Sheet lub cokolwiek tam używacie, a który zbiera yy zbiera yyy decyzje, które mamy do podjęcia, bo my bardzo często lubimy szybko podejmować decyzje, nawet jeżeli one nie muszą być w danym momencie podjęte. Więc zbieramy sobie decyzję do podjęcia z szybkim opisem osobą, która zgłosiła jakiś na przykład problem do rozwiązania i tak dalej, i tak dalej i mamy decyzje podjęte w projekcie. To się szczególnie sprawdza w projektach, które są na poziomie bardzo wielu zespołów, a lub na przykład trwają dłużej niż kwartał, żeby pamiętać dlaczego podjęliśmy pewnego rodzaju decyzję. Więc polecam to jako praktykę, która się nam bardzo fajnie sprawdziła, ale daleko skaczecie ziomeczkowie i i teraz tutaj Wojtek i chłopaki na czacie też dlatego, że mówicie na przykład o ADR albo mówicie o FC i ale to już jest rozwiązanie techniczne. To już jest wtedy, kiedy my zrozumieliśmy co oni od nas chcą i takaz opisujemy jak to rozwiązanie powinno wyglądać.
ewentualnie dyskutujemy we własnym wewnętrznym gronie, ale jak damy takie RFC na przykład product managerowi do zwalidowania, no nie, to nie zadziała. Jak chcemy sukces projektu weryfikować po tym, czy RFC zostało zaimplementowane, to też nie zadziała. Tu jest jeszcze ten jeden krok wcześniej, czyli to co kiedyś było jakimś powiedzmy plikiem, nie wiem, dokumentem z wymaganiami, a najbliżej tego jest ten obecny PRD, o którym już tam chyba ktoś ktoś wspomniał, czyli de facto specyfikacja tego, co my byśmy oczekiwali od strony problemu trochę, no co to ma robić po prostu. Tak, dokładnie. Tak. I i taka specyfikacja też może zawierać pewnego rodzaju modele koncepcyjne, czy nie wiem, budujemy modele rozliczeń, to jak to powinno wyglądać, jaki tam jest flow, jak tam są aktorzy, jakie tam są interakcje. Znowu to to to są oczekiwania od strony biznesowej, nie? Że wprowadzamy takie taki typu użytkownika, nie ma tam nic o żadnym języku programowania, żadnej bazie danych, nothing zupełnie, tylko jest to dokument, no który potem rzeczywiście potem przy nazwijmy to odbiorze możemy możemy rozwinąć, tak? Tylko to PRD może zawierać, słuchaj, non functional requirement, tak? Czyli tam mamy PRD z reguły składa się, to jest taki dokumencik, który składa się z celu projektu biznesowego, tak jak powiedziałeś, functional requirements,
bardzo często podanych w formie use cases, user cases, jobs to be done, zależy z czym pracujemy. Nonfunctional requirements. Tutaj też zwrócę uwagę, że PRD często zawiera na przykład w naszym przypadku compliance requirements, tak? Czyli, że coś może albo nie może być zrobione. I robicie, robisz, robicie u was w firmie? Yyy, tak podobnym, może nie nazywamy tego PRD, ale myślę, że format jest dosyć podobny. Jeszcze szybko dodam, że bardzo ważnym elementem, który ja bardzo polecam, żeby był zawarty w PRD jest coś, co my nazywamy dependencies, czyli powiedzmy wszelkie powiązania lub uzależnienia, ewentualnie ryzyka, które mogą z tego wyniknąć i metryki sukcesu, czyli kiedy wiemy, że ten projekt się udał. To jest bardzo dobre, żeby jasno zdefować zdefiniować też co jest out of scope, bo jeżeli mamy metrykę sukcesu, to wtedy jest faktycznie dużo łatwiej skweryfikować yyy wiesz out of scope.
Mhm. A tu ktoś mnie striggerował, Łukasz mnie striggerował na czacie pisząc albo event storming, więc ja specjalnie tego nie pokazywałem, powiedziałem, że może myślałem, że przegapisz. Więc pytanie jest takie, czy ktoś z was faktycznie korzysta z eventingu i nie jest, nie wiem, zawodowym konsultantem application modern application modernization i a jeżeli korzysta, to w jakich scenariuszach, w jakich sytuacjach? Nie mówcie, że zawsze, bo nie łyknę tego. Ja ja mogę powiedzieć, że korzystamy. Yyy albo słuchajcie, jest w zależności od tego, bo tak naprawdę wiecie, event storming to dla mnie też nie jest jedno narzędzie, które zostało zdefiniowane i zresztą sam autor mówi, nie zostało zdefiniowane, także nie możecie go zmodyfikować, więc ewentualne modyfikacje tak, żeby to działało dla zespołu są jak najbardziej dopuszczone. Więc powiem krótko. Owszem, zdarza się przy szczególnie przy procesach, które których dobrze nie rozumiemy, to wtedy to jest faktycznie to jest dobre narzędzie, żeby wyrównać wiedzę w zespole.
U mnie ja się nie wypowiem, ale tylko coś powiem, bo ja sam nie brałem nigdy udziału. Elementy zespołu, które są na czacie mojego może się wypowiedzą, bo one brały udział. Widziałem jak nasze zespoły z tego korzystały i chyba najczęstszy sposób użycia to był tak jak Wojtek powiedział, że wydobycie z klienta tak naprawdę nie, co to ma robić, jak to ma działać, co oni chcą. Więc to jest chyba było używane bardziej jako sposób dyskusji, żeby wyciągnąć z klienta na końcu wymagania, ale to jest czysto teoretycznie widziałem ich przez szybę, jak przyklejali karteczki i robili różne inne zabiegi. Ja się do tego sporo yyy nie nie powiem, że odbijałem, no dotykałem tego, ale powiem ci, że ja mam duży problem z tym z tym sformułowaniem, że co to ma robić, jak to ma działać. dlatego, że w moich doświadczeniach event storming nie działa, jeżeli projektujemy coś zupełnie nowego, dlatego że wtedy nie ma tego jednego precyzyjnego lingo tego is lang zaczynają spekulować i to się do jednej mapy nigdy nie spina. Event storming ma szansę się spiąć i całkiem nieźle działa. Jeżeli na przykład przychodzimy gdzieś do jakiejś firmy, coś modernizujemy, czyli już jest jakiś proces, oni już jakoś działają w jakimś trybie albo pracują z jakimś legacy
systemem i teraz nie ma nigdzie do jego dokumentacji, trzeba wydrzeć tym ludziom powiedzę z gardła. Ja to widziałem dokładnie w takim użyciu. Ja to widziałem dokładnie w takim użyciu, że wiesz, jest firma, która coś robi i chce mieć software, który wiesz coś z tym zrobić. jest jak zespół, który ma to zrobić, ma wydobyć od nich jak to ma być wedy działa to wtedy działa, bo wtedy jest szansa na wspólne lingo jest wtedy szansa, że oni są te punkty spięcia kto już są, więc ci ludzie nagle mają ten aha moments przy tym białym boardzie gdzieś tam przy tym białej rolce papieru. Chyba narzędzie jak każde, nie? No jest po prostu czy wiesz po co je używasz i do czego nie? Forma warsztatu tak no ma tą ma tą przewagę, że że jest bardzo charakterystyczna wizualnie została nazwana, więc wszyscy wiedzą o co chodzi. Dokładnie się zdjęcia też potem robi przy tej tablicy. Hell yeah. Kolejny mit, albo nie mit, może, może fakt, słuchajcie, a budowanie prototypów i MVPS, e, czyli wypuszczanie jakiejś zupełnie wstępnej wersji tam memle product działa, nie działa? Używacie tego, nie używacie tego, jak to wygląda w praktyce to ja teraz wejdę i używamy bardzo często.
Każdy nowy feature jaki widzieliście, to jest praktycznie rozpoczęty jako MVP. Bardzo często to jest nawet jako tak zwany pet, czyli tutaj cofnę się do samego początku. Jeżeli masz pomysł na stworzenie jakiejś funkcjonalności większej, szczególnie która będzie wymagała zbudowanie zespołów, a budujesz tak zwany bet, to jest o tyle ciekawe, że to jest trochę działa jak wewnętrzne VC, czyli board, Revoluta, tam CEO, CTO i kilka jeszcze innych osób weryfikują twój pomysł i i tak jakby inwestują w twój pomysł. I wtedy bardzo często właśnie masz bardzo krótki okres czasu, żeby zweryfikować jego sukces. To jest z reguły 12 miesięcy, słuchajcie. Więc ty musisz już bardzo szybko w pierwszym kwartale wypuścić już MVP. coś, coś, co będzie na jakiejś grupie klientów już testowane. Yyy, yyy, oczywiście yyy w dojrzałych produktach też to tak działa, też tak też to jest testowane i tutaj podkreślę, bardzo często yyy idea jest taka, żeby daną funkcjonalność zmieścić, nową zmieścić w kwartale kropka. I raczej rzadko kiedy jest MVP, jest dłuższe niż kwartał.
Ja znowu tak w lekkiej kontrze, nie będę mówił jak to u mnie działało, nie działało, ale znowu w lekkiej kontrze powiem tak, z kimkolwiek by na ten temat nie rozmawiał to mówią, że tak nie to jest bez sensu, bo żaden pro manager się nie podejmie jakby podpisania swoim własnym nazwiskiem pod tym, bo to jest not enough, nie? To musi być ten efekt muszę innej rzeczy. Musę innej rzeczy kompletnie. Dlaczego? Bo ty mówisz o polityce i unikaniu ryzyka, a nie o tym czy MVP działają. Nie, to nie jest polityka. To jest to jest zidentyfikowanie tego punktu przegięcia, kiedy już MVP jest good enough, żeby faktycznie była atrakcja. To nie jest polityka. Wiesz co, to inaczej to yyy ja uważam, że MVP działają. Tak teraz jest yyy to co powiedziałeś, to dla mnie jest trochę w ogóle wypatrzenie idei, nie? No bo najlepszym przykładem MVP y jaki widziałem zrealizowany w swoim otoczeniu to było to, co doprowadziło wiesz do y ten taki zamek Tedy, który tam jeden z moich byłych wspólników dalej rozwija, nie? No bo to był po prostu to jest tak, mam pomysł, najpierw waliduję nawet swoimi może ten czy ten pomysł to ma sens, potem waliduję w jakikolwiek sposób, czy to się da zbudować, wiesz,
cokolwiek, nie? I każdy cię przybliża do prawdopodobieństwa, czy to jest to, co chcesz, nie? Teraz no i to tak literalnie się odbyło, nie? Pomysł, research, płytka, która robi BIP, płytka, która robi BIP zdalnie i tak dalej, i tak dalej, i tak dalej, nie? I każda iteracja przybliża ci, waliduje ci twoje założenia i pokazuje ci czego nie wiesz. Więc ja jestem fanem MVP. Teraz zależy jak ten walidacji produktu, projektu, pomysłu, zanim w niego dużo zainwestujesz. I teraz dużo to jest zależy co robisz, nie? E, ja się spotkałem wiesz już czysto na moim poletku jako CTO firmy usługowej wtedy, nie, że z dwoma podejściami, czyli na przykład ja robiłem takie podejście, gdzie naszym MVP na produkt usługowy to było zbudowanie pomysłu na produkt, wypuszczenie go na rynek, zrobienie dookoła niego jakiegoś szumu informacyjnego, żeby się znaleźć czy jest klientem, nie? Jak był to dowoziliśmy pierwszą wersję i jąowaliśmy. Firmy spotkałem, które miały pomysł i walidowały go w tak sposób, że 6 miesięcy nad nim pracowały i potem wychodziły z nim na rynek. Nie no i wtedy są 6 miesięcy w pupie i jest flop przeważnie, bo nie miały feedbacku. Więc ja uważam, że to to jest pytanie co to
jest MVP i po co je robisz, ale on takie iteracje i walidowanie pomysłów ma sens, nie? No dobra. A, ale to co powiedziałeś o project managerze, to ja to rozumiem, tylko ja bym to zakategoryzował w kwestię unikania odpowiedzialności rozgrywki polityczne, a nie czy MVP ma sens. Ale to nie tylko toż wiele firm działa w ten sposób, że każdy projekt jest jakimś betem, jakąś inwestycją, więc w związku z tym też oczekują, że będzie ten efekt wow. Po prostu mówią wprost efekt wow na przykład. I ten efekt wow to czasami jest kwestia tego, że funkcjonalność kompletne odświeżenie wyglądu, na przykład kompletnie nowa aplikacja mobilna. Okej, to to patrzymy na to inaczej, bo dla mniep jest sposobem zarządzania ryzykiem, nie? I to jest kwestia, jak wywalę się po dwóch tygodniach i nie wydałem 100 000 zł, to to jest sukces, nawet jak to nie działa i źle wygląda, nie? Mhm. Wiesz, ryzykiem możesz też zarządzać jakimś przez doc feeling, jakieś sprawdzenie tego wewnętrzne albo w ogóle friends and family. Więc friends and family nie musi być tożsame z MVP, nie?
Dobra, Wojtek jeszcze ruszył jeden fajny temat, którego nie dotknęliśmy tutaj, który też może nas trochę dyskusję może trochę rozkręcić. NFRY, wymagania niefunkcjonalne. No bo tak, one niekoniecznie muszą płynąć ze strony biznesowej. wcale nie, wręcz, wręcz przeciwnie, ale jak pewne oczekiwania względem jakości rozwiązania, nie wiem, czasów odpowiedzi, maintainowalności tego, reliability, scillability, miliona innych technicznych aspektów, no generalnie powinny być. Więc jak to u was działało najlepiej? W sensie jakie tutaj sugerujecie paterny, a jakie widzieliście antypaterny, jeżeli chodzi o to skąd się biorą NFRY, jak są formułowane, od kogo one się biorą, może też w ten sposób? Wojtek. No ja bym powiedział, że nie z jednego źródła. To po pierwsze. A po drugie to co się chyba dobrze sprawdza, to jest to, żeby pewne rzeczy były jasno określone z góry, żeby nie trzeba było koła wymyślać na nowo. O ile o ile to nie jest specyficzna sytuacja, już je wytłumaczę, żeby nie nie doprowadzić do sytuacji, że każdy zespół ma inne wymagania niefunkcjonalne, bo później możemy się rozbić o dowożenie wymagań niefunkcjonalnych, które nie są łatwe,
proste. Już daję przykład. Może być tak, że response time na endpocie zespołu, który tworzy rozwiązanie wewnętrzne jest większy niż zespołu, który który tworzy na przykład zewnętrzne API, prawda? I może dojść do sytuacji, że ten zespół zamiast rozwiązać konkretny problem biznesowy będzie rozwiązywał jak dowieźć bardziej agresywny bardziej agresywny SLO. przykładowo. Więc z mojego doświadczenia to co się sprawdza, to żeby ustandaryzować to wszystko co jest dałoby się ustandaryzować, żeby to było jasne, oczywiste dla programistów, jeżeli chodzi o wymagania. Pozostałe rzeczy upraszczać. Yyy, bardzo często yyy n yyy NFRY, czyli nonfunction requirement są źródłem wprowadzania bardzo skomplikowanych rozwiązań i bardzo yyy dziwnych technologii tylko dlatego, że ktoś pomyślał, że dzięki temu będzie prościej, łatwiej dowieźć właśnie NFR.
Mogę dać przykład, wiecie, no daj. Poprzez dany danyer na przykład będziemy sięgać do innej nowej jeszcze nieużywanej bazy danych lub sposobu przetwarzania danych. Po to tylko żeby dowieść NFR. Znaczy to jest nonfunctional requirement pod tytułem Team chce się pochwalić, że użył bazy danej, której nikt jeszcze nie użył. You name it. Ale wiesz o co mi chodzi, że na przykład to może być przykładem potrzebujemy wyszukiwać i automatycznie zespół sięgnie po Elastic Searcha, tak? Pomimo tego, że przykładowo on nie będzie potrzebny w danym projekcie. Czy to jest odpowiedzialność? TNF jak to zwykle robicie w projektach, których ja pracuję teraz, prawda? w produkcie y jest to odpowiedzialność zespołu i to jest na przykład elementem tego dokumentu system design, który wspomniałem przy okazji właśnie takiego lekkiego procesu RFC, a oni sami sobie to definiują, kto ich challenguje?
Nie, nie, nie. Tam jest sporo, spora część ustandaryzowana. Właśnie miałem się spytać, a istnieje coś takiego? Teraz pokrillujemy chwilę Wojtka. M istnieje coś takiego właśnie trochę odpowiedziałeś, bo jak ja jeszcze byłem sobie w Microsofcie dawno temu, więc pewnie to się zmieniło z 10 razy, ale wtedy tam istniało coś takiego, co się nazywało Engineering Criteria, nie? Czyli to były wspólne NFR, który wszystkie rzeczy robione w Microsoftie muszą spełnić, nie? SL Response time, interfejs konkretny. Na przykład wtedy akurat wchodził PowerSell i właśnie wiesz NFrem było, że każdy musi wystawić powershell module, nie? To po prostu kawałek inżynieria criteria, że wiesz, ma być API nie słynne Amazonowe, nie wiem czy to prawda czy nie, ale że wszystko ma wystawić API do wszystkiego innego i tak dalej, nie? E, więc zakładam, że coś takiego macie. Tak.
Odpowiedź jest tak. Odpowiedź jest krótka takać. Jak najbardziej tak. A to jest dobre, dobre pytanie, bo w sumie pewnie gdzieś gdzieś by się znalazło, że można coś upublicznić. Do tego wszystkiego jest jeszcze bardzo daleko posunięty. Tutaj Tomek wspomina w komentarzach technology strategy. My mamy bardzo podsunięte technology governance nawet, czyli mamy własne narzędzia do w pewnym sensie wymuszania niektórych NFRów i i automatyzacji. Bo teraz dlaczego to jest istotne? Słuchajcie, standaryzacja oznacza automatyzację, automatyzacja oznacza niższe koszty, łatwiejsze utrzymanie, mniejszą awaryjność, więc to wszystko tak naprawdę ma bardzo głęboki sens. Więc u nas faktycznie jest to taka strategia, nie nazwałbym tego może strategią, ale faktycznie technology governance, gdzie spora część NFRów jest wewnątrz tego narzędzia i ona jest monitorowana, to wszystko jest monitorowane oczywiście wszelkie przekroczenia NFRów są też alertowane zespołom i tak dalej i tak dalej. Więc to jest, ale tak jak Sebastian pewnie już wspomniałeś, utrzymanie miało być później, natomiast to jest oczywiście znane. Jeżeli ja doprodukuję dany rodzaj y usługi,
serwisu, m wystawiam konkretne API, to ja znam te faktycznie znam z góry oczekiwane ode mnie NFRy. Część NFRów, by the way może wynikać z compliance w naszym przypadku, tak? Czyli na przykład regulator oczekuje, że mamy przykładowo Open Banking API z takimi takim z takimi takimi wymaganiami nietnicznymi, przepraszam, no niefunkcjonalnymi. Mhm. y trochę w tym samym temacie, ale jeszcze wrócę do tego, co chłopaki pisały wcześniej na czacie, bo tam się pojawiały AT, pojawiały się tam RFC, to są już dokumenty bardziej techniczne i teraz zakładam, że część z nich, przynajmniej na przykład ADRY to jest też dokumenty, które nie dotyczą tylko i wyłącznie jednego teamu, tylko dotyczą większej ilości teamów. Więc pytanie, jak to uspójniacie? Czy tworzycie mechanizmy typu gildie, mechanizmy typu na przykład rola architekta, który takie rzeczy uspójnia, mechanizmy typu jakieś, nazwijmy to, regularne cykliczne spotkania, gdzie tego typu tematy są dyskutowane. Jak ta kto uje tą wizję techniczną na pewnym poziomie i kto challengeuje te decyzje techniczne zespołu, które są podejmowane w tym tam
trybie planowania, bo automaty nie wszystko macie w automatach, nie wierzę. Tak, tak, tak. To myślę, że wiesz, kierunek, no to to jest oczywiście CTO. W każdej organizacji to jest rola CTO. Kierunek to co może Tomek określa rą strategii, chociaż dla mnie to jest trochę mało namacalne, jeżeli to zamkniemy jako technology strategy. Natomiast faktycznie, jeżeli byśmy pomyśleli takie pryncypia, szczegóły tego technology governance, to faktycznie jest rżekturę. Ona na przykład w rewolucie jest ustandaryzowana, żeby było ciekawiej. Więc mamy pewne standardy się da inaczej. Tak bym strzelił. Da się inaczej, ale jeżeli chcesz właśnie wiesz nie rozwiązywać koła na nowo i no to jest wiele zalet, co to jest na inną dyskusję, to to warto robić. Może tak powiem. Natomiast faktycznie jest coś takiego jak global SDR process, czyli system design review, czyli Sebastian, ja bym nie powiedział, że to jest rola architektów, tak, ale to jest rola, to są inżynierowie inni bardzo doświadczeni w firmie, którzy faktycznie potrafią ci
twój RFC dokument usiąść z tobą i przejrzeć go również wskazując na podobne rozwiązania gdzie indziej. [Muzyka] Miałbym pytanie wyciągające i to może jeszcze szybko dodam na poziomie na poziomie na przykład już konkretnego departamentu, czyli na przykład tak jak ja pracuję w bankowości biznesowej, a to mamy bardzo podobny proces, ale wewnątrz departamentu. W związku z tym jako inżynier każdy może poprosić o review doświadczonych inżynierów. Y więc to jest też yyy a taka ciekawostka. Natomiast każdy przygotowuje ten dokument. U nas w firmie jest oczekiwane, że od roli mida w górę każdy jest architektem. Nie ma oddzielnej roli architekta. Architektura jest częścią wytwarzania programu. Czy te review to są po prostu jakieś tam peer reviews, o które prosisz. To nie jest tak, że są ludzie, których robotą full time jest po prostu reviewowanie tego, bo oni są takimi custodians na przykład.
Absolutnie. Absolutnie nie. To są inżynierowie, którzy pracują normalnie w projektach. Słuchajcie, już mam już nam dwie minuty. To jest taki ja bym tylko zadał pytanie wyciągające z tego co Wojtek powiedział, ale no u was to pewnie z tego co mówisz nie ma tego problemu, bo jesteście dynamiczną, prężną organizacją, jak wszyscy widzieliśmy wczoraj top 12 tak, firm na świecie, jeżeli chodzi o wycenę, bo jak w tym wszystkim jaki jest taki review potrzebny, uniknąć takiego Ivor Tower, nie? Czyli, bo ja widziałem to w firmach Enterprise, gdzie właśnie takie review powoduje paraliż, nie? Bo zawsze jest, bo są ludzie, którzy mają to przejrzeć, zatwierdzić. Zadałeś bardzo, bardzo dobre pytanie. Mi się wydaje, że Ivory Tower, czyli wytłumaczmy, to jest bardzo częsty przykład tego, że jest wiecie idealne rozwiązanie. Wszyscy muszą dostać stamp od Wojtka. Gildia mistrzów to właśnie jest antypat. Bardzo często się pojawia antipatern w momencie kiedy mamy gildię architektów a double antipattern w momencie kiedy ci architekci już nie programują i nie tworzą tego tych rozwiązań to chyba właśnie odpowiedział bo kiedy wyszło że to jest spear review ludzi którzy nie zają się tym full time tylko po prostu są w innych zespołach i są od poziomu mida wzwyż takie tego typu rzeczy robią nie miałem w głowie zanim on to odpowiedział musiałem je
powiedzieć nie dobrze teraz już możemy zrobić rap słuchajcie z ta minuta zróbmy rapa, bo bo my żeśmy dojechali nawet nie dojechaliśmy do końca tej pierwszej sekcji scoping planowanie jeszcze mamy tam proces codzienny jakoś konty łapki w górę czy chcecie żeby to kontynuować w poprzednim następnym cof możemy zrobić numer dwa już robiliśmy takie rzeczy w przyszłości więc mamy praktykę dokładnie tak słuchajcie dzięki bardzo za udział dzięki bardzo za dzisiejszą rozmowę fajnie się rozmawiało y po zachęcamy do tego, żeby nas śledzić tak powiedziałem na mediach społecznościowych będziemy tam publikowali informacje o kolejnych odcinkach zachęcamy też do rzucenia okiem nasze archiwum. A póki co to ja będę ja będę vibe kodował w międzyczasie system synchronizacji komentarzy. O, hell yeah. By się przydało. I jeszcze automatyczne zgłaszenie bugów w riverszie, żeby Ale dobra, nie będę koduj. Dobra, dzięki bardzo. Trzymajcie się. Spokojnego piątku i spokojnego weekendu. Hej, cześć. Hej. Ah.
