Krzysztof:
To jest 305. odcinek Porozmawiajmy IT. Dziś rozmawiamy o przewidywalności dowożenia przez zespoły IT.

Wprowadzenie do przewidywalności w IT

Krzysztof:
Notatkę linki i transkrypcję znajdziesz na porozmawiajmyoit.plpl, łamane na 305. A jeśli myślisz o zmianie pracy, albo po prostu masz dość klikania dalej na głoszeniach bez widełek, to zajrzyj na Solid Jobs. Tam wszystko jest na tacy. Wynagrodzenie, technologie, projekty. Bez zgadywania. Nazywam się Krzysztof Kempiński. Tworzę ten podcast, napisałem też książkę Marka Osobista w branży IT. Jeśli lubisz moje rozmowy, będzie mi bardzo miło, jeśli udostępnisz ten odcinek dalej albo zostawisz ocenę w swojej apce. To naprawdę pomaga przebijać się przez algorytmy i docierać do kolejnych osób z branży. A teraz odpalamy! Cześć, mój dzisiejszy gość to konsultant z ponad 20-letnym doświadczeniem w branży IT. Pomaga firmom technologicznym uporządkować pracę zespołów, by efektywnie i przewidywalnie dowoziły wyniki biznesowe. Autor książki Labirynty Scruma, współtwórca podcastu Porządny Agile oraz współzałożyciel firmy konsultingowej 202%. Moim waszym gościem jest Jacek Wieczorek. Cześć Jacku, bardzo miło mi gościć w podcaście.

Jacek:
Cześć, dzięki za zaproszenie. Fajnie, że możemy porozmawiać o tym temacie.

Krzysztof:
No właśnie, bo w branży IT już pewnie od dosyć dawna słyszymy o tym, żeby dowozić dużo, żeby dowozić często, szybko. No bo przecież konkurencja, no bo przecież w ostatnim czasie AI musimy być pierwsi, musimy jak najwięcej tej wartości dostarczać. Tymczasem, gdyby się przyjrzeć temu procesowi tak bardziej dogłębnie i precyzyjnie, to pewnie okaże się, że oprócz szybkości dowożenia jest coś,

Podcasty w życiu Jacka

Krzysztof:
co właśnie w dłuższej perspektywie może mieć nawet większe znaczenie. I tym czynnikiem jest właśnie przewidywalność. To jest temat, który dzisiaj bierzemy sobie na tapet z Jackiem. Dobrze, Jacku, to może takim pytaniem wprowadzającym z mojej strony będzie to, czy słuchasz podcastów i co ciekawego na twojej liście podcastowej się znajduje.

Jacek:
Tak, podcastów słucham myślę już dosyć od dawna. Zaczynałem od Marka Jankowskiego i od Michała Szafrańskiego. Takie dwa, bym powiedział, może nie do końca związane z tym, co się zajmuje. Podcasty, ale bardzo interesujące. Natomiast tak jak dzisiaj sobie o tym myślę, czego najwięcej słucham, to jest to podcast Bieganie.pl na ten moment, czyli widzę, że w tym wolnym czasie, kiedy mogę, to raczej spędzam czas na słuchaniu rzeczy, które nie są tak bezpośrednio związane z moją ścieżką zawodową, a raczej dotyczą hobby, tym co robię w wolnym czasie.

Krzysztof:
No jasne, głowa musi też w końcu odpocząć, to jest niezwykle istotne.

Definiowanie przewidywalności

Krzysztof:
Właśnie, dużo będziemy dzisiaj mówić o przewidywalności, więc na początku warto byłoby zdefiniować, czym ona w ogóle jest, oczywiście w kontekście pracy zespołów IT.

Jacek:
W mojej definicji przewidywalność mówi nam, w jakim stopniu zespół dowozi lub dostarcza to, co zaplanował. I możemy na to spojrzeć zarówno w perspektywie całego projektu, czy całej inicjatywy, za którą odpowiada zespół, ale możemy też spojrzeć trochę wężej, czyli zobaczyć na przykład, czy w jakichś sensownych odcinkach czasu tygodniowych, dwutygodniowych zespół realizuje, to, co planował zrealizować, czyli z mojej perspektywy jest to takie wczesne ostrzeganie, czy będziemy mieć problemy z dowiezieniem jakichś konkretnych rzeczy na określony termin.

Krzysztof:
Właśnie w Scrumie, zresztą nie tylko w Scrumie, w różnych innych podejściach wywodzących się z Agile, przyzwyczailiśmy się, przynajmniej jako osoby techniczne, tutaj może bardziej mówię ze swojego punktu widzenia, do patrzenia albo do skupiania się właśnie na tym odcinku dwutygodniowym, miesięcznym, w zależności od tego, jaki sobie ten okres sprintu przyjmiemy. No i z tej perspektywy, jeśli zapytamy ten przysłowiowy biznes, czy coś ma być szybko, czy coś może poczekać, no to oczywiście powie nam, że jak najszybciej tak pewnie większość osób zajmujących się produktem, biznesem właśnie odpowie. Natomiast chciałbym Cię zapytać, czy z punktu widzenia biznesu to właśnie szybkość jest tym czynnikiem, który powinien głównie gdzieś tam widnieć w planowaniu, w rozmowach z osobami technicznymi, czy też może właśnie przewidywalność jest lepszym faktorem do skupienia się na nim?

Jacek:
Myślę, że taka pierwsza naturalna mysz to jest tak, jak powiedziałeś, czyli generalnie chcielibyśmy, żeby było szybko. Oczywiście tutaj nikt nie ma wątpliwości, Ale im dłużej rozmawiam z osobami biznesowymi, tym coraz częściej słyszę od nich, że oni by woleli, żeby pewne rzeczy były realizowane w przewidywalny sposób, być może troszeczkę wolniej. Niż bardzo szybko, ale w dosyć takim dużym rozchwianiu. Na zasadzie raz się uda dostarczyć na czas, raz się nie uda. Więc przez to, że biznes nie działa w próżni, no bo mamy jakieś terminy, mamy jakieś zobowiązania, są jakieś zmiany w prawie, na które musimy zareagować, są zaplanowane jakieś kampanie marketingowe, no to okazuje się, że jednak wszystkie te rzeczy mają wpływ na to, że pewna doza, bo będziemy tutaj dzisiaj rozmawiać o pewnym takim zakresie przewidywalności, jest jednak czymś, co obok szybkości dostarczania, które oczywiście też ma sens,

Koszt braku przewidywalności

Jacek:
z perspektywy biznesowej jest istotnym czynnikiem.

