Porozmawiajmy o IT

O przewidywalności dowożenia przez zespoły IT. Gość: Jacek Wieczorek - POIT 305

• Krzysztof Kempiński • Season 1 • Episode 305

Share episode

Witam w trzysta piątym podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest przewidywalność dowożenia przez zespoły IT.

Dziś moimi gościem jest Jacek Wieczorek – konsultant z ponad 20-letnim 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 Procent.


W tym odcinku o przewidywalności dowożenia w IT rozmawiamy w następujących kontekstach:

  • czym w praktyce jest przewidywalność dowożenia w zespołach IT
  • dlaczego z perspektywy biznesu przewidywalność bywa ważniejsza niż sama szybkość dostarczania
  • jakie realne koszty dla organizacji generuje brak przewidywalności
  • jak przewidywalność wpływa na zaufanie między biznesem a IT
  • czy zespół, który regularnie dowozi niewielką część planu, nadal można uznać za przewidywalny
  • jak sensownie liczyć przewidywalność w ramach iteracji lub sprintu<
  • jaki wpływ na przewidywalność mają zmiany zakresu w trakcie trwania iteracji
  • jakimi narzędziami i metrykami można mierzyć przewidywalność zespołu
  • czy wynik bliski 100% to ideał, czy raczej sygnał ostrzegawczy
  • skąd bierze się koncepcja „zdrowej przewidywalności” w przedziale 80–120%
  • dlaczego zespoły mają tendencję do chronicznego przeplanowywania
  • jak poprawiać przewidywalność, nie zabijając eksperymentowania i nie generując długu technologicznego


Subskrypcja podcastu:


Linki:


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

https://porozmawiajmyoit.pl/305

SPEAKER_00:

To jest 305 odcinek Porozmawiajmy IT. Dziś rozmawiamy o przewidywalności dowożenia przez zespoł IT. Dotatkę, linki i transkrypcje znajdziesz na porozmawiajmy.pl ł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 Kępiński, tworzę ten podcast, napisałem też książkę markę ostopista branż IT. Jeśli lubisz moje rozmowy, będzie mi bardzo miło, jeśli udostępnisz ten odcinek dalej albo zostawisz ocenę 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-letnim doświadczeniem w branży T. Pomaga firmom technologicznym uporządkować pracę zespołów, by efektywnie i przewidywalnie dowoziły wyniki biznesowe. Autor książki Labirynty z Krama, współtwórca podcastu Porządny Agile oraz współzałożyciel firmy konsultingowej 202%. Moim waszym gościem jest Jacek Baczorek. Cześć Jacku, bardzo miło mi gościcie w podcaście.

SPEAKER_01:

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

SPEAKER_00:

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ć pielsi, musimy jak najwięcej tej wartości dostarczać. Tymczasem, gdyby się przyjrzeć temu procesowi tak bardziej dogłębniej i precyzyjnie, to pewnie okaże się, że oprócz szybkości dowożenia jest coś, 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 Jackie. Dobrze Jacku, to może takim pytaniem wprowadzającym z mojej strony będzie to, czy słuchasz podcastów i co ciekawego na Twoje liście podcastowej się znajduje.

SPEAKER_01:

Tak, podcastów słucham myślę już dosyć dawno, od dawna, zaczynałem od Marka Jękowskiego i od Michała Safrańskiego. Takie dwa bym powiedział, no może nie do końca związane z tym, co się zajmuje podcastem, ale bardzo interesujące. Natomiast tak jak dzisiaj sobie o tym myślę, czego najwięcej słucham, to jest to podcast biegania.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.

SPEAKER_00:

No jasne, głowa musi też w końcu odpocząć, to jest niezwykle niezwykle istotne. Właśnie dużo będziemy dzisiaj mówić o przewidywalności, więc na początku warto byłoby zdefiniować się, czym ona w ogóle jest, oczywiście w kontekście pracy zespołu w IT.

SPEAKER_01:

W mojej definicji przewidywalność mówi nam, w jakim stopniu zespół dowodzi 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.

SPEAKER_00:

Właśnie w skramie, zresztą nie tylko w skramie, w różnych innych podejściach wywodzących się z Agile, przyzwyczailiśmy się, przynajmniej jak osoby takie techniczne, to i może bardziej mówię ze swojego punktu widzenia, do patrzenia albo do skupiania się właśnie na tym odcinku dwutygodniowym, miesięcznym, tak, 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?

SPEAKER_01:

Myślę, że taka pierwsza naturalna myśl 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óra oczywiście też ma sens, z perspektywy biznesowej jest istotnym czynnikiem.

SPEAKER_00:

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?

