Coffee Coffee #81
Nowoczesny proces developerski (część 2)
O odcinku
Transkrypcja
Brak wyników.
Zwykle robię za centrum świata. No dopiero teraz poszukanie po betonie. Jesteśmy też poszukie. Poszuk. W jakich butach biegacie? W jakich butach biegacie ludzie? W dobrych w tych w klapkach. Od tego zaczęliśmy, od tego zaczęliśmy tutaj dzień dzisiaj. Dzień dobry. Hoka is the best. Tak. Dzień dobry. Cześć. Witamy wszystkich. Mam nadzieję, że nas widzicie i nas słyszycie i za chwilę Tomek nam powie, czy to jest tylko płodna nadzieja, czy może jednak nie. Chyba nie, ale ten No lecimy, lecimy, lecimy, lecimy. Wojtek, Tomek, Sebastian. To jest City of Morning Coffee, nasze regularne co dwutygodniowe, a ostatnio chyba trzytygodniowe spotkania, gdzie rozmawiamy sobie na żywo z wami o tematach istotnych dla tak zwanych senior technical leaders, czyli właśnie CTO, piece of Engineering, directors, senior managers, architects, principal engineers i tak dalej, i tak dalej, i tak dalej. Mówimy o tych obecnych, obecnie pełniących te funkcje i również o tych aspirujących. Każda nasza taka sesja live trwa godzinę czasu, ma konkretny temat, w ramach którego rozmawiamy sobie i cała idea jest taka, żebyście wy uczestniczyli w tym aktywnie.
Yyy, kiedyś robiliśmy to na Twitter Spaces, było to troszkę łatwiejsze, teraz robimy to na Riversidezie, więc jeżeli chcecie dołączyć do nas na żywo, jeżeli chodzi o dźwięk, jeżeli chodzi o wideo, jest taka szansa. Ja za chwileczkę odpalę wam tutaj linka, żebyście widzieli jak jak to można zrobić. W każdym razie jeżeli po prostu chcecie nas słuchać to możecie to robić albo robicie to już w tym momencie na między innymi na YouTubie LinkedInie i na Twitterze. Gdzie jest ten mój nieszczęsny gdzie jest ten mój nieszczęsny tekst? Zaraz go tutaj wkleimy. No więc tak. Dzisiejsza sesja to jest tak naprawdę dogrywka. dogrywka dlatego, że ostatnio rozmawialiśmy na temat nowoczesnego procesu wytwórczego i tak naprawdę zeszło nam godzinę, ale porozmawialiśmy głównie o części dotyczącej planowania, estymowania i przygotowywania tego, nad czym będziemy pracować, czyli między innymi jakichś standardów dokumentowania. Więc tak naprawdę nie przeszliśmy jeszcze w ogóle do tego, nazwijmy to execution, do samego procesu. I dzisiaj chcemy to nadrobić. Dzisiaj chcemy o tym porozmawiać i bardzo, bardzo na was liczymy. Znaczy
my mamy swoje doświadczenia. W paru firmach każdy z nas pracował, coś każdy z nas widział, ale jednak fajnie by było, żebyśmy z tego może robili nie ankietę, a nie jakieś tam spojrzenie, nie wiem, raportowe statystyczne, ale koniecznie wrzucajcie gdzieś na na czaty, najlepiej na czat Riversite, ewentualnie na YouTubea, bo chyba stamtąd widzimy z LinkedIna, to Tomek będzie zaglądał i sobie wtedy z chęcią się ustosunkujemy do tego, co. Będę wszędzie zaglądał i i będę robił za teraz jest takie modne słowo AI agent do synchronizacji napisów. Boskie słuchaj ale tak zupełnie poważnie moglibyśmy tego użyć od jakiegoś kometa czy coś. Next time. A w ogóle nie wiem czy wiecie comet od wczoraj setem dla wszystkich. Tak właśnie miałem się pytać czy już dia jest ten skrót z polskimi literkami zrobiony czy nie. Musisz przetestować. No właśnie zrobiłem upgrade, więc przetestuję. Wracając, my tu nie o komecie, o komecie to przy innej okazji. Wróćmy do tego naszego nieszczęsnego procesu wytwórczego albo szczęśnego procesu wytwórczego.
Czemu nieszczęsnego? No właśnie. Słuchajcie, zawiesiliśmy się w momencie właśnie, kiedy mieliśmy przejść już do tego takiego codziennego, normalnego execution. I teraz tak może pierwsze pytanie od którego chciałbym zacząć to jest czy time bokxować czy niebebxować bo tutaj każdy ma jakąś swoją szkołę są firmy, są z engineing unity starają się postawić na jakiś rytm na jakiś taktie które po prostu mówią że tego nie potrzebują really when done albo my pracujemy w trybie ciągłym jeżeli coś zrobimy to po co czekać na to aż jakiś sprint się skończy czy jakiś inny releas się skończy, cokolwiek innego boksować czy nie Wojtek? Ja bym powiedział, że to trochę też zależy od specyfikacji pracy zespołu. Tak. O, Wojtek przyzedł w konsultanta. Tak, to zależy, nie słuchajcie, no z doświadczenia, tak, bo są zespoły, które świetnie sobie radzą w sytuacji pracy ciągłej, tylko po pierwsze myślę, że wymaga to pewnego doświadczenia.
jest ten jednak cały, cały czas ma ciąg pracy. Nie wszyscy potrafią pracować bez jakiegoś takiego, wiesz, miejsca, w którym można odciąć, iść, wiesz, popatrzeć dookoła, może zatrzymać się, iść dalej. To jest taka ciekawa rzecz. Druga rzecz, że nie każdy projekt się do tego nadaje. Są projekty, które faktycznie dużo lepiej według mnie działają akurat w tym modelu. Z mojego doświadczenia na przykład tak pracujemy z zespami, które szeroko można by nazwać platformowymi. Jeżeli są wiesz na przykład do zrobienia spore migracje, toebxowanie migracji, która ma na przykład trwać dwa miesiące, nie wiem czy ma jakikolwiek sens. Tak, mamy dokładnie spis, nie wiem, klas, modułów, tabel w ba danych, zależy co tam sobie migrujemy. No i wiesz, codziennie siadasz i wiesz, wiesz co masz do ściągnięcia, wiesz kiedy skończysz. Więc to jest dla mnie typowy projekt, który lepiej działa w trybie ciągłym.
A spora część projektów produktowych, faktycznie jest dużo lepiej. zespoły same się znajdują w tym, że jest jakiś jest jakiś time boksowany najczęściej demo, ja bym powiedział, prawda? To jak zespół pracuje w środku, to też jest inna sprawa, ale time boxowane demo, gdzie możemy co jak co dwa tygodnie zaraportować jakiś status, to też całkiem nieźle działa. Mhm. Tomek, coś chciałeś znać? Tak, boy Wojtek tam wytrygerował mnie z jedną rzeczą tylko. Znaczy miałem powiedzieć, że pytanie jest tendencyjne. Yyy, i ale tak y tylko że wiecie, no znowu są różne doświadczenia. Ja nie pracowałem nigdy przy produkcie tak ściśle, nie? Y i teraz jak Wojtek mówił o tej migracji właśnie, znaczy, bo to jest pytanie czy czy mówimy o time boksowaniu tylko wiesz typu względem czasu, czy bardziej yyy znaczy czemu to ma służyć? O tak o. Nie, bo teraz no może zć innym rzeczą. To jest tak w tle tego pytania. Tak, tak, tak. Bo teboksowanie według mnie znaczy może służyć yyy powiedzmy nie, nie bójmy się tego. Może służyć to po prostu temu, żeby ktoś miał pracę przy rytuale.
Powiedziałem. O, dobra. Y, ale yyy nie yyy generalnie jeżeli założymy, jeżeli okej, ja przyjmę teraz założenie swoje, jeżeli założymy, że ma to służyć temu, żeby był weryfikowalny progres, to time booxować, jakkolwiek to nazwiemy, nie? Bo yyy to co chciałbym, to dla to do czego u mnie to powiedzmy najczęściej służyło, to jest do tego, żeby dało się generalnie śledzić w jakiś sposób skończony progres rzeczy robionych. I w tym wypadku na przykład wiesz y przy takich migracjach to ja też chciałbym mieć checkpointy co ileś czasu w który sprawdzamy czy czy to co zapracow ten. Więc to jest pytanie czemu to ma służyć. Jedno dr to tylko wskoczę tutaj i jedno drugie nie wyklucza drugiego w sensie bo ty mówisz prawda, że zarówno zespół jak i na przykład otoczenie tego zespołu, cokolwiek to oznacza, bo na przykład zespoły zależne od tych migracji chociażby, tak mają regularny checkpoint. na przykład co tydzień to tego w ogóle jedno drugiego nie wykluczę i do tego checkpointu warto dodać jeszcze parę rzeczy z mojego doświadczenia texy te boxy powinny służyć temu jeżeli służą temu że zespół robi ship cokolwiek znaczy shipyt to time bokxować nie i
tutaj ja miałem kilka takich przypadków gdzie y na przykład bym powiedział że też warto robić tylko dlatego, żeby ludzie nie wpadali w wiesz żeby nie nie cyzelowali rzeczy których już nie warto robić nie że mają coś zrobić, dowieźć i masz checkpoint z nimi, żeby oni przestali już nad tym pracować, bo miałem takich ludzi, którzy wiesz urywali milisekundy z czegoś, nie? Więc w tym zakresie to jest bardzo dobre. No i teraz mówię, to jest trochę definicja, no bo dla mnie regularny checkpoint z jakimś co mieliśmy dowieźć gdzie jesteśmy. Jak ktoś dowiesz więcej, to spoko. Jak ktoś nie dowiózł czegoś, to mamy wiesz nie nie ginie to w szumie. jest jakaś procedura sprawdzenia, czy dowieźliśmy to, co mieliśmy dowieźć, albo myśleliśmy, że dowiemy, to w tym w tym zakresie uważam, że boksować, że taki rytm, e, ludzie, którzy mają podejście takie sprzedażowe w różnych korporacjach to nazywają to rythm of business, nie? Są takie r tak zwane, nie? To taki rythm ofiness w developencie czegokolwiek według mnie też jest potrzebny, nie? Więc bym powiedział, że tak, ale nie robiłbym z tego religii.
Mnie się też wydawało na początku, że jest znacznie większa łatwość raportowania, jeżeli chodzi o już podejście z tej odpiął, to tak, ale to jest przesada. To nie jest znacznie większa, jest odrobinę większa, bo flow matrix można liczyć też po takim podejściu typowo canbonowym i tak dalej. Natomiast jak dla mnie podstawowy powód dla którego time boxować to jest jeżeli my chcemy organizację na czegoś nauczyć nie ludzi organizację czegoś nauczyć wyrobić pewien mięsień. Kiedyś dawno dawno temu wyglądało to w ten sposób że organizacja miała na przykład problemy releasowe, bo wszystko się testowało w dużych jakiś paczkach, były jakieś wielkie testy regresji, nikt nie automatyzował. Chodziło o to, żeby ludzi nauczyć pewnego rodzaju rytmu, że coś się dzieje do danego momentu, potem jakiś catfis i wtedy to boksowanie było mega potrzebne. Teraz jest potrzebne do nauczenia trochę innego rytmu, czyli właśnie na przykład tego, żebyśmy regularnie planowali, żeby pewnych rzeczy nie zaniedbywać. Wiadomo jak to wygląda w cyklu tworzenia oprogramowania, że jest cykl przygotowywania pewnej roboty, która się będzie działa, tych różnych refinamentów, planowań i tak dalej.
Jest też cykl już sam wytwórczy. One jakoś na siebie troszeczkę nachodzą, ale są przesunięte. I generalnie jeżeli stworzymy pewnego rodzaju mechanizm, pewnego rodzaju takt czy rytm, to nam to troszeczkę ułatwia. On ten mechanizm trochę sam siebie pilnuje. Niekoniecznie ludzie muszą aż tak go pilnować. Więc ja ogólnie powiem tak, ale to teraz będę prowokował dalej. To czekaj, to ja tylko wejdę w jedną rzecz. Y, bo nie mamy tego na liście i dlatego z nią wejdę. Tak, zobaczyłem, bo tu powiedziałeś, że kiedyś myślałeś, że to służy do tego, żeby yyy, że ułatwia raportowanie jakby progresu i tak dalej. Nie minimalnie, ale właśnie tak. A to ja uważam, że raportowanie powinno się odbywać w trybie ciągłym, ale to oznacza, że powinieneś w danym momencie być w stanie wejść i zobaczyć, co zostało zrobione, czy zostało zrobione, kiedy i kto. I teraz nie na zasadzie, wiesz, nadzoru takiego ten, tylko po prostu nie, ja, ja miałem takie sytuacje wiesz, żeby nie było opowiadania historii, nie? Czyli ja miałem taką sytuację, gdzie człowiek po prostu mi opowiadał historię, a mówiłem nie rozmawiamy o niczym, czego nie ma w backlogu, jak masz pytanie, cokolwiek ten, e, to tam je ten i tam gdzie się tego trzymaliśmy, nie? Jeżeli taka dookoła tego, to tam się pracowało lepiej, nie? Takie było doświadczenie,
nawet jak klient tam zaczynał pisać i tak dalej, więc raportowanie bym od tego odpiął. Po prostu od strony raportowania. Ja powinienem, wiem, ale wiesz, chodzi mi o to, że na przykład, ale to też jest to, bo ludzie sobie wrzucają rzeczy do zrobienia i ja powinienem w danym momencie móc wejść i zobaczyć nad czym pracujemy zawsze. Jednym zdaniem powiem ci dlaczego to jest ważne przy raportowaniu. Zgadzam się z tobą, że informacje powinny być dostępne na żywo przez cały czas. Chodzi o porównywanie. Chcesz porównać dwa okresy, które zawierają wszystko. I trochę planowania, i trochę dewelopmentu, i jakiś releas, i jakieś testy. Więc jeżeli w tym momencie masz rytm i w tym rytmie masz mniej więcej po tyle samo tego samego, to porównujesz jeden, że tak powiem, cykl rytmu z innym cyklem rytmu inaczej niż jakieś wyrywki przykładowo kanowe, które mają pod spodem mogą mieć trochę inny charakter. No chyba, że jest typowo supportowe. Tu Michał też się włączył z boku. Nie wiem czy widzieliście, że właśnie te boksowanie utrzymuje ludzi w korytarzu. Dzięki Michał. To nie był dokładny komentarz, to ja się odniosę też do tego, co ty powiedziałeś i co Michał powiedział. To jest tak, że warto warto przede wszystkim zacząć pracę nad czymkolwiek, żeby mieć jasny scope in i scope out, tak? czyli to, co robimy i to, czego nie robimy. E, do tego y polecam, jeżeli prowadzicie projekty właśnie też przede wszystkim
typu właśnie platformowy, migracyjny, to jest niesamowicie przydatne. Upewnić się, że mamy całą listę blokerów ewentualnych i decyzji do podjęcia. I na przykład wracając do tego, co ty mówisz, Tomek, absolutnie zgadzam się, że w ogóle, szczególnie w sytuacjach, w których yyy mamy do czynienia z pracą w zespołach zdalnych, yyy, takie raportowanie live progresu, gdzie ja nie muszę nikogo pytać yyy albo nie muszę być przez nikogo pytany, żeby ten ktoś wiedział, gdzie jesteśmy z tym projektem, to jest absolutnie absolutnie potrzebna rzecz. Tak więc w ogóle nie dyskutuję i naprawdę zachęcam, żeby upewnić się, że mamy cokolwiek to jest yyy nawet prosty dokument typu spreadsheet y z gdzie wszystkie zespoły yy tam sobie to wszystko wrzucają. A jeżeli chodzi o to spotkanie, to do tego Michał, co ty powiedziałeś, to też powiem z mojego doświadczenia bardzo dobrze, bardzo dobrze działa, jeżeli faktycznie pracujemy na przykład w kilka zespołów, żeby też synchronizować się co do niektórych decyzji, a mieć właśnie tego decision loga, decyzje, które mamy do podjęcia, które mogą czekać, bo te które nie mogą czekać, to od razu, słuchajcie, od razu wrócy. Ty, ja tylko wyciągnę taki insight z naszej historii.
Revolt leci na sprecie. Tak. I to się dowiesz wszędzie i najlepsze narzędzia do prowadzenia wielu projektów. Kilka lat temu nawet wiesz kilka tysięcy osób było. Wiele rzeczy było nawet odnośnie osób tak prowadzonych. Tak da się. Nie potrzebujesz mieć jakiegoś zdewelopowany lokalny system kolejkowy do wprowadzenia zmian w sp. Natomiast wiecie jest jeszcze kilka jest jeszcze kilka aspektów, tak? bo mamy do podjęcia też decyzje. Myślę, że na przykład jeżeli chodzi o architekturę, jeżeli chodzi o design, a polecam nie nie przypatrzeć się swoim procesom tak, żeby nie tworzyć narzędzi, które powodują sztuczne kolejki. Yy więc jeżeli w projektach macie na przykład ten moment synchronizacji i na niego czekacie, żeby podjąć decyzję, to to jest dobry sygnał, że coś jest nie tak. A bo wiecie, bardzo często jest tak, że mamy spotkanie, którym będziemy, nie wiem, prezentować adaery, przykładowo w w jakimś dużym projekcie albo albo design, tak, UX i tak dalej, i tak dalej, zmiany UXowe i
raz na tydzień, raz na dwa dowiemy się, co się zmieniło w tym projekcie. Na takie takie rzeczy proponuję łowić i upewniać się, że za nie się zabieramy, bo to jest coś, co zabija flow. No dobra, czyli tak generalnie toboksować, no chyba, że jakieś tam mamy specyficzne casy, teamy, nie wiem, platformowe, migracyjne i tak dalej. Okej, ale my tych teamów mamy więcej niż jeden zazwyczaj. W jaki sposób synchronizować pracę pomiędzy nimi? Czy ktoś tu wymyślił coś lepszego niż jednak to, co zaproponował ten znienawidzony scram guide, czyli synchronizacja w ramach teamów w formie jakiś daily i też synchronizacja pomiędzy teamami w formie jakiś nexusów, scram of scrums. Czy czy jest to są to jakieś lepsze rozwiązania? A może trzeba wejść do tego project managerów, którzy na przykład są dedykowanymi osobami od synchronizacji pomiędzy team? To będzie hejterskie pytanie, nie? Ja zacznę, ja będę miał może prościej. Znaczy nie hejtowałbym project managerów, nie nazwałbym ich tylko project managerami.
Toż tam nasza filozofia była w firmie, że się nazywają project owner z różnych powodów. E, nawu ma znaczenie. Jeżeli to jest dobra osoba i dobrze robić swoją robotę, to to jest bardzo pożyteczna osoba. Jeżeli ten projekt jest większy i tak dalej. Teraz czy to ma być Scram of Scrams, coś tam. My poszliśmy w którymś momencie w kierunku czegoś takiego jak sejf. To nie było według mnie dobre, ale kolega koledze się podobało. No spoko, coś tam robiliśmy, nie? Jakiś proc, jakiś proces mus musi być. Tylko znowu z doświadczenia najlepiej jak on jest oparty, jak najbardziej o jakieś narzędziowe rzeczy typu u nas akurat wiesz, my korzystaliśmy, o, teraz to będzie hejt, wiesz, zażur DevOPS, nie? I teraz jeżeli ktoś dobrze tym zarządza i ludzie raportują rzeczy i tak dalej, to dużo synchronizacji odbywa się po prostu na poziomie narzędzia też nie widać co gdzie jest i tak dalej. Wiesz co, to się okazuje, że jak dobra osoba potrafi, jak położysz dobrą osobę z z narzędziem, nie mówię dobrym narzędziem, ale z jakimkolwiek narzędziem, to się okazuje, że magia się zaczyna dziać, nie? Więc jakiś proces synchronizacji musi być. Nie wiem, my nie trzymaliśmy się religijnie rzeczy typu scram czy
coś, nie? Tylko po prostu wybieraliśmy z tego jakieś praktyki i one były wdrażane i każda z tych osób trochę sobie to robiła, to przyznaje. Ale tak, synchronizacja w jakiś sposób jest potrzebna? W ogóle synchronizacja to jest duże zagadnienie w ogóle w każdej organizacji dotyczy wszystkiego, nie? I teraz jest pytanie, jak to sobie zorganizujesz? Ja byłbym tutaj fanem tego, żeby ono się do, żeby synchronizacja wykonywała się, dokonywała się dookoła artefaktów, a nie dookoła procesu czy rytuału. Zaraz do tego dojdziemy. To to tak, ale dajem jeszcze Wojtkowi odpowiedzieć na to oryginalne pytanie. Synchronizacja pomiędzy zespołami. Tak więc pierwsza rzecz do tego co mówicie to jest, ja bym powiedział, że bądźmy pragmatyczni jeszcze raz. Po pierwsze to chyba też zależy od tego jakie jakie mamy doświadczenie w zespole, bo Tomek to co powiedziałeś, że magia się dzieje, to ja bym powiedział jak mamy właściwych ludzi to magia i tak się podzieje. Nie musimy wielu rzeczy mieć, bo ci ludzie będą mieli, ale może być mniej lub bardziej efektywna, nie?
No tak, ale wiesz, ale dobrzy ludzie i tak spowodują tą magię, którą o której powiedziałeś. Jeżeli mamy faktycznie niedoświadczone osoby, no to to jest inne pytanie i trzeba faktycznie troszeczkę pewnie podciągnąć jakieś kolektywne doświadczenie. Natomiast do rzeczy, synchronizacja pomiędzy zespołami. Ja bym to też powiedział, y wydaje mi się, że z doświadczenia zależy o jakiej skali projektów mówimy, bo jeżeli to jest synchronizacja pomiędzy dwoma, trzema zespołami i de facto mamy do zrobienia projekt, to dlaczego nie zrobić takiego teamu projektowego, czyli wyciągnąć wirtualnie, można by powiedzieć, tych ludzi i stworzyć wirtualny zespół i niech sobie zorganizują tą pracę. Jak oni to zorganizują? Może to być wiecie synchronizacja daily, weekly. Oni oni sami do tego dojdą i sobie zorganizują tą pracę. Jeżeli to jest synchronizacja pomiędzy na przykład kompletnie różnymi zespołami, nawet może tam składami, departamentami, jakolwiek to nazwiemy, to pytanie pojawi się jeszcze według mnie o ten incentive. Przepraszam, że to powiem, ale a co powoduje, że chcemy pracować razem.
I tutaj warto też przede wszystkim synchronizować [Muzyka] pewnego rodzaju właśnie system nagród za ten projekt, tak żeby zespoły priorytetyzowały odpowiednio swoje swoją tak jakby wiecie zależną pracę, żeby ten projekt znów powiem optymalizować pod flow, a nie pod wiecie jakieś artefakty sztuczne, dokumentacje. wiecie, scram, scramów i tak dalej, i tak dalej. Według mnie to jest tak proste jak wszyscy chcemy to zrobić, a i w ten sam sposób można do tego podejść, czyli stworzyć wirtualny zespół, tylko upewniając się, że jest ten właściwy incentive od samego początku.hm Dobra, ja tylko powiem, że jeszcze wiem co jest antypaternem i bo to jest już z się zrobił się mem, nie? Ale to był problem tej organizacji, w której kiedyś pracowałem, czyli Microsoftu dawno temu, nie? Że komunikacja między zespołami odbywała się przez multiple levels of middle managers, nie? Stąd moja propozycja mojego wirtualnego zespołu.
Faktycznie zaangażujmy ludzi, którzy są tylko i wyłącznie zaangażowani w projekt. Tam doszło do sytuacji, w której człowiek pracujący nad featerem X z człowiekiem nad feiterem Y musiał rozmawiać przez dwóch, trzech menadżerów. Nie mogli rozmawiać direct, nie jakby oficjalnie przynajmniej. No i to był to jest wtedy to jest, ale to to tak punktowo się przyczepia tego, bo powiedziałeś Tamk, że tam dość tego hejtowania. Czy w organizacjach większych, które realizują jakieś inicjatywy pomiędzy kilkoma zespołami, używacie project managerów, czy nie? Czy jednak taki jest full product management all the way from the bottom to the top? Znaczy wiesz co, y my tak nie mieliśmy, bo u nas generalnie wszystko było dookoła projektu, nie? Czyli u nas projekt był entity, na którym pracowaliśmy i wtedy nawet jeżeli to był duży projekt i tak dalej, to tam była osoba odpowiedzialna za projekt i ona pełniła tą rolę, nie? Teraz u moich klientów to było bardzo y popularne podejście, nie? Czyli generalnie jeżeli to był duży projekt, który obejmował bardzo dużo ludzi i tak dalej, to pojawiała się osoba, której faktycznie jedynym w zasadzie e zadaniem było synchronizowanie tych zespołów między sobą, wyłapywanie issues, organizowanie flow, rozwiązywania tych issuesów i tak
dalej, nie? I w większych organizacjach to to był standard, nie? Teraz zawsze była kwestia jak czy to jak ta osoba działała i to jest czy to był chaos czy porządek. Nie może powiem do czego piję zanim jeszcze Wojtkowi oddam mikrofon. Pije do tego, że jak jest większa organizacja i pojawia się jakiś pomysł na przykład na jakiś nie wiem większy feater, w ogóle jakiś funkcjonalny obszar w aplikacji, często angażuje to wiele zespołów. Wiele zespołów i wiele produktów mniejszych i wielu product managerów. Każdy z nich ma swoją działkę do dowiezienia. Działka każdego z nich dowieziona osobno nie ma znaczenia. Liczy się suma tego wszystkiego, całość. Ta całość ma być może na przykład spowodować większą adopcję, nie wiem, przyj nowych klientów, zwiększenie user experience i tak dalej, i tak dalej, i tak dalej. I teraz tak, każdy z tych product managerów ma ogólnie jakąś tam swoją agendę różnych tematów. ten konkretny program czy projekt niekoniecznie musi być numer jeden na ich tapecie, ale może być na tapecie jakiegoś na przykład właściciela komercyjnego jakieś części tego biznesu.
I teraz jeżeli jest ich kilku, oni są na powiedzmy powiedział na tym samym poziomie, to który z nich jest accountable za sukces całości? Czy niepotrzebna jest ta osoba? I jeszcze dokończę ostatni wątek. To jeżeli my mamy tą osobę, nazwemy ją czy product managerem, czy program managerem, project czy program managerem, to teraz na ile ta osoba po prostu powinna być od takiego operacyjnego popychania projektu, a na ile faktycznie powinna być trochę takim komercyjnym menedżerem pilnującym, że to faktycznie dowozi wynik biznesowy. To z mojego punktu widzenia, ale to są obserwacje. Znaczy wewnątrz firmy też to robiłem takie rzeczy. Albo chłopaki robiły, robili albo dziewczyny. Tylko to jest tak, że to co opisałeś wymaga dwóch osób i na końcu dotknąłeś tej głównej, że tam zawsze jest ktoś kto jest takim spiritus movem z tego, nie? Ktoś kto ma sponsor, można to nazwać inaczej, nie? Sponsor jest często mało zaangażowany. Tak. Tak. Bardzo dobrym przykładem jest na przykład jak ktoś tam nie śledził czy nie słyszał historia powstania Powershella w w Microsofcie. No generalnie powershell nikt nie chciał i ten koleś, który wymyślił powersh i w końcu go zrobił, to został zdegradowany za to, że chciał powersella, nie? Ale on chciał powershellA, bo uważał, że to jest dobre i musiał przekonać wszystkich, żeby
chcieli tego powershella, nie? No i on musiał No i to jest to jest ta funkcja, o której powiedziałeś. To jest ktoś, kto chce zmiany i musi tych ludzi dogadać. Teraz potem wykonanie tej zmiany, no to to już jest kwestia jak organizacja działa, nie? Jeżeli to wymaga faktycznie tam project managera, kogoś to ten, ale raczej jak on już przekona i dobrze to zrobił to ci ludzie i tak to robią, bo to wpada w jakieś ich cele i tak dalej i tak dalej. Więc to jest trochę szersze zagadnienie. W ogóle możemy je zaparkować, nie, na osobny temat, bo to jest trochę już kiedyś mówiliśmy leading without authority, nie? Ale to jest tak getting things done without authority, nie? Albo przy różnych incentivach, nie? To dam jeszcze Fkowi się odpowiedzieć. A bym odbił, Sebastian, bo ty zbyt łatwo zadajesz pytania i i nie odpowiadasz, więc dajesz. No taką ma rolę, nie? Znaczy tak, ja powiem w ten sposób, ja zawsze kanonicznie próbowałem podchodzić do tego w ten sposób, że program manager i project manager jest niepotrzebny, nie? Natomiast dlatego, że każdy również również deweloper powinien być trochę project managerem. Każdy powinien być w stanie przeprowadzić jakiś temat od punktu A do punktu B, rozbijając go w logiczny sposób, zarządzając podstawowymi rzeczami takimi jak resource, ryzyka i tak dalej. yyy każdy powinien być w stanie zidentyfikować ścieżkę krytyczną yyy i tak dalej i tak dalej. Każdy powinien to umieć. Jeżeli
chodzi o koordynację pomiędzy zespołami, uważam, że i tą rolę tutaj taką project managerską też uważam, że na pewnym poziomie dojrzałości organizacja jest w stanie to robić sama. E, ale to faktycznie wymaga pewnego specyficznego rodzaju ludzi, którzy nie pozwalają, aby piłeczka upadła. To nie jest zawsze proste. Ja bym powiedział tak i to to nie jest tak, że na w tym momencie skreślam project managerów. Dlaczego już mówię? Bo pojawiłem się, słuchajcie i to w małych organizacjach takich super digital w sensie tylko i wyłącznie nie wiem portal internetowy Full SAS tego nie widać, ale jest dużo organizacji gdzie projekt wychodzi daleko poza IT. Operations, gdzieś jakieś fizyczne wdrożenie w jakichś oddziałach, wyedukowanie jakichś ludzi, w ogóle jakieś fizyczne itemy, wdrożenie tego nawet w jakimś marketingu, milion różnych tematów. Dział prawny. Dokładnie tak. I w tym momencie IT oczywiście robi my tego nie chcemy miałem powiedzieć że to że twoje że twoje pierwsze założenie upada w tym momencie bo jak wchodzę tam w duży projekt wchodzi dużo tematów które nie są techniczne nie są inżynieryjne one są całkiem inne i wtedy dużo ludzi z tych którzy sobie potrafią znaleźć tą ścieżkę krytyczną i tak dalej to oni to odpuszczą dokładnie tak bo po prostu nie rozumiejemy jak działają tamte departamenty nie chcą zrozumieć jak działają tamte departamenty co więcej
jeżeli tamte departamenty czy jednostki czy cokolwiek mają pewnego rodzaju swoje ograniczenia, których nie ma w softwareze, to w tym momencie to jest tylko i wyłącznie dla na przykład deweloperów czy ogólnie inżynierów irytujące, niezrozumiałe. To są showstoperzy, oni nie umieją pracować szybko, itd. itp. Lecimy dalej. Więc więc w tym momencie tak w tym momencie yyy yyy jakby bez takiej roli faktycznie kogoś spiritus mem project managera, duera, jak jak zwał, tak zwał, egzekutora, to jest już ciężko. Natomiast ja mam bardzo duży problem z ludźmi, którzy podchodzą do tego bardzo mechanicznie, czyli to są po prostu tacy trochę odklikiwacze albo checkbxów odpytywaniiej, tak? Odpytywamie jaki jest status zadań w Excelu, nie? I to jest bezużyteczne, nie? Tak. Tak. Jeżeli nie umieją scallengeować tego, nie umiejłem z pewnych rzeczy zwalidować, to w ogóle ma sens, czy nie możemy tego skipnąć, nie są nie są w stanie wejść na odpowiedni poziom głębokości, to tak naprawdę bardzo mało dodają wartości. Tak, zgadzamy się.
Długi jest ten temat związany ze sponsoringiem i z tym z tą rolą spiritus movence i jeszcze z tą rolą leadership authority. Nie będę w niego wnikał. Pozwólcie, że zaparkujemy to w tym momencie. Natomiast to jest to jest taki trochę nierozwiązany problem powiedziałbym do tej pory. No ale może zaparkujmy. To jest dobry temat. Dajcie znać tam w komentarzach, czy gdzieś czy w ogóle chcielibyście pogadać o tym, bo to jest dobry temat. W ogóle moglibyśmy kogoś zć ciągnąć do tego jakiegoś takiego tak zawodowego program managera na przykład. Dobra, jedźmy dalej, bo tych tematów mamy mnóstwo. Słuchajci. Aha, właśnie patrzę na listę. No tak, przecież ze dwa punkty szykuje się part trzy, bo jakaś przerwa będzie potrzebna. Dobra. Okej, jedźmy dalej. Y, powiedzcie mi, ja bym jeszcze chciał was dopytać, no to tak, mamy te nasze teamy. Jak wygląda nowocześnie zorganizowany team w takim nowocześnie nowoczesnym procesie dostarczania czy wytwórczym? Bo mówiło się, dużo jest bazwów, czyli że team crossfunkcjonalny, że po prostu jak team member każdy może być wszystko, ludzie są zastępowani, że tam każdy powinien być w stanie tak jak do tego podchodzicie, czy czy macie liderów, czy nie? Jacy, kim są ci liderzy? są liderzy techniczni, czy liderzy teamu, czy menedżerowie, taki team, jaką powinien mieć wielkość,
czy taki team powinien być funkcyjny, czy wyspecjalizowany, czym powinien być team, jak powinien wygnać team. Dobrze, to ja wejdę, bo ja będę miał inny punkt widzenia niż Wojtek, to szybko go powiem. E, i znowu to jest moje specyficzne doświadczenie, bo ja mało różnych firm zaliczałem w międzyczasie, nie, ostatnio. E, ale więc punkt widzenia firmy usługowej, w której pracowaliśmy nad projektami, czyli dla nas dowiezieniem było projektu dla klienta, ale de facto uważam, że to jest dobry model. Okej. Rozdziel rozdzielmy team organizacyjny od teamu, który coś dowozi. Czemu nie? Bo są dwie rzeczy, nie? Jedna jest rzecz taka, że ludzie muszą w jakiś sposób mieć rzeczy załatwione. U, dobra, u nas tak to było, nie mówię rozdzielne, u nas tak to było, że ludzie muszą mieć zapewnione pewne funkcje takie socjalne, menadżerskie, firmowe, nie? Podwyżki, kariera, planowanie jej, zespół z którymi i tak dalej, a potem są rzeczy do zrobienia, nie? I u nas podejście było takie, że team, który robi, znaczy team, który jakby w strukturze organizacyjnej to jesteś do niego przypisany, on jest dla ciebie stały i tak dalej, ale team, który robi rzeczy jest liquid, czyli generalnie team jest formowany pod to co jest do zrobienia, nie? I teraz mogłeś dlatego u
nas człowiek był w jednym zespole, jeżeli chodzi o tak jakby przynależność organizacyjną, nie? ale mógł być nawet w jednym czasie w kilku zespołach projektowych albo zmieniał ten zespół projektowy i pracował z różnymi ludźmi nad różnymi rzeczami, nie? Dlatego, że u nas zespół do zrobienia rzeczy był robiony pod to, co trzeba zrobić i teraz jeżeli ich było więcej, to nawet się tworzyła struktura zespołów w ramach projektu, nie? I tam byli inni liderzy i tak dalej do robienia tego projektu, nie? E, no i to my mieliśmy jakieś tam filozofie, dlaczego tak to zrobiliśmy za tym. No ale w naszym wypadku to działało i teraz jeżeli tam jest mamy pytanie czy zespół ich dyscyplinarny czy funkcyjny no dla nas to był zespół taki który dobierał ludzi którzy są do zrobienia nie i ktoś mógł wskoczyć do zespołu zostać dołożony bo trzeba było ludzi od infry w danym momencie ale jak ludzie od infry nie byli potrzebni to oni wyskak znaczy inaczej przestali pracować w tym zespole ale za dwa miesiące mogli wrócić do tego zespołu i dalej byli w temacie bo wiedzieli co zrobili nie więc u nas naszym podejściem było że teamy formowały się pod projekt i były trzymane tak długo jak projekt istniał i tak dalej. Jeden z takich zespołów istnieje prawdopodobnie już s albo 8 lat, bo dalej istnieje, nawet więcej, nie? Bo zajmuje się konkretną rzeczą,
nie? I on się rozrasta po prostu i tam jest cała już struktura. Rozrasta, czyli ile osób? Pewnie z 40 teraz. I co? Razem planują na przykład. Proszę. I razem planują na przykład. Tak, znaczy w ramach tego, co robią na 40 osób. Zależy jak powiesz co planują. Co to znaczy planują? Dwóch lat nie mam z nimi do ten nie wiem jak teraz to robią, więc wiem jak robili to kiedyś. Tym jest dla mnie pewną jednostką na którą patrzę. Jestem w stanie ją monitorować. Jestem w stanie widzieć co ona na przykład będzie robić, ale w ramach tych 40 osób oni są już się też dzielą, nie? Więc generalnie każdy wie co robi ten zespół i tak dalej, nie? Okej, czyli tu już jest bardziej unit, a tam teamy to pod spodem. No tak. No bo przy takim, no wiesz, no generalnie, bo jak jak projekt ci rośnie do kilkudziesięciu osób, nie, to to się tworzy osobny unit. Tylko znowu ci ludzie, nawet jak byli w tym unicie projektu, nie, to organizacyjnie mogli mieć innego menadżera i tak dalej i tak dalej, z którym rozmawiali o jakichś rzeczach. Rozumiem. Tylko bardziej jak pytam o team, to w tym momencie chodzi mi o coś takiego, o team, który jest możliwie enkapsulowany, jakby zamknięty na przykład, sam planuje, sam ma jakby jasny swój własny scope i odpowiedzialność, któ rozliczasz. Wiadomo, że nie rozliczasz wszystkich 40 osób z tego samego, bo to
nie o to chodzi, nie? Bo to jest ta dekompozycja, nie? Okej, to teraz jeżeli chodzi, jeżeli wchodzisz w to, to zarówno organizacyjnie, jak i w projektach, jak już ten, to te zespoły u nas miały tam ograniczenie do ośmiu osób na przykład, nie? Czyli mówiliśmy, że osiem osób to jeden menadżer taki funkcyjny, czy ten to czy team lead to powinien mieć osiem osób, który mi zarządza. Jak tam jest więcej, no to był jakiś proces, żeby wypączkować nowego Team Leada, tego typu rzeczy, nie? Więc tak, ograniczyliśmy ich rozmiar, to na pewno nie, bo powyżej jakieś liczby ludzi to się daje robi niezarządzalne. Przynajmniej tak my to do tego podchodziliśmy. Więc wiesz, jeżeli, czyli dla nas zespół projektowy był funkcj, znaczy był do dowiezienia czegoś i w zespół wchodzili ci ludzie, którzy byli potrzebni do dowiezienia czegoś, nie? Teraz jeżeli to się robiło duże, to to się faktycznie dzieliło. No bo jak mieliśmy projekt, w którym jest 40 osób, to team infry może być już na tyle duży, że jest osobno, nie? Team data może być osobno, team czegoś może być osobno, nie? Ale jeżeli to jest zespół, z którym osiem osób jest skłonny, znaczy jest w stanie to dowieźć, no to wtedy człowiek od infry, od mobilki, od weba, od frontendu, od tego będzie w tym zespole. To jest zespół dowożący części, nie? Nie ma, że mamy trzy różne zespoły w tych, nie?
Wojtek, no ja mogę się wypowiedzieć chyba najprościej na temat tego, jak teraz pracujemy. Więc jak pytasz jak zorganizować zespoły w nowoczesny sposób, więc znaczy mogę powiedzieć w nowoczesny, no taki, który faktycznie widzę, że daje rezultaty w pewien z nowoczesnymi y prcypiami, można by powiedzieć, znaczy nowoczesnymi inżynierskimi produktowymi. Dobra, lecimy. Pierwsza rzecz, faktycznie te produkty są poukładane w departamenty, czyli te, które są wyspecjalizowane w i wiecie, ich struktura też jest zoptymalizowana pod to, co co ten departament robi, tak? Czyli na przykład, ale biznesowo. Biznesowo, tak? Co innego potrzebujemy, jeżeli na przykład mamy produkty krypto, a co innego, jeżeli mamy na przykład wiecie, payment gateways, tak? A co innego, jeżeli robimy taki cały enduser produkt, z którym ja na przykład pracuję. Więc to jest pierwsza rzecz. Druga rzecz, więc departament jest całkowicie odpowiedzialny za swoją dziedzinę, można by powiedzieć.
Departament składa się zespołów produktowych i operational, tak, ops, czyli tych wspierających pracę, jakkolwiek byśmy to nazwali. I tam jeszcze oczywiście bywają dodatkowe, jeżeli są potrzebne to powiedzmy dwa główne zespoły. Jeżeli mówimy o produktowych to mówimy o zespołach feature teams tudzież produktowych, czyli wszystko co widzicie w aplikacji, za tym stoi jakiś zespół produktowy, który jest odpowiedzialny plus za całkowicie za ten za ten produkt, za jego, słuchajcie, sukces komercyjny użytkownika. Jak to mierzyć w bardzo krótko. Sukces komercyjny, gross profit, ilość użytkowników i tak dalej, i tak dalej. Jak jest, jaki jest dla użytkowników ilość kontaktu użytkownika proszącego o support, buugi i zespół jest całkowicie za to odpowiedzialny. Nie ma żadnych innych osób, które są wiecie odpowiedzialne za coś takiego.
No product manager, chyba że liczysz go jako część zespołu już jak część zespołu, bo teraz właśnie co to jest zespół? Jeszcze dodam do tego, są faktycznie zespoły platformowe, tak, czyli takie, które odpowiadają za utrzymanie całej tej platformy, za planowanie niektórych zadań. Do tego możemy wrócić. Jeżeli chodzi o zespół produktowy, to faktycznie to jest coś, co byśmy nazwali taki crossfunkcyjny i to jest takim tak naprawdę startup w startupie, tak? Czyli podejście, w którym Product owner jest na tyle odpowiedzialny, że można powiedzieć, że to jest mini CEO odpowiedzialny za cały ten produkt, łącznie z wizją, łącznie z dowożeniem. wszystkich KPIów i tak dalej i tak dalej. Tak więc to jest to jest ta rzecz. To mogę challengować na bieżąco, bo też żebyśmy nie popadali w długie monolog. Okej, to ja tutaj parkuję, bo zaraz przejdę do inżynier. Żeby to była mini też chciałem coś dodać, żeby to była mini firma, to tak naprawdę musisz mieć na przykład takie rzecz jak zastępowalność ludzi. Nie możesz mieć jakiegoś tam pas faktora i musisz być w stanie dostarczyć coś end to end. Czyli w przypadku takiego banku jak na przykład wasz to musi wyglądać w ten sposób, że na przykład masz tam i ludzi od backendu i ludzi od frontendu i od Wy macie chyba aplikacje natywne, więc i osobno od Androida, i osobno od iOSa. To nie może być jedna osoba, to musi być kilka osób, więc powoli to się zaczyna rozrastać.
Do operations to jeszcze w ogóle przejdziemy, bo jestem strasznie ciekawy gdzie wyznaczacie tą granicę, jeżeli chodzi o operations, ale to się powoli zaczyna robić tak naprawdę duży team. Co więcej, jeżeli wy tego teamu używacie do planowania ahead tak naprawdę, to też to planowanie musi być stabilne, czyli musisz wiedzieć kogo będziesz miał w tym teamie za na przykład trzy miesiące. Więc też zakładam, że to nie jest tak, że co dwa tygodnie szaflujesz ludzi z jednego miejsca w drugie, a mimo wszystko ten chyba workload na tych teach jest różny. Więc jakbyś powiedział trochę właśnie jak do tego podchodzicie i jaką się krotnością kończy, nie? Bo te jesteś. Zanim tylko jeszcze Wojtek dojdzie to to ja tylko dorzucę, bo to mi przyszło do głowy, że właśnie, że to jest ciekawe, bo jednostką zespołu jest odpowiedzialność. O nie, czyli, bo u nas to się sprowadzało do tego samego. Odpowiedzialność i impakt, ja bym powiedział, czyli wpływ. Tak, ale że, że dla nas odpowiedzialnością zespołu było dowiezienie projektu, nie? I i to jest według mnie takie dość ciekawe, bo chyba ludzie o tym tak nie mówią. Jak to tak, jak to tak mówisz, to ja bym to za przepraszam, bo nie polskie słowo dla mnie nie do końca to oddaje. Tak, ale ja bym powiedział, że może jednost taki ownership.
Dokładnie. Tak. Tak, czyli ja dlatego u nas się nazywał project owner, a nie menagżer, nie? Dla Ja odpowiadam zarówno jako jako, bo teraz przejdziemy właśnie jest product owner, jest odpowiedzialny za tą za ten dany feature team. Więc zarówno jako inżynier jak jak i product owner najważniejsze żebym najważniejsza cecha której szukamy jest to, że faktycznie ty cał bierzesz odpowiedzialność za całość. Tak? Nikt inny nie jest odpowiedzialny i nie powinien być odpowiedzialny za na przykład UX tego featera jak to zaimplementowane zostało na przykład na iOSie niż inżynier, który pracuje w tym zespole i jest odpowiedzialny za iOS. Tak y więc to w ogóle nie powinno podlegać jakiejkolwiek dyskusji. I dobra, czyli jeżeli tak mamy to teraz druga rzecz. Sebastian jeszcze raz powiedzmy w zwięj formie w pytanie. Tomek mi rozwalił to pytanie. Ja tam przez 5 minut zadawałem pytanie. Potem Tomek dokładnie to w związ Dobrac moje pytanie jest następujące. Jeżeli to ma być faktycznie mini firma ta minifirma potrzebuje bardzo wiele różnych specjalności tak żeby tak robić wszystko.
Wielkość zespołu planowania i tak dalej. Tak, tak. Dobra, lecimy. Zespół standardowo składa się przynajmniej w przede wszystkim w tym departamencie, w którym ja pracuję, bo inne mogą być troszeczkę ze względu na swoją charakterystykę troszeczkę inne. Tak, czyli mówimy o zespołach, które budują zarówno takie korowe serwisy, jak i całe całe serwisy, to co tworzy tą w moim przypadku bankowość biznesową, jak i cały UI. Yyy, więc my potrzebujemy tak naprawdę wszystkich specjalizacji w każdym zespole, więc można by powiedzieć, że jest przynajmniej jeden iOS-owiec, jeden Android, jeden web, yyy, i przynajmniej dwóch backendowców. Yyy, w naszym przypadku to jest Java i z reguły przynajmniej jeden, yy, yy, znaczy jedna jeden data analyst i jeden designer. To jest taki minimalny zespół. To nie jest mały zespół, tak? Dlatego bardzo często także tak jest chyba trudność zrobienia sobie review. na przykład muszą zrobić cross zespoło. Y, kwestia jest taka, że wiesz, no właśnie teraz jak można by powiedzieć review są różne, ale wróćmy do planowania, jak to zaplanować przy tego typu zespołach, bo to jest to powiedzmy jest najmniejszy zespół, tak? Przy czym największy zespół, z którym na przykład pracujemy, to jest naprawdę duża duża część aplikacji, bo to są na przykład karty, to jest ogromna część aplikacji i
ten zespół faktycznie jest taki, że tam jest, on jest chyba ze trzy razy większy i to jest jeden zespół. Czy da się optymalnie pracować? Tak, da się cały czas optymalnie pracować. W jaki sposób? Przede wszystkim faktycznie co do tego planowania. Stabilność zespołu, o którą pytałeś Sebastian. Tak. Tak. Czyli w ramach zespołu my wiemy, że na przykład y i też dopracowujemy cały czas formułę i jako product owner biorąc pod uwagę strategię roczną powinieneś upewnić się, że planujesz około 60 do 80% czasu zespołu pod pracę tą, którą sobie planujesz. Do tego dojdźmy, pod pracę nowe featery i usprawnienia istniejących, tak żeby faktycznie na przykład podbić KPI, tak? Czyli na przykład jeżeli masz problem, że dużo użytkowników nie rozumie twojej funkcjonalności, co u nas w prowadza się bardzo prosto, bo zaczynasz czat z danego miejsca. My wiemy, że zacząłeś czat na przykład wiesz, z ekranu ustawień karty, czyli ten feater prawdopodobnie idealny feater, nie ma bugów, nie ma nie ma nie powinien mieć użytkownicy nie powinni musieć się kontaktować. Jeżeli masz jakikolwiek kontakt, masz pagi, no to wiadomo, że musimy się przepatrzeć, czyli temu featerowi, czyli wiesz, zespół za to odpowiada. Do tego dochodzą jeszcze
szybciutko tutaj dokończę. około 20 30% czasu mamy pod migrację i technologie, wiesz, jakieś zagadnienia technologiczne i UIUX, jeżeli chodzi o o frontend, czyli wszystko, co byśmy zamknęli pod tytułem dług jakikolwiek lub wiesz związany z utrzymaniem tego. I teraz jeszcze dodam może takie takie takie kilka highlights bym wrzucił. Zespół zespół całkowicie ten ownership jest tak przesunięty, że ty tworzysz, ty wrzucasz na produkcję, ty monitorujesz, ty utrzymujesz, ty jesteś odpowiedzialny za reakcję. Czy nie macie na przykład release managera takiego, który gdzieś spaja i robi z tego wspólny release na przykład aplikacji tej bankowości tam korporacyjne? Nie, nie, nie całkowicie jest, wiesz i na przykład ilość DevOpsów na, słuchajcie, jest ponad 100 000 pracowników, ponad 1000, no myślę, że z 1500 inżynierów w tym momencie, prawda? tam 65 milionów użytkowników to jest 15 deopsów wtedy jest potrzebnych do utrzymania całej całej naszej chmury.
Będę trochę tak chciałem tylko chciałem powiedzieć, że właśnie zniszczyłeś plany, znaczy realia niektórych firm, które jak ich coo to usłyszą to po prostu, nie? To słuchajcie, to jest jeden z modeli, nie? Bo to też możemy sobie pogadać trochę o kosztach takiego modelu. No to generalnie taki model, w którym nie możesz popsuć czegoś nikomu innemu. W związku z tym musisz mieć jasno wyspecyfikowane kontrakty. Jasno markowane breaking changes na przykład. Poza tym koniec końców gdzieś jeżeli na przykład masz jakąś informację do partnera, to partner rozmawiać z każdym teamem osobno, tylko potrzebuje mieć jakąś na przykład konwencję ogólnie rowania jakiegoś swojego API, więc też musisz to gdzieś uspniać na poziomie organizacji. To jest koszt, który trzeba po prostu ponieść wcześniej. Ale ja chciałem trochę pograć Monikę o lening i trochę pochallengeować tam Wojtka. Nie, nie wiem kto teraz challengeuje kiedyś challengowała Monika Olejnik, bo tak jak słyszę o tym teamie i ten team ma bardzo różne specjalizacje, to są ludzie trochę z innej bajki, oni się pewnie trochę nudzą na planowaniu, jak tam nie wiem, gada głównie w tym momencie powiedzmy frontendowiec, iOSowiec, a tam backendowcy w tym czasie zbijają bąki. To jest tam trochę przesada wiadomo, ale koniec końców wpadają jakieś featery, pomysły, one są biznesowe. Jedna okazuje się, że akurat no tu ten gościu oddajy nie ma co robić.
No więc w tym sprincie kiedyś według takiego kanonicznego scrama to robiłby co innego. Na przykład testowałby, no bo mamy być zastępowali. Rozumiem, że tak nie jest. Rozumiem, że oni mają troszeczkę swoje własne osobne backlogi. Czyli wobec tego on będzie robił coś innego z datą. Co nie masz czegoś takiego jak cel sprintu? Datą. Tak. Tak, bo właśnie to co powiedziałem, że bardzo często tworzą się projekty wirtualne, tak? Czyli i teraz jeszcze powinienem dodać, nie ma absolutnie żadnej reguły wymuszonej firmie, jak zespoły powinny się organizować same. To jest dla zespołu. Tak jak powiedziałem, niektóre pracują, u nas było to samo. Kambatem, scrambanem, inne wiesz, kanbanem. Każdy sobie może wybrać metodologię jak chce. Są punkty synchronizacji, tak jak mówis. Weźmy takiego. Ale tylko wejdę na chwileczkę tylko wejdę, bo to jest to nie, bo tam też jak miałem powiedzieć coś, jak ty mówiłeś Sebastian, o redundancję właśnie planowanie z obłożenia ludzi i tak dalej, nie? Że tutaj wchodzi to, że według mnie tu się sprowadza to do ustawienia zasad jak pracujemy, niektórych rzeczy wspólnych, na przykład na jakich narzędziach pracujemy. Nie, że jedno narzędzie, ale na zestawie narzędzi, które pracujemy, żeby ludzie mogli przechodzić i wiedzieli, że to działa, nie? Bo teraz to co powiedziałeś, to jest dokładnie to.
Do tego się mogę za chwileczkę, Tomek odnieść. Nie, u nas nawet każdy zespół projektowy mógł się zorganizować inaczej, mieć inny rytm i tak dalej, nie? Ale wszyscy pracowali na tych samych narzędziach, więc jak osoba musiała wejść w projekt, to wiedziała gdzie co jest, gdzie co powinno być, jakie artefakty powinny być i tak dalej. Tutaj tak do tego jeszcze powiem coś, co musi paść. Nie ma ani jednej osoby w firmie, która ma tytuł Agile łaman przez scram. Jak żyjecie jakoś. E, więc y nie ma żadnej osoby, która wiecie masuje te procesy. Zakłada, zakładamy, że zespoły są na tyle odpowiedzialne i organizujące się, że faktycznie wiecie, dopasują się do tej, do tej do tej maszyny. Można by powiedzieć, do tego co Tomek powiedziałeś. Może sekundka małe przypomnienie dla wszystkich. Słuchajcie, jeżeli macie jakieś pytania albo chcecie się podzielić, albo ustosunkować odpwiedzieć jak to u was działa, to wrzucajcie koniecznie na czat. do tego co Tomek powiedziałeś, czyli czyli jeżeli chodzi o kwestie Czekaj, bo tam było kilka rzeczy, których dotknąłeś przed chwilą, jakbyś mi mógł przypomnieć.
Ja Tomek, tak, bo do tego chciałem mówiłem o tym, o że mają być zasady pracy, wspólne narzędzia i tak okej, dobra. To nie musi być od, ja bym powiedział, od dnia zero. Prawda jest taka, że wiecie parę rzeczy może się podiać organicznie, możemy się z możemy się zorganizować. Narzędzia same, które potrzebujemy, same się pokażą. I ja bym powiedział i teraz Sebastian zanim zanim od razu wyskoczysz to powiem, ale oczywiście są narzucone narzucone pewne zasady, pewne ograniczenia jeżeli chodzi o tooling, jeżeli chodzi o wybór na przykład narzędzi, języków, baz i tak dalej, i tak dalej, to im więcej, tak, im więcej, słuchajcie, ograniczeń damy, tym zespół będzie szybszy, bo będzie mógł pracować, nie będzie musiał rozwiązywać tych samych problemów. To jest pierwsza rzecz. Druga rzecz, faktycznie coraz więcej takiego governansu i automatyzacji. Tam gdzie ona się ma sens, to coraz więcej jej się pokazuje, tak? Czyli chodzi o to, żeby zespół mógł mógł coraz szybciej bez ręcznych narzutów wykonywać swoją pracę.
I bardzo często my patrzymy, okej, co robimy ręcznie, a co możemy zautomatyzować? I tak jest. Wiecie co? kwartał, pół roku, rok, jak człowiek popatrzy na tą deltę, no to faktycznie udaje się sporo tych rzeczy zrobić, więc to jest taka zasada, której się mocno próbujemy trzymać. To jest jedna rzecz, której żeśmy nie dotknęli, ale ona jest bardzo ciekawa, to jest to, że no dobra, jak dostawiasz tą tam swobodę zespołom, że tam mogą pracować jakimś scrambatem czy jakimś innym czymś dziwnym, to gdzieś koniec końców ty musisz mieć tą zunifikowaną perspektywę na przykład tych samych metryk, na które patrzysz, definicji tych samych met. Tak, ale wiesz co, ale to jest dokładnie ten zestaw, że ustalasz jakieś zasady gry czy protokół synchronizacji. Nie, no ja to rozumiem. Tylko właśnie szkoda, że tą Okej, dobra, dobra. Czyli to już już wam powiem. Mięsko to jest to, co ludzie interesuje. Tak, tak. Jeżeli ktoś jest bardzo zainteresowany, to jest takie narzędzie, które zostało wypuszczone na rynek, nazywa się People Ops i ono służy tak naprawdę do synchronizacji całej firmy. Tam mamy zarówno cele, jak i KPI z góry na dół od wiecie od poziomu CEO w dół.
To nie są yyy to nie są OKRy. Yyy to bardziej są właśnie cele i KPI. A i teraz yyy możemy to jest pierwsze narzędzie synchronizacji, tak? Czyli ja mogę iść do pier do każdego zespołu, mam totalnie przerzroczyste jaka jest ich roadmapa, jakie są ich cele, tak? Bo to są dwie różne rzeczy. A cele, tak jak powiedziałem, przede wszystkim jeżeli optymalizujemy tak jak, tak jak Revolut, no to to będzie wzrost komercyjny, wzrost użytkowników i satysfakcja użytkowników. takie powiedzmy trzy cele. Tak. A ale na tym, znaczy ja rozumiem, że to jest gdzieś tam jakaś tak idea z tyłu, ale to to nie jest tak, że tak operacyjnie to się wcale o tym nie gada, tylko gada się o tym, czy dowiozłeś projekt ABC, czy stokrotka skończyła się. Tak, absolutnie, absolutnie. Tak więc i teraz jeżeli chodzi o to, co jeszcze pytasz, do tego dochodzą punkty synchronizacji, tak? Czyli y faktycznie jest tak, że raz na dwa tygodnie na przykład jest jakieś tam i teraz uwaga wirtualne demo, czyli są nagrywane asynchronicznie dema, więc nie nikt nie musi siedzieć i wiecie i klepać a i czekać jak inni zaprezentują w kolejce.
Tylko to co mnie interesuje, mogę sobie wybrać, oglądnąć. To jest pierwsza rzecz. do tego jeszcze wszystkiego faktycznie co kwartał jest synchronizacja jeżeli chodzi o to co wypuszczamy co planujemy i co tydzień dwa jest synchronizacja na przykład na poziomie no jak to zwał z zwału jak zwał tribów składów także z na przykład head of product head of department i tak dalej ciekawostka jesteśmy już tam 53 minuty in ale jeszcze ani razu nie padło team topologisties to chyba dobrze. Okej. Ja bym jeszcze chciał jedną rzecz poruszyć. D było okej. No i dalej jest już jest mamy 7 minut. Ja bym jedną rzecz chciał poruszyć. Powiedziałeś Wojtek coś takiego, że zespół to to ma wszystko, żeby tam swoją robotę robić. Ma tam jak ma potrzeba deopsa kogoś do relisu i tak dalej to też to ma. Nie powiedzieliśmy nic o jakości. Jakości w sensie quality assurance. Czy jak to jest w tym w tym nowoczesnym nowoczesnych procesach? Czy ma swoich procesowany teraz? Jeżeli nigdy nikt mnie nie słyszał, to myślę, że może być zdziwiony. Ale uwaga, będą kalumnie.
Jest bank, który nie ma ani jednego Qwaya. Ma tylko compliance. Słyszycie to? Tak. I compliance też ma. Bardzo, bardzo zresztą wiecie uwielbiane przez bardzo wielu regulatorów. Ma tylko środowisko DEF i produkcyjne, więc da się to zrobić. o tych regulatorach, bo to znaczy, że to nie wy. Słuchajcie, da się zrobić. Y i to działa. Tak, czyli co to oznacza? Ten ownership faktycznie idzie też w kierunku jakości, tak jak powiedziałeś, ale to w praktyce jak to jest implementowane wobec tego? To co jest oczekiwanie, że deweloperzy wszystko automatyzują, mają pełną piramidkę od unitów integration end to end, znają te wszystkie narzędzia na tym samym staku. Teraz na przykład wdrażamy nowe też narzędzie do end to end testów. Także taka takie jest oczekiwanie. Mówimy o tysiącach testów. Czyli dla mnie wiecie zbudowanie po pierwsze TDD, po drugie zbudowanie danego featera musi łączyć się z tym, że ja myślę o ty o tym jak on ma działać, o o przypadkach brzegowych i go otestuje. Tak. I to jest absolutnie to ten jeden film sam w ramach siebie wewnętrznie.
Absolutnie tak. Absolutnie tak. Kolejna rzecz, no to oczywiście, żeby móc tak pracować, to musimy mieć feature flagi i jakieś jakieś, słuchajcie, narzędzia do relasowania. AB testów i tak dalej, i tak dalej. Więc to też jest, to też jest taka ciekawostka, że to jest inhouseowe narzędzie, ale dzięki temu zobaczcie co się dzieje. Małe inkrementy, bo to jest takie nieraz wiecie po kilka kilka komitów dziennie danego featera leci cały czas na dea i z dea leci na produkcję. na produkcji. My mamy kilka relasów dziennie, nawet w niektórych serwisach, tak więc yyy te yyy to cały czas wychodzi, nie ma problemu integracji, nie ma problemu release sprintów i tak dalej, i tak dalej. Ej, to ja ci tego nie odpuszczę. Czekaj, ctery minuty. Powiedziałeś, że tylko def i tylko produkcja, bo to to tam to wcześniejsze to mnie nie zszokowałeś, a tym to mnie akurat trochę zszokowałeś, no bo generalnie to jest tak w ogóle jeszcze jest okej, jeszcze jest sbox, jeszcze jest sbox, bo jest wymagany przez regulatorów.
No. No więc teraz tak, ludzie pracują nad czymś. Zakładam, że dewelopentem pracą lokalnie u siebie na stacji jak mogą nad jakimś tam wycinkiem, ale muszą się integrować, więc zakładam, że integrują się mergejąc do jakiegoś brancha, który jest branchem wspólnym i to ten branch wspólny jest jest na tym devie. Czy to jest tak, że mają wiele branchzy i w sumie na tego dea to każdy na yolo może zdeplojować co chce? No nie, no shorting branch zdecydowanie, więc więc wiesz, czyli trank based development, tak? Okej, czyli de facto mogą zdyplojować tam co chcą, albo nie, inaczej jest reżim, że dyplują tylko i wyłącznie maina na tym devie, czy jak? W którą stronę? Main tylko main. Okej, czyli dopóki nie są demowani do maina, to de facto są uśmiechniecie się, ale master. No, do no dobra, master. Spoko, main, whatever. Kilka epitetów brzmi, brzmi boleśnie, bo w tym momencie jesteśmy swoim teamem, na przykład jesteśmy team stokrotki i mamy środowiska. Yyy, jeżeli chcemy się zintegrować w ramach teamu, czyli ja chcę zobaczyć, co tam zrobił Czesiek i tak dalej, to de facto po prostu muszę spolować jego zmiany i odpalić to u siebie. Yyy, jeżeli Czesiek jest frontendem, ja generalnie frontendu w sumie nie chcę diplować u siebie, to i tak muszę to zrobić, bo yyy bo bo bo nie mam innej opcji, bo nie mam środowiska, na którym mógłbym zobaczyć, co nasz
wspólnie zespół razem dokonał. Masz, no masz dea. Tak, to jeżeli możesz, ale tam już jest po mergeu, tamto już jest przecież na mailu. Możesz, możesz możesz lokalnie, możesz wiesz, zależy jak sobie ułożysz pracę. Tak, bo jeżeli to ile na ile to jest zautomatyzowane wszystko, Wojtek? Y dość. Muszę powiedzieć, że automatyzacja jest, tak jak powiedziałem jest takim dosyć elementem. Tak sobie pomyślałem, że wiesz, że chodzi o to, że jeżeli on nawet musi czy ona to zdeplejować wszystko, nie? Ale jeżeli jest to effortless pod tytułem nie musi myśleć o tych wszystkich innych rzeczach, tylko wie co ma zrobić i co się stanie, to nie widzę problem. No jest problem, to trwa wachlowanie na przykład tymiami. Pytanie ile trwa, ale to wiesz, to jest też kwestia ile na przykład jak to jest gryzione w tle, nie? Czyli czy na przykład za każdym razem musi to być pełen inkrement, czy na przykład jest to inaczej zrobione. Nie, to jest ciekawy temat. Niestety skończył nam się czas. Zostało nam dwie minuty.
To akurat w sam raz tyle, żeby po zamknąć w Graceful. Chociaż zrobiliśmy jakieś, nie wiem, musimy się ogarnąć, bo zrobiliśmy ze trzy punkty tylko z tej listy, więc jest albo robimy jakiś City of Morning Day, gdzie będziemy grać przez cały dzień, albo nie wiem co, bo w każdym razie nie dość, że my tego nie domknęliśmy, to nawet nie liznęliśmy tego tak na poważnie. No lista była długa. Tak, musimy się zastanawić nad sobą poważnie. E, ale ja tylko, ja tylko, ja tylko od kuchni powiem dla wszystkich, że lista, o czym mieliśmy porozmawiać, ma tak na oko z 30 punktów i na końcu jest jeden punkt, o czym nie gadamy. Okej. Dajcie nam znać, co było interesujące i może w co w co warto jeszcze głębiej wskoczyć. Jestem smutny, bo mało osób się się udzielało swoimi pytaniami, swoimi komentarzami, więc jestem jestem smutny. Będę miał smutny dzień. To przez was. Tak. wszystkim wesołego piątku w ten w tym tygodniu w poniedziałek wpadło nowe blue Sebastian będzie miały piątek wpadło faj wpadło nowe bwół nowe bru jest bardzo fajne także polecamy się na przyszłość polecamy się gorąc to jest jeszcze ma działanie terapeutyczne jak to padło w jednym komentarz a wiecie następne brw będzie między innymi o sorze 2. To będzie ciekawe. To już się możecie nakręcać.
Ja dostałem dzisiaj świeżą partię filmu z Sora 2. Jest wymiot. Znaczy czę wymiot. Możemy nagrać kolejny odcinek w ogóle przez Sora 2, nie? A nie wiem czy widzieliście tą Nie da się incepcję Sorry. W sensie y na Sorze już wygenerowane blopersy na przykład y jak wyglądały pseudo nagrania na Sorze. To mi się też też podobało. Anyway, dobra, rozgadaliśmy się. Kończymy. Dzięki bardzo. Fajnie się gadało jak zawsze. Y mam nadzieję, że było interesujące również nie tylko dla nas, ale też dla was. Dajcie nam znać w co warto się może zagłębić i właśnie pogrzebać. Dokładnie tak. Dokładnie tak. A póki co to miłego piątku, miłego weekendu. Korzystajmy z pogody, póki jeszcze jest miara ładna i do usłyszenia, do zobaczenia. Strzałeczka. Dzięki. Hej. M.