Krzysztof:
Właśnie z perspektywy biznesowej ważna jest optymalizacja zysku, ale też minimalizacja kosztu. Czy możemy mówić o czymś takim jak koszt wynikający z braku przewidywalności?

Jacek:
Tak, ja myślę, że tutaj poszedłbym takimi dwoma ścieżkami. Pierwsza ścieżka to jest kosztu traconych korzyści, czyli przykładowo, jeżeli chcemy wprowadzić, na przykład prowadzimy jakiś biznes e-commerce i chcielibyśmy wprowadzić płatność ratalną, wierzymy, że ona spowoduje, że ludzie będą wkładać więcej produktów do koszyka, no to im dłużej nie będziemy mieć tej funkcjonalności, no to można to policzyć w pieniądzu, ile potencjalnego przychodu czy zysku straciliśmy. To może być też taki aspekt, że… Nie będziemy pierwsi na rynku, bo nasza konkurencja wprowadzi jakieś funkcje, jakieś udogodnienia dla klientów i po prostu będziemy te pieniądze tracić i to jest bardzo mocno policzalne, myślę, że nawet prościej niż drugi aspekt, który również ma znaczenie, bo myślę, że musimy tutaj pamiętać też o koszcie wizerunkowym, czyli przykładowo teraz wiele firm, które dostarczają oprogramowanie finansowe, musi zadbać o to, żeby poprawnie zaimplementować funkcjonalność związaną z KSEF-em.

Jacek:
No i teraz jeżeli nasz produkt, który rozwijamy, nie będzie gotowy na czas, nie będzie kompatybilny z KSEF-em i z wymogami prawnymi, no to możemy mieć problem z pozyskiwaniem kolejnych klientów, no bo pójdzie fama, że ta aplikacja nie odpowiada na to, co się dzieje na rynku prawnym. A z drugiej perspektywy, wyobraźmy sobie, że prowadzimy na przykład software house, no to brak przewidywalności, brak takiej pewności co do tego, czy te rzeczy, które są obiecane będą zrobione, mogą z kolei spowodować problemy z utrzymaniem klienta. Więc ten koszt wizerunkowy może zarówno mieć wpływ na to, że klienci będą bądź odchodzić od naszych produktów czy usług, albo o wiele trudniej będzie nam ich do naszej oferty przyciągnąć.

Krzysztof:
Czyli powiedzmy lepsze planowanie, ale też właśnie unikanie pewnych kosztów, pewnych problemów, o których ty powiedziałeś, jest wszystkim tym, dlaczego biznes powinien się skupić na przewidywalności. Natomiast z perspektywy IT, przynajmniej, Oczywiście mogą być jakieś rzeczy związane z taką wiarą wewnętrzną tego zespołu, czy członków tego zespołu w to, że działają sprawnie, działają skutecznie.

Zaufanie w zespole

Krzysztof:
Taka, można powiedzieć, motywacja się wtedy gdzieś tam polepsza. Ale gdybyśmy to zestawili tutaj z biznesem, czy według ciebie to, że zespół dowozi w sposób przewidywalny, powoduje, że biznes pokłada jakieś większe zaufanie właśnie w tym zespole, że ta współpraca lepiej wygląda?

Jacek:
Tak, myślę, że generalnie jakby na początek dać taki przykład życiowy, no to po prostu ludzie, na których możemy polegać, ludzie, którzy mówią, że coś zrobią, a potem to zrobią, no to ja na takich ludzi patrzę na zasadzie, ok, to są ludzie, którym mogę zaufać. Coś powiedzieli i to zrobili, jeśli były kłopoty, no to bardzo wcześnie usłyszałem jakieś wytłumaczenie, co się stało, co możemy zrobić. I moim zdaniem to się bardzo dobrze przenosi również na ten świat biznesowy. Istnieje nawet wzór na zaufanie z książki bodajże Trusted Advisor. Takie książki o tym, jak skutecznie prowadzić biznes konsultingowy i tam był wzór na zasadzie, że zaufanie to jest w liczniku była wiarygodność, rzetelność i bliskość, taka bliskość biznesowa, a w mianowniku mieliśmy skupienie i koncentracja na sobie. Więc rzetelność, im ona jest większa, im bardziej wypełniamy nasze obietnice,

Wartość przewidywalności

Jacek:
tym ta nasza góra tego orównania, ten licznik będzie nam rósł.

Krzysztof:
Czyli mówimy tutaj o tym, że przewidywalność jest pożądana zarówno ze strony produktowo-biznesowej, jak i z tej technicznej, wnosi wiele wartości, ale samo postawienie sprawy w ten sposób nie mówi nam o tym, jaka wartość tej przewidywalności, jakkolwiek będziemy sobie to mierzyć, jest pożądana. Można byłoby przewrotnie powiedzieć, że przecież zespół, który dowozi 30% oczekiwań czy ustalonego planu, też dowozi w sposób przewidywalny, jednak nie jest to pewnie idealna sytuacja.

Jacek:
Miałem na LinkedInie ostatnio krótką wymianę właśnie na ten temat, że o co chodzi? Przecież jeżeli zespół, który regularnie nie dowozi, no to to jest zespół, który jest przewidywalny. On po prostu przewidywalnie nie realizuje obietnic. I mój komentarz wtedy był taki, że to jest ogólnie taki dobry żart, ale ten żart nie będzie śmieszny, kiedy będzie trzeba opowiedzieć o statusie prac na zarządzie. Więc w mojej definicji taka tak ujęta przewidywalność to nie jest przewidywalność, o której ja myślę.

Mierzenie przewidywalności

Jacek:
Dla mnie przewidywalny zespół to jest taka zdrowa przewidywalność, czyli to, co sobie planujemy, to faktycznie realizujemy. Jeżeli regularnie nie realizujemy naszych założeń, to ja to bardziej traktuję w kategoriach problemu, który należy rozwiązać, bo rozwiązanie tego problemu generalnie nie jest jakieś super trudne i skomplikowane, tylko po prostu trzeba mieć świadomość, że w ogóle ten problem istnieje i dopiero wtedy zastanowić się, ok, jeżeli to jest faktycznie problem, to co możemy z nim zrobić.

Krzysztof:
Żeby być świadomym tego problemu, trzeba tę przewidywalność w jakiś sposób mierzyć i zastanawiam się, czy tutaj odpowiednią perspektywą jest pojedyncza iteracja, czy to nam cokolwiek daje, czy też potrzebujemy być może tych iteracji mieć ileś, żeby pewne wnioski wyciągnąć. No i właściwie jak tą przewidywalność mierzyć?