SPEAKER_01:

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 chyw wprowadzić, na przykład prowadzimy jakiś biznes e-commerceowy, 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 koście wizerunkowym. Czyli przykładowo, teraz wiele firm, które dostarczają oprogramowanie finansowe, musi zadbać o to, żeby poprawnie zaimplementować funkcjonalność związaną z KSFem. No i teraz, jeżeli nasz produkt, który rozwijamy, nie będzie gotowy na czas, nie będzie kompatybilny z KSE-em i z wymogami prawnymi, no to możemy mieć problem z pozyskiwaniem kolejnych klientów, 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ąć.

SPEAKER_00:

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 oczywiście mogą być się 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, 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ół dowodzi w sposób przewidywalny, powoduje, że biznes ma pokłada jakieś większe zaufanie właśnie w tym zespole, że ta współpraca lepiej wygląda?

SPEAKER_01:

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, okej, 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, tym nasza góra tego równania ten licznik będzie nam rósł.

SPEAKER_00:

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 postawien 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, tak 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.

SPEAKER_01:

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 dowodzi, 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 pracy na zarządzie. Więc w mojej definicji taka tak ujęta przewidywalność, to nie jest przewidywalność, o której ja myślę, 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, to 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ć?

SPEAKER_00:

Żeby być świadomym tego problemu, trzeba tę przewidywalność w jakiś sposób mierzyć. I zastanawiam się, czy tutaj odpowiednią perspektywą jest pojedyncza iteracja, czy tam 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ć.

SPEAKER_01:

No, 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. 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 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 domierzenia przepustowości, czyli ile rzeczy robimy w konkretnym okresie, a raczej staram się odchodzić od też popularnego podejścia, którym jest liczenie Story Pointów. Wtedy też mogę sobie zsumować Story Pointy, ile zostało zrealizowane 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ę.

SPEAKER_00:

Tak, taki trend tutaj nawet mówiąc też widzę coraz szerzej. Zresztą, gdzieś tam sami można powiedzieć, ojcowie założyciele, agile, czy też skramat, również się do tego gdzieś tam skłaniają, żeby właśnie takie podejście zastosować. I myślę, że bardzo dobrze obszarze jedną z wartości tego podejścia jest to, żeby się uczy, czegoś 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 skąp zadania, pewnego milestone, Epika, był nam znany, bo biznes się zmienia, mnóstwo różnych czynników oczywiście na to wpływa temat pewnie też na inną rozmowę. Natomiast tak się dzieje, prawda? Więc teraz, kiedy stawimy 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?

SPEAKER_01:

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ę. 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ć 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ąć.

SPEAKER_00:

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 do nas 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?

SPEAKER_01:

No 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, ż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ł. A z drugiej strony poniżej pewnej wartości to będzie oznaczało, że mamy jakiś problem, czyli jeżeli dla mnie to jest tak 80%, 80-120 to jest powiedzmy taki, zdrowy zakres przewidywalności, ale spotykam zespoły, które mają przewidywalność na poziomie 30%, 40%. No i z mojej perspektywy, no takiej patrząc, jakby z perspektywy osoby, która była w roli menadżerskiej i musiałem brać jakiś tam ciężar odpowiedzialności za to, co zespoły robią bądź nie, to taka przewidywalność dla mnie jest nieakceptowalna.

SPEAKER_00:

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

SPEAKER_01:

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%, to ona będzie i to nie dotyczy tylko przewidywalności, tylko właściwie każdą miarę, którą sobie nie wymyślimy, 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, no albo jakieś tam rezultaty są osiągane jakimś kosztem, być może rośnie duch technologiczny, być może jakościowo pewne rzeczy nie są tak dobrze przetestowane, jakby 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 gdy pozostaną po prostu tym wewnętrznym barometrem zespołu, może być problematyczne. Ale znam firmy, gdzie miały. 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ą.

SPEAKER_00:

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

SPEAKER_01:

Najwięcej zespołów, które ja spotykam w swojej praktyce, korzystają z giry, jest to narzędzie, które jeśli jest dobrze skonfigurowane, no 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 ziry mamy na dobrym poziomie czyli mam na myśli to, że ta faktycznie wykonywana praca jest odzwierciedlona w dzirze, i jeżeli coś kończymy, to faktycznie odklikujemy to w narzędziu, czyli można powiedzieć, że jest gira wtedy takim bezpiecznym odbiciem tej faktycznie wykonanej pracy, no to wtedy gira jest naprawdę jakby na start bardzo prostym, ale wystarczającym narzędziem, które z pudełka daje nam już możliwość podejrzenia 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, bo możemy sobie do niego wrzucać właściwie dowolne informacje, obrabiać, robić sobie do tego wykresy, produkować linię trendu, no i tak naprawdę Excel ma bardzo niewiele ograniczeń i w kwestii liczenia przewidywalności, szczególnie śledzenia miar zespołu, nadal jest bardzo dobrym i dosyć też prostym w użyciu rozwiązaniem.