Jacek:
Ja jestem fanem tego, żeby jednak zacząć od tej przewidywalności takiej w iteracji, w sprincie, w tygodniu, jakkolwiek sobie ten zakres określimy, no bo jeżeli w tak krótkim okresie nie jesteśmy w stanie uzyskać przewidywalnych wyników, no to oczywiście to będzie impaktować na to, czy będziemy w stanie coś dostarczyć na za dwa, za trzy, czy za miesiące, czy za pół roku.

Jacek:
Więc to jest jakby jeden aspekt, dlatego patrzyłbym na ten okres wąski, no bo on jest wczesnym ostrzeganiem, że są problemy. I teraz jak to faktycznie policzyć? Ja bym na to spojrzał, że to jest po prostu stosunek ilości elementów, tematów, zadań, które zrealizowaliśmy w trakcie konkretnej iteracji do ilości zaplanowanych elementów, zadań, tasków na tą konkretną iterację. Jak słyszysz mówię tutaj o ilości bo generalnie na dzień dzisiejszy jest mi o wiele bliżej do mierzenia przepustowości czyli ile rzeczy robimy w konkretnym okresie a raczej staram się odchodzić od też popularnego podejścia którym jest liczenie story pointu wtedy też mogę sobie zsumować story pointy ile zostało zrealizowanych w trakcie sprintu, W stosunku do tego, ile zaplanowaliśmy, ale tak jak mówię, wolę raczej dzielić pracę na małe kawałki, porównywalne kawałki i odejść w ogóle od tej próby szacowania, no bo ona co do zasady jest skazana na porażkę.

Krzysztof:
Tak, taki trend tutaj nawet mówiąc też widzę coraz szerzej. Zresztą gdzieś tam sami można powiedzieć, o co je założyciele Agile czy też Scrama również się do tego gdzieś tam skłaniają, żeby właśnie takie podejście zastosować i myślę, że bardzo dobrze, bo przecież jedną z wartości tego podejścia jest to, żeby się uczyć, żeby się zmieniać i dostosowywać do sytuacji. Okej, jak natomiast to, o czym teraz powiedziałeś, ma się do często, może nie często, ale jednak spotykanej sytuacji, kiedy ze sprintu, który jest w jakiś sposób zaplanowany, określony, pewne zadania wypadają, pewne zadania dochodzą, no bo przecież wiemy, że nie do końca być może ten scope zadania, pewnego milestone na epika, był nam znany, bo biznes się zmienia. No mnóstwo różnych czynników oczywiście na to wpływa. Temat pewnie też na inną

Fluktuacje w sprintach

Krzysztof:
rozmowę. Natomiast tak się dzieje, prawda? Więc teraz, kiedy zestawimy to z mierzeniem przewidywalności, to jak ten fakt, że ten sprint nam troszkę fluktuuje pod względem zakresu, jak te dwie rzeczy tutaj ze sobą współdziałają, wpływają na siebie?

Jacek:
Myślę, że zanim odpowiem na to pytanie, to warto zaznaczyć, że przewidywalność traktowałbym jako taki wewnętrzny kompas zespołu, czyli to ma być taka miara wewnętrzna, która pomaga zespołowi lepiej planować i realizować swoją pracę.

Jacek:
Stąd jestem ok z tym, że ten kompas Raz pokazuje północ, raz może trochę inny kierunek I my wiemy, co to dla nas oznacza, Teraz przenosząc tą opowieść już na takie realia zespołowe, no to zależy co chcemy tak naprawdę zmierzyć, no bo ja bym rozróżnił, jeżeli chcemy zmierzyć jak trafnie realizujemy to, co sobie zaplanowaliśmy, no to wtedy ta przewidywalność będzie nam mierzyć jak dobrze realizujemy plan, ale możemy na to spojrzeć z innej perspektywy, czyli możemy potraktować przewidywalność jako zdolność zespołu do realizacji pewnej liczby zadań. I ta pewna liczba zadań, ona może się zmieniać w trakcie sprintu, na zasadzie, tak jak powiedziałeś, pewne rzeczy mogą zostać dołożone w trakcie, jakieś rzeczy mogą zostać zabrane. I teraz pytanie, co jest dla nas bardziej istotne, czy chcemy się skupić na tym, ile mniej więcej jesteśmy w stanie zrealizować w jakimś wybranym okresie, czy raczej chcemy sprawdzać przewidywalnością, jak trafnie realizujemy plany. I teraz w zależności od tego, w jak dynamicznym środowisku będziemy pracować, no to jedne zespoły mogą skłaniać się bardziej ku temu, żeby sprawdzać, czy dobrze podążamy za planami, ale będą zespoły, które po prostu będą chciały wiedzieć, ile my tak naprawdę możemy zrealizować w jakimś wybranym okresie, żebyśmy byli w stanie sobie spojrzeć.

Jacek:
Na szerszy obrazek i na bazie tych danych policzyć, czy ten termin, który przed nami czeka, czy on jest realny do osiągnięcia, czy przy tym tempie pracy, przy tym napływie zmian, czy w ogóle jesteśmy w stanie taką ilość podjąć.

Krzysztof:
No właśnie, czy to jest ta przewidywalność, czy to jest swego rodzaju metryka, swego rodzaju czynnik, tak czerwona lampka, która nam się może zapalić w trakcie, że pewne wartości schodzą poniżej określonej, przyjętej dla nas wartości, czy też może jest to pewna wartość, którą możemy wykorzystać do przodu, planując zadania, planując sprint, być może nawet dalej, czy na jej bazie jesteśmy w stanie coś estymować, coś wnioskować do przodu, czy też może tylko mierzyć, co się wydarzyło?

Jacek:
Ja patrzę raczej na to, że to jest pewien zakres, czyli raczej bym nie spodziewał się albo nawet więcej, byłbym podejrzliwy, gdyby zespoły regularnie miały przewidywalność 100%, bo to by znaczyło, że dokładnie to, co zaplanowaliśmy, to zostało zrealizowane. I raczej bym szukał pewnego zakresu, bo jeżeli będziemy bardzo mocno trafiać w te plany, no to należy się zastanowić z czego to wynika. Może to wynikać z tego, że ta miara została wykorzystana jako narzędzie opresji, na przykład przez kadrę zarządzającą, no więc zespół, żeby mieć święty spokój, tak inteligentnie planuje, no żeby po prostu się wyrabiać. Może to hamować na przykład ambicje zespołu do tego, żeby sprawdzić może jesteśmy w stanie wziąć trochę więcej pracy no i wtedy ta przewidywalność będzie nam szła w górę, czyli według tego mojego wzoru będzie wynosiła powyżej 100%, 110, 120 w zależności od tego, ile więcej zespół dostarczył w stosunku do tego co planował. Z drugiej strony poniżej pewnej wartości no to będzie oznaczało, że mamy jakiś problem, czyli jeżeli.