SPEAKER_00:

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 taki wewnętrzny barometr, to jest raczej oznaka czegoś pozytywnego, jak ty podchodzisz właśnie do wyniku 100% w tych zawodach.

SPEAKER_01:

No wiesz, ja 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ły w miarę stały, 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 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ąć. I ktoś inny mówi, no tak, ale co jak nie dowiedziemy, spadnie nam przewidywalność. I się rozpoczynała dyskusja, któryj efektem był wniosek 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 jakby z wykształcenia 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?

SPEAKER_00:

No tak, nie możemy być zakładnikiem tej, ani żadnej innej miary, bo wówczas faktycznie optymalizujemy nasze działania pod tą miarę, na to już chodzi różne naturzenia. 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?

SPEAKER_01:

To jest to przedział, który dobrałem go na podstawie swoich doświadczeń pracując z różnymi zespołami 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. To 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. 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. 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.

SPEAKER_00:

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. Tymczasem jestem przekonany, że z Twojej obserwacji też wynika coś takiego, że jednak jest swego rodzaju tendencja w zespoło HT, żeby planować zbyt dużo, masz jakieś obserwacje, jakieś wnioski, dlaczego tak się dzieje?

SPEAKER_01:

Ja myślę, że takim najbardziej istotnym wnioskiem czy obserwacjom jest coś takiego, że trochę brakuje odwagi, żeby stanąć wprawdzie i powiedzieć sobie, coś robimy źle. No bo jak inaczej nazwać sytuacja, kiedy planujemy pracę, realizujemy ją w bardzo niewielkim zakresie. 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, no i po prostu musimy to zaakceptować. 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, 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, 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 brak tej przewidywalności nie powoduje, że ten mur się niweluje, no tylko niestety każde kolejne, każda kolejna niedowiedziona obietnica dokłada kolejną cegiełkę do tego muru. Z mojej perspektywy odwaga, żeby zanegować ten stan i żeby zastanowić się, 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, którą dopiero musimy odkryć. Jak powiedzmy, nie wiem, agenci AI, którzy, które, w sumie nie wiem, jak dobrze odmienić, jest 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ść, no tutaj akurat uważam, że ta wiedza jest sprawdzona i po prostu trzeba świadomie do niej sięgnąć.

SPEAKER_00:

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. No i 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 tutaj biznesowi odpowiedzieć i będąc w tym w miarę właśnie szczerym i precyzyjnym, bo właśnie jeśli tego nie będzie, to kolejną cegiełkę do tego muru dokładamy.

SPEAKER_01:

Tak, i ważną rzecz powiedziałeś, powiedziałeś o tej asertywności, ona też jest potrzebna, on też jest konieczna, żeby powiedzieć, słuchajcie, to nie dojedzie. W sensie w tym zakresie to nie ma szans i też 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. Co można zrobić najprościej? Można wziąć pozostałą pracę do wykonania, spojrzeć sobie do Jerry, 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 5 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ć. To jest jakby pierwsza rzecz, którą możemy zrobić. Druga rzecz, na którą bym spojrzał, to będę 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, 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 i z takich obliczeń może nam wyjść, że na przykład jest 50% szans na to, że dowiedziemy na koniec marca, 85% szans na to, że dowiedziemy na koniec kwietnia. I z takimi informacjami też można już coś zrobić, podyskutować tak naprawdę o ryzyku, 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 i jakie jest ryzyko, że to się nam nie uda.

SPEAKER_00:

Myślę sobie, że poprawa przewidywalności to jest pewnie swego rodzaju proces, który trwa, tak 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ć.

SPEAKER_01:

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? I nie proszę o żadną konkretną cyfrę, o żadną miarę, tylko właśnie o takie luźne odczucie. 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 tego do drugiej skrajności, że fatalnie nic nie dowodzimy. 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, nie wiem, 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 miarę 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 zacznie 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. 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. Czyli żeby sobie w regularnych odcinkach czasu, wspominałeś o skramie są zespoły, które realizują retrospektywę, czyli spotkanie podczas którego rozmawiają o tym, jak usprawnić proces pracy, to elementem takiego spotkania może być przegląd miar, które są dla nas istotne, w tym przypadku to będzie też przewidywalność, 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ść. Jeżeli oczywiście jest zbudowana w organizacji narracja pod tytułem zależy nam na przewidywalności. Bo bez tej narracji, po co nam przewidywalność, to zespół najczęściej odbiera to, że to jest jakaś kolejna rzecz, którą wymyślił manedżmę, i zawracają nam głowę, a my chcemy przecież kodować. I o co chodzi z tą przewidywalnością? Będzie jak będzie. 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, że ta współpraca między zespołami wytwórczymi a biznesem, że tak naprawdę na koniec dnia jedziemy na jednym wózku i im będziemy bliżej i im będziemy lepiej współpracować, tym te wyniki po prostu będą lepsze.