Zakres przewidywalności

Jacek:
Dla mnie to jest taki 80%, 80% do 120% to jest powiedzmy taki zdrowy zakres przewidywalności, ale spotykam zespoły, które mają przewidywalność na poziomie 30%, 40% i z mojej perspektywy, patrząc z perspektywy osoby, która była w roli menedżerskiej i musiałem brać jakiś tam ciężar odpowiedzialności za to, co zespoły robią bądź nie, no to taka przewidywalność dla mnie jest nieakceptowalna.

Krzysztof:
Mówiłeś tutaj o tym, że raczej widziałbyś to jako taką miarę wewnętrzną dla zespołu, która coś mówi o pracy tego zespołu. Czy są jakieś ryzyka, jakieś niebezpieczeństwa, jeśli chcielibyśmy tą miarę wynieść wyżej, jeśli chcielibyśmy ją w jakiś sposób wyeksponować np. Dla kadry zarządzającej?

Jacek:
No myślę, że główne ryzyko może być takie, że może to być miara, która zostanie ograna na zasadzie, jeżeli zespoły widzą i czują, że należy mieć przewidywalność na poziomie 100%, no to ona będzie i to nie dotyczy tylko przewidywalności, tylko właściwie każdą miarę, którą sobie nie wymyślimy, no jesteśmy po prostu w stanie do niej doprowadzić tak, żeby wskazywała te spodziewane rezultaty. Oczywiście gdzieś tam mniej widoczne jest to, że coś poświęcamy, czyli albo moglibyśmy realizować więcej pracy, ale chcemy być bardzo zapobiegawczy i po prostu robimy te spokojne 100% i nic więcej.

Jacek:
Albo jakieś tam rezultaty są osiągane jakimś kosztem, być może rośnie dług technologiczny, być może jakościowo pewne rzeczy nie są tak dobrze przetestowane, jak by mogły być. No i moim zdaniem to jest kwestia kultury firmy. Jeżeli panuje kultura taka opresyjna i ludzie raczej czują strach, kiedy myślą o miarach, no to eksponowanie takich miar, które z mojej perspektywy idealnie,

Rola miar w zespole

Jacek:
gdy pozostaną po prostu tym wewnętrznym barometrem zespołu, może być problematyczne. Ale znam firmy, gdzie miary nie są narzędziem do karania zespołów, a raczej są tylko czymś wokół czego możemy porozmawiać, czyli jeżeli mamy jakieś miary, no to możemy się zastanowić czy to co one wskazują, czy to jest dla nas ok, czy nie, możemy porozmawiać o trendach i patrzeć na to bardziej z perspektywy systemowej, czyli one nam coś pokazują, są jakieś problemy i zastanówmy się na spokojnie z czego te problemy wynikają.

Krzysztof:
Myślę, że tutaj warto byłoby jeszcze dodać taki klocek trochę narzędziowy, czyli jak właśnie od tej strony narzędziowej możemy mierzyć przewidywalność obecnego.

Jacek:
Najwięcej zespołów, które ja spotykam w swojej praktyce, korzystają z JIR-y. Jest to narzędzie, które jeśli jest dobrze skonfigurowane, to sporo miar i w szczególności też przewidywalność możemy sobie po prostu wyklikać, wchodząc w odpowiednie raporty. Więc jeżeli tą higienę używania JIR-y mamy na dobrym poziomie, czyli… Mam na myśli to, że ta faktycznie wykonywana praca jest odzwierciedlona w JIRA i jeżeli coś kończymy, to faktycznie odklikujemy to w narzędziu, czyli można powiedzieć, że jest JIRA wtedy takim bezpiecznym odbiciem tej faktycznie wykonanej pracy, no to wtedy JIRA jest naprawdę na start bardzo prostym, ale wystarczającym narzędziem, które z pudełka daje nam już możliwość podejrzania sobie przewidywalności. Jeżeli ktoś chciałby coś więcej, na przykład pytałeś o to, co jeśli nam wpadają rzeczy do sprintu, albo co jeśli wyjmujemy rzeczy do sprintu, jeżeli chcemy takie trochę bardziej już skomplikowane obliczenia sobie wykonać, na zasadzie może nie skomplikowane, a bardziej dopasowane pod nasze potrzeby, no to tutaj nieśmiertelny Excel nadal jest moim zdaniem pierwszym wyborem, no bo możemy sobie do niego wrzucać właściwie dowolne informacje, obrabiać, robić sobie do tego wykresy.

Narzędzia do mierzenia przewidywalności

Jacek:
Produkować linię trendu i tak naprawdę Excel ma bardzo niewiele ograniczeń i w kwestii liczenia przewidywalności czy ogólnie śledzenia miar zespołu nadal jest bardzo dobrym i dosyć też prostym w użyciu rozwiązaniem.

Krzysztof:
No tak bardzo uniwersalnym. Wspomniałeś o tej bliskiej 100% przewidywalności, która może rodzić pewne niepokoje, ale myślę sobie, że z punktu widzenia zespołu, jeśli faktycznie zespół traktuje to jako wewnętrzny barometr, no to jest raczej oznaka czegoś pozytywnego, jak ty podchodzisz właśnie do wyniku stuprocentowego tutaj w tych zawodach

Jacek:
Tak jak powiedziałem, jest to na pewno jakaś tam żółta flaga, którą bym rozważył, ale wyobrażam sobie też warianty takie bardzo pozytywne, czyli zespół po prostu wie, ile jest w stanie zrealizować, zna domenę, w której pracuje, skład zespołu jest w miarę stały, No więc tak naprawdę mało jest takich rzeczy, które mogłyby ten zespół zaskoczyć, zakładając, że ten produkt, który rozwijają nie jest jakoś przesadnie złożony no i generalnie są w stanie zaplanować sobie pracę, zrozumieć tą pracę, co jest do zrobienia i ją zrealizować. Ja sam pamiętam takie doświadczenia z zespołu, w którym pracowałem i liczyliśmy sobie przewidywalność. Były takie dyskusje na zasadzie, Ktoś się nagle odzywał, kurczę, może spróbujemy jeszcze to zadanie wziąć. No i ktoś inny mówi, no tak, ale co, jak nie dowieziemy, spadnie nam przewidywalność. No i się rozpoczynała dyskusja, której efektem był wniosek, no to nic, że spadnie. W sensie nie możemy jako zespół być niewolnikiem miary, tej konkretnej czy właściwie żadnej innej, w takim stopniu, że ona zaczyna nam wiązać ręce. Jestem wielkim fanem mierzenia, jestem z wykształcenia.

Jacek:
Inżynierem, więc zawsze będę szukał liczby, jakiejś cyferki, a nie tylko komentarza czy odczucia, ale w momencie, kiedy te miary zaczynają nas paraliżować i zaczynamy podejmować dziwne decyzje, no to wtedy taka miara z mojej perspektywy staje się zagrożeniem.

Krzysztof:
No tak, nie możemy być zakładnikiem tej ani żadnej innej miary, bo wówczas faktycznie optymalizujemy nasze działania pod tą miarę, a to już rodzi różne wynaturzenia. Mówiłeś o tym, że taki zdrowy przedział, który uznajesz jako poprawny, to jest pomiędzy 80 a 120% właśnie w kontekście przewidywalności. Skąd te liczby i dlaczego według Ciebie to jest właśnie ten przedział, który powinien funkcjonować w zdrowych zespołach?

Jacek:
To jest to przedział, który dobrałem go na podstawie swoich doświadczeń, pracując z różnymi zespołami i bardzo często pomagając konkretnie zespołom w poprawie przewidywalności. Z mojej perspektywy przewidywalność powinna być pewnego rodzaju zakresem, czyli tak jak rozmawialiśmy, jeżeli ona jest bardzo niska, no to to jest niepokojące. Jeżeli jest bardzo wysoka, to to też jest niepokojące, bo to znaczy, że jesteśmy w stanie zrobić o wiele, wiele więcej niż planowaliśmy. Te 80 i 120 to z mojej perspektywy ma być wyrazem tego, że nie zapominajmy, że nadal działamy zwykle w złożonych środowiskach, gdzie ten cały codebase, na którym pracujemy, zwykle ma swoje lata.

Elastyczność w zespole

Jacek:
Działamy na konkurencyjnych rynkach, bardzo dużo rzeczy się zmienia, biznes też ma bardzo dużo pomysłów, na niektóre pomysły mądrze jest zareagować jak najszybciej, Z drugiej strony nie chcemy pracować w chaosie, to nie może być tak, że codziennie mamy inne zdanie, więc pewna taka doza plastyczności czy elastyczności zespołu z mojej perspektywy jest konieczna.

Jacek:
Gorzej tylko, jeżeli ona zaczyna, ta elastyczność stawać się takim pretekstem do tego, że właściwie codziennie mamy inny pomysł na to, czym będziemy się zajmować. No bo tutaj niestety koszt przełączania kontekstu, cała ta praca przerywana, niewykonana, ona zacznie być kosztem i może się okazać, że tak bardzo mieszamy w zespole, że sporo energii idzie na samo mieszanie, a niekoniecznie zespół jest w stanie efektywnie dostarczać te konkretne funkcje czy zmiany, na których nam zależy.

Krzysztof:
Myślę sobie, że aby zespół mógł się niejako wstrzelić właśnie w ten zakres, no to musi być też świadomy swojego planowania albo nie brać zbyt dużo na swoje barki. Ja tymczasem jestem przekonany, że z twojej obserwacji też wynika coś takiego, że jednak jest swego rodzaju tendencja w zespołach IT, żeby planować zbyt dużo. Masz jakieś obserwacje, jakieś wnioski, dlaczego tak się dzieje?

Jacek:
Ja myślę, że takim najbardziej istotnym wnioskiem czy obserwacją jest coś takiego, że trochę brakuje odwagi, żeby stanąć w prawdzie i powiedzieć sobie, coś robimy źle. No bo jak inaczej nazwać sytuację, kiedy planujemy pracę, realizujemy ją w bardzo niewielkim zakresie. I znowu planujemy, nie zmieniamy nic, I oczekujemy, że będą lepsze rezultaty. Nie ma takiej możliwości. Więc wydaje mi się, że przede wszystkim to jest taka odwaga trochę w połączeniu ze świadomością, żeby nazwać ten problem, który czasem mam wrażenie jest akceptowalny organizacyjnie. Na takiej zasadzie, że po prostu zawsze tak było, co niestety przypina często zespołom wytwórczym taką łatkę, że właśnie nie można na nich polegać, nie są przewidywalni i organizacja zaczyna żyć sobie po prostu z tym stanem, że tak jest i po prostu musimy to zaakceptować.

Jacek:
Moje doświadczenie natomiast pokazuje, że wcale to nie musi tak wyglądać. Jeżeli tylko rozpoczniemy taką uczciwą dyskusję o tym, z czego to wynika, jakie są powody, czego nam brakuje, no to okazuje się, że zwykle to jest jakaś taka mieszanka rzeczy do usprawnienia zarówno po tej stronie takiej czysto deweloperskiej, jak i po stronie biznesowej. Idealnie oczywiście, żeby biznes i IT w każdej organizacji pracował jak najbliżej,

Odwaga w zespole

Jacek:
jak najbardziej partnersko, ale wiemy, że nie zawsze tak jest. Są firmy, gdzie nadal ten mur pomiędzy działem i ludźmi biznesowymi, a działem i ludźmi IT występuje i prak tej przewidywalności nie powoduje, że ten mur się niweluje, tylko niestety każda kolejna niedowieziona obietnica dokłada kolejną cegiełkę do tego muru. Więc z mojej perspektywy odwaga, żeby zanegować ten stan i żeby zastanowić się, ok, to co możemy zrobić, żeby było inaczej, bo można zrobić sporo rzeczy i jakby rynek ma już doświadczenie w tym temacie, to nie jest jakaś taka wiedza.

Jacek:
Którą dopiero musimy odkryć, jak powiedzmy, nie wiem, agenci AI, którzy… Które, w sumie nie wiem jak dobrze odmienić, w sensie sztuczna inteligencja, która dopiero od niedawna jest na rynku i możemy nie wiedzieć jak sobie radzić z pewnymi problemami, bo dopiero to wyjdzie w praniu. Natomiast przewidywalność, tutaj akurat uważam, że ta wiedza jest sprawdzona i po prostu trzeba świadomie do niej sięgnąć.