SPEAKER_00:

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 gdyby 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, no nie wiem, są względem siebie przeciwstawne. Jak ty to widzisz?

SPEAKER_01:

Faktycznie jest tak, że są zespoły, których natura pracy może być taka bardziej eksperymentalna, takie trochę RD, 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, I gdy zapytać osoby, które wykonują jakąś taką pracę bardziej, ja to nazywam, odkrywkową, czy tak nazywać eksperymentalną, to one mówią, nie wiemy, robimy, będzie, jak będzie, i tak dalej. Ja 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 są, 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, to tam jakieś drobne niepowodzenia powodują, że okej, tam powiedzmy przewidywalność, że jest trudniejsze 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. Jakby akceptujemy ten stan rzeczy, bo to jest software development, domena jest złożona, no i po prostu rządzi się swoimi prawami.

SPEAKER_00:

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 tak z, można powiedzieć, z nurtem rzeki jest jedynym sensownym i tam po prostu przewidywalność nic nie wnosi.

SPEAKER_01:

W szczególności taka przewidywalność na zasadzie, co sobie planowaliśmy, co zrobiliśmy, może mieć mały sens 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 Fajerwallem, ktoś przyjdzie, nie wiem, z laptopem, w zależności, czym się zespół zajmuje. Jeżeli ta natura naszej pracy 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ą planowania nie ma, ale nadal takie zespoły mogą sobie mierzyć inne rzeczy, na przykład cykl time, no i być w stanie prognozować, kiedy tego typu zgłoszenie może zostać zrealizowane na bazie informacji historycznych.

SPEAKER_00:

Jeśli tą przewidywaność zbyt mocno postawimy sobie na piestale, 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 zmieć 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.

SPEAKER_01:

Ja myślę, że żeby uniknąć tego ryzyka, to musimy zacząć zarządza zakresem, a nie jakością. Czyli zaakceptować, jeżeli mamy sztywną datę, na którą z jakichś tam powodów musimy dostarczyć jakieś rozwiązanie i wiemy, że mamy zespół, który 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, 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 featera, albo go nie robimy. A ja bym raczej zachęcił do takiej rozmowy, 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ę takną z myśli, które stały za manifestem zwinnego wytwarzania oprogramowania, czyli maksymalizacja ilości pracy niewykonanej jest kluczowa. 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 otworzy nam się przestrzeń na robienie kolejnych innych, najmądrzejszych rzeczy. Więc zarządzanie zakresem, ale tak ja bym powiedział, mądre zarządzanie z zakresem, to jest odpowiedź na to pytanie.

SPEAKER_00:

Tak, myślę sobie, że czasem jako IT zapominamy o tym, że naszą rolą nie jest tylko dowozenie maksymalnej ilości linii kodu, ale mimo wszystko współpraca z biznesem i doważenie właśnie tej wartości użytkowej 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 ofatera, nowego rozwiązania, które pozwoli nam rozszerzyć co prawda ofertę, natomiast niekoniecznie musi być to, do czego jako biznes dążymy. 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, 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.

SPEAKER_01:

Dziękuję, Krzysztof, dzięki za rozmowę i za waszą uwagę.

SPEAKER_00:

Powiedz proszę na końcu, gdzie cię możemy znaleźć w internecie.

SPEAKER_01:

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 Jakubą Szczepanikiem, czyli porządnyadaj.pl.

SPEAKER_00:

Oczywiście wszystkie te linki będą w tawce do odcinka. Jeszcze raz Ci dziękuję, miłego dnia. Cześć.

SPEAKER_01:

Dzięki wzajem, cze.

SPEAKER_00:

To już wszystko na dzisiaj. Jeśli chcesz więcej takich rozmów, archiwum czeka. Tam też działam się ciekawe rzeczy. Masz pytania, przemyślenia? Możesz się ze mną skontaktować na social mediach lub mailowo na krzyżofmałpa.prozmawiajmat.pl. Nazywam się Krzysztof Kępiński, a to był odcinek podcastu porozmawiajmy IT o przewidywalności dołożenia przez zespoł IT. Dzięki za wspólnie spędzony czas. Do usłyszenia w kolejnym odcinku. Cześć.

Head Shot

Krzysztof Kempiński

Host