Krzysztof:
Myślę sobie, że pewnego rodzaju doza asertywności też z pewnością może się przydać. Może się również przydać w takiej sytuacji, kiedy biznes pyta nas, na kiedy to będzie. Tutaj jest pytanie o to, czy tą wiedzę o przewidywalności możemy w jakiś sposób użyć, czy możemy w jakiś sposób wykorzystać dane, które zebraliśmy, aby w miarę szczerze i w miarę w takim, można powiedzieć, właśnie duchu opartym na danych biznesowi odpowiedzieć i będąc w tym w miarę właśnie i szczerym i precyzyjnym, bo właśnie jeśli tego nie będzie, no to kolejną cegiełkę do tego muru dokładamy.

Jacek:
Tak i ważną rzecz powiedziałeś, powiedziałeś o tej asertywności. Ona też jest, potrzebna, ona też jest konieczna, żeby powiedzieć, słuchajcie, to nie dojedzie, w sensie w tym zakresie to nie ma szans i ten głos też się musi pojawić, bo jeżeli się nie pojawi, no to wiadomo, druga strona, powie, no ale nic nie mówiliście i rozumiem to. Wracając do twojego pytania, co można zrobić opierając się na danych? No, co można Można zrobić najprościej, można wziąć pozostałą pracę do wykonania, spojrzeć sobie do Jiry czy do dowolnego innego miejsca, z którego korzystamy, policzyć ile tych elementów dla danego projektu czy dla danej inicjatywy pozostało do zrobienia i zestawić to z naszą historyczną przepustowością w jakiejś tam jednostce czasu. Czyli teraz uproszczę, powiedzmy, że na dwa tygodnie realizujemy 10 zadań, no to jeżeli mamy 50 zadań do zrobienia, no to możemy na oko policzyć, że to będzie z pięć tygodni. Oczywiście w jakimś pozytywnym scenariuszu, który zakłada, że będziemy realizować faktycznie 10 zadań na te dwa tygodnie, jak również, że nic nie będziemy dokładać.

Jacek:
Więc to jest jakby pierwsza rzecz, którą możemy zrobić. Druga rzecz, na którą bym spojrzał, to bym spojrzał na średni czas trwania cyklu, czyli na cycle time, czyli ten czas od momentu, kiedy rozpoczynamy pracę nad konkretnym zadaniem do momentu, kiedy ta praca jest ukończona. To też jest fajna miara, która może nam pokazać, gdzie tak naprawdę tracimy czas. Zwykle ten czas tracimy na oczekiwaniu.

Jacek:
Przykładowo praca jest wykonywana, następnie jest przetestowana i czeka sobie na code review, no to okazuje się, że jak rozbijemy sobie ten czas trwania na poszczególne etapy, no to implementacja to na przykład był jeden dzień, a trzy dni coś czeka na code review, bo na przykład tylko wybrane, najbardziej doświadczone osoby w organizacji takie przeglądy realizują. Więc to jest druga rzecz, na którą bym spojrzał. No i myślę, że trzecia, taka najbardziej zaawansowana, można by się było pokusić jakąś symulację na bazie danych historycznych i otrzymać jakieś tam warianty przyszłości z procentem szans na dowiezienie jakiegoś tam konkretnego zakresu. Z takich obliczeń może nam wyjść, że na przykład jest 50% szans na to, że dowieziemy na koniec marca, 85% szans na to, że dowieziemy na koniec kwietnia. I z takimi informacjami też można już coś zrobić, podyskutować tak naprawdę o ryzyku, no bo na koniec dnia cała ta dyskusja właśnie się o to rozchodzi, czyli z jakim prawdopodobieństwem jesteśmy w stanie dostarczyć pewne elementy

Praktyki poprawy przewidywalności

Jacek:
i jakie jest ryzyko, że to się nam nie uda.

Krzysztof:
Myślę sobie, że poprawa przewidywalności to jest pewnie swego rodzaju proces, który trwa, to nie jest tak, że my nagle z tych 30% nieco patologicznych przechodzimy na bliskie stół, to wymaga pewnie zmian, to wymaga czasu, więc chciałbym Cię zapytać o jakieś trzy konkretne praktyki, które mógłbyś zasugerować zespołowi, który właśnie chciałby nad tą przewidywalnością popracować, coś usprawnić, coś ulepszyć.

Jacek:
No to ja myślę tak, że przede wszystkim zanim wymienię te trzy takie, które myślę, że będą najbardziej takie zwiększające szanse, że poprawimy nasze rezultaty, no to trzeba zacząć mierzyć, bo tak jak już gdzieś to padło w naszej rozmowie wcześniej, bez danych to jest rozmowa o odczuciach, wiadomo, każdy ma jakieś tam swoje odczucia. Ja bardzo często robię takie ćwiczenie, jeżeli wchodzę do jakiegoś zespołu, żeby pomóc im z przewidywalnością, no to jedną z pierwszych aktywności, którą robię, to są spotkania jeden na jeden z każdą osobą z zespołu. Celem tego spotkania jest przede wszystkim poznać tą konkretną osobę, trochę zrozumieć perspektywę tej osoby na konkretny projekt czy produkt, który jest rozwijany. Jeżeli pracujemy nad przewidywalnością, to ja zadaję pytanie, jak oceniasz przewidywalność zespołu? Nie proszę o żadną konkretną cyfrę, o żadną miarę, tylko właśnie o takie luźne odczucie.

Jacek:
I to, co zaobserwowałem, to to, że jak zapytamy zespół, to dostajemy tak naprawdę całą paletę różnych odpowiedzi, od myślę, że jest nieźle, do drugiej skrajności, że fatalnie nic nie dowozimy. No i oczywiście to jest bardzo ogólne i lubię ten moment, kiedy jednak wyciągamy sobie tą konkretną cyferkę, która nam mówi, że to jest na przykład 35%. No i wtedy się otwierają oczy w zespole na zasadzie jak to. albo inni mówią, a nie mówiłem, właśnie tak jest. Więc miara, w sensie te dane są absolutną podstawą i co bym zrobił? Przede wszystkim zacząłbym dzielić pracę na mniejsze kawałki, to jest absolutna podstawa. Bardzo trudno jest dowozić elementy, które są za duże, które przechodzą z jednej iteracji na drugą, które tak naprawdę nie wiemy, ile jeszcze potrwają, bo po prostu są zbyt potężne, więc dzielenie na małe kawałki druga rzecz myślenie o pracy na zasadzie zacznij kończyć, przestań zaczynać, ilość rozgrzebanej pracy w toku w zespołach jest zwykle wyższa niż powinna być czyli gdyby spojrzeć w danym momencie na pracę, która się dzieje w zespole najczęściej okazuje się, że pojedyncza osoba robi więcej niż jedną rzecz i to zwykle nie dwie rzeczy, tylko powiedzmy z trzy Tak, tak, tak.

Jacek:
No i przełączanie się między tymi kontekstami, niekończenie pracy, rozpoczynanie kolejnej powoduje, że nam ta wartość tej pracy w toku rośnie, co powoduje, że znowu mamy rozgrzebane tematy, wszyscy mają poczucie, że się napracowali, że wykonują tytaniczną pracę, ale tych efektów w postaci zakończonych jakichś konkretnych funkcji, czy funkcjonalności, czy zmian w naszym produkcie nie ma. Więc to jest myślę taka druga bardzo istotna rzecz. I trzecią, pytasz o trzy, to myślę, że wskazałbym regularne usprawnianie się, ale takie bazujące na miarach.

Jacek:
Czyli żeby sobie w regularnych odcinkach czasu, wspominałeś o Scrumie, są zespoły, które realizują retrospektywę, czyli spotkanie, podczas którego rozmawiają o tym, jak usprawnić proces pracy, no to elementem takiego spotkania może być przegląd miar, które są dla nas istotne, w tym przypadku to będzie też przewidywalność, no i zastanawiać się, co się wydarzyło, że nam ta przewidywalność skoczyła, dlaczego spadła, dlaczego poszła w górę. I z moich doświadczeń w takich okresach powiedzmy między dwa a trzy miesiące zespoły są w stanie wyprowadzić się na prostą jeśli chodzi o przewidywalność,

Współpraca z biznesem

Jacek:
jeżeli oczywiście jest zbudowana w organizacji narracja pod tytułem zależy nam na przewidywalności. Wobec tej narracji po co nam przewidywalność? No to zespół najczęściej odbiera to, że to jest jakaś kolejna rzecz, którą wymyślił management, no i zawracają nam głowę, a my chcemy przecież kodować i o co chodzi z tą przewidywalnością? Będzie jak będzie.

Jacek:
Ale w momencie, jak osoby z biznesu wytłumaczą, dlaczego to jest istotne, jaki jest impakt finansowy na to, że brakuje nam tej przewidywalności, tej takiej pewności, no to wtedy… Postawa zwykle się zmienia na zasadzie, aha, dobra, zaczynamy rozumieć, że nie działamy w izolacji, no i de facto też, że ta współpraca między zespołami wytwórczymi a biznesem, no że tak naprawdę na koniec dnia jedziemy na jednym wózku i im będziemy bliżej, im będziemy lepiej współpracować, na tym te wyniki po prostu będą lepsze.

Krzysztof:
Przedstawiamy podnoszenie, polepszenie przewidywalności jako coś pozytywnego, jako coś do czego pewnie wiele zespołów powinno dążyć, ale z drugiej strony zastanawiam się, czy to trochę nie idzie w kontrze też z taką dążnością do eksperymentowania, do podejmowania się rzeczy, które jednak nie są przewidywalne, które nie wiemy, czy po pierwsze się udadzą pod względem takim biznesowym i technicznym, ale również nie wiemy, czy wypełnią nam ten czas, który gdzieś tam sobie przeznaczyliśmy, zaplanowaliśmy właśnie na te zadania. Więc jak te dwie potrzeby optymalizacji przewidywalności z jednej strony, a z drugiej strony podejmowania się prób zrealizowania czegoś, co nie jest przewidywalne, idą ze sobą? Czy one się uzupełniają? Może w jakiś sposób są względem siebie przeciwstawne? Jak ty to widzisz?

Jacek:
Faktycznie jest tak, że są zespoły, których natura pracy może być taka bardziej, eksperymentalna, takie trochę R&D, czy na przykład zespoły, które pracują z uczeniem maszynowym, tworzą modele, trochę trudniej może być im zaplanować przewidywalne rezultaty, co nie zmienia faktu, że nadal dobre określenie też pewnych ram tych eksperymentów pomaga, bo to co często obserwuję to to, że te eksperymenty są nieosadzone w czasie.

Jacek:
I gdy zapytać osoby, które wykonują jakąś taką pracę bardziej, ja to nazywam odkrywkową, czy tak to nazywa się eksperymentalną, no to one mówią, nie wiemy, robimy, będzie jak będzie i tak dalej. Jednak jestem fanem zakładania sobie pewnych ograniczeń czasowych, bo ograniczenia czasowe powodują, że musimy płynąć do brzegu. Sam wiele lat byłem deweloperem, wiem jak bardzo łatwo jest popłynąć w kodzie, dodać sobie coś tam jeszcze, to jeszcze zrefaktoryzować, to zrobić ładniej, możliwości polerowania są nieograniczone, więc na pewno będą zespoły, którym będzie trudniej osiągnąć przewidywalność, ale taki przeciętny zespół, który spotykam, zwykle jest w stanie osiągnąć akceptowalną przewidywalność pracy bez zabijania tego ducha eksperymentowania, bo na przykład to eksperymentowanie jest tylko małą cząstką tego, czym się zajmują w ramach na przykład dwóch tygodni, więc nawet jeśli w tym drobnym obszarze, gdzie trochę bardziej nie wiedzą do końca i jakby to operują w mgle, no to tam jakieś drobne niepowodzenia powodują, że ok.

Jacek:
Tam powiedzmy przewidywalność jest trudniejsza do osiągnięcia, ale cała ta reszta, którą się zajmujemy, jak najbardziej. Stąd ten zakres, o którym mówiłem, te 80-120, on zakłada, że właśnie na przykład będziemy dotykać tematów, które z natury rzeczy będą trudne do wsadzenia w pewne ramy i to jest ok.

Jacek:
Akceptujemy ten stan rzeczy, no bo to jest software development, domena jest złożona i po prostu rządzi się swoimi prawami.

Krzysztof:
Czy w związku z tym istnieją jakieś zespoły, dla których mierzenie przewidywalności nie ma kompletnie sensu, gdzie nie zalecałbyś tego typu podejścia, gdzie właśnie trochę działanie z nurtem rzeki jest jedynym sensownym i tam po prostu przewidywalność nic nie wnosi?

Jacek:
W szczególności taka przewidywalność na zasadzie, co sobie planowaliśmy, a co zrobiliśmy, może mieć małe sensy w zespołach takich, które działają, tak trochę serwis deskowo, czyli przychodzę do pracy i będą spływać zadania jakieś. Ktoś będzie miał problem z bazą danych, ktoś z firewallem, ktoś przyjdzie z laptopem, w zależności czym się zespół zajmuje. Jeżeli ta natura naszej pracy jest, uniemożliwia planowanie, no to trudno mówić o przewidywalności. W sensie nie wiem, kto dzisiaj do mnie przyjdzie z problemem, ale wiem, że te problemy będę rozwiązywał, więc jako tak o planowania nie ma, ale nadal takie zespoły mogą sobie mierzyć inne rzeczy, na przykład cycle time, no i być w stanie prognozować, kiedy tego typu zgłoszenie może zostać zrealizowane na bazie informacji historycznych.

Krzysztof:
Jeśli tą przewidywaność zbyt mocno postawimy sobie na pietestale, jeśli wszystko będziemy pod to optymalizować i dążyć do jakiejś założonej wartości, no to możemy się spotkać właśnie z problemem bardzo kreatywnych ludzi technicznych, którzy będą jednak wszystko chcieli tak zmienić i tak dostosować, aby tą wartość osiągnąć. I jednym z takich działań może być zaciąganie długu technicznego, technologicznego po to tylko, żeby coś dowieść w zakładanym czasie i w ten sposób tą miarę w jakiś sposób wypełnić, potwierdzić, zrealizować. Czy znasz jakieś metody, jakieś podejście, aby pogodzić tutaj te mimo wszystko dwie strony, czyli przewidywalne dowożenie z jakościowym dowożeniem?

Jacek:
Ja myślę, że żeby uniknąć tego ryzyka, to musimy zacząć zarządzać zakresem, a nie jakością, czyli zaakceptować, że jeżeli mamy sztywną datę, na którą z jakichś tam powodów musimy dostarczyć jakieś rozwiązanie i wiemy, że mamy zespół, jego skład jest znany, stały, nie planujemy dorzucać ludzi, wiemy też historycznie, że dorzucanie na późnym etapie jest złym pomysłem, no to tak naprawdę jedynym sensownym bokiem trójkąta, którym możemy sobie operować jest zakres, w szczególności niejakość i to jest trudne moim zdaniem do zrozumienia, no bo zwykle chcemy mieć wszystko, natomiast możliwości zwykle są takie, że nie będziemy mieć wszystkiego, Natomiast pomaga takie myślenie niebinarne o tych elementach zakresu, czyli bardzo często jak rozmawiam z osobami biznesowymi, no to jest takie myślenie, albo robimy tego dużego feature’a, albo go nie robimy, a ja bym raczej zachęcił do takiej rozmowy.

Jacek:
Która część tej dużej zmiany jest taka najbardziej krytyczna, jest istotna i może zróbmy na razie tylko ten kawałek, nie róbmy tej zmiany w sposób taki piękny, nie polerujmy jej, nie obsługujmy wszystkich możliwych przypadków brzegowych, może zacznijmy od jakiejś takiej ścieżki najbardziej prawdopodobnej, zaakceptujmy, że do tego terminu po prostu nie będziemy w stanie wszystkiego zrobić. Co powoduje, że zaczynamy sobie kręcić takimi pokrętłami trochę, czyli może trochę więcej pracy będzie do zrobienia ręcznie, może nie obsłużymy wszystkich przypadków, które byśmy chcieli, może wizualnie to nie będzie tak wypieszczone, ale możemy zacząć sobie sterować i rozpoczynać rozmowę o tym, co tak naprawdę jest istotne. Bo ja bardzo lubię jedną z myśli, które stały za manifestem zwinnego wytwarzania oprogramowania, czyli maksymalizacja ilości pracy niewykonanej jest kluczowa.

Jacek:
Czyli zachęca do myślenia nie o tym, jak naładować najwięcej, tylko które z tych rzeczy, które nam się wydaje, że są istotne, tak naprawdę nie są aż tak istotne, albo nie są aż tak istotne na tym etapie, co spowoduje, że zaczniemy realizować mniej, ale to będą mądrzejsze rzeczy, przez co tworzy nam się przestrzeń na robienie kolejnych innych najmądrzejszych rzeczy. Więc zarządzanie zakresem, ale takie bym powiedział mądre zarządzanie zakresem to jest odpowiedź na to pytanie.

Krzysztof:
Tak, myślę sobie, że czasem jako IT zapominamy o tym, że naszą rolą nie jest tylko dowożenie maksymalnej ilości linii kodu, ale mimo wszystko współpraca z biznesem i dowożenie właśnie tej wartości użytkowej. I często właśnie obcięcie tego zakresu, przedefiniowanie w jakaś tutaj zmiana może być najlepszym rozwiązaniem, a nie właśnie tworzenie nowego feature’a, nowego rozwiązania, które pozwoli nam rozszerzyć co prawda ofertę, natomiast to niekoniecznie musi być to, do czego jako biznes dążymy.

Podsumowanie rozmowy

Krzysztof:
Dobrze, w tym naszym dzisiejszym spotkaniu było o przewidywalności, o tym czym ona jest, w jaki sposób działa właśnie w kontekście zespołów IT, ale też o bardzo takim zdroworozsądkowym podejściu do jej mierzenia, optymalizacji, no i takiej ciekawej myślę perspektywie na to, że to nie zawsze ilość dowożonych feature’ów, czy też nawet szybkość ich dowożenia, ale właśnie przewidywalność może być tą miarą, która zapewni nam sukces szeroko rozumiany, nie tylko techniczny, ale również biznesowy. Jacku, bardzo Ci dziękuję za tą rozmowę i wprowadzenie właśnie w ten świat.

Jacek:
Dziękuję Krzysztof, dzięki za rozmowę i za Waszą uwagę.

Krzysztof:
Powiedz proszę na końcu, gdzie Cię możemy znaleźć w internecie?

Jacek:
Myślę, że trzy miejsca na mojej stronie domowej jacekwieczorek.pl, na stronie mojej firmy konsultingowej, czyli 202%.pl oraz na stronie podcastu, który wprowadzę z Jakubem Szczepanikiem, czyli porządneagile.pl.

Krzysztof:
Oczywiście wszystkie te linki będą w datce do odcinka. Jeszcze raz Ci dziękuję, miłego dnia i cześć.

Jacek:
Dzięki, wzajemnie, cześć.

Krzysztof:
To już wszystko na dzisiaj. Jeśli chcesz więcej takich rozmów, Archiwum czeka. Tam też dzieją się ciekawe rzeczy. Masz pytania, przemyślenia? Możesz się ze mną skontaktować na social mediach lub mailowo na krzysztof@porozmawiajmyoit.pl Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy.it o przewidywalności dowożenia przez zespoły IT. Dzięki za wspólnie spędzony czas. Do usłyszenia w kolejnym odcinku.