“Musimy się lepiej komunikować” – czy zdarza się, że słyszysz to w swoich zespołach? Niby proste hasło, ale często nikt nie wie, co to właściwie znaczy i jak to zrobić.Rozłożyliśmy efektywność komunikacji na czynniki pierwsze. Zdefiniowaliśmy ją i pokazaliśmy praktyki  komunikacji nie tylko w zespołach projektowych, ale też managerskich. Skorzystaj z naszych sprawdzonych rekomendacji, które możesz wdrożyć od razu by komunikacja stała się efektywna.

Zapraszamy Cię do obejrzenia nagrania podcastu

Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu Porządny Agile.

Jacek: Czy masz wrażenie, że w twoim zespole nieustannie powtarza się frazy „Musimy się lepiej komunikować”, ale nikt nie wie co to właściwie znaczy i jak to zrobić?

Kuba: W tym odcinku rozłożymy na czynniki pierwsze zagadnienie efektywności komunikacji. Dowiesz się jak ją precyzyjnie zdefiniować i co najważniejsze przedstawimy konkretne praktyki i rozwiązania, które możesz wdrożyć natychmiast od komunikacji bez pośredników, przez współdziałanie i bliskość, aż po wzmacnianie wizualizacją.

Kuba: Przeprowadziliśmy w grudniu warsztaty dla ponad 100-osobowej grupy. Samo w sobie było to dużym wyzwaniem, żeby taką grupę ogarnąć czy tak logistycznie czy facylitacyjnie, ale ja nie o tym. Natomiast fajne było to, że przedmiotem ćwiczenia była kwestia komunikacji w dużej skali i efektywności tej komunikacji. I ćwiczenie wyszło bardzo sprawnie, sami z Jackiem jesteśmy bardzo zadowoleni. Dostaliśmy też dobre informacje zwrotne ze strony zarówno uczestników, jak i organizatorów. Natomiast refleksje powarsztatowe i też taki materiał merytoryczny, który stał pod tymi warsztatami jest wkładem do dzisiejszego nagrania. 

Jacek: I o komunikacji można wiele mówić i funkcjonuje wręcz taki żart, że co można usprawnić. Zawsze możemy się po prostu lepiej komunikować. Natomiast co to właściwie znaczy lepsza komunikacja? Zwykle w takiej praktyce, kiedy jest podejmowana decyzja, że powinniśmy się lepiej komunikować, to nikt za bardzo nie wie, ale wszyscy są uspokojeni. Natomiast ta koncepcja usprawniania komunikacji jest kluczowa i chcielibyśmy dzisiaj porozmawiać o tym w tym odcinku, co to konkretnie znaczy, że komunikujemy się lepiej i komunikujemy się efektywniej.

Kuba: I nasze porady będą, myślę, bardzo uniwersalne, zwłaszcza na poziomie spisu treści czy nagłówków naszych porad. Natomiast tutaj od razu zadeklaruję tobie, Słuchaczu lub Słuchaczko, że będziemy starali się mówić o komunikacji nie tylko na poziomie komunikacji zespołu projektowego, czy zadaniowego, czy produktowego, ale również o komunikacji na poziomie organizacji, na poziomie zespołu managerskiego, czy zespołu liderów, którzy gdzieś zarządzają organizacją. Więc tutaj zastrzegam to na początku, bo niektóre nasze przykłady mogą się wydawać nietypowe, ale myślę, że wszyscy byliśmy też jako tutaj odbiorcy naszego podcastu nie tylko w sytuacjach projektowych, ale również w sytuacjach takich zarządczych organizacyjnych i spróbujemy podawać takie przykłady, bo one jednocześnie są też o wiele bardziej uniwersalne, bo niezależne od metody, w której się pracuje w danym konkretnym jednym zespole.

Jacek: Spis treści na dzisiaj. Po pierwsze powiemy, jak rozumiemy efektywność komunikacji. Następnie ta kluczowa część odcinka, praktyki podnoszenia efektywności komunikacji i na koniec powiemy kilka zdanie o tym, jak usprawnić efektywność komunikacji zespołu.

Kuba: To zaczynajmy od razu rozdział czym jest efektywność? Jakie mamy tutaj podejście, zwłaszcza dla osób, które nie słuchają wszystkich naszych odcinków?

Jacek: Tak. Za każdym razem, gdy mówimy o efektywności, mamy na myśli wartość uzyskaną z danej konkretnej czynności do kosztu jej uzyskania. I jakby się tak chwilkę zastanowić, to ten wzór pięknie pasuje również do kwestii komunikacji. Czyli oczekiwalibyśmy, żeby komunikacja dawała nam jak najwięcej wartości, czyli żeby była z naszej perspektywy efektywna przy jak najniższym koszcie doprowadzenia do sytuacji, w której czujemy, że ta efektywność jest wysoka. Czyli przykładowo możesz mieć bardzo długie spotkanie, na które zaprosisz sporo osób, a efekt tego spotkania wcale nie będzie taki spektakularny. Wtedy będziemy mówić o niskiej efektywności. Ale z drugiej strony możesz mieć krótkie spotkanie, być może zaproszone jest tam tylko kilka osób. Natomiast wnioski, z którymi wyjdziesz wraz z grupą z tego spotkania mogą być bardzo wartościowe, mogą popychać twój biznes do przodu. Wtedy będziemy mówić o tym, że to spotkanie było efektywne. I komunikacja jako taka szeroko rozumiana również byłaby tutaj oceniona wysoko.

Kuba: Natomiast wyzwanie w takim podejściu, o ile filozofia jest dosyć prosta, to wyzwanie tkwi w tym, żeby precyzyjnie wyliczyć wartość komunikacji. Koszt będzie najczęściej widoczny gołym okiem. To będą rzeczy łatwo policzalne, albo przynajmniej wydawałoby się, że łatwo policzalne, natomiast wartość dodana będzie trudna. Ja tu proponuję trochę uproszczone podejście, czyli nie trzymanie się tak dosłownie koncepcji wzoru na koszt i korzyść. Przyjmij, że Twoja efektywność pracy Twojego zespołu czy efektywność komunikacji tego zespołu jest jakaś, być może nieokreślona, ale jest jakaś, no i przeanalizuj, jak konkretne zmiany w przepływie informacji wpływają na wyniki. Więc może nie musisz złapać precyzyjnie wartości obecnej i wyliczyć wartości totalnej, tylko po prostu zrobić takie wyliczenie różnicy. Uzyskana korzyść dodatkowa dzięki lepszej komunikacji i dodatkowe koszty, a może oszczędności kosztu, bo czasami to może pójść nawet w tę stronę, uzyskane dzięki poprawie praktyk komunikacji. No i tutaj nakłady będą najczęściej związane z czasem zespołu, więc tak jak ja wyliczał kilka, kilkanaście osób uczestniczących w jakiejś aktywności związanej z komunikacją. Czy to jest jakieś spotkanie, czy to jest jakaś praca warsztatowa, czy to jest jakieś duże spotkanie szersze, ale to też może być czas na napisanie nawet głupiego maila, to też jest komunikacja, no i ten czas na napisanie go i na przeczytanie i zrozumienie go, to też będzie koszt. I taki wynik, takie koszty trochę oszacowane i takie wartość dodana, to nie będzie może wartość bezwzględna, to będzie tylko ocena zmiany efektywności, ale jest to wskaźnik wystarczający dla optymalizacji pracy zespołu i do analizy tego, co proponujemy w kolejnym rozdziale.

Kuba: Ale, zanim zaczniemy kolejny rozdział, przypominamy, że jeżeli chcesz pogłębić wiedzę, jeszcze bardziej niż robimy to w podkaście, to znajdziesz nasze płatne produkty na stronie porządnyagie.pl/sklep.

Jacek: Teraz przechodzimy do konkretnych praktyk i do rozwiązań, jak podnosić efektywność komunikacji w zespole. Pierwsza nasza rekomendacja to komunikuj się bez pośredników. Mamy tutaj na myśli to, żeby unikać pośrednictwa w komunikacji, wszędzie tam, gdzie jest to możliwe, komunikować się bezpośrednio. Jest to taka praktyka, można powiedzieć, oczywista, ewidentna do rozważenia z perspektywy efektywności, bo każda kolejna osoba, którą dokładamy do łańcuszka, najprawdopodobniej będzie nam generować jakiś koszt. Natomiast z drugiej strony, patrząc, każdy pośrednik też potencjalnie może nam obniżać tą wartość, którą uzyskamy, bo pewne rzeczy mogą być przekręcone, niedopowiedziane no i ta komunikacja nie będzie tak idealna, jakbyśmy sobie to wymyślili. Osobiście z Kubą mamy bardzo mocną preferencję do komunikacji bezpośredniej i mówił Kuba na samym początku podcastu o warsztatach, które organizowaliśmy przy organizacji właśnie tego konkretnego warsztatu. Również zdecydowaliśmy się na kontakt bezpośredni z organizatorem, żeby dograć wszystkie szczegóły organizacji, tej przestrzeni, na której prowadziliśmy warsztaty i uniknąć efektu głuchego telefonu.

Kuba: I konkretne dwie praktyki z życia takiego biznesowego. Jedna praktyka, ja spotykam się z nią pod nazwą skip level. Oczywiście wszystko po angielsku brzmi mądrze i chodzi o to, żeby ominąć taką klasyczną hierarchię, że przełożony rozmawia tylko z podwładnymi, dyrektor tylko z kierownikami, prezes tylko z jakimiś dyrektorami zarządzającymi. Czyli koncepcjalny skip level polega na tym, że np. członek zarządu rozmawia z przedstawicielami zespołów projektowych bezpośrednio, ewentualnie może w towarzystwie jakichś managerów pośredniego szczebla, ale na pewno nie polega tylko i wyłącznie na komunikacji za ich powiedzmy pośrednictwem, o czym właśnie mówi ten punkt. Czyli tutaj jest okazja generowana czasami, czasami trzeba do tego pretekstu, czasami są po prostu rutyny w firmie, ale poszukanie sposobu na to, żeby np. wyżsi zarządzający rozumieli perspektywę pracowników pierwszego poziomu poprzez osobistą rozmowę, osobistą obserwację, mogą być do tego okazje typu podsumowywania projektów, startowania tych projektów, mogą być też okazje typu jakieś refleksje na to usprawnianie, zmiana strategii, powodów dla różnych organizacji będzie dużo. Ważne, żeby przełamać trochę zasadę, że o tym co się dzieje w firmie wiem tylko i wyłącznie od szczebla minus jeden zarządzającego pod sobą. 

Kuba: Drugi przykład to unikanie pośredników w relacjach z rynkiem. Tutaj powiedziałbym jakiś rodzaj udziału w warsztatach z przedstawicielami klienta. I nieważne czy jesteś w roli takiej firmy, w firmie takiej roli, gdzie faktycznie bezpośrednio pracujesz z rynkiem, jakaś sprzedaż, jakaś opieka, jakiś może rozwój produktu, rozwój biznesu. Nawet jeśli nie robisz takich ról, fajnie, jeśli od czasu do czasu masz okazję do zobaczenia i porozmawiania z klientem na żywo, nawet w lekko zaaranżowanych warunkach lepiej zbudujesz swoje zrozumienie tego, czego klient potrzebuje, jakim językiem mówi, jakie są emocje, czy jakie są takie już namacalne, konkretne potrzeby, które zgłasza, żeby może właśnie przełamać ryzyko, że wszyscy pośrednicy, jak stoją między Tobą a rynkiem, powodują, że ten komunikat jest już trochę przeinaczony i traci się okazji do jakichś wartościowych spostrzeżeń. Powtórzę to, co Jacek powiedział w swojej części o tej poradzie, że tak, to trzeba wszystko rozważyć z perspektywy efektywności. Czyli skip level będzie kosztowny, bo wysoko pozycjonowana osoba w organizacji będzie spędzać sporo czasu na dodatkowych spotkaniach, które może można uniknąć. No i tak samo te warsztaty z przedstawicielem klienta będzie wymagało czasu, będzie odrywało trochę od innych obowiązków. Natomiast w obu tych praktykach i z doświadczenia i powiedzmy z założenia zakładam, że jest też duża wartość dodatkowa uzyskana dzięki temu, że rozwiązania będą lepsze, perspektywa będzie lepsza, decyzje będą lepsze i w efekcie wynik, rezultat będzie lepszy.

Kuba: Druga porada, twórz warunki do współdziałania. Dosyć ogólnie brzmiąca porada, ale chodzi w niej o to, żeby tak układać współpracę, żeby ta komunikacja wydarzała się przy jej okazji, a nie, żeby komunikacja służyła połączeniu pracy w izolacji. Czyli mamy tutaj taką tezę w tej poradzie, że bardzo skuteczna komunikacja ujawnia się sama przy okazji tego, że po prostu dwie lub więcej osób w zespole czy w jakiejś grupie zadaniowej po prostu współpracuje, tworzy coś razem, a nie komunikacja jest jakąś osobną aktywnością do innych aktywności osoby, która działa w ramach organizacji. Więc przykładowo, wyobraźmy sobie, że na przykład trzeba zrobić reorganizację i w Twojej organizacji trzeba zmienić strukturę. Najlepiej będzie ona zrozumiana, ta reorganizacja i powody, jej konkretne rozwiązania, jej konkretne pomysły, jeśli zespół liderów, osób zaangażowanych w tę zmianę będzie też ją jednocześnie w jakimś sensie współkreować czy tworzyć. Zaczną od brudnopisu, od niepełnych pomysłów, może sprzecznych wręcz koncepcji, ale w toku tej pracy będą potrzebowali się mocno komunikować i ta komunikacja dzięki temu tak sumarycznie będzie bardzo efektywna. Owszem, spędzi się trochę czasu nad dosyć żmudnym procesem dochodzenia do ustaleń, ale jednocześnie te ustalenia będą perfekcyjnie rozumiane, bo wszyscy zaangażowani uczestniczyli w tym procesie. To jest oczywiście dosyć kontrowersyjny przykład, bo może jeden z najbardziej hardcore’owych, jeśli te reorganizacje oznaczają też jakieś zmiany personalne, ale możemy to sobie też oczywiście zredukować do na przykład pracy projektowej, do pracy nad pomysłem, nad nowym produktem, czy jakiejś zmiany drobniejszej skali, ale wymagającej dobrej komunikacji.

Jacek: I przy tej okazji warto wspomnieć o tym, że łączy się to z koncepcją zależności jakości komunikacji od tego, jakie narzędzie stosujemy. Upraszczając można powiedzieć, że najsłabszym narzędziem jest przesyłanie sobie jakichś dokumentów pisemnych, jakichś opracowań. Pewnie średnia też jest rozmowa. Najlepsza będzie najprawdopodobniej wspólna praca nad jednym dokumentem, jakimś szkicem, draftem, czy jakąś konkretną koncepcją, ale wszystko to, co mówię, ma sens i jest prawdziwe tylko przy pewnym ważnym zastrzeżeniu, że mówimy tutaj o wypracowywaniu złożonej koncepcji, bo oczywiście nadal będą przypadki, gdzie najbardziej efektywne będzie napisanie do siebie po prostu dobrze skonstruowanego maila, ale wszędzie tam, gdzie będziemy coś tworzyć, wymyślać i generalnie im większa będzie złożoność, tym większy benefit będziemy mieć z tego, że będzie to faktycznie bliska współpraca. No i rolą lidera w tej układance będzie tworzenie warunków do takiego współdziałania, zachęcanie, pokazywanie, najprawdopodobniej też po prostu używanie przez samego lidera, czyli liderkę takich narzędzi, żeby ludzie w otoczeniu mieli okazję zobaczyć, jak by to mogło wyglądać w praktyce.

Jacek: Trzecia praktyka, zbliż się w komunikacji. Tutaj wychodzimy z takiego założenia, że aby się dobrze komunikować, trzeba być dosłownie blisko. Co mamy tutaj na myśli? W przypadku, gdy mówimy o pracy stacjonarnej, może to być np. siedzenie w jednej przestrzeni. Powoduje to, że właściwie obrót krzesła wystarczy, żeby coś skomentować, żeby coś dopytać. Dochodzi tutaj też taka koncepcja komunikacji przez osmozę, czyli przez przypadek właściwie mogę usłyszeć coś w open space, czy we wspólnym pokoju, co może być istotne, albo dla mnie, czyli otrzymam jakąś informację mimowolnie, albo przez przypadek można powiedzieć usłyszę jakąś informację, którą np. uznam, że warto ją skorygować. Natomiast nie musi to odnosić się wyłącznie do pracy stacjonarnej. Takim przykładem zbliżania się jest też czat grupowy, gdzie wszyscy mają ekspozycję na informacje, które przepływają w ramach pracy grupowej. Jeżeli spotkanie jest online, to warto zadbać, żeby przypominało spotkanie fizyczne. Tutaj mocno z Kubą wierzymy i lubimy jednak taki kontakt, nie tylko słowny, ale też, żeby można było zobaczyć osobę, z którą się rozmawia, więc jakby kamera, żebyśmy widzieli też wszystkie sygnały niewerbalne, dobrej jakości połączenie, żeby było i wyraźnie słychać, i żeby było dobrze widać. Tak naprawdę nie ma już dzisiaj przeciwwskazań technologicznych do tego, żeby się na odległość w skuteczny sposób komunikować.

Kuba: No i trochę się uśmiecham, bo z przekąsem można powiedzieć, że mamy 2026 rok, a nadal bywa wyzwaniem jakość komunikacji właśnie online i nie u osób, które pracują teoretycznie hybrydowo już najczęściej parę lat. Ja tutaj zamiast przykładu na zbliżenie się komunikacji, bo tutaj Jacek w zasadzie pokrył wszystko, mam króciutką anegdotę historyczną, bardziej odwołującą się do moich hobbies. Siedzenie razem bardzo widać w koncepcji projektowania rozwiązań w bombowcach z czasów II wojny światowej. Zwłaszcza niemieckie bombowce miały rozwiązanie wiążące się z tym, że cała załoga bombowca, a taka załoga to najczęściej jest cztery, a może nawet i więcej osób, siedzi bardzo blisko siebie razem. Mają malutką kabinę, wewnątrz której jest obok siebie pilot, bombardier, nawigator, strzelcy, radiooperator, czasami te funkcje są łączone, a czasami rozdzielne i oni wszyscy są zgrupowani obok siebie, więc nie tylko porozumiewają się poprzez intercom, czyli takie wewnętrzne radio i słuchawki, ale też mogą sobie coś pokazać ręką, krzyknąć do siebie, jakoś tak wzajemnie reagować wspólnie jako wspólna załoga. Bardzo podobny koncept też jest pokazany w moim starym artykule o łodziach podwodnych. To są już oczywiście o wiele większe konstrukcje niż samolot, ale tam też w pewnym prototypowym rozwiązaniu z czasów sowieckich doprowadzono do tego, że cała załoga siedzi, czy może grupa zarządzająca statkiem siedzi w jednym miejscu, dzięki temu bardzo wzrasta efektywność ich komunikacji, bo dzięki temu, że różne osoby siedzą obok siebie, mogą też bardzo szybko sobie pomagać, szybko reagować w sytuacjach kryzysowych czy właśnie tak przy okazji coś dostrzec.

Kuba: Następna porada, komunikuj się małymi partiami. Chodzi o to, żeby unikać komunikatów długich, późno wytworzonych na późnym etapie. To jest koncepcja taka trochę fraktalowa, czyli to jest prawdziwe na poziomie nawet niedużego maila, zawsze nieduży mail może być rozbity na jeszcze mniejsze partie. Zwłaszcza myślę, to się wypukla w przypadku dużych komunikacji. Nowa strategia, miesiącami generowana i opublikowana na raz, 20 slajdów, mail, który się przewija i przewija i przewija i końca nie widać, godzinne spotkanie, na którym nie ma gdzie szpilki wcisnąć, bo tam już każde jedno słowo jest to, które musi paść. To wszystko powoduje, że taka komunikacja jest kosztowna i może być przede wszystkim mało skuteczna. O tym się czasami zapomina, że osoby, które nadają komunikat, są zadowolone, że wreszcie wypluły z siebie ten wielki komunikat, natomiast faktycznie ze skutecznością może być krucho. Więc zamiast zbierania i formułowania jednego ostatecznego komunikatu proponujemy, żeby podzielić ten komunikat na mniejsze kawałki, żeby odblokować przepływ w takim rozumieniu praktyk, powiedzmy, zwinnych. Czyli po prostu, żeby uruchomić pewne pierwsze procesy, zacząć nadawać pierwsze kawałki komunikacji. Być może będą z tego uruchomione jakieś pierwsze działania, które już nie muszą czekać na to coś, co jest komunikowane, oczywiście w zależnie od co to jest. Można też dać szansę zebrać pierwszy feedback czy nadbudować pomysły kolejnych osób. Dajemy pewną pierwszą cząstkę informacji, na tej bazie pojawią się pierwsze reakcje, być może rzeczy, których ktoś nie przemyślał, kto nadaje ten komunikat i w efekcie uzyskać jeszcze większą wartość. Zwłaszcza jeśli połączymy to z praktyką od ogółu do szczegółu. Czyli w pierwszej partii komunikacji pójdzie jakiś kontekst, jakiś wysokopoziomowy cel, jakieś może ogólne założenia i deklaracja, że pierwsze szczegóły czy pierwsze akcje wykonawcze będą nadawane w jakimś tam najbliższym czasie z góry zadeklarowanym, czyli jest możliwość oswajania się z komunikatem, być może też można nadać te ogólniki, które się pewnie nie zmieniają aż tak mocno szybciej niż jakieś szczegóły wykonawcze, które podążają za kolejnymi jakimiś ustaleniami. To wszystko pozwoli z jednej strony lepiej przyswoić koncepcję, zaczynamy od ogólnych założeń, ale też by ewentualnie wyłapać fundamentalne różnice. Jeśli na przykład zespół nie zgadza się z zakomunikowaną zmianą strategii na poziomie najwyższym, to tym bardziej nie będzie przyswajał jakichś szczegółów wykonawczych, jakichś konkretnych milestone’ów czy konkretnych oczekiwanych feature’ów.

Jacek: I dwa przykłady do tego, co powiedział Kuba, czyli, zamiast przygotowywać finalny, wyrafinowany, wypolerowany, wymuskany raport na za tydzień, możesz spróbować dostarczyć pierwsze surowe wnioski już po dwóch dniach. To spowoduje, że po pierwsze dostarczasz wartość szybciej, a po drugie możesz się też czegoś dowiedzieć wcześniej na temat tego jak te wnioski rezonują, jak ta forma, którą przybrałeś czy przybrałaś odpowiada odbiorcom i jest szansa na to, żeby wykorzystać tę informację zwrotną i usprawnić to co przygotowujesz, czyli jest szansa na to, że ta ostateczna efektywność tego, co przekażesz będzie wyższa. Ale nawet w takiej pojedynczej komunikacji niekoniecznie musi być to coś dużego i rozbudowanego. Czyli na przykład to może być expose na spotkaniu z nowym zespołem. Możesz zastosować taką strukturę, żeby już po kilku pierwszych komunikatach, na przykład takich otwierających głównych czy przekazujących jakieś fundamentalne informacje, zrobić świadomą pauzę i pozwolić osobom, które są odbiorcami tych komunikatów do zadawania pytań lub komentarzy. Wiem, że zarówno mnie samego, jak i Kubę często kusi taka idea przesunięcia dyskusji i pytań na koniec na przykład prezentacji, ale może to się skończyć długim słowotokiem, którego szczegóły umykają, ludzie się być może trochę wyłączają, a ostateczna skuteczność komunikacji, a w tym też jej efektywność może być niższa. Tak więc warto się zastanowić, czy te partie, którymi karmimy otoczenie, czy one nie są zbyt duże, bo może się pojawić efekt znużenia i wyłączenia. 

Jacek: Kolejna praktyka. Wzmacniaj komunikację wizualizacją. Sporo mówiliśmy o komunikacji werbalnej, trochę też o komunikacji tekstowej, nawet przed chwilą o komunikacji w małych partiach. Natomiast problem jest taki, że taka forma komunikacji może być ulotna, podatna na błędy poznawcze i trudna do przyswojenia w dłuższym horyzoncie czasowym. Wizualizacja to z naszej perspektywy stworzenie wspólnego obrazu dyskusji, który widać w zależności od tego, gdzie pracujesz, albo na ścianie, albo na jakimś flipboardzie, albo na kartce, albo na ekranie, w jakimś współdzielonym pliku, czy w jakimś narzędziu do pracy wizualnej. 

Kuba: Konkretne przykłady. Jeśli w Twoim zespole rozmawia się o wynikach produktu, najlepsze, co można zrobić, to całą tę rozmowę prowadzić na podkładzie tzw. czyli gdzieś na wyświetlonej informacji o konkretnych miernikach produktowych, jakiś dashboard z wynikami, jakieś statystyki, jakieś wykresy. Wszystko to, co powoduje, że ta rozmowa nie jest zawieszona w powietrzu. Dowolne osoby po pierwsze widzą też to, co widzą pozostali, ale też ewentualnie mogą dostrzegać jakieś ważne cząstki do kontynuowania dyskusji, do zabierania głosu, czy chociaż wyobrażenia sobie o czym się mówi. Jeśli Twój zespół właśnie reorganizuje strukturę, jak zacząłem od tego hardkorowego przykładu na początku w poradach, no to najlepiej to robić poprzez rozmowę, gdzie w tle wyświetlona jest struktura, jakieś konkretne koncepcje na opcje dodatkowe, żeby ta rozmowa, zwłaszcza jeśli wymiarów jest więcej niż 2, 3, żeby nie była w głowach i w próbie wyobrażenia sobie tego, tylko po prostu rozmawiamy o konkretnych propozycjach, konkretnych schematach, konkretnych wymiarach, konkretnych fragmentach. Ale nawet jeśli to spotkanie nie jest o żadnych zmianach, żadnych jakichś dużych rzeczach, tylko jest to rutynowe, cotygodniowe spotkanie, jakieś bieżące takie operacyjne, gdzie zapadają kolejne ustalenia, nawet te ustalenia można wizualizować i my tutaj właśnie mocno rekomendujemy. Wszyscy uczestnicy mogą widzieć tworzącą się notatkę, ona może się tworzyć na czacie, ona może się najlepiej tworzyć wspólnie na ekranie, na jakimś współdzielonym dysku, na którym wszyscy mogą też ewentualnie dopisać swoje kawałki. Decyzje też są widoczne, wszyscy widzą jakie są zapisywane ustalenia, kto, co, do kiedy ma zrobić i w efekcie albo skorygować, jeśli jednak się nie zgadzam z tym, co zapadło na tym spotkaniu, albo lepiej zrozumieć i po prostu podążać za tym spotkaniem. Wszystko, co zajmie więcej niż parę minut już grozi tym, że ktoś się na chwilę rozproszy, na chwilę zostanie rozproszony i w efekcie ta efektywność komunikacyjna może spadać, nawet jeśli wydaje się, że rutynowe spotkanie przebiega jak zwykle. Wizualizuj takie spotkania, wizualizuj ustalenia z takich spotkań, w efekcie jest szansa na lepsze zrozumienie, lepsze skuteczne ustalenie, czy zapadnięcie pewnych decyzji.

Kuba: Szósta porada będzie prosta, sprawdzaj zrozumienie komunikatu. Oczywiście chodzi nam po prostu o parafrazę i takie upewnienie się, że ten, kto odbiera komunikat rozumie ten komunikat tak, jak jest on nadany w intencji nadającego. Natomiast chyba chcemy przede wszystkim mu wypuklić w tym, że to wymieniamy, że chodzi nie tylko o to, żeby ten, kto komunikuje, jakąś na przykład zmianę sprawdzał, czy odbiorcy tego komunikatu to sprawdzają, ale też chyba chcemy zachęcić do odwagi w parafrazowaniu w drugą stronę. Czyli również jako odbiorca komunikacji, niezależnie od tego w jakiej pozycji jesteś względem osoby, która coś ci przekazuje, żeby również to sprawdzić, sparafrazować i upewnić się, że istnieje zrozumienie i istnieje skuteczne komunikowanie się pomiędzy wami.

Jacek: I takie podsumowujące dwa przykłady na bazie tego, co powiedział Kuba. Możesz poprosić o parafrazę odbiorcę twojego komunikatu, który nadałeś, nadałaś, to jest jakby taka oczywista sprawa, ale też w drugą stronę możesz, będąc odbiorcą pewnych komunikatów, sparafrazować to, co usłyszałeś bądź usłyszałaś i dopiero upewniając się, że dobrze rozumiesz komunikację, która wokół ciebie się dzieje, odpowiednio skomentować. To może być w szczególności ciekawe podejście, jeżeli zespoły nie są przyzwyczajone do tego, żeby też odbiorca komunikatu w pewnym sensie brał odpowiedzialność za to, czy ta komunikacja faktycznie jest precyzyjna i czy na koniec dnia wszyscy rozumieją, co chcieliśmy zakomunikować.

Jacek: Przedostatnia praktyka, regularnie usprawniaj komunikację. Wychodzimy tutaj z Kubą z takiego założenia, że zespół podnosi efektywność komunikacji nie tylko poprzez po prostu komunikowanie się i nabieranie, można powiedzieć, wprawy, ale także dzięki ciągłym, drobnym usprawnieniom tego, jak się komunikują. Wymaga to oczywiście, jak się pewnie domyślasz, pewnej inwestycji, żeby wyjść poza tą rutynę komunikowania się. Natomiast potencjalnie czeka tutaj zwrot z inwestycji w postaci małych, drobnych eksperymentów i usprawnień, które na koniec dnia mają szansę podnieść efektywność tego, w jaki sposób się komunikujesz.

Kuba: Przykładem realizacji tej porady jest nawyk zadawania sobie pytania na przykład na tym wspomnianym, regularnym spotkaniu tygodniowym, punkt w programie, czy możemy coś ulepszyć w komunikacji. Krótkie 5 minut, a może nawet tylko jedno pytanie i sprawdzenie, czy ktoś w zespole, czy ktoś w grupie zadaniowej nie ma jakiegoś pomysłu i prawdopodobnie będą się pojawiać bardzo przyziemne usprawnienia. To nie będą przełomowe rozwiązania, nowe metody czy jakieś nowe kosmiczne praktyki. To będzie czasem pomysł typu lepszy tytuł maila albo jakaś zmieniona forma notatki ze spotkania, które uwypukli pewne rzeczy, które są ważne albo które były kłopotliwe w poprzednich tygodniach. Ale chodzi o to, żeby były ciągłe drobne usprawnienia i bardzo świadomie deklarowane, bardzo świadomie ustalane z całym zespołem. Czyli to, co Jacek powiedział, żeby to nie było takie usprawnianie się poprzez ciągłe powtarzanie tego i nabieranie wprawy, ale również bardzo świadome wprowadzanie jakichś nowych rozwiązań. Poza takim drobnym nawykiem regularnym proponuję drugi przykład. Jeśli w Twojej organizacji realizuje się jakieś okazjonalne spotkania większego kalibru, na przykład wyjazdowy typu offsite, może tam też fajnie w programie zamieścić jakiś punkt, może wtedy to już jest jednak wyraźnie zaznaczona, osobna sesja do głębszej refleksji i do wygenerowania pomysłów na temat tego, co można usprawnić w tym, jak się komunikujecie w obrębie swojego zespołu czy w obrębie firmy i wygenerować jakieś pomysły na zmiany oraz oczywiście zadeklarować sobie wzajemnie, żeby te zmiany wprowadzić w życie.

Kuba: Przykładem realizacji tej porady jest nawyk zadawania sobie pytania na przykład na tym wspomnianym, regularnym spotkaniu tygodniowym, punkt w programie, czy możemy coś ulepszyć w komunikacji. Krótkie 5 minut, a może nawet tylko jedno pytanie i sprawdzenie, czy ktoś w zespole, czy ktoś w grupie zadaniowej nie ma jakiegoś pomysłu i prawdopodobnie będą się pojawiać bardzo przyziemne usprawnienia. To nie będą przełomowe rozwiązania, nowe metody czy jakieś nowe kosmiczne praktyki. To będzie czasem pomysł typu lepszy tytuł maila albo jakaś zmieniona forma notatki ze spotkania, które uwypukli pewne rzeczy, które są ważne albo które były kłopotliwe w poprzednich tygodniach. Ale chodzi o to, żeby były ciągłe drobne usprawnienia i bardzo świadomie deklarowane, bardzo świadomie ustalane z całym zespołem. Czyli to, co Jacek powiedział, żeby to nie było takie usprawnianie się poprzez ciągłe powtarzanie tego i nabieranie wprawy, ale również bardzo świadome wprowadzanie jakichś nowych rozwiązań. Poza takim drobnym nawykiem regularnym proponuję drugi przykład. Jeśli w Twojej organizacji realizuje się jakieś okazjonalne spotkania większego kalibru, na przykład wyjazdowy typu offsite, może tam też fajnie w programie zamieścić jakiś punkt, może wtedy to już jest jednak wyraźnie zaznaczona, osobna sesja do głębszej refleksji i do wygenerowania pomysłów na temat tego, co można usprawnić w tym, jak się komunikujecie w obrębie swojego zespołu czy w obrębie firmy i wygenerować jakieś pomysły na zmiany oraz oczywiście zadeklarować sobie wzajemnie, żeby te zmiany wprowadzić w życie.

Kuba: I ostatnia porada, podobna do poprzedniej, ale jednak inna, eksperymentuj ze sposobami komunikacji. Tak uwypuklę różnicę. W tej poprzedniej myślimy o takich ciągłych, drobnych usprawnieniach, takim ciągłym dążeniu do doskonałości. Natomiast w tym punkcie proponujemy odrobinę szaleństwa, ale takiego zdrowo rozumianego. Nie dowiesz się, czy coś zadziała w złożonych realiach, dopóki tego nie spróbujesz. Czyli o niektórych kwestiach nie dywagujcie, nie zastanawiajcie się, nie wymieniajcie się między sobą jakimiś argumentami i kontrargumentami do kontrargumentów, tylko po prostu zróbcie eksperyment, ale taki bardzo świadomy eksperyment. Działamy jakoś inaczej, wprowadzamy jakąś zupełnie inną, nową praktykę, niż to, co robiliśmy do tej pory. Robimy sobie to świadomie, robimy sobie to jako eksperyment z założonymi jakimiś celami. Obserwujemy również niespodziewane zjawiska uboczne, na które nie wiemy, czy wystąpią. No i jako zespół podejmujecie podsumowanie takich eksperymentów i podejmujecie decyzję, czy któryś z tych szalonych pomysłów wchodzi w życie, czy nie. Mówię szalonych pomysłów z uśmiechem. Jak słuchasz, to nie widzisz, jak na wideo, to widać, że się uśmiecham, bo to szalone pomysły dla jednej firmy, to będzie normalna rutyna dnia codziennego dla innej firmy. Więc to mogą być rzeczy niektóre z tych, które wymieniliśmy jako przykłady, jakieś inne, których może nie wymieniliśmy, typu dzień bez spotkań, czy jakiś dzień bez maila, czy anulowanie spotkań jakiegoś typu. To wszystko mogą być rzeczy, które po prostu wymagają pewnej odwagi i tę odwagę łatwiej uzyskać, jeśli robisz eksperyment rozumiany jako coś tymczasowego, coś, żeby sprawdzić i wyciągnąć wnioski na bazie rzeczywistości, a nie tylko na bazie wyobrażeń, jak mogłoby być, gdybyśmy to próbowali robić.

Jacek: I dodam do tego, co powiedział Kuba, takiego osobnego przykładu. Może nie podamy, ale przykładem może być po prostu dowolne zastosowanie albo zaprzestanie stosowania którejkolwiek z wymienionych dzisiaj praktyk.

Jacek: Przechodzimy do ostatniego rozdziału, czyli powiedzieliśmy dotychczas o praktykach, a teraz tak trochę konkretniej, jak zamienić te słowa w czyny, czyli jak usprawnić efektywność komunikacji.

Kuba: Pierwszy punkt bazowy, fundamentalny, to zbuduj świadomość nieefektywności komunikacji. Żadna zmiana nie nastąpi, jeśli nie ma świadomości, że ta zmiana jest potrzebna. To jest dosyć oczywiste, ale komunikacja też jest tutaj możliwym zjawiskiem, które podlega również tej zasadzie. Czyli ta komunikacja w Twoim zespole jest jakaś, jest efektywna w oczywiście swoim stopniu i ma swoje niedoskonałości, ale ma też swoje mocne strony. Natomiast może być tak, zwłaszcza jeśli w waszej organizacji nie ma takiego myślenia, czy takiego nastawienia, że nikomu do głowy nie przyjdzie, że ta komunikacja jest nieefektywna. Komunikujemy się tak samo już od tygodni, miesięcy, od czasu ostatniej zmiany szefa, który wprowadził jakieś swoje praktyki. No i nikt może nie pomyśleć, że to wymaga coś poprawy, po prostu jest jak jest. Więc tutaj być może trzeba to ująć mniej lub bardziej dyplomatycznie, ale jednak pokazać potencjał usprawnienia, potencjał zmiany no i może nawet wprost nazwać niedoskonałość obecnego stanu, jakieś rzeczy, które wymagają zmiany. 

Jacek: Druga wskazówka, wzbudzaj poparcie dla zmiany. Chodzi o dotarcie do każdej osoby, która jest objęta zmianą i pokazanie tej zmiany w taki sposób, by miała ona sens dla tej konkretnej osoby. Nie chodzi tutaj o jakieś manipulowanie, tylko wynika to z faktu, że różne osoby mają różne potrzeby, mają różne nastawienie, są w różnej sytuacji aktualnej, zawodowej i prywatnej. No i należałoby spojrzeć na każdą osobę tak w miarę z pojedynczej perspektywy i zastanowić się jak można sensownie dotrzeć, jakimi argumentami do tej konkretnej osoby, żeby ta osoba zaczęła podążać za zmianą i zaczęła tę zmianę wspierać.

Kuba: Trzeci krok to uzupełniaj kompetencje komunikacyjne. Komunikowanie się jest kompetencją i jak każda kompetencja wymaga doskonalenia. Sama z siebie nigdy nie jest idealna i tutaj też trzeba poprawiać albo ewentualnie dostrzegać jakieś luki i je uzupełnić czy po prostu sprawić, żeby nie istniały. Jako pracownik niejednej korporacji wiele razy uczestniczyłem w szkoleniach tak zwanych miękkich i wtedy, gdy w nich uczestniczyłem, może nie za każdym razem dobrze rozumiałem, po co to się dzieje, nie zawsze je może też doceniałem, ale jednak z perspektywy czasu, z mądrości dnia dzisiejszego widzę, że to ma sens, żeby jeszcze raz spróbować dawać sobie informację zwrotną, zakomunikować jakąś zmianę czy może pokazać, jak można formułować cele, tak żeby były motywujące i pewnie mogę wymieniać po kolei program wielu tego typu szkoleń. Ważne, że ćwiczy się na takich warsztatach, poznaje się może jakieś nowe proste schematy, które można później zastosować na co dzień i to wszystko powoduje, że te ewentualne luki kompetencyjne albo jakieś już lekko zaśniedziałe umiejętności ponownie stają się aktywne.

Jacek: Czwarta porada, pomóż wykorzystać nowe praktyki. Możesz znaleźć się w takiej sytuacji, kiedy potrzebne będzie dodatkowe zainicjowanie wykorzystania wszystkiego tego, czego Twoje zespoły nauczyły się w trakcie szkoleń czy warsztatów, o których Kuba przed chwilą wspominał, tam mogą się pojawiać różne modele, techniki, pewne praktyki. No i jak to zwykle bywa ze szkoleniami, jeżeli nie wykorzystasz tego w praktyce od razu, to najprawdopodobniej ta wiedza się szybko ulotni, więc tą poradą chcemy zachęcić do tego, żeby tak świadomie zachęcać do eksperymentów i wykorzystania tej wiedzy, którą ludzie zdobyli na warsztatach czy na szkoleniach. I właściwie identyczna porada dotyczy zmiany podejścia do komunikacji. Cały poprzedni rozdział to była lista gotowych praktyk. Może jest tak, że któraś z tych rzeczy nie jest wykorzystywana w Twoim zespole, a czujesz, że mogłoby to podnieść efektywność komunikacji, więc zachęcamy do tego, żebyś zainicjował, czy to przesiadkę bliżej siebie, czy może jakąś formę warsztatów, w których efektem będzie refleksja i usprawnienia konkretne na temat tego, jak na co dzień komunikują się ludzie w Twoich zespołach.

Kuba: I ostatni krok, wzmacniaj kierunek usprawnienia komunikacji. Jacek mówił o tym, żeby zainicjować pewne zmiany. To może być Twoja rola. Twoją rolą może być też podsumowanie sobie zmiany. Ja zaczynałem na początku wyliczać, jak trudne może być wyliczenie wzoru na efektywność. Twoim zadaniem może być pokazanie ludziom, że wprowadziliśmy jako zespół zmiany i są różnice, są efekty. Możesz im to powiedzieć. Może możesz zapytać, czy oni tak sądzą. Techniki to może być twój indywidualny styl zarządczy, ale ważne, żeby systematycznie dokonywać podsumowywań uzyskanych zmian, zagospodarować sobie trochę czasu na to, żeby te zmiany może policzyć, może sobie nazwać, może jakieś story do tego dołożyć. Tak żeby połączyć włożony wysiłek, próbę zbudowania nowych nawyków z uzyskiwanymi efektami jako zespół, z uzyskiwanymi rezultatami efektywności komunikacji.

Jacek: Podsumowując dzisiejszy odcinek. Jakie praktyki można zastosować, żeby poprawić efektywność komunikacji? 

Kuba: Komunikuj się bez pośredników. Twórz warunki do współdziałania. Zbliż się w komunikacji. Komunikuj się małymi partiami. 

Jacek: Wzmacniaj komunikację wizualizacją. Sprawdzaj zrozumienie komunikatu. Regularnie usprawniaj komunikację i eksperymentuj ze sposobami komunikacji.

Kuba: Jeśli w Twoich zespołach wciąż powtarza się to stwierdzenie z Jacka otwarcia, że musimy się lepiej komunikować, ale nikt nie wie jak to osiągnąć, skorzystaj z naszej sesji warsztatowej usprawniającej efektywność komunikacji. Zdobądź konkretne narzędzia, wzmocnij kompetencje komunikacyjne i wprowadź trwałe usprawnienia. Więcej szczegółów znajdziesz na 202procent.pl/sesja-warsztatowa. Skontaktuj się z nami, żeby umówić konkretny termin. Link powtórzymy w opisie odcinka i na stronie porzadnyagile.pl dedykowanej temu konkretnemu nagraniu.

Jacek: A notatki do tego odcinka, artykuł, transkrypcję, zapis wideo znajdziesz na stronie porzadnyagile.pl/141.

Kuba: I to by było wszystko na dzisiaj. Dzięki Jacek. 

Jacek: Dzięki Kuba. I do usłyszenia wkrótce.

________

To była pełna transkrypcja odcinka podcastu Porządny Agile. Dziękujemy za lekturę!

Czy Twój zespół naprawdę dowozi to, co zaplanuje? A może się przyzwyczailiście do tego, że zrealizowany jest tylko ułamek planu na iterację? Rozkładamy na czynniki pierwsze przewidywalność zespołu. Miara ta może być potężnym wsparciem dla zespołu, ale i źródłem frustracji czy złych decyzji. Pokażemy Ci jak mierzyć ją w Jira, Excelu czy innych narzędziach. Podpowiemy też, jak interpretować wyniki, by realnie ustabilizować w zespole proces dowożenia zaplanowanego zakresu prac. Cała rozmowa odnosi się do case study z naszej pracy z jednym z zespołów. Jeśli masz już dość niewykonanych planów oraz ciągłych tłumaczeń, ten odcinek jest dla Ciebie.

Spis treści

• Definicja przewidywalności
• Jak mierzyć przewidywalność?
• Wskazówki na temat stosowania miary przewidywalności
• Jak poprawiać przewidywalność zespołu?
• FAQ: Przewidywalność zespołu
• Transkrypcja podcastu „Przewidywalność zespołu”

Przewidywalność rozumiemy jako to, w jakim stopniu zespół dowozi lub dostarcza to, co zaplanował. W jakim stopniu realizuje plan, który przyjął? Czy jeśli zespół mówi, że coś zostanie zrealizowane, to faktycznie tak się stanie? Z jakim prawdopodobieństwem zespół realizuje swoje zamiary. Z jednej strony jest to miara, do której można wrócić w dalszej części, ponieważ da się ją wyrazić w sposób precyzyjny…a z drugiej, mówiąc o przewidywalności zespołu, mamy na myśli cechę, którą warto uznawać za pożądaną. To zespół, na którego prognozach organizacja może polegać.

Dla równowagi warto doprecyzować, czym przewidywalność – w naszym rozumieniu – nie jest, mimo że bywa tak postrzegana. Przewidywalność bywa utożsamiana z ogólnym prawdopodobieństwem dostarczania, niezależnie od jego poziomu lub dużej zmienności. W sensie czysto matematycznym nadal mieści się to w definicji, podobnie jak smród jest zapachem, a brunatny jest kolorem… jednak przewidywalność postrzegamy jako zjawisko pozytywne, pożądane. Nie uznajemy za sukces sytuacji, w której zespół dostarcza jedno zadanie na cztery lub realizuje jedynie 20% planu, mimo że taki poziom również może być „przewidywalny”. Choć w ujęciu matematycznym nadal można to nazwać przewidywalnością, odcinamy się od takiego podejścia. Przewidywalność rozumiemy jako korzystną cechę zespołu. To cecha, która powinna zmierzać ku konkretnym, ambitnym wartościom. Przewidywalny zespół to ten, który dostarcza to, co zaplanuje, nie tylko tyle, ile zazwyczaj udaje mu się osiągnąć. Nawet jeśli ta „zazwyczaj osiągana” wartość jest bardzo niska. Zespół, który regularnie dostarcza mało, nie jest dla nas przewidywalny, nawet jeśli działa w sposób powtarzalny.

Ogólny sposób obliczania jest dość prosty. W uproszczeniu: to stosunek wartości faktycznie zrealizowanej w danej iteracji (np. Sprincie) do wartości uprzednio zaplanowanej. W większości przypadków wyraża się to w procentach.

W szczegółach może się to okazać znacznie bardziej złożone. Poszczególne zespoły uwzględniają w tym wzorze różne elementy składowe. Najprostsze podejście polega na uwzględnieniu wszystkich elementów realizowanych przez zespół, niezależnie od typu pracy czy rodzaju planowanych zadań w iteracji. Część zespołów decyduje się jednak na mierzenie przewidywalności wyłącznie na podstawie historyjek użytkownika (tzw. storki), niezależnie od przyjętej lokalnej terminologii. W innych przypadkach brane są pod uwagę tylko funkcjonalności lub wyłącznie prace rozwojowe. Zdarza się też, że zespoły uwzględniają zadania techniczne lub podzadania niezbędne do realizacji zaplanowanej pracy. Kontrowersyjne bywa włączanie do kalkulacji przewidywalności błędów zaplanowanych do rozwiązania, mimo że są one znane już na początku Sprintu. Podobne wątpliwości może budzić uwzględnianie zadań utrzymaniowych, powtarzalnych czynności, które muszą zostać wykonane niezależnie od okoliczności i regularnie pojawiają się w iteracjach. Warto jednak zaznaczyć, że sposób uwzględniania typów pracy w mierzeniu przewidywalności to temat wart refleksji. To obszar, który wymaga świadomego zaplanowania i doprecyzowania, co dokładnie zostanie ujęte w wzorze stosowanym przez konkretny zespół.

Jeśli zespół zaplanował dostarczenie 10 elementów, a zrealizował tylko 2 – przewidywalność wynosi 20%. Przy realizacji 5 z 10 zaplanowanych elementów przewidywalność wynosi 50%. Jeśli zaplanowano 10, a dostarczono 12 – przewidywalność osiąga poziom 120%. Przewidywalność to miara, w której wartość oczekiwana mieści się w pewnym akceptowalnym zakresie. Zakresem uznawanym za wart rozmowy jest przedział 80 a 120%. Istotniejsze jest utrzymywanie się w tym zakresie niż osiąganie konkretnego, precyzyjnego wyniku. Powtarzalne osiąganie dokładnie 100% może świadczyć o tym, że miara została potraktowana jako cel sam w sobie. Zakres zdrowej przewidywalności można porównać do przedziałów referencyjnych w wynikach badań krwi. Otrzymujemy listę wyników wraz z informacją, czy konkretna wartość mieści się w normie lub spodziewanym zakresie. Bardzo podobnie działa to w przypadku przewidywalności.

W kontekście przewidywalności warto również wspomnieć, jak można ją mierzyć w praktyce, za pomocą narzędzi. Innymi słowy, w jaki sposób technicznie przeprowadzić taki pomiar.

Najczęściej spotykanym narzędziem w organizacjach, jest JIRA.Wystarczy przejść do sekcji raportów i wybrać wykres Velocity Chart (w wersji anglojęzycznej). Na wykresie znajdziesz zarówno informację o faktycznie zrealizowanej pracy (prędkość zespołu), jak i o zakresie pracy zaplanowanej na dany Sprint. Dane te powinny pojawić się automatycznie, pod warunkiem zachowania podstawowej higieny pracy w JIRA. Oznacza to m.in. prawidłowe uruchamianie Sprintów. Sprint powinien wystartować w faktycznym momencie jego rozpoczęcia, a zakończony dokładnie w momencie jego ukończenia. W jego zakresie powinna znaleźć się realnie wykonywana praca. Równie istotna jest poprawna konfiguracja boardu, jak i samego projektu, który zespół realizuje. Przy takim podejściu wykres otrzymujemy „z pudełka”, bez dodatkowej konfiguracji. Nie jest potrzebna żadna dodatkowa konfiguracja, aby sprawdzić, jak historycznie kształtowała się przewidywalność zespołu.

W porównaniu z JIRA, Excel oferuje znacznie większą elastyczność, choć dane nie zbierają się automatycznie, jak ma to miejsce w JIRA. Przy zachowaniu podstawowej dyscypliny pracy, JIRA zlicza dane samodzielnie. W Excelu natomiast konieczne jest ręczne wprowadzanie danych, najczęściej przez osobę odpowiedzialną za proces, członka zespołu lub jego lidera. Należy pamiętać o przeniesieniu danych historycznych i użyciu odpowiednich formuł, aby uzyskać oczekiwany wynik. Choć jest to praca wymagająca większego zaangażowania, to w sytuacjach bardziej złożonych lub wymagających większej precyzji w doborze danych do analizy, Excel może okazać się bardziej wiarygodnym i lepiej kontrolowanym rozwiązaniem niż narzędzia generujące wynik na podstawie filtrów lub niewłaściwie prowadzone.

Innymi narzędziami mogą być wszelkiego rodzaju rozwiązania wspierające wizualizację pracy oraz powiązanych z nią koncepcji. W warunkach pracy zdalnej mogą to być narzędzia takie jak Mural czy Miro. W pracy stacjonarnej równie dobrze sprawdzi się tablica, flipchart czy nawet kartka papieru. Kluczowe jest, aby dane znalazły się w miejscach, wokół których zespół będzie się koncentrować. Na podstawie obserwacji, zespoły pracujące zdalnie często prowadzą refleksję np. na Muralu. W takim przypadku śledzenie informacji procesowych, w szczególności dotyczących przewidywalności, może być naturalnym elementem, który i tak zostanie uwzględniony podczas cotygodniowej lub dwutygodniowej refleksji. Posiadanie kompletu informacji w miejscu, do którego zespół zagląda rutynowo, znacząco zwiększa szansę na ich wykorzystanie i refleksję nad tym, jakie wnioski z nich płyną.

Ostatnią z opcji w kontekście narzędziowego mierzenia i prezentowania przewidywalności są narzędzia BI. Najczęściej źródłem danych była JIRA, Azure DevOps lub podobne narzędzia służące do zarządzania zadaniami. Surowe dane z tych narzędzi można przesłać do systemów BI. Niezależnie, czy będzie to Power BI, Tableau czy inne narzędzie, zależnie od tego, co jest używane w danej organizacji. Różne narzędzia mają różny poziom popularności w zależności od organizacji. Oczywiście wymaga to już określonych kompetencji, zarówno w zakresie podłączenia danych, jak i konfiguracji raportów. W zamian można otrzymać atrakcyjną formę wizualizacji, możliwość konfigurowania dodatkowych filtrów lub rozszerzania zakresu danych. W przypadku dużych organizacji dużą wartością może być możliwość pokazania na jednym dashboardzie wyników wielu zespołów lub pewna forma standaryzacji np. dotycząca sposobu mierzenia przewidywalności. Potencjalna nagroda jest duża, ale wiąże się to również z określonym kosztem. Jeżeli zespół dysponuje odpowiednimi kompetencjami, koszt może być pomijalny, a w niektórych przypadkach warto ponieść ten wysiłek, aby uzyskać wartościowe raporty i miarodajne wizualizacje.

Warto rozpocząć od uwzględnienia stopnia innowacyjności zespołu. W typowym zespole wytwórczym przewidywalność powinna być mierzona. Jest to również pożądana cecha takiego zespołu. W praktyce można jednak wskazać zespoły o bardzo wysokim poziomie innowacyjności, których praca opiera się głównie na badaniach, odkrywaniu i działaniach typu research and development a poziom innowacyjności tych zespołów jest wyjątkowo wysoki. Ze względu na złożoność i nieprzewidywalność zadań badawczych, takie zespoły z natury rzeczy mogą mieć trudność z osiąganiem przewidywalności, w rozumieniu prezentowanym artykule. W takich przypadkach należy przyjąć pewną poprawkę, swego rodzaju gwiazdkę przy tej miarze. W niektórych organizacjach część zespołów może być z definicji nieprzewidywalna. Zdarzają się też firmy, w których przewidywalność nie jest możliwa w żadnym zespole, ze względu na charakter produktu lub branży. Warto więc uwzględnić, że nie w każdej firmie i nie w każdym zespole mierzenie przewidywalności będzie adekwatne. Może to być również miara, której zastosowanie nie zawsze ma sens.

Przy tej okazji warto zwrócić uwagę na zjawisko, które często można zaobserwować w zespołach. Wiele zespołów ma poczucie, że są wyjątkowe i na tyle innowacyjne, że ze względu na charakter swojej pracy nie są w stanie działać w sposób przewidywalny. Jednak doświadczenie pokazuje, że w większości przypadków nie jest to do końca uzasadnione. Zespoły, które rzeczywiście funkcjonują w taki sposób, stanowią zdecydowaną mniejszość. Nawet w przypadku zespołów realizujących działania badawcze, również możliwe jest ich planowanie, dzielenie na mniejsze kroki oraz precyzyjne określenie kryteriów akceptacji. Można także w uporządkowany sposób decydować, czy zaplanowane działania zostały zrealizowane, nie tyle przez pryzmat rezultatu, ile przez wykonanie zaplanowanej pracy. Większość zespołów wykonuje pracę, która ma najczęściej taki charakter, że można dość dobrze przewidzieć zakres realizowanych zadań. Warto zatem zaznaczyć istnienie potencjalnej pułapki myślenia, i zachęcić do rzetelnej refleksji, czy rzeczywiście praca zespołu jest aż tak niezarządzalna i nieprzewidywalna, czy jedynie utknęliśmy w przekonaniu, że właśnie taka ona jest.

W poprzednich fragmentach została omówiona zarówno postać wzoru, jak i sposób wyrażania jego wyniku. Jedną z głównych wątpliwości osób analizujących temat przewidywalności jest wybór między analizą liczby konkretnych elementów zaplanowanych na dany Sprint lub iterację, czy analizą sumy przypisanych im story pointów. Choć pierwsze próby mierzenia przewidywalności opierały się głównie na story pointach, obecnie zdecydowanie bliższe jest podejście polegające na analizie liczby zaplanowanych elementów. W Jirze istnieje możliwość zmiany ustawień wykresu tak, aby prezentował liczbę zadań (issue count), czyli liczbę elementów zaplanowanych na dany Sprint. Takie podejście przybliża do koncepcji mierzenia przepustowości oraz przewidywalności w oparciu o ilość zadań, a nie klasyczne velocity, które zazwyczaj oparte jest na sumie story pointów zaplanowanych na dany Sprint.

Dlaczego warto poświęcić czas na ten temat? Ponieważ wiele zespołów traci czas na szczegółową wycenę elementów, aby tylko uwzględnić je we wzorze na przewidywalność. Tymczasem niezależne obserwacje i doświadczenia wskazują że w wielu zespołach korelacja między liczbą zakończonych elementów a liczbą zrealizowanych story pointów jest na tyle silna, że nie ma potrzeby inwestowania dodatkowej energii w wycenianie wszystkich prac. Szczególnie gdy prowadzi to do naszym zdaniem niepotrzebnych działań, takich jak wycenianie błędów czy zadań technicznych, jedynie po to, aby dobrze wyglądały w zestawieniach. Prostsze podejście, polegające na liczeniu liczby zakończonych elementów, w takim predictability może okazać się wystarczające. Wzór oparty na liczbie elementów jest prosty i łatwy do wyliczenia, a jego zastosowanie nie wymaga dodatkowego wysiłku, który nie przekłada się na wartość. Warto podkreślić (jak wcześniej wspomniano), że domyślnie narzędzie Jira prezentuje dane (a z obserwacji wynika, że jest to najczęściej używane narzędzie), w oparciu o story pointy. Oznacza to, że elementy niewycenione nie zostaną uwzględnione w analizie przewidywalności, co może zaburzyć dokładność wskaźnika, zwłaszcza gdy zespół realizuje zadania przechodzące pomiędzy Sprintami. Jeśli zespół w praktyce uwzględnia także elementy niewyceniane, to domyślne podejście oparte na story pointach może okazać się mylące. Dlatego warto świadomie dobrać zmienne uwzględniane we wzorze na przewidywalność.

Wiele niepożądanych skutków pojawia się w organizacjach, w których przewidywalność staje się celem samym w sobie. W niektórych organizacjach przewidywalność wpisywana jest jako cel roczny, a premie są uzależniane od stopnia przewidywalności zespołu.Często przy tym określane są konkretne oczekiwane wartości. Często spotykaną praktyką jest oczekiwanie dokładnie 100% realizacji planów, czyli „realizujcie dokładnie to, co zaplanowane”, co może prowadzić do licznych pułapek. Widziano też organizację, w której oczekiwano, że przewidywalność nie powinna przekraczać 80%, co oznacza, że przewidywalny zespół to taki, który konsekwentnie nie dowozi całości planu. To również nie jest trafne podejście. Przewidywalność powinna pełnić przede wszystkim rolę wewnętrznej miary zespołu, służącej jako punkt odniesienia przy doskonaleniu procesu, a także jako pomoc przy planowaniu i refleksji zespołowej (np. podczas Retrospektyw). Może być również przydatna w dłuższym horyzoncie czasowym, jednak nie powinna być podstawą do nagród lub kar. Tak jak każda podobna metryka, przewidywalność może łatwo zostać wypaczona, jeśli stanie się celem sama w sobie, zamiast wiarygodnym wsparciem dla usprawnień.

Przewidywalność nie powinna być jedynym wskaźnikiem, na który zespół zwraca uwagę w ramach monitorowania procesu. Może być dobrym punktem wyjścia, ale nie należy poprzestawać wyłącznie na niej.  Przykładowo, warto równolegle obserwować przepustowość (throughput). Można uzupełnić ten zestaw o wskaźnik jakości lub wartości biznesowej. Kluczowe jest uwzględnienie tego, co w danym momencie jest istotne i co zespół chce monitorować, tworząc zestaw miar odpowiadający kontekstowi. Należy obserwować, jak poszczególne wskaźniki wpływają na siebie nawzajem. Zdarza się, że poprawa jednej metryki wpływa negatywnie na inną. Dlatego warto świadomie dobrać zestaw wskaźników, aby uzyskać pełniejszy obraz kondycji zespołu oraz jego otoczenia.

Wiele sposobów na poprawę przewidywalności zostało już omówionych we wcześniejszych artykułach. Z perspektywy czasu można się uśmiechnąć, że tekst poświęcony przewidywalności pojawia się tak późno, skoro wiele związanych z nią praktyk zostało już wcześniej szczegółowo opisanych. Potraktuj ten fragment jako spis treści: zestaw ośmiu praktyk, które rekomendujemy w kontekście poprawy przewidywalności zespołu.

 Jakie praktyki zastosować, żeby poprawić przewidywalność zespołu?

Przewidywalność to miara i jednocześnie pożądana cecha zespołu, która pokazuje, w jakim stopniu zespół realizuje pracę planowaną na Sprint. Zwykle wyraża się ją w procentach, jako stosunek liczby elementów faktycznie zrealizowanych do liczby elementów pierwotnie zaplanowanych.

Przewidywalność obliczysz jako stosunek liczby elementów zrealizowanych do liczby elementów zaplanowanych, wyrażony w procentach.Przykładowo: zespół planuje zrealizować 10 zadań, udaje się zrobić 7, przewidywalność = 70%

Optymalny wynik przewidywalności mieści się w przedziale pomiędzy 80% a 120%. Powtarzalny wynik 100% może sygnalizować manipulowanie planowaniem, a nie faktyczną poprawę procesu.

Wybór narzędzia zależy od tego, czego aktualnie używasz jak również indywidualnych preferencji:

To zespół, który regularnie nie dostarcza tego, co planuje zrealizować. Brak przewidywalności może dotyczyć pojedynczego Sprintu lub dowolnego, dłuższego okresu.

Do miary przewidywalności można wliczać:

Zespoły mogą uważać, że ich praca jest wyjątkowo innowacyjna i nieprzewidywalna, przez co jest niemożliwa do zaplanowania.

Gdy miara staje się podstawą nagród lub kar, traci wiarygodność. Zespół zaczyna działać pod wskaźnik, a nie pod wartość. Przewidywalność powinna być wewnętrznym kompasem, a nie narzędziem kontroli.

Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu Porządny Agile.

Jacek: Ostatnio na naszej stronie pojawiło się nowe case study. Dotyczy ono tego, jak w jednym z zespołów poprawiliśmy przewidywalność. Uznaliśmy z Kubą, że jest to dobra okazja, żeby powiedzieć trochę więcej o przewidywalności w ramach tego odcinka.

Kuba: Adres case jest nie do przedyktowania w nagraniu audio, więc po prostu zachęcam Cię do tego, żeby znaleźć wspomniany case study w notatkach do odcinka i przeczytanie tego, co Jacek tam pisze.

Jacek: Jaki spis treści na dzisiaj? Przede wszystkim zdefiniujemy, czym dla nas jest przewidywalność. Opowiemy, jak mierzyć przewidywalność. Podzielimy się wskazówkami na temat stosowania przewidywalności i na koniec damy kilka wskazówek, jak faktycznie, jakimi praktykami poprawić przewidywalność zespołu.

Kuba: To przechodząc do rzeczy, pierwsza część to definicja przewidywalności. Przewidywalność rozumiemy to, jak zespół dowozi czy dostarcza to, co zaplanował. W jakim stopniu realizuje ten plan, który sobie przyjął? Czy, jak mówią, że coś będzie zrealizowane, czy to faktycznie będzie? Z jakim prawdopodobieństwem zespół realizuje swoje zamiary.

Jacek: Więc jest to dla nas z jednej strony miara, o której powiemy za chwilę trochę więcej, bo można ją bardzo konkretnie wyrazić, a z drugiej strony, jak mówimy o tym, że zespół jest przewidywalny, to myślimy też w kontekście takim, że jest to pewna pożądana cecha zespołu. To jest taki zespół, na którym w kontekście tych prognoz, z którymi się dzielą z organizacją, można na nim polegać.

Kuba: Dla równowagi powiemy też, czym nie jest przewidywalność według nas, choć niektórzy to też tak rozumieją. Niektórzy rozumieją przewidywalność jako pewną taką cechę generyczną rozumianą jako prawdopodobieństwo dostarczania, ale również prawdopodobieństwo o bardzo niskim stopniu albo o bardzo dużej zmienności tej wartości. W sensie, takim matematycznym, to też jest przewidywalność, tak samo jak smród jest zapachem albo jakiś brunatny też jest kolorem, ale jednak jako przewidywalność rozumiemy coś pozytywnego, zjawisko korzystne. W tym sensie nie cieszy nas fakt, że jakiś zespół ma przewidywalność, tylko ta przewidywalność to jest jedno zadanie na cztery zaplanowane albo 20% planu. W sensie matematycznym to jest przewidywalność, ale my się od takiej przewidywalności i takiego rozumienia tego słowa odcinamy, uważamy, że przewidywalność jest cechą czy charakterystyką pozytywną. Miarą, która powinna dążyć też do pewnych wartości. Zespół przewidywalny to taki, który dostarcza to, co planuje, a nie dostarcza tyle, ile zazwyczaj dostarcza. Nawet jeśli zazwyczaj dostarcza bardzo mało. Zespół, który przewidywalnie dostarcza mało, to jest dla nas zespół nieprzewidywalny, a nie przewidywalny w jakimś dziwnym znaczeniu.

Jacek: To prowadzi nas do pytania, w jaki sposób możemy przeżyć przewidywalność. Ogólny wzór jest bardzo prosty. W dużym uproszczeniu jest to stosunek tego, co zostało faktycznie zrealizowane w konkretnym Sprincie czy w konkretnej iteracji w stosunku do tego, co było zaplanowane. Najczęściej jest to wyrażone po prostu w procentach.

Kuba: Natomiast w szczegółach już może być trochę bogato. Różne zespoły uwzględniają do tego wzoru różne składowe elementy. Najprościej, gdy po prostu bierze się wszystko to, co zespół realizuje, niezależnie od tego, jakie typy pracy, jakie typy elementów planów wchodzą w skład danego Sprintu właśnie czy iteracji. Ale wiemy też i obserwujemy, i czasem ma to sens, że są zespoły, które liczą na przykład tylko historyjki użytkownika, storki, czy jakkolwiek to się w danym zespole nazywa. Czasem ficzery, czasem jakieś wyłącznie prace rozwojowe. Inne zespoły uwzględniają zadania czy jakiś rodzaj subtasków, jakaś praca techniczna do wykonania tego, co jest potrzebne do zrobienia w danym Sprincie. Kontrowersje mogą się zaczynać gdzieś w sferze tego, gdy się zaczyna liczyć do przewidywalności zaplanowane rozwiązania błędów, które wiemy, że istnieją, gdy zaczyna się Sprint, ale jest plan w zespole, żeby je rozwiązać. No i kontrowersją mogą być też zadania utrzymaniowe, czyli jakieś zadania powtarzalne, które z góry wiadomo, że trzeba zrealizować, no i choćby nie wiadomo, co się działo, to one po prostu faktycznie są częścią pracy w Sprincie. W ewentualnej kontrowersji głębiej się nie chcemy zagłębiać. Tutaj tylko jakby sygnalizuje, że jest temat, jakie typy pracy uwzględniać w mierze przewidywalności. No moim zdaniem jest tu temat do przemyślenia i bardzo świadomego zaplanowania czy do doprecyzowania, co jest uwzględnione we wzorze dla Twojego zespołu.

Jacek: Może to jest dobry czas na taki prosty, namacalny przykład. Jeżeli zespół planował dostarczyć 10 elementów, nazwijmy to bardzo ogólnie, i dostarczył tylko dwa elementy, no to dla nas, patrząc na ten wzór przewidywalność, to jest 20%. Jeżeli planował dostarczyć 10, a dostarczył 5, no to przewidywalność jest 50%, natomiast jeśli planował dostarczyć 10, a dostarczył 12, to przewidywalność wynosi 120%. Tak więc przewidywalność jest miarą, w której ta wartość oczekiwana raczej jest pewnym zakresem. Takim dla nas powiedzmy akceptowalnym punktem do rozpoczęcia rozmowy, to jest przewidywalność między 80 a 120%. I bardziej chodzi nam o przebywanie w tym zakresie, niż osiąganie jakiegoś konkretnego, precyzyjnego wyniku. W szczególności powtarzalne osiąganie 100% może oczywiście wskazywać na to, że no ta miara być może za bardzo jest traktowana jako jakiś taki punkt do osiągnięcia. Z kolei o tym zakresie, który można nazwać, że jest powiedzmy zdrowy, można myśleć tak jak na przykład o wskaźnikach, kiedy idziemy na badanie krwi. Dostajemy wylistowaną listę, dostajemy poukładaną listę wyników i najczęściej jesteśmy w stanie znaleźć informacje, czy ta konkretna wartość zbadania jest w normie, czy mieści się w jakimś tam spodziewanym zakresie. I bardzo podobnie, właściwie można powiedzieć, wręcz identycznie działa to w przypadku przewidywalności.

Kuba: Jeśli chodzi o przewidywalność, warto też wspomnieć to, jak narzędziowo można to mierzyć, jak można to liczyć, czyli jak konkretnie w narzędziu, jakim sposobem to zrealizować. Jest kilka opcji, wymienimy cztery.

Jacek: Tak, pierwsze narzędzie takie, no, najczęściej nadal spotykane przez nas w organizacjach, to jest JIRA. Należałoby się skierować do sekcji raportów i znaleźć tam w wersji anglojęzycznej Velocity Chart i na tym wykresie oprócz tej informacji, ile faktycznie zespół zrealizował, czyli jaka jest prędkość zespołu, no, można również znaleźć tę informację o tym, ile na dany Sprint zostało zaplanowane. Te dane, te wykresy powinny się właściwie same wyświetlić, jeśli tylko przestrzegasz jakiejś takiej podstawowej higieny pracy w JIRA. To znaczy faktycznie uruchamiane są Sprinty. We właściwych momentach takich prawdziwych, kiedy zaczyna się Sprint, to ten Sprint jest startowany, powinien też być zamykany faktycznie wtedy, kiedy Sprint się kończy. Sprint powinien zawierać w sobie tę faktycznie wykonywaną pracę. Jak również pewna taka otoczka dotycząca tego boardu, na którym się znajdujemy, czy projektu, który realizujemy, te rzeczy też powinny być poprawnie skonfigurowane, no i wtedy można powiedzieć, że ten wykres dostajemy z pudełka. Właściwie nic nie musimy dodatkowego zrobić, żeby móc zobaczyć sobie historycznie, jak ta przewidywalność się w naszym zespole układała.

Kuba: Drugą opcją narzędziową jest po prostu Excel. W porównaniu do JIRA, Excel stanie się, czy jest o wiele bardziej elastyczny, co prawda nie budują się dane same, jak w JIRA. Jeśli dobrze zachować tą dyscyplinę, o której mówi Jacek, no to JIRA liczy to sama, no w Excelu siłą rzeczy, ktoś odpowiedzialny za proces, albo członek zespołu, albo jakiś jego rodzaj lidera, po prostu musi te dane do tego Excela wprowadzić. Pamiętać o tym, żeby je przepisać, żeby złapać te dane historyczne bazowe i też pewnie w odpowiednie formuły wprowadzić te dane, żeby pokazały pewien wynik. Jest to oczywiście praca trochę ręczna, ale za to po drugiej stronie, zwłaszcza gdyby zespół miał jakąś bardziej skomplikowaną sytuację, albo bardziej wysublimowane warunki, co uwzględniać, czego nie uwzględniać, no to może się okazać, że ten Excel jest bardziej wiarygodny i pod większą kontrolą, niż narzędzia, które biorą po prostu wynik jakiegoś filtru lub nie są tak dobrze prowadzone.

Jacek: Innymi narzędziami mogą być wszelkiego rodzaju narzędzia, które pomagają nam wizualizować pracę i pewne koncepcje z nią związaną. Czyli z jednej strony w warunkach online’owych to może być jakiś Mural czy Miro. W warunkach stacjonarnych to może być tablica, flipchart czy nawet wręcz kartka papieru. Tak naprawdę istotne jest, żeby te dane się znalazły w tych miejscach, wokół których będziemy się skupiać jako zespół. Na bazie moich doświadczeń bardzo często zespoły pracujące online dokonują refleksji na przykład na Muralu. No i w takim przypadku śledzenie tych informacji procesowych w kontekście tego odcinka, mówię tutaj w szczególności o przewidywalności, może być takim naturalnym miejscem, na które i tak spojrzymy w momencie, kiedy będziemy realizować cotygodniową czy co dwutygodniową refleksję. Tak więc posiadając komplet informacji w miejscu, do którego i tak rutynowo zaglądamy, drastycznie zwiększa szanse, że na te dane spojrzymy i zastanowimy się co z tych informacji, które posiadamy płynie, jakie wnioski do zespołu.

Kuba: Ostatnią opcją, którą wymienimy, jeśli chodzi o narzędziowe pokazanie, mierzenie i uwidacznianie przewidywalności to są narzędzia BI-owe. W kilku organizacjach niezależnie od siebie widziałem taki efekt podłączenia bazy danych. Najczęściej pod spodem była jakaś JIRA, może Azure DevOps, albo tego typu narzędzia do mierzenia zadań, pokazywania tych zadań, kończenia ich. Dane surowe z takich narzędzi można przerzucić do narzędzi BI-owych. Czy to jest Power BI, czy to jest Tablo, czy to jest jeszcze coś innego. Kilka narzędzi różnie popularnych w różnych organizacjach. Oczywiście wymaga to już pewnych konkretnych kompetencji, żeby to wszystko podłączyć, żeby też być może odpowiednio skonfigurować raporty. No potencjalnie po stronie nagrody jest dosyć atrakcyjny sposób wizualizacji, być może sposób też jakiejś konfiguracji dodatkowego filtrowania dodatkowego, może dokładania kolejnych danych. W kontekście dużej organizacji wartością w sobie samo może być też pokazanie na jednym dash-boardzie wyników wielu zespołów, czy może pewien rodzaj standaryzacji pomiędzy zespołami, jakie aspekty są tam odpowiednio uwzględniane. Potencjalnie nagroda wielka, no ale tak jak wspomniałem też potencjalnie pewien koszt. Jeśli ma się te kompetencje w zespole, to może ten koszt jest siłą rzeczy pomijalny, a czasami warto to zainwestować, żeby dostać wartościowe widoki, czy wartościowe mierniki.

Kuba: Ostatnią opcją, którą wymienimy, jeśli chodzi o narzędziowe pokazanie, mierzenie i uwidacznianie przewidywalności to są narzędzia BI-owe. W kilku organizacjach niezależnie od siebie widziałem taki efekt podłączenia bazy danych. Najczęściej pod spodem była jakaś JIRA, może Azure DevOps, albo tego typu narzędzia do mierzenia zadań, pokazywania tych zadań, kończenia ich. Dane surowe z takich narzędzi można przerzucić do narzędzi BI-owych. Czy to jest Power BI, czy to jest Tablo, czy to jest jeszcze coś innego? Kilka narzędzi różnie popularnych w różnych organizacjach. Oczywiście wymaga to już pewnych konkretnych kompetencji, żeby to wszystko podłączyć, żeby też być może odpowiednio skonfigurować raporty. No potencjalnie po stronie nagrody jest dosyć atrakcyjny sposób wizualizacji, być może sposób też jakiejś konfiguracji dodatkowego filtrowania dodatkowego, może dokładania kolejnych danych. W kontekście dużej organizacji wartością w sobie samo może być też pokazanie na jednym dash-boardzie wyników wielu zespołów, czy może pewien rodzaj standaryzacji pomiędzy zespołami, jakie aspekty są tam odpowiednio uwzględniane. Potencjalnie nagroda wielka, no ale tak jak wspomniałem też potencjalnie pewien koszt. Jeśli ma się te kompetencje w zespole, to może ten koszt jest siłą rzeczy pomijalny, a czasami warto to zainwestować, żeby dostać wartościowe widoki, czy wartościowe mierniki.

Kuba: I zanim przejdziemy do następnego rozdziału, przypominamy, że jeżeli chcesz pogłębić wiedzę, jeszcze bardziej niż robimy to w podcaście, to znajdziesz nasze płatne produkty na stronie porzadnyagile.pl/sklep.

Jacek: Przechodzimy do kolejnej sekcji dzisiejszego odcinka, czyli kilka wskazówek na temat tego, jak stosować miary przewidywalności w praktyce.

Kuba: Pierwsza rzecz, od której chcę zacząć, to uwzględnij stopień innowacyjności zespołu. Przewidywalność jako miara w typowym zespole wytwórczym powinna być mierzona. To jest też cecha, którą taki zespół powinien posiadać. Natomiast mamy w swoim doświadczeniu kilka przykładów takich zespołów, które są naprawdę mocno innowacyjne, robią zadania takie mocno polegające na jakimś rodzaju research and development, jakimś badaniu, jakimś odkrywaniu, w takim stopniu innowacyjności naprawdę dużym. Te zespoły siłą rzeczy z racji na taką dużą chaotyczność czy dużą złożoność swojej pracy badawczej, po prostu tej przewidywalności osiągnąć nie za bardzo mogą, w takim znaczeniu, o jakim mówimy w tym odcinku. Dlatego tutaj bierzemy taką poprawkę, może taką dokładamy gwiazdkę do przewidywalności. W wybranej organizacji to niektóre zespoły będą siłą rzeczy nieprzewidywalne, w których firmach może w ogóle wszystkie, bo taka jest natura produktu czy branży, w której się działa, więc może wziąć warto poprawkę na to, że nie we wszystkich zespołach, nie we wszystkich firmach ta przewidywalność, o której dzisiaj powiedzieliśmy i jeszcze będziemy mówić, jest adekwatna, czy jest miarą, na którą warto spoglądać.

Jacek: Jednocześnie przy tej okazji warto zwrócić uwagę na taki pewien ewenement, który obserwujemy z Kubą, że wiele zespołów wpada w poczucie, że są właśnie takim bardzo wyjątkowym i innowacyjnym zespołem, który ze względu na naturę swojej pracy nie jest w stanie pracować w przewidywalny sposób i nasze doświadczenie jest takie, że raczej nie do końca jest tak na takiej zasadzie, że faktycznie takie zespoły spotykamy, ale tych zespołów jest zdecydowania mniejszość. Nawet jeśli to faktycznie jest ten research, o którym wspominał Kuba, takie działania też można planować, można dzielić je na mniejsze kroki, bardzo precyzyjnie sobie określać kryteria akceptacji. I też w miarę w uporządkowany sposób decydować, czy to, co zaplanowaliśmy sobie zrobić, niekoniecznie te uzyskane rezultaty, ale tę pracę wykonaną, którą planowaliśmy, jesteśmy w stanie zaplanować. Raczej większość zespołów tę pracę, którą wykonuje ona, ma najczęściej jednak charakter taki, że jesteśmy w stanie przewidzieć, co będziemy realizować. Więc tutaj chcemy z Kubą wyraźnie zaznaczyć taką potencjalną pułapkę, żeby dokonać faktycznej refleksji, czy rzeczywiście ta nasza praca nosi znamiona takiej absolutnie niezarządzalnej, nieprzewidywalnej, czy tylko wpadliśmy w tę pułapkę, że tak o tej pracy myślimy.

Jacek: Druga wskazówka, świadomie wybierz zmienne do wzoru. Wspomnieliśmy, jak taki wzór mógłby wyglądać, wspomnieliśmy, w jakiej jednostce wyrażony jest wynik. Taką główną wątpliwością osób, które podchodzą do tematu przewidywalności, jest wybór tego, czy powinniśmy patrzeć na konkretne elementy, które posiadamy jako zakres w danym konkretnym Sprincie, czy iteracji, czy raczej powinniśmy patrzeć na sumę story pointów I o ile historycznie pierwsze próby mierzenia się z przewidywalnością kierowały nas z Kubą w stronę story pointów, no to dzisiaj zdecydowanie jest nam bliżej do tego, żeby raczej patrzeć na tę liczbę elementów, które bierzemy do Sprintu. Konkretnie w Jirze można sobie przestawić wykres, ustawić go na to, żeby pokazywał issue count, czyli żeby po prostu policzył nam tę liczbę elementów, którą mamy w Sprincie. No i generalnie zbliża nas to do myślenia bardziej o patrzeniu i mierzeniu przepustowości i przewidywalności na tej bazie, niż na takie klasyczne Velocity, które najczęściej wyrażane jest jako suma story pointów zaplanowanych na konkretny Sprint.

Kuba: Dlaczego poświęcamy na to czas w tym nagraniu? Bo wiele zespołów poświęca niepotrzebnie czas na przykład szczegółowy wycenianie, bo inaczej nie będzie pewien element uwzględniony we wzorze, a po wszystkim zwłaszcza też niezależne próby to potwierdzają w wielu zespołach, w wielu firmach korelacja między ilością skończonych elementów a story pointami zakończonymi jest na tyle silna, że w zasadzie nie ma potrzeby wkładać dodatkowej energii w to, żeby nawyceniać wszystkie prace. Zwłaszcza jeśli ma to prowadzić do, no naszym zdaniem, absurdów takich jak wycenianie błędów czy wycenianie jakichś zadań technicznych, tylko po to, żeby one się później ładnie w słupki sumowały. Może się okazać, że prosta suma ilości elementów jakichkolwiek, które uwzględniamy w takim predictability po prostu są do wzięcia i tyle, to jest dosyć łatwe, łatwo mechanicznie wyliczyć taki wzór i po prostu niepotrzebnie nie wkładać dodatkowej energii w coś, co nie wniesie dodatkowej wartości. I zaakcentuję, czy może tak trochę refrenem powtórzę to, co powiedział Jacek, niestety domyślnie Jira pokazuje, a Jira jest też najbardziej popularnym narzędziem z tego, co widzimy, pokazuje właśnie po story pointach, co może oznaczać, że nie uwzględnia rzeczy niewycenionych do tego typu wzorów na przewidywalność, no i z drugiej strony właśnie trochę miesza w przewidywalności, jeśli zespół cierpi na zadania przechodzące między Sprintami. Jeśli zespół właśnie uwzględnia w swoich działaniach również elementy, które są niewyceniane, więc tutaj domyślny sposób pokazania przewidywalności mierzonej w story pointach może być pewną pułapką, stąd wskazówka świadomie wybierz zmienne do wzoru.

Kuba: Trzecia wskazówka to traktuj przewidywalność jako wewnętrzny kompas zespołu. Dużo nieszczęścia dzieje się w organizacjach, w których zostaje się celem. Jacek już to lekko zaznaczył, ja to wzmocnię. Są organizacje, które wręcz żądają, domagają się, zostawiają w celach rocznych, uzależniają premię od tego, czy zespół będzie przewidywalny, ustawiając też konkretne oczekiwane wartości. Najczęściej spotykam, że wartością oczekiwaną jest dokładnie 100%, czyli róbcie dokładnie tyle, ile planujecie, to poprowadzi do pewnych pułapek, ale znam też organizację, w której oczekiwana wartość przewidywalności to jest nie powinna przekraczać powiedzmy 80%. Czyli przewidywalny zespół to taki, który w przewidywalny sposób zawsze trochę nie dowozi. Też nie najszczęśliwszy pomysł. Więc tutaj mocno opieramy się na pomyśle, że przewidywalność to jest raczej miara wewnętrzna do mierzenia procesu przez zespół, do traktowania go jako punkt odniesienia przy usprawnianiu się, do myślenia o nim w czasie planowania, myślenia o nim w czasie Retrospektyw, myślenia o nim w jakimś tam dłuższym horyzoncie, ale na pewno nie jako sposób czy podstawa do tego, żeby dostać nagrodę albo karę, bo siłą rzeczy, zresztą jak każda inna miara tego typu, może się to łatwo przeinaczyć czy wręcz wypaczyć, stać się celem samym w sobie zamiast wiarygodną podstawą do usprawniania.

Jacek: I czwarta porada, nie polegaj wyłącznie na przewidywalności. Tutaj zdecydowanie rekomendujemy, żeby przewidywalność nie była jedyną miarą procesu, którą zespół monitoruje. Dobrze jest od czegoś zacząć, ale zdecydowanie nie spoczywałbym tutaj na laurach. Przykładowo jednocześnie warto spojrzeć na throughput, czyli na przepustowość. Można do tego dołożyć sobie jakąś miarę jakości, można dołożyć jakąś miarę wartości biznesowej. To, co jest dla nas w danym momencie istotne i to, na co chcemy zwracać uwagę i wtedy patrzeć na pewien zestaw miar. Patrzeć jak one się wzajemnie zachowują. Może być tak, że poprawa jednej konkretnej miary może pogarszać wyniki w drugiej. Warto na to zwrócić uwagę i tak sobie skonfigurować te miary, żebyśmy mieli taki dosyć pełny obraz tego, jaka jest kondycja naszego zespołu i jego otoczenia.

Kuba: I ostatni rozdział. Jak poprawiać przewidywalność zespołu? Ten rozdział będzie krótki, bo tak naprawdę to, co poprawia przewidywalność było tematem masy z poprzednich odcinków. My w zasadzie sami się z Jackiem zaśmialiśmy, że tak późno z naszej strony odcinek o przewidywalności w czasie, gdy mnóstwo praktyk poprawy przewidywalności już było przez nas poruszonych. Więc tutaj nie będziemy pogłębiać tematu, co dokładnie oznacza dana praktyka. Raczej potraktuj tę zawartość tego jako pewnego rodzaju spis treści czy nasze rekomendowane tak dokładnie osiem praktyk poprawy przewidywalności. Jeśli które z nich brzmi dla Ciebie intrygująco albo coś, czego jeszcze nie stosujesz, to po prostu odsyłamy Cię do materiałów, które też zamieszczamy w opisie odcinka. 

Jacek: Ok, czyli jakie praktyki zastosować, żeby poprawić przewidywalność zespołu?

Kuba: Przede wszystkim zacznij kończyć, skończ zaczynać. Stosuj krótkie Sprinty. Wzmacniaj odpowiedzialność zespołu za produkt i dziel pracę na mniejsze kawałki.

Jacek: Dodatkowo planuj zespołowo, zarządzaj zależnościami zewnętrznymi, traktuj codzienny stand-up jako bezpiecznik i usprawniaj się w oparciu o miary dostarczania produktu.

Kuba: Wszystkie wymienione koncepcje, tak jak powiedziałem, znajdziesz w naszych starszych odcinkach, które linkujemy w opisie odcinka i na stronie tego odcinka porzadnyagile.pl/140

Jacek: Przewidywalność to miara i jednocześnie pożądana cecha zespołu, który realizuje zakres pracy, jaki sobie zaplanował na Sprint. Najczęściej przewidywalność podaje się w procentach jako stosunek liczby elementów faktycznie zrealizowanych do liczby elementów pierwotnie zaplanowanych.

Kuba: Przewidywalność jest miarą, której wartość oczekiwana jest zakresem. Naszym zdaniem powinna mieścić się zazwyczaj między 80 a 120 procent. Istnieje szereg praktyk wspierających przewidywalność zespołu i zachęcamy do ich zastosowania w Twoim zespole.

Jacek: Przyczyny braku przewidywalności w danym zespole mogą oczywiście być różne. Jako doświadczenie eksperci dołączamy do zespołu lub wskazanej części firmy i jasno je wskazujemy wraz z rekomendacjami sposobów, aby zmienić proces wytwórczy tak, by przewidywalność faktycznie rosła. Sprawdź naszą propozycję na stronie 202procent.pl/diagnoza.

Kuba: A notatki do tego odcinka, artykuł, transkrypcję, wspomniane linki do innych rekomendowanych materiałów oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/140.

Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek. I do usłyszenia wkrótce.

________

To była pełna transkrypcja odcinka podcastu Porządny Agile. Dziękujemy za lekturę!

Ostatnia aktualizacja: 12 stycznia 2026

Być może często słyszysz w zespole „Niech ktoś to podzieli” i nie bardzo wiadomo, kto dokładnie powinien się za to zabrać. To jedno z częstych wyzwań w dzieleniu projektów na mniejsze części. Omawiamy też jeszcze kilka innych problemów z tym związanych. Dostaniesz od nas po kilka gotowych rozwiązań do każdego z nich. Odciąży to Twój zespół i sprawi, że dzielenie pracy stanie się naturalnym elementem codziennego działania.

Spis treści

• Problem z dobrym zrozumieniem celu projektu
• Presja biznesu na wdrożenie całości
• Wyważenie perspektywy technologii i biznesu przy podziale
• Czasochłonność procesu dzielenia
• Mentalność „Niech ktoś podzieli”
• FAQ: Wyzwania w dzieleniu projektów na mniejsze części
• Transkrypcja podcastu „Wyzwania w dzieleniu projektów na mniejsze części„

Naszym zdaniem jest to częsty bloker, który sprawia, że bardzo trudno przystąpić do sensownego podziału projektu czy inicjatywy, jeżeli tak naprawdę nie rozumiemy, co chcemy uzyskać. Oczywiście, bez zrozumienia celu możemy mechanicznie spróbować podzielić projekt na mniejsze części, ale prawdziwa różnica pojawia się wtedy, gdy bardzo dobrze rozumiemy cel. W takiej sytuacji otwierają się możliwości zrealizowania pewnych rzeczy w znacznie mądrzejszy sposób, zamiast patrzeć na projekt bez zrozumienia, co tak naprawdę chcielibyśmy tym projektem uzyskać. Zrozumienie celu jest tutaj fundamentalnym wstępem do dobrego podziału, dlatego pierwsza porada może wydawać się oczywista.

Można to osiągnąć na kilka sposobów. Jednym z nich jest dobre spotkanie typu kick-off, czyli otwarcie inicjatywy, projektu, zmiany produktowej lub kolejnego etapu rozwoju produktu.

Nie zakładaj, że inni wiedzą to samo, co ty. Zadbaj o klarowny wstęp, krótkie exposé i odpowiednie wprowadzenie zespołu w dotychczas zebrane informacje oraz kontekst biznesowy, który uzasadnia realizację danego przedsięwzięcia. Takie przygotowania do kick-offu nie pójdą na marne, ponieważ zrozumienie celu można wzmacniać również przez powtarzanie tych informacji. Warto zatem wypracować praktykę regularnego wracania do celu przy każdej nadarzającej się okazji. Mogą to być Przeglądy Sprintów, jeśli stosujesz Scruma, a także demo, spotkania projektowe, warsztaty lub podsumowania prac. Każde z tych miejsc, w których zbiera się zespół lub jego wyraźna część, stanowi okazję do przypomnienia, jaki jest cel i na czym polega istota aktualnie realizowanych działań. Warto przyjąć założenie, że wielokrotne powtarzanie – także w różnych formach – pomoże utrwalić cel i umożliwi jego trwalsze osadzenie w zespole.

Dzięki temu, gdy nadejdzie moment związany z podziałem pracy, zarówno na początku, jak i w dalszych etapach, cel będzie pamiętany, łatwy do przywołania i na tyle zrozumiały, że stanie się dla zespołu oczywistością.

Warto rozważyć takie techniki jak impact mapping, podejście golden circle, product vision board, OKR-y czy opportunity solution tree. Jeśli te nazwy są ci obecnie mało znane, możesz je łatwo wyszukać w internecie. Mamy doświadczenie z większością tych narzędzi i możemy potwierdzić, że nie tylko wspierają zrozumienie, po co realizowane są poszczególne działania, lecz także są zazwyczaj narzędziami wizualnymi. Praca z nimi to nie tylko rozmowa, to również element wizualny, który znacząco poprawia i zwiększa zrozumienie tego, co stanowi istotę danej zmiany.

W sytuacji, gdy zespół przygotowuje się do sesji dzielenia, a zespół nie korzystał wcześniej z tych narzędzi, warto sięgnąć po jedno z nich jako rozgrzewkę lub wstęp. Jeśli zespół pracował z nimi wcześniej, dobrze wrócić do nich na początku sesji.

Trzecia praktyka polega na jak najczęstszym sprawdzaniu, czy zespół rozumie cel. Nie tylko osoba zarządzająca projektem, lider produktu czy manager zespołu może komunikować cel, bo możesz poprosić uczestników, aby w formie ćwiczenia lub krótkiej wypowiedzi swoimi słowami opisali, jaki jest cel danej inicjatywy. Dzięki temu sprawdzisz, czy cel jest zrozumiały, a jednocześnie wprowadzisz element, który aktywizuje lub rozgrzewa zespół, i wykorzystasz różnorodność zespołu, różne perspektywy i specjalizacje, dzięki którym uczestnicy patrzą na sprawy w inny sposób. Parafraza celu lub próba jego opisania z różnych perspektyw poprawia jakość zrozumienia. Dlatego regularnie sprawdzaj zrozumienie, na przykład prosząc osoby z zespołu o parafrazę celu.

Mamy na myśli wdrożenie całego projektu, całego zakresu, całej inicjatywy albo czasami pełnej funkcji w produkcie. Taka sytuacja może wywołać niechęć lub poczucie bezsensu dzielenia pracy. Pojawia się wtedy pytanie: po co dzielić, skoro na końcu i tak trzeba wdrożyć całość zgodnie z pierwotną definicją, a presja biznesu lub managementu może wywołać wrażenie, że podzielenie pracy to proszenie się o kłopoty, bo strona wywierająca presję może uznać, że zespół próbuje wycofać się z części zakresu. To może wywołać różne negatywne emocje i sprawić, że zespół nie chce podjąć się dzielenia pracy.

Warto założyć, że nie wszyscy znają te korzyści ani ich wcześniej nie doświadczyli. Mamy na myśli przede wszystkim wczesne ograniczanie ryzyk biznesowych. Dzięki temu możesz wcześniej sprawdzić, czy proponowane rozwiązanie odpowiada na potrzebę rynkową i czy jest poprawnie zaprojektowane. Możesz również ograniczyć ryzyka technologiczne, na przykład upewniając się, że zespół potrafi pracować z wybraną technologią. A także ryzyka społeczne, czy osoby odpowiedzialne za implementację potrafią ze sobą skutecznie współpracować. Ryzyka to jedna strona tej sytuacji, a druga strona dotyczy dostarczenia najważniejszej wartości, esencji zmiany, możliwie jak najwcześniej.

Warto uruchomić empatię i wczuć się w perspektywę interesariuszy. To, co z perspektywy zespołu wykonawczego wygląda jak niezrozumiała albo nawet nieracjonalna presja, może wynikać z unikalnych doświadczeń konkretnej osoby, managera lub grupy w organizacji. Możesz tego nie dostrzegać, a mimo to warto to uwzględnić. Co to oznacza w praktyce? Odniesiemy się do przykładu z jednej z firm, z którą współpracowaliśmy. Zespół odpowiedzialny za operacje, na przykład za działania posprzedażowe i obsługę klienta, obawiał się, że ich narzędzia zostaną uznane za nieistotne albo w ogóle nie powstaną w ramach projektu, dlatego podchodzili do negocjacji twardo i sceptycznie oraz nie chcieli dzielić zgłoszonych wymagań czy potrzeb narzędziowych. Wynikało to z doświadczeń z poprzednich projektów, w których pod presją czasu narzędzia dla nich w ogóle nie powstawały, a zespół musiał obsługiwać klientów za pomocą Excela i ręcznie pisanych maili, ponieważ system nie obejmował ich potrzeb, mimo że pierwotnie był tak planowany. Dlatego warto uwzględnić tę perspektywę i zrozumieć obawy interesariuszy.

Innym przykładem obawy jest sytuacja, w której ktoś obiecał komuś bardzo precyzyjny i często rozbudowany zakres. Często te osoby nie mówią o tym wprost albo trudno im przyznać, że złożyły taką obietnicę, dlatego z oporem podchodzą do pomysłu podzielenia tej całości na mniejsze części. Obawiają się, że podział może stać się pretekstem do usunięcia części zakresu.

W części organizacji pojawia się pęd do realizowania dużych i spektakularnych projektów. W takim kontekście idea dzielenia może wydawać się sprzeczna z tym podejściem. Wynika to z potrzeby tworzenia dużych projektów strategicznych, spektakularnych premier oraz zdobywania nagród za przełomowe odkrycia lub innowacje. Warto uwzględnić tę perspektywę, bo ktoś może przygotowywać się na konferencję dotyczącą innowacji w bankowości i chce opowiedzieć na scenie o dużych, efektownych planach, na przykład o nowych implementacjach opartych na AI. To nie oznacza, że spektakularnych projektów nie da się podzielić, ale warto uwzględnić kontekst i zadbać o komunikację, ponieważ jedno nie wyklucza drugiego. W najgorszym razie wdrożenie może odbyć się jako spektakularna premiera, ale wciąż warto dzielić pracę wcześniej i dostarczać ją etapami, nawet jeśli część rezultatów nie trafi od razu do publikacji.

W skrócie: podział pracy na mniejsze części nie oznacza automatycznie rezygnacji z wdrożenia całości. Jednocześnie widzimy tu pewną kontrowersję, bo możesz mieć doświadczenia z obecnej lub poprzednich firm, w których podział pracy prowadził do wdrożenia tylko części rozwiązania z powodu ograniczeń czasowych. Zdarza się, że ta część jest satysfakcjonująca, a elementy, których nie udało się zrobić wcześniej, nie trafiają już do realizacji, bo organizacja przechodzi do kolejnych koncepcji. W założeniu nie musi to wyglądać w ten sposób, ale rozumiemy, że wcześniejsze doświadczenia mogą skłaniać do ostrożnego podejścia do tej porady.

W szczegółach pojawia się druga kontrowersja – koncepcja potrzebnej całości. Może się okazać, że ktoś kurczowo trzyma się wyobrażenia całości zakresu lub rozwiązania, które powstało na bardzo wczesnym etapie. Czasami niektórzy trzymają się tej wizji, zakładając, że od początku wiedzieli, czego potrzeba, i że cały pierwotny zakres odpowiada dokładnie na potrzeby rynku lub klienta. To prowadzi z powrotem do kwestii ryzyk biznesowych. Zbyt wiele decyzji podjętych na zbyt wczesnym etapie może tworzyć złudzenie, że wiadomo, czego naprawdę potrzeba. To dlatego ta rada wiąże się z podwójną kontrowersją, ale na bardzo wczesnym etapie bardziej dyplomatyczne może być stwierdzenie: „Podzielimy na kawałki i wdrożymy to, co okaże się potrzebną całością”, przy jednoczesnym założeniu, że potrzebna całość nie musi oznaczać pełnego zakresu rozumianego na dziś, bo dopiero czas pokaże, co dokładnie stanie się tym, co warto wdrożyć.

Mamy na myśli sytuację, którą można zobaczyć po dwóch stronach tej samej osi. Z jednej strony podział powstaje wyłącznie w izolacji biznesowej, bez udziału osób technologicznych, co sprawia, że zespół traci ważną perspektywę wykonalności, a także dostęp do opcji proponowanych przez osoby technologiczne, które widzą rozwiązania spoza perspektywy biznesowej. Z drugiej strony pojawia się próba stworzenia podziału wyłącznie technologicznego, która może doprowadzić do sensownego rozbicia pracy na mniejsze elementy, ale jeśli zespół nie rozumie aspektów biznesowych albo nie może dopytać o ich konsekwencje, na przykład o biznesowy wpływ rozwiązania, taki podział będzie jedynie częściowy, i na pewno nie stanie się podziałem optymalnym.

To podejście wykracza poza dwie skrajne perspektywy wspomniane wcześniej, bo możesz potrzebować również perspektywy prawnej, perspektywy user experience, więc liczba uczestników warsztatów lub aktywności związanych z podziałem będzie zależeć od kontekstu i specyfiki produktu. Zapraszając osoby, warto od razu wyjaśnić, po co ktoś ma się pojawić, z jaką wiedzą przychodzi i jaką perspektywę ma reprezentować. Często słyszymy, że zaproszono przedstawicieli IT, architektów czy senior developerów, ale podczas spotkania te osoby prawie się nie odzywały, nie zabierały głosu i nie wnosiły swojej perspektywy, nawet gdy ktoś je o to prosił. Problem może wynikać z tego, że zaproszono te osoby „bo tak trzeba”, „bo wypada”, podczas gdy te osoby nie wiedziały, po co w ogóle pojawiły się na spotkaniu. Dlatego osoba zapraszająca, niezależnie od roli, odgrywa kluczową rolę, ponieważ powinna jasno wyjaśnić uczestnikom, czego od nich oczekuje, w jakiej roli mają wystąpić i jakiego wkładu oczekuje od każdej osoby. Dzięki temu nikt nie będzie się bał, wycofywał ani powstrzymywał z wypowiedzią, szczególnie że podczas dzielenia pracy mogą pojawić się tarcia. Ktoś może zaproponować podział korzystny biznesowo, ale niepasujący technologicznie, inny pomysł może wyglądać dobrze z perspektywy biznesu i technologii, ale straci sens z punktu widzenia prawa, albo bezpieczeństwa. Każdy powinien rozumieć, dlaczego uczestniczy w warsztacie lub spotkaniu, i jaką rolę pełni w tych aktywnościach.

Druga wskazówka polega na tym, aby ustalić facylitatora i oczekiwać od tej osoby zadbania o każdą perspektywę. Aby wszystkie dostępne perspektywy wybrzmiały równomiernie, zgodnie z tym, o czym wspomniano wcześniej, a także aby rozmowy miały właściwą głębokość. Na przykład facylitator powinien dbać o to, aby zespół nie schodził w bardzo niskopoziomowe detale technologiczne, ponieważ może to wywołać u osób nietechnicznych wrażenie, że spotkanie jest źle poprowadzone. Kto może poprowadzić takie spotkanie? Może to zrobić analityk, lead developer albo architekt. Nazwa roli nie ma tutaj większego znaczenia. Ważne, aby ta osoba była dobrze przygotowana do poprowadzenia warsztatu, a czasem całej serii warsztatów, ponieważ nie zawsze jest to jednorazowe działanie, oraz aby facylitator dbał o równomierne uwzględnianie wszystkich perspektyw, zamiast reprezentować jedynie własny punkt widzenia. W przeciwnym razie spotkanie nie stworzy dobrej reputacji dla podobnych inicjatyw w przyszłości.

Mamy na myśli przede wszystkim Story Mapping, technikę, którą lubimy, której używamy, często rekomendujemy i stosujemy w pracy biznesowej oraz przy tworzeniu podcastu. Story Mapping jest na tyle powszechną techniką, że wielu odbiorców powinno go już znać, ale jeśli nadal go nie znasz, zdecydowanie zachęcamy, aby się z nim zapoznać lub wziąć udział w warsztacie, w którym się go stosuje. Story Mapping świetnie sprawdza się w wizualizacji zakresu i dostępnych opcji, oraz pomaga zrozumieć, czym jest całe przedsięwzięcie i na jakie mniejsze elementy można je podzielić. Elementy te najczęściej bazują na perspektywie użytkownika, dzięki czemu pozostają czytelne zarówno dla biznesu, jak i dla osób odpowiedzialnych za implementację. Obiecująco prezentuje się także zastosowanie Event Stormingu. Jeśli facilitator dobrze poprowadzi takie spotkanie, Event Storming może przynieść rezultat podobny do Story Mappingu, choć działa według nieco innych zasad.

Często, gdy przekonujemy zespół, że warto dzielić pracę, słyszymy argument, że dzielenie wymaga dodatkowej pracy, ktoś musi to zrobić i wprowadzić do systemu, a pojawi się wiele elementów, którymi trzeba później zarządzać i je koordynować. Zgadzamy się, że wymaga to dodatkowego wysiłku, ale dla wielu zespołów i organizacji największym wyzwaniem jest to, jak właściwie zacząć. Co w takiej sytuacji rekomendujemy?

Przede wszystkim warto zmienić sposób myślenia i nie traktować dzielenia jako kosztu, lecz traktować je jako inwestycję w proces dostarczania, która pomaga zespołowi lepiej zrozumieć zakres, daje lepszą kontrolę nad postępem prac, ponieważ praca na mniejszych elementach ułatwia monitorowanie zmian, a jednocześnie zmniejsza złożoność poszczególnych kroków dużej inicjatywy. Idzie za tym również wiele korzyści technicznych, ponieważ przepływ pracy w zespole przy mniejszych elementach powinien przyspieszyć, dzięki temu, że szybciej można coś zaimplementować, szybciej przeprowadzić code review, szybciej dokonać merge’u, a ostatecznie szybciej wypuścić na środowisko produkcyjne. Zyskujemy więc wiele pozytywnych efektów, pod warunkiem, że zainwestujemy czas w podzielenie pracy na mniejsze fragmenty.

W praktyce ta inwestycja może zajmować określony czas, a część tego czasu pochłania przygotowanie lub zbędne zagłębianie się w techniki i narzędzia związane z dekompozycją. Warto, aby osoby pełniące role liderskie lub odpowiadające za proces pracy wykorzystywały każdą okazję do przygotowania i ponownego używania checklist, na przykład sposobów dzielenia pracy. To może być prosta lista metod, którymi można podzielić projekt lub element omawiany na warsztacie. Mogą to być również przygotowane szablony lub wcześniej opracowane wersje technik, o których wspominaliśmy, na przykład gotowe tablice w Miro albo elementy przygotowane do przeniesienia na flipchart czy kartki. Warto także korzystać ze schematów, które zespół już zna. Dzięki temu nie trzeba za każdym razem zastanawiać się, o co chodzi facylitatorowi, bo zespół wypracowuje z czasem gotowe ścieżki działania, które często wymagają minimalnych instrukcji i pozwalają wejść w pracę niemal automatycznie. Oczywiście instrukcje nadal powinny istnieć, ale mogą być zwięzłe i nie wymagać dodatkowych wyjaśnień, a jednocześnie powinny umożliwiać płynne wejście w zadanie. Dzięki temu zespół od razu przechodzi do pracy, bez dyskusji typu „o co chodzi?” lub „co masz na myśli?” bo wszyscy wiedzą, co oznaczają polecenia dotyczące dzielenia na elementy, te schematy są już znane i naturalne. To daje realną okazję do oszczędności czasu, o ile zespół podchodzi do tego świadomie i dzięki temu kolejne procesy dzielenia, oparte na check listach lub schematach, wymagają mniej czasu.

Gdy zespół zbuduje doświadczenie i będzie korzystał z checklist oraz narzędzi, które ułatwiają pracę, wtedy dzielenie staje się naturalne, płynne i oczywiste i przebiega w sposób sprawny. Przestaje wymagać zastanawiania się, nic nie blokuje zespołu, znika obawa dotycząca tego, jak to przeprowadzić, bo dzielenie staje się naturalną częścią pracy zespołu, czymś oczywistym, na co warto poświęcić czas. To nie wydarzy się samo, ale pierwsze, drugie i trzecie podzielenie pracy zazwyczaj przynosi wartościowe efekty, które budują w „pamięci mięśniowej” zespołu przekonanie, że warto to robić, więc z czasem pojawia się nie pytanie „czy to zrobimy”, ale „kiedy to zrobimy”, bo zespół wie, że to działanie jest potrzebne i ma sens. Zespół kojarzy również, że wykonał to wiele razy, więc zrobi to ponownie z równą łatwością, gdy pojawi się kolejna okazja lub potrzeba, aby wykorzystać te umiejętności.

Wyzwanie związane z czasochłonnością dzielenia często przecenia lub niepotrzebnie podkreśla ta grupa, która tego dzielenia nie wykonuje. Tymczasem osoby, które dzielą pracę rutynowo, traktują to jako nieodłączną część pracy, wykonują to płynnie i nie tworzą wokół tego niepotrzebnego zamieszania.

To sytuacja, w której nie wiadomo, kto właściwie powinien podjąć się dzielenia pracy. Możemy czuć, że warto byłoby podzielić pracę, ale zakładamy, że nie my powinniśmy się tym zająć. Uważamy, że powinni zrobić to „oni” albo „ktoś”. Jeśli wiele osób w organizacji myśli w ten sam sposób, unikając wzięcia odpowiedzialności za działanie, czas będzie mijał, co jest nieuniknione, i zaczniemy pracować na tym, co mamy, czyli na projekcie w obecnym stanie, bez jakiegokolwiek podziału. Jak zatem poradzić sobie z taką mentalnością?

Pierwsza praktyka, choć nie uderza w problem bezpośrednio, polega na podziale na poziomie całego portfela. Nie rozwiązuje to wprost mentalności „ktoś inny powinien podzielić”, bo w pewnym sensie sugeruje, że podział faktycznie może wykonać ktoś inny, że do zespołów wykonawczych, produktowych lub projektowych trafiają elementy o bardzo dużej skali, często już wstępnie zdefiniowane w sposób, który utrudnia ich podział. Dlatego warto na poziomie portfela, produktu, roadmapy lub całego zbioru projektów jeśli tak działa dana organizacja, rozważyć wprowadzenie podziału na wczesnym etapie, czy to jako wymóg, czy jako dobrą praktykę. Kiedy do zespołu trafi mniejszy element, mniejszy etap projektu, mniejszy fragment celu lub realizacja jednego z kluczowych aspektów inicjatywy, wtedy podział na poziomie zespołu stanie się znacznie łatwiejszy. Dlatego mentalność „niech ktoś podzieli” często wynika z tego, że zespół dostaje elementy zbyt duże i przytłaczające, a rozwiązaniem jest podział na wcześniejszym etapie, ponad poziomem zespołu, na poziomie strategicznym lub co najmniej taktycznym.

Oznacza to, że gdy przychodzi Ci do głowy sposób podziału, po prostu go komunikujesz. Skąd wynika ta propozycja? Często podczas superwizji obserwujemy, jak pracuje zespół. Pada pytanie i nikt nie odpowiada. Można wtedy odnieść wrażenie, że zespół nie ma żadnych pomysłów. Jednak gdy porozmawia się spokojnie z pojedynczymi osobami,albo gdy zastosuje się strukturę, która lepiej aktywizuje uczestników, okazuje się, że zespół ma wiele pomysłów, ale z różnych powodów nie dzieli się nimi publicznie. Proponowana zasada ma budować śmiałość w zespole. Dzięki niej zespół uprości sobie pracę – jeśli ktoś zauważy dobry sposób podziału, po prostu od razu go zgłosi. Choć brzmi to banalnie, doświadczenie pokazuje, że pojedynczy sygnał lub komentarz potrafi uruchomić wartościową zmianę w zespole. Zdecydowanie rekomendujemy umówienie się na takie proaktywne działanie.

Dzielenie powinno być wyraźnym oczekiwaniem wobec zespołu. Jeśli zespół stosuje ustaloną zasadę dzielenia, powinien być za to doceniany. Jeśli zespół jej nie stosuje, tłumaczy się stagnacją, brakiem postępów albo tym, że ryzyka projektowe się zmaterializowały, ponieważ nie podzielono pracy to powinno prowadzić do poważnej rozmowy o tym, że pojawia się realny problem, ponieważ management, niezależnie od roli, powinien wymagać, aby dzielenie pracy rzeczywiście następowało. Dlatego warto jasno określić dzielenie jako oczekiwanie, udzielać feedbacku, gdy zespół dzieli pracę, i udzielać feedbacku również wtedy, gdy tego nie robi. Warto także wspierać pomysły na podział, zwłaszcza te bardziej odważne, które dotykają aspektów biznesowych wyższego poziomu lub wymagają głębszego zrozumienia celu. Wszystkie te działania warto konsekwentnie wzmacniać. Trzeba też unikać sytuacji, w których zespół czuje, że ma zablokowaną możliwość dzielenia pracy. Chodzi o wytyczne lub komunikaty, które sugerują, że wszystko musi zostać wdrożone jako całość, lub inne blokery i komunikaty, które sprawiały, że zespół obecnie nie wierzy w efekty pracy przyrostowej i przestaje widzieć sens w dzieleniu pracy. 

Dzielenie pracy na mniejsze części to zawsze dobry pomysł. Nie spotkaliśmy zespołu, który byłby zawiedziony efektami dobrze przeprowadzonego podziału pracy. Dzielenie to supertaktyka. Można je porównać do „superfood” w świecie praktyk zespołowych. Przynosi korzyści na wielu poziomach i stanowi jeden z fundamentów efektywności zespołów. Warto budować kulturę pracy, która wspiera dzielenie pracy na mniejsze części oraz aktywnie mierzyć się z wyzwaniami związanymi z tą praktyką.

Jeśli będziesz dzielić projekt na mniejsze części, to możesz dostarczać wartość szybciej i z mniejszym ryzykiem. Zyskasz też większą przewidywalność i o wiele mniej stresu w zespole

Gdy wszyscy rozumieją cel, łatwiej znaleźć sprytne skróty i priorytety. W efekcie mniej czasu tracisz na poprawki i gaszenie pożarów.

Do zrozumienia celu projektu rekomendujemy wykorzystanie jednej z tych technik:

Obniżanie ryzyk biznesowych, technologicznych i społecznych, najważniejsza wartość dostarczona  wcześniej to główne korzyści podzielenia projektu już na początku.

Zacznij od zrozumienia ich obaw. Pokaż im, że chronisz to, co dla nich kluczowe i często unikalne. Dzięki temu zmniejszysz strach przed utratą zakresu, skrócisz czas do pierwszych efektów i zbudujesz zgodę na mniejsze kroki.

Dla Biznesu i IT zastosuj techniki wizualne. Rekomendujemy Story Mapping, obiecująco wygląda też zastosowanie Event Stormingu.

Kolejne procesy dzielenia będą mniej czasochłonne, jeśli użyjesz reużywalnych narzędzi takich jak: checklisty, szablony i znane zespołowi schematy.

Traktuj dzielenie jako inwestycję. Szybciej osiągniesz dobre zrozumienie zakresu i odzyskasz poczucie kontroli nad postępem. Zespół wtedy działa na prostszych krokach, zatem mniej się blokuje i dostarcza wartość szybciej, z mniejszym ryzykiem i stresem.

Postawa „Niech ktoś podzieli” polega na tym, że w zespole lub organizacji nie bardzo wiadomo, kto dokładnie powinien się zabrać za dzielenie. Często też wynika z tego, zespół jest konfrontowany ze zbyt dużym projektem, co sprawia, że podział jest trudny.

Wspieranie kultury dzielenia pracy przez management to: stawianie jasnych oczekiwania, dawanie feedbacku, wspieranie pomysłów na podział i nie blokowanie swoimi decyzjami możliwości pracy przyrostowej.

Zbuduj doświadczenie w dzieleniu i wtedy staje się ono czymś naturalnym, płynnym i sprawnym. Stanie się naturalną częścią pracy zespołów, nad którą nie trzeba będzie się zastanawiać.

Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu Porządny Agile.

Kuba: Niedawno zakończyłem serię warsztatów na temat praktyk dzielenia większych inicjatyw produktowych i projektowych na mniejsze części. Grupa mierzyła się m.in. z tematem wyzwań, jakie występują przy okazji procesu dzielenia. Wypracowaliśmy w poszczególnych grupach bardzo wartościową treść, zarówno jeśli chodzi o samą definicję tych wyzwań, jak i możliwe rozwiązania, więc tutaj postanowiliśmy, że wycinek tej treści, a konkretnie te konkretne wyzwania, które grupy wygenerowały, będą stanowiły wsad do tego nagrania. A przy okazji serdecznie pozdrawiam wszystkie pięć grup. Wiecie dobrze, że przepracowaliśmy o wiele więcej wątków, ale w odcinku może zmieścić się tylko część z tego, co omawialiśmy.

Jacek: Spis treści na dzisiaj to wyzwania, jakie poruszymy. A są to problem z dobrym zrozumieniem celu projektu, presja biznesu na wdrożenie całości, wyważenie perspektywy technologii i biznesu przy podziale, czasochłonność procesu dzielenia i mentalność – niech ktoś to podzieli.

Kuba: Schemat odcinka będzie dosyć prosty. Wejdziemy w definicję tego, co konkretnie oznacza daną wyzwanie. Te hasła nie zawsze są zrozumiane na pierwszy rzut oka. No i potem wygenerujemy po trzy rozwiązania, jakie przychodzą nam do głowy jako takie najczęściej się sprawdzające w praktyce rzeczy, które są w naszym doświadczeniu możliwym rozwiązaniem albo chociaż minimalizacją danego wyzwania.

Jacek: Pierwsze wyzwanie to problem z dobrym zrozumieniem celu projektu. Jest to naszym zdaniem popularny bloker, który powoduje, że bardzo trudno jest zasiąść do mądrego podzielenia projektu czy inicjatywy, jeżeli tak naprawdę nie rozumiemy, co chcemy uzyskać. Oczywiście bez zrozumienia celu możemy tak bardzo mechanicznie spróbować podzielić pewien projekt na mniejsze części, ale prawdziwa magia dzieje się wtedy, kiedy bardzo dobrze rozumiemy cel, ponieważ wtedy otwierają nam się furtki do tego, jak pewne rzeczy możemy zrealizować w o wiele mądrzejszy sposób, niż tak patrząc na projekt bez zrozumienia, co tak naprawdę chcielibyśmy tym projektem uzyskać.

Kuba: I jest tak, że to zrozumienie jest tutaj fundamentalnym wstępem do dobrego podziału, więc pierwsza porada może być dosyć oczywista. Zapewnij, że cel jest zrozumiały. Tutaj mamy na myśli kilka możliwych realizacji tego zapewnienia. Jedną z rzeczy na pewno jest dobry kick-off, czyli jakiś rodzaj spotkania otwierającego daną inicjatywę, dany projekt, daną zmianę produktową czy dany etap rozwoju danego produktu. Nie przechodź do założenia, że ludzie wiedzą, bo ty wiesz, tylko zapewnij jakiś wstęp, jakieś exposé, jakieś dobre wtajemniczenie ludzi w dotychczas zebrane badania, w taki kontekst biznesowy, dlaczego pewną rzecz realizujemy. I te przygotowania się do tego kick-offu nie pójdą na marne, bo też zapewnienie zrozumienia celu może być poprzez powtarzanie tych informacji. Czyli też zbuduj sobie praktykę wracania do celu przy każdej nadarzającej się okazji. To mogą być jakieś Przeglądy Sprintów, jeśli stosujesz Scruma, to mogą być jakieś demo, spotkania projektowe, jakieś warsztaty, jakieś podsumowania. Wszystkie te miejsca, gdzie zebrany jest zespół lub jego wyraźna część, to mogą być okazje do tego, żeby wrócić do tej mantry, co jest celem, co jest istotą tego, co jest realizowane w danym momencie. No i tutaj trochę założenie, że wielokrotne powtórzenie, być może powtórzenie na pewne różne sposoby, przekazanie tej informacji sprawi, że ten cel będzie rozumiany, da okazję do tego, żeby się tak mocniej w zespole osadzić. No i tym samym, gdy przyjdzie moment na aktywność związaną z dzieleniem, czy na początku jakiegoś kroku, czy w trakcie już dalszych prac, to ten cel będzie pamiętany, łatwy do przypomnienia, czy po prostu tak już na tyle zrozumiały, że w zasadzie wszyscy to traktują jako oczywistość.

Jacek: Druga porada jest pewnego rodzaju pogłębieniem tego, co powiedział Kuba, czyli rekomendujemy użycie sprawdzonych technik, które wspierają pracę na celach, lepsze zrozumienie tego, czym ten cel właściwie jest. I mamy tutaj na myśli szereg różnych technik, podejść. Chcielibyśmy je teraz troszeczkę wymienić, tak żeby rozsypać takie ziarenka możliwości. Na pewno sensowną techniką do rozważania jest impact mapping, podejście golden circle, koncepcja product vision board, OKR-y czy opportunity solution tree. Jeżeli te nazwy niewiele ci mówią na ten moment, żadna strata po prostu wyszuka je w internecie, jeśli jeszcze ich nie znasz. Mamy z Kubą doświadczenie w większości tych narzędzi no i faktycznie możemy potwierdzić, że nie dość, że są fajnym narzędziem, które wspomaga zrozumienie, po co pewne rzeczy robimy, to zwykle są to też narzędzia, które są wizualne. Tak więc praca z nimi to nie jest tylko rozmowa, jest też ta część taka widoczna, która bardzo mocno poprawia i zwiększa zrozumienie tego, co on tak naprawdę jest esencją danej zmiany.

Kuba: I tu konkretnie, jeśli by zespół zawierał się do jakiejś sesji dzielenia, to jeśli do tej pory nie zostało to zrobione, to rekomendujemy wykorzystanie jako swego rodzaju rozgrzewki czy wstępu właśnie któregoś z tych narzędzi lub powrotu do tych narzędzi, jeśli one zostały już przepracowane na wcześniejszych etapach. 

Kuba: I trzecia praktyka, którą rekomendujemy to stosowanie tak często, jak tylko się da sprawdzenia zrozumienia celu. To nie tylko osoba zarządzająca projektem, lider produktu czy manager zespołu, może być osobą, która komunikuje, jaki jest cel, ale możemy też poprosić o to, aby to uczestnicy w jakiejś formie ćwiczeniowej albo po prostu na zasadzie takiej szybkiej śmierci po prostu powiedzieli, przypomnieli, czy swoimi słowami opowiedzieli, jaki jest cel danej inicjatywy. To może być okazja do tego, żeby w ogóle sprawdzić, czy to jest zrozumiałe, to może być też narzędzia aktywizujące czy rozgrzewające uczestników, ale też jest fajna okazja do tego, żeby skorzystać z różnorodności zespołu, różnych perspektyw, różnych osób, z różnych profesji, które na sprawy patrzą trochę inaczej. Również warsztatowo na wspomnianym szkoleniu przeze mnie było to bardzo doceniane. Mieliśmy miks osób o bardzo różnych specjalizacjach na warsztacie i też właśnie ten aspekt wychodził. Pewne osoby patrzą na sprawy bardziej systemowo, inne bardziej biznesowo. No i ta parafraza celu albo próba zrozumienia celu też może być atakowana na różne sposoby i w efekcie to zrozumienie jest lepsze. Więc dąż do tego, żeby sprawdzać zrozumienie na przykład poprzez parafrazę przez osoby zaangażowane w zespół.

Kuba: Przejdźmy zatem do drugiego wyzwania. Jest to presja biznesu na wdrożenie całości. Co mamy na myśli? Całości projektu, całości zakresu, całości inicjatywy, czasami może całość jakiejś zdefiniowanej funkcji w produkcie. To zjawisko może powodować, że jest pewna niechęć czy pewne poczucie bezsensu dzielenia. No bo po co dzielić, jeśli i tak musimy na końcu wdrożyć wielką całość tak, jak została ona zdefiniowana, a czasami z tą presją biznesu może się wręcz wiązać czy z presją może managementu, może się nawet wiązać takie poczucie, że podzielenie to proszenie się o kłopoty, bo być może ta strona, która wywiera tę presję, może wręcz zaraz zacząć dostrzegać się, że my chcemy spróbować się wyślizgnąć z jakiegoś kawałku zakresu. Więc szereg pewnych takich negatywnych emocji, które mogą powodować, że tego dzielenia nie chce zespół zrealizować.

Jacek: I pierwsza nasza rekomendacja odnośnie do tego wyzwania jest taka, żeby pokazać korzyści, które wynikają z tej dekompozycji na wczesnym etapie. Warto założyć, że nie wszyscy wiedzą, nie wszyscy doświadczyli tego, jakie to są korzyści. A myślimy tutaj przede wszystkim o wczesnym obniżaniu ryzyk, zarówno biznesowym. Czyli mamy okazję wcześniej przekonać się, że to, co wymyśliliśmy, faktycznie trafia w potrzebę rynkową, jest właściwie rozwiązane. Ryzyk technologicznych, czyli czy potrafimy posługiwać się konkretną technologią, której chcemy użyć, czy ryzyk społecznych, czyli czy ta grupa osób, która odpowiada na implementację tego rozwiązania, czy potrafią ze sobą efektywnie współpracować. Więc ryzyka to jest jakby jedna strona tej monety, a z drugiej strony jest taka koncepcja, że chcielibyśmy tę najważniejszą wartość, tę esencję tak naprawdę, konkretne zmiany projektu czy inicjatywy, chcielibyśmy dostarczyć jak najwcześniej. Jeżeli ten temat jest dla Ciebie interesujący, to zdecydowanie polecamy nasz wcześniejszy odcinek, odcinek, który nazwaliśmy „Dlaczego warto dzielić praca na małe części?”, ponieważ zawarliśmy tam całą masę pomysłów, koncepcji i wskazówek, dlaczego warto dzielić. Odsyłamy do odcinka numer 76 dostępnego pod adresem porzadnyagile.pl/76.

Kuba: Drugi z możliwych rozwiązań na presję biznesu na wdrożenie całości jest zrozumienie obaw interesariuszy, które blokują ich na tenże podział. Tutaj proponuję uruchomić empatię, proponuję zrozumieć i wczuć się w perspektywę tych Interesariuszy. Coś, co widać z zewnątrz z perspektywy też może konkretnego zespołu wykonawczego jako jakiegoś rodzaju niezrozumiała albo wręcz nieracjonalna presja, może tak naprawdę być czymś unikalnym dla tej osoby, dla tego konkretnego managera czy tej konkretnej grupy ludzi z jakiejś części organizacji. To może być coś, czego ty nie doceniasz, a jednak trzeba zagospodarować. Co mam tu na myśli? Bardzo konkretny przykład z konkretnej firmy, w której uczestniczyłem. Na przykład zespół odpowiedzialny za operację, czyli jakieś takie działania związane z usługami, na przykład po sprzedaży i obsługą klienta. Bardzo bał się, że ich narzędzia zostaną uznane za nieistotne, albo w ogóle nie zostaną zrealizowane w całym projekcie, dlatego oni byli bardzo sceptyczni i bardzo tacy twardzi w negocjacjach, bardzo niechętni do jakiegokolwiek dzielenia tego, co oni zgłosili, jakichś puli, ich wymagań, ich potrzeb narzędziowych. No bo ich życiowe doświadczenie z przeszłości jakichś poprzednich projektów pokazywało, że często kończyło się tym, że pod presją czasu w ogóle żadne narzędzia dla nich nie były wykonywane i muszą obsługiwać klienta Excelami i mailami pisanymi z ręki, bo system nie zagospodarował tego, choć pierwotnie było to planowane. Więc tutaj warto wziąć na to poprawkę, warto wczuć się w tę perspektywę i też zrozumieć ewentualne obawy.

Jacek: Innym przykładem obawy może być sytuacja, w której ktoś komuś obiecał bardzo precyzyjny i zwykle bardzo rozbudowany zakres. Często jest tak, że osoby te nie mówią tego wprost albo po prostu może trochę im jest trudno też przyznać, że gdzieś tam komuś coś takiego obiecały no i będą opornie podchodzić do tematu, żeby ten duży kawałek, tą całość podzielić. Z takiej obawy, że to dzielenie będzie jednak być może pretekstem do tego, żeby z tego zakresu wyleciało.

Kuba: Taki przykład specyficzny już dla pewnej grupy firm to to, że jest też w niektórych organizacjach taki pęd ku robieniu dużych, spektakularnych rzeczy. I tutaj w tym kontekście idea dzielenia trochę stoi z tym w poprzek. No bo trzeba robić wielkie projekty strategiczne, robić wielkie wow, mieć wielkie premiery, mieć wielkie nagrody za jakieś tam przełomowe niesamowite odkrycia czy innowacje w danej branży. W tym sensie warto tę perspektywę też złapać, że może być tak, że osoba właśnie szykuje się na przyszłą konferencję innowacji w bankowości i tam naprawdę ma wielką ochotę wyskoczyć na scenę i poopowiadać, jak to wielkie, wspaniałe, nowe implementacje, pewnie w tym roku AI w apce, ma w planach. Oczywiście to nie oznacza, że spektakularne rzeczy muszą być niepodzielone, ale warto może mieć tutaj świadomość tej sytuacji i ewentualnie dbać o tę komunikację, bo jedno nie stoi w przyszłości z drugim. W najgorszym razie faktycznie wdrożenie może mieć miejsce jako wielki wow, co nie znaczy, że nie warto podzielić na wcześniejszych etapach i też dostarczać kawałkami, być może kawałkami, które nie będą jeszcze publikowane.

Jacek: I to, co Kuba powiedział, to właściwie przesuwa nas do trzeciej porady, czyli przepracowania z biznesem różnic pomiędzy podziałem na części, a obietnicą realizacji całości. W największym skrócie chodzi o to, że to, że podzielimy na mniejsze kawałki pracę, nie musi automatycznie oznaczać, że nie wdrożymy potrzebnej całości. Przy czym jednak tutaj oczywiście dostrzegamy pewną kontrowersję, no bo może być tak, że masz doświadczenie z aktualnej firmy czy z wcześniejszych firm, że jednak ze względu zwykle na jakieś ograniczenia czasowe taki podział powoduje, że do konkretnej daty jednak wdrażana jest jakaś tam część. Bywa, że ona jest satysfakcjonująca i nie są realizowane te rzeczy, których nie zdążyliśmy zrobić w dalszej kolejności, tylko realizowane są jakieś kolejne inne koncepcje. Więc co do zasady nie musi tak być, ale rozumiemy, że doświadczenie i historię wcześniejszych projektów mogą podpowiadać, że z tą poradą trzeba byłoby czy do tej porady podchodzić w ostrożny sposób.

Kuba: W szczegółach jest też druga kontrowersja, to koncepcja potrzebnej całości. Może się okazać, że tutaj ktoś się bardzo kurczowo trzyma tego czegoś, co jest wyobrażeniem całości zakresu czy całości rozwiązania, co powstało na bardzo wczesnym etapie. No i czasami niektórzy zbyt kurczowo się trzymają tej wizji raczej zakładając, że od początku mieli rację co do tego, co jest potrzebne, od początku wiedzieli, że dokładnie ten cały zakres jest tym, czego potrzebuje rynek czy potrzebuje klient. Więc tutaj wracamy też do ryzyk biznesowych. Zbyt dużo decyzji podjętych na zbyt wczesnym etapie może być, tak naprawdę złudzeniem co jest potrzebne. Więc rada z podwójną kontrowersją jak to pokazaliśmy, ale mimo wszystko na etapie takim bardzo wczesnym, być może bardziej dyplomatyczne jest powiedzenie, „Podzielimy na kawałki i wdrożymy to, co jest potrzebną całością”, gdzie ja w swojej głowie mówię, potrzebna całość to nie będzie cały zakres, tak jak go czujemy dzisiaj, bo jeszcze czas pokaże, co to dokładnie będzie to coś, co wdrożymy.

Jacek: Trzecie wyzwanie to wyważenie perspektywy technologii i biznesu przy podziale. Mamy tutaj na myśli sytuację po dwóch stronach osi. Z jednej strony, kiedy podział dzieje się wyłącznie w izolacji biznesowej i osoby technologiczne do tego podziału nie są zapraszane, co oczywiście powoduje, że tracimy bardzo istotny aspekt wykonalności, jak również dostępnych opcji, które płyną nie z głów biznesowych, a od osób technologicznych. Z drugiej strony próba podziału wyłącznie technologicznego, co może się udać z perspektywy podziału tego na mniejsze kawałki, ale dobrze nie rozumiejąc aspektów biznesowych albo nie mając możliwości dopytania – przykładowo, jaki to będzie miało impakt biznesowy – również spowoduje, że taki podział będzie jakiś, ale na pewno nie będzie to podział optymalny.

Kuba: Rozwiązanie pierwsze jest dosyć oczywiste. Zaproś przemyślany skład, będący reprezentacją potrzebnych stron. I to idzie trochę dalej niż tylko te dwie skrajne kawałki osi, które wymienił Jacek, bo to może być też perspektywa na przykład prawna, to może być perspektywa user experience, więc tutaj uczestników tego typu warsztatów czy aktywności związanych z podziałem powinno być prawdopodobnie sporo w zależności od kontekstu i specyfiki twojego produktu. Natomiast w tej Radzie „Zaproś” jest też koncept tego, że w ogóle rozmawiamy po co, kto, z czym ma przyjść i jaką perspektywę reprezentować. Mnie serce boli, jak często słyszę ze strony biznesowej, że zaprosili na przykład przedstawicieli IT, jakiś architektów, jakiś senior developerów, po czym się okazało, że te osoby były bardzo ciche na spotkaniu, nie za bardzo zabierały głos, nie za bardzo dokładały od siebie – nawet zapytane. Moim zdaniem tu może być taki błąd pierwotny w tym, że ktoś zaprosił te osoby, przyszły, bo warto, bo trzeba, bo tak wypada, bo taki jest zwyczaj, natomiast tak naprawdę te osoby mogłyby nie wiedzieć, po co na danym spotkaniu są. Więc tutaj pojawia się bardzo ważna rola osoby zapraszającej, ktokolwiek to jest w danym kontekście, która również wyjaśnia wszystkim obecnym czy wszystkim planowanym do wzięcia udziału w tych czynnościach, żeby jednak bardzo jasno wyrazić, na co liczę, na czego oczekuję od Ciebie, jako uczestnika tego typu warsztatów. Żeby też nikt się nie bał, nie krygował, nie hamował, zwłaszcza, że prawdopodobnie w ramach takiego dzielenia się będzie trochę tarć. Ktoś zaproponuje podział biznesowy, który nie do końca jest dobry technologicznie, któryś podział biznesowo-technologicznie fajnie się zapowiadający będzie trochę bezsensowny z perspektywy prawnika, czy z perspektywy osoby odpowiedzialnej za bezpieczeństwo. Więc tutaj się rzeczy będą tarcia, więc każdy musi rozumieć też, po co jest na tym warsztacie, czy na tym spotkaniu, czy uczestniczy w tych aktywnościach.

Jacek: Druga wskazówka ustal facylitatora i oczekuj od tej osoby, że zadba o każdą perspektywę. Mówiąc prostszym językiem, zadba, żeby była osoba, która zadba o to, żeby przebieg tego warsztatu był maksymalnie efektywny, żeby równomiernie wybrzmiały dostępne na spotkaniu perspektywy, nawiązując do tego, co powiedział Kuba, jak również, żeby zbalansować też głębokość tych rozmów. Czyli przykładowo, żeby nie zabrnąć w jakieś super niskopoziomowe detale na przykład technologiczne, bo to może powodować, że wszystkie te inne osoby, które nie są tak techniczne, może się o nich rodzić poczucie, że to spotkanie tak nie do końca jest dobrze poprowadzone. Kto może prowadzić takie spotkanie? To może być ogarnięty analityk, to może być lead developer, to może być architekt. Tak naprawdę nie ma to znaczenia, jak nazywa się ta konkretna rola. Ważne jest natomiast, żeby ta osoba była po pierwsze dobrze przygotowana do poprowadzenia takich warsztatów, czasem serii warsztatów, bo to może być więcej niż jednorazowa akcja, i żeby starała się ta osoba trzymać perspektywę wszystkich stron będących na tym spotkaniu równomiernie, a nie była tylko reprezentantem tej jednej. Bo tak jak wspomniałem przed chwilą może to spowodować, że nie do końca będzie to dobra reklama na przyszłość dla tego typu inicjatyw w organizacji.

Kuba: I trzecia porada, jak sobie poradzić z wyważeniem perspektywy technologii i biznesu, to zastosować techniki wizualne, które są zrozumiałe zarówno dla biznesu, jak i IT. Mamy tu konkretnie przede wszystkim na myśli Story mapping, który lubimy, robimy, często rekomendujemy i sami też regularnie wręcz stosujemy do swojej własnej pracy biznesowej czy pracy związanej z podcastem. Podobnie jak z poprzednimi wymienionymi technikami, nie będziemy tutaj w odcinku ich opisywać. Zakładam, że Story Mapping jest już na tyle powszechną techniką, że akurat on powinien być wśród odbiorców znany naszego podcastu, ale jeśli nadal go nie znasz, to mocno rekomendujemy sprawdź to, może dołącz do jakiegoś warsztatu, gdzie jest to realizowane, bo technika jest supermocna, jeśli chodzi o wizualizację, jeśli chodzi o pokazanie zakresu, pokazanie opcji, ale też między innymi w kontekście tego, o czym tu mówimy, takie pokazanie sobie, czym jest w ogóle to przedsięwzięcie, które realizujemy, jaką ono się dzieli na mniejsze kawałeczki i te kawałeczki najczęściej są realizowane z perspektywy użytkownika, więc zrozumiałe są zarówno dla biznesu, jak i dla strony tych osób, które będą później to implementować. Obiecująco wygląda też zastosowanie Event stormingu. Ja sam osobiście nie prowadzę tych sesji, ale kilkukrotnie uczestniczyłem jako obserwator czy jako uczestnik. Mam tu mniejsze doświadczenia, ale jeśli ktoś umie to poprowadzić, to uważam, że może dać bardzo podobny rezultat co Story mapping, choć rządzi się trochę innymi prawami.

Jacek: Zanim pójdziemy dalej, krótka informacja, mamy dostępny z Kuba webinar dotyczący kwestii tego, jak dzielić pracę na mniejsze kawałki. Ten webinar nauczy Cię formułować celne argumenty za tym, że w ogóle warto dzielić, nauczy Cię też używać w praktyce wyselekcjonowanych przez nas konkretnych metod dzielenia. W webinarze pokazujemy wszystko na bazie łatwych, do zrozumienia przykładów, jak dzielić oraz podpowiadamy sporo wskazówek z naszej praktyki, jak lepiej dzielić elementy, angażując w to wydarzenie całe zespół. Więcej informacji oraz możliwości zakupu webinaru znajdziesz na stronie porzadnyagile.pl/deco.

Kuba: Czwartym wyzwaniem jest czasochłonność procesu dzielenia. Często, gdy przekonuję jakiś zespół do tego, że warto dzielić, słyszę jako jeden z argumentów przeciwko dzieleniu, jest to, że to jest praca do wykonania, ktoś to musi zrobić, ktoś to musi wpisać, tu będzie dużo elementów, które później trzeba zarządzić, skoordynować. I przyjmuję do wiadomości, że to jest pewna praca, to jest pewien wysiłek, ale dla wielu zespołów czy w wielu organizacjach jest to po prostu pewnego rodzaju wyzwanie, jak się za to zabrać. Co tutaj rekomendujemy?

Jacek: Przede wszystkim warto zadbać o zmianę myślenia, że dzielenie to nie jest koszt i tak nie nazywać tego procesu, tylko raczej myśleć o tym, że to jest inwestycja w proces dostarczania, która pomoże zespołowi uchwycić po pierwsze dobre zrozumienie zakresu, da też o wiele lepszą kontrolę nad postępem prac, przez to, że będziemy pracować na trochę mniejszych klockach i też zmniejszy złożoność danego kroku większej inicjatywy, które mamy do wykonania. Za tym wszystkim płynie cały szereg technicznych aspektów, a mianowicie sam przepływ pracy wewnątrz zespołu powinien tak naprawdę przy pracowaniu na mniejszych kawałkach przyspieszyć, przez to, że szybciej coś zostanie zaimplementowane, szybciej będziemy w stanie to przetestować, szybciej będziemy w stanie zrobić code review, czy ostatecznie szybciej pewne rzeczy zmergować, czy wypuścić na środowisko produkcyjne. Jest więc cała masa bardzo pozytywnych rzeczy, które dostaniemy, tylko jeśli zainwestujemy czas w to, żeby tę pracę, która na nas czeka, po prostu, żeby ją podzielić na mniejsze fragmenty.

Kuba: Druga rada to wykorzystaj reużywalność narzędzi i instrukcji. Faktycznie może być tak, że ten koszt czy inwestycja, jak to Jacek przed chwilą bardzo wyraźnie wskazał czy skorygował, może po prostu zajmować pewien konkretny czas i częścią tego czasu może być przygotowywanie się lub niepotrzebne wgryzanie się w techniki czy w narzędzia związane z dekompozycją czy właśnie dzieleniem elementów. Tutaj mocno rekomenduję, zwłaszcza osobom, które pełnią jakieś funkcje liderskie w zespole, czy odpowiadają za proces pracy, by jak najmocniej wykorzystywać okazję do szykowania czy reużywania checklist, na przykład metody dzielenia. To jest bardzo prosta checklista, jakimi metodami możemy podzielić dany projekt czy dany element, który podlega właśnie warsztatowaniu. To mogą być przygotowane szablony, wymieniliśmy konkretne już techniki, te techniki można mieć już przygotowane, jakieś boardy na jakimś miro czy jakieś przygotowane gotowe kawałki do przepisania na flipchart czy do przepisania na jakieś kartki. Ale chodzi też o znane zespołowi schematy. Nie trzeba się silić za każdym razem, żeby zrozumieć o co chodzi tej osobie, która prowadzi daną sesję warsztatową, tylko zespół się dopracowuje z czasem gotowych ścieżek, tych, które już można nawet prawie nie dawać żadnych instrukcji, tylko po prostu wejść na takim trochę automacie. Oczywiście nie sugeruję, te instrukcje zawsze jednak jakieś powinny być, ale one mogą być super związłe, niewymagające żadnych dodatkowych omówień i też wchodzące zespołowi, tak nazwij, gładko. Czyli zespół płynnie wchodzi w temat, nie ma żadnych dyskusji, ale o co ci chodzi, gdy każesz nam tu coś rozpisać albo co masz na myśli, gdy mówisz o dzieleniu po jakiś tam elementach, bo to wszystko zespół już zna, czuje. Więc też w jakimś sensie jest okazja do oszczędności czasowej, jeśli tylko do tego podchodzi się w taki bardzo świadomy sposób i dzięki temu, zwłaszcza kolejne dzielenia, gdy już bazujesz na checklistach albo schematach, są już mniej czasochłonne.

Jacek: To co powiedział Kuba jest wprowadzeniem do trzeciej porady, czyli nabierzmy wprawy w dzieleniu. Kiedy zbudujemy doświadczenie, kiedy będziemy mieć te wszystkie checklisty, te wszystkie rzeczy, które nam ułatwiają, wtedy dzielenie staje się czymś naturalnym, płynnym, oczywistym i jest po prostu przeprowadzane w sposób generalnie dosyć sprawny. Przestaje być tematem, na którym trzeba się zastanawiać, nic nas nie blokuje, nie ma tej obawy jak to zrobimy, tylko po prostu staje się tu naturalną częścią pracy zespołów, coś co jest absolutnie oczywiste i należy poświęcić na to trochę czasu. To nie jest tak, że to się po prostu wydarzy, ale pierwsze podzielenie, drugie, trzecie. Zwykle pojawiają się bardzo wartościowe efekty dzielenia, powodują, że w tej pamięci mięśniowej zespołu zostaje taka myśl, że to po prostu warto robić, więc z perspektywy czasu nie ma już myślenia, czy to zrobimy, tylko tak naprawdę, kiedy to zrobimy, bo po prostu wiemy, że to po prostu trzeba robić, że to ma sens. I też skojarzenie jest takie, że zrobiliśmy to tyle razy, że zrobimy to z równą łatwością, kiedy przyjdzie kolejna okazja czy konieczność, żeby wykazać się tymi umiejętnościami.

Kuba: I pokuszę się o taką szpileczkę, że wyzwanie z czasochłonnością dzielenia, szczególnie przecenia czy niepotrzebnie uwypukla ta grupa, która tego dzielenia nie robi. Czyli tutaj jest pewnego rodzaju obietnica osoby, które realizują dzielenie rutynowo, po prostu uważają to za nieodłączną część pracy, robią to dosyć płynnie i nie robią z tego niepotrzebnego szumu.

Jacek: Ostatnie wyzwanie, które chcemy pokryć w dzisiejszym odcinku, to mentalność, niech ktoś podzieli. Czyli jest to sytuacja, w której nie do końca wiadomo, kto powinien się zabrać za dzielenie. Może i czujemy, że dobrze by było podzielić, ale to na pewno nie powinniśmy robić my. To powinni zrobić oni, albo to powinien zrobić ktoś. Jeżeli więcej osób w organizacji pomyśli w ten sam sposób, odrzucając trochę tę rękawicę pod tytułem wezmę i zrobię, to może się okazać, że czas sobie będzie płynął, co jest nieuniknione i po prostu zaczniemy pracę z tym, co mamy, czyli będziemy pracować z projektem w takim stanie, jaki jest, bez podziału. Jakie mamy pomysły na to, żeby sobie z tą mentalnością poradzić?

Kuba: Pierwsza praktyka, chociaż nieatakująca problemu wprost, to podział na poziomie całego portfela. Mówię, że nie atakuję to wprost, bo to nie rozwali tej mentalności, że ktoś inny powinien podzielić, a w pewnym sensie nawet wręcz właśnie rekomenduję, żeby faktycznie ktoś inny podzielił, ale mam tu na myśli to, że jednym z problemów tego takiego przytłoczenia albo potrzeby, żeby ktoś podzielił, jest właśnie ta perspektywa, że często do zespołów wykonawczych, czy takich zespołów produktowych, projektowych trafia coś, co jest bardzo dużych rozmiarów i to tak z góry zdeterminowane, czy z góry zdefiniowane w taki sposób, że ten podział nie jest prosty. Więc tutaj mocno rekomenduję, by to na poziomie portfela, czy produktu, czy Road mapy, czy całego portfela projektów, jeśli tak to funkcjonuje w twojej organizacji, zastanowić się, czy by tego podziału jednak w jakimś sensie, albo nie wymusić, albo chociaż propagować jako dobrą praktykę. Bo wtedy, jeśli do zespołu trafi coś, co jest mniejszą cząstką, jakimś mniejszym etapem projektu, mniejszym wycinkiem celu, albo realizacją tylko jednego z najważniejszego celu spośród kilku, które dana inicjatywa pierwotnie miała realizować, to ten podział w tym zespole już konkretnym będzie trochę prostszy. Więc ta mentalność niech ktoś podzieli, moim zdaniem może m.in. częściowo bazować na tym, że zespół jest konfrontowany z trochę za dużymi elementami i rozwiązaniem na to jest podział na wczesnym etapie, jeszcze tak trochę ponad zespołem, czy na tym etapie takim strategicznym, albo chociaż taktycznym.

Jacek: Druga porada to zasada, którą chcemy zaproponować, że warto się na nią umówić w zespole, która brzmi, jak widzisz linię podziału, to zgłaszasz propozycję podziału. Czyli koncepcja, w której jeżeli przechodzi Ci do głowy, jak można coś byłoby podzielić, to po prostu mówisz to. Z czego wynika ta propozycja? Wielokrotnie spotykam się z sytuacją, że obserwuję np. podczas procesu superwizji, jak pracuje konkretny zespół. Ktoś zadaje pytanie, pada pytanie, nikt się nie odzywa. Można odnieść wrażenie, że w zespole nie ma odpowiedzi. Kiedy zagłębić się i porozmawiać na spokojnie z pojedynczymi osobami, albo kiedy zastosujemy inną strukturę, która w lepszy sposób aktywizuje osoby dostępne w zespole, okazuje się, że zespół ma całą masę różnych pomysłów, bo tylko z jakichś powodów się tymi pomysłami nie dzieli. Zasada, którą tutaj proponujemy, ma na celu zbudowanie śmiałości w ludziach. Na zasadzie uprościmy sobie życie, jeśli ktoś zobaczy fajny, sensowny sposób podziału, to się w danym momencie odezwie. Brzmi to banalnie, ale wiem z doświadczenia, że czasem pojedynczy sygnał, impuls, komentarz potrafi uruchomić bardzo fajną zmianę w zespole. Zdecydowanie do umówienia się na takie proaktywne działanie rekomendujemy.

Kuba: Trzecia, ostatnia porada w tym wyzwaniu to kształtowanie przez management konieczności dzielenia. To dzielenie musi być oczekiwane, czyli członkowie zespołu. Jeśli wprowadzili tę zasadę Jacka, to powinni być za nią doceniani. Jeśli jej nie wprowadzają albo zasłaniają się, że idzie, jak idzie, albo postępów nie ma, albo ryzyka projektowe się ziściły, bo nie podzieliliśmy, to powinien być wstęp do bardzo poważnej rozmowy o tym, że to jest problem, bo jako management organizacji, czy jako Product manager, czy Project manager, czy jakiś manager strukturalny, hierarchiczny, wszyscy wymagają tego, żeby to dzielenie miało miejsce. Warto postawić dzielenie jako oczekiwanie, dawać feedback, jeśli to dzielenie następuje, dawać feedback, jeśli nie następuje. Też wspierać pomysły na podział, zwłaszcza takie bardziej odważne, wiążące się też z zahaczeniem o aspekty wyższego poziomu biznesowe, czy związane ze zrozumieniem celu. Wszystko to warto propagować. I przez odwrotność też powiem, nie doprowadzać do sytuacji, w której zespół ma poczucie, że ma zablokowaną możliwość dzielenia. Mam na myśli takie jakieś wytyczne czy jakieś stawianie pewnych spraw, że na przykład wszystko musi być wdrożone jako całość, co było przedmiotem innego wyzwania, czy jakieś inne rodzaje blokerów albo komunikatów, które powodują, że zespół nie wierzy w efekty pracy przyrostowej i nie widzi w związku z tym sensu dzielenia.

Jacek: Na koniec kilka myśli, którymi chcemy się podzielić zamiast takiego klasycznego podsumowania. Dzielenie pracy na mniejsze kawałki to zawsze dobry pomysł. Jeszcze nie spotkałem zespołu, który byłby zawiedziony efektami dobrze przeprowadzonego dzielenia.

Kuba: Dzielenie jest superpraktyką. Analogicznie do tego jak o żywności mówi się superfood. Daje masę korzyści na wielu poziomach i jest jednym z fundamentów efektywności zespołów.

Jacek: Warto kreować kulturę pracy wspierającą dzielenie pracy na mniejsze części i aktywnie mierzyć się z ewentualnymi wyzwaniami, z takimi aktywnościami.

Kuba: Jeśli mierzysz się w swojej organizacji z wyzwaniami związanymi z dzieleniem, tymi, które wymieniamy albo innymi, skorzystaj z naszej oferty wsparcia konsultacyjnego. W Twoim konkretnym kontekście pomożemy przemyśleć dany temat albo wskazać konkretne rozwiązania z naszego wieloletniego doświadczenia. Sprawdź całość oferty na 202procent.pl/konsultacje.

Jacek: Ja również polecam się odezwać do nas. Natomiast notatki do tego odcinka, artykuł, transkrypcja oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/139.

Kuba: I to by było wszystko na dzisiaj. Dzięki, Jacek.

Jacek: Dzięki, Kuba. I do usłyszenia wkrótce.

________

To była pełna transkrypcja odcinka podcastu Porządny Agile. Dziękujemy za lekturę!

Ostatnia aktualizacja: 13 stycznia 2026

Poznaj 11 prostych, ale jednocześnie skutecznych sposobów na ogarnięcie własnej produktywności — od listy rzeczy do zrobienia i planowania dnia, po technikę Pomodoro, regularne przerwy i blokadę powiadomień.  Dowiesz się, jak przestać rozgrzebywać milion zadań, jak utrzymać skupienie i jak stworzyć sobie przestrzeń, w której naprawdę da się pracować. To solidny zastrzyk inspiracji dla każdego, kto chce pracować mądrzej, a nie więcej.

Spis treści

• Lista rzeczy do zrobienia
• Planowanie dnia 
• Dzielenie pracy na małe kawałki 
• Skupienie na jednej rzeczy na raz 
• Łączenie pracy w paczki
• Technika Pomodoro 
• Regularne przerwy 
• Izolacja od dźwięku otoczenia 
• Blokada stron niezwiązanych z pracą 
• Blokada połączeń i powiadomień 
• Organizacja przestrzeni do pracy
• FAQ: Praktyki wspierające produktywność osobistą
• Transkrypcja podcastu „Praktyki wspierające produktywność osobistą„

Zacznijmy od pierwszej praktyki, listy rzeczy do zrobienia. Co właściwie się za nią kryje? To praktyka inspirowana metodą Getting Things Done. Jej celem jest ograniczenie rozproszenia poprzez przeniesienie wszystkich zadań z głowy na najlepiej konkretną, fizyczną lub elektroniczną listę rzeczy do zrobienia. Im bardziej rozproszona jest praca i im więcej wątków trzeba ogarniać równocześnie, tym łatwiej coś umyka. Zadania potrafią przypominać o sobie w losowych momentach. Takie sytuacje frustrują, stresują i często powodują przerwanie aktualnego zadania, by zająć się czymś zupełnie innym. Im bardziej zróżnicowane są zadania i wątki, tym większe ryzyko zapominania o części z nich. Niezapisane sprawy potrafią przypomnieć o sobie w zupełnie przypadkowych momentach. Niespodziewane przypomnienia wywołują stres, frustrację i często prowadzą do przerwania bieżącej pracy, by zająć się czymś innym.

Regularne korzystanie z list rzeczy do zrobienia pozwala ograniczyć stres i odzyskać spokój. Zamiast nosić wszystkie zadania w pamięci, wystarczy zapisać je na liście i wrócić do nich w odpowiednim momencie. Warto prowadzić kilka oddzielnych list, osobno dla spraw zawodowych, domowych czy prywatnych. Dzięki temu można sięgać po konkretne zadania wtedy, gdy przychodzi na nie czas, a jednocześnie uniknąć niechcianych przypomnień w nieodpowiednich momentach. Dzięki takiemu podejściu nie zdarza się już sytuacja, w której podczas pełnego skupienia, na przykład w trakcie prezentacji, nagle przypomina się o konieczności wysłania oferty lub odpowiedzi na wiadomość. Książkę, na której oparto tę metodę, przeczytaliśmy wiele lat temu. Już wtedy było widać, że wymaga aktualizacji. Część treści powtarzała się, a autor omawiał je kilkakrotnie w różnej formie. Mimo to sama koncepcja nadal ma wartość i zastosowanie. Kluczowym elementem metody jest tzw. Trusted System – jedno zaufane miejsce, w którym można zapisać wszystko, co wymaga uwagi, z pewnością, że nic nie zaginie. Wspomniane wcześniej nagłe przypomnienia o zadaniach w trakcie pracy to zjawisko dobrze znane. W takich sytuacjach warto natychmiast zanotować myśl w zaufanym systemie, na przykład w aplikacji do zarządzania zadaniami  i wrócić do bieżącego zajęcia. Wystarczy kilka sekund, by uniknąć utraty koncentracji i mieć pewność, że nic istotnego nie umknie.

W kontekście produktywności warto dodać, że wiele z praktyk omawianych w tym materiale dotyczy umiejętności utrzymania skupienia i doprowadzania zadań do końca. Jednym z najtrudniejszych rodzajów rozproszenia jest tzw. pętla niekończącego się myślenia o zadaniach, ciągłe przypominanie sobie o nich zamiast faktycznego działania. 

Sama lista rzeczy do zrobienia jest pomocna, ale kluczowym krokiem jest jej codzienne przejrzenie i świadome zaplanowanie, które z zadań warto, trzeba lub chce się zrealizować danego dnia. Istnieją różne podejścia do momentu, w którym najlepiej zaplanować dzień. Najczęściej planujemy w jednym z dwóch momentów, wieczorem, z myślą o kolejnym dniu, lub rano, tuż przed rozpoczęciem pracy. Zanim rozpoczniesz pracę, przejrzyj listę zadań i określ, co powinno lub może zostać wykonane danego dnia. Wystarczy poświęcić na to od 5 do 15 minut, by rozpocząć dzień z jasnym planem i pewnością, że żadne istotne zadanie nie zostało pominięte.

Ta praktyka łączy się nie tylko z produktywnością, lecz także z ogólną efektywnością osobistą. Przeglądając plan dnia, najlepiej rano, warto ocenić, które zadania są najbardziej wartościowe i realne do wykonania w danym dniu. Celem jest skupienie się na działaniach, które przyniosą największy efekt. Niektóre zadania mogą poczekać, inne mają charakter czysto życzeniowy. To właśnie moment, by podejść do planowania realistycznie i codziennie rano zastanowić się, co rzeczywiście da się wykonać i co będzie najbardziej wartościowe. Warto określić, które z tych działań stanowi priorytet lub najważniejszy punkt dnia. W pracy w metodyce Scrum można to połączyć z koncepcją celu dnia. To konkretne zadanie lub rezultat, który ma być kluczowym osiągnięciem dnia. W ten sposób wcześniejsza praktyka, lista rzeczy do zrobienia, staje się naturalnym źródłem pomysłów na to, jak zaplanować dzień i jakie działania wybrać jako priorytetowe.

Jednym z powodów odkładania pracy lub utknięcia w zadaniach jest ich zbyt duża skala. Próba realizacji zadań o zbyt szerokim zakresie często prowadzi do przeciążenia i braku postępów. Samo wyobrażenie dużego, złożonego zadania może wywoływać zniechęcenie, obawę przed porażką czy poczucie przeciążenia. W efekcie prowadzi to do odwlekania działania lub rozpoczęcia pracy bez realnego postępu. Mogą to być nawet drobne, pojedyncze czynności. Dobrym przykładem jest przygotowanie prezentacji. Przykładowo, przygotowanie godzinnej prezentacji inspiracyjnej można rozłożyć na kilka etapów: wymyślenie tematu, zapisanie pierwszych notatek, utworzenie pliku i podstawowego szkieletu prezentacji (np. strona tytułowa, wstęp, zakończenie). Każdy slajd może stanowić osobne zadanie, podobnie jak końcowy przegląd całej prezentacji. W połączeniu z listą rzeczy do zrobienia takie podejście sprzyja skupieniu. Duże, skomplikowane projekty przekształcają się w serię drobnych, wykonalnych zadań, które można realizować etapami, w dogodnym tempie, dziś, jutro lub wtedy, gdy pojawi się przestrzeń i energia.

Ważnym elementem dzielenia pracy na małe części jest poczucie postępu. Wykonanie nawet drobnego zadania daje szybką nagrodę, satysfakcję z odhaczenia pozycji na liście. W aplikacjach często towarzyszy temu dźwięk lub animacja, które wzmacniają to pozytywne wrażenie. To prosty, ale skuteczny mechanizm psychologiczny motywujący do dalszego działania. Dzielenie pracy na mniejsze elementy ma też wymiar praktyczny – pomaga doprecyzować, co właściwie należy zrobić. W trakcie tego procesu pojawiają się różne możliwe ścieżki realizacji: proste i szybkie, pośrednie lub bardziej rozbudowane. To moment, w którym można ocenić, która z nich najlepiej pasuje do sytuacji. Wybór ścieżki zależy od czasu, dostępnej energii i nastawienia do tematu. Warto rozbić zadanie na krótkie, łatwe do wykonania kroki, które nie budzą oporu przed rozpoczęciem. Kluczowa jest świadomość, że każdy z nich można zrealizować w kilkanaście minut. W tym miejscu działa prosta zasada: gdy już zaczynasz, łatwiej jest kontynuować. Dlatego wykonywanie zadań małymi krokami to skuteczny sposób na przełamanie oporu przed rozpoczęciem pracy. Dzięki temu praca stopniowo się posuwa, a lista zadań realnie się skraca.

Istnieje też dodatkowy efekt uboczny dzielenia pracy, po rozbiciu zadania można zauważyć, że niektóre jego elementy mają większą wartość, a inne są całkowicie zbędne. Warto to świadomie dostrzec już na wczesnym etapie pracy, uporządkować i zdecydować, z których elementów lepiej zrezygnować, szczególnie z tych, które wymagają czasu, a nie wnoszą realnej wartości dodanej, niezależnie od tego, jak jest ona definiowana. Przykładowo, przy przygotowywaniu prezentacji można świadomie pominąć niektóre elementy, jak notatki dla prelegenta. Choć wydają się przydatne, w praktyce często nie wnoszą istotnej wartości, dlatego ich pominięcie pozwala zaoszczędzić czas i skupić się na ważniejszych aspektach.

Kolejną skuteczną praktyką jest skupienie się na jednej rzeczy. Jej istota polega na konsekwentnym realizowaniu jednego konkretnego zadania od początku do końca, bez równoległego podejmowania innych działań. Nawet jeśli pojawiają się drobne przerwy lub nowe zadania, warto świadomie wracać do pierwotnego tematu, aby uniknąć jego rozciągania w czasie i utraty koncentracji. Po pierwsze, zbyt długie przerwy prowadzą do utraty skupienia, mimo że istniał konkretny powód rozpoczęcia pracy nad danym zadaniem. Po drugie, każde rozproszenie wydłuża całkowity czas realizacji. Choć nie poświęca się wtedy pracy nad zadaniem, jego „cykl życia” procesowo się wydłuża. Realizowanie zadań z przerwami, w kilku podejściach, generuje coraz wyższy koszt czasowy i poznawczy. W efekcie coś, co mogło zająć kilka minut, trwa kilkakrotnie dłużej, ponieważ każde ponowne wejście w zadanie wymaga ponownego „rozruchu” uwagi. Warto ćwiczyć umiejętność utrzymywania skupienia. Częstą pokusą jest podążanie za kolejnymi ciekawymi wątkami, np. otwieranie nowych kart, czytanie artykułów lub analizowanie tematów niezwiązanych z bieżącym zadaniem. Dlatego warto przyjąć zasadę świadomego skupienia, zobowiązania wobec siebie, by doprowadzić rozpoczęte zadanie do końca, odhaczyć je na liście i dopiero potem przejść do kolejnego. Domknięcie pracy daje satysfakcję i poczucie postępu. Najlepiej działa rytm pracy, w którym kolejne zadania są realizowane i domykane po jednym. To przeciwieństwo modelu z wieloma rozgrzebanymi tematami, licznymi otwartymi zakładkami, szkicami wiadomości i plikami w edycji, które rozpraszają uwagę i blokują efektywność. Tak jak komputer spowalnia przy zbyt wielu otwartych oknach, tak samo spada wydajność umysłowa, gdy uwaga jest rozproszona. Zmęczenie narasta szybciej, a efektywność pracy maleje.

Może się to wydawać sprzeczne z zasadą skupienia na jednej rzeczy, jednak w niektórych sytuacjach świadome grupowanie zadań ma uzasadnienie i przynosi wymierne korzyści. Na czym to polega? Istota tej praktyki polega na łączeniu podobnych zadań w serie lub bloki wykonywane jedno po drugim, w ramach tego samego okresu pracy. Jeśli zadania są do siebie podobne, warto rozważyć ich grupowe wykonanie. Może to przynieść efekt synergii, usprawnić pracę, skrócić czas realizacji lub ograniczyć koszty. Zgrupowanie zadań w bloku czasowym sprzyja również utrzymaniu rytmu i tempa działania.

Dwa przykłady dobrze pokazują, jak można stosować tę praktykę w codziennej pracy. Pierwszym przykładem jest praca z pocztą elektroniczną. Zamiast reagować na każdy przychodzący e-mail i nieustannie sprawdzać skrzynkę, lepiej zaplanować jeden konkretny moment na przetworzenie wiadomości. Wtedy można przejrzeć wszystkie nowe maile i świadomie się nimi zająć.

Można połączyć to podejście z metodą Getting Things Done – jeśli wiadomość wymaga krótkiej odpowiedzi, od razu na nią odpowiadam. Jeśli wymaga więcej czasu, tworzę z niej zadanie do wykonania i archiwizuję e-mail. Dzięki temu skrzynka pozostaje pusta, a żadne zobowiązanie nie ginie. Taki sposób pracy pozwala w krótkim czasie osiągnąć stan „inbox zero”, czyli pustą skrzynkę odbiorczą, co daje poczucie kontroli i porządku.

Drugim przykładem są czynności związane z podsumowaniem miesiąca, głównie w obszarze faktur i finansów, które celowo odkładamy w czasie. W tym przypadku faktury przychodzące trafiają w jedno wyznaczone miejsce. Raz w miesiącu przeprowadzamy pełne rozliczenie: przeglądamy, skanujemy i wysyłamy dokumenty. Choć to nie należy do ulubionych zadań, wykonanie wszystkiego w jednym bloku daje ulgę i satysfakcję, że temat pozostaje zamknięty na kolejny miesiąc.

Warto zwrócić uwagę, że do łączenia pracy w paczki najlepiej nadają się zadania o asymfonicznej naturze, takie, które nie wymagają natychmiastowej reakcji. Przykładowo: na e-mail można odpowiedzieć pod koniec dnia, a księgowa poczeka do uzgodnionego terminu zamknięcia miesiąca. Część zadań naturalnie łączy się w bloki pracy. Nie każde wymaga natychmiastowej reakcji, wiele z nich można zaplanować i wykonać później, w odpowiednim momencie. Warto świadomie grupować podobne czynności, dostosowując sposób pracy do własnych potrzeb i charakteru zadań.

Czym właściwie jest technika Pomodoro? To popularna metoda zarządzania czasem i budowania osobistego skupienia. Jej celem jest utrzymanie pełnej koncentracji przez określony, z góry ustalony czas. Nazwa techniki pochodzi od kuchennego minutnika w kształcie pomidora. Zegar symbolizuje ustalenie tzw. timeboxu odcinka czasu, w którym pracujesz w pełnym skupieniu. W tym czasie podejmujemy zobowiązanie wobec siebie, że nie będziesz się rozpraszać, a otoczenie może zauważyć, że jesteśmy zajęci. Polecany odcinek czasu w technice Pomodoro to 25 minut. To wystarczająco długo, by wykonać konkretne zadanie, a jednocześnie na tyle krótko, by łatwo było się zmobilizować i odłożyć inne sprawy na później. Sama metoda jest wyjątkowo prosta – polega na ustaleniu określonego czasu pracy i pełnym poświęceniu się zadaniu w tym przedziale. Po zakończeniu cyklu zrób krótką, świadomą przerwę, odpocząć, oderwać wzrok od ekranu, dać sobie chwilę wytchnienia. Następnie można rozpocząć kolejny cykl, czyli następne „Pomodoro”, kolejne 25 minut w pełnym skupieniu. Praca przebiega więc w rytmie naprzemiennych bloków koncentracji i krótkich przerw.

Wiele osób doświadcza pokusy pracowania tak długo, jak to możliwe, by dopracować każdy szczegół. Dotyczy to zarówno prostych czynności, takich jak napisanie wiadomości e-mail, jak i bardziej złożonych zadań, projektowania grafiki, przygotowywania raportu czy prowadzenia researchu. Gdy nie istnieje wyraźny termin zakończenia pracy, łatwo wpaść w pułapkę niekończącego się dopracowywania i udoskonalania szczegółów. Dlatego warto świadomie określać granice czasu poświęcanego na dane zadanie, na przykład zaplanować trzydzieści minut na research i uznać rezultat uzyskany w tym czasie za wystarczający. Podejście good enough, połączone z ograniczeniem czasu na wykonanie zadania, pozwala uniknąć scenariusza, w którym kolejne godziny upływają na bezskutecznym szukaniu odpowiedzi. W przypadku researchu warto założyć, że jeśli po określonym czasie nie uda się jej znaleźć, należy przerwać poszukiwania i przejść dalej.

Kolejną techniką, zbliżoną do poprzedniej, są regularne przerwy w pracy. Choć brzmi to podobnie do metody Pomodoro, różni się od niej w szczegółach i w charakterze przerw. Oznacza to, że po 50 minutach pracy robisz regularną, dziesięciominutową przerwę. Czas przerwy powinien być czymś wyraźnie innym niż praca. Tu właśnie leży różnica w stosunku do Pomodoro, w tej metodzie przerwa może być krótsza i spędzona przy biurku, np. na przeczytaniu czegoś lekkiego dla relaksu. W podejściu 50–10 chodzi o przerwę fizyczną. Warto wstać od biurka, przewietrzyć pokój, rozprostować się, zrobić kilka ruchów, by przełamać długie siedzenie. Chodzi o realny odpoczynek od komputera i pracy umysłowej. Często to moment, by spojrzeć przez okno, dolać wody, zrobić kawę. W tym czasie warto skupić się na czymś zupełnie innym niż praca – chodzi o krótkie „naładowanie baterii” i powrót do kolejnego bloku z nową energią. Brak przerw powoduje spadek koncentracji, po około półtorej godziny uwaga zaczyna słabnąć, pojawia się zmęczenie i rozproszenie. Taka dziesięciominutowa przerwa jest potrzebna, by utrzymać skupienie. 

Warto położyć nacisk na fizyczny aspekt przerwy. Niezależnie od tego, czy praca ma charakter kreatywny, intelektualny czy powtarzalny, ciało prędzej czy później zaczyna się domagać odpoczynku, a nasze możliwości koncentracji są ograniczone. Stosowana praktyka 50–10 znalazła potwierdzenie w badaniach, które wskazują bardzo podobne wyniki. Badania pokazują, że optymalny czas pracy to 53 minuty, po których zalecana jest przerwa. Warto wstać, poruszyć się, spojrzeć w niebo, dać oczom odpocząć, zrobić spokojne wdechy, kilka prostych działań związanych z ciałem i chwilą oderwania się. Kulisy nagrywania mogą być przykładem tej praktyki, treść nagraliśmy w trzech blokach pięćdziesięciominutowych. Nawet podczas dłuższego spotkania po około 50 minutach robiliśmy przerwę, mimo pokusy, by dodać jeszcze jeden punkt lub coś poprawić.

Świadomie robiona przerwa jest częścią umowy między współpracującymi osobami lub obietnicą złożoną sobie. Próba „dociągnięcia jeszcze kilku minut” zwykle kończy się zmęczeniem, dlatego lepiej robić przerwy regularnie, by utrzymać energię i produktywność przez cały dzień.

To praktyka, która wydaje się oczywista i zrozumiała, ale dojście do niej często zajmuje trochę czasu. Ponieważ wiele osób wciąż jej nie stosuje, zdecydowaliśmy się ją wymienić. Chodzi o to, żeby w jakimkolwiek otoczeniu, w którym pracujesz, zadbać o możliwość izolacji, na przykład poprzez słuchawki wytłumiające lub muzykę, która sprawia, że mniej rozprasza otoczenie, mniej denerwują odgłosy, koty na korytarzu czy kurier przyjeżdżający do sąsiada, a może akurat do nas. Albo w tym najtrudniejszym scenariuszu, gdy praca odbywa się w biurze typu open space, gdzie naprawdę dużo się dzieje wokół i trudno się skupić. Dlatego warto świadomie zadbać o takie rozwiązanie, czasem nawet zainwestować w jakościowe, może droższe słuchawki, albo muzykę, która uspokaja i pozwala się skupić. Chodzi o to, by nie słyszeć otoczenia, by nie rozpraszało, nie spowalniało i nie irytowało, ponieważ wszystko to przekłada się na to, że każde zadanie trwa dłużej, a jego efekt może być gorszy.

Słuchawki wytłumiające okazały się jednym z największych odkryć w kontekście produktywności. Szczególnie uciążliwe bywały podróże pociągiem, gdzie wciąż brakuje zwyczaju zachowania ciszy w przedziale, a pasażerowie potrafią bez skrępowania prowadzić długie rozmowy telefoniczne. Osoby chcące w tym czasie poczytać książkę lub popracować przy komputerze mają trudność ze skupieniem, gdy w tle słychać czyjeś rozmowy. Możliwość odizolowania się od hałasu i dźwięków otoczenia staje się wtedy prawdziwym wybawieniem. Wystarczy założyć słuchawki, by natychmiast poczuć różnicę – dźwięki otoczenia stają się ledwo słyszalnym tłem, które przestaje przeszkadzać w skupieniu. Cicha muzyka w tle dodatkowo wzmacnia poczucie komfortu i tworzy wrażenie własnej, bezpiecznej przestrzeni do pracy. Co ciekawe, słuchawki nie muszą być używane wyłącznie w hałaśliwym otoczeniu. Nawet podczas pracy w domu mogą stanowić element rytuału, założenie słuchawek i włączenie ulubionej muzyki staje się sygnałem rozpoczęcia pracy. Słuchawki kojarzą się z momentem skupienia i produktywności, dlatego nawet bez potrzeby izolacji pomagają wejść w tryb pracy i utrzymać koncentrację.

Nie padło jeszcze, jaka to muzyka. Dla przykładu można wskazać, jaka muzyka sprawdza się najlepiej, bo ma to znaczenie. W tym przypadku najlepiej sprawdza się muzyka instrumentalna, jazz lub hip-hop w wersji bez wokalu, na przykład składanki podkładów DJ-a Premiera. Znajomość rytmu i brak tekstu sprzyjają skupieniu i utrzymaniu dobrego tempa pracy. Alternatywą i ciekawym odkryciem jest muzyka oparta na określonych częstotliwościach, jak w albumie Deep Healing, wykorzystującym tony o częstotliwości 432 Hz. Nie ma tam słów, to raczej ambient, dźwięki tworzące delikatne tło, które otacza i wycisza. Dobrze sprawdzają się jako przyjemne tło, sprzyjające skupieniu i spokojnej pracy. Muzyka ze słowami utrudnia skupienie, znajome utwory od razu przywołują w pamięci teksty i głosy, co rozprasza uwagę. Natomiast instrumentale – jak muzyka filmowa, spokojna elektronika czy chill-out – tworzą dobre tło do pracy i wspierają produktywność.

W kontekście wcześniejszego odniesienia do techniki Pomodoro, warto wspomnieć o praktyce blokowania stron niezwiązanych z pracą jako sposobie wspierania skupienia. Zastosowanie takiego rozwiązania wynika z obserwacji powtarzającego się schematu: przy mniej angażujących zadaniach pojawia się impuls, by odwiedzić jedną z „ulubionych” stron, czy to w poszukiwaniu ciekawostek, czy planując coś z zupełnie innego obszaru, np. sezon biegowy. To mechanizm, który w oczywisty sposób obniża koncentrację. Najczęściej ustawia się blokadę na godzinę, a przy większych tematach, na dwie godziny, z założeniem, że w połowie nastąpi przerwa. To forma cichej umowy z samym sobą, że w danym czasie, mimo przerwy, poświęcisz uwagę konkretnemu zagadnieniu. Nawet dziś zdarzają się sytuacje, gdy podczas pracy pojawia się impuls, by odwiedzić jedną z zablokowanych stron. Czasem odruchowo następuje kliknięcie i pojawia się ekran z komunikatem o blokadzie. To moment, w którym pojawia się w duchu taka myśl, za wcześniejszą decyzję o aktywacji blokady. To dobry przykład na to, jak łatwo wpaść w nieprzemyślane decyzje, mózg w poszukiwaniu dopaminy kieruje uwagę ku bodźcom niezwiązanym z pracą. W efekcie tracimy koncentrację i produktywność.

Ta praktyka może być szczególnie bliska osobom, które z niej nie korzystają – i odczuwają skutki braku ochrony przed rozpraszaczami. Wśród typowych pułapek znajdują się strony internetowe, filmy czy inne źródła bieżącej treści. Przykładem może być scrollowanie newsów, czy to na portalach informacyjnych, czy na platformach społecznościowych, takich jak X.com (dawniej Twitter). Wystarczy jedna ciekawa historia, nawet związana z pracą, by skutecznie „zabić” produktywny dzień. Dobrym przykładem jest LinkedIn, źródło zawodowych treści, ale również miejsce, w którym łatwo się zapętlić. Minuty mijają, zamieniają się w godziny, a produktywność dnia znika bez śladu. Nawet jeśli ta praktyka nie została jeszcze wdrożona, warto przyjrzeć się jej bliżej i zainspirować działaniem innych. Warto świadomie wykonać ten krok.

Nawet jeśli blokada stron nie jest stosowana, warto świadomie kontrolować to, co próbuje odciągnąć uwagę, od komunikatów po połączenia przychodzące. Przykładowo, w trakcie nagrania podcastu (co widać na wersji wideo) telefon ustawiamy w trybie samolotowym. Dzięki temu nikt przypadkiem do nas nie zadzwoni, ale też nie pojawi się żaden komunikat, o SMS-ie, wiadomości w komunikatorze czy jakimś powiadomieniu z aplikacji. Idąc dalej, można, podejść do tego jeszcze bardziej kompleksowo. Chodzi o takie ustawienie komputera i telefonu, żeby te wszystkie połączenia, powiadomienia, wyskakujące okienka, pingnięcia i dźwięki nie rozpraszały. Czasem to działa zupełnie nieświadomie, tuż przed nagraniem może przyjść wiadomość od klienta z pytaniem o współpracę. I już jakiś fragment uwagi przez cały czas zajmuje myśl: co trzeba będzie odpisać, jak się tym zająć. To może skutecznie rozwalić produktywność. Dlatego warto świadomie poustawiać sobie te wszystkie notyfikacje. Najlepiej większość z nich po prostu wyłączyć i zostawić tylko te, które naprawdę są potrzebne, a większość nie jest.

Powiadomienia bywają jednym z największych rozpraszaczy i zdecydowanie warto je eliminować. Gdyby wszystkim aplikacjom na komputerze i telefonie pozwolić na swobodny dostęp, można funkcjonować w stanie ciągłego reagowania na powiadomienia. Przykładem może być silny detoks od mediów społecznościowych. Obecność ograniczona jest w zasadzie wyłącznie do LinkedIna. Inne platformy jak X, Facebook czy Instagram nie są zainstalowane na telefonie, a dostęp na komputerze jest zablokowany przez brak zalogowania. Dodatkowa bariera np. konieczność użycia fizycznego klucza powoduje, że decyzja o wejściu musi być naprawdę świadoma. Często widać osoby, które podczas podróży na przykład w pociągu nieustannie odbierają kolejne powiadomienia. Wystarczy jedna trasa pociągiem, by zobaczyć, jak łatwo można spędzić godzinę, reagując na powiadomienia co minutę. Taki tryb działania trudno sobie wyobrazić, dlatego powiadomienia ograniczone są do absolutnego minimum, wyłącznie tych naprawdę krytycznych. Stosowane są co najmniej dwa poziomy odcięcia: jeden tryb pracy, który całkowicie wycisza wszystko. Żadnych połączeń, komunikatów ani dźwięków. Drugi łagodniejszy tryb „nie przeszkadzać” – pozwala na kontakt, tylko wybranym osobom, rodzinie czy konkretnym osobom oznaczonym jako ważne. Wybrane powiadomienia, od bezpośrednich współpracowników, mają swoją rangę, ale są wyjątkami. Również ustalenie wspólnych zasad kontaktu w zależności od pilności ułatwia zarządzanie powiadomieniami i ogranicza niepotrzebne dystraktory. Świadome zarządzanie wszystkimi bodźcami, którymi świat próbuje bombardować w czasie pracy, może naprawdę mocno podnieść produktywność,o ile pojawi się gotowość, by zrezygnować z FOMO. To przekonanie, że brak bieżących informacji oznacza stratę, może być złudne. Z doświadczenia, nawet jeśli coś zostaje „utracone”, to nie wpływa to na jakość życia. Wiele informacji powiela się w mediach, zmieniają się jedynie nagłówki. Tego typu treści, nawet jeśli powszechnie uznawane za ważne, wcale nie muszą być potrzebne do tak zwanego szczęścia.

W kontekście popularnych rozpraszaczy warto zwrócić uwagę na dwa narzędzia z rodziny Microsoftu Outlook i Teams, szczególnie obecne w środowiskach korporacyjnych. Rekomendacja jest prosta: warto wyłączyć wyskakujące powiadomienia o nowych wiadomościach e-mail. W typowym środowisku biurowym napływ e-maili jest nieprzerwany. Nie ma realnych szans, by nadążyć za wszystkimi wiadomościami. Co gorsza, fragment wiadomości wyświetlony w formie powiadomienia może całkowicie oderwać od wykonywanego zadania. Podobnie jest z komunikatorami w szczególności z Microsoft Teams, gdzie uczestnictwo w wielu kanałach może skutkować nieustannym strumieniem pingnięć, komunikatów i alertów. Warto skorzystać z możliwości systemu operacyjnego – zarówno Windows, jak i macOS i wyciszyć wszystkie niepotrzebne sygnały. Alternatywą może być korzystanie z dedykowanych trybów skupienia, które ograniczają zakłócenia tylko do niezbędnego minimum.

Tę praktykę warto omówić z dwóch perspektyw. Pierwsza dotyczy przygotowania przestrzeni przed rozpoczęciem pracy. Chodzi o przygotowanie wszystkich elementów niezbędnych do pracy, które, w zależności od osoby, mogą się różnić. Kluczowe jest, by nie trzeba było ich szukać czy po nie wstawać, każda taka czynność to potencjalne rozproszenie.

[Na koniec zachęcamy do refleksji, jak zapewniasz sobie produktywność osobistą, na ile nad tym panujesz, czy budujesz sobie nawyki albo, czy masz nawyki, które produktywność obniżają. Przykładowo: woda, kawa, przybory do pisania czy notatnik, to wszystko powinno znaleźć się w zasięgu ręki. Przejście do innego pomieszczenia, do kuchni, często kończy się niespodziewanym odciągnięciem uwagi. Dlatego przygotowanie wszystkich niezbędnych rzeczy z wyprzedzeniem, w tym zaplanowanie posiłków, pozwala ograniczyć potrzebę odchodzenia od biurka. Każde odejście od stanowiska pracy może wybić z rytmu i utrudnić powrót do skupienia.

Kolejna perspektywa dotyczy fizycznej przestrzeni pracy. Osoby oglądające nagranie mogą dostrzec konkretne przykłady organizacji stanowiska. W zasięgu ręki znajdują się karteczki, notatnik, zapas długopisów, drukarka, a także półka z najczęściej wykorzystywanymi książkami. Dzięki odpowiedniej organizacji przestrzeni można przepracować wiele godzin bez konieczności odchodzenia od biurka. Wszystko, co potrzebne, znajduje się w zasięgu ręki i ogranicza rozpraszacze. Szczególnie przy pracy zdalnej warto oddzielić przestrzeń przeznaczoną do pracy od tej, która służy rozrywce. Pomaga to w zachowaniu skupienia. Im łatwiej dostępny jest rozpraszacz, tym większe prawdopodobieństwo, że odciągnie uwagę od właściwego zadania. Przykładowo: książki o ogrodzie znajdują się w innym pomieszczeniu. Dzięki temu nie rozpraszają w czasie pracy. Jeśli pojawia się potrzeba pracy nad planowaniem ogrodu, trzeba fizycznie zmienić przestrzeń. 

Podsumowując, w materiale znalazło się jedenaście praktyk, które przetestowaliśmy lub regularnie stosujemy. To nie jest zamknięty katalog. Nikt nie ma złudzeń, że wdrożenie dokładnie tych praktyk automatycznie poprawi sytuację w każdej organizacji. Głównym celem było zachęcenie do refleksji nad osobistą produktywnością. Na ile świadomie podchodzi się do zarządzania uwagą i eliminowania przeszkód w skupieniu? Warto zadać sobie pytanie, czy budujesz sobie pozytywne nawyki, które pomagają ci w tej produktywności, albo czy masz takie nawyki, które tą produktywność obniżają i czy zdajesz sobie z nich sprawę i próbujesz coś z nimi robić?

Kolejna refleksja na zakończenie dotyczy możliwości przeniesienia wybranych praktyk z poziomu indywidualnego na poziom zespołowy. Lista zadań do wykonania może funkcjonować jako narzędzie wspólne dla całego zespołu. Wspólne planowanie dnia lub dłuższych okresów pracy to kolejna praktyka, którą można z powodzeniem stosować w grupie. Dzielenie pracy na mniejsze elementy oraz koncentracja na jednym zadaniu w danym momencie to zasady, które dobrze sprawdzają się również w pracy zespołowej. Łączenie w paczki zadań o podobnym charakterze także może przynieść efekty na poziomie całego zespołu. To przykłady działań, które nie muszą pozostawać wyłącznie w sferze indywidualnej, lecz mogą wspierać również zespołową efektywność i organizację pracy.

Produktywność to ilość pracy wykonanej w danym czasie, a efektywność to również wartość tej pracy. W praktyce – osoba produktywna częściej bywa efektywna.

Lista rzeczy do zrobienia odciąża pamięć i redukuje stres. Zamiast martwić się, że coś zapomnisz, zapisujesz wszystko w „trusted system” i możesz skupić się na działaniu.

Nie ma jednej reguły czy planować rano, czy wieczorem. Poranne planowanie daje świeże spojrzenie na priorytety dnia. Jeśli wieczorem wolisz zamknąć głowę na noc – to też dobry moment.

Małe kroki w realizacji wielkich planów są łatwiejsze do rozpoczęcia i szybsze do ukończenia. To daje dopaminową satysfakcję z postępu i motywuje do dalszej pracy.

Zasada One Piece Flow: realizujesz jedno zadanie od początku do końca, zanim ruszysz z kolejnym. Dzięki temu unikasz rozproszenia i kończysz więcej zadań w krótszym czasie.

Łączenie pracy w paczki to grupowanie podobnych zadań – np. odpowiadanie na maile, wystawianie faktur – w jeden blok czasowy. Pozwala szybciej wejść w rytm i skrócić łączny czas pracy.

W technice Pomodoro pracujesz w skupieniu przez 25 minut, po czym robisz krótką przerwę. Po kilku takich cyklach – dłuższa przerwa. Prosta metoda, która pomaga utrzymać uwagę i nie przeciążać się.

Pracujesz 50 minut i robisz 10 minut przerwy. Zrób reset dla ciała i mózgu. Wstań, przewietrz pokój, poruszaj się.

Izoluj się od dźwięków otoczenia za pomocą słuchawek wytłumiających lub muzyki bez słów. Taka praktyka pomaga zachować skupienie, nawet w hałaśliwym otoczeniu (np. open space czy pociąg).

Zablokuj sobie strony, które nie są potrzebne do pracy. Nawet krótkie „zajrzenie na chwilę” często kończy się 20-minutowym rozproszeniem. Aplikacja do blokowania stron to sposób na odzyskanie własnego czasu.

Notyfikacje mogą spowolnić Twoją pracę. Wyłącz wszystko, co nie jest naprawdę potrzebne. Ustaw tryb pracy, ogranicz powiadomienia, wycisz komunikatory. Każde „pingnięcie” to utrata skupienia.

Dobre zorganizowanie sobie przestrzeni roboczej to zadbanie, by wszystko, co potrzebne, było pod ręką, a rzeczy rozpraszające – poza zasięgiem. Czyste biurko i porządek w otoczeniu przekładają się na możliwość nieprzerwanej pracy w skupieniu.

Robienie listy zadań zapobiega przerywaniu pracy przez nagłe przypominanie sobie o innych obowiązkach. Przy decydowaniu o nowym zadaniu łatwo wrócić do ustalonej listy pomysłów.

Łącz w paczki zadania o charakterze asynchronicznym, które nie wymagają natychmiastowej reakcji. Mogą to też być zadania żmudne albo mało satysfakcjonujące lub takie, które wymagają dodatkowych przygotowań na starcie.

Produktywność członków zespołu jest skorelowana z efektywnością całego zespołu. Gdy każdy członek działa bardziej świadomie i kończy zadania, zamiast je rozgrzebywać, cała grupa staje się efektywniejsza — mniej chaosu, więcej realnych rezultatów.

Tego unikaj: brak planu dnia, reagowanie na powiadomienia w czasie pracy, odkładanie dużych zadań i multitasking. Te drobne, nieświadome zachowania codziennie „zjadają” godziny i obniżają Twoją produktywność.

Wybierz jedną praktykę i przetestuj ją przez tydzień — np. planowanie dnia lub przerwy 50/10. Nie próbuj wdrażać wszystkiego naraz; kluczem jest konsekwencja w budowaniu nowego nawyku, a nie skala zmian.

Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu Porządny Agile.

Jacek: Dzisiaj trochę inny odcinek niż nagrywamy zwykle. Będzie zdecydowanie bardziej z perspektywy osobistej. Natomiast uważamy z Kubą, że wszystko to co dzisiaj powiemy bardzo dobrze aplikuje się do pracy pojedynczego członka zespołu. Ponieważ  sumy efektywnych i produktywnych jednostek uzyskujemy efektywny zespół. Bez skupienia się na poziomie indywidualnym zespół będzie kosztował. Natomiast nie będzie generował tak dużej wartości.

Kuba: Konkretne praktyki, które wymienimy są głównie skupione na produktywności. Rozumiane jako ilości pracy, która dana osoba jest w stanie wykonać w jednej jednostce czasu. Na przykład w jednym dniu i jednym tygodniu. A nie efektywności, tak jak ją wspominamy w naszych dotychczasowych materiałach. Gdzie w efektywności patrzy się też na wartość pracy. Ale, jednak to na poziomie osobistym, na poziomie pojedynczej osoby jest to bardzo silnie skorelowane. Czyli osoba, która jest w stanie zamknąć trzy zadania dowolnego typu w trakcie dnia prawdopodobnie, jakby na to nie spojrzeć, będzie bardziej efektywna niż osoba, który tej zadań nie w stanie zrobić tylko jedno albo ma tak niepoukładany warsztat pracy, że nie robi nic. Tutaj cały odcinek będzie o tym, jak tak poukładać sobie pracę i tak wykonywać zadania, żeby być w stanie kończyć, dostarczać efekty z pracy, którą się ma.

Jacek: Spis treści na dzisiaj, to będzie lista konkretnych praktyk. I wymienimy i omówimy następujące praktyki. Lista rzeczy do zrobienia, planowanie dnia, dzielenie pracy na małe kawałki, skupianie się na jednej rzeczy na raz, łączenie pracy w paczki, technika Pomodoro, regularne przerwy, izolacja od dźwięków otoczenia, blokada stron niezwiązanych z pracą, blokada połączeń i powiadomień, organizacja przestrzeni do pracy.

Kuba: W tym sensie odcinek po prostu składa się z wejścia głębiej w te praktyki. Zacznijmy od pierwszej praktyki, czyli lista rzeczy do zrobienia. Co tutaj mamy na myśli? Jest to praktyka mocno zainspirowana chociażby metodą Getting Things Done, czyli koncepcja tego, żeby nie rozpraszać się myśleniem o tym, co jest do zrobienia, mieć mechanizmy, najlepiej listę rzeczy, konkretną, fizyczną albo elektroniczną, w której zapisywane są rzeczy, które są do zrobienia przez daną osobę. Im bardziej rozproszona nasza praca, im bardziej rozproszona wątki, które mam ja sam na głowie na przykład, tym bardziej zapominam o pewnych sprawach, przypominają one mi się w dość losowych momentach. To mnie denerwuje, to mnie stresuje, to czasami powoduje we mnie przerwanie pracy, którą wykonuję w danej chwili i przełączenie się na jakiś zupełnie inny wątek. Po tym, jak zacząłem sam mocno osobiście stosować listy rzeczy do zrobienia i zapisuję sobie takie listy, po prostu przestałem się martwić, przestałem się tym stresować, tylko po prostu wyrzucam sobie wszystkie te myśli na listę rzeczy do zrobienia. Mam ich kilka, mam jedną do rzeczy do zrobienia takich zawodowych, mam też listę rzeczy do zrobienia w ogrodzie, mam listę rzeczy do zrobienia w domu czy w życiu rodzinnym i z tych konkretnych list czerpię, gdy przychodzi dzień czy moment, żeby zacząć coś z tym robić, ale też na to listę rzeczy wrzucam, żeby się nie martwić, żeby one mi się nie przypominały, żeby mi się w szczególności nie przypominały. W najgorszym możliwym momencie, gdy jestem turbo skupiony na jakiejś prezentacji, a mi się przypomina, że mam wysłać ofertę albo odpowiedzieć na jakiegoś maila.

Jacek: Tak i ja podobnie jak Kuba stosuję też to podejście. Czytałem książkę lata temu, nie wspominam tego najlepiej, bo ta książka już te kilka lat temu miałem poczucie, że wymagałaby trochę odświeżenia, jak również miałem wrażenie, że pewne rzeczy są w dosyć taki powtarzalny sposób zapętlane i omawiane, ale innymi słowami. Niemniej sama ta koncepcja jak najbardziej ze mną rezonuje. W szczególności to autor oryginalnie nazywa Trusted System, o ile dobrze pamiętam, czyli takie jedno miejsce, w którym zawsze wiemy, że możemy pewne rzeczy zapisać i wiemy, że one tam będą. I to co Kuba mówisz o tym, że sobie przypominasz, pewne rzeczy w trakcie, kiedy wykonujesz jakieś konkretne zadania, to mam bardzo podobnie i działa to u mnie w ten sposób, że jeśli mi taka myśl przyjdzie, niepokojąca np. miałem zrobić coś tam, to po prostu wyrobiłem sobie nawyk używania szybko skrótu klawiaturowego, wpisuję to zadanie w moim przypadku akurat do aplikacji To Do List i po prostu zamykam. Całość trwa 3 sekundy, a ja zyskuję pewność, że żadna myśl, która mi przychodzi do głowy i albo jest sensowna, albo ocenię za jakiś czas, czy jest sensowna, wiem, że taka myśl mi nie uleci.

Kuba: Taki komentarz, jak to się przykłada na produktywność, bo to może wprost od nas nie padło, no to tutaj wiele z praktyk, które będziemy wymieniać w dalszej części tego materiału, będzie orbitowała wokół skupienia, wokół kończenia. No i jednym z najtrudniejszych właśnie przerwań to jest taka pętla niekończącego się myślenia o rzeczach, które są do zrobienia, przypominania sobie, próbowania o nich ciągle myśleć zamiast je robić. Więc tutaj jest taki koncept zrzuć je na listę, nie myśl o nich, gdy je nie robisz, albo miej miejsce, z którego zaczerpniesz następną rzecz do zrobienia, gdy będzie właśnie okienko, żeby coś zrobić.

Jacek: Druga praktyka, którą chcemy się podzielić, to praktyka planowanie dnia. Posiadanie listy rzeczy do zrobienia jest bardzo przydatne, natomiast to, co trzeba zrobić w kolejnym kroku z taką listą, to jednak przysiąść i zastanowić się dobrze, to co z tej listy powinienem albo chcę, albo muszę zrobić dzisiaj. Różne ludzie mają podejścia do tego momentu, kiedy występuje planowanie. Takie dwa najpopularniejsze podejścia, które spotykam, to jest albo to jest wykonywane wieczorem na kolejny dzień, albo jest to wykonywane rano. Z mojej perspektywy akurat mi najbardziej działa to planowanie od rana, czyli zanim zacznę jakiekolwiek działania wykonywać w danym dniu, przeglądam sobie tę listę, oceniam, co powinno się wydarzyć dzisiaj albo co chciałbym zrealizować dzisiaj. Poświęcam na to od 5 do 15 minut i tak naprawdę wchodzę w dzień z poczuciem, że o żadnej istotnej rzeczy nie zapomniałem. 

Kuba: I tutaj jest praktyka, która fajnie może się połączyć jednak z efektywnością osobistą, ale nie tylko z produktywnością, czyli przeglądając sobie ten plan dnia, ja też to robię z rana, mogę ocenić, co jest najbardziej wartościowe, co mogę zrobić dzisiaj, co jest realne, że w ogóle zrobię dzisiaj. No i też skupić się właśnie na dokładnie tych rzeczach, które najważniejsze efekty dadzą. Są rzeczy, które mogą poczekać, są rzeczy, które może są tylko takimi chciejkami, fajnie byłoby je zrobić, to jest dokładnie ten moment, żeby być bardzo szczerym względem siebie, codziennie rano się zastanowić, czy da się to zrobić i co spośród tego, co jestem w stanie zrobić jest wartościowe, może co jest takim highlightem dnia, a jeśli stosujemy Scruma, to może tutaj też jest miejsce na taką koncepcję celu dnia. Czyli jakaś rzecz, którą chcę szczególnie osiągnąć, coś, co mnie szczególnie przyświeca. Swoją drogą to się ze sobą łączy, czyli tak jak Jacek to przedstawił, czyli ta lista rzeczy do zrobienia, czyli pierwsza praktyka wymieniona przez nas, no to to może być właśnie takie źródło, z którego czepiemy pomysły na to, jak i co sobie zaplanować na ten konkretny dzień.

Kuba: Trzecią praktyką, którą dorzucamy do puli, to dzielenie pracy na małe kawałki. Jednym z powodów zarówno nie podejmowania zadania, gdyż ewentualnego utknięcia w zadaniach zbyt dużych i takiego rozwleczenia, może być to, że próbujemy przełknąć za duży kawałek, mówiąc potocznie, czyli zabieramy się za jakieś zadanie, które jest za duże. W moim przypadku to jest ewidentnie nawet odwlekanie tego, że sama perspektywa, że mam coś dużego przed sobą, powoduje, że na przykład czuję, że nie podołam, nie skończę, będę się denerwował rozgrzebie i z tego powodu pewnych rzeczy nie realizuję, a jeszcze w najgorszym scenariuszu próbuję się za nie zabrać, ale jednak się za nie zabieram i nic nie robię w tym momencie czy w tamtym okresie. Więc tutaj zdecydowanie rekomendujemy podzielić pracę na małe kawałki. To mogą być dosłownie pojedyncze czynności do wykonania, użyję takiego przykładu przygotowania prezentacji. Żeby przygotować na przykład jakąś prezentację inspiracyjną godzinną, no to mogę to rozdzielić na najdrobniejsze możliwe cząstki, jakie mi przychodzą do głowy, czyli wymyślić, o czym w ogóle coś chcę powiedzieć. To już jest jedno zadanie i to jest osobne zadanie, zapisać parę notatek. Oddzielnie to jest założyć sobie jakiś plik i jakiś totalnie szkielet, zrobić wstęp, strona tytułowa i może przekopiować podziękowanie za pytania. No i oddzielnymi punktami będą te pojedyncze slajdy, każdy jeden to jest w zasadzie osobne zadanie, może też osobne zadanie, to jest przejrzeć całość. I zwłaszcza jeśli stosujemy listę rzeczy do zrobienia, jeśli sobie też tak bardzo dozujemy skupienie, no to może się okazać, że te trudniejsze, wielkie rzeczy po prostu są rozwijane na gruncie rzeczy banalne, oddzielne taski i takie małe cząstki, które można domknąć, przeskoczyć na następną albo wrócić do tego na przykład dopiero jutro czy pojutrze, jeśli nie mamy na to przestrzeni czy siły.

Jacek: I istotnym aspektem dzielenia tej pracy na małe kawałki jest też ten aspekt takiego poczucia, że faktycznie coś zrobiliśmy, czyli zrobienie małego zadania daje nam bardzo szybko taką dopaminową nagrodę, że coś odhaczamy, zwykle w aplikacji, jeżeli to robimy na komputerze czy na telefonie, towarzyszy temu jakiś dźwięk, jakaś animacja, coś, co już mamy w pewnym sensie zaprogramowane, że to jest fajne, w sensie lubimy ten moment, kiedy te rzeczy odhaczamy i kiedy je wykonujemy, więc to jest taki aspekt psychologiczny. A z drugiej strony, jeśli chodzi o mnie, ja bardzo często bez podzielenia na małe kawałki tak do końca nie wiem jeszcze, co powinienem zrobić, więc sam proces dzielenia jest dla mnie jednocześnie też takim momentem, kiedy zastanawiam się, co bym chciał uzyskać, od razu w głowie mi się pojawiają różne ścieżki dojścia do rozwiązania, takie superproste, coś co jestem w stanie zrobić szybko, jakieś warianty pośrednie, też takie warianty najbardziej rozbudowane. I w zależności od sytuacji, od tego ile mam czasu, ile mam energii, jak bardzo lubię ten konkretny temat, wybieram sobie jedną z tych ścieżek i rozbijam sobie to na mniejsze, krótsze zadania, które wiem, że nie będę miał problemu, żeby w ogóle je podjąć, bo w głowie sobie mówię, przecież zrobisz to w 15 minut. Tu z kolei odpala się ta sztuczka, że jeśli już coś zaczniemy robić, to jest nam trochę trudniej przestać, więc z mojej perspektywy takie dziubanie tych tematów do zrobienia małymi kawałkami jest też bardzo fajnym sposobem na to, żeby się za tę pracę po prostu zabrać i żeby ona zaczęła w naszych rękach się wykonywać, a jednocześnie też znikać.

Kuba: Jest jeszcze dodatkowy efekt boczny dzielenia, może się okazać, że praca po podzieleniu będzie miała cząstki bardziej wartościowe czy właśnie totalnie pomijane, co też warto sobie bardzo świadomie na wczesnym etapie zauważyć, poukładać i być może również bardzo świadomie zrezygnować z niektórych elementów, które np. wymagają czasu, a w sumie wartości dodanej, jakkolwiek ją mierzymy czy jakkolwiek ją sobie identyfikujemy, po prostu w tym czymś nie ma. Czyli powiedzmy idąc tropem tej prezentacji np. w moim przypadku najczęściej rezygnuję z notatek dla prelegenta, bo choć fajnie byłoby je mieć, wiem, że za bardzo i tak zazwyczaj mi nie pomagają, więc jednak z nich zupełnie rezygnuję.

Jacek: Kolejna praktyka, która się nam bardzo dobrze sprawdza, to praktyka skupienia się na jednej rzeczy na raz. Polega ona na tym, że dążymy do realizacji jednego konkretnego tematu, czy jednego konkretnego zadania od samego początku, aż do momentu, kiedy nie będzie to zadanie zrealizowane. Czyli osobiście podchodzę do tego w ten sposób, że nawet jeżeli mam jakieś drobne przerwania, które muszę obsłużyć w trakcie realizacji jakiegoś większego zadania, to jednak nawet, jeśli z tych przerwań wynikają jakieś kolejne zadania, które mógłbym zrealizować i może nawet chciałbym je zrealizować, to jednak świadomie staram się wracać do tego pierwotnego zadania, które rozpocząłem, po to, żeby ono się nie rozwlekało w czasie. Po pierwsze, ryzyko jest takie, że mogę stracić skupienie i zostawię je na dłuższy czas rozgrzebane, a jednak był jakiś powód, dla którego je rozpocząłem. A drugi aspekt jest taki, że ono po prostu będzie się ciągnąć. Ten czas przestojów, ten czas, kiedy poświęcam się na coś innego niż to zadanie, chcąc nie chcąc, powoduje, że patrząc tak ze strony procesowej, to czas realizacji tego konkretnego zadania po prostu będzie rósł, pomimo iż aktywnie nie wkładam w to zadanie żadnej pracy. drobniejsze, robione na kilka razy, czyli z kilkoma podejściami po przerwaniu, powrót do zadania, które zostały już trochę rozgrzebane. No, koszt ich rośnie strasznie. Może się okazać, że coś, co powinno zająć się parę minut, sumarycznie zajmuje kilkanaście czy kilkadziesiąt minut, bo co się próbowało w nie wejść, to się człowiek rozproszył albo przeskoczył na jakieś inne zadanie. Więc tutaj też się ćwiczę w tym skupieniu. Sam osobiście miewam tendencję właśnie do rozproszeń, do takiego podejścia, a skoro już coś ciekawego znalazłem, to jakby łapię za ten sznureczek i zaczynam za niego ciągnąć i gdzieś tam dwie zakładki dalej się orientuję, że przecież miałem odpowiedzieć na maila, a nie przeglądać się na jakieś nowe newsy z jakiejś merytoryki najnowszych zmian w branży, więc tutaj takie świadome założenie sobie samemu, obiecanie sobie samemu, że będę się skupiać na tej rzeczy, którą właśnie podjąłem i też dążenie ze wszystkich sił do tego, żeby po prostu je odhaczyć, zamknąć, odhaczyć na liście, co tam będzie wracało, czyli ucieszyć się z tego domknięcia, zamknięcia i dopiero wtedy ewentualnie zastanowić się, co jest tą następną rzeczą, którą mogę podjąć i tak najlepiej to wpaść w taki ciąg kolejnych, pojedynczych rzeczy, które są domknięte, a jako przeciwieństwo modelu, w którym jest mnóstwo rozgrzebanych wątków, pełno pootwieranych zakładek, kilka maili w szkicu, czy kilka stron w edycji, kilka plików otwartych, na których ciągle coś tam jest, jakiś wątek, no tak przyrysowuję to, ale sam to mam i co gorsza, czasem jak zajrzę komuś przez ramię do komputera innej osoby, to też to widzę, że tam w zasadzie co zakładka, to otwarty wątek. I niestety tak jak komp lekko siada, gdy próbuję nadążyć za tym, żeby przerobić te wszystkie zakładki, tak samo uważam, jakby skupienie osobiste też lekko siada i człowiek się łatwo, szybko męczy.

Kuba: Piąta praktyka, którą proponujemy, to łączenie pracy w paczki. Tutaj może być pewien paradoks, bo być może w niektórych przypadkach to łączenie pracy w paczki jest trochę w kontrze do tego skupienia się na jednej rzeczy na raz, ale uważam, że są te momenty, gdy świadomie warto coś tego zrobić.  Na czym to polega? Chodzi o to, żeby łączyć podobne do siebie zadania w takie paczki czy grupy, czy serie zadań wykonanych pod rząd jednocześnie, robienie ich razem w każdym razie. Jeśli są to zadania dość do siebie podobne i jest jakiś efekt pozytywny, jakaś synergia, jakieś zrobienie tego jednocześnie, czy jest jakiś korzyść z tego, czy to psychologiczna, czy nawet dosłownie jakaś fizyczna oszczędność czasu czy oszczędność jakichś pieniędzy, to może ma sens to wszystko ze sobą połączyć i zrealizować je jednocześnie albo blisko siebie, jedno po drugim, ale w planie dnia mieć taki okres, żeby coś takiego zrobić. Jacek może zarzuć przykładem, o co chodzi.

Jacek: Tak, dla mnie robię takie dwa przykłady wykorzystania tego w praktyce. Pierwszy przykład to jest sposób, w jaki pracuję z pocztą, czyli, zamiast odpowiadać na bieżąco na każdego maila, który wpadnie i w ogóle często sprawdzać pocztę, to to cały czas pracuję nad nawykiem, żeby do poczty podchodzić na zasadzie, jeśli już usiądę do poczty, no to po prostu przejdę po tym wszystkim, co widzę nowe, co przyszło do mnie jako wiadomości przychodzące. Łączę to czasem z tym podejściem GTD, czyli jeżeli coś widzę, procesuję pojedynczego maila, widzę, że mogę szybko odpowiedzieć, to po prostu odpisuję, a jeżeli nie, to tworzę sobie z takiego maila zadanie, żeby móc go zarchiwizować i mieć poczucie, że nic nie zalega mi w tej skrzynce tematów nadchodzących, ale z drugiej strony mam to odzwierciedlone już jako task do zrobienia, więc mam pewność, że tego nie zapomnę. Łapię się na tym, że bardzo mocno potrafię się w to wkręcić i naprawdę sam na koniec bywam zaskoczony, jak w sumie niewiele czasu ostatecznie potrzeba w skupieniu, żeby doprowadzić do inboxa zero. Więc to jest coś, co bardzo dobrze się sprawdza. Z drugiej strony rzecz, którą w tym sensie prokrastynuję, odkładam na później, to są wszystkie takie rzeczy związane z podsumowaniem miesiąca od strony takiej fakturowo-finansowej, więc akurat tych faktur przychodzących nie robię tak jak GTD nakazuje od razu, tylko wszystko ląduje w odpowiednim miejscu na biurku i po prostu jak przychodzi ten moment, kiedy po prostu muszę już ten miesiąc zamknąć, to wtedy biorę i po prostu wszystko przeprocesowuję i faktury przychodzące i faktury, które musiałem wystawić, koszty, wszystko skanuję, wysyłam gdzie trzeba i po prostu mam takie poczucie, że akurat tego nie lubię robić, więc wiem, że jak usiądę, to zrobię wszystko, co jest do zrobienia w tym temacie i jest ta radość, że zrobiłem to i kolejny raz to będzie dopiero za miesiąc.

Kuba: Osobie, która słucha tego, co Jacek opowiada, zwrócę uwagę na jedną kwestię, że szczególnie do takiego łączenia pracy w paczki nadają się rzeczy, które mają taką asymfoniczną naturę, czyli mail przysłany może np. poczekać do końca dnia, nie każe odpowiadać natychmiast, np. księgowa poczeka do umówionej daty końca miesiąca, a nie, że natychmiast mi się wszystko spływasz na bieżąco i pewnie znamy wszyscy i każdy, kto tego słucha, ma też tego typu pracę. Warto mieć to po prostu świadomie ustawione. Pewna praca łączy się w takie paczki pracy i też nie każde zadanie, które do nas spływa, wymaga natychmiastowej reakcji i czasami jest wielu względów akurat różnych dla każdego, pewnie indywidualnie, ale powody, żeby sobie takie łączenie porobić.

Jacek: I zanim przejdziemy do kolejnych praktyk, przypominamy, że jeżeli chcesz pogłębić wiedzę jeszcze bardziej niż robimy to w podcaście, to znajdziesz nasze płatne produkty na stronie porzadnyagile.pl/sklep.

Kuba: Szósta technika rekomendowana to technika Pomodoro. Tutaj akurat z Jackiem mamy różnicę, Jacek tego nie korzysta. Ja sobie to poćwiczyłem, więc może będzie bardziej o mnie, a Jacek ewentualnie dorzuci jakąś swoją perspektywę, może też komentarz, dlaczego nie używa. Czym jest technika Pomodoro? Ona jest moim zdaniem dosyć popularna, więc mogłaś się już z tym spotkać. Opowiem tak, jak ja to rozumiem. Pomodoro to metoda zarządzania czasem, taka metoda skupienia osobistego. Nazwa techniki pochodzi wprost od zegarka kuchennego, która kręca po to, żeby sobie nawet fizycznie pokazać sobie i może swojemu otoczeniu, jeśli pracujemy w jakimś tam otoczeniu, że jesteśmy skupieni, że sobie zaplanowaliśmy pracę w skupieniu i że ustawiliśmy sobie w wyrozumieniu scrumowym taki timebox, taki limit czasowy, w czasie którego sami sobie obiecujemy, że się skupiamy i całe otoczenie też widzi, że jesteśmy skupieni na tym odcinku czasowym. Taki osobiście przeze mnie polecany odcinek czasowy to 25 minut. To jest już długo, żeby coś konkretnie zrobić, a jednocześnie wystarczy na co krótko, żeby samemu się na początku przymusić do tego, żeby pewne rzeczy odłożyć na późno. Tutaj technika jest w zasadzie prosta jak drut. Jeśli się on nie opowiada, umawiam się sam ze sobą i ustawiam sobie również jakiś formę czasu, odliczania tego czasu, żeby zrealizować w skupieniu to coś, pracować w skupieniu. Potem, gdy upłynie nie ten czas, zrobić sobie krótką, świadomą przerwę, odetchnąć, być może jednak dać się rozproszyć na chwilę innymi rzeczami. No i oczywiście w modelu takim ciągłym, to przejść do następnego Pomodoro, następnego bloku czasowego, na przykład tych kolejnych 25 minut znowu w maksymalnym możliwym skupieniu. 

Jacek: No to w sumie, słucham, jak o tym opowiadasz, to w pewnym sensie stosuję to podejście, ale nie w takim oryginalnym czy tym proponowanym wymiarze czasowym, raczej pracuję w blokach godzinnych i po tej godzinie robię sobie przerwę. I w sumie trochę więcej o tym powiem, myślę, w dalszej części odcinka, bo to jest powiązane z jeszcze jedną praktyką. Natomiast takie krótkie odcinki czasu daję sobie, ale nie w jakiś taki sposób usystematyzowany. Kiedy wiem, że coś jest do zrobienia, nie chcę popłynąć za bardzo z tym tematem, chcę jak najszybciej dopłynąć do brzegu, zrobić, no to mówię sobie, dobra, 15 minut i nie więcej. I to co w te 15 minut przygotuję, to po prostu uznaję, że to będzie takie wystarczająco dobre, żeby z tym pójść dalej. Czyli na przykład ostatnio pisałem maila do klienta i taka trochę nam się wyłoniła dłuższa rozmowa i postanowiłem, że to trzeba jednak zamknąć w krótkiej wiadomości, w krótkim mailu. Nie chciałem ciągnąć tego rozpisywania, więc postarałem się maksymalnie w skondensowany sposób odpisać jednocześnie zachęcając do tego, że moglibyśmy w sumie się jednak zdzwonić, no bo po prostu temat, który omawialiśmy, mam poczucie, że o wiele szybciej rozwiążemy, jak zdzwonimy się, czy telefonicznie, czy na jakimś tam Zoomie, Teamsach, czy w jakimś innym narzędziu online.

Kuba: Zwrócę uwagę na ten przykład Jacka, bo tutaj niektóre osoby, ja sam też w niektórych sferach tak mam, że może być pokusa pracowania tak długo, jak to tylko możliwe, żeby dopieścić. Mail to jest nawet najbardziej możliwy banalny poziom, na przykład projektuję grafikę, wykonuję jakiś research, przygotowuję jakiś raport. W zasadzie, zwłaszcza jeśli nie mamy jakiegoś ograniczenia związanego z deadline’em, no to może się okazać, że w nieskończoność jest próba jeszcze do precyzowania, dopolerowania, doszlifowania tego rozwiązania. Tutaj bardzo świadome powiedzenie sobie, ok, daję sobie na ten research pół godziny, to co osiągnę w te pół godziny to miało być to właśnie to i nie ciągnę tego dłużej. Być może takie good enough podejście właśnie połączone z takim limitowaniem sobie czasu, ile czasu chcę poświęcić na to sprawdzenie, no albo w tym czarnym scenariuszu akurat w researchu to jest możliwe powiedzenie sobie, ok, w pół godziny nie znalazłem odpowiedzi na pytania, jakiego szukam, może nie ma tej odpowiedzi, ale w szczególności, żeby się nie okazało, że resztę dnia spędzę na poszukiwaniu optymalnego scenariusza na pozycjonowanie mojej strony. Już tego dnia nic więcej nie zrobię.

Jacek: Kolejna technika trochę podobna do tej poprzedniej, ale jednak myślę, że w detalach się różni i to są regularne przerwy. Coś, co z Kubą praktykujemy i bardzo często też promujemy to podejście wśród naszych klientów, to jest w szczególności, gdy mówimy o takiej pracy, która odbywa się w trybie online, to jest praktyka, którą nazwaliśmy 50-10. Czyli po 50 minutach pracy online robimy sobie regularne 10 minut przerwy. Ten czas, który jest przerwą, ma być ewidentnie takim czymś wyraźnie innym niż praca i tutaj jest, myślę, ta różnica też w Pomodoro, gdzie ja sobie tak wyobrażam, że faktycznie tak w tej pięciominutowej przerwie pomiędzy kolejnym blokiem ja nie muszę wstawać od biurka, a mogę sobie właśnie wejść w jakąś tam stronę, poczytać sobie rzeczy, które będą dla mnie formą relaksu, natomiast tutaj w tym podejściu 50-10 jednak bardziej chodzi o taką fizyczną przerwę, czyli w moim przypadku ja lubię wstać, bardzo często automatycznie otwieram sobie okno w pokoju, żeby trochę przewietrzyć, wychodzę z pokoju, jak pamiętam, to wychodząc z pokoju zawieszony drążek, taki nie do podciągania, a raczej właśnie, żeby sobie na nim zawisnąć, żeby trochę się rozprostować, rozciągnąć, przełamać trochę siedzenie, no i po prostu chodzi o fizyczny odpoczynek, od komputera, od tej pracy, którą wykonywaliśmy. Więc bardzo często to jest czas, kiedy też spojrzę na ogród, doleję sobie wody, zrobię sobie kawę. Jakby skupię się na czymś zupełnie innym, niż wykonywana praca, żeby tak troszeczkę, mówiąc potocznie, podładować baterie i wrócić do kolejnego slotu naładowany, świeży. No bo, gdy tych przerw nie ma, to mam takie poczucie przynajmniej, jeśli chodzi o mnie, że tak półtorej godziny jestem w stanie utrzymać uwagę, zresztą Kuba to może potwierdzić, natomiast no później już zaczynam niestety kiepsko performować, mówiąc po staropolsku, rozpraszam się, gubię skupienie, no i tak fizycznie całym sobą czuję, że takie 10 minut przerwy jest mi bardzo potrzebne.

Kuba: Więc położę tutaj nacisk na tą taką przerwę z fizycznym aspektem, zwłaszcza jeśli pracujesz kreatywnie, jeśli pracujesz ze swoim mózgiem, a nawet jeśli to jest praca nawet w jakimś sensie powtarzalna, ale jednak wymagająca skupienia, to ta fizyczna strona zaczyna się upominać, mamy skończone możliwości. Stosowaliśmy tę praktykę 50-10, potem się okazało, że nawet są konkretne badania, które praktycznie identyczne wyniki podają, bodajże, jeśli dobrze sobie przypominam. Dokładnie zbadane jest, że to jest 53 minuty, gdzie jest zalecane, żeby po 53 minutach zrobić tę przerwę. I tak właśnie jak Jacek opowiadał o tej fizycznej stronie, wstać, poruszać się, spojrzeć w niebo, dać odpocząć oczom i pewnie spokojne wdechy zrobić, no parę innych mechanizmów związanych już naprawdę tak dosłownie z ciałem i z taką chwilą odpoczynku, chwilą oderwania się. Tak zdradzając trochę kulisy nagrywania, tą treść, którą teraz właśnie nagrywamy, którą właśnie słuchasz, powstała w trzech blokach 50-minutowych, gdzie my się z Jackiem spotkaliśmy na długie spotkanie, ale nadal w ramach tego spotkania sobie mówimy, okej, płynęło 50 minut, oczywiście plus minus, czas na przerwę, nawet jeśli wszystko mi każe powiedzieć, aj, jeszcze ten punkt dopiszmy, jeszcze tu coś przeformujmy. Nie, powstrzymujemy się, świadomie sobie przerywamy, to w przypadku pracy wy dwóch, tutaj jest nasza umowa w przypadku produktywności osobistej, to jest po prostu obietnica samemu sobie, że okej, może jeszcze minutę uciągnę, może nawet jeszcze 10 minut lub ciągnę, ale to na koniec dnia się zemści, bo już po całym dniu będę na maksa styrany i lepiej jednak sobie to dozować i te przerwy robić, żeby zajść dłużej i z całego dnia też tej produktywności więcej uzyskać.

Kuba: Następna praktyka to izolacja od dźwięków otoczenia. Tu mam poczucie, że ona jest samoczytająca się, bardzo zrozumiała, ale też chwilę zajęło, żeby do niej dojść i czasem widzę osobę, której nie stosują, więc podjęliśmy decyzję, że jednak ją wymienimy. Chodzi o to, żeby w jakimkolwiek otoczeniu nie jesteś, czy pracujesz jednak zrobić coś takiego, na przykład słuchawki wytłumiające, zapuszczenie sobie muzyki, która powoduje, że trochę mniej rozprasza nas otoczenie, że trochę mniej denerwuje się, że nie skaczą koty po korytarzu albo że do sąsiada przyjechał kurier, a może to ode mnie przyjechał. Czy w tym najczarniejszym scenariuszu, gdy się pracuje w biurze z otoczeniem typu open space, że naprawdę dużo się dzieje wokół mnie i trudno się skupić? Więc tutaj świadome zadbanie, najczęściej też może zainwestowanie w jakieś rozwiązanie, na przykład konkretne, jakościowe, rzeczywiście trochę droższe słuchawki, zadbanie o to, żebym mógł sobie puścić muzykę, która cię uspokaja, która ci pozwoli się skupić, tak żeby tego otoczenia nie słyszeć, żeby nie rozpraszało, żeby nie spowadniało, czy nawet żeby nie irytowało, bo to wszystko się przekłada na to, że każdy zadanie, które się wykonuje, trwa dłużej, a jego efekt może być też gorszy.

Jacek: Dla mnie słuchawki wytłumiające były jednym z takich największych odkryć, jeśli chodzi o produktywność. W szczególności męczyły mnie wycieczki pociągiem, gdzie jednak tej kultury w miarę zachowania się cicho w przedziale, ja nadal nie dostrzegam, ludzie potrafią bez skrępowania godzinę rozmawiać przez telefon. No i jako osoba, która ten czas chce wykorzystać czy na poczytanie sobie jakieś książki, czy na zrobienie czegoś na komputerze, no to ja po prostu nie potrafię się skupić, jak słyszę jakąś tam opowieść, którą ktoś toczy przez telefon, więc możliwość w dowolnym momencie odizolowania się od hałasów, rozmów, po prostu jest dla mnie wybawieniem. I to właściwie jak ręką odjął zakładam słuchawki, czuję ten moment, kiedy właśnie mnie odcina gdzieś tam w tle oczywiście słyszę, że ktoś tam coś mówi, ale to już jest naprawdę absolutne tło. Jak do tego cicho sobie włączę muzykę, to już jest absolutne poczucie, że jestem w takiej swojej bezpiecznej strefie. Co ciekawe, nie zawsze zakładam słuchawki tylko w sytuacjach, kiedy jest hałas. Zauważyłem, że nawet jak jestem sam w domu i pracuję z domu, lubię założyć słuchawki, włączyć sobie muzykę, którą lubię, bo są to takie skojarzenia z pracą. Czyli jestem produktywny, kiedy mam słuchawki na uszach i po prostu zauważyłem, że nawet jeśli nie potrzebuję tej izolacji, to pewne nawyki pokazują mi, że to jest ten moment, kiedy będziesz skupiony na pracy.

Kuba: Nie powiedziełeś jaka to myzyka. Na rozpęd ja powiem, jaka to jest w moim przypadku, bo to też jest muzyka, to ma znaczenie. Zaraz Jacek pewnie powie pewnie więcej.  W moim przypadku jest to albo instrumentalny jazz, kiedyś jeszcze instrumentalny hip-hop, to są akurat składanki podkładów DJ’a Premiera, bez żadnego tekstu, ale znałem te kawałki i mi się głowa sama bujała.

Jacek: Tak, dla mnie takim sporym odkryciem jest taka muzyka, nie wiem w sumie, czy to jest jakiś typ muzyki, ale to, czego najczęściej słucham, to jest taki album Deep Healing i to są dźwięki na bardzo określonych częstotliwościach, tutaj akurat te 432. Nie ma tam słów, trudno też mówić, że to jest muzyka, to jest bardziej taki dźwięk, najbliżej bym to nazwał, że to jakiś ambient, jakieś takie dźwięki, które nas otaczają. One po prostu są o tyle dobre, że robią mi takie przyjemne tło, dobrze mi się przy tym pracuje. Dla mnie absolutnie to, co Kuba mówisz, bo słuchając sporo muzyki hip-hopowej, to znam te numery i te instrumentale po prostu od razu mi słyszę te zwrotki, które tam są, słyszę ten głos, więc dla mnie muzyka ze słowami jest absolutnie nieakceptowalna, ale właśnie takie instrumentale, ala np. muzyka filmowa czy jakieś takie instrumentale gdzieś tam z pogranicza muzyki elektronicznej, ale spokojnej, bardziej taki chill-out, to jest coś, co tworzy mi dobre tło do produktywności.

Jacek: Kolejna praktyka blokada stron niezwiązanych z pracą. Wspomniałem, jak Kuba mówił o Pomodoro, że odniosę się do tego później i dla mnie trochę takim meta poziomem robienia sobie skupienia jest właśnie blokowanie stron niezwiązanych z pracą. Mianowicie polega to na tym, że włączam w sobie aplikację, która odcina mi dostęp do stron, na które bym wszedł, gdybym chciał zająć się czymś innym niż pracą, czyli wszelkiego rodzaju e-commerce, jakieś tam strony społecznościowe, ostatnio to ograniczyłem, czy stronki piszące np. o technologii sportowej. Jest to temat, który śledzę, to to wszystko mam poblokowane, bo zauważyłem taki naturalny wzorzec, że jak robię coś, co niekoniecznie mnie pasjonuje, to sobie myślę, spojrzę na stronkę X czy na stronkę Y, albo myślę sobie, że świetnie byłoby zaplanować właśnie teraz sezon biegowy, więc muszę oczywiście wejść na jakieś strony, poczytać, zasilić się wiedzą, no i to oczywiście jest zgubne. Więc ja najczęściej włączam sobie takie bloki na godzinę, jeżeli mam duży temat, to blokuję sobie na dwie godziny, wiedząc, że i tak w przerwie, tak mniej więcej gdzieś w połowie zrobię sobie stop. Ale to jest też taka trochę umowa sama ze sobą, że ok, te dwie godziny wiadomo, że z przerwą, ale jednak planuję poświęcić na jakiś tam konkretny temat. I łapię się do dzisiaj na tym, że robię coś i myślę sobie, a, bym sobie teraz tam wszedł na jakąś stronkę. No i nawet czasem wchodzę i dostaję ten ekran taki mówiący, strona zablokowana i wtedy się w duchu cieszę, że dobrze, że włączyłem jednak tą apkę, która te strony blokuje, no bo widzę, czasem są to takie nie do końca przemyślane decyzje i jednak mózg w poszukiwaniu dopaminy i rzeczy ciekawych potrafi nas zwiewać na obszary, które w danym momencie niekoniecznie są nam potrzebne do zwiększania produktywności.

Kuba: W tej praktyce mogą być co najbliżej, szczerze powiem, gościu właśnie nie robi tego i strasznie na tym cierpi, że w ramach rozpraszaczy są te strony, jakieś filmy, jakieś strony ciekawe czy nawet po prostu bieżące newsy, akurat w tym przypadku strona x.com z dawniej Twitter. No to może zabić dzień to, zwłaszcza jak się trafi tam jakaś naprawdę ciekawa historyjka, coś co jest interesujące i nawet niech to będzie związane z pracą, to może LinkedIn akurat jest kopalnią takiego zapętlenia się, ale to wszystko może spowodować, że minuty lecą, zamieniają się w godziny i produktywność dnia poszła się gonić. Więc tutaj sam tego nie stosuję, ale kupuję i sam wziąłem też w Jacka jak to działa, warto świadomie wykonać ten krok.

Kuba: Podobna, przedostatnia praktyka związana z produktywnością to blokada połączeń i powiadomień. O ile stron sobie nie blokuję, to bardzo świadomie podchodzę do tego, co mi się wyświetla, co próbuje się ze mną połączyć. Chociażby nawet znowu wracając trochę do kulis kuchni, w tej chwili my nagrywamy ten podcast, osoby, które obejrzą to nagranie na YouTube mogą też to widzieć. Na telefonie ustawiony tryb samolotowy, żeby przez przypadek ktoś tutaj nie próbował się do mnie dodzwonić, ale też, żeby nawet nie próbował mi się tam wyświetlać w telefonie jakiś komunikat, że przyszedł do mnie SMS, jakaś wiadomość na WhatsAppie, czy jakaś aplikacja też próbuje coś mi wyświetlić. No i rozszerzając, można to zrobić naprawdę dobrze. Jacek za chwilę opowie, bo robi to jeszcze lepiej ode mnie, ale jednak takie ustawienie, takie wysetupowanie swojego komputera czy telefonu, żeby te wszystkie połączenia, powiadomienia, wyświetlające się okienka, jakieś pingnięcia, wszystkie te komunikaty, dźwięki, żeby to wszystko nie rozpraszało. To może się dziać bezwiednie, chociażby tuż przed rozpoczęciem nagrania przyszła wiadomość od zapytania od klienta, że jest zainteresowany jakąś współpracą i naprawdę 10% mojego mózgu przez całą tę rozmowę, przez całe nagranie też już się troszczy o to, o kurcze, co tam trzeba odpisać. To potrafi produktywność rozwalić. Więc to tu jest cała koncepcja tego, żeby świadomie sobie poustawiać te notyfikacje. Szczerze mówiąc, większość z nich wyłączyć, zostawić tylko te, które naprawdę są potrzebne, większość z nich nie jest. Ale więcej o tym, jak można to zrobić, ma fajnie to roztykane, Jacek.

Jacek: Tak, w sumie tak. Wszystko to zgadzam się z wszystkim tym, co Kuba powiedział. Ja ogólnie uważam, że powiadomienia to jest zło, które należy eliminować. Bardzo nie lubię, jak coś mi przeszkadza w pracy i powiadomienia, gdyby tym wszystkim aplikacjom na komputerze i na telefonie pozwolić, to tak naprawdę możemy być w takim ciągłym trybie przychodzących powiadomień. Ja jestem na bardzo dużym detoxie od social mediów. Tak naprawdę właściwie jedyne miejsce, gdzie jestem jakoś tam aktywny, to jest LinkedIn. Natomiast wspominany X, czy Facebook, czy Instagram, to są rzeczy, z których nie mam aplikacji na telefonie i jestem wylogowany na komputerze, więc gdybym chciał wejść, to muszę się zalogować. A że mam klucz fizyczny, to mi się go nie chce wkładać do USB i tak naprawdę sobie ustawiłem taki próg, że po prostu muszę bardzo chcieć, żeby się tam dostać. Widzę osoby, które mają aplikację na przykład jadąc pociągu i widzę czy nawet słyszę, że komuś cały czas przychodzi. Taka trasa, na przykład z Warszawy do Poznania, to może być takie właściwie ciągłe reagowanie co minutę, co dwie, co pięć na powiadomienia z telefonu. Nie wyobrażam sobie osobiście tak funkcjonować, więc tak jak Kuba powiedział, mam to dosyć mocno zorganizowane, czyli właściwie ograniczone do minimum powiadomienia, tylko takie właściwie krytyczne, plus co najmniej takie dwa stopnie eliminacji, czyli jeden to jest tryb pracy, gdzie właściwie nie można się do mnie dodzwonić, nie wiem, że ktoś do mnie dzwoni, nic mi się nie pokazuje, właściwie zero notyfikacji. I taki trochę łagodniejszy tryb nie przeszkadzać, gdzie jednak pewne rzeczy mogą do mnie dochodzić, ale to też są wyselekcjonowane rzeczy, czyli w stylu rodzina się może do mnie dodzwonić czy jakieś osoby, które oznaczyłem, że mogą. Kuba też jest na tej liście, czyli prywatne powiadomienie ze Slacka od Kuby ma jednak jakąś tam rangę, bo jeżeli pisze do mnie osobiście, to to jednak jest w jakimś stopniu istotne. Chociaż wiem, że gdyby było coś pilnego, to Kuba by zadzwonił, gdyby było coś istotnego, a nie pilnego, to by napisał SMS, a więc też tak trochę tutaj między nami mamy ustalone jakieś tam progi, kiedy kontaktujemy się w jaki sposób i generalnie myślę, że mądre zarządzenie tym wszystkim, czym świat chce nas zbombardować, też może być naprawdę niesamowitym takim boosterem produktywności, jeśli tylko odważymy się to zrobić, np. bo myślę, że tutaj wchodzi w grę na pewno FOMO, czyli że jak nie będę wiedział na bieżąco, to coś tracę. Mogę powiedzieć na bazie moich eksperymentów, że tracę i żyję i jest fajnie i że nie muszę każdego newsa, który na przykład jest grzany od kilku dni, tylko tak naprawdę zmienia się na główek i w sumie nic więcej nie wiemy, tylko to jest parafrazowane. Uznaję, że nie jest mi to potrzebne, do szczęścia.

Kuba: Używałeś przykładów w takich bazie social mediowych albo narzędziowych, ale ja mocno wskażę dwa narzędzia z rodziny Microsoftu, Outlook i Teams, bardzo popularne w realiach korporacyjnych, tam też mocno rekomenduję, żeby sobie ustawić na przykład niewyskakujące okno z powiadomieniem o nowym mailu. Przeciętna osoba w realiach korporacyjnych dostaje non stop te maile, nie ma szans, że nad wszystkim nagonisz, a co gorsza, właśnie taki wyświetlony kawałeczek treści maila może cię totalnie oderwać od tego, co robisz. Maile nie służą do tego, żeby przerywać sobie pracę. I podobnie Teamsy, zwłaszcza jak jest się na wielu grupach, to może się okazać, że to jest niekończący się budzik, ciągle przychodzący, wyskakujący, pikający kolejne powiadomienie, zrób tak, żeby tego było jak najmniej, a w tym razie po prostu z poziomu Windowsa, czy tam poziomu Maca, wycisz to wszystko, żeby cię nie rozpraszało, albo chociaż mniej tryby, gdy potrzebujesz, żeby cię to nie rozpraszało.

Jacek: I ostatnia praktyka, którą chcemy się podzielić, to organizacja przestrzeni do pracy. O tej praktyce powiemy z dwóch perspektyw. Ja zacznę od tej pierwszej perspektywy. I to jest perspektywa, w której te rzeczy, które są nam potrzebne do pracy, i to mogą być różne rzeczy w zależności od tego, jak pracujesz. W moim przypadku to jest zawsze napełniona butelka wody, przygotowana kawa, ołówek, długopis na stole, jakiś notatnik do notowania. To są rzeczy, które potrzebuję. Te rzeczy chcę mieć pod ręką, nie chcę po nie wstawać, nie chcę po nie gdzieś tam schodzić, wychodzić. No bo oczywiste jest, że jak zejdę do kuchni, to wiele rzeczy tam na mnie czeka, które na pewno jakąś tam moją uwagę będą rozpraszać. Tak więc mi bardzo dobrze działa przygotowanie sobie tych wszystkich rzeczy z wyprzedzeniem, czyli też jakieś tam planowanie posiłków i posiadanie tego wszystkiego, co jest istotne w zasięgu ręki, żeby minimalizować szansę, że będę musiał odejść od biurka, czy wstać z tego krzesła w zależności czy stoję, czy siedzę. To na pewno będzie coś, co wybije mnie z rytmu. 

Kuba: Użyję przykładu, ponownie będę trochę opowiadał, co robię, a osoby, które oglądają wideo, będą to też nawet widzieć. Tu mam karteczki do notowania, tu mam takie większe karteczki do notowania, tutaj mam drukarkę, jak coś wydrukuje, tutaj mam swój notatnik, tu mam z pięć długopisów, jakby się jeden wypisał, to od razu mam następny, za sobą mam bezpośrednio półkę z książkami, do których najczęściej nawiązuje, jak z nich coś cytuję. Tu jest Reinerzen, tu są książki o Scrumie, tu są Labirynty Scruma, zaraz za moją głową, więc nie będę się przesuwał. Piętro niżej są dokumenty księgowe, firmowe, umowy, różne takie rzeczy, może mniej sexy, ale też bardzo często stosowane. Tutaj poniżej mam też teczkę trenerską, gdzie mogę wyciągnąć jakieś rzeczy związane bardziej ze szkoleniem. Tak naprawdę coddzienny dzień pracy oznacza, że jakbym nie chciał i nie uwzględniał tych przerw, o których mówiliśmy wcześniej, to mogę się cały dzień nie ruszać, wiele, wiele godzin lecieć, w zasadzie tylko wychylając rękę i robiąc właściwe rzeczy, bo jest to po prostu mi potrzebne bezpośrednio. To jest drugi wymiar, akurat niekoniecznie w pełni go realizuję, ale tutaj Jacek jest w tym lepszy, jako minimalista jest też ten wymiar mniej z rzeczy, które cię rozpraszają poza zasięgiem. Zwłaszcza jeśli się pracuje zdalnie, fajnie jest mieć ten klimat w miarę czystego biurka i wręcz takiej przestrzeni do pracy, która jest inną przestrzenią niż przestrzeń do rozrywki, żeby tutaj się nie okazało, że wszystko, co rozprasza, co przeszkadza w pracy, jest za łatwo dostępne i taka fizyczna analogia tych rozpraszających stron. Jeśli bardzo łatwo mi wejść na stronę, to na nią wejdę, jeśli bardzo łatwo jest mi sięgnąć jakąś rzecz, która oderwie mnie od pracy, to to zrobię. Tu wszystko, co mogę szczególnie powiedzieć, to na przykład żadnej książki o ogrodzie, nie mam tutaj, te książki na ogrodzie. Te książki o ogrodzie, są piętro niżej na dolę w dużym pokoju i jak chcę popracować nad planowaniem ogrodu, to muszę to robić tam. Tutaj nie mam wszystkich swoich potrzebnych materiałów. Z innymi kwestiami nie jest tak łatwo, ale nie będę ich zmieniał. I tak trochę zamykając wątek, wymieniliśmy 11 konkretnych praktyk, które my sami stosujemy albo chociaż jeden z nas stosuje, ale to nie jest tak, że to jest kompletna lista, to nie jest też tak, że mamy tutaj złudzenia, że dokładnie te 11 rzeczy, jakby zaaplikujesz do swojej pracy, to będzie lepiej. Pewnie część stosujesz, stosujesz być może też inne, których nie wymieniamy, ale coś, po co nagraliśmy ten materiał, to to, żeby zachęcić się do refleksji, jak sobie zapewniasz produktywność osobistą. Na ile robisz to świadomie, na ile nad tym panujesz, na ile masz też świadomość, co cię rozprasza, co przeszkadza w skupieniu, co przeszkadza w twojej produktywności. No i też kwestia nawyków, zwłaszcza Jacek to wprost nazywał. Czy budujesz sobie pozytywne nawyki, które pomagają ci w tej produktywności, albo czy masz takie nawyki, które tą produktywność obniżają i czy zdajesz sobie z nich sprawę i próbujesz coś z nimi robić?

Jacek: Druga myśl, którą my chcieliśmy się podzielić na koniec, jest taka, że część z tych praktyk, które wymieniliśmy, które działają na poziomie pojedynczej osoby, można też zaaplikować na poziomie zespołu. Czyli przykładowo lista rzeczy do zrobienia, to może być coś zespołowego, wspólna praktyka planowania dnia, czy planowania jakichś dłuższych odcinków pracy, dzielenie na małe kawałki, skupienie się w procesie na jednej rzeczy naraz, łączenie podobnych tematów w paczki, to ewidentnie są tematy, które można też zaaplikować nie tylko na poziomie pojedynczej osoby, ale też na poziomie całego zespołu. Jeżeli czujesz, że te praktyki, o których wspomnieliśmy, mogą pomóc osobom w twojej firmie, to zachęcamy, żebyś się podzielił bądź podzieliła się z nimi tym odcinkiem.

Kuba: I podsumowując, 11 praktyk poprawy produktywności osobistej, które rekomendujemy i sami stosujemy to: lista rzeczy do zrobienia, planowanie dnia, dzielenie pracy na małe kawałki, skupienie się na jednej rzeczy naraz i łączenie pracy w paczki.

Jacek: Jak również technika Pomodoro, regularne przerwy, izolacja od dźwięku otoczenia, blokada stron niezwiązanych z pracą, blokada połączeń i powiadomień oraz organizacja przestrzeni do pracy.

Kuba: Produktywność osobista jest jedną ze składowych efektywności całego zespołu, o czym powiedzieliśmy na samym starcie. Jest to jedna z rzeczy, na którą zwracamy uwagę podczas szkolenia naszego autorstwa, którego ten materiał może być kawałkiem. Zobacz więcej na stronie 202procent.pl/szkolenie-efektywność i sprawdź, czy to jest materiał, który przydałby się w twojej firmie i w twoim zespole.

Jacek: Natomiast notatki do tego odcinka, artykuł, transkrypcję oraz zapis wideo znajdziesz na stronie porzadnyagie.pl/138.

Kuba: I to by było wszystko na dzisiaj. Dzięki, Jacek.

Jacek: Dzięki, Kuba. I do usłyszenia wkrótce.

________

To była pełna transkrypcja odcinka podcastu Porządny Agile. Dziękujemy za lekturę!

Ostatnia aktualizacja: 7 listopada 2025

Czy Twój zespół jest ciągle zajęty, a mimo to efekty nie robią wrażenia?  A może ktoś w firmie wierzy, że wystarczy „dowieźć szybciej” albo kupić nowe narzędzie, by nagle wszystko zaczęło działać jak w zegarku? Bierzemy na tapet 7 najczęściej spotykanych mitów o efektywności zespołów. Pokazujemy, dlaczego „więcej” nie zawsze znaczy „lepiej”, czemu brak przestojów to wcale nie złoty Graal i jak nie wpaść w pułapkę myślenia, że narzędzia rozwiążą za nas problemy. Podsuniemy Ci też praktyczne wskazówki – jak rozmawiać o efektywności w firmie i jak odróżniać realne usprawnienia od złudnych obietnic.

Na początek warto wyjaśnić, czym właściwie jest efektywność. Nie chodzi o dokładną definicję, lecz o uporządkowanie pojęć, zanim pojawią się mity. Efektywność zespołu to relacja wartości uzyskanej z jego pracy do kosztu uzyskania danego efektu. Z tak prostego wzoru wynika, że można ją poprawić na dwa sposoby:

Spis treści

• Czym dla nas jest efektywność?
• „Efektywności nie da się mierzyć”
• „Najistotniejsza jest dostarczona wartość, nie ma potrzeby sprawdzać efektywności” 
• „Efektywność moich zespołów wzrośnie, jeśli będą w stanie robić więcej” 
• „Efektywność moich zespołów wzrośnie, jeśli będą w stanie pracować szybciej” 
• „Efektywność moich zespołów wzrośnie, jeśli nie będzie wolnych przebiegów” 
• „Efektywne zespoły pracują nad wieloma tematami jednocześnie”
• „Nowe narzędzie rozwiąże nasze problemy z efektywnością” 
• FAQ: Mity o efektywności zespołów
• Transkrypcja podcastu „Mity o efektywności zespołów„

Przejdźmy do mitów i uproszczeń dotyczących efektywności. Będzie ich siedem, a każdy zostanie przedstawiony w formie cytatu. Część z nich to autentyczne wypowiedzi, które naprawdę padły, inne to lekkie uogólnienia, ale łatwo wyobrazić sobie, że mogłyby zostać wypowiedziane w podobny sposób. 

To przekonanie pojawia się wyjątkowo często. Zazwyczaj wynika z braku refleksji lub praktycznego doświadczenia w tym obszarze. Osoba, która tak twierdzi, nie ma jasnego obrazu, czym efektywność naprawdę jest, więc uznaje ją za pojęcie zbyt płynne i nieuchwytne, by można je było zmierzyć.

Podobne stwierdzenie często pojawia się ze strony osób zarządzających lub przedstawicieli firm, w których mierzenie wyników jest na niskim poziomie dojrzałości. Jeśli organizacja nie monitoruje jakości, satysfakcji ani innych kluczowych wskaźników, trudno oczekiwać, że będzie potrafiła mierzyć efektywność. W tym przypadku nie ma miejsca na wątpliwości,  efektywność da się zmierzyć. To sytuacja wyjątkowo klarowna. W innych przykładach pojawi się więcej niuansów. Wystarczy znać wartość dostarczoną, wyrazić ją w konkretnej jednostce, podzielić przez koszt wytworzenia i otrzymujemy miarę efektywności. Sam pomiar jest prosty. Trudność pojawia się dopiero wtedy, gdy trzeba odpowiednio wykorzystać jego wynik.

Osoba, która tak twierdzi, zwykle zakłada, że najważniejsze jest skupienie się na wartości biznesowej i jej maksymalizacji. Taki sposób myślenia można znaleźć choćby w starszej wersji Scrum Guide’a, w definicji roli Product Ownera, gdzie nie kładziono nacisku na pomiar efektywności. Założenie jest proste: jeśli skupimy się wyłącznie na maksymalizacji wartości, efektywność przestaje mieć znaczenie. To przykład sytuacji, w której jedna strona równania efektywności dominuje nad drugą. Jest tu jednak istotny niuans. Dążenie do maksymalizacji wartości jest jednym z najlepszych sposobów na poprawę efektywności, ale nie może być traktowane jako jedyne rozwiązanie. Nie chodzi o to, by stale wybierać tylko działania o najwyższej wartości. Takie podejście ma swoje ograniczenia i może prowadzić do pułapek.

Innymi słowy, obie strony równania efektywności mają znaczenie. Nawet jeśli mamy przekonanie lub potwierdzenie, że dostarczana wartość jest satysfakcjonująca, warto sprawdzić jakiego kosztu wymagała. Można łatwo wyobrazić sobie sytuację, w której zespół dostarcza coś rzeczywiście wartościowego, lecz za bardzo wysoką cenę. Po dokładnym przeliczeniu może się okazać, że relacja wartości do kosztu przestaje być korzystna. Na przykład, jeśli coś wartościowego dostarczymy w ciągu trzech miesięcy, koszt może być akceptowalny w stosunku do uzyskanej wartości. Jednak gdy ten sam efekt wymaga dziewięciu miesięcy pracy, proporcja między wartością a kosztem mogłaby okazać się nieakceptowalna. Innymi słowy, koszt uzyskania efektu może przewyższyć wartość, jaką ten efekt wnosi.

To przekonanie opiera się na uproszczonym założeniu, że im więcej pracy wykonujemy, tym wyższa jest efektywność. Takie podejście kryje w sobie poważną pułapkę. Skupienie się wyłącznie na ilości wytwarzanej pracy może sprawić, że zabraknie refleksji nad tym, czy to, co powstaje w większej ilości, ma rzeczywistą wartość.

Ta pułapka jest wyjątkowo powszechna, zwłaszcza gdy organizacja skupia się na mierzeniu ilości wykonanej pracy, na przykład liczbie zakończonych projektów, dostarczonych story pointów lub trendzie ich wzrostu. Takie wskaźniki mogą być przydatne, jeśli analizuje się je razem z innymi danymi, jednak z perspektywy efektywności bywają mylące. Liczba dostarczonych funkcji nie musi przekładać się na realny rezultat biznesowy, który najłatwiej zmierzyć poprzez dane finansowe, na przykład wzrost przychodu, liczbę nowych rejestracji czy zwiększoną sprzedaż dzięki nowym elementom produktu. Właśnie w tym tkwi główna pułapka. Paradoksalnie efektywność może wzrosnąć, gdy zespoły będą realizować mniej zadań, ale bardziej wartościowych. Można to osiągnąć dzięki lepszej selekcji, właściwemu ustalaniu priorytetów oraz stosowaniu dobrych praktyk Product Discovery, zamiast koncentrować się na nieprzemyślanej pogoni za kolejnym zadaniem. Oczywiście istnieje też sytuacja idealna, w której zespoły robią więcej i jednocześnie to, co robią, ma wysoką wartość. W praktyce jednak nie należy zakładać, że większa liczba zadań zawsze oznacza wyższą efektywność. Może się okazać, że efektywność pozostaje na tym samym poziomie, a nawet spada, jeśli brakuje odpowiedniej selekcji i skupienia na realizacji rzeczy naprawdę wartościowych i przemyślanych.

Warto rozróżnić te dwa podejścia, wcześniejsze dotyczyło robienia większej ilości pracy, a to odnosi się do tempa jej wykonywania. Można zauważyć trend wynikający z popularności wskaźnika time to market, który przez lata był jednym z kluczowych mierników w transformacjach zwinnych i produktowych. Należy jednak zachować ostrożność. Praca wykonywana szybko tylko po to, by „dowieźć” coś jak najszybciej, może prowadzić do poważnych błędów i spadku jakości. Ostrzegamy przed sytuacją, w której tempo pracy staje się ważniejsze niż jakość. Szybkie działanie bez refleksji nad wartością lub całkowitym kosztem utrzymania rozwiązania może przynieść odwrotny efekt. Często okazuje się, że pominięcie refaktoryzacji czy dbałości o utrzymanie produktu daje krótkotrwałą oszczędność, ale w dłuższej perspektywie powoduje poważne problemy. Może się zdarzyć, że pojedynczy Sprint lub inicjatywa kończy się szybko, ale w dłuższej perspektywie koszty wzrosną. W efekcie efektywność, zwłaszcza długoterminowa, zaczyna spadać.

Temat jest złożony, ponieważ istnieją sytuacje, w których szybsze dostarczenie produktu lub nowych funkcji na rynek pozwala zająć pozycję lidera i uzyskać przewagę konkurencyjną. Jednak przekonanie, że szybkie działanie zawsze oznacza efektywność, w dłuższej perspektywie może okazać się pułapką. Szybsze dostarczanie może zwiększyć efektywność, o ile jest stosowane rozważnie. Stały nacisk na tempo pracy „za wszelką cenę” prowadzi jednak często do odwrotnych skutków niż zamierzone.

Ten mit opiera się na przekonaniu, że najbardziej efektywne są te zespoły, które są nieustannie zajęte. Zakłada się, że wysoka efektywność oznacza maksymalne obłożenie zadaniami. Często używa się określeń, że zespoły są „doładowane”, „zapakowane po korek” czy „zatankowane do pełna”. Wszystko to sprowadza się do przekonania, że im więcej zadań uda się upchnąć, tym lepiej wykorzystany będzie czas pracy i tym większa będzie efektywność. W takim myśleniu nie ma miejsca na żadną wolną przestrzeń, każdy moment musi być wypełniony zadaniami. Według tej logiki pełne obłożenie pracą oznacza najwyższą efektywność.

Teorie dotyczące organizacji pracy jasno wskazują, że to błędne założenie. Efektywność zespołów spada, gdy nie mają żadnej przestrzeni na wolniejsze przebiegi. To zjawisko jest nieuniknione. Potwierdza to między innymi teoria kolejek, zgodnie z którą pełne obłożenie prowadzi do powstawania długich kolejek, a te generują dodatkowe koszty i opóźnienia, które wzajemnie się nasilają. 

Drugi aspekt dotyczy psychologii zarządzania i motywacji. Przeładowanie zadaniami obniża efektywność pracy poszczególnych osób. Osoba zbyt mocno obciążona zadaniami kreatywnymi wykonuje je z mniejszą jakością. Dodatkowo realizuje je wolniej, co niweluje ewentualny efekt „szybszego dostarczania”. W rezultacie przeładowane zespoły dostarczają wolniej, a każde zadanie wykonywane jest dłużej i drożej. Szczególnie niebezpieczna jest presja menedżerów, Product Ownera czy zarządów, by nie pozostawiać żadnej przestrzeni,  żadnego luzu czy marginesu w pracy zespołów. Przeładowanie planów, zarówno na poziomie kwartału czy projektu, jak i pojedynczego Sprintu, jest zjawiskiem wyjątkowo groźnym, ponieważ trudno je później skorygować. Z perspektywy menedżerskiej warto unikać takiego przeciążania i raczej zachęcać do tworzenia przestrzeni w planach zespołu. Warto pamiętać o prostej zasadzie: jeśli zespół skończy wcześniej, zawsze można dodać kolejne zadanie lub przyspieszyć wdrożenie. Każdy inżynier wypełni wolny czas wartościowymi zadaniami, refaktoryzacją, usprawnieniami technicznymi lub przygotowaniem kolejnego elementu produktu. Przepakowywanie ludzi, dokładanie zadań „na zapas” czy unikanie przerw w pracy to ślepa uliczka prowadząca do spadku efektywności. Gdy efektywność nie jest mierzona, trudno to zauważyć, ale w momencie wprowadzenia pomiaru różnica staje się natychmiast widoczna.

Chodzi o sytuację związaną z przepakowywaniem kwartałów, o którym była mowa wcześniej. Mit ten opiera się na przekonaniu, że zespół jest najbardziej efektywny, gdy równocześnie realizuje wiele projektów, inicjatyw lub rozwija produkt w kilku kierunkach naraz. Podobnie jak poprzedni mit, który dotyczył braku przestrzeni w pracy pojedynczych osób, ten przenosi to myślenie na poziom całej organizacji. Zakłada się, że zespoły działają skuteczniej, gdy wykonują wiele zadań równolegle i potrafią się między nimi przełączać, co ma rzekomo zwiększać efekty pracy.

Często pojawia się założenie, że jeśli zespół zajmuje się tylko jednym tematem, to musi pojawić się przestój, bo przecież „nie da się pracować całym zespołem nad jednym zagadnieniem”. To błędne przekonanie. Bardziej trafne byłoby stwierdzenie: „mój zespół nie potrafi jeszcze efektywnie współpracować nad jednym tematem w większym składzie”. Często pojawia się też przekonanie, że lepiej uruchomić kilka wątków jednocześnie, aby w razie zablokowania jednego można było przełączyć się na inny. Takie podejście jest jednak pułapką, zamiast rozwiązywać przyczyny blokad i dbać o płynność pracy zespołu, przenosi uwagę na „gaszenie pożarów”. Dodatkowo błędne jest przekonanie, że większa liczba uruchomionych wątków chroni zespół przed przestojami, że w razie blokady wystarczy po prostu zająć się czymś innym. W praktyce prowadzi to do sytuacji, w której zamiast usuwać przeszkodę, zespół z łatwością przenosi się do innych zadań. Takie działanie daje wrażenie aktywności i zaangażowania, więc trudno je na pierwszy rzut oka skrytykować. Z perspektywy przepływu pracy to jednak problem, pozostawione wątki trafiają w stan oczekiwania, co wydłuża całkowity czas dostarczania.

Blokady mogą mieć różny charakter, od decyzji produktowych, przez kwestie proceduralne i wewnętrzne, po ograniczenia narzędziowe, technologiczne czy problemy we współpracy między zespołami. Wszystkie te obszary stanowią duży potencjał do poprawy efektywności,  zarówno pod względem kosztowym, jak i w zakresie płynności pracy. Jednak zespół przeciążony wieloma tematami jednocześnie nie ma motywacji, by te problemy rozwiązywać. Gdy jeden projekt zostanie zablokowany, można po prostu przełączyć się na inny. Jak wspomnieliśmy wcześniej, takie przełączanie nie jest ani bezkarne, ani bezkosztowe, zarówno przejście na inny projekt, jak i późniejszy powrót powodują stratę czasu i energii. Co więcej, problem proceduralny lub operacyjny, który pierwotnie blokował pracę, wciąż pozostaje nierozwiązany. Nikt nie czuje potrzeby, by się nim zająć, bo zawsze można zająć się kolejnym projektem B, C lub D.

Ten mit wynika z przekonania, że nowe narzędzia, metody czy frameworki, wdrożone bez większego zastanowienia, automatycznie rozwiążą wszystkie problemy. Wprowadzanie nowych technik lub zmian w sposobie pracy z przekonaniem, że jedna z nich sama w sobie poprawi efektywność, to ślepa uliczka.

Różne narzędzia i frameworki mogą rzeczywiście poprawić współpracę w zespole, usprawnić komunikację, procesy oraz jakość pracy inżynierów. Jednak efektywność (lub jej brak) to złożony i wielowątkowy temat. Dlatego żadna pojedyncza metoda nie przyniesie trwałej poprawy, zmiana musi obejmować cały system działania organizacji. Praktyka pokazuje, że nawet tak popularny framework jak Scrum nie rozwiązuje problemów sam w sobie. To samo dotyczy wszystkich innych narzędzi, technicznych, produktowych, operacyjnych czy strukturalnych. Nie istnieje narzędzie, które w magiczny sposób rozwiązuje problemy, każda zmiana wymaga współpracy i konsekwentnej pracy zespołu. Warto też zachować sceptycyzm wobec marketingowych obietnic czy prezentacji konferencyjnych, w których padają proste hasła typu: „poprawiliśmy efektywność zespołów dzięki X”. Być może efektywność rzeczywiście się poprawiła, ale równie dobrze mogło to być przypadkowe lub źle zmierzone zjawisko, dlatego warto patrzeć na takie deklaracje krytycznie.

Jeśli również dostrzegasz część z nich, to:

Tak! To relacja wartości uzyskanej z pracy zespołu do kosztu jej wytworzenia. Liczy się nie tylko „co” dostarczamy, ale też „za ile”.

Nie. Zespół może „produkować” dużo, ale jeśli to nie ma wartości biznesowej – efektywność realnie spada. Liczy się wartość, nie tylko ilość.

Tylko na krótką metę, jeśli nie zadba się o jakość rozwiązań. Dług technologiczny i spadek jakości szybko zjedzą każdą „oszczędność czasu”, ponieważ wytworzenie kolejnych elementów będzie coraz droższe.

Spada produktywność i jakość. Członkowie zespołu pracują wolniej, dłużej i mniej kreatywnie, a kolejki zadań tylko rosną.

Nie. 100% obłożenia prowadzi do chaosu, a nie do wartości. ”Slack time” w zespole to przestrzeń na innowacje i poprawki.

Wręcz przeciwnie – multitasking spowalnia przepływ pracy i podnosi koszt wytworzenia danego projektu. Lepiej skupić się cały zespołem na najważniejszym wątku i dostarczyć wartość wcześniej.

Niestety nie. Narzędzia pomagają, ale same w sobie nie rozwiązują problemów organizacyjnych i produktowych, a to one są blokerami efektywności.

Bo liczy się też koszt jej dostarczenia. Nawet wartościowe rozwiązanie może być nieopłacalne, jeśli zespół dostarcza je za drogo.

Gdy liderzy chwalą się, że „robimy więcej”, zamiast pytać „jaką to naprawdę przynosi wartość?”.

Efektywność = wartość dostarczona ÷ koszt wytworzenia. Poprawa efektywności może wynikać z podniesienia wartości lub obniżenia kosztu jej wytworzenia.

Bo wymaga zarówno policzenia wartości (np. wpływu na biznes), jak i realnych kosztów. Zespoły często nie mają dostępu do takich informacji.

Czas na naukę, refactoring, rozwiązywanie problemów i innowacje. Jest też bufor czasu na sytuacje nieprzewidziane. To przekłada się na trwałą efektywność.

Najpierw zdefiniować, czym jest efektywność dla organizacji. Potem porozmawiać z kluczowymi osobami i zadbać o spójne komunikowanie tego w codziennej pracy.

Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu Porządny Agile.

Kuba: Często ostatnio rozmawiam z klientami albo z potencjalnymi klientami, którzy chcą rozpocząć współpracę. Coś, co dostrzegam, to to, że wiele z tych osób czy wielu z tych firm, które się zgłaszają, chcą porozmawiać o efektywności, efektywności zespołów, efektywności całego IT. I najczęściej mam lekką rozterkę, czy na pewno za każdym razem rozmawiamy o tym samym. To znaczy, bardzo fajnie się zgodzić, że tak, tak, efektywność jest ważna. Natomiast jak wejdziemy w szczegół – po czym poznajemy, że ta efektywność jest nie taka, co możemy wspólnie ze sobą zrobić, znaczy w czym ja mogę pomóc tej organizacji – okazuje się, że te szczegóły są dość radykalnie różne. Postanowiliśmy z Jackiem przygotować ten materiał, który właśnie się zaczyna, by trochę odczarować ewentualne złe skojarzenia albo niezrozumienia, jakie wiążą się z efektywnością. Być może uprościć sobie niekomfortowe rozmowy w przyszłości, no bo może komuś ten odcinek jeszcze będziemy podsyłać.

Jacek: Spis treści na dzisiaj jest następujący. Najpierw bardzo krótko przypomnimy naszą definicję efektywności zespołu. Następnie podzielimy się siedmioma mitami i nieporozumieniami na temat efektywności. I na koniec krótko podpowiemy, co zrobić, gdy dostrzegasz mity o efektywności w twojej firmie.

Kuba: Zaczynając od razu od pierwszej części, krótkie intro, czym dla nas jest efektywność. Ten odcinek nie jest o tym, żeby to dokładnie definiować, ale wypadałoby na początku podać poprawną wersję, zanim potem mówimy o mitach. Efektywność zespołu to relacja wartości uzyskanej z pracy tego zespołu do kosztu uzyskania danego efektu. Z tak prostego ułamka wynika też, że żeby poprawić efektywność jako tę wartość, o którą walczymy, można się albo skupić na tym, żeby zwiększyć wartość wykonanej pracy, czyli ta sama praca, jeśli chodzi o koszt, ale za to lepszy efekt dostarczony, albo alternatywnie można zmniejszyć koszt wytworzenia danego efektu, czyli ten sam rezultat, ale taniej

Jacek: Więcej na temat poprawy efektywności zespołu, właśnie od tej strony wartości dostarczonej, znajdziesz w odcinku 60., w którym z Kubą omawialiśmy ten temat. Znajdziesz go pod adresem porzadnyagile.pl/60

Kuba: Zanim zaczniemy tę zasadniczą część, czyli mity i niezrozumienia związane z efektywnością, przypominamy, że jeżeli chcesz pogłębić wiedzę jeszcze bardziej, niż robimy to w podcaście, to znajdziesz nasze płatne produkty na stronie porzadnyagile.pl/sklep.

Kuba: No i przejdźmy do tych mitów, czy niezrozumień, czy uproszczeń, jeśli chodzi o efektywność. Wymienimy ich siedem i każdy z nich będzie próbą cytatu. Niektóre z nich są naprawdę wierne, to znaczy dosłownie mamy przed oczami twarz, która coś takiego powiedziała. Inne są takim może lekkim dramatyzowaniem, ale wyobrażamy sobie, że moglibyśmy dokładnie takie zdanie usłyszeć. To jaki cytat, jeśli chodzi o efektywność, weźmiemy jako pierwszy?

Jacek: Pierwszy będzie cytat: „Efektywności nie da się mierzyć”. Jest to stwierdzenie, które bardzo często spotykamy. Najczęściej wynika ono z tego, że temat efektywności nie został przez konkretną osobę przemyślany, przećwiczony. Stąd może rodzić się takie poczucie, że czym w ogóle jest ta efektywność, tak do końca nie wiadomo, no a jak do końca nie wiadomo, no to jak coś tak płynnego i nienamacalnego w ogóle moglibyśmy zmierzyć.

Kuba: Podobny głos też usłyszę od osoby zarządzającej albo od przedstawiciela firmy, w której w ogóle mierzenie jest na niskim poziomie dojrzałości. To jeśli się nie mierzy również jakości, satysfakcji i paru innych rzeczy, to faktycznie z tym mierzeniem efektywności będzie kiepsko. Tutaj absolutnie, kompletnie nie zgadzamy się z tym, że efektywności nie da się zmierzyć. Tutaj jednak nie ma niuansów, w innych cytatach ich trochę będzie, ale tu absolutnie efektywność jest możliwa do zmierzenia. Chwilę temu w pierwszej części krótkiej, bardzo jasno pokazałem, jest wzór. Musimy wiedzieć, jaka jest wartość dostarczona, ją wyrazić w jakiejś jednostce, podzielić przez koszt wytworzenia i mamy gotowy pomiar efektywności. To w gruncie rzeczy jest dość proste, co dalej z tym zrobić, no to jest inna historia.

Kuba: Drugi cytat, drugi mit o efektywności: „To najistotniejsza jest dostarczona wartość. Nie ma potrzeby sprawdzać efektywności”. Tutaj założenie osoby, która takie coś stwierdza, jest takie, że w zasadzie skupmy się na wartości, wartości biznesowej, maksymalizacji tej wartości. I tu tak nawet łatwo, specjalnie teraz użyłem cytat na przykład z poprzedniej wersji Scrum Guide’a i definicji Product Ownera, że nie ma potrzeby sprawdzać efektywności. Jak w zasadzie skupimy się na tym, żeby wartość była najlepsza możliwa, to w zasadzie efektywność możemy zignorować. Tutaj taki prymat jednej ze strony tego równania na efektywność. I tu jest oczywiście już pewien niuans, bo sami zresztą jesteśmy mocno fanami tego, żeby maksymalizować wartość, bo to jest jeden z fajnych i bardzo obiecujących sposobów na poprawę efektywności, ale to nie jest absolut. To nie jest sytuacja, w której tylko i wyłącznie podnosimy wartość albo wybieramy rzeczy, które mają maksymalną wartość, bo to ma swoje ograniczenie, czy to może być pułapką.

Jacek: Tak, mówiąc innymi słowami, tak naprawdę obie strony tego równania są istotne. Czyli pomimo tego, iż mamy poczucie, czy mamy zmierzone, że ta wartość, którą dostarczamy, jest faktycznie satysfakcjonująca, to nadal zachęcamy do tego, żeby jednak zastanowić się, jakim kosztem ta praca, ta wartość, ten efekt została zrealizowana, czy dostarczona? Jestem sobie w stanie wyobrazić sytuację, w której faktycznie zespół czy zespoły dostarczają coś naprawdę wartościowego, ale odbywa się to potężnym kosztem. Być może jest to koszt, który jeśli by go tak faktycznie policzyć, no to może się okazać, że ten stosunek wartości do kosztu przestaje być dla nas satysfakcjonujący.  Czyli przykładowo, jeżeli dostarczamy coś wartościowego w 3 miesiące, może się okazać, że ten koszt dostarczenia tego jest akceptowalny w relacji do dostarczonej wartości, natomiast gdyby trwało to 9 miesięcy, no to może to już być nieakceptowalne. Na zasadzie ten stosunek wartości do tego całkiem potężnego kosztu może być po prostu zbyt duży.

Jacek: Kolejny mit, z którym się spotykamy, brzmi, „Efektywność moich zespołów wzrośnie, jeśli będą w stanie robić więcej”. Jest to taki mit, który wiąże się dosyć mocno z takim założeniem, że efektywność można bardzo łatwo uprościć do takiego myślenia, że im robimy więcej, tym ta efektywność rośnie. Z tym podejściem związana jest oczywiście spora pułapka, no bo akcent jest kładziony bardzo mocno na to, ile faktycznie produkujemy, co może spowodować, że zbyt mocno skupimy się na tym walorze robienia więcej, a za mało będziemy pochylać się nad refleksją, czy to, czego robimy więcej, jest jednocześnie wartościowe. 

Kuba: Ta pułapka jest bardzo powszechna, zwłaszcza jeśli mierzy się właśnie ilość pracy wykonanej, czyli np. ile projektów skończyli członkowie danego zespołu albo całe IT, ile Story pointów zostało dostarczone i czy ten wykres Story pointów dostarczanych rośnie, albo jest na satysfakcjonującym stałym, stabilnym poziomie. I to oczywiście są ciekawe miary, można je interpretować łącznie z innymi miarami, natomiast z perspektywy efektywności można się naprawdę ciężko przejechać, bo liczba efektów pracy rozumiana jako np. dostarczone feature’y może się mieć mniej jak do rezultatu biznesowego, które na końcu najłatwiej zmierzyć po prostu wartością ujawnioną w wyniku finansowym, ile firma zarabia więcej na tym produkcie, ile mamy nowych rejestracji dzięki nowemu formularzowi rejestracji, czy jak wzrosła sprzedaż dzięki jakimś nowym cechom produktu, który właśnie zespoły dostarczyły. Więc tutaj jest duża pułapka. Paradoksalnie może być tak, że efektywność będzie lepsza, jeśli zespoły będą robiły trochę mniej, ale za to bardzo wartościowych rzeczy, co oczywiście mogą osiągnąć poprzez np. większe skupienia się na dobrej selekcji, dobrym priorytetyzacji, dobrych praktykach Product Discovery, a niekoniecznie ślepej pogoni za tym, żeby jeszcze jeden feature wcisnąć, zupełnie nie patrząc na rezultaty. Oczywiście jest też idealny punkt, że robią więcej i to, co robią więcej, jest też bardzo wartościowe, ale tu jest akurat ten zniuansowany cytat, nie stawiajmy znaku równania, że zawsze, gdy robią więcej, to jest lepsza efektywność, bo może ona być albo identyczna, albo co gorsze słabsza, niż gdyby np. poświęcili więcej uwagi na dobrej selekcji i realizowali mniej, ale wyłącznie bardziej wartościowe rzeczy i dobrze przemyślane.

Kuba: Czwarty cytat jest dosyć podobny, więc tutaj proszę o uwagę. „Efektywność moich zespołów wzrośnie, jeśli będą w stanie pracować szybciej”. Bardzo chcemy tutaj oddzielić, czyli poprzednio mówiliśmy, że będą w stanie robić więcej, a teraz mówimy, że będą w stanie pracować szybciej. Myślę, że jest taki trend, on jest pewnie pokłosiem koncepcji mierzenia Time to market, które było często jednym z najważniejszych mierników wielu transformacji zwinnych czy produktowych. Bardzo przestrzegamy przed tym, że praca szybko dla bycia szybkim, dla jeszcze wcześniejszego, intensywniejszego dostarczenia, czy nawet wręcz może tutaj pasuje, dowiezienia, byle szybciej dowieźć, może też być pułapką. Czyli przestrzegamy przed sytuacją, w której szybko oznacza np. ze słabą jakością, bez patrzenia na to, czy to jest wartościowe byle, tylko szybko przepuścić przez cały proces wytwórczy, czy bez patrzenia na Total cost of ownership. Gdzie może się okazać, że ktoś zaoszczędził parę złotych na dobrym refactoringu, czy dobrym maintainability produktu, a potem to wszystko strasznie klęka. I o ile ten jeden Sprint, czy ta jedna inicjatywa jeszcze była w miarę szybko dostarczona, ale w długim okresie koszty strasznie rosną, co powoduje, że efektywność, zwłaszcza ta w dłuższym okresie, zaczyna spadać.

Jacek: Oczywiście temat jest zniuansowany, bo możemy zacząć rozważać sytuację, kiedy szybsze dostarczenie czegoś na rynek może spowodować, że rozsiądziemy się wygodnie na fotelu lidera, który jako pierwszy wprowadza jakiś produkt na rynek, czy jakieś konkretne funkcje, czy cechy produktu, ale z kolei takie myślenie na stałe, że trzeba zrobić jak najszybciej i wtedy jesteśmy efektywni, no jednak długoterminowo może być pułapką. Czyli co do zasady szybsze dostarczanie może nam dać dobrą efektywność, ale z drugiej strony taki nieustanny nacisk na prędkość dostarczania, tak powiedzmy za wszelką cenę, może dać nam w długim terminie odwrotne rezultaty, jakich się spodziewaliśmy.

Jacek: Kolejny mit. „Efektywność moich zespołów wzrośnie, jeśli nie będzie wolnych przebiegów”. W tym micie wychodzi takie założenie, że najbardziej efektywne zespoły, to są takie zespoły, które są bardzo mocno zajęte. Są maksymalnie obłożone pracą. Tutaj bardzo różne określenia spotykamy, że zespoły i ludzie są doładowani, są zapakowani, pod korek, pod kokardę, zatankowani do pełna. No i to wszystko sprowadza się do takiej wiary, że im więcej poupychamy, tym bardziej ten tetris zadań, które ludzie wykonują, będzie szczelny i przylegający do siebie. Nie będzie właściwie żadnej przestrzeni, w którą jeszcze coś można byłoby upchnąć. Tym bardziej jesteśmy efektywni.

Kuba: No i tutaj funkcjonujące teorie na temat organizacji pracy wprost mówią, jesteś w błędzie. Nie, efektywność twoich zespołów spadnie, jeśli nie będzie wolnych przebiegów. I to jest gwarantowane. Gwarantuje to z jednej strony teoria kolejek, czyli założenie, że 100% zajętości oznacza bardzo długie kolejki, co oznacza też wszystkie koszty, które wynikają z kolejek i one się wzajemnie wzmacniają. No i druga kwestia już bardziej związana z psychologią zarządzania, z motywacją. Osoby przeładowane zadaniami po prostu są słabsze, jeśli chodzi o efektywność ich pracy. Osoba, która ma wiele zadań kreatywnych na sobie, jest pod takim obciążeniem, że wykonuje każde z tych zadań gorzej. No, jeszcze plus wykonuje je dłużej, co znowu wraca do ewentualnego korzystnego efektu, że przynajmniej dostarczyliśmy szybciej. Więc tutaj przeładowane zespoły dostarczają wolniej i każde jedno z zadań, które taka przeładowana osoba ma, będzie realizowane też samo w sobie, wolniej, dłużej, bardziej kosztownie. Więc ten mit nie ma tutaj żadnego niuansu. Bardzo niebezpiecznym zjawiskiem jest managerska presja, Product Ownerska presja, członka zarządu presja na to, żeby nie widzieć ani sekundy lub sekundy, żeby nie widzieć, ani sekundy, nie widzieć, ani sekundy luzu tego jakiegoś Slacka czy przestrzeni na jakieś dodatkowe rzeczy. Szczególnie niebezpieczne jest przepakowanie np. kwartałów, przepakowanie planów całych projektów, bo tego w zasadzie już nie za bardzo da się skorygować, ale również nawet na lokalnym poziomie np. pojedynczego Sprintu, to też może być niebezpieczne zjawisko. Więc z perspektywy managerskiej nie generuj czegoś takiego, wręcz nawet zachęcaj do tego, żeby zespoły miały pewne przestrzenie. Zawsze można dobrać, to jest komunikat, który często w takich przypadkach bardzo prosty komunikuje, zawsze jeszcze można dorobić coś, zawsze jeszcze można wdrożyć wcześniej, jeśli skończymy i wyrobimy się wcześniej. Zawsze każdy inżynier znajdzie sobie coś fajnego do roboty, jakiś refactoring, jakieś narzędzia, jakieś prace techniczne albo po prostu następnym feature. Ale przepakowanie ludzi, wciskanie na te pół dnia jeszcze jakiejś dodatkowej roboty czy rozpoczynanie czegoś na zapas, żeby czasem nie było przestoju, to jest ślepa uliczka. I niestety, jeśli się nie mierzy efektywności, to może tego nie być widać, ale jak tylko się zacznie to mierzyć i mieć porównanie, to wychodzi błyskawicznie.

Kuba: Podobny cytat do tego, co powiedzieliśmy przed chwilą, to „Efektywne zespoły pracują nad wieloma tematami jednocześnie”. I chodzi tutaj o tę sytuację, którą chwilę temu zapowiedziałem, czyli przepakowywanie kwartałów. Założenie, że zespół jest efektywny wtedy, gdy pracuje na przykład nad wieloma projektami jednocześnie, nad wieloma inicjatywami produktowymi, czy próbuje rozwinąć Road Mapę produktu w wielu kierunkach równocześnie. Tak jak ten poprzedni mit mocno mówił o tym, że pojedyncze osoba lepiej, żeby nie miały wolnego przestoju, ten mit o efektywnym zespole, który pracuje nad wieloma rzeczami jednocześnie przenosi to na poziom wręcz całej organizacji, czyli te zespoły są lepsze wtedy, gdy po prostu robią wiele rzeczy, jednocześnie jakoś tak magicznie się przełączają i wtedy jest większy efekt.

Jacek: Założenie jest takie, że jakby mieli mieć jeden tylko temat, to na pewno będą przestoje, bo przecież nie można pracować całym zespołem nad jednym tematem, co oczywiście jest potężnym mitem. Powiedzmy sobie raczej, nie umie mój zespół pracować wiele osób nad jednym tematem. Myślę, że to byłoby bardziej prawdziwe. No i tutaj jest też takie założenie, że lepiej, żeby mieli więcej wątków, bo jeżeli jakiś wątek się, czy jakiś temat się przyblokuje, no to będzie można przeskoczyć na coś innego, co samo w sobie też jest pewnego rodzaju pułapką, bo zamiast aktywnie działać, żeby flow twojego zespołu było płynne. Jednocześnie błędnym założeniem przy okazji tego mitu jest takie poczucie, że jeśli mamy więcej wątków uruchomionych, to w przypadku zblokowania się zespół będzie w stanie po prostu przełączyć się na jakieś inne zadania. Tutaj paradoksalnie jest to problem, bo zamiast zadbać o to, żeby rozwiązać to konkretne zadanie, które blokuje zespół, no to z łatwością przeskakują po prostu do innych zadań, co oczywiście daje poczucie, że pracujemy, jesteśmy zajęci, no i trudno cokolwiek zarzucić, ale z perspektywy flow zespołu, przepływo pracy, to właśnie sobie jakiś temat zostawiamy, żeby był w stanie oczekującym na coś, co oczywiście wydłuży nam czas dostarczania.

Kuba: Te blokady to mogą być różne rzeczy, to mogą być decyzje produktowe, to mogą być kwestie bardzo proceduralne, takie wewnątrz firmowe, to mogą być rzeczy narzędziowe, to mogą być rzeczy technologiczne, to może być współpraca międzyzespołowa, to są wszystko piękne potencjały na poprawę efektywności od tej strony powiedzmy kosztowej, od tej płynności pracy, no ale zespół przeładowany wieloma tematami jednocześnie, w zasadzie nie ma żadnego powodu, żeby cokolwiek zmieniać, no bo zawsze, gdy projekt A nam się zblokuje, możemy się przynajmniej przełączyć na projekt B. I tak jak Jacek mówił, po pierwsze to nie jest bezkarne i bezkosztowe przełączenie się na projekt B, a później powrotne przełączenie się na projekt A, a po drugie ten problem taki proceduralny, operacyjny nadal istnieje. Tylko nikt z nim nic nie musi robić, bo zawsze jest projekt B, C, D, na który można się przełączyć.

Jacek: I ostatni mit, który chcieliśmy w tym odcinku wyróżnić, to mit, który brzmi „Nowe narzędzie rozwiąże nasze problemy z efektywnością”. Mit ten opiera się na wierze, że nowe narzędzia, nowe metody, nowe frameworki, nowe sposoby w pracy, tak wprost wyjęte z pudełka po prostu rozwiążą nasze problemy. Wprowadzanie nowych technik czy zmienianie tego jak funkcjonujemy i takie zbyt ślepe wierzenie, że oto ta jedna drobna zmiana spowoduje, że efektywność się poprawi jest z naszej perspektywy ślepą uliczką. 

Kuba: Różne konkretne narzędzia, czy frameworki, tak jak Jacek powiedział, mogą poprawić się. Kolektywność, mogą poprawić komunikację, mogą poprawić usprawnienie procesu, wykorzystanie jakichś konkretnych technik, może poprawić jakość pracy inżynierów, ale zazwyczaj efektywność, a w zasadzie nieefektywność danej organizacji czy danego zespołu produktowego to jest na tyle szeroka, złożona wielowątkowa kwestia, że zmiana musi być też również szeroka i zaaplikowanie jednej metody nic nie da. Długo działamy w Scrumie i twórcy Scruma bardzo mocno np. przypominają, że Scrum nie rozwiązuje Ci problemów. Scrum jest bardzo popularny, Scrum jest modny, Scrum jest punktem inspiracji do sposobów działania zespołów, ale to dopiero te usprawniania, dopiero decyzje produktowe, dopiero dobry, mocny zespół, one wszystkie będą składowymi dobrej efektywności i Scrum sam w sobie tylko po prostu wdrożone tego nie da. I tak po kolei można powiedzieć o wszystkich narzędziach, czy bardziej technicznych, czy bardziej produktowych, czy bardziej operacyjnych, strukturalnych. Nie znamy żadnego takiego, które z automatu, magicznym dotknięciem, różdżki rozwiązują problem, wymaga to współpracy. No i nie wierzmy sprzedawcom, nie wierzmy landing page’om, nie wierzmy jakimś historiom z konferencji, gdzie w krótkim zdaniu ktoś stwierdza, poprawiliśmy efektywne zespołów dzięki X. Ona mogła się poprawić, mogła przy okazji się poprawić, albo ktoś po prostu kiepsko to mierzy, więc może obiecać dowolne rzeczy.

Kuba: Podsumowując cały odcinek. 7 mitów o efektywności zespołów, które najczęściej spotykamy to.

Jacek: Efektywności nie da się mierzyć. Najistotniejsza jest dostarczona wartość, nie ma potrzeby sprawdzać efektywności. Efektywność moich zespołów wzrośnie, jeśli będą w stanie robić więcej.

Kuba: Efektywność moich zespołów wzrośnie, jeśli będą w stanie pracować szybciej. Efektywność moich zespołów wzrośnie, jeśli nie będzie wolnych przebiegów. Efektywne zespoły pracują nad wieloma tematami, jednocześnie. Nowe narzędzie rozwiąże nasze problemy z efektywnością.

Jacek: Jeśli również dostrzegasz, jeśli również dostrzegasz część z nich, to zastanów się jak definiujesz efektywność. Sprawdź jak rozumieją efektywność kluczowe osoby w firmie i zwróć uwagę jak komunikujesz istotę efektywności.

Kuba: Jeśli temat efektywności rozumianej, tak jak omawiamy to w nagraniu, jest istotną kwestią i potrzebujesz ją poprawić, porozmawiamy o tym, jak możemy pomóc. Jako doświadczenie eksperci dołączamy do zespołu lub podanej części firmy i wskazujemy potencjał do poprawy oraz rekomendujemy sposoby, by zmienić proces wytwórczy tak, by efektywność faktycznie wzrosła. Sprawdź naszą propozycję na 202procent.pl/diagnoza-efektywnosci.

Jacek: Natomiast te notatki do tego odcinka, artykuł, transkrypcję oraz zapis wideo znajdziesz na stronie porządnyagile.pl/137

Kuba: I to by było wszystko na dzisiaj. Dzięki, Jacek.

Jacek: Dzięki, Kuba. I do usłyszenia wkrótce.

________

To była pełna transkrypcja odcinka podcastu Porządny Agile. Dziękujemy za lekturę!

Ostatnia aktualizacja: 30 grudnia 2025

Czy wiesz, że wiedza w Twojej firmie może niepostrzeżenie zanikać? Erozja umiejętności pojawia się wtedy, gdy nowe osoby uczą się głównie od starszych stażem kolegów – często przejmując ich nawyki, niekoniecznie te najlepsze i aktualne. Z czasem prowadzi to do sytuacji, w której każdy pracuje „po swojemu”, a efektywność zespołu spada. Opowiadamy o typowych błędnych założeniach, które przyspieszają ten proces, oraz pokazujemy praktyczne sposoby na zatrzymanie erozji wiedzy. Dowiesz się, jak sprawić, by szkolenia były tylko początkiem, a realny rozwój trwał w codziennej pracy Twojego zespołu.

Większość zespołów, zwłaszcza tych pracujących dłużej w podobnym składzie, wypracowuje własną kombinację praktyk. Część z nich wspiera efektywność, ale część działań wręcz ją ogranicza. Nie są to praktyki opisane w książkach ani zgodne z modelem, teorią czy popularnym podejściem. Nie stanowią też świadomej i korzystnej ewolucji istniejących metod. To raczej lokalne modyfikacje, często niezamierzone i nieuświadomione, które sprawiają, że zespół wykonuje pewne działania, lecz nie czerpie z nich korzyści ani w pierwotnej formie, ani w nowej wersji.

Spis treści

• Zdefiniowanie zjawiska
• Jakie założenia mogą prowadzić do erozji efektów szkoleniowych?
• Jak rozpoznać, że problem erozji wiedzy dotyczy twojego obszaru?
• Co zrobić, żeby przezwyciężyć erozję wiedzy i umiejętności?
• FAQ: Powolna erozja efektów szkoleniowych
• Transkrypcja podcastu „Powolna erozja efektów szkoleniowych”

Oto przykład z praktyki. Jeden z zespołów potraktował koncepcję Backlogu Produktu w uproszczony sposób: po zakończeniu zadania każdy wybierał kolejne działanie według własnego uznania. W efekcie członkowie skupiali się na tematach, które wydawały się sensowne w danym momencie, pomijając fakt, że Backlog Produktu powinien być uporządkowany. Najważniejsze elementy muszą znajdować się na jego górze i to właśnie na nich zespół powinien koncentrować się w pierwszej kolejności.

Kolejny przykład związany jest z retrospektywą. Kilka lat temu jeden z zespołów, wcześniej uczestniczący w szkoleniu z podstaw Scruma, poprosił o wsparcie. Zespół dobrze współpracował i rozwijał się, a po pewnym czasie poprosił o dodatkowe wsparcie. Niezależnie od szczegółów, ciekawą obserwacją było przyjęcie przez zespół założenia, iż Retrospektywa służy wyłącznie rozmowom o relacjach w zespole. Wpływ na to miało podejście ówczesnego Scrum Mastera, który koncentrował się głównie na tym obszarze, jednak równocześnie pojawiła się potrzeba usprawnienia procesu wytwórczego w obszarze standardów kodowania i narzędzi używanych przez deweloperów. Początkowo trudno było zrozumieć, dlaczego zespół nie wykorzystywał do tego Retrospektywy, dopóki nie okazało się, że format spotkań koncentrował się wyłącznie na relacjach, komunikacji i emocjach. W efekcie w tej niezamierzonej modyfikacji zabrakło przestrzeni na rozmowę deweloperów o standardach kodowania i sposobach pracy.

Chcemy zwrócić uwagę na degradację i erozję praktyk prowadzącą do sytuacji, w której z pierwotnych metod pozostają jedynie szczątkowe elementy, które nie zapewniają efektu, na jaki początkowo liczono.

Poniżej znajdziesz przykłady takich założeń – to nie jest pełna lista, ale możesz potraktować ją jako listę do autorefleksji, swoistą checklistę. Zastanów się, czy w Twoim zespole albo w obszarze, którym zarządzasz, takie założenia mogą występować, a także, czy czasem nie pojawiają się one w Twoim własnym myśleniu.

Skoro raz przerobiono materiał – na przykład trzy lata temu – pojawia się przekonanie, że to wystarczy, nie ma potrzeby do niego wracać, bo treści są opanowane, wykorzystywane w praktyce i temat został zamknięty.

Zakłada się, że każdy nowy członek zespołu lub osoba, która przenosi się pomiędzy zespołami w większej firmie rozumie pojęcia w taki sam sposób jak osoby już obecne w zespole lub ci, którzy wcześniej odbyli szkolenie w odpowiednim formacie.

Trzecie założenie opiera się na przekonaniu, że pewne koncepcje są oczywiste i nie wymagają tłumaczenia. To punkt podobny do poprzedniego, choć różni się źródłem. W tym przypadku chodzi o tzw. klątwę wiedzy: doświadczeni pracownicy i menedżerowie zapominają, jak to jest czegoś nie wiedzieć. Przyjmują, że określone koncepcje są oczywiste dla każdego, a w konsekwencji nie dostrzegają potrzeby ich ponownego wyjaśniania ani organizowania dedykowanych szkoleń.

Czwarte założenie zakłada, że pracownicy nauczą się w praktyce od bardziej doświadczonych osób. Oparte jest ono na przekonaniu o pewnej sekwencji zdarzeń. Dzięki temu poprawiono proces, a nowi członkowie, dołączając do usprawnionego środowiska – mają rzekomo uczyć się wyłącznie poprzez praktykę, co prowadzi do wniosku, że nie potrzebują teorii ani dodatkowych szkoleń. Zakłada się, że mechanizm ten będzie samonapędzający, niczym efekt „perpetuum mobile”. Każda nowa osoba ma uczyć się od poprzedników, co rzekomo eliminuje konieczność organizowania szkoleń.

Kolejnym powodem degradacji efektów szkoleniowych jest brak budżetów na ponowne szkolenia z tego samego obszaru. To proza życia – firmy często nie inwestują wystarczająco w rozwój pracowników. A jeśli raz przeznaczono środki na dane zagadnienie, trudno jest uzyskać nowy budżet po kilku latach na ten sam temat. Uznaje się bowiem, że to temat zamknięty. Szczególnie trudne staje się to wtedy, gdy pojawiają się nowe trendy i modne praktyki, które  zdaniem zarządzających, lepiej uzasadniają wydatki i wydają się ważniejsze. Przykładem może być zagadnienie sztucznej inteligencji, które dotyka dziś niemal wszystkich. To obszar, który może wypierać inne ważne tematy, istotne dla Twojego zespołu i Twojej pracy.

Ostatnie założenie zakłada, że szkolenia nic nie dają. Źródłem tego przekonania bywają złe doświadczenia z wcześniejszych szkoleń lub programów rozwojowych, szczególnie jeśli miały one charakter masowy albo dotyczyły wyłącznie podstaw, kierowanych do osób początkujących. Z takich szkoleń zespoły mogły niewiele wynieść, a menedżerowie otrzymali negatywną informację zwrotną i nie chcą powtarzać tego formatu. Szczególnie gdy szkolenia dotyczyły rytuałów, konkretnych narzędzi lub rozwiązań niedopasowanych do kontekstu organizacji czy zespołu, można zrozumieć niechęć i świadome nastawienie do unikania takich działań. Problem pojawia się wtedy, gdy nie organizuje się ani takich, ani żadnych innych szkoleń, a erozja efektów postępuje i nie jest równoważona.

Istnieją jednak fundamentalne zasady, a także praktyki i umiejętności, które każda firma powinna rozwijać i cyklicznie podtrzymywać. Nie chodzi tu o samą deklarację zwinności. Kluczowe są takie elementy jak efektywność działań, przewidywalność, jakość dostarczanych rezultatów oraz koncentracja na tym, by faktycznie dostarczać wartość odbiorcy. Warto więc zadać sobie pytanie, czy te fundamentalne aspekty są właściwie prowadzone.

Przedstawiamy kilka praktyk, możesz wykorzystać jedną lub kilka z nich. Warto jednak rozważyć wszystkie, które zostaną wymienione, ponieważ razem tworzą spójny program do przeanalizowania sytuacji w Twoim obszarze.

W wielu zespołach mówi się o efektywności, a w wielu firmach oczekuje się od zarządzających jej poprawy. Problem w codziennej praktyce polega na tym, że często trudno jest tę efektywność precyzyjnie zdefiniować i zmierzyć. Dlatego warto jasno określić miarę efektywności dla swojego zespołu, zmierzyć ją i sprawdzić wyniki. To, czy efektywność jest satysfakcjonująca, może stać się kluczowym punktem w dalszej dyskusji o tym, co należy zrobić, aby zmienić sposób działania zespołu lub obszaru.

W dobrze zorganizowanych procesach wytwórczych stosuje się opomiarowanie, co pozwala ocenić ich kondycję na podstawie konkretnych wskaźników. Mogą się one różnić w zależności od organizacji. Jeśli jednak pojawiają się niepokojące trendy w tych wskaźnikach albo od dawna utrzymują się na niskim poziomie, może to oznaczać, że np. niski wskaźnik jakościowy wskazuje na stopniową utratę kompetencji lub umiejętności związanych z zapewnieniem jakości w zespole.

Chodzi o przyjrzenie się procesowi wytwórczemu lub szerzej – procesowi tworzenia i rozwoju produktu. Należy ocenić, które kroki budują wartość, a które jej nie tworzą. Celem jest refleksja nad całością procesu, bez wskazywania pojedynczych praktyk. Zastanów się, gdzie w procesie występuje marnotrawstwo, przestoje lub opóźnienia, a także które punkty zapalne utrudniają pracę i powodują, że proces nie działa sprawnie. Taka analiza ma częściowo charakter ekspercki i jakościowy, ale może dostarczyć cennych wniosków. Dzięki niej możesz zidentyfikować miejsca, w których proces nie funkcjonuje prawidłowo, co często wiąże się z praktykami i wiedzą członków zespołu, którym zarządzasz.

Warto ocenić, czy osoby będące odbiorcami rezultatów lub zainteresowane ich efektami są zadowolone i uważają, że rezultaty procesu wytwórczego mają odpowiednią jakość. Jeśli nie, może to oznaczać, że w zespole pozostały luki kompetencyjne. W takiej sytuacji osoby oceniające efekty pracy mogą dostrzegać coraz więcej niedociągnięć.

Poprzednia wskazówka dotyczyła otoczenia zespołu, ta skupia się na jego wnętrzu. Brzmi: spytaj obecnych i odchodzących pracowników o rozwój. Porozmawiaj z wybranymi lub wszystkimi członkami zespołu i sprawdź, jak się rozwijają, jak wykorzystują zdobyte kompetencje i w jaki sposób rozwijają się w codziennej pracy oraz w projektach. Oceń, czy kierunek rozwoju odpowiada potrzebom zespołu i organizacji. Ważne jest nie tylko to, czy pracownicy są zadowoleni, lecz także to, czy kierunek ich rozwoju jest właściwy i zgodny z potrzebami Twojego obszaru, firmy jako całości oraz produktu, za który odpowiadasz. Sygnałem alarmowym jest informacja od odchodzących pracowników, że nie mieli możliwości rozwoju. To wyraźny znak, że w zespole trudno się rozwijać, lub że rozwój jest niesatysfakcjonujący dla osób, na których najbardziej Ci zależy.

Zwróć uwagę nie tylko na to, co zespół dostarcza, ale także na sposób, w jaki to robi. Ważne jest jednak, aby osoba prowadząca obserwację miała odpowiednie doświadczenie i dobrze rozumiała poprawność stosowanych praktyk. Jeśli nie czujesz się na siłach lub w firmie nie ma osób zdolnych zrobić to rzetelnie, warto rozważyć powierzenie tego zadania osobie spoza organizacji.

Ostatnia porada idzie nieco w poprzek poprzednich sześciu. Zastanów się, w jakim stopniu wiarygodne są wyniki wcześniejszych analiz. Oceń, czy to, co widzisz w pomiarach, analizach procesów, danych i rozmowach, rzeczywiście odzwierciedla prawdę. Groźnym zjawiskiem bywa „teatr pozorów”, czyli fałszowanie wyników, udzielanie oczekiwanych, a nie prawdziwych odpowiedzi oraz inne podobne praktyki, które mogą sprawić, że wyniki badań i analiz będą całkowicie rozbieżne z rzeczywistością. Dlatego z jednej strony warto bazować na własnej intuicji – nawet jeśli wskaźniki sugerują, że jakość jest wysoka, a stosowane praktyki światowej klasy. Jeśli jednak awarie następują jedna po drugiej, a interesariusze sygnalizują, że coś jest nie tak, i sam widzisz, że sytuacja jest nie do przyjęcia, być może trzeba odrzucić wyniki poprzednich analiz lub całych etapów oceny. Ważne, by nie wpaść w mechaniczną pułapkę bezkrytycznego zaufania słowom, liczbom czy wykresom. Równocześnie warto spojrzeć na sprawę z własnej perspektywy i na tej podstawie zastanowić się, czy działania naprawcze nie są konieczne, czy erozja efektów szkoleniowych, stosowanych praktyk, umiejętności lub wiedzy już nie nastąpiła, albo właśnie nie zbliża się wielkimi krokami.

Nawet jeśli po przeanalizowaniu tych punktów uznasz, że sytuacja wygląda dobrze, warto spojrzeć na temat w perspektywie długofalowej. Oznacza to nie tylko obserwację bieżącej sytuacji, by nie wpaść w pułapkę erozji wiedzy, umiejętności i praktyk. 

wiedzę. Warto przyjąć założenie, że wiedza z czasem się zaciera. Możesz zaplanować powtórkę teoretyczną, krótką „pigułkę wiedzy”, ale też zadbać o powrót trenera lub mentora do zespołu po pewnym czasie, aby sprawdzić, czy elementy omawiane na szkoleniu faktycznie są wykorzystywane i czy są stosowane we właściwy sposób.

Powtórkę warto czasem przeprowadzić z innym trenerem, a powodów takiej decyzji może być wiele. Pierwsze szkolenie mogło być niedopasowane, a uczestnicy obwiniają prowadzącego, wtedy zmiana trenera bywa konieczna. Może się też okazać, że zespół potrzebuje osoby o innym profilu – bardziej zaawansowanej lub posiadającej większe doświadczenie praktyczne. Przyczyn zmiany jest wiele, dlatego warto świadomie rozważyć taką decyzję. Nawet bez negatywnych doświadczeń dobrze jest „czerpać wodę z różnych studni”. Widać to choćby na przykładzie szkoleń scrumowych – uczestnictwo w kilku różnych daje szerszą perspektywę. Każde szkolenie było inne – prowadzone w odmiennym stylu, związane z innym doświadczeniem i temperamentem trenera. Dzięki temu powstało lepsze, wielostronne zrozumienie – warto o to zadbać także w przypadku Twojego zespołu. Nawet jeśli pierwszy trener był bardzo dobry, warto spróbować kogoś, kto pokaże sprawę w nowym świetle, trafi do zespołu innym sposobem, przytoczy inne przykłady i doświadczenia, co ostatecznie buduje solidniejszy fundament i poszerza wiedzę zespołu.

Zakłada ona, że znasz już więcej i Twój zespół potrafi precyzyjnie określić swoje potrzeby, bo ma za sobą podstawowe szkolenia i pierwsze doświadczenia praktyczne. W takiej sytuacji szablonowe, katalogowe szkolenia mogą nie odpowiadać na potrzeby ani zespołu, ani Twojego obszaru. Dlatego warto precyzyjnie wskazać faktyczne potrzeby i wyzwania szkoleniowe, a następnie przedstawić je trenerowi lub osobie odpowiedzialnej za przygotowanie szkolenia, aby szkolenie było rzeczywiście dopasowane do potrzeb Twojego zespołu i obszaru.

Przykładowo, jeżeli zespół ma zdiagnozowany problem z dzieleniem pracy na mniejsze części, warto, aby szkolenie uzupełniające koncentrowało się właśnie na tym obszarze oraz opierało się na rzeczywistych przykładach zespołu, a nie na wyidealizowanych, ogólnych scenariuszach, aby łatwiej było zrozumieć koncepcje i sprawdzić ich wykonalność na własnym gruncie.

Łatwo wpaść w pułapkę zapominania, że nowe osoby w organizacji również potrzebują szkoleń wyrównawczych, zdobycia wiedzy i rozwinięcia konkretnych umiejętności. Warto zatem sprawdzić, czy mają możliwość udziału w szkoleniach wyrównawczych oraz, czy istnieje systemowe podejście, np. regularne, półroczne przeglądy listy nowozatrudnionych. W takim przeglądzie należy ocenić, jakie szkolenia już się odbyły, a których brakuje, oraz jak zorganizować grupy szkoleniowe, aby nikt nie miał poczucia, że nie otrzymał potrzebnego szkolenia lub nie miał szansy w nim uczestniczyć.

Praktyka pokazuje, że programy wyrównawcze mogą być realizowane zarówno w formie obowiązkowej dla wszystkich nowozatrudnionych, jak i w ramach grup mieszanych, tworzonych z nowych pracowników pochodzących z różnych części firmy. W dużych firmach łatwiej zebrać grupę, ponieważ liczba nowych pracowników jest na tyle duża, że naturalnie tworzy się grupa szkoleniowa. Większym wyzwaniem staje się sytuacja, gdy w ciągu roku zatrudniono np. tylko jednego nowego programistę. Wówczas trudno utworzyć zamkniętą grupę i konieczne staje się poszukanie alternatyw. Można wtedy skorzystać ze szkoleń otwartych, w których uczestniczą osoby z różnych organizacji. Takie rozwiązanie ma dodatkową zaletę – pozwala na wymianę doświadczeń pomiędzy różnymi firmami. Kluczowe jest jednak, aby unikać myślenia w stylu: „wszyscy odbyli szkolenie”, skoro szkoleniem objęto osoby zatrudnione np. w marcu 2023 roku, a pominięto pięciu nowych pracowników, którzy dołączyli później.

Jedną z przyczyn erozji bywa zbyt mały nacisk na wdrażanie nowych praktyk, pokonywanie trudności w ich stosowaniu oraz wspieranie osób odpowiedzialnych za konkretne obszary.

Taką odpowiedzialność mogą ponosić np. Product Owner, Agile Coach, Scrum Master, User Experience Designer lub lider techniczny. W praktyce często wskazuje się osobę odpowiedzialną za daną praktykę – pełniącą jednocześnie rolę mentora, lidera zmiany i osoby pilnującej, by zmiana faktycznie postępowała. W różnych firmach wygląda to zupełnie inaczej. W jednej organizacji management mocno wspiera zmianę, a osoby ją pilotujące mają codzienne wsparcie, poparcie i odpowiednią reakcję w razie problemów. W innych przypadkach osoby odpowiedzialne za zmianę są osamotnione – mają duże oczekiwania wobec siebie, ale niewielkie wsparcie otoczenia. To punkt do refleksji: jak bardzo z perspektywy managerskiej lub liderskiej wspierasz stosowanie nowych praktyk, podejść i rozwiązań oraz dbasz o ich utrwalenie w zmianie.

Przykładem z życia może być program rozwojowy realizowany w jednej z organizacji, w ramach którego wszystkie osoby na poziomie liderskim uczestniczyły w szkoleniu i warsztatach dotyczących regularnego usprawniania pracy. Otrzymali oni dodatkowe sesje szkoleniowe, pogłębioną porcję wiedzy oraz dedykowane warsztaty, podczas których na głębszym poziomie pracowali nad koncepcjami potrzebnymi w praktyce, aby mogli skutecznie pełnić rolę osób odpowiedzialnych za to, by ciągłe usprawnianie faktycznie miało miejsce i było elementem kultury organizacyjnej.

Dużo uwagi poświęciliśmy dużym formom rozwojowym, takim jak warsztaty, szkolenia czy programy. Istnieje jednak wiele mniejszych form, które również mogą być wartościowe. To np. gildie czy spotkania służące wymianie wiedzy, minikonferencje poświęcone najważniejszym tematom, dzielenie się doświadczeniami czy nawet proste działania, takie jak stworzenie czasu na eksperymentowanie z nowo nabytą wiedzą. Wszystkie te formy świetnie uzupełniają klasyczne działania rozwojowe. Warto sprawdzić, czy organizacja w ogóle korzysta z tego typu rozwiązań. Jeśli nie, przyjrzyj się tej liście i zastanów, aby najistotniejsze praktyki mogły skutecznie propagować się w organizacji.

Powód, aby stosować takie formaty, jest podwójny. Po pierwsze, wymiana najlepszych praktyk między zespołami spowalnia erozję wiedzy a czasem wręcz jej zapobiega. Może też przynieść pozytywny efekt wzajemnego wspierania się i inspirowania do rozwoju we właściwym kierunku. To nie tylko przeciwdziałanie zapominaniu, ale wręcz napędzanie się zespołów do jeszcze lepszego działania. Po drugie, propagowanie wiedzy uruchamia mechanizm uczenia się poprzez nauczanie innych. Eksperci i osoby z unikalnym doświadczeniem, występując np. na minikonferencji, nie tylko inspirują innych, ale także porządkują własną wiedzę, ćwiczą się w jej przekazywaniu i doskonalą umiejętność dzielenia się nią. Dzięki temu wiedza przepływa wprost pomiędzy zespołami, a dodatkowo najlepsi eksperci, którzy dzielą się doświadczeniem, sami ją utrwalają i uczą się, jak skuteczniej propagować ją dalej.

Po poprzednim rozdziale mogło pojawić się pytanie, jak taką wielowymiarową analizę procesów przeprowadzić jednorazowo, skoro część osób robi to na bieżąco. Jeśli robisz to regularnie – to świetnie. Jednak nie wszyscy działają w takim trybie ciągłym, dlatego pojawia się oddzielna porada: przyglądaj się procesowi, który masz pod opieką, lub temu, którego jesteś częścią. Regularnie wracaj do odpowiednich miar, sprawdzaj wyniki i obserwuj trendy, a także wykonuj badania i rozmowy, do których wcześniej zachęcaliśmy. W najgorszym przypadku pozwoli to jak najwcześniej wychwycić niepokojące objawy i sygnały ostrzegawcze. Ogólnie rzecz biorąc, to także dobra praktyka managerska, aby zachować zdroworozsądkową kontrolę nad procesem, wiedzieć, w jakim kierunku zmierza i kiedy należy uważniej przyjrzeć się sprawom, by je korygować lub wspierać ich usprawnienie

Erozja efektów szkoleniowych to proces, w którym wiedza i umiejętności zdobyte na szkoleniu stopniowo zanikają, a zespoły wracają do starych lub nieefektywnych nawyków.

Nowa wiedza ulega zapomnieniu, bez powtórek i utrwalania – a organizacja nie zyskuje trwałej poprawy efektywności.

Widzisz spadek jakości, chaos w praktykach zespołowych i poczucie, że każdy pracuje inaczej – mimo wcześniejszych szkoleń.

Jeśli ignorujesz zaistniały problem, to spadnie efektywność i przewidywalność pracy, pojawiają się błędy, frustracja i niższa satysfakcja interesariuszy.

Planuj powtarzalne formy rozwojowe – warsztaty, sesje wymiany wiedzy czy szkolenia wyrównawcze dla nowych pracowników.

Zapewnij wszystkim nowym pracownikom program wyrównawczy, aby nie kopiowali złych nawyków, tylko od razu weszli w sprawdzone praktyki.

Szkolenie dopasowane do realnych potrzeb firmy daje Ci pewność, że uczestnicy rozwiązują konkretne problemy swojego zespołu, a nie tracą czas na generyczne przykłady z szablonu.

Monitorowanie procesu i statysfakcja interesariuszy pozwoli Ci wcześnie wychwycić problemy i szybko reagować, zanim drobne braki przerodzą się w poważne dysfunkcje.

Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu Porządny Agile.

Jacek: Wiele firm przeszkoliło się ze zwinności 5-10 lat temu. Od tego czasu zespoły się dosyć mocno zmieniły. Część osób naturalnie odeszła, pojawiły się też nowe osoby. Tyle że ci nowi uczą się praktyk pracy zespołowej poprzez obserwację, kopiując zachowania starszych kolegów i koleżanek. Tych dobrych zachowań, jak również i tych złych. Ostatecznie niby wszyscy wiedzą, jak pracować efektywnie, ale tak naprawdę każdy robi to po swojemu.

Kuba: I o tym będzie ten dzisiejszy odcinek o zjawisku, które nazwaliśmy w tytule erozją wiedzy czy erozją umiejętności. I choć Jacek w tym swoim przykładzie i wstępie wspomniał o zwinności, ale tak czujemy, że tak naprawdę można bardzo łatwo uogólnić materiał, który zaprezentujemy. Bo to równie dobrze może chodzić o zarządzanie projektami, o praktyki Product Discovery, pracę w podejściu DevOps, narzędzia związane z AI, czy cokolwiek z czego aktualnie albo kilka lat temu szkolił się dany zespół wytwórczy, czy jego poszczególni członkowie.

Jacek: Spis treści dzisiejszego odcinka jest następujący. Zdefiniujemy zjawisko, o którym opowiadamy. Odpowiemy na pytanie, jakie założenia mogą prowadzić do erozji efektów szkoleniowych. Podpowiemy, jak rozpoznać, że problem erozji wiedzy dotyczy twojego obszaru. I na koniec powiemy, co zrobić, żeby przezwyciężyć erozję wiedzy i umiejętności.

Kuba: To przechodząc do pierwszego rozdziału, zdefiniowanie zjawiska. Uogólniając. Większość zespołów, jakie spotykamy, zwłaszcza tych, które pracują dłużej w danym składzie albo mniej więcej w takim składzie, zespoły te mają jakąś unikalną kombinację praktyk. Część z tych praktyk jest bardzo korzystna, ale część z tych praktyk, takich, jakie spotykamy czy napotykamy w danym zespole, to są działania, które nie wspierają efektywności tego zespołu. Nie są to praktyki z jakiejś książki, nie są to zgodne z jakimś modelem czy teorią, czy czymś, co jest popularne, ale to nie jest też jakaś korzystna ewolucja danej praktyki. To nie jest tak, że zespół znalazł swój unikalny sposób na planowanie, swój sposób na synchronizację, tylko są to jakieś takie lokalne mutacje, nie chcę użyć za mocnego słowa, ale takie jakieś coś, co idzie w stronę dysfunkcji albo jakiejś modyfikacji, ale takiej bezwiednej, mimowolnej, trochę nieświadomej, która powoduje, że zespół wykonuje jakieś praktyki, ale tak naprawdę nie ma ani żadnych korzyści z tej oryginalnej praktyki, ani nie ma żadnej korzyści z jakiejś takiej świadomej modyfikacji.

Jacek: Przykład taki z mojej praktyki. Pracowałem ostatnio z zespołem, który, no właśnie tak jak Kuba opowiada, wypatrzył pewną konkretną ideę, w tym przypadku była to koncepcja Backlogu Produktu, gdzie po zakończeniu swojego zadania, czy jakiejś konkretnego kawałka pracy, każdy z zespołu robił sobie to, co po prostu uważał w danym momencie za sensowne. Jakiś temat, za który odpowiadał jakieś zadanie, które wydawało się w danym momencie sensowne, trochę zapominając, że koncepcja Backlogu Produktu mówi nam o tym, że jest on uporządkowany i tak naprawdę te najbardziej istotne elementy powinny się znajdować na górze Backlogu Produktu i to na nie powinniśmy tak naprawdę w pierwszej kolejności patrzeć.

Kuba: Mój przykład będzie o Retrospektywie. Jakiś czas temu wróciłem do zespołu, który poznałem dwa lata wcześniej niż w tej historii, podczas szkolenia z podstaw Scruma. Zespół ten fajnie się zgrywał, fajnie się rozwijał, natomiast po jakimś czasie wrócili do mnie z prośbą o pewne wsparcie i abstrahując do tego, o co tam dokładnie chodziło, jedną z ciekawostek, jaką zaobserwowałem, to to, że zespół przyjął założenie, że Retrospektywa służy wyłącznie do rozmowy o relacji w zespole. Tak sobie to dookreślili, tam były konkretne powody ku temu, bo tak też mocno nastawiony był ich ówczesny Scrum Master, no ale przyszli z prośbą o to, żebym im pomógł w tym, jak usprawnić ich proces wytwórczy od strony takiej twardej związanej ze standardami kodowania i narzędziami wykorzystywanymi przez deweloperów. Kompletnie nie potrafiłem zrozumieć, dlaczego nie używają do tego Retrospektywy, póki nie zobaczyłem, że faktycznie formaty Retro były ciągle skupione wokół wątków relacji, komunikacji, wzajemnych emocji. No i faktycznie w tym wariancie, w tej ich modyfikacji, czy takiej jakiejś bezwiednej ewolucji, no nie było przestrzeni na to, żeby sobie deweloper z deweloperem porozmawiał o tym, jak koduje.

Jacek: I słuchając tych dwóch przykładów, możesz pomyśleć, że chodzi nam o coś, co definiuje się jako Kult Cargo. Nagraliśmy o tym oddzielny odcinek, znajdziesz go pod adresem porzadnyagile.pl/78. Natomiast w dzisiejszym odcinku chcemy powiedzieć o czymś, co jest jednak trochę inne. Nie chcemy mówić o ślepym kopiowaniu i trzymaniu się poszczególnych praktyk, tak trochę nie rozumiejąc sensu, a bardziej chcielibyśmy zwrócić uwagę na pewnego rodzaju degradację i erozję praktyk w taki sposób, że z tych oryginalnych, pierwotnych praktyk zostają już tak naprawdę szczątkowe elementy, które już nie dają tego efektu, na którym nam pierwotnie zależało.

Kuba: Ok, to przechodząc do kolejnego rozdziału, jakie założenia mogą prowadzić do erozji efektów szkoleniowych? Wymienimy takie założenia, które nam przychodzą do głowy, pewnie nie są to wszystkie, natomiast potraktuj, słuchając tę listę, jako taką swego rodzaju listę do autorefleksji, jakąś checklistę. Zastanów się, czy w Twoim zespole, w Twoim obszarze, którym zarządzasz, takie założenia mogą mieć miejsce lub, co ważne, czy takie założenia czasami nie są w twojej głowie?

Jacek: Pierwsze założenie może być takie, że szkolenie to jednorazowy zastrzyk wiedzy dla danego zespołu. Czyli raz zrobili konkretny materiał trzy lata temu, przepracowali go i wszyscy czują, że wystarczy, nie ma po co do tego wracać, te rzeczy są opanowane, wykorzystywane w praktyce, raz zostały zrealizowane i wystarczy.

Kuba: Drugie możliwe założenie to założenie, że wiedza na dany temat jest powszechna. Czyli każdy nowozatrudniony członek zespołu czy osoba przesuwana pomiędzy zespołami w większej firmie wie i rozumie pojęcia tak samo, jak są one rozumiane u tych, których już w zespole masz, albo tych, których w zespole wcześniej przeszkoliłeś czy zostali przeszkoleni przez jakiś odpowiedni format szkoleniowy.

Jacek: Kolejne założenie może być takie, że pewne koncepty są oczywiste, nie trzeba już ich tłumaczyć. Jest to podobny punkt do tego, co mówił Kuba przed chwilą, ale jednak trochę inne jest pochodzenie tego założenia. Tutaj bardziej myślimy o klątwie wiedzy, czyli doświadczeni pracownicy, managerowie zapominają tak naprawdę, jak to jest nie wiedzieć. Zakładają, że pewne koncepcje są po prostu oczywiste dla wszystkich, przez co nie widzą potrzeby ich ponownego tłumaczenia czy organizowania dedykowanego szkolenia.

Kuba: Inne możliwe założenie to to, że pracownicy nauczą się w boju od doświadczonych osób. Czyli założenie, które w skrócie zakłada pewną taką sekwencję. Część członków zespołu, czy może ówczesny skład zespołu dostał zastrzyk wiedzy, czy szkolenia. Dzięki temu poprawili swój proces i osoby, które wejdą już w dobrze poprawiony proces będą w zasadzie nauczone w praktyce, więc nie potrzebują żadnej teorii, ani żadnych szkoleń, bo to będzie się tak jakby samo napędzać, czy taki efekt trochę perpetuum mobile. Każda nowa osoba nauczy się od poprzedników i dzięki temu unikniemy potrzeby szkolenia.

Kuba: Kolejny powód degradacji efektów szkoleniowych jest taki, że być może nie ma budżetów na powtórne szkolenia z tego samego. Czyli taka trochę proza życia, gdzie firmy nie inwestują tyle, ile trzeba w rozwój pracowników. Jeśli natomiast wydawane są jakieś kwoty na dane zagadnienia, to trudno jest uzyskać nowe budżety po paru latach na to samo. Coś, co już przecież przepracowywaliśmy. I to w szczególności może być trudne, jeśli na horyzoncie pojawiają się kolejne nowinki, kolejne trendy, kolejne modne praktyki, które być może lepiej uzasadnią wydatki i zdaniem zarządzających, potrzeba rozwoju w tej sferze może być jeszcze bardziej paląca. Takim przykładem, który myślę dotyka nas wszystkich, to jest na przykład zagadnienie związane ze sztuczną inteligencją. Może to być temat, który będzie wypierał inne istotne obszary ważne dla Twojego zespołu i Twojego obszaru.

Kuba: I ostatnie założenie, trochę z innej parafii, to założenie szkolenia nic nie dają. Może to wynikać z złych doświadczeń, z dotychczas przeprowadzonych szkoleń czy programów rozwojowych, zwłaszcza jeśli to były działania mające charakter, nazwijmy to masowy, albo były to szkolenia absolutnie o podstawach dla osób bardzo początkujących. Z takich szkoleń być może niewiele wyniosły zespoły, managerowie też usłyszeli złą informację zwrotną no i nie mają ochoty ich powtórzyć w takim właśnie kształcie. Zwłaszcza jeśli były to rzeczy o rytuałach, o konkretnych, precyzyjnych rozwiązaniach, narzędziach niedopasowanych do kontekstu danej organizacji czy konkretnego zespołu, to nie ma znaczenia na to, rozumiem, że może być niechęć, czy bardzo świadome nastawienie unikania takich szkoleń. No gorzej, że takich szkoleń się nie robi i żadnych innych też nie, więc te erozje, efektów następują i nie za bardzo są skontrowane.

Jacek: Natomiast z Kubą uważamy, że są pewne fundamentalne zasady, fundamentalne praktyki czy umiejętności które firma powinna rozwijać, ale co ważne też cyklicznie podtrzymywać. I nie chodzi nam tutaj na przykład o to, że trzeba być zwinnym. Bardziej chcemy zwrócić uwagę na takie fundamentalne rzeczy jak efektywność działań, przewidywalność, jakość tego, co zespołu dostarczają, czy skupienie na tym, żeby faktycznie dostarczać wartość dla odbiorcy. No i w tym wszystkim taka refleksja, czy te kluczowe fundamentalne aspekty, czy one są porządnie zaopiekowane.

Kuba: To czas na trzeci rozdział. Jak rozpoznać, że problem erozji wiedzy dotyczy twojego obszaru? Pokażemy tutaj kilka możliwych praktyk. Może zastosujesz jedną lub kilka. Prawdopodobnie warto rozważyć w zasadzie wszystkie, które wymienimy, bo stanowi to pewien taki kompleksowy program, czy może system do przeanalizowania tego, jak to wygląda w twoim obszarze. 

Kuba: Pierwszy punkt. Zmiesz efektywność zespołów. W wielu zespołach mówi się o efektywności, w wielu firmach od zarządzających oczekuje się poprawy efektywności. Natomiast niestety na razie proza życia i taka codzienność, jaką spotykam, to to, że mówi się o tym, ale nie za bardzo umie się to zdefiniować i w efekcie zmierzyć. Więc cokolwiek jest tą miarą efektywności dla twojego zespołu, nazwij to, zmierz to, zobacz jakie masz wyniki, bo to, że efektywność jest jakaś i czy ona jest satysfakcjonująca, może być bardzo ważnym punktem w dalszej dyskusji o tym, co zrobić, żeby zmienić sposób działania twojego zespołu lub obszaru.

Jacek: Drugą rzecz, którą warto sprawdzić, to prześledzenie wyników miar procesu wytwórczego. Dobre procesy wytwórcze są opomiarowane, czyli jesteśmy w stanie ocenić kondycję procesu, patrząc na konkretne miary procesowe. One mogą być różne w zależności od organizacji. Natomiast jeżeli widzimy niepokojące trendy, jeśli chodzi o te wskaźniki, albo po prostu one są od zawsze kiepskie, więc to nawet nie możemy mówić o trendzie, no to może to być sygnał, że na przykład jeżeli pewną miarą procesu jest np. jakiś wskaźnik jakościowy, no to fakt, że on jest niski może wynikać z tego, że pewne kompetencje czy pewne umiejętności dotyczące zapewnienia wysokiej jakości zaczynają powoli z zespołu ulatywać.

Kuba: Trzecia podpowiedź, przeanalizuj proces od strony dostarczania wartości. Mamy tu na myśli przyjrzenie się procesowi wytwórczemu, czy może jeszcze szerzej jakiemuś procesowi tworzenia produktu i jego rozwoju. Od tej perspektywy dostarczania wartości kroków, które tę wartość budują i kroków, których tej wartości nie budują. Bardzo opisowo, bez może konkretnego wskazywania tej praktyki chodzi nam o to, żeby dokonać refleksji. Zastanów się, gdzie masz w procesie marnotrawstwo, gdzie masz w procesie przestoje, gdzie są jakieś opóźnienia, gdzie są jakieś takie typowe punkty zapalne, które powodują, że jest gorzej, że jest ciężko, że coś nie działa. To już jest oczywiście pewnego rodzaju analiza taka trochę ekspercka, trochę taka jakościowa, ale jednak dająca pewne przemyślenia. Po takiej szerokiej analizie możesz mieć podpowiedzi na temat tego, gdzie w procesie coś nie gra i to może być bardzo powiązane z praktykami i wiedzą członków zespołu, którymi zarządzasz.

Jacek: Kolejna wskazówka zwraca uwagę na trochę inny obszar, mianowicie sprawdź satysfakcję ze współpracy u interesariuszy. Czyli zachęcamy do sprawdzenia, czy osoby, które są odbiorcami tego, co wytwarzamy, czy są po prostu osobami, którym zależy z różnych powodów na tych efektach, czy są zadowolone, czy ich zdaniem to, co wypływa z procesu wytwórczego jest na odpowiednim poziomie jakościowym. Jeżeli nie, może to świadczyć o tym, że pewne luki w kompetencjach nie zostały zaopiekowane. No i jest już na tyle późno, że osoby, które patrzą na to, jakie są efekty pracy, zaczynają obserwować niedociągnięcia.

Kuba: Jacka wskazówka mówiła o tym, żeby przyjrzeć się otoczeniu zespołu, natomiast moja mówi o tym, żeby zajrzeć do środka tego zespołu. I brzmi. Spytaj obecnych i odchodzących pracowników o ich rozwój. Porozmawiaj z wybranymi, a może wszystkimi, jeśli się da członkami swojego zespołu i sprawdź, jak się rozwijają, jak wykorzystują poznane kompetencje, jak sami też rozbudowują w trakcie działania takiego no codziennego czy projektowego. No i oceń, czy rozwijają się zgodnie z potrzebami. Nie tylko słuchaj tego, że oni są usatysfakcjonowani, no lub nie, ale też czy to w którą stronę się ci ludzie rozwijają tak, jak się to dzieje, czy jest zgodne z tym, czego Twój obszar, firma jako całość czy produkt, który masz pod opieką, czy to wszystko idzie w dobrą stronę. W szczególności niepokojące jest, jeśli odchodzący pracownicy jednak dają sygnał, że tego rozwoju nie ma, to może być taki no bardzo namacalny znak, że trudno się w tym zespole rozwinąć, no albo jest to niesatysfakcjonujące dla osób, na których prawdopodobnie ci zależy.

Jacek: Przedostatnia wskazówka, obserwuj zespoły pod kątem poprawności stosowanych praktyk. Spójrz nie tylko na to, co zespół dostarcza, ale również na to, jak to robi. Z istotnym zastrzeżeniem, że osoba, która obserwuje powinna mieć doświadczenie odpowiednie, jak również dobre zrozumienie poprawności obserwowanych praktyk. Jeżeli nie czujesz się na siłach albo w firmie nie ma osób, które są w stanie zrobić to rzetelnie, można ewentualnie zdelegować coś takiego na osobę z zewnątrz organizacji.

Kuba: I ostatnia porada, taka trochę w poprzek wszystkich sześciu poprzednich. Zastanów się, na ile wiarygodne są wyniki poprzednich porad. Czy to, co widzisz, to, co ci wynika z pomiarów, z analiz danych, z analizy procesu, z rozmów i wywiadów, czy to jest prawda? Jednym z groźniejszych zjawisk może być pewnego rodzaju teatr pozorów, czyli nazwijmy to wprost fałszowanie wyników, odpowiedzi takie, jakie są oczekiwane, a nie prawdziwe i szereg innych kolejnych tego typu zjawisk, które może spowodować, że choć wykonasz takie badanie, taką analizę, to tak naprawdę wyniki będą zupełnie niezgodne z tym, co tak naprawdę się dzieje. Więc tutaj z jednej strony może bazuj po prostu nadal na swojej intuicji, nawet jeśli np. że z jakością jest wszystko w porządku, a praktyki stosowane są klasy światowej. No jeśli awaria goni awarię, a interesariusze dają wyraźny sygnał, że w zasadzie tak być nie powinno i ty też wiesz, że tak nie może być, no to być może po prostu trzeba odrzucić wyniki tamtych części analizy albo w ogóle całych tych kroków. Więc tutaj, żeby tylko nie wpaść w mechaniczną pułapkę takiego wierzenia na słowo albo wierzenia na liczbę czy na jakiś wykres. Oddzielnie jednak zachęcamy do spojrzenia na sprawę wyłącznie ze swojej perspektywy i dopiero na tej bazie zastanowienia się, czy jednak te działania nie są jakieś potrzebne, czy ta erozja efektów szkoleniowych, erozja stosowanych praktyk, umiejętności czy posiadanej wiedzy nie nastąpiła już albo właśnie nie puka u drzwi.

Jacek: Ale nawet jeśli po wysłuchaniu tych naszych punktów czujesz teraz, że w sumie jest dobrze, no to i tak zachęcamy do tego, żeby patrzeć na temat długofalowo, czyli nie tylko obserwować taki tam bieżący odczyt rzeczywistości, ale też wdrożyć konkretne działania, które długoterminowo będą nas chronić przed tym, żeby w pułapkę tej erozji, o której mówimy dzisiaj z Kubą, nie wpadać.

Kuba: Dobrze, to ostatni rozdział, najbardziej praktyczny. Co zrobić, żeby przezwyciężyć erozję wiedzy i umiejętności?

Jacek: Pierwsza myśl, zaplanuj powtarzalność form szkoleniowych. Mamy tu na myśli zainwestowanie w świadome powtórki, czy to warsztatów, czy innych form rozwojowych, które odświeżają wiedzę. Mając z tyłu głowy takie założenie, że ta wiedza na pewno się będzie zacierać. Z jednej strony to jest kwestia zaplanowania powtórki teoretycznej, czy powtórki pewnej pigułki wiedzy, ale równie dobrze to może być zadbanie o taki praktyczny powrót trenera czy mentora do zespołu po pewnym czasie, po to, żeby spojrzeć na to, czy te elementy, które były omawiane na szkoleniu, czy one faktycznie są wykorzystywane, to po pierwsze, a po drugie, jeśli są wykorzystywane, to czy są wykorzystywane we właściwy sposób.

Kuba: Może się tak zdarzyć, że ta powtórka, o której Jacek wspomniał, musi być albo powinna być zrealizowana z kimś innym, z innym trenerem i przyczyn tego może być wiele, bo może trafił się ten przypadek z naszych założeń, że niestety to szkolenie pierwsze nie do końca było dopasowane i tutaj winisz albo uczestnicy winią trenera i może trzeba go zmienić. A może jest też tak, że już czas na osobę o jakimś innym profilu, na przykład w większym zaawansowaniu albo w większej wiedzy praktycznej, bo zespół też już ma trochę inne potrzeby. Przyczyn zmiany może być wiele, ale warto to rozważyć, warto to tutaj bardzo świadomie zrealizować. A nawet jeśli nie jest żaden przypadek negatywny, to warto po prostu czerpać wodę z różnych studni. Ja sam sobie cenię to, że na szkoleniach na przykład scrumowych, to chyba byłem pięciu. Każdy było trochę inne, każdy było w różnym stylu, każdy było w jakimś sensie powiązane też z jakimś tam profilem doświadczenia i też temperamentu osoby prowadzącej. No i to było super, dało mi lepsze zrozumienie w wielostronną perspektywę i myślę, że tu też można zadbać. Po prostu od tej strony nawet jeśli trener pierwszy był dobry albo świetny, to dlaczego nie spróbować kogoś, kto rzuci nowe światło na sprawę, może dotrze trochę inaczej, może pokaże jakieś inne przykłady z innych firm niż te pierwszego trenera, to ostatecznie buduje bardzo fajny fundament i ciekawą wiedzę.

Jacek: Swoją drogą, pewnym sposobem na odświeżenie i uporządkowanie wiedzy mogą być nasze webinary. Znajdziesz je pod adresem porzadnyagile.pl/sklep.

Kuba: Druga porada, co zrobić, żeby przezwyciężyć erozję wiedzy, to dopasuj zakres szkoleń pod twoje faktyczne potrzeby. Przyjmuję w tej poradzie założenie, że może już wiesz co nieco więcej i też twój zespół umie precyzyjnie określić swoje potrzeby, bo już przeszedł w ten sposób jakąś podstawę, być może trochę popraktykowali i teraz może się okazać, że takie szablonowe, katalogowe szkolenia, jakieś takie powtarzalne, to już nie jest to, czego potrzebuje twój zespół, to nie jest to, czego potrzebuje twój obszar. Więc warto bardzo asertywnie, bardzo mocno podejść do precyzyjnego podania tego, co jest bolączką, potrzebą szkoleniową, i tak poprowadzić rozmowę z osobą, która takie szkolenie ewentualnie będzie realizować, albo szykuje się do jej realizacji, żeby to naprawdę było dopasowane do tego, czego potrzebujesz.

Jacek: Ale nawet jeśli po wysłuchaniu tych naszych punktów czujesz teraz, że w sumie jest dobrze, no to i tak zachęcamy do tego, żeby patrzeć na temat długofalowo, czyli nie tylko obserwować taki tam bieżący odczyt rzeczywistości, ale też wdrożyć konkretne działania, które długoterminowo będą nas chronić przed tym, żeby w pułapkę tej erozji, o której mówimy dzisiaj z Kubą, nie wpadać.

Kuba: Dobrze, to ostatni rozdział, najbardziej praktyczny. Co zrobić, żeby przezwyciężyć erozję wiedzy i umiejętności?

Jacek: Pierwsza myśl, zaplanuj powtarzalność form szkoleniowych. Mamy tu na myśli zainwestowanie w świadome powtórki, czy to warsztatów, czy innych form rozwojowych, które odświeżają wiedzę. Mając z tyłu głowy takie założenie, że ta wiedza na pewno się będzie zacierać. Z jednej strony to jest kwestia zaplanowania powtórki teoretycznej, czy powtórki pewnej pigułki wiedzy, ale równie dobrze to może być zadbanie o taki praktyczny powrót trenera czy mentora do zespołu po pewnym czasie, po to, żeby spojrzeć na to, czy te elementy, które były omawiane na szkoleniu, czy one faktycznie są wykorzystywane, to po pierwsze, a po drugie, jeśli są wykorzystywane, to czy są wykorzystywane we właściwy sposób.

Kuba: Może się tak zdarzyć, że ta powtórka, o której Jacek wspomniał, musi być albo powinna być zrealizowana z kimś innym, z innym trenerem i przyczyn tego może być wiele, bo może trafił się ten przypadek z naszych założeń, że niestety to szkolenie pierwsze nie do końca było dopasowane i tutaj winisz albo uczestnicy winią trenera i może trzeba go zmienić. A może jest też tak, że już czas na osobę o jakimś innym profilu, na przykład w większym zaawansowaniu albo w większej wiedzy praktycznej, bo zespół też już ma trochę inne potrzeby. Przyczyn zmiany może być wiele, ale warto to rozważyć, warto to tutaj bardzo świadomie zrealizować. A nawet jeśli nie jest żaden przypadek negatywny, to warto po prostu czerpać wodę z różnych studni. Ja sam sobie cenię to, że na szkoleniach na przykład scrumowych, to chyba byłem pięciu. Każdy było trochę inne, każdy było w różnym stylu, każdy było w jakimś sensie powiązane też z jakimś tam profilem doświadczenia i też temperamentu osoby prowadzącej. No i to było super, dało mi lepsze zrozumienie w wielostronną perspektywę i myślę, że tu też można zadbać. Po prostu od tej strony nawet jeśli trener pierwszy był dobry albo świetny, to dlaczego nie spróbować kogoś, kto rzuci nowe światło na sprawę, może dotrze trochę inaczej, może pokaże jakieś inne przykłady z innych firm niż te pierwszego trenera, to ostatecznie buduje bardzo fajny fundament i ciekawą wiedzę.

Jacek: Swoją drogą, pewnym sposobem na odświeżenie i uporządkowanie wiedzy mogą być nasze webinary. Znajdziesz je pod adresem porzadnyagile.pl/sklep.

Kuba: Druga porada, co zrobić, żeby przezwyciężyć erozję wiedzy, to dopasuj zakres szkoleń pod twoje faktyczne potrzeby. Przyjmuję w tej poradzie założenie, że może już wiesz co nieco więcej i też twój zespół umie precyzyjnie określić swoje potrzeby, bo już przeszedł w ten sposób jakąś podstawę, być może trochę popraktykowali i teraz może się okazać, że takie szablonowe, katalogowe szkolenia, jakieś takie powtarzalne, to już nie jest to, czego potrzebuje twój zespół, to nie jest to, czego potrzebuje twój obszar. Więc warto bardzo asertywnie, bardzo mocno podejść do precyzyjnego podania tego, co jest bolączką, potrzebą szkoleniową, i tak poprowadzić rozmowę z osobą, która takie szkolenie ewentualnie będzie realizować, albo szykuje się do jej realizacji, żeby to naprawdę było dopasowane do tego, czego potrzebujesz.

Jacek: Bazując na tym, co przed chwilą powiedział Kuba, przykładowo, jeżeli zespół ma zdiagnozowany problem z dzieleniem na mniejsze kawałki, warto zadbać o to, żeby to uzupełniające szkolenie było skupione na tym aspekcie i żeby zespół pracował faktycznie na swoich przykładach, a nie jakichś wyidealizowanych, generycznych, po to, żeby lepiej zrozumieć i zobaczyć na przykładzie własnego podwórka, może pewne koncepcje są możliwe do wykonania.

Jacek: Trzecia wskazówka. Obejmuj programem szkoleniowym nowozatrudnionych. Bardzo łatwo wpaść w pułapkę, w której zapominamy o tym, że nowe osoby, które dołączają do organizacji, też potrzebują konkretnych szkoleń, wyrównania wiedzy, nabycia jakichś konkretnych umiejętności. Warto więc dokonać refleksji, czy mają okazję do takich szkoleń wyrównawczych i czy to jest systemowo zaopiekowane na takiej zasadzie, że na przykład regularnie co pół roku sprawdzamy listę osób, które dołączyły do organizacji i patrzymy na to, jakie szkolenia się odbyły, które szkolenia są brakujące, w jaki sposób możemy te grupy stworzyć po to, żeby nikt w organizacji nie został z takim poczuciem, że jakiegoś tam konkretnego szkolenia nie dostał czy nie miał szans w nim uczestniczyć.

Kuba: I sam realizowałem takie programy właśnie wyrównawcze, zarówno jako osoba, która opiekowała to, żeby właśnie wszyscy zatrudnieni przez coś takiego przeszli, tak i też jako wewnętrzny trener po prostu realizowałem takie grupy trochę mieszane, bo oczywiście pochodzące ze świeżo zatrudnionych osób z bardzo różnych części firmy. W dużej firmie pewnie to trochę prościej rozwiązać, bo po prostu na tyle dużo jest nowozatrudnionych, że co jakiś czas po prostu zbierze się grupa. Pewnie większym wyzwaniem jest to, że mam dokładnie tylko jednego nowego programistę przez ostatni rok, no i tu być może nie ma jak zrobić zamkniętej grupy i trzeba poszukać jakichś alternatyw, no ale w niektórych kwestiach da się zorganizować też szkolenia, czy w zasadzie dołączyć do szkoleń otwartych, gdzie jakieś grupy są zebrane z różnych organizacji. To ma swoją oddzielną, fajną zaletę. No ale kluczem jest to, żeby właśnie przede wszystkim nie mieć tego tunelowego widzenia, że przecież przeszkodliliśmy wszystkich, tak, wszystkich, ale którzy byli zatrudnieni w marcu 2023, od tego czasu mamy pięć nowych osób, które już przeszkolone nie były.

Kuba: Czwarta porada, wspieraj zmiany w firmie i osoby, które są za to odpowiedzialne. Jedną z przyczyn erozji może być niewystarczający nacisk na to, żeby wprowadzać nowe praktyki, żeby przezwyciężać jakieś trudności w ich stosowaniu, czy też niewystarczająco wspierać osoby, które za daną, konkretną praktykę to są bardziej odpowiedzialne. Te bardziej odpowiedzialne osoby to może być jakiś Product Owner, to może być Agile Coach, może Scrum Master, może User Experience Designer, może jeden z liderów technicznych. Być może dla danej praktyki jest ktoś konkretnie wskazany, kto jest jednocześnie może trochę mentorem, trochę liderem zmiany, trochę osobą, która trochę, tak nazwijmy, to pilnuje, oczywiście potocznie to nazywam, pilnuje tego, żeby zmiana się działa. No i w dwóch różnych firmach to może wyglądać zupełnie inaczej. W jednej firmie management wspiera mocno zmianę i te osoby, które tą zmianę faktycznie pilotują tak praktycznie i na co dzień mają duże wsparcie, duże poparcie i w razie problemów dostają odpowiednią reakcję ze strony managementu. W innych firmach takie osoby są bardzo osamotnione, w zasadzie są duże oczekiwania, niewiele się dzieje, żeby tym osobom się udało. W tej poradzie daję taki punkt do refleksji, na ile z perspektywy managerskiej czy liderskiej w obszarze wspierasz to, żeby te nowe praktyki, nowe podejścia, nowe rozwiązania są stosowane i są wspierane w dalszej zmianie.

Jacek: I przykład z życia pracowałem nad programem rozwojowym dla pewnej organizacji, gdzie wszystkie osoby na poziomie liderskim przechodziły takie podstawowe szkolenie i warsztaty z tego, jak się regularnie usprawniać. Natomiast wyłoniła się grupa uczestników, których zadaniem miało być takie aktywne propagowanie tej wiedzy w organizacji i te osoby dostały dodatkowe sloty, dodatkową porcję wiedzy, takie dedykowane warsztaty, gdzie na takim jeszcze głębszym poziomie mogły z nimi przepracować koncepcje, które w praktyce będą im potrzebne, jeśli mają być tymi osobami, które za to, żeby ciągłe usprawnianie w organizacji miało miejsce, żeby te osoby mogły czuć się odpowiedzialne.

Jacek: Przedostatnia porada. Zapewnij czas na propagowanie najlepszych praktyk. Sporo z Kubą mówiliśmy o takich dużych formach, warsztaty, szkolenia, programy, natomiast jest cała masa możliwości trochę mniejszego kalibru, która nadal może być wartościowa. Wszelkiego rodzaju gildie czy spotkania, których celem jest wymienianie wiedzy. Minikonferencje, podczas których omawiane są najbardziej istotne tematy, dzielenie się doświadczeniami czy nawet takie prozaiczne rzeczy, jak stworzenie czasu, w którym zespoły mogą eksperymentować z nowo nabytą wiedzą, są świetnym uzupełnieniem tych takich klasycznych form rozwojowych. Warto dokonać refleksji, czy w ogóle z takiej puli rozwiązań w organizacji korzystamy, a jeśli nie, to zachęcam do tego, żebyś spojrzał czy spojrzała na tę listę i zastanowił się, czy zastanowiła, z czym moglibyśmy pójść dalej, co można byłoby spróbować jako taki dodatkowy suplement zapewniający, że te najistotniejsze praktyki będą w organizacji się propagować.

Kuba: Tutaj przyczyna, żeby zastosować takie formaty jest podwójna. Z jednej strony dzięki wymienianiu najlepszych praktyk pomiędzy zespołami jest szansa, że ta erozja będzie następować powoli, jeśli w ogóle, a jest może nawet szansa na bardzo pozytywny efekt takiego wspierania się wzajemnie, inspirowania ewolucji we właściwą stronę. Czyli to nawet nie będzie ratowanie tego zjawiska zapominania, a wręcz nawet nakręcanie się wzajemne w tym, żeby działać jeszcze lepiej. A z drugiej strony na sprawę patrząc, takie danie mocnego wsparcia czy mocnego akcentu na to, żeby tę wiedzę propagować, uruchamia te mechanizmy uczenia się poprzez uczenie innych. Czyli najlepsi eksperci czy osoby, które mają jakieś fajne, unikalne doświadczenie, poproszone o to, żeby wystąpiły na minii konferencji i o tym opowiedziały, nie tylko po prostu inspirują innych, ale same sobie tę wiedzę lepiej porządkują, być może ćwiczą się w tym, jak tę wiedzę dobrze przekazywać kolejnym osobom. Więc tutaj jest takie trochę combo, że raz, że po prostu wprost ta wiedza przepływa, ale oprócz tego ci najlepsi, którzy zgodzą się czy odważą się dzielić tą wiedzą, sami ją sobie po prostu trochę lepiej porządkują i uczą się tego, jak tę wiedzę propagować dalej.

Kuba: I ostatnia porada, nieustannie monitoruj proces i satysfakcję interesariuszy. Można było sobie pomyśleć w naszym poprzednim rozdziale, że tak zachęcamy do takiej głębokiej analizy procesów wielowymiarowej i może część z naszych słuchaczy sobie pomyślała, no ale jak to jednorazowo zrobić, jak ja to robię ciągle. Jeśli robisz to ciągle, no to super. Natomiast no mamy przekonanie, że nie wszyscy robią to w takim trybie ciągłym czy nieustannym, więc tutaj taka oddzielna porada, przyglądaj się swojemu procesowi, który masz pod opieką, czy procesowi, którego jesteś częścią i wracaj do odpowiednich miar, sprawdzaj ich wyniki, sprawdzaj trendy, które się dzieją, wykonuj te wszystkie badania i rozmowy, do których zachęcaliśmy. W najgorszym razie po to, żeby jak najwcześniej wyłapać jakieś niepokojące objawy, jakieś wczesne sygnały ostrzegawcze, no ale tak ogólnie mówiąc to oczywiście to też dobra praktyka managerska, żeby mieć taką zdroworozumianą kontrolę nad tym, co się dzieje, gdzie pewne rzeczy idą i gdzie trzeba uważniej się przyjrzeć sprawom, żeby je korygować, czy wspierać ich usprawnienie.

Jacek: Podsumowując, co zrobić, żeby przezwyciężyć erozję wiedzy i umiejętności? 

Kuba: Zaplanuj powtarzalność form szkoleniowych. Dopasuj zakres szkoleń pod Twoje faktyczne potrzeby. Obejmuj programem szkoleniowym nowozatrudnionych.

Jacek: Wspieraj zmianę w filmie i osoby, które są za to odpowiedzialne. Zapewnij czas na propagowanie najlepszych praktyk oraz nieustannie monitoruj proces i satysfakcję interesariuszy.

Kuba: Dobraliśmy temat tego nagrania nieprzypadkowo, bo widzimy coraz więcej firm w sytuacji opisanej w tym odcinku. Dlatego proponujemy ze swojej strony coś prostego, co robi różnicę praktyki poprawy efektywności zespołu. Jest to szkolenie przez nas zorganizowane, wymyślone i poprowadzone. Ale nie jest to szkolenie od zera. Zakładamy, że jakaś podstawa praktyki i wiedzy jest już wśród uczestników. Skupiamy się na realnych problemach danego zespołu i sposobach ich usprawniania. Propozycję tego szkolenia znajdziesz na stronie 202procent.pl/oferta. Zamieszczamy też link do konkretnej strony opisującej cały ten materiał w opisie odcinka.

Jacek: Natomiast notatki do tego odcinka, artykuł, transkrypcję oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/136

Kuba: I to by było wszystko na dzisiaj. Dzięki Jacek. 

Jacek: Dzięki Kuba. I do usłyszenia wkrótce.

________

To była pełna transkrypcja odcinka podcastu Porządny Agile. Dziękujemy za lekturę!

Ostatnia aktualizacja: 13 stycznia 2026

Jakie miary warto śledzić, żeby naprawdę usprawniać proces wytwarzania produktu? Poznaj nasz zestaw sześciu rekomendowanych miar procesu dostarczania od Time To Market po Delivery Predictability. Wyjaśniamy jak wprowadzać je mądrze i  dlaczego ich mierzenie jest szansą na rozwój i lepszą współpracę w zespole. Jak zawsze wplatamy przykłady z życia i historie zawodowe, by lepiej przedstawić temat.

Spis treści

• Dlaczego mierzenie procesu jest ważne?
• Sześć rekomendowanych miar procesu dostarczania
• Jak wykorzystać miary procesu dostarczania w praktyce?
• Rekomendowane miary dostarczania produktu – podsumowanie
• FAQ: Rekomendowane miary dostarczania produktu
• 📄Transkrypcja podcastu „Rekomendowane miary dostarczania produktu”

Mierzenie procesu pozwala lepiej zrozumieć jego kondycję. Opinie, odczucia i wyobrażenia są z natury subiektywne. W tym artykule chcemy zwrócić uwagę na to, by opierać się na możliwie konkretnych i obiektywnych danych.

Mierzenie procesu umożliwia również lepsze planowanie, prognozowanie i zwiększa przewidywalność pracy zespołu. W zależności od roli w zespole można samodzielnie planować, wspólnie prognozować działania lub pracować w strukturze, w której zespoły bazują na faktach i konkretnych danych. Takie plany da się zweryfikować, sprawdzają się co najmniej w większym przybliżeniu. Choć zawsze istnieje pewien margines nieprzewidywalności, to pomierzony proces z zasady cechuje się większą przewidywalnością niż opieranie się na subiektywnych opiniach czy przeczuciach.

Mierzenie procesu umożliwia też weryfikację tempa realizacji strategii produktowej. W większości organizacji istnieją pewne plany, które powinny zostać zrealizowane. Znajomość rzeczywistego przebiegu procesu pozwala zestawić te dane z aspiracjami firmy. Pozwoli też ocenić, czy przy obecnej kondycji procesu oczekiwania dotyczące efektów za miesiąc czy trzy miesiące są w ogóle realne.

Mierzenie procesu wspiera budowanie zaufania u interesariuszy i klientów. Jeśli wcześniejsze plany są realizowane, a informacje o procesie, jego przebiegu, typowych stanach czy statystykach, są transparentnie komunikowane, wzmacnia to wiarygodność zespołu. Interesariusze i klienci, niezależnie od tego, kim są, zyskują zrozumienie, możliwość przewidywania i poczucie, że można Wam zaufać.

I ostatni argument, którym chcemy się podzielić: miary mogą stanowić punkt odniesienia dla usprawnień procesu w zespole. Część zespołów opiera się na intuicji, rozmawia o możliwych usprawnieniach, ale nie dochodzi do konkretów. Zachęcamy, aby w takich rozmowach pojawiały się twarde dane: konkretne liczby, połączone z oczekiwaniami co do pożądanego stanu. Dzięki temu zespół może opierać refleksję na rzeczywistych, empirycznych informacjach płynących z procesu.

Time To Market to czas realizacji inicjatywy od momentu pojawienia się pomysłu do chwili, gdy rozwiązanie jest skutecznie wykorzystywane przez klienta końcowego. Liczenie rozpoczyna się w chwili narodzin koncepcji, niezależnie od tego, czy pojawiła się w głowie konkretnej osoby, czy w wyniku pracy większej grupy. Kończy się, gdy przekształcona w funkcję produktową idea zostaje realnie użyta przez użytkownika.

Najczęściej stosowaną metodą liczenia Time To Market jest średnia krocząca z ostatnich X inicjatyw. Liczba X może wynosić np. 10, ale w przypadku dużych organizacji lub bardzo małych inicjatyw może być znacznie większa. Alternatywnie można obliczyć średnią z określonego okresu np. kwartału, półrocza lub całego roku. Stosowanie średniej kroczącej lub średniej okresowej pozwala zauważyć zmiany w czasie. Zarówno te pozytywne (przyspieszenie realizacji), jak i negatywne, np. spowolnienie procesu. Gdyby natomiast liczyć średnią ze wszystkich inicjatyw od początku istnienia organizacji, zmiany te byłyby niewidoczne. Rozmyłyby się w danych i dawały jedynie nieznaczne wahania „po przecinku”.

Będziemy posługiwać się w całym niniejszym materiale analogią wizyty w restauracji. W przypadku Time To Market odpowiada on czasowi od momentu wejścia do restauracji do chwili, gdy klient zje pierwszy kęs zamówionego posiłku. Innymi słowy, od chwili, w której decyduje, że chce coś zjeść w konkretnej restauracji, do momentu, gdy faktycznie otrzymuje i może skosztować zamówione danie.

Powyższy przykład ma szczególne znaczenie, może być nawet powodem akademickiej dyskusji. Od kiedy właściwie powinno się liczyć Time To Market? Od wejścia do restauracji? A może od zamówienia? Świadomie chcemy zasygnalizować tę potencjalną kontrowersję, bo w praktyce mierzenie Time To Market często budzi wątpliwości. Jednym z kluczowych wyzwań jest precyzyjne określenie momentu rozpoczęcia liczenia. Od kiedy uznaje się, że inicjatywa faktycznie się rozpoczęła?

Choć hasło Time To Market jest szeroko wykorzystywane, a wiele firm deklaruje, że je mierzy, jego praktyczna aplikacja bywa problematyczna. Często zdarza się, że moment pojawienia się pomysłu nie jest nigdzie formalnie zarejestrowany. Nie trafił jeszcze do żadnego systemu ani narzędzia. Dodatkowo niektóre zespoły czy organizacje uznają, że liczenie od zbyt wczesnego etapu np. od momentu, gdy pomysł pojawia się w głowie produktowca czy stratega, jest niesprawiedliwe. Dlatego nie chcemy wskazywać jednej właściwej definicji. Warto natomiast być świadomym, że ta popularna miara niesie ze sobą spore kontrowersje. Jej interpretacja ma kluczowe znaczenie dla sposobu, w jaki analizujesz skuteczność działań swojego procesu.

Na pierwszy rzut oka może wydawać się podobna do Time To Market, jednak między nimi istnieją istotne różnice. Lead Time najczęściej definiuje się jako czas realizacji inicjatywy: od jej formalnego zgłoszenia do momentu wdrożenia. Przez inicjatywę rozumiemy tu większą całość. W klasycznym ujęciu może to być projekt. W środowisku produktowym będzie to pomysł lub okazja biznesowa, często obejmująca zestaw funkcji czy zmian. Miarę tę liczymy od chwili, gdy inicjatywa zostaje uchwycona (zapisana / nazwana /zarejestrowana), aż do momentu, gdy zostaje udostępniona użytkownikom.

Także w przypadku Lead Time mogą pojawić się kontrowersje,  szczególnie w kwestii tego, co dokładnie oznacza „zgłoszenie” inicjatywy. Czy chodzi o zapisanie pomysłu w ogólnodostępnym repozytorium, czy o formalne przekazanie go do konkretnego zespołu? Różne organizacje mogą przyjąć odmienne podejścia, dlatego kluczowe jest jednoznaczne zdefiniowanie tego momentu.

Najczęściej stosuje się średnią kroczącą z ostatnich kilku lub kilkunastu inicjatyw. Ich liczba i rozmiar zależą od specyfiki organizacji. Alternatywnie, można użyć średniej z wszystkich inicjatyw zakończonych w danym okresie, czy w kwartale. Niezależnie od przyjętej metody, świadomie dobierz analizowany przedział czasowy i upewnij się, że dane wykorzystywane do pomiaru są rzetelne. Jakość danych jest wprost zależna od dyscypliny osób korzystających z narzędzi zespołowych. A to przekłada się na wiarygodność wniosków, które można wyciągnąć na podstawie tej miary.

W porównaniu z Time To Market – gdzie czas często zaczyna być liczony jeszcze na etapie nieuchwytnego, luźnego pomysłu – Lead Time bazuje zazwyczaj na danych dostępnych w narzędziach zespołu. Czyni to Lead Time miarą łatwiejszą do uporządkowania i bardziej jednoznaczną.

Przenieśmy Lead Time na zastosowaną już wyżej analogię restauracyjną. Jego pomiar rozpoczyna się w momencie złożenia zamówienia kelnerowi lub kelnerce, a kończy w chwili, gdy danie zostaje wydane z kuchni. To zakres węższy niż w Time To Market. Ale nadal w wielu restauracjach może zająć trochę czasu. Zawiera w sobie czasy choćby przekazania zamówienia do kuchni albo ewentualne przestoje pomiędzy przekazaniem zamówienia a faktycznym rozpoczęciem przygotowania posiłków.

Cycle Time to czas realizacji inicjatywy liczony od faktycznego rozpoczęcia prac wytwórczych do ich zakończenia. W tym przypadku nie bierze się pod uwagę momentu zgłoszenia inicjatywy ani okresu oczekiwania. Do pomiaru interesujący jest wyłącznie czas przetwarzania, czyli moment rozpoczęcia konkretnych działań mających na celu stworzenie produktu lub funkcji, aż do chwili zakończenia tych działań i przekazania efektu do wdrożenia.

W przypadku Cycle Time wyraźnie widać zawężenie zakresu. Obejmuje on przesunięcie zadania do stanu „in progress”, czyli faktyczne rozpoczęcie pracy przez zespół, aż do zakończenia tego zadania po jego stronie. Poza tym etapem mogą występować dalsze czynności, np. weryfikacja lub wdrożenie, które nie są objęte tą miarą.

Najczęściej obliczany jest jako średnia krocząca z ostatnich kilku-kilkunastu inicjatyw lub średnia z inicjatyw zakończonych w danym okresie (np. kwartał, półrocze, rok).

Cycle Time to czas od rozpoczęcia realizacji zamówienia np. obierania ziemniaków czy smażenia kotleta, aż do momentu, gdy kuchnia uzna danie za gotowe i przekaże do wydania. Innymi słowy Cycle Time do czas faktycznego procesu przygotowania posiłku.

Flow Efficiency (pol. Wydajność albo Sprawność Procesu) to procentowy udział czasu aktywnej pracy nad inicjatywą w całkowitym czasie jej realizacji. Wzór jest prosty: suma czasu aktywnej pracy dzielona przez Lead Time i pomnożona przez 100%. W tej mierze sprawdza się jaką część całego procesu stanowiła realna praca. Odwrotnością tej miary jest procent okresów nieaktywnych: jaki procent całego Lead Time to były przestoje, oczekiwania, blokady decyzyjne czy świadome wstrzymanie działań.

W przeciwieństwie do wyżej wymienionych miar, Flow Efficiency jest rzadziej stosowana i rzadziej uwzględniana w standardowych raportach narzędziowych. Mimo to warto rozważyć jej zastosowanie, ponieważ wnosi istotny wgląd w rzeczywistą efektywność pracy.

Największym wyzwaniem przy mierzeniu Flow Efficiency jest rzetelne oszacowanie czasu aktywnej realizacji. Odpowiedzialność za to leży po stronie osób wykonujących pracę. Ważne by dane rejestrowane w narzędziach śledzących postęp oraz czas poświęcony na zadania możliwie wiernie odzwierciedlały rzeczywistość. Choć dopuszczalne jest pewne przybliżenie, to i tak, bazując na naszym doświadczeniu, zakładamy, że w przeciętnej firmie Flow Efficiency bywa niepokojąco niskie.

Przykład restauracyjny ilustrujący Flow Efficiency: klient czeka na posiłek 30 minut – więc tyle wynosi Lead Time dla tego przypadku. Z tego czasu kucharz faktycznie poświęcił na przygotowanie dania 15 minut, a pozostałe 15 minut spędził, np. przeglądając shorts’y na YouTube Porządnego Agile’a. Oznacza to, że Flow Efficiency wynosi 50%, ponieważ tylko połowa całkowitego czasu oczekiwania była aktywnie wykorzystana na pracę nad zamówieniem.

Nie dziwi nas zbytnio, że kucharz nie mógł się oprzeć 😉 . W realiach produktów cyfrowych elementy obniżające efektywność przepływu to wszelkiego rodzaju przestoje. Mogą to być awarie, niedostępność narzędzi lub środowisk, rozpraszające spotkania czy czas oczekiwania na przekazanie informacji lub części pracy pomiędzy specjalistami.

Deployment Frequency to częstotliwość wdrożeń. Mierzy się ją, zliczając wdrożenia na środowiska produkcyjne (czyli te, z których korzysta użytkownik końcowy) w określonej jednostce czasu.

Warto zauważyć, że częste wdrożenia zazwyczaj idą w parze z krótszym Time To Market lub Lead Time’em. Częste wdrożenia umożliwiają więcej iteracji i większą liczbę eksperymentów oraz częstsze doskonalenie produktu.

Co ciekawe, raport DORA wskazuje też, że częste wdrożenia często korelują z wyższą ogólną jakością produktu. Można więc wysnuć wniosek, że im częściej organizacja wdraża zmiany, tym większe prawdopodobieństwo, że jakość dostarczanego klientowi produktu będzie wyższa.

Przykład częstotliwości wdrożeń w restauracji może być mniej intuicyjny, ale wyobraźmy sobie następującą sytuację: na zmianie pracuje tylko jeden kelner, który obsługuje całą salę. W praktyce oznacza to, że co 5 minut jest w stanie dostarczyć do stolika jeden posiłek. Poza tym przyjmuje zamówienia, obsługuje płatności i odpowiada na pytania gości. Finalnie częstotliwość serwowania potraw ma bezpośrednie przełożenie na ocenę obsługi i satysfakcję klientów.

W przypadku produktów cyfrowych częstotliwość wdrożeń jest ściśle powiązana ze sprawnością procesu wdrożeniowego. Niektóre organizacje, zwłaszcza bardziej zaawansowane, wdrożenia przekazują zespołom produktowym lub zespołom funkcjonalnym. W innych nadal funkcjonują odrębne jednostki, np. zespoły DevOps, które przejmują odpowiedzialność za ten etap.

Kluczowy wpływ na częstotliwość wdrożeń ma stopień automatyzacji procesu. Im większa automatyzacja i mniejsze zaangażowanie czynnika ludzkiego, tym większa szansa na częste i szybkie dostarczanie mniejszych zmian. Istotne są również narzędzia klasy CI/CD, które wspierają ten proces. Warto też zwrócić uwagę na architekturę samego produktu. Jeśli podzielono go na mniejsze komponenty lub paczki wdrożeniowe, ułatwia to częstsze i bezpieczniejsze wdrażanie. Operowanie dużymi blokami zmian znacznie ogranicza tę elastyczność.

Delivery Predictability określa procent dostarczonych funkcji (lub elementów Backlogu Produktu) na koniec konkretnego odcinka czasu (najczęściej iteracji lub Sprintu), w stosunku do liczby elementów zaplanowanych na jego początku. Najczęściej dane są uśredniane, analizuje się wyniki z pojedynczych Sprintów lub z dłuższego okresu, np. kwartału. Pojedynczy słabszy Sprint może czasem wywołać spore poruszenie przy analizie tej miary. Z tego powodu obserwuje się trend, który buduje się w czasie i stanowi dla zespołu punkt wyjścia do działań usprawniających.

W Przewidywalności Dostarczania uzyskaną konkretną liczbę traktuj jako oczekiwany zakres, pewien przedział który jest pożądany. Zarówno jego wyraźny nieuzyskanie jak i trwałe przekraczanie traktować jako sytuację budzącą pytania. Proponowany przez nas zakres to zazwyczaj od 80% do 120%. Celem nie jest idealne trafienie w 100%, lecz osiągnięcie poziomu przewidywalności wystarczającego zarówno z perspektywy interesariuszy, jak i zespołu. Chodzi o to, na ile można polegać na zdolnościach planistycznych zespołu.

Zaznaczamy też, że jest to dosyć kontrowersyjna miara, często budząca wiele emocji, zarówno u praktyków technik zarządzania jak i w samych zespołach.

Załóżmy, że klient w restauracji przy składaniu zamówienia pyta obsługę, w jakim czasie otrzyma posiłek. Nie jest to sytuacja abstrakcyjna. Zdarza się, że goście pytają o to, np. mając ograniczony czas podczas przerwy w pracy i chcąc szybko zjeść. Załóżmy, że klient otrzymał informację, iż posiłek zostanie podany w 15 minut. Kuchnia nie była przeciążona, a proces wydawał się sprawny. Ostatecznie jednak danie dotarło dopiero po 30 minutach. Klient został wprawdzie przeproszony i otrzymał wyjaśnienie, jednak wcześniejsza deklaracja czasowa nie została dotrzymana.

W przypadku kuchni przewidywalność można byłoby zmierzyć poprzez zestawienie wszystkich wydanych posiłków z wcześniejszymi deklaracjami czasowymi. Miarą będzie sprawdzenie, w ilu przypadkach zostały one dotrzymane. Zakładamy przy tym, że czas jest istotnym czynnikiem, zarówno dla klienta, któremu zależy na terminowej obsłudze, jak i dla restauracji, w której opóźnienia mogą prowadzić do spiętrzenia zamówień.

Pomysłów na miary jest wiele więcej, niż wymieniamy w tym materiale. Najprawdopodobniej nie dasz rady wykorzystać wszystkich jednocześnie. Warto więc świadomie określić, po co chcesz mierzyć proces. Zastanów się, które z pięciu powodów, o których piszemy na początku artykułu, są dla Ciebie najistotniejsze. Na tej podstawie dobierz konkretne miary. Takie podejście ułatwi nie tylko przemyślenie własnych priorytetów w obszarze mierzenia procesów, lecz także pomoże w późniejszej komunikacji z zespołami.

Przykład z życia: w jednej z firm typu software house mierzyliśmy się z problemem zaufania klienta oraz z częstotliwością dostarczania wysokiej jakości produktu. W tych okolicznościach zdecydowaliśmy się śledzić dwie miary:

Przykład przedstawia sytuację, w której decyzja o mierzeniu procesów ma racjonalne podstawy. W praktyce jednak wprowadzenie mierzenia, szczególnie w organizacji, która wcześniej tego nie robiła, może zostać odebrane jako działanie kontrowersyjne. Może budzić skojarzenia z kontrolą, brakiem zaufania czy próbą rozliczania ludzi z błędów. Właśnie dlatego tak ważne jest, by jasno określić cel wdrażanych miar i sposób ich wykorzystywania w organizacji. To element komunikacji towarzyszącej zmianie, którą najprawdopodobniej planujesz wprowadzić w firmie lub jej części.

Wprowadzenie mierzenia procesu do organizacji często budzi kontrowersje. Dlatego należy precyzyjnie określić, co będzie mierzone, w jaki sposób, skąd będą pochodziły dane, jak będą przetwarzane oraz prezentowane. Każdy powinien mieć jasność, czego dotyczą miary. Szczególnie wrażliwe mogą być wskaźniki związane z czasem. W wielu firmach pracownicy zobowiązani są do logowania czasu pracy. Oczekuje się też, że są aktualizowane statusy poszczególnych elementów czy zadań składających się na tworzony produkt. Jakość zbieranych danych będzie bezpośrednio wpływać na wiarygodność uzyskanych wyników. Dlatego warto poświęcić uwagę na dokładne określenie i wspólne zrozumienie zasad pomiaru.

W przypadku miar związanych z czasem szczególnie istotne jest jednoznaczne określenie momentu rozpoczęcia i zakończenia pomiaru. Bez precyzyjnych ustaleń, kiedy stoper zaczyna i kończy odliczanie, istnieje ryzyko, że różne zespoły będą interpretować to na własny sposób. Może to podważyć wiarygodność całego procesu mierzenia i opierania decyzji na danych. Aby temu zapobiec, warto ustalić jasne zasady obowiązujące w całej organizacji. Dobrym rozwiązaniem jest również maksymalne zautomatyzowanie pomiaru i osadzenie go w narzędziach, eliminując możliwość ręcznej ingerencji. Dane powinny pochodzić bezpośrednio z systemów, bez dodatkowego przetwarzania.

Choć w naszym materiale pojawiło się sześć rekomendacji, uważamy, że nie warto wdrażać zbyt wielu wskaźników naraz. Zdecydowanie lepszym podejściem jest świadomy wybór niewielkiego, ale dobrze dopasowanego zestawu miar, które faktycznie zostaną wdrożone i regularnie stosowane. Ważne jest także, aby te miary były konsekwentnie komunikowane w całej organizacji zarówno przez kadrę zarządzającą, jak i przez Product Ownerów podczas podsumowań Sprintów. Zadbaj o to, by wyniki były na bieżąco przekazywane wszystkim zainteresowanym.

Liczba wybranych miar ma duże znaczenie. Nawet jedna czy dwie wprowadzone miary będą nowością i mogą budzić kontrowersje oraz pytania w organizacji. Zbyt duża liczba miar może natomiast stać się przeszkodą, która utrudni cały proces zmiany. Dlatego tak ważne jest rozsądne wybranie tych aspektów procesu, które w danej firmie mają realne znaczenie i przyniosą największą wartość.

Samo zdefiniowanie mierników to za mało. Konieczne jest zbudowanie systemu, który umożliwi kontrolowanie i bieżące śledzenie aktualnych wartości miar, aby można było podejmować działania korygujące. Warto przemyśleć, jak często zaglądać do tych danych. Codzienne monitorowanie może nie ujawnić trendów. Lepszym rozwiązaniem jest regularność skorelowana z cyklem wytwórczym, np. raz w tygodniu lub co dwa tygodnie. Warto obserwować, czy taka częstotliwość jest wystarczająca i czy pozwala dostrzec istotne sygnały.

W praktyce można to realizować na dwa sposoby. Pierwszym jest wykorzystanie radiatorów informacji. Wielu menedżerów ma ekrany lub zestawy ekranów, na których stale wyświetlane są kluczowe mierniki. Często są to nie tylko miary procesowe, lecz także dane o stabilności działania produktu czy miary biznesowe. Dzięki temu możliwe jest bieżące śledzenie istotnych informacji.

Drugim sposobem, bardziej cyklicznym, jest wykorzystywanie okazji takich jak wizyta zarządzających na Sprint Review, podsumowania miesięczne czy kwartalne. Podczas takich spotkań warto na stałe uwzględnić w agendzie omówienie jednej, dwóch lub trzech najważniejszych miar procesowych. Warto też poprosić o publiczną refleksję nad tym, jak wygląda obecny stan procesu i w jakim kierunku zmierza.

Samo mierzenie to za mało. Załóżmy, że proces jest już pomierzony, dane i statystyki są regularnie weryfikowane, a zespół został o nich poinformowany podczas odpowiednich spotkań. Kluczowe jest jednak to, by zgromadzone dane faktycznie wykorzystać do wprowadzania usprawnień. W tym celu warto, by zespół przy wsparciu lidera opracował konkretny plan działań. Rola lidera polega tu zarówno na inicjowaniu oczekiwania, by taki plan powstał, jak i na wskazaniu wizji, do której warto dążyć.

Jak przy każdej zmianie, wyzwaniem będzie wygospodarowanie czasu na analizę danych pozyskanych z procesu. Nie wystarczy samo wyświetlanie wskaźników na dashboardach. Kluczowe jest, by znaleźć przestrzeń na omówienie tych wyników z zespołem. Jeśli odczyty są niepokojące (albo bardzo optymistyczne),  warto wspólnie zastanowić się, co za nimi stoi. Dzięki temu można wzmacniać pozytywne zachowania wpływające na poprawę procesu lub przygotować działania korygujące, gdy dane wskazują, że sytuacja zmierza w niewłaściwym kierunku.

Unikaj poprawiania wyników „na papierze”. To ważny i często kontrowersyjny aspekt. W zespołach może pojawić się naturalna pokusa, by manipulować wynikami, skoro organizacja oczekuje ich poprawy. Kluczową rolą liderów i managerów jest konsekwentne przypominanie, że nie o to chodzi. Istotne jest posiadanie rzetelnych danych, które pozwolą faktycznie korygować proces. Należy zaakceptować, że początkowe wyniki mogą być dalekie od oczekiwań. Warto też przygotować się na tzw. efekt szoku, czyli uświadomienia sobie, że rzeczywista sytuacja odbiega od wcześniejszych wyobrażeń. Rolą lidera jest wtedy zadbać o to, aby zamiast „pudrowania” wyników, zespoły wzięły odpowiedzialność za rzeczywisty stan procesu i przygotowały działania naprawcze.

W ramach opisanych wcześniej „szoków” mogą pojawiać się pokusy manipulowania danymi, np. wyłączania z analizy inicjatyw, które wypadły gorzej, lub uznawania pewnych inicjatyw za nowe, by zacząć je liczyć od nowa. Warto w takich sytuacjach wykazać się osobistą odwagą i jasno komunikować, że dane powinny pozostać niezmienione, nawet jeśli chwilowo pokazują wyniki mniej korzystne lub niesprawiedliwe. To tylko fakty, które nie świadczą o beznadziejności zespołu, lecz o stanie procesu.

Twoją rolą jako lidera/ki będzie modelowanie właściwych postaw i dawanie przykładu. Zachęcaj do traktowania tych danych jako impulsu do refleksji i wspólnego poszukiwania rozwiązań. Zespoły i cała organizacja powinny skupić się na tym, co można zmienić: w systemie, narzędziach, sposobie pracy czy kulturze organizacyjnej, aby proces faktycznie się poprawiał, a dane odzwierciedlały realny postęp.

To stały element każdej listy naszych rekomendacji. W tym przypadku oznacza świadome i systematyczne przyglądanie się temu, jak zbierane są dane, jak komunikowane są wyniki, jakie kontrowersje to wywołuje oraz czy narzędzia wykorzystywane do mierzenia spełniają swoją rolę. Warto poprosić o informację zwrotną i wspólnie w zespole (lub szerszej grupie) przeanalizować, czy sposób mierzenia procesu i prezentowania wyników faktycznie wspiera usprawnienia.

Należy również ocenić, jak wydajny jest sam proces mierzenia i co można w nim poprawić. Zazwyczaj jest tu sporo przestrzeni do doskonalenia  m.in. eliminacja zbędnego udziału czynnika ludzkiego oraz zwiększenie użyteczności prezentowanych informacji. Dobrze prowadzone mierzenie nie powinno stać się źródłem frustracji ani powodem do porzucenia idei mierzenia. Przeciwnie, mierzenie powinno wspierać rozwój procesów i budować zaufanie do prezentowanych danych.

Nie jest to abstrakcyjna przestroga ani zachęta do bezrefleksyjnego usprawniania wszystkiego, za tą rekomendacją stoją konkretne, realne doświadczenia. W praktyce w każdej organizacji znajdą się osoby, które nie będą zainteresowane zmianą i będą dążyły do utrzymania status quo. To właśnie one jako pierwsze zaczną podważać jakość danych pochodzących z miar.

Często pojawiają się wówczas komentarze w stylu: „to nie ma sensu”, „nic z tego nie wynika”, „tracimy tylko czas”, „od początku mówiłem, że to się nie sprawdzi”. Dlatego właśnie tak ważne jest, aby sposób zbierania danych i zarządzania miarami był solidny i transparentny. Tylko wtedy mogą one faktycznie wspierać poprawę efektywności organizacji i być odpornym na tego typu podważanie.

Mierzenie procesu pozwala na:

Time To Market jest to czas realizacji inicjatywy, mierzony od nazwania pomysłu do skutecznego użycia przez klienta końcowego. W praktyce firmy najczęściej liczą go jako średnią kroczącą z ostatnich kilku inicjatyw albo jako średnią czasów wszystkich zakończonych inicjatyw w danym okresie.

Lead Time jest to czas realizacji inicjatywy mierzony od zgłoszenia inicjatywy do wdrożenia jej efektów. Najczęściej w firmach jest to średnia krocząca z ostatnich x inicjatyw albo średnia z wszystkich czasów inicjatyw skończonych w danym okresie (np. kwartale albo roku).

Cycle Time to czas realizacji inicjatywy od mierzony od faktycznego rozpoczęcia prac wytwórczych do ich zakończenia. W firmach najczęściej obliczany jako średnia krocząca z ostatnich kilku inicjatyw lub jako średnia czasów wszystkich zakończonych inicjatyw w określonym przedziale czasu (np. kwartale albo roku).

Flow Efficiency to procent czasu aktywnej realizacji inicjatywy – podziel czas rzeczywistej aktywnej pracy przez Lead Time danej inicjatywy.

W realiach rozwoju produktu cyfrowego uwidacznia jak wiele czasu zajmują nieefektywności procesu: przestoje dowolnego typu, awarie, niedostępności narzędzi, rozpraszające spotkania czy oczekiwania na przekazanie pracy pomiędzy kolejnymi specjalistami.

Deployment Frequency to liczba wdrożeń na środowiska produkcyjne w danej jednostce czasu (np. w tygodniu, miesiącu bądź kwartale). Częstsze wdrożenia są skorelowane z krótszymi czasami realizacji (Time To Market, Lead Time) oraz wyższą jakością i pozwalają na więcej iteracji i eksperymentowania.

Delivery Predictability to procent zrealizowanych funkcji lub elementów w odniesieniu do pierwotnie zaplanowanej liczby w danej jednostce czasu. Najczęściej miara analizowana jest w ujęciu sprintowym (2 tygodnie) lub kwartalnym. Warto traktować tę miarę jako akceptowalny zakres (np. 80–120%), a nie próbę idealnego trafienia w 100%.

Lead Time to czas od zgłoszenia potrzeby do jej dostarczenia. Cycle Time mierzy tylko czas od rozpoczęcia prac do ich zakończenia. Różnica między tymi miarami może uwidocznić czas spędzony w inicjatywie na oczekiwaniu w kolejce do realizacji oraz ewentualny czas między końcem prac a faktycznym przekazaniem do klienta.

Najlepiej analizuj miary cyklicznie – np. co sprint lub co miesiąc. Ale pamiętaj, że  kluczem jest wychwycenie trendów, a nie paniczne reagowanie na każdą zmianę po pojedynczym słabszym Sprincie.

Na początek wystarczą może tylko dwie, ale kluczowe dla kontekstu twoich zespołów. Mniej znaczy lepiej – łatwiej o zrozumienie, komunikację i działanie. Nadmiar danych spowalnia i może przytłoczyć zarówno członków zespołów, jak i zarządzających. Jak nabierzecie jako firma wprawy, możecie poszerzyć pulę miar o kolejne istotne aspekty.

Tak – jeśli są używane do kontroli i obwiniania zamiast do rozwoju i nauki. Dobre miary wspierają refleksję i decyzje, a nie piętnują błędy. Pokazują też efekty podjętych usprawnień i zachęcają do podejmowania i wspierania kolejnych zmian.

Najlepiej z narzędzi, które zespół już używa – np. Jira, Azure DevOps. Im mniej ręcznego wpisywania, tym lepiej dla wiarygodności wyników i wygody objętych zespołów.

Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu Porządny Agile.

Kuba: Niedawno miałem okazję podzielić się tematem metryk procesowych z pewną grupą produktowców. Byli to Product Managerowie i Product Ownerzy, którzy zebrali się na wewnątrzfirmowym spotkaniu o wymianę wiedzy i takiej wzajemnej inspiracji. Przygotowałem materiał, który porusza właśnie tematy związane z procesem i jego mierzeniem. Materiał na tyle dobry, że nadaje się do przytoczenia jako podstawa treści tego odcinka.

I, zanim Jacek poda spis treści tego odcinka, polecam Twojej uwadze temat możliwości zaproszenia nas na wewnątrzfirmowe konferencje, spotkania inspiracyjne, jakiejś podsumowania etapów transformacji. Robimy takie rzeczy, nie zawsze o tym słychać, nie zawsze też jest to publicznie widoczne, ale można albo nas obu, albo jednego z nas zaprosić i wzmocnić program takiego wydarzenia naszym wystąpieniem na konkretny wskazany przez Ciebie temat.

Jacek: Spis treści tego odcinka. Po pierwsze powiemy, dlaczego mierzenie procesu jest ważne. Następnie podzielimy się sześcioma rekomendowanymi miarami procesu dostarczania i na koniec podsumujemy, jak wykorzystać miary procesu dostarczania w praktyce.

Kuba: Więc zaczynając od początku. Dlaczego mierzenie procesu jest ważne?

Jacek: Po pierwsze mierzenie procesu pozwoli Ci lepiej zrozumieć, w jakiej kondycji ten proces jest. Subiektywne opinie, odczucia, wyobrażenia są bardzo subiektywne, a w tym odcinku chcemy zwrócić Twoją uwagę na to, żebyś operował lub operowała na jak najbardziej konkretnych danych. 

Kuba: Mierzenie procesu pozwala też na lepsze planowanie, prognozowanie i przewidywalność. W zależności od tego, jakie jesteś w funkcji w zespole, możesz albo osobiście planować, albo wspólnie z zespołem prognozować pewne działania, lub w ramach swojej struktury posiadać zespoły, które dobrze planują, prognozują, bazują właśnie na konkretach, na faktach. Można też te plany po prostu sprawdzić, one się sprawdzają jako tako. Oczywiście z pewną dozą dokładności zawsze jakiś rodzaj nieprzewidywalności będzie, ale jednak przewidywalność pomierzonego procesu z zasady powinna być wyższa niż takie właśnie subiektywne opinie, o których wspomniał przed chwilą Jacek.

Jacek: Po trzecie, mierzenie procesu jest ważne, bo pozwoli Ci weryfikować tempo realizacji strategii produktowej. Zwykle w firmie masz jakąś formę planów, które organizacja chciałaby, żeby były zrealizowane. No i świadomość tego, jak faktycznie wygląda Twój proces, pozwala nałożyć niejako tą informację na te aspiracje, które są w firmie zbudowane, no i ocenić czy przy takiej kondycji procesu te wyobrażenia, co będziemy mieć za miesiąc, co będziemy mieć za 3 miesiące, czy one w ogóle są realne.

Kuba: Po czwarte, mierzenie procesu pozwala na budowanie zaufania u interesariuszy i klientów. Jeśli te wspomniane przez nas poprzednie plany są realizowane, jeśli też transparentnie propagujesz informacje na temat tego, jak Twój proces wygląda, jakie ma, powiedzmy, typowe stany czy statystyki, to jest jakiś rodzaj informacji wzbudzającej zaufanie, powodującej, że interesariusze czy też klienci, w zależności od Twojej sytuacji, to mogą być bardzo różne grupy, rozumieją, przewidują, mają poczucie czy wyczucie, że można Wam zaufać.

Jacek: I ostatni argument, który chcemy się podzielić. Miary mogą być punktem odniesienia dla usprawniań procesu w zespole. Są zespoły, które usprawniają swój proces na wyczucie, rozmawiają, co można zrobić lepiej, jak można pewne rzeczy usprawnić, ale nie pojawiają się zatem żadne konkrety. Zdecydowanie tutaj chcielibyśmy Cię zachęcić do tego, żeby zadbać o to, aby podczas rozmów zespołowych o tym, jak jest, żeby w tle faktycznie pojawiały się jakieś konkretne liczby połączone z pewnymi oczekiwaniami, jakbyśmy chcieli, żeby było, no i żeby ta rozmowa po prostu opierała się na twardych, empirycznych danych, które płyną z procesu.

Kuba: Ok, to przejdźmy do drugiego rozdziału. Podamy 6 rekomendowanych miar procesu dostarczania. Na początku mikro spis treści wewnątrz tego rozdziału, żebyś miał lub miała wyczucie, o czym w ogóle dzisiaj będziemy rozmawiać. Zatem, jakie 6 miar procesu dostarczania rekomendujemy? Time To Market, Lead Time, Cycle Time, Flow Efficiency, Deployment Frequency i Delivery predictability. 

Jacek: I w tym rozdziale omówimy po kolei wszystkie te miary. Świadomie zdecydowaliśmy się na angielskie wersje tych miar, dlatego, żeby nie wprowadzać zamieszania. Wynika to z tego, że najczęściej właśnie w oryginale spotykamy te nazwy na co dzień w firmach. Takie nazwy też możecie sobie wyszukać, czy w narzędziach, z których korzystacie do wytwarzania produktów cyfrowych, czy też w internecie. Tak więc pomimo, że nagrywamy po polsku, uznaliśmy z Kubą przed nagraniem, że zachowamy oryginalne nazewnictwo tych miar i w tę formę agieską będziemy dzisiaj zachowywać.

Kuba: Chociaż czasem w niektórych dla wygody i próby niezłamania sobie języków może też użyjemy polskich odpowiedników. Dobrze, to pierwsza bardzo popularna miara, Time To Market.

Jacek: Tak, Time To Market, czyli jest to czas realizacji inicjatywy od nazwania pomysłu, czyli od momentu, kiedy się pojawia, do skutecznego użycia przez klienta końcowego. Czyli pojawia się jakaś koncepcja w głowie, w organizacji i od tego momentu włączamy licznik, natomiast wyłączamy go, gdy faktycznie ta idea w formie już zamienionej w jakąś funkcję produktu jest wykorzystana przez tego naszego klienta końcowego czy użytkownika końcowego.

Kuba: Do każdej z miar, którą proponujemy, opowiemy też, jak dokładnie można je policzyć, jakim wzorem.

No i zaczynając od Time To Market, najczęściej w firmach jest to średnia krocząca z ostatnich X inicjatyw, gdzie X to jest albo liczba typu 10, może to jest o wiele więcej, jeśli firma jest naprawdę duża, albo inicjatywy w tej firmie są na tyle małe, że ma sens to liczyć, w każdym razie bierzemy statystyki z ostatnich iluś inicjatyw i robimy z nich średnią. Czasami jest to też średnia z wszystkich czasów w danym okresie, czyli na przykład średnia z kwartału, albo średnia z ostatniego półrocza czy roku.

Dlaczego średnia krocząca albo średnia z ostatniego okresu, żeby jednak złapać pewną zmianę w czasie, gdyby się okazało, że na przykład przyspieszyliśmy, albo – co gorsza – jednak spowolniliśmy swój proces, coś się zatkało, no to będzie widać tę zmianę. Natomiast gdyby ciągle brać średnią z wszystkich inicjatyw od początku istnienia świata, no to ta zmiana w końcu przestała być w ogóle widoczna, no bo nieznaczne tam po przecinku jakieś liczby by się ujawniały.

Jacek: I chcemy też podawać dla miar takie życiowe przykłady i będziemy się tutaj trzymać takiej koncepcji wizyty w restauracji. W przypadku Time To Market jest to czas liczony od wejścia do restauracji do pierwszego kęsa, czyli zamówionego posiłku, czyli od momentu, kiedy wymyślimy sobie tak naprawdę, że chcemy w konkretnej restauracji coś zjeść, do momentu, kiedy faktycznie doświadczamy tego, co zamówiliśmy od kelnera.

Kuba: I ten przykład jest o tyle ważny i można od razu tutaj rozpocząć akademicką dyskusję z Jackiem, że jak to od wejścia do restauracji, o jak to do pierwszego kęsa. Natomiast tak naprawdę tutaj bardzo świadomie, ewentualną kontrowersję chcieliśmy wywołać, bo tak naprawdę z Time To Market czujemy, że jest właśnie ten kłopot, że bardzo dużo zależy od tego, jak dokładnie definiujemy ten moment rozpoczęcia liczenia czasu Time To Market. Time To Market jest takim dosyć wyświechtanym hasłem.

Wiele firm mówi, że mierzy albo pod tym hasłem wiele transformacji z winnych się kiedyś rozpoczęło lub dzisiaj próbuje się nadal toczyć. Natomiast takie liczenie, po pierwsze może być bardzo trudne, bo być może ten moment wpadnięcia na pomysł, na inicjatywę w ogóle nie ma jeszcze nigdzie odzwierciedlenia w żadnym narzędziu, na przykład, jeśli stosuje się jakieś narzędzia do zgłaszania pomysłów czy inicjatyw.

A po drugie wiele też organizacji czy wiele zespołów uważa, że jest trochę niesprawiedliwe, żeby na przykład bardzo wcześnie zacząć liczyć Time To Market, gdy na zarządzie albo w głowie jakiegoś produktowca czy stratega pojawił się jakiś pomysł i on jeszcze przez jakiś czas dojrzewał. Więc tutaj chyba nie chcemy stawać po żadnej ze stron, natomiast warto zdawać sobie sprawę, że ta chyba jedna z najbardziej popularnych miar ma w sobie bardzo dużo kontrowersji właśnie w tej kwestii, od kiedy liczysz Time To Market.

Jacek: Druga miara, Lead Time. Lead Time jest w pewnym sensie podobną miarą do Time To Market, ale jednak są tutaj pewne różnice. O jakich różnicach tutaj będziemy mówić Kuba?

Kuba: Zazwyczaj Lead Time definiuje się tak, że jest to czas realizacji inicjatywy od jej zgłoszenia do jej wdrożenia. Jako inicjatywę rozumiemy tu w takim klasycznym rozumieniu projekt, w organizacji bardziej produktowej to będzie bardziej jakiś pomysł produktowy czy jakaś okazja, w każdym razie jest jakaś większa całość czy jakiś taki zbiór pewnych funkcji, które są realizowane. No i teraz ten Lead Time to będzie czas od momentu jego zarejestrowania, zapisania, nazwania, jakiegoś takiego złapania aż do wdrożenia, czyli przekazania do użycia.

Jacek: I tutaj też mogą się pojawić kontrowersje. Czym jest to zgłoszenie? Czy to jest zgłoszenie do jakiegoś banku pomysłów? Czy to jest zgłoszenie już do konkretnego zespołu? Różnie mogą sobie to organizacje rozgrywać, natomiast istotne jest, żeby ten moment właściwie uchwycić. Najczęściej, podobnie jak w przypadku Time To Market, jest to średnia krocząca z ostatnich iluś inicjatyw. One mogą być o różnych rozmiarach. Ta liczba może być różna w zależności od organizacji albo średnia za wszystkich czasów inicjatyw skończonych w danym okresie.

No bo na to też warto zwrócić uwagę, że to okienko, na które patrzymy, też musi zostać wybrane w jakiś taki w miarę sensowny sposób. No a już na pewno warto mieć pewność, że te dane, w sensie jakość tych danych, które mamy pozbierane, która jest skorelowana oczywiście z jakąś tam dyscypliną po stronie osób, które pracują na tych naszych narzędziach, jest niezwykle istotna, żeby te informacje płynące z tych miar miały jakieś sensowne znaczenie.

Kuba: I à propos jakości danych, to ten komentarz taki, że w porównaniu do Time To Market, gdzie prawdopodobnie ten stoper zaczyna liczyć czas, gdy ta inicjatywa jest jeszcze bardzo mglista, gdzieś zawieszona w powietrzu jako luźny pomysł, Lead Time już najczęściej jednak w narzędziach widocznych jest i to jest relatywnie łatwiejsze do poukładania.

A przenosząc tę historię Lead Time’u na przykład z restauracji, no to Lead Time w restauracji liczyłbym od momentu złożenia zamówienia, czyli składam zamówienie kelnerowi lub kelnerce, aż do momentu wydania posiłku z kuchni. Jest to już troszkę węższe niż ten Time To Market, ale nadal może to w mniej jednej restauracji chwilę zająć.

Jacek: Zgadza się. Przechodzimy dalej i tutaj jeszcze bardziej będziemy zawężać. Mianowicie będziemy mówić o Cycle Time.

Kuba: Cycle Time to czas realizacji inicjatywy od faktycznego rozpoczęcia prac wytwórczych do ich zakończenia. Czyli tutaj już nie martwimy się, czy ta inicjatywa została zgłoszona, czy ona gdzieś tam czekała, tylko bardzo mocno patrzymy wyłącznie na ten czas, powiedzmy przetwarzania, jeśli się posilę tutaj na jakąś próbę tłumaczenia, czyli faktyczne rozpoczęcie pracy, rozpoczęcie pierwszych czynności związanych z tym, żeby stworzyć produkt albo funkcje związane z tą daną inicjatywą, aż do momentu ich realnego zakończenia i przekazania już do ewentualnego wdrożenia.

Jacek: Tak, tutaj wyraźnie widać to takie wycięcie, czyli bardzo często w zespołach jest to przesunięcie pewnych zadań do stanu in progress, czyli faktyczne rozpoczęcie, wyciągnięcie z tej kolumny, która jest kolumną, z której czerpiemy pracę, do zakończenia, ale właśnie zakończenia po stronie zespołu. Natomiast poza zespołem może występować jeszcze ileś kolejnych etapów, jakaś weryfikacja, jakieś wdrożenie, którego ta konkretna miara nie pokrywa. Podobnie jak w dwóch poprzednich miarach, najczęściej jest to średnia krocząca z ostatnich iluś wybranych inicjatyw, albo średnia ze wszystkich czasów inicjatyw skończonych w danym okresie.

Kuba: No i przykład restauracyjny, Cycle Time w restauracji, to byłoby rozpoczęcie mierzenia czasu w momencie rozpoczęcia realizacji zamówienia klienta, może jakiegoś obierania ziemniaków, albo rozpoczęcia smażenia kotleta do końca jego przygotowania, czyli przygotowania już dania. Kuchnia stwierdza danie gotowe, reszta nas nie interesuje, przestajemy liczyć czas, Cycle Time dla przygotowania posiłku.

Jacek: Kolejna czwarta miara, Flow Efficiency, czyli wydajność procesu. 

Kuba: Ta miara jest już mniej popularna. Trzy poprzednie czasy są po pierwsze bardzo popularne, po drugie też bardzo często łatwo zaszyte w jakichś raportach, w narzędziach. Natomiast zwracamy Twoją uwagę na miary, które warto pomierzyć, nawet te rzadsze. Flow Efficiency to procent czasu aktywnej realizacji inicjatywy. Wzór tutaj jest dosyć prosty, suma czasu aktywnego pracy nad daną inicjatywą dzielona jest przez Lead Time, który już zdefiniowaliśmy wcześniej i mnożona razy 100%.

Czyli jakby, mówiąc tak językiem potocznym, sprawdzamy jaki procent czasu trwania całej inicjatywy, to czas, gdy toczyły się aktywne prace. No i odwrotnością Flow Efficiency będzie też czas zupełnie nieaktywny, czyli czasy jakichś przestojów, oczekiwań, blokad, decyzji o tym, żeby jednak na chwilę zapauzować różne działania.

Jacek: Największym wyzwaniem z tą miarą jest rzetelne policzenie tego czasu aktywnej realizacji. No i tutaj jakby piłka jest po stronie osób wykonujących, żeby w narzędziach, które śledzą najczęściej postęp prac, a jednocześnie też ile czasu zostało na konkretne zadania zalogowane, no tutaj musi to być jak najbliższe rzeczywistości. Oczywiście możemy się zgodzić na jakąś tam przybliżoną dokładność, natomiast niezależnie od tego w ciemno stawiamy z Kubą, że Flow Efficiency w przeciętnej firmie może być niepokojąco niskie.

Kuba: I przykład z restauracji, tutaj już przestajemy liczyć czasy od zamówienia czy jakiegoś przetwarzania, tylko przerzucamy się na to Flow Efficiency. Załóżmy, że klient czeka na swój posiłek 30 minut i to jest Lead Time, natomiast 15 minut z tych 30 minut, czego klient nie widzi, bo nie widzi kuchni, kucharz spędził na przeglądaniu shorts’ów na YouTube Porządnego Agile’a, a nie na realnej pracy, więc danie było przygotowane w faktycznej pracy w 15 minut, a Flow Efficiency w tym przypadku to będzie 50%.

Jacek: Ja się trochę nie dziwię kucharzowi, że się nie mógł oprzeć, natomiast w realiach produktów cyfrowych te rzeczy, które powodują, że flow nie jest tak efektywne, to mogą być wszelkiego rodzaju przestoje, awarie, jakieś okresy niedostępności narzędzi, środowisk, to mogą być rozpraszające spotkania, ale to też może być czas oczekiwania, kiedy przekazujemy sobie informacje czy pewne fragmenty pracy pomiędzy konkretnymi specjalistami.

Kuba: Piąta miara to Deployment Frequency, czyli częstotliwość wdrożeń. Mierzymy to w ten sposób, że sprawdzamy liczbę wdrożeń na środowiska produkcyjne, środowiska klienckie, z których korzysta użytkownik końcowy, w danej jednostce czasu. Coś, co jest też istotne, to to, że często wdrożenia są skorelowane z krótszymi czasami realizacji, czyli tymi albo Time To Market, albo z Lead Time’em, co pozwala na większą liczbę iteracji, eksperymentowania, czy nawet z tej perspektywy, częstego poprawiania produktu.

Jacek: I co jest ciekawe, DORA Report wskazuje na to, że częste wdrożenia bardzo często idą w parze z generalną, lepszą jakością produktu. Czyli możemy z tego wysnuć taki wniosek, że im częściej firma jest w stanie wdrażać, tym najprawdopodobniej też ta jakość produktu dostarczanego do klienta będzie po prostu wyższa. 

Kuba: Z częstotliwością wdrożeń w realiach restauracyjnego przykładu będzie trochę trudniej, więc tutaj wytrzymaj z nami. Wyobraź sobie, że jeden kelner jest na zmianie, więc ma urwanie głowy, bo musi obsłużyć całą salę, więc jest w stanie wydać jeden talerz z posiłkiem na 5 minut. Oprócz tego oczywiście zajmuje się też przyjmowaniem zamówień, obsługą płatności, opieką, sprawdzaniem, załatwianiem jakichś potrzeb informacyjnych klientów, ale fakty są na końcu proste. Jeden posiłek na 5 minut i to nie jest zupełnie niemożliwe.

Dosłownie w weekend byłem w pewnej restauracji, gdzie pomimo tego, że wydawało mi się, że powinno to być przygotowane szybciej, czekałem dosyć długo, bo tak była zorganizowana ta restauracja. Tak po prostu był ułożony system, że szybciej wydawać posiłków się nie dało.

Jacek: Dałeś informację zwrotną?

Kuba: W postaci obniżonego napiwku.

Jacek: W realiach produktu cyfrowego zwykle z tą miarą jest połączona sprawność procesu wdrożeniowego. Różnie to jest czasem w tych bardziej rozwiniętych firmach, jest to coś, za co odpowiadają zespoły produktowe, feature’owe, jakkolwiek je sobie nazwiemy, ale są nadal firmy, gdzie wdrożenie jest przekazywane do jakiegoś konkretnego oddziału, do jakichś tam DevOpsów, gdzieś w każdym razie. I to oczywiście ma wpływ na to, jak często jesteśmy w stanie to zrobić.

Ale wpływ ma też stopień z automatyzowania procesu wdrożeniowego, czyli im większa automatyzacja, im mniej tutaj czynnik ludzki ma znaczenie, tym większa szansa na to, że te wdrożenia mogą być częściej, mogą być robione na mniejszych paczkach, no i jakby cały obszar narzędzi CI-CD też będzie miał na to wpływ.

Taki trochę mniej oczywisty przykład, również to, jak dzielimy produkt, to czy to jest podzielone na mniejsze paczki wdrożeniowe, czy w ogóle dzielimy produkt na mniejsze kawałki, czy operujemy na dużych fragmentach, też będzie miało duży wpływ na to, jak często jesteśmy w stanie wdrażać produkt na produkcję.

Kuba: I ostatnia miara, Delivery predictability, czyli przewidywalność dostarczania. 

Jacek: I to jest taka dosyć kontrowersyjna miara, która potrafi wzbudzać dużo emocji. Nie mniej jest to procent dostarczonych funkcji czy elementów. Na koniec już konkretnego odcinka czasu, bardzo często to jest czy iteracja, czy Sprint, w stosunku do planowanej liczby dostarczonych elementów na początku iteracji, czy na początku Sprintu.

Kuba: Najczęściej jest to jakoś uśredniane, bierzemy dane z pojedynczych Sprintów, patrzymy też być może na perspektywę dłuższego horyzontu, na przykład kwartału, czy było też tak, że pojedynczy Sprint powoduje jakąś aferę. Ten procent dostarczania w pewnym zespole jest pewnego rodzaju trendem czy jakąś taką historią, którą pewien zespół ma i może coś z tym zrobić.

Jacek: I, jeśli chodzi o przewidywalność, to tę konkretną liczbę trzeba raczej traktować jako pewien zakres oczekiwany, czyli jakie przewidywalności mogłabyś, mogłabyś oczekiwać od Twoich zespołów. My z Kubą proponujemy pewien zakres, zwykle między 80 a 120. Nie chodzi o to, żeby trafiać idealnie w 100%, a raczej, żeby ta przewidywalność była wystarczająca z perspektywy interesariuszy, wystarczająca z perspektywy zespołu. Na takiej zasadzie, jak bardzo możemy polegać na naszych zdolnościach planistycznych. 

Kuba: I przykład restauracji, tu już dosyć abstrakcyjny, chociaż może się nadal zdarzyć. Załóżmy, że jestem w restauracji i przy zamawianiu pytam kelnera lub kelnerkę, w jakim czasie dostanę posiłek. To akurat nie jest abstrakcyjne, czasami o to pytam, bo na przykład mam tylko godzinę do odjazdu pociągu i chcę jeszcze coś szybko zjeść, ale jeśli tak jest na styk, to wolę się upewnić.

Załóżmy, że dostałem informację, że posiłek dostanę w 15 minut, bo nie mamy obciążenia, bo tak sprawna jest kuchnia, a jednak posiłek dotarł po 30 minutach. Zostałem bardzo mocno przeproszony i z uśmiechem coś tam zostało mi wyjaśnione, ale tak naprawdę pewna deklaracja czasowa nie została zrealizowana.

No i przewidywalność dostarczania w tej kuchni polegałaby raczej na tym, że zsumowane zostały wszystkie wydane posiłki, złożone obietnice czasowe i sprawdzone te, które zostały zrealizowane. To byłby ten procent skuteczności przewidywania tego, w jakim czasie jest posiłek wydany. Przyjmujemy tu założenie, że ten czas jest istotny, że klientowi zależy na tym czasie i ewentualne opóźnienie jest jednak problemem zarówno dla klienta, jak i też ewentualnego spiętrzenia się zamówień dla restauracji.

Jacek: I, zanim zaczniemy ostatni rozdział, w tym odcinku przypominamy, że jeżeli chcesz pogłębić wiedzę jeszcze bardziej niż robimy to w podcaście, to znajdziesz nasze płatne produkty na stronie porzadnyagile.pl/sklep 

Jacek: Ostatni rozdział. Skupimy się tutaj na pytaniu, jak wykorzystać miary procesu dostarczania w praktyce.

Kuba: Pierwszy punkt, bardzo ważny. Ustal, dlaczego potrzebujesz miar. Wymieniamy 6 miar. Można bez problemu nagenerować jeszcze kolejnych. Najbardziej prawdopodobne jest to, że nie wykorzystasz wszystkich jednocześnie i warto się zastanowić, po co potrzebujesz tych miar. Prawdopodobnie jeden z tych pięciu powodów, które wymieniliśmy na początku odcinka będzie dla Ciebie najistotniejszy. Zastanów się, co jest dla Ciebie ważne i na tej bazie zdecyduj się na konkretny zestaw miar. Ta priorytetyzacja będzie potrzebna do tego, żeby w ogóle przemyśleć sobie same oddzielnie, co tu w ogóle jest dla mnie ważne w temacie mierzenia procesu, ale to też przyda się do komunikacji do zespołów.

Jacek: I przykład z życia. Pracowałem w firmie typu software house. Tam mierzyliśmy się z problemem zaufania klienta i też tego, jak często potrafiliśmy wysokiej jakości produkt oddawać do klienta. Stąd jakby rozumiejąc te okoliczności, zdecydowałem, że będziemy śledzić zarówno przewidywalność, czyli czy jesteśmy w stanie realizować jakieś założone obietnice, prognozy.

Z drugiej strony mieliśmy taką miarę, która się nazywała szczelność procesu testowania i ta miara pokazywała w firmie, jaki procent błędów jest zgłaszany przez klienta. Chcieliśmy, żeby ten procent był dążący do zera, czyli wszystkie błędy chcielibyśmy wyłapywać w ramach procesu testowania wewnętrznego, tak żeby klient tak naprawdę nie miał się już do czego przyczepić.

Kuba: I tak jak słuchasz tego przykładu Jacka, to to jest spokojna historia mająca racjonalne podstawy. Natomiast te doświadczenia nam pokazuje, że wprowadzenie mierzenia, zwłaszcza do organizacji, która do tej pory tego nie realizowała, potrafi być odebrane jako bardzo kontrowersyjne działanie managerskie. Że jest to kontrola, że to jest brak zaufania, że to jest jakieś rozliczanie ludzi, może rozliczanie błędów wykonywanych w ramach działań pracowników czy całych zespołów.

Więc tutaj ta bardzo świadoma decyzja na temat tego, dlaczego chcesz te miary mieć i dlaczego je będziemy wszyscy stosować jako cała organizacja, to jest część komunikacji, która będzie bardzo istotna w ramach zmiany, którą tutaj prawdopodobnie wprowadzasz do firmy czy swojej części firmy.

Jacek: Drugi punkt, zapewnij wspólne zrozumienie definicji miar. Trochę to jest powiązane z tym, co Kuba przed chwilą mówił o tych wszystkich kontrowersjach, które mogą się pojawić wraz z wprowadzaniem mierzenia do organizacji. Istotne jest, żeby dobrze zrozumieć, co tak naprawdę mierzymy, jak to mierzymy, w jaki sposób te miary będą pobierane, w jaki sposób będą obrabiane, jak będą prezentowane, tak żeby była absolutna jasność, z czym się mierzymy.

W szczególności kontrowersyjne mogą być mierniki związane z czasem. Bardzo często w firmach ludzie muszą ten czas pracy logować. Ten aspekt, o którym wspominaliśmy wcześniej, ta jakość danych, którą będziemy mieli, ona będzie determinować w twojej firmie to, czy te miary będą wiarygodne, czy też nie. 

Kuba: Z czasem jest też ta kontrowersja, od której zaczęliśmy w temacie Time to Market. Warto całej organizacji zakomunikować albo z odpowiednimi osobami jednoznacznie ustalić, kiedy ten faktyczny stoper zaczyna liczyć i kiedy przestaje liczyć, bo brak jednoznaczności w tej sferze może spowodować, że różne zespoły albo poszczególne inicjatywy będą miały to robione w sposób nieregularny, co może w zasadzie trochę skompromitować cały kontekst mierzenia i bazowania na faktach i danych, jeśli te dane będą tak niechlujnie zebrane.

Więc najczęściej jednak wiąże się też z takim aspektem, którego nie do końca może lubimy mniej związanym z agile’em, ale jednak zaszyć to wszystko w narzędziach, żeby tu może było jak najmniej interpretacji, jak najmniej okazji do tego, żeby się ktoś mógł tym bawić czy mówiąc potocznie przy tym majstrować. Po prostu suche dane wyciągane prosto z systemu bez żadnej ingerencji ludzkiej.

Kuba: Trzecia porada praktyczna to, wybierz jedną, dwie miary i propaguj zmierzone wyniki do organizacji. Jest to wynik tej porady o priorytetach, choć sami dajemy sześć przykładów, sześć rekomendacji co do miar. Jacek wymienił w przykładzie jeszcze siódmą i moglibyśmy tak iść dalej. Jednak zdecydowanie rekomendujemy, żeby wybrać pewien skończony zestaw miar, może właśnie z pełną premedytacją dwie miary, ale jednak faktycznie zastosowane, wprowadzone w życie, bez odkładania na później i propagowane do organizacji przy nadarzających się okazjach, komunikowane ze strony grona zarządzającego całą organizacją, komunikowane przez Product Ownerów na podsumowaniach Sprintu, regularnie mierzone i komunikowane do tych, którzy potrzebują tej informacji.

Jacek: I ta liczba tutaj podana przez Kubę ma znaczenie, nawet jedna czy dwie miary, one i tak będą kontrowersją, zawsze będą czymś nowym, coś co będzie powodować, że będą się w Twojej organizacji pojawiać pytania, więc jakby przeładowanie miarami, no to może być taka bramka samobójcza, która jeszcze bardziej utrudni cały proces zmiany, więc takie rozsądne wybranie istotnych aspektów procesu, które w Twojej firmie mają znaczenie, jest niezwykle istotne.

Jacek: Kolejna porada, na bieżąco obserwuj odczyty miar na dashboardzie. To, że wiesz już, co chcesz mierzyć, to nie jest wystarczające. Samo zdefiniowanie mierników to może być zbyt mało. Należy zbudować system, który pozwoli nam kontrolować, podglądać aktualny stan tych miar, tak, żebyś mógł podejmować na bieżąco akcje korygujące.

Warto tutaj zastanowić się nad tym, jak często na te miary spoglądać, pewnie takie codzienne patrzenie i odczytywanie może nie pokazać nam trendów, które się z tego wyłaniają, ale jakaś taka regularność skorelowana z cyklem wytwarzania, czyli może raz na tydzień, może raz na dwa tygodnie, to jest coś, od czego bym zaczął. I obserwował, czy taka częstotliwość jest wystarczająca i czy pozwala już nam coś zaobserwować.

Kuba: I w praktyce widzę to realizowane na dwa sposoby. Jeden ze sposobów jest wykorzystanie radiatorów informacji, więc wielu zarządzających w wielu organizacjach ma jakiś rodzaj ekranu, a może nawet pewnej puli ekranów gdzieś zawieszonych pod sufitem, gdzie pewne istotne mierniki są wyświetlane albo wręcz rotują się kolejne dashboardy z ważnymi rzeczami, które dla tego zarządzającego i dla jego obszaru są istotne.

Tam najczęściej jest coś więcej niż tylko miary procesu, o których dzisiaj mówimy, bo tam pewnie będzie też temat związany ze stabilnością działania produktu, a pewnie przede wszystkim jakieś miary biznesowe związane z tym konkretnym produktem, ale w każdym razie jest okazja do tego, żeby widzieć na bieżąco pewne odczyty.

A druga praktyka, którą widuję, może taka bardziej przerywana, związana z tym, co powiedziałeś o cyklach, Jacek, czyli wykorzystanie jakichś okazji typu Sprint Review, jakieś podsumowanie, może takie dłuższe podsumowania typu jakieś spotkania kwartalne, miesięczne, jakkolwiek jest to w firmie zorganizowane. Tam też może stałym punktem programu mógł być temat jednej, dwóch, trzech miar, na których nam zależy procesowych i jakaś refleksja publiczna, przejrzysta komunikacja na temat tego, jak proces w tej chwili wygląda i gdzie zmierza.

Kuba: Piąta porada, wspólnie z zespołem ustalcie plan usprawniania procesu. Tutaj konsekwentnie gramy teraz z Jackiem tę piłkę, samo mierzenie to za mało, czyli załóżmy, że masz już pomierzony proces, na bieżąco weryfikujesz dane, statystyki, Twój zespół ma to zakomunikowane przy jakiejś nadarzającej się okazji. Natomiast jednoznacznie rekomendujemy, żeby te miary pozyskane, żeby te liczby, które gdzieś pokazują na temat procesu pewne fakty, żeby to wykorzystać do usprawniania. I tutaj rolą liderską będzie z jednej strony oczekiwanie, żeby powstał plan usprawnień, ale też będzie pewna wizja do przekazania, jak mogłoby albo jak powinno być.

Jacek: Jak z każdą zmianą wyzwaniem może być wygospodarowanie czasu na to, żeby się nad tymi danymi, które pozyskamy z procesu zastanowić. To nie jest tak, że tak jak Kuba mówi, są jakieś dashboardy, które to wyświetlają i jakby cała reszta się dzieje samoistnie. To będzie wymagało czasu, czyli mamy jakieś odczyty. One są niepokojące albo właśnie takie optymistyczne.

No i będziesz musiał w Twojej firmie, czy musiała, znaleźć czas na to, żeby to przedyskutować z zespołem, ocenić, dlaczego tak jest, z czego to wynika, po to, żeby albo wzmacniać pewne pozytywne zachowania, które powodują, że mierniki, na których ci zależy, idą we właściwą stronę, albo żeby przygotować jakieś działania korygujące, jeśli patrzysz na dane. I one pokazują, że sprawy nie idą we właściwym kierunku.

Jacek: Przedostatnia porada, skup się na usprawnianiu procesu, a nie podkręcaniu wyników. To jest jeden z kontrowersyjnych punktów, które chcemy ci przedstawić. W takim sensie, że bywa, że uruchamia się mechanizm w ludziach, w zespołach, na zasadzie, że skoro oczekują jakiś konkretnych od nas wyników, organizacja oczekuje, no to będziemy robić tak, żeby te wyniki się pojawiły.

Tutaj wyraźną rolą liderów, managerów w organizacji jest nieustanne komunikowanie, że nie o to chodzi, że tak naprawdę istotne jest posiadanie danych, na bazie których możemy korygować proces. No i w pewnym sensie należy zaakceptować, że te początkowe wyniki nie będą tak dobre, jak intuicyjnie czujesz, że mogłyby być.

I na pewno jest tutaj temat, użyje analogizmu, zarządzania szokiem, czyli będzie zdziwienie, że wcale nie jest tak kolorowo, jak sobie wszyscy wyobrażaliśmy w firmie. No i będziesz musiał zadbać o to, żeby pomimo tego szoku, nie pojawił się efekt pomalowania, przemalowania wyników na zielono, tylko żeby jednak zespoły wzięły odpowiedzialność za to, jak jest, no i przygotowały odpowiednie działania naprawcze. 

Kuba: W ramach takich szoków, o których Jacek mówi, pojawiają się takie pomysły, jak na przykład wyłączenie pewnej puli inicjatyw ze średniej, no bo te akurat nam źle wyszły albo one były wyjątkowe, czy właśnie też takie majstrowanie, o którym wspomniałem wcześniej, że tutaj może na nowo zgłośmy tą inicjatywę, bo tak naprawdę to jest zupełnie nowa inicjatywa.

Zwracając na to uwagę, może właśnie pokażę taką odwagę osobistą poprzez poproszenie wszystkich o to, żeby jednak dane były takie, jakie są, nawet jeśli są trochę krzywdzące, trochę niesprawiedliwe, no bo to są tylko suche fakty, to nie jest tak, że jesteśmy beznadziejni, tylko taki jest właśnie proces i takie statystyki, takie dane pokazuje.

Więc tutaj Twoją dużą rolą może być no takie modelowanie zachowań, pokazanie na własnym przykładzie, pokazanie pewnej odwagi, no i przesunięcie uwagi też na to, żeby wszyscy zastanowili się w całej organizacji, co wszyscy mogą zrobić, jak zmienić system, jak zmienić narzędzie, jak zmienić sposób działania, jak zmienić kulturę, żeby ten proces usprawnić i żeby statystyki pokazały, że faktycznie jest lepiej.

Kuba: I ostatnia porada z naszej strony to regularnie dokonuj refleksji na temat procesu mierzenia. To jest nasz klasyk, zawsze różne sumy, porad czy listy jakichś naszych rekomendacji, kończymy tego typu uwagą, natomiast tutaj bardzo ważny aspekt, taki logiczny, refleksja na temat procesu mierzenia, czyli tutaj nieodłącznym elementem mierzenia jest również usprawnianie procesu, natomiast my chcemy zwrócić uwagę na temat, jak zbierane są dane, jak są komunikowane wyniki, jakie kontrowersje to wszystko wywołuje, czy narzędziówka jest taka, jaka ma być.

Czyli zastanów się, poproś o informację zwrotną, zastanówcie się w jakiejś większej grupie, jak te kwestie mierzenia procesu i propagowania tych wyników związanych z procesem, jak później ich wykorzystanie w praktyce się sprawdza, jak wydajny jest proces mierzenia procesu i co można w nim ewentualnie poprawić.

Najczęściej jest sporo do poprawy, np. eliminacja jak największej ilości czynnika ludzkiego w tym procesie, doskonalenie użyteczności pewnych informacji. Jest co w tym robić i warto to doskonalić, żeby czasami nie przypiąć takiej łatki, że niedoskonałe mierzenie powoduje, że porzucamy ten koncept, bo wszyscy mają takie poczucie, że może można było to robić lepiej, albo to, co jest dzisiaj tą pierwszą wersją, jest niewystarczająco dobre, żeby można było zaufać tym liczbom.

Jacek: Nie są to jakieś historie zmyślone czy zachęta do tego, żeby usprawniać wszystko, bo przecież jesteśmy w ramach podcastu Porządny Agile, tylko za tą przestrogą stoją konkretne historie, których z Kubą doświadczamy i tak mówiąc bardzo praktycznie, znajdą się osoby w twojej organizacji, które nie są zainteresowane zmianą, które będą zainteresowane tym, żeby było, tak jak jest.

I to będą pierwsze osoby, które będą kwestionować jakość tych danych, które będą płynąć z miar. No i bardzo łatwo będzie takim osobom skomentować, że to nie ma sensu, że widzicie, mówię od początku, nic z tego nie wynika, nic nam to nie daje, tracimy tyle czasu na to i tak dalej i tak dalej, więc jakby to są niestety żywe i prawdziwe historie, dlatego ten aspekt usprawniania sposobu zbierania i w ogóle zarządzania tymi miarami jest niezwykle istotne, żeby to miało faktyczny wpływ na poprawianie efektywności twojej organizacji.

Jacek: Podsumowując. Znajomość miar Twojego procesu pozwala lepiej zarządzać produktem, budować zaufanie u interesariuszy i usprawniać sposób wytwarzania.

Kuba: Mierniki procesu takie jak Time to Market, Lead Time czy Cycle Time są popularne, ale wymagają jasnej definicji i zdyscyplinowanego pomiaru. 

Jacek: Warto rozważyć mniej popularne miary, takie jak na przykład Flow Efficiency.

Kuba: Zbuduj w Twoim zespole plan stosowania miar i usprawniaj na tej bazie proces. 

Jacek: Temat usprawniania procesu jest jednym z elementów spisu treści mojej nadchodzącej książki, czyli „Labiryntów Scruma” wydania drugiego. Jest to drugie wydanie po kilku latach od pojawienia się pierwszej wersji. Poprawione, usprawnione, dodana jest cała masa różnych przykładów, również ta dotycząca tego jak mierzyć proces.

I książka ta będzie dostępna w sprzedaży pod koniec czerwca. Tak naprawdę trwają teraz ostatnie prace związane z poprawkami po wydruku próbnym. Jeżeli interesujecie temat jak naprawić wykorzystanie Scruma w Twoim zespole, czy chciałabyś dostać taki kompletny przewodnik jak to zrobić, to zachęcam Cię do śledzenia strony labiryntyscruma.pl, jak również mojego newslettera na stronie jacekwieczorek.pl oraz w mediach społecznościowych, w których się udzielam, najwięcej na LinkedInie, po to, żebyś dostał lub dostała informacje o tym, że faktycznie książka jest już dostępna.

Kuba: A notatki do tego odcinka, artykuł, transkrypcję oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/135.

Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek. I do usłyszenia wkrótce.

________

To była pełna transkrypcja odcinka podcastu Porządny Agile. Dziękujemy za lekturę!

Ostatnia aktualizacja: 13 stycznia 2026

Jak przygotować się do Retrospektywy wielu zespołów? Wyjaśnimy Ci, jak skutecznie organizować spotkania usprawnieniowe obejmujące więcej niż jeden zespół. Omawiamy najczęstsze błędy i podpowiadamy, jak stworzyć dobrą strukturę takiego wydarzenia. W rozmowie przedstawimy Ci konkretne wskazówki dotyczące przygotowania Retrospektywy. Jeśli jesteś liderem zespołu, kierownikiem projektu, Product Managerem lub Scrum Masterem i masz pod swoimi skrzydłami więcej niż jeden zespół — ten materiał jest dla Ciebie.

Spis treści

• Jakie mogą być problemy z wielozespołowym spotkaniem usprawnieniowym?
• 7 kroków udanej retrospektywy według Porządny Agile 
• Wskazówki co do sposobu przygotowania skalowanej Retrospektywy
• FAQ: Spotkania usprawnieniowe wielu zespołów
• Materiały dodatkowe
• 📄Transkrypcja podcastu „Spotkania usprawnieniowe wielu zespołów”

1. Marnowanie czasu – Niewłaściwie przeprowadzone wydarzenie może okazać się stratą czasu. Zazwyczaj uczestniczy w nim wiele osób, a jego przebieg trwa dłużej niż standardowa Retrospektywa. Im więcej uczestników, im dłuższe spotkanie, tym większy koszt, a jeśli nie przyniesie konkretnych rezultatów, trudno będzie uzasadnić jego sens.

2. Niewłaściwy skład – Retrospektywa może również mieć niewłaściwy skład. Często pojawia się pokusa, by zaprosić wszystkich członków zaangażowanych zespołów, a nawet dodatkowe osoby pełniące funkcje zarządcze. W efekcie spotkanie staje się zbyt liczne, co utrudnia sprawną pracę i prowadzi do braku decyzyjności lub bezwładności. Taka konfiguracja rzadko sprzyja konkretnym wnioskom i wartościowym rezultatom.

3. Chaotyczny przebieg – Spotkanie przeprowadzone bez odpowiedniego przygotowania może przebiegać w sposób chaotyczny. Obecność wielu osób o różnych temperamentach i z różnych zespołów, które nie miały okazji wcześniej wypracować wspólnych zasad działania, w połączeniu z brakiem struktury, niekontrolowanym dopuszczaniem do głosu i brakiem moderacji – to przepis na nieuporządkowaną dyskusję. Takie spotkanie może być intensywne, ale rzadko przynosi konkretne i mierzalne efekty.

4. Narzekanie – Zdarza się, że spotkanie przeradza się w zbiorową sesję narzekania. Kolejne osoby, przedstawiciele różnych zespołów dzielą się tym, co nie działa i jak mogłoby wyglądać inaczej. Jednak jeśli rozmowa nie jest odpowiednio moderowana, nie prowadzi do żadnych konstruktywnych wniosków. Zamiast tego uczestnicy mogą się wzajemnie nakręcać, co potęguje negatywne emocje i zniechęca do udziału w kolejnych sesjach tego typu.

5. Brak realnych zmian – W efekcie wszystkie wymienione wcześniej błędy mogą prowadzić do braku realnych zmian. Może się okazać, że spotkanie nie kończy się żadnymi sensownymi wnioskami albo  jeśli skalowana Retrospektywa została źle zaplanowana, ustalenia będą powierzchowne. Nawet jeśli pojawią się jakieś propozycje działań, zabraknie konkretnego ustalenia, kto odpowiada za ich wdrożenie.

Problemów tego typu może być znacznie więcej, jednak w tym miejscu skupiamy się na kilku najczęstszych, aby zarysować tło przed kolejnymi rozdziałami i podkreślić, dlaczego struktura, dobre przygotowanie oraz konkretne wskazówki, którymi się podzielimy, są naprawdę istotne.

Uważamy, że filarem skutecznego wielozespołowego usprawniania się jest porządna struktura. To dobry moment, aby przytoczyć fragment naszego webinaru o Retrospektywie, w którym dzielimy się rekomendacjami dotyczącymi jej przebiegu i struktury. Jeśli jeszcze nie widziałeś tego materiału, znajdziesz go na stronie porzadnyagile.pl/retro. W materiale przedstawiamy również naszą autorską wersję struktury, którą nazywamy siedmioma krokami udanej Retrospektywy według Porządnego Agile’a. Co stanowi pierwszy krok?

Aby Retrospektywa miała sens, warto sprawdzić, czy ustalenia z poprzedniego spotkania zostały zrealizowane. Jeśli nie – należy zastanowić się, dlaczego tak się stało i jakie działania należy podjąć, by zrealizować zaległe usprawnienia.

W szczególności wtedy, gdy w spotkaniu biorą udział osoby dołączające okazjonalnie albo gdy zaplanowano konkretny temat do omówienia, warto na początku przypomnieć cel i zakres rozmowy. Ułatwi to uczestnikom zrozumienie, dlaczego biorą udział w spotkaniu i czego można się po nim spodziewać.

Na tym etapie ważne jest systemowe i przemyślane pozyskanie wkładu od wszystkich uczestników spotkania. Chodzi o to, by każda z zaproszonych osób miała szansę wyrazić swoje obserwacje i spostrzeżenia. Wyrównanie czasu antenowego zapobiega sytuacjom, w których jeden z liderów – świadomie lub nie – nadaje kierunek rozmowie. Dzięki temu zespół może usłyszeć różnorodne perspektywy i zbudować pełniejszy obraz sytuacji.

Zebrane propozycje tematów warto uporządkować i wspólnie zdecydować, które z nich są kluczowe. Aby uniknąć sytuacji, w której zespół spontanicznie skupia się na pierwszym zgłoszonym zagadnieniu, warto oddzielić etap zbierania tematów od ich selekcji, na przykład poprzez głosowanie. Niezależnie od wybranej metody, uczestnicy powinni wiedzieć, że powstanie ranking, który wyznaczy kolejność omawiania tematów zaczynając od tych najistotniejszych.

Piąty krok to dokładna analiza najważniejszego problemu. Gdy zespół wybierze temat do omówienia, warto najpierw zastanowić się, z czego ten problem wynika. Nie zalecamy od razu przechodzić do propozycji rozwiązań, w takim podejściu mogą się pojawić działania powierzchowne lub nieskuteczne. Lepiej zatrzymać się i przyjrzeć się systemowo temu, skąd bierze się dany kłopot i jakie mogą być jego przyczyny.

Dopiero po analizie przyczyn i przemyśleniu możliwych scenariuszy działania, zespół podejmuje świadomą decyzję o konkretnym usprawnieniu. To moment, w którym grupa deklaruje, że podejmie się wdrożenia danego rozwiązania i będzie go konsekwentnie realizować.

Warto na zakończenie spotkania upewnić się, że wszystkie ustalenia zostały jednakowo zrozumiane przez uczestników. W przypadku dłuższych wydarzeń, jakimi są skalowane Retrospektywy, część tematów poruszanych na początku może już nie być tak świeża w pamięci. Jasne podsumowanie pozwala zebrać najważniejsze wnioski i potwierdzić, co konkretnie zostało ustalone i co należy zrobić po zakończeniu spotkania.Świadomie zatrzymaliśmy się na ogólnym poziomie omówienia tej struktury. Szczegółowe instrukcje, gotowe szablony oraz różne techniki realizacji poszczególnych kroków znajdziesz w naszym webinarze o Porządnej Retrospektywie. Sprawdź materiał na stronie: porzadnyagile.pl/retro.

Na wstępie warto zaznaczyć, że nieprzypadkowo ten rozdział poświęcamy przygotowaniu skalowanej Retrospektywy. Świadomie podkreślamy, że w porównaniu do standardowego spotkania retrospektywnego jednego zespołu, tutaj znaczenie przygotowania rośnie. Skalowana Retrospektywa to nie jest spotkanie, które można poprowadzić rutynowo z marszu.

Skuteczność tego wydarzenia w dużej mierze zależy od przemyślanych kroków przygotowawczych wykonanych przez osobę odpowiedzialną za organizację i moderację. Oczywiście, podczas takiego spotkania zwłaszcza w większym gronie, zawsze mogą pojawić się niespodziewane tematy. Tym bardziej warto zadbać o to, aby wszystkie elementy, które można przewidzieć i zaplanować, były dobrze przygotowane. To one stanowią fundament udanego przebiegu Retrospektywy.

Na skalowanej Retrospektywie powinni pojawić się reprezentanci różnych ról i zespołów, zwłaszcza tacy, którzy mają realny mandat do działania. Choć rozmowa może być wartościowa sama w sobie, to kluczowe jest, aby na koniec spotkania można było podjąć konkretne decyzje. To one stanowią paliwo napędowe dalszych zmian uczestnicy widzą, że coś się dzieje, zapadają decyzje i rzeczywiście ruszamy do przodu. Zadbanie o odpowiedni skład gości leży po stronie organizatora spotkania, to właśnie ta osoba powinna dopasować uczestników do tematyki, którą planujemy poruszyć.To może być misja wewnątrz jakiejś misji, trzeba odpowiednio wytypować uczestników spotkania i upewnić się, że rzeczywiście są to właściwe osoby. W dużej organizacji może się zdarzyć, że nie znamy wszystkich, dlatego tym bardziej warto zadbać o obecność reprezentantów kluczowych obszarów. Przykładowo: osoby odpowiedzialne za proces wdrożeniowy, za współpracę z infrastrukturą, czy przedstawiciele działu prawnego, którzy mogą wziąć odpowiedzialność za wdrożenie zmian.
Potrzebujemy na tym spotkaniu ludzi, którzy  nawet jeśli nie podejmą decyzji od razu będą w stanie przyjąć zobowiązania, wprowadzić zmiany samodzielnie lub przekazać je dalej do realizacji. Może to być ich własny zespół, jeśli pełnią funkcje liderskie, albo grupy zadaniowe, jeśli mówimy o ekspertach.
Bez odpowiednich osób, nawet najlepsze ustalenia nie mają szans na wdrożenie, dlatego tak ważny jest właściwy skład uczestników usprawnieniowego spotkania wielozespołowego.

Druga wskazówka dotyczy przygotowania uczestników przed spotkaniem. Wielozespołowa Retrospektywa nie powinna być organizowana z marszu,szczególnie jeśli biorą w niej udział osoby, które nie mają na co dzień kontaktu z kulturą ciągłego doskonalenia czy z praktyką retrospektyw znanych ze Scruma.

W spotkaniu mogą uczestniczyć przedstawiciele różnych poziomów organizacyjnych na przykład dyrektor infrastruktury czy szefowa działu prawnego a więc osoby, które mogą nie znać tej formy pracy lub nie czuć się w niej komfortowo. Również pozostali uczestnicy mogą odczuwać dyskomfort związany z obecnością takich osób.

Warto więc w miarę możliwości przeprowadzić rozmowy przygotowawcze. Wyjaśnijmy uczestnikom, czego dotyczy spotkanie, zachęćmy do otwartości i wspierajmy ich w aktywnym uczestnictwie.

Taka zakulisowa praca może obejmować m.in. indywidualne rozmowy z osobami, które warto zachęcić do wypowiedzi, a także uprzednie ustalenia z tymi, które mają tendencję do dominowania dyskusji, by dały przestrzeń innym uczestnikom. To znacząco zwiększy szanse na konstruktywny i zbalansowany przebieg spotkania.

Warto pamiętać, że niektóre osoby mogą mieć negatywne doświadczenia z podobnych spotkań. Dobrym pomysłem będzie wcześniejsze przedstawienie planu wydarzenia, pokazanie przemyślanej struktury i solidnego przygotowania. To może zwiększyć szanse, że uczestnicy uznają udział za wartościowy i chętniej poświęcą swój czas.

Dodatkowym elementem, który warto przygotować, są dane. Jeśli temat spotkania jest znany, a powinien być często w organizacji można znaleźć konkretne informacje dotyczące procesów, technologii lub produktu. Takie dane mogą być przydatne w trakcie dyskusji, zwłaszcza gdy pojawią się różnice zdań co do tego, jak coś funkcjonuje. Wtedy odwołanie się do twardych danych pomoże nadać rozmowie konkretny kierunek. 

Dane może przygotować osoba prowadząca spotkanie, ale jeszcze lepszym rozwiązaniem jest wcześniejsze poproszenie uczestników, by przynieśli informacje ze swojego obszaru  dotyczące konkretnego procesu czy zagadnienia, którym się zajmują. Dzięki temu rozmowa opiera się na faktach i konkretach, a nie na subiektywnych opiniach czy domysłach.

Kolejnym elementem przygotowania jest zapewnienie wsparcia ze strony wyższego szczebla zarządzania. Chodzi o wcześniejsze poinformowanie osób pełniących kluczowe role w organizacji o znaczeniu nadchodzącej Retrospektywy i możliwych efektach tego spotkania. Warto zadbać o to, by menedżerowie potraktowali poważnie informacje i propozycje, które zostaną im przekazane po wydarzeniu. Nic tak nie demotywuje zespołu, jak odbicie się od nieprzygotowanego managera, który nie rozumie kontekstu, nie zna celu spotkania lub reaguje zdawkowo, bagatelizując wypracowane pomysły. W skrajnych przypadkach może to wręcz wygenerować dodatkowe problemy. Dlatego przygotowanie wyższego managementu to zadanie, które warto zaplanować i zrealizować z wyprzedzeniem.
Ten temat ma również związek z koncepcją Circle of Influence, którą omówiliśmy w 126 odcinku naszego podcastu. Warto mieć świadomość, że nawet dobrze dobrani uczestnicy Retrospektywy mogą dojść do punktu, w którym uznają, że omawiane kwestie wykraczają poza ich strefę wpływu. Dlatego tak ważne jest wcześniejsze uzyskanie wsparcia ze strony wyższego szczebla zarządzania. Osoba prowadząca spotkanie może wtedy powiedzieć: „Rozmawiałem z Iwoną i ona chce, żebyśmy przyszli z konkretną propozycją, analizą lub planem i obiecała, że zostaniemy wysłuchani.” Tego typu komunikat wzmacnia motywację uczestników i zwiększa szanse na realne wdrożenie wypracowanych pomysłów. Takie podejście sprzyja też budowaniu lepszych relacji między menedżerami a zespołami operacyjnymi. Więcej o Circle of Influence znajdziesz na stronie porzadnyagile.pl/126

Jeśli masz doświadczenie z Retrospektywami prowadzonymi dla jednego zespołu, musisz liczyć się z tym, że w wersji wielozespołowej wszystko trwa znacznie dłużej. Gdy zapraszasz przedstawicieli wielu zespołów, również procesowych czy wsparciowych rośnie ryzyko, że nie zmieścisz się w zaplanowanym czasie. W najgorszym scenariuszu uczestnicy zaczną wychodzić, zanim wypracujecie jakiekolwiek ustalenia, ponieważ spotkanie było przewidziane na godzinę lub dwie.

Zachęcamy, aby od razu zaplanować więcej czasu. Spotkania tego typu przebiegają wolniej, uczestnicy chcą dzielić się swoimi perspektywami, przedstawiać dane, a każdy etap wymaga dobrej struktury i uważnego przejścia. Załóż, że potrzebujesz przynajmniej dwa razy więcej czasu niż na standardową Retrospektywę. Jeśli tylko Twoja organizacja może sobie na to pozwolić, rozważ nawet pół dnia lub sześć godzin, zależnie od skali i liczby uczestników.

Taki czas to nie koszt, lecz inwestycja w realne usprawnienia. Nasze doświadczenie pokazuje, że dobrze zaplanowane Retrospektywy wielozespołowe przynoszą świetne efekty. Najważniejsze, by nie zapomnieć o jednym, potrzebujesz na nie odpowiednio dużo przestrzeni czasowej.

Warto uważać na pewną pułapkę związaną z liczebnością grupy. Nawet jeśli w spotkaniu uczestniczą jedynie reprezentanci różnych obszarów lub zespołów, ich liczba może wydawać się niewielka – co może skłaniać do pozostawienia domyślnego czasu trwania Retrospektywy. Tymczasem kluczowe jest to, że pojawią się zróżnicowane perspektywy. Może to być przedstawiciel działu sprzedaży, DevOpsów czy HR-u,  każda z tych osób wnosi inną wiedzę i doświadczenie.

Aby te punkty widzenia zostały właściwie zrozumiane, potrzebny jest czas. Wyjaśnienie specyficznego tematu wymaga nie tylko dokładnego przedstawienia, ale również otwarcia przestrzeni na pytania i doprecyzowania. Dotyczy to każdej osoby i każdej specjalizacji obecnej na spotkaniu.

Jeśli chcesz, by decyzje były trafne i wspólne, zadbaj o to, by wszyscy dobrze rozumieli przedstawiane informacje. Nie ma skuteczniejszego sposobu niż uważne słuchanie i upewnienie się, że właściwie interpretujemy to, co druga strona chce przekazać.

Przed rozpoczęciem takiego spotkania warto jasno zaznaczyć, po co właściwie się spotykacie i jaki jest cel wspólnej pracy. To dobry moment na krótkie, konkretne wprowadzenie – możesz podkreślić znaczenie wspólnego doskonalenia i wyjaśnić, dlaczego warto poświęcić czas na szukanie usprawnień.

Jeśli chcesz dodatkowo wzmocnić przekaz, poproś o głos osobę z wyższego szczebla organizacji. Nawet krótkie wystąpienie z komunikatem: „czekam na wyniki, życzę powodzenia, jestem z Wami jeśli potrzebujecie wsparcia, dajcie znać” może istotnie wpłynąć na zaangażowanie uczestników.

Taka zachęta, zwłaszcza na początku spotkania może zadziałać jak dobre paliwo, które będzie potrzebne przy analizie problemów i tworzeniu realnych rozwiązań.

Ta wskazówka łączy się z wcześniejszymi poradami dotyczącymi przygotowania uczestników oraz zapewnienia wsparcia ze strony wyższego managementu. W idealnym scenariuszu osoba z top managementu pojawia się na początku spotkania i przedstawia krótkie Expose, podkreślając jego wagę.

Nawet jeśli takie wystąpienie się nie wydarzy, wszyscy uczestnicy muszą rozumieć, jaki jest cel wydarzenia i dlaczego zostało zwołane. To szczególnie ważne w kontekście wcześniejszych, często negatywnych doświadczeń z podobnymi spotkaniami. Wiele osób reaguje dziś sceptycznie na zapowiedź „międzyzespołowej Retrospektywy”, ponieważ mają w pamięci chaotyczne spotkania, które nic nie wniosły, a jedynie pochłonęły pół dnia w krytycznym momencie projektu.

Właśnie dlatego warto zadbać o jasny przekaz dotyczący celu i sensu spotkania. Dobrze sformułowane wprowadzenie, zbudowanie właściwego nastawienia i pokazanie wartości tej inicjatywy mogą nadać ton całej Retrospektywie. To moment, w którym uczestnicy powinni zyskać poczucie, że pracują nad czymś konstruktywnym nad poprawą działania zespołów, produktów, czy sposobu realizacji przyszłych projektów w podobnym składzie.

Przedostatnia wskazówka dotyczy zadbania o jasną i zrozumiałą instrukcję dotyczącą przebiegu spotkania. Warto pamiętać, że w Retrospektywie wielozespołowej mogą uczestniczyć osoby, które rzadko biorą udział w podobnych wydarzeniach, a niektóre mogą nigdy wcześniej nie uczestniczyć w Retrospektywie.

Jeśli grupa jest liczna, pojawiają się osoby o silnych osobowościach lub z własnymi interesami wynikającymi z trudności w ich zespołach, może to prowadzić do nieuporządkowanego przebiegu dyskusji. Nawet jeśli spotkanie nie będzie chaotyczne w oczywisty sposób, dla mniej doświadczonych uczestników może być trudne do śledzenia.

Z tego powodu odpowiedzialność za przekazanie jasnych instrukcji spoczywa na osobie prowadzącej spotkanie. Warto zadbać, by uczestnicy dobrze rozumieli zasady pracy i wiedzieli, czego się od nich oczekuje w każdym etapie wydarzenia. Dobrą praktyką jest przygotowanie notatek lub wizualnych pomocy np. prostych grafik czy slajdów, które jasno pokazują, gdzie należy coś zapisać, zaznaczyć, umieścić strzałkę lub punkt.

Równie istotne jest późniejsze pilnowanie, by ustalone zasady były przestrzegane. Dzięki temu spotkanie przebiega sprawnie, a każdy uczestnik ma szansę w pełni zaangażować się w proces usprawniania.

To, że pewne rzeczy dzieją się automatycznie w Twoim zespole, nie oznacza, że tak samo będzie w nowej, większej grupie. W znanym zespole można bazować na wspólnych doświadczeniach, wypracowanych skrótach myślowych, a uczestnicy zazwyczaj są przyzwyczajeni do konkretnego stylu pracy, nawet jeśli forma spotkania nieco się zmienia.

Warto jednak pamiętać, że pojęcie „Retrospektywa” może znaczyć coś zupełnie innego dla różnych zespołów lub osób w organizacji. Przykładowo, w jednej z firm, którą obecnie wspieramy, Retrospektywa to spotkanie prowadzone przez lidera, który sam zadaje pytania i sam na nie odpowiada. Dominuje w rozmowie, a pozostali uczestnicy czują się zepchnięci na margines. Ich zdanie nie ma realnego wpływu na przebieg spotkania, a żadne usprawnienia nie są wprowadzane.

Osoby z takim doświadczeniem mogą przystąpić do Retrospektywy z ograniczonym zaufaniem lub niechęcią. Dlatego tak istotne jest, aby instrukcje przekazywane przed i w trakcie spotkania były jasne, spokojne i konkretne. Dla wielu uczestników może to być coś nowego – warto więc zadbać o przejrzystość i zrozumienie od samego początku.

Ostatnia porada: umów się z uczestnikami na zasady monitorowania ustaleń. Wyjście ze spotkania z konkretnymi działaniami to jedno, pomóc w tym może dobra struktura oraz wszystkie wcześniejsze elementy, o których wspomnieliśmy.

W przypadku wielozespołowych Retrospektyw szczególnym wyzwaniem jest to, że uczestnicy najczęściej wracają do swoich ról w różnych działach czy zespołach. Trudno wtedy o regularny follow-up i dopilnowanie realizacji ustalonych działań.

Dlatego już podczas spotkania warto uzgodnić, jak monitorować wdrażanie usprawnień. Może to oznaczać ustalenie punktów synchronizacji, zasad komunikacji lub konkretnego kanału, na którym uczestnicy będą dzielić się postępami. Dzięki temu zwiększamy szansę, że ustalenia nie zostaną zapomniane, a usprawnienia rzeczywiście zostaną zrealizowane. 

Pomysłów na monitorowanie ustaleń może być wiele, ale najlepiej mieć własną propozycję jeszcze przed rozpoczęciem spotkania. W końcowej fazie Retrospektywy, gdy uczestnicy są już zmęczeni, wspólne ustalanie, czy tworzymy kanał na Teamsie, czy organizujemy kolejne spotkanie, może okazać się zbyt obciążające.

Warto w takiej sytuacji jako osoba prowadząca mieć gotową i dopasowaną do realiów organizacji propozycję działania albo od razu ją zaprezentować, albo przygotować jako punkt wyjścia do krótkiej dyskusji.

Nie zakładaj, że „wszyscy się wywiążą”. Jak wspomnieliśmy wcześniej, uczestnicy wrócą do swoich zespołów i obowiązków, a jeśli nie będzie jasno ustalonego sposobu na dalszą komunikację, nawet najbardziej konkretne i sensowne pomysły mogą się po prostu rozmyć.

Dlatego warto wcześniej zaplanować: kiedy i jak wracamy do tematu, w jakiej formie się synchronizujemy, jak dzielimy się postępami, czy i w jaki sposób kontynuować rozmowę, szczególnie w przypadku bardziej złożonych tematów.

Jak dobrze przygotować się do spotkania usprawnieniowego wielu zespołów?

W temacie skalowanej Retrospektywy możemy wesprzeć Twoją firmę na wiele sposobów:

Jeśli Twoje zespoły potrzebują wsparcia w efektywnych, skalowanych spotkaniach usprawnieniowych, odezwij się do nas przez formularz na stronie porzadnyagile.pl/kontakt.

W trakcie spotkania usprawnieniowego wspólna rozmowa pozwala szybko zidentyfikować blokady, usprawnić współpracę i wprowadzić zmiany, które działają szeroko w całej organizacji.

Spodziewaj się chaosu, straty czasu i braku realnych efektów — a to odbiera ludziom motywację i zaufanie do zmian.

Zaproś tylko te osoby, które mają realny wpływ na decyzje — dzięki temu zmiany ustalone podczas spotkania mogą być szybko wdrożone.

Świadomi uczestnicy szybciej wchodzą w merytoryczne rozmowy i wspólnie szukają rozwiązań, zamiast tracić czas na nieporozumienia lub poszukiwanie informacji.

Daj wszystkim uczestnikom jasny kontekst i odpowiednie wsparcie – wtedy nawet trudne tematy mają szansę zostać wypowiedziane i rozwiązane.

Przy wielu zespołach potrzeba więcej czasu na zrozumienie różnych perspektyw i wypracowanie realnych, a nie powierzchownych usprawnień. Zarezerwujcie sobie na to kilka godzin.

Dobre exposé ustawia wszystkich na wspólny cel i motywuje do szukania rozwiązań, a nie tylko omawiania problemów.

Jasne instrukcje pomagają wszystkim odnaleźć się w strukturze spotkania i utrzymać tempo bez zbędnego chaosu.

Ustal konkretne zasady monitorowania — to zwiększy szansę, że ustalenia nie „znikną” w natłoku codziennej pracy.

Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu Porządny Agile.

Kuba: I w tym wstępie Jacek powiedział o tym, że wspieramy organizacje poprzez między innymi warsztaty. Podczas niedawnych warsztatów u jednego z klientów pomagaliśmy przygotować się w pewnej grupie. W tym konkretnym przypadku grupie Scrum Masterów w temacie poprowadzenia wielozespołowych spotkań usprawnieniowych. Mamy tu na myśli coś, co bywa też nazywane na przykład skalowaną Retrospektywą, ale w tym przypadku to często niekoniecznie jest Retrospektywa Sprintu, to jest rozmowa o jakimś wdrożeniu, podsumowanie projektu, temat współpracy kilku zespołów, być może kilku zespołów, nawet niekoniecznie Scrumowych, ale zespołów w ramach organizacji czy w ramach jakiegoś projektu. Kwestia tego, jak je przeprowadzić, takie warsztaty usprawnieniowe wielozespołowe jest na tyle ważna i trzeba je na tyle dobrze przygotować, jest to też jednocześnie na tyle rzadko poruszane, że postanowiliśmy poświęcić cały odcinek tylko tej kwestii.

Jacek: I nagrywamy ten konkretny odcinek z myślą o liderach zespołów, z myślą o kierownikach projektu, Product Managerach czy Scrum Masterach, którzy mają pod swoją opieką, pod swoimi skrzydłami więcej niż jeden zespół i potrzebują zorganizować spotkanie usprawnieniowe, które obejmie cały obszar, całą grupę zespołów, czy być może też cały obszar, całą grupę zespołów, czy być może jakiś stream w zależności od tego, jak zorganizowana jest struktura w twojej filmie.

Kuba: Ale jeśli jesteś w organizacji w innej roli niż te, które wymienił Jacek, wytrzymaj z nami też, bo prawdopodobnie z jakiegoś powodu słuchasz naszego podcastu i myślę, że tutaj też będą treści również dla innych ról. Zwłaszcza jeśli jesteś w innych rolach, to też moja prośba czy nasza wspólna prośba o to, żeby wytrzymać też temat Retrospektyw. Być może w twojej organizacji czy w twoim doświadczeniu Retrospektywy kojarzą się trochę inaczej niż to, jak o tym dzisiaj opowiemy. Może mają też odmienny przebieg. Posłuchaj naszej wersji, co to znaczy porządna Retrospektywa, porządne spotkania usprawnieniowe, zwłaszcza w skali wielu zespołów.

Kuba: To zaczynając od pierwszego rozdziału w super skrócie. Jakie mogą być problemy z wielozespołowym spotkaniem usprawnieniowym?

Jacek: Niewłaściwie przeprowadzone może być marnowaniem czasu. Pojawi się na takim wydarzeniu sporo osób, to wydarzenie będzie też trwało, pewnie zwykle trochę duże niż taka normalna Retrospektywa. No i niestety przemnożenie osób przez czas powoduje, że w przypadku zmarnowania tego czasu będzie to nas kosztować, a nie będzie z tego żadnych sensownych rezultatów.

Kuba: Takie Retrospektywy mogą też mieć niewłaściwy skład. Czasami jest pokusa zaproszenia absolutnie wszystkich członków, wszystkich zaangażowanych zespołów, być może do proszenia kolejnych osób w jakiś rolach zarządczych, co może spowodować dużą liczebność, o której powiedział Jacek, a jednocześnie jakąś bezwładność czy brak odpowiedniego składu, co rzutuje na efekty.

Jacek: Niewłaściwie przeprowadzone spotkanie może mieć chaotyczny przebieg. Dużo osób, dużo różnych osobowości z różnych zespołów, które może nie są za sobą jakoś super dobrze dograne. Jeśli na to nałożymy brak sensownej struktury, dopuszczanie każdego, kto chce powiedzieć do głosu, niedbanie o żadne zasady związane z moderacją, no będą powodować, że takie spotkanie będzie chaotyczne, no i coś tam się na nim będzie działo, ale na pewno nie będzie prowadziło nas do wymiernych efektów.

Kuba: Bywa, że takie spotkanie też zamienia się w jakąś taką zbiorową sesję wspólnego narzekania, czyli kolejne osoby, kolejnymi przedstawiciele zespołów zaczynają dokładać tę perspektywę, co jest nie tak, jak mogłoby być inaczej, ale ponieważ nie jest to dobrze poprowadzone, z tego narzekania nic nie wynika, wręcz ludzie się tylko nakręcają, czy nawet może wręcz wpadają w stany takie negatywne, emocjonalne i nie mają ochoty w ten sposób przeprowadzać tego typu sesji.

Jacek: No i sumarycznie to wszystko, co mówimy może prowadzić do braku realnych zmian. Raz, że możemy w ogóle nie doprowadzić do sensownych wniosków, z drugiej strony niewłaściwie zaplanowana taka skalowana Retrospektywa może spowodować, że to na co się mówimy będzie albo miałkie, albo po prostu na coś się umówimy, ale zabraknie dyskusji o odpowiedzialności za to, żeby te konkretne akcje usprawnieniowe zrealizować.

Kuba: Problemów tego typu może być znacznie więcej, ale wymieniamy tylko te kilka najbardziej popularnych, żeby zarysować pewne tło przed kolejnymi rozdziałami i żeby pokazać też istotność tego, dlaczego struktura, dobre przygotowanie i pewne wskazówki, którymi się podzielimy, dlaczego one są ważne.

Jacek: Dobrze, przejdźmy do kolejnego rozdziału. Uważamy z Kubą, że filarem takiego dobrego wielozespołowego usprawniania się jest porządna struktura. To jest dobry moment, żebyśmy przytoczyli tutaj fragment naszego webinaru o Retrospektywie, gdzie m.in. dajemy naszą rekomendację co do przebiegu i struktury Retrospektywy. Jeśli jeszcze nie sprawdziłeś bądź nie sprawdziłaś tego materiału,znajdziesz go na stronie porządneagile.pl/retro.

Kuba: I wymieniamy tam m.in. naszą autorską wersję struktury, nazywamy ją siedmioma krokami udanej Retrospektywy według Porządnego Agile’a. Co jest pierwszym krokiem?

Jacek: Pierwszy krok, zweryfikuj usprawnienia z poprzedniej Retrospektywy. Żeby wydarzenia typu Retrospektywa miały sens, no to musimy sprawdzić w jakiś sposób, czy to na co się mówiliśmy na poprzednim tego typu spotkaniu, czy udało nam się zrealizować. Jeśli nie, należałoby się zastanowić, z czego to wynika i jakie są nasze kroki w związku z tym, że to na co się mówiliśmy jest niedowiezione.

Kuba: Drugi krok to przypomnij, co będzie przedmiotem i celem Retrospektywy. Zwłaszcza jeśli w tym spotkaniu uczestniczą osoby tylko okazjonalne, albo jest jakiś konkretny, z góry zaplanowany temat, który będzie podlegał dyskusji, warto to przypomnieć, warto to ustanowić na samym początku tego typu spotkania, żeby wszyscy uczestnicy rozumieli, po co tu się znajdują i o czym będzie całe wydarzenie.

Jacek: Trzeci krok, zbierz tematy do dyskusji lub przeanalizowania. Mamy tutaj na myśli systemowe, mądre zebranie wsadu od osób, które znajdują się na tym spotkaniu, po to, żeby wybrzmiały różne głosy i żeby ten czas antenowy dostępny dla uczestników był równo rozdany. Ma to zapobiec sytuacjom, w których ktoś pierwszy się odzywa, jakiś taki najbardziej czujący się do przodu lider i nieświadomie, a czasem świadomie, może nadać pewien bieg już konkretny tej Retrospektywie, a my byśmy tak naprawdę chcieli usłyszeć głos osób, które świadomie na to spotkanie zaprosiliśmy.

Kuba: I kolejny krok to wybierz z zespołem najważniejsze tematy. Tak jak Jacek powiedział, jest zagrożenie rzucenia się na pierwszy z tematów zgłoszonych albo w ogóle jedyny, który w ogóle się ujawnił. Proponujemy odróżnić krok, tak jak Jacek powiedział, ze zbieraniem tematów od kroku głosowaniem na nie. Metod głosowania jest wiele, nie będziemy teraz się w nie zagłębiać, ale w każdym razie wszyscy uczestnicy muszą zrozumieć, że zbudowany zostanie jakiś rodzaj rankingu tematów i poruszymy przede wszystkim te najważniejsze, zaczynając od tego pierwszego, najważniejszego czy najistotniejszego.

Jacek: Kolejny krok, omów dogłębnie największy problem. Kiedy mamy już wybrany temat, należałoby najpierw zastanowić się z czego ten problem wynika. Przestrzegamy przed szukaniem od razu rozwiązań, bo to może prowadzić do tego, że te rozwiązania będą niewłaściwe, płytkie bądź nieskuteczne, a raczej zachęcamy do tego, żeby dogłębnie systemowo spojrzeć na to, z czego lub z jak wielu różnych powodów mamy taki problem, a nie inny.

Kuba: I dopiero szóstym krokiem jest ustal rozwiązanie omówionego problemu. Czyli tak jak Jacek wspomniał, zanurkowaliśmy w przyczyny lub przyczyny problemu, porozmawialiśmy o tym, jakie są możliwe rozwiązania i dopiero jako grupa świadomie w przedostatnim kroku struktury dopiero ustalamy konkretne rozwiązanie, do którego grupa się będzie zobowiązywała, czy będzie się go trzymać.

Jacek: Ostatni krok, podsumuj zaplanowane usprawnienia. Dobrą praktyką jest, żeby na koniec spotkania upewnić się, że wszyscy tak samo rozumieją ustalenia, które zostały wypracowane przez grupę, biorąc też pod uwagę, że spotkanie takie skalowane to może być troszeczkę dłuższe wydarzenie. Może być tak, że te rzeczy, które omawialiśmy w pierwszej części już nie są dla ludzi tak świeże, no bo przykryliśmy je jakimiś tam kolejnymi tematami, więc podsumowanie na koniec tego, co zespół czy uczestniczące osoby w tym spotkaniu wypracowały, jest dobrym pomysłem, żeby upewnić się, że jest takie samo zrozumienie, co przed nami na skutek przeprowadzenia skalowanej Retrospektywy.

Kuba: I bardzo świadomie zatrzymaliśmy się na pewnym pobieżnym poziomie tej struktury. Więcej szczegółów o tym, jak je konkretnie realizować, konkretne instrukcje, gotowe szablony, kilka konkretnych różnych od siebie technik na to, jak zrealizować pewne punkty. Wszystko to znajdziesz w naszym webinarze o Porządnej Retrospektywie. Przypominam adres porzadnyagile.pl/retro.

Jacek: Dobrze, przechodzimy do ostatniego punktu, ale takiego najbardziej, myślę, konkretnego dzisiejszego odcinka, czyli wskazówki co do sposobu przygotowania skalowanej Retrospektywy.

Kuba: I tak tytułem wstępu to nie przypadek, że ten rozdział jest o przygotowaniu skalowanej Retrospektywy, bo też bardzo świadomie, gdy zastanawiamy się nad tym, od czego zależy sukces takiego spotkania, to w porównaniu do takiej zwykłej Retrospektywy, zwykłego spotkania pojedynczego z zespołu, tutaj rośnie znaczenie przygotowania się do spotkania. To nie jest spotkanie, które można zrealizować rutynowo, jak zwykle z marszu na żywioł. Tutaj dużo zależy od odpowiednich wykonanych kroków przygotowawczych przez osobę, która tego typu spotkanie przygotowuje i później faktycznie też poprowadzi. Jednocześnie oczywiście będzie tak, że w trakcie takich spotkań, zwłaszcza w dużym gronie, te tematy, które są problematyczne i tak pojawią się niespodziewane wątki, zwłaszcza te rzeczy, nad którymi jest kontrola, lepiej jest je mieć zaplanowane, dobrze przygotowane i zrealizować takie spotkania według konkretnego, ustalonego przygotowanego planu.

Jacek: Dobrze, to pierwsza porada z naszej strony. Zaproś osoby, które mogą podejmować decyzje. W tym punkcie istotne jest, żeby na skalowanej Retrospektywie pojawili się reprezentanci różnych ról, które masz w organizacji lub oraz różnych zespołów i nie zawsze osoby te będą mieć pełnomocnictwo czy mandat do podejmowania decyzji. Zawsze jest fajnie i miło sobie porozmawiać, natomiast na koniec dnia chcielibyśmy, żeby pojawiły się jakieś konkretne decyzje. Jest to też takie dobre paliwo dla ludzi, no bo widzą, że mamy konkret, mamy decyzje, idziemy do przodu. I to na Tobie jako na organizatorze czy organizatorce takiego spotkania spoczywa odpowiedzialność za to, żeby zaprosić właściwe osoby w zależności oczywiście od poruszonego tematu.

Kuba: Co może oczywiście tworzyć taką misję wewnątrz większej misji, bo te właściwe osoby trzeba wytypować, być może upewnić się, że to są te właściwe osoby. Jeśli jest bardzo rozległa organizacja, to być może nawet nie do końca znamy wszystkich, no ale na przykład osoby decydujące o procesie wdrożeniowym, procesie współpracy z infrastrukturą, zespoły prawników reprezentowane przez kogoś, kto może brać na siebie zobowiązania co do zmiany procesu, to takich kilka przykładów tego, jak różne osoby mogą być potrzebne na tego typu spotkaniach. I to są osoby, które mogą trochę w ciemno przyjąć założenia, że co do większości poruszanych tematów mogą albo podjąć decyzję, albo wziąć na siebie pewne zobowiązanie co do wykonania konkretnych działań usprawnieniowych. I to jest o tyle istotne, że tego typu spotkania wielozespołowe mogą prowadzić do ustalenia rozsądnych akcji, tylko nie ma komu ich wykonać. Więc tutaj dobrze byłoby, żebyśmy na takim spotkaniu mieli osoby, które mogą się zobowiązać, że albo same coś zrobią, albo zaniosą to do dalszej realizacji, na przykład do swojego własnego zespołu, jeśli mówimy o osobach w rolach liderskich, albo na przykład jakieś grupy zadaniowe, jeśli to będą osoby bardziej eksperckie. Ale w każdym razie musimy mieć właściwych ludzi na spotkaniu tym usprawnieniowym.

Kuba: Druga wskazówka, co do przygotowania się do samej Retrospektywy takiej wielozespołowej, to przygotuj uczestników przed spotkaniem. Tak jak powiedziałem, na wstępie to nie może się odbyć z marszu, może się tak zdarzać na tego typu spotkaniach, że udział w nich biorą osoby, które niekoniecznie mają zwyczaj pracy poprzez ciągłe doskonalenie, czy usprawnianie się, czy właśnie takie skcrumowe Retrospektywy Sprintów. To mogą być uczestnicy z różnych poziomów organizacyjnych. W poprzednim punkcie rekomendowaliśmy, żeby to były właściwe decyzyjne osoby, więc być może na spotkaniu będziemy mieli dyrektora infrastruktury, albo szefową prawników. Więc to też mogą być osoby, które nie tylko nie są do końca zaznajomione w ogóle ze zwyczajami i praktykami tego typu, ale nawet nie za bardzo mogą też się czuć komfortowo, albo inni uczestnicy mogą się czuć niekomfortowo z ich udziałem.Tutaj dobrą praktyką i dużo wartości przynosi to, żeby być może z kluczowymi, a może z wszystkimi uczestnikami odbyć pewną serię rozmów przygotowawczych, wyjaśnić to, co będzie się działo, zachęcić do pewnej otwartości, wykonać szereg zakulisowej pracy, takiej też wzmocnieniowej, żeby pewne osoby się odzywały tyle, ile trzeba, żeby pewne osoby otwarcie wypowiedziały swoje zdanie, a być może inne osoby takie znane z tego, że są bardzo aktywne, albo wręcz nadaktywne, żeby też troszkę wyprzedzająco może poprosić o to, żeby dały przestrzeń pozostałym uczestnikom tego typu spotkania.

Jacek: Warto tutaj pamiętać, że konkretne osoby mogą nie mieć też dobrych doświadczeń z tego typu spotkaniami. Warto powiedzieć i podzielić się tym, jaki mamy plan na to wydarzenie, pokazanie też dobrego planu, wykazanie dobrego przygotowania, jest też dobrą zachętą dla tych osób. Na zasadzie jest ok, że poświęcę czas na coś, co jest dobrze ogarnięte od strony czy logistycznej, czy samej struktury. To, co może być pomocne, z czym warto, żeby konkretne osoby pojawiły się na takim wydarzeniu, to są sensownie przygotowane dane. Jeżeli temat takiej Retrospektywy wielozespołowej jest znany, wiemy, dlaczego chcemy się spotykać, a powinniśmy wiedzieć, no to jest spora szansa, że są w organizacji jakieś konkretne dane, które jesteśmy w stanie wyciągnąć, czy to dotyczące procesu, czy to dotyczące technologii, czy to dotyczące produktu, które mogą być fajną podpórką do rozmowy, w szczególności w sytuacji, kiedy rozpocznie się dyskusja na temat tego, jakie coś jest, czy proces jest taki, czy jest inny. No, w takiej sytuacji wyciągnięcie danych może być bardzo dobrym punktem odniesienia do tego, żeby taką dyskusję wprowadzić na sensowne tory.

Kuba: I te dane możesz wyciągać ty, jako osoba prowadząca takie spotkanie, ale jeszcze lepiej, jeśli się wyraźnie poprosi odpowiednich uczestników o to, żeby się przygotowali ze swojej części, ze swojego obszaru, ze swojego procesu, ze swoją perspektywą. To powoduje najczęściej też taką bardzo dobrze ugruntowaną rozmowę o konkretach, a nie o widzimisie albo jakiś takich subiektywnych opiniach różnych osób.

Jacek: Kolejny punkt, zapewnij wsparcie wyższego managementu. Mamy tutaj na myśli pewną pracę, warto wykonać z osobami, które z racji funkcjonowania na wyższym poziomie struktury mają pewną moc sprawczą w zależności od tego, w jakiej roli czy jaką odpowiedzialność mają w organizacji. Warto uprzedzić takie osoby, żeby poważnie potraktowały to, z czym przyjdą ludzie po takiej Retrospektywie. Zachęć do tego, żeby wysłuchać, co takie osoby mają do powiedzenia. No bo myślę, że mało rzeczy jest mniej motywujących niż to, że efektem spotkania będą bardzo fajne, konkretne pomysły, które będą wymagały wsparcia wyższego managementu. No i odbicie się od takiego nieprzygotowanego managera, który albo to potraktuje mało poważnie, albo tak dosyć zdawkowo, albo będzie zupełnie zaskoczony, że dlaczego i po co, albo jeszcze skomentuje, dlaczego mnie tam nie było. No może być niemiłym zaskoczeniem. Wyobrażam sobie, że może wygenerować jeszcze jakieś dodatkowe problemy. Dlatego ta praca, żeby top management czy wyższy management był przygotowany jest do wykonania i warto sobie taką pracę planować.

Kuba: Wiąże się ta kwestia pośrednio z koncepcją Circle of Influence, o którym niedawno nagrywaliśmy, 126. odcinek. Tutaj jest prawdopodobne, że uczestnicy spotkania usprawnieniowego, nawet jeśli dobrze dobraliśmy grupę, dobrną do sfery, którą uznają za coś, co jest już poza ich wpływem. Dobrze jest mieć z góry ustawione to wsparcie wyższego managementu, żeby jako prowadząca osoba mógł na przykład zachęcić grupę i tak rozmawiałem z przykładowym Markiem albo z przykładową Iwoną i ona chce, żebyśmy przyszli z jakimiś punktami, z jakimś planem, z jakąś propozycją, z jakąś analizą i zostaniemy wysłuchani, zostaniemy gdzieś tam potraktowani serio. To bardzo pozytywnie wpływa na sukces spotkania usprawnieniowego, a prawdopodobnie w ogóle dobrze też wpływa na taką fajną relację między wyższym managementem a tym szczeblem średnim, czy szczeblem specjalistów. Nie będziemy się na temat Circle of Influence tutaj dalej rozwodzić, ale mocno polecam ten materiał do znalezienia pod adresem porzadnyagile.pl/126.

Kuba: Czwarta wskazówka na temat przygotowania dobrej wielozespołowej retrospektywy to uwzględnij, że będziesz potrzebować więcej czasu. To jest porada dla osób, które mają już jakąś wprawę z przygotowywaniem tego typu spotkań, ale do tej pory działały wyłącznie w realiach jednego zespołu, może ewentualnie jednego zespołu z dodatkowymi kilkoma zaproszonymi gośćmi. Jeśli zaprosisz reprezentację wielu zespołów, reprezentację też zespołów jakichś procesowych albo wsparciowych, może się okazać, że z automatu się nie wyrobisz w czasie, jakiekolwiek limity czasowe się rozjadą i najgorszy scenariusz to to, że na przykład ze spotkania ludzie zaczną wychodzić, zanim dojdziemy do jakiejś konkluzji, no bo zaplanowane było na przykład na godziny albo dwie, więc już czas iść dalej i przełączyć się na inne spotkania albo wejść do innej sali spotkaniowej. Tutaj bardzo mocno przestrzegamy albo pozytywnie zachęcamy do tego, żeby sobie wziąć dużą poprawkę na to, że tego typu spotkania trwają o wiele wolniej. Uczestnicy mają ochotę dużo wypowiedzieć swojej perspektywy, podzielić się danymi, które przygotowali. To też wymaga pewnej struktury, pewnych kroków, przejścia pewną rutynę. To wszystko może trwać o wiele, wiele wolniej, więc z góry bym założył, że co najmniej dwa razy więcej niż ze zwykłej Retrospektywy, a jeśli firma i zespoły mogą sobie na to pozwolić, to może nawet i jeszcze, jeszcze więcej. Więc tutaj z automatu mówimy raczej o wydarzeniach, które raczej trwają pół dnia, może sześć godzin, w zależności oczywiście od tej skali i liczby uczestników i istotności dla firmy i to niestety jest nieodłączny koszt tego typu dużych wydarzeń. Liczymy na to, że to wszystko zostanie zamienione w inwestycje, w usprawnienie, więc to warto takie wydarzenia robić. Doświadczenie pokazuje, że dużo dobrych rzeczy się z tego staje, ale jednak nie przegap tego momentu, że trzeba zaplanować dużo czasu.

Jacek: I tutaj taka pułapka jest po drodze, że może, nawet jeśli to będą tylko reprezentanci różnych obszarów czy zespołów, no to może nie będzie to aż tak liczna grupa, co może skłonić do tego, żeby ten czas jednak nie wydłużać, zostawić taki domyślny. Natomiast będą prezentowane różne, odmienne perspektywy. To często mogą być perspektywy osób z różnych obszarów. To może być osoba ze sprzedaży, to może być osoba z DevOpsów i osoba z HR-u na przykład. No i te perspektywy, żeby dobrze zrozumieć, no to po prostu trzeba poświęcić trochę więcej czasu. Osoba, która tłumaczy jakiś temat, który może nie być do końca jasny dla pozostałych osób, a powinien być, no po prostu będzie musiała ten temat opowiedzieć, wyjaśnić, mogą się pojawić i zapewne pojawią się jakieś dodatkowe pytania. No i naprawdę tak generalnie to z każdą osobą czy z każdą specjalizacją, która się pojawi, może być ta sama historia. Jeżeli chcemy podjąć sensowne decyzje, to musimy dobrze zrozumieć, jaka jest sytuacja. No i niestety póki co nie ma lepszych sposobów niż posłuchanie, co druga strona ma do powiedzenia i upewnienie się, że dobrze rozumiemy, co chce nam przekazać.

Jacek: Kolejna wskazówka, nadaj kontekst i przypomnij cel usprawniania się. W szczególności przed tak istotnymi spotkaniami warto zadbać o to, żeby na samym początku powtórzyć, po co tak naprawdę się spotykamy, jaki jest tego cel, ale też być może wytłumaczyć, dlaczego w ogóle warto się usprawniać. To jest świetne miejsce na Twoje exposé, krótkie wprowadzenie, zwięzłe, przypominające te najistotniejsze aspekty, które wymieniłem. Możesz też sięgnąć po osobę, która jest wyżej od Ciebie w hierarchii i będzie to przy okazji takie dodatkowe umocowanie tego wydarzenia na zasadzie ja jako osoba z top managementu czekam na wyniki, życzę Wam powodzenia. Skupcie się na tym aspekcie. Działajcie, jestem z Wami. Jak potrzebujecie pomocy, to mówcie. Nawet taka krótka myśl, taka zachęta może być bardzo fajnym paliwem, które będzie potrzebne na pewno na etapie kategoryzowania problemów, analizowania ich i wymyślania sensownych rozwiązań.

Kuba: Ta wskazówka trochę łączy się z wskazówkami o przygotowaniu uczestników przed spotkaniem i o zapewnieniu wsparcia wyższego managementu, bo być może ta wspomniana osoba z wyższego managementu pojawia się na samym początku takiej sesji ustprawnieniowej i prezentuje swoje expose. A nawet jeśli się to nie wydarzy, to wszyscy uczestnicy muszą zrozumieć cel i sens tego spotkania i rozumieć, dlaczego je zwołujemy. Mówię to również z tą świadomością gorszych doświadczeń pracy tego typu. Coraz częściej spotykam osoby, które dosyć nerwowo albo alergicznie reagują na pomysł tego typu spotkania. Zróbmy na ten temat międzyzespołowe retro, bo np. były te osoby już uczestnikami takiego dosyć chaotycznego spotkania, które niewiele wniosło, ale za to np. wycięło krytyczny moment tuż przed wdrożeniem albo w jakiś moment w projekcie, gdzie trochę szkoda było zmarnować się pół dnia roboczego wielu uczestnikom. Więc tutaj pewnego rodzaju expose, pewnego rodzaju nastawienie na cel, pewnego rodzaju obietnice co do tego, po co to wszystko tutaj realizujemy. Jest bardzo potrzebna i jest też takim punktem odniesienia do tego, żeby całe spotkanie przebiegało w takim nastroju konstruktywnego, doskonalenia się, poprawiania tego jak działa ten zespół, ta grupa zespołów, ten produkt czy może przyszłe projekty, które będą też realizowane w podobnym składzie osobowym.

Kuba: I przedostatnia wskazówka to zadbaj o klarowną instrukcję odnośnie przebiegu spotkania. Już parę razy powiedzieliśmy, że prawdopodobne jest to, że uczestniczyć w takim spotkaniu będą osoby, które albo rzadziej uczestniczą w spotkaniach usprawnieniowych czy Retrospektywach, może jeszcze w ogóle nigdy nie uczestniczyły w czymś takim, no i zwłaszcza jeśli grupa jest liczna, jeśli są też mocne charaktery, jeśli są też osoby, które mają jakiś interes, bo ich zespół jakoś cierpi na jakiejś niedoskonałości, to może spowodować spore zamieszanie i nawet jeśli to nie jest zamieszanie w takim rozumieniu, że ludzie się przekrzykują, to może być trudno uczestniczyć w takim spotkaniu osobom, które w tym spotkaniu rzadziej zazwyczaj biorą udział. Dlatego to Twoją rolą jako osoby prowadzącej takie spotkanie usprawnieniowe jest takie przekazanie instrukcji, żeby wszyscy je rozumieli, żeby one były jasne, żeby można się było ich trzymać. Ważne też oczywiście, żeby później pilnować ich przestrzegania przez wszystkich uczestników, ale to jest sfera w skrócie, którą warto przygotować, być może nawet dosłownie mieć notatkę, mieć jakąś podpowiedź dla samego siebie czy samej siebie, żeby te instrukcje były precyzyjne, wsparte też być może jakąś wizualizacją, żeby wszyscy uczestnicy wiedzieli, czego się od nich oczekuje, co mają teraz robić, gdzie zapisać, gdzie postawić kropkę, gdzie postawić jakąś strzałkę czy cokolwiek, czego od nich oczekujemy.

Jacek: I to, że takie rzeczy dzieją się na autopilocie w Twoim zespole wcale nie oznacza, że zadziała to tak samo w tej grupie. W zespole możesz bazować już na pewnych doświadczeniach, na pewnych skrótach myślowych, ludzie już właściwie wiedzą trochę, czego się spodziewać, nawet jak ta struktura się zmienia, po prostu przyzwyczają się do twojego stylu. Natomiast warto pamiętać, że to, co różne zespoły czy różne osoby w firmie nazywają Retrospektywą, to może być coś zupełnie innego. Przykładowo w jednej z organizacji, którą aktualnie wspieram, Retrospektywa to jest spotkanie, które tak naprawdę prowadzi lider, pyta się jak jest. Właściwie, zaraz ma na to odpowiedź, dominuje, jest go tam dużo. Dla ludzi, którzy są tam zaproszeni, Retrospektywa to jest przykry obowiązek, gdzie właściwie ich zdanie jest marginalizowane, to spotkanie nie kończy się usprawnieniami. Mogą wejść na to spotkanie też z takim nastawieniem i w szczególności te instrukcje, które będziesz kierował czy kierowała, mogą wymagać takiego bardzo spokojnego i klarownego przekazania, bo mogą to być dla pewnych osób nowe rzeczy.

Jacek: I ostatnia porada, umów się na zasady monitorowania ustaleń. To, że z takiego wydarzenia chcemy wyjść z czymś konkretnym, to jest jedno. I tutaj pomaga dobra struktura, o której mówiliśmy na początku odcinka, jak również wszystkie te punkty, które dotychczas pokryliśmy. Natomiast druga sprawa jest taka, że o wiele trudniej jest monitorować ustalenia, kiedy mamy grupę, która najprawdopodobniej zaraz się rozproszy i wróci do swoich działów, departamentów czy zespołów. W takich przypadkach jest o wiele trudniej, o jakiś taki sensowny follow-up do tych akcji, które ustaliliśmy. Stąd istotne jest, dodatkowo umówić się, w jaki sposób będziemy te zasady monitorować. Może będzie konieczne ustalenie tutaj jakichś takich punktów styku, gdzie będziemy się synkronizować, może to jest kwestia ustalenia jakichś zasad komunikacji, może na jakimś kanale będziemy się po prostu dedykowanym update’ować, co udało się zrobić, a może w jakiś inny sposób ustalisz uczestnikami, jak zadbać o to, żeby te rzeczy, które ustalicie, żeby wam nie zeszły z radaru.

Kuba: Tych rozwiązań jest wiele, ale najlepiej byłoby mieć swój własny pomysł czy swój własny program, zanim ta rozmowa w ogóle na spotkaniu zacznie się dziać, bo prawdopodobnie blisko końca takiego spotkania, gdy już wszyscy będą zmęczeni, dopiero wtedy odkrywanie i negocjowanie i ustalanie, czy zakładamy kanał na Teams’ie, czy może jednak zwołujemy jeszcze nowe spotkanie, to może być już za dużo dla wszystkich. To jest to miejsce, gdzie być może możesz za wszystkich zadecydować, a może chociaż mieć swoją konkretną, w miarę spójną, kompletną propozycję, co wybieramy, co jest takie powiedzmy dopasowane do realiów twojej firmy czy Twojej części firmy, jeśli mówimy o naprawdę dużej organizacji. Więc tutaj miej swój pomysł, zaproponuj go grupie, na pewno nie pozwól na coś takiego, że po prostu na pewno wszyscy się wywiążą, bo niestety to, co Jacek powiedział, ludzie się rozejdą, rozproszą i może się okazać, że całkiem fajne pomysły, całkiem rzeczowe, konkretne kroki, po prostu mogą się rozejść po kościach, tylko dlatego, że się nie umówiliśmy na termin, nie umówiliśmy się na sprawdzenie, nie umówiliśmy się być może na jakieś dodatkowe połączenie i wymianę perspektyw, zwłaszcza dla bardziej złożonych kwestii.

Kuba: Podsumowując, jak dobrze przygotować się do spotkania usprawnieniowego wielu zespołów? Zaproś osoby, które mogą podejmować decyzje. Przygotuj uczestników przed spotkaniem. Zapewnij wsparcie wyższego managementu.

Jacek: Uwzględnij, że będziesz potrzebować więcej czasu. Nadaj kontekst i przypomnij cel usprawniania się. Zadbaj o klarowną instrukcję odnośnie przebiegu spotkania i umów się na zasady monitorowania ustaleń.

Kuba: W temacie skalowanego retro możemy wesprzeć swoją firmę na wiele sposobów. 

Jacek: Mamy webinar, o którym wspominaliśmy już wcześniej w odcinku, który na bardzo dużym poziomie szczegółowości pokrywa temat organizacji Retrospektywy, która faktycznie przynosi sensowne rezultaty.

Kuba: Możemy też przygotować dla Ciebie lub Twoich ludzi warsztat o tym, jak się przeprowadza tego typu spotkanie, poszerzając te wątki, które wymieniliśmy i być może dopasowujący pewne aspekty, które będą specyficzne dla Twojej sytuacji.

Jacek: Możemy też wejść w rolę prowadzącego takie spotkanie, czyli zadbać o to, żeby zostały one przeprowadzone porządnie, zwłaszcza jeśli w Twojej firmie przeprowadzenie takiego spotkania jest wyzwaniem.

Kuba: Realizujemy również superwizję tego typu wydarzeń i dzielimy się po ich przebiegu informacją zwrotną, traktując to jako pewien program rozwojowy dla liderów, którzy przeprowadzają tego typu sytuacje.

Jacek: Jeżeli Twoje zespoły potrzebują wsparcia na efektywnych, skalowanych spotkaniach usprawnieniowych, odezwij się do nas poprzez formularz na stronie porzadnyagile.pl/kontakt.

Kuba: Notatki do tego odcinka, artykuł, transkrypcję naszej rozmowy, zapis wideo znajdziesz na stronie porzadnyagile.pl/134.

Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek. I do usłyszenia wkrótce.

________

To była pełna transkrypcja odcinka podcastu Porządny Agile. Dziękujemy za lekturę!

Ostatnia aktualizacja: 25 września 2025

Gdzie powinno znajdować się właścicielstwo produktowe w organizacji? W IT? W biznesie? A może to temat, który wymaga zupełnie innego podejścia? Poznaj różne modele umiejscowienia odpowiedzialności za produkt i analizę ich wpływu na współpracę zespołów, podejmowanie decyzji i skuteczność wdrażania strategii. Sprawdź, w którym miejscu na osi znajduje się Twój zespół i oceń, czy można w tej kwestii uzyskać usprawnienia.

Pisząc o właścicielstwie produktowym, mamy na myśli miejsce w strukturze organizacyjnej, w którym znajdują się osoby zarządzające produktem, a także ich podległość służbowa. W zależności od firmy, mogą to być Product Ownerzy, Product Managerowie lub specjaliści odpowiedzialni za rozwój funkcjonalności. Niektóre organizacje te stanowiska nazywają inaczej, jednak ich rola pozostaje zbliżona.

W niektórych organizacjach stanowiska te mogą mieć inne nazwy, na przykład specjaliści ds. rozwoju funkcjonalności lub podobne role. Nie będziemy tutaj szczegółowo wymieniać wszystkich możliwych wariantów, ale na potrzeby tego tekstu będziemy używać określeń Product Owner i Product Manager, mając na myśli także inne, podobne stanowiska.

Spis treści

• Możliwe modele umiejscowienia właścicielstwa produktowego
• Brak jasnego właścicielstwa 
• Zarządca Backlogu w IT
• Zarządzanie produktem po stronie IT
• Podwójne właścicielstwo 
• Zarządzanie produktem po stronie biznesowej 
• Umocowane zespoły produktowe
• Jak w praktyce podejść do zmiany właścicielstwa produktowego?
• Zdefiniuj gdzie jesteś
• Ustal jakich rezultatów oczekujesz po zmianie
• Określ argumenty przemawiające za utrzymaniem obecnego stanu rzeczy
• Narysuj mapę sojuszników i przeciwników zmiany 
• Myśl o strukturze jak o żyjącym bycie, a nie finalnym ustawieniu
• Przyjmij, że lepsze jakiekolwiek właścicielstwo niż jego brak
• FAQ: Właścicielstwo produktowe – w Biznesie czy w IT?
• 📄 Transkrypcja podcastu „Właścicielstwo produktowe – w Biznesie czy w IT?”

W różnych organizacjach spotykamy różne modele umiejscowienia właścicielstwa produktowego. Czasami te osoby znajdują się po stronie IT lub technologii, co oznacza, że są częścią zespołu technologicznego i współpracują głównie z działem inżynieryjnym. W innych przypadkach są przypisane do działu biznesowego, gdzie ich rola koncentruje się na strategii i rozwoju produktu z perspektywy rynku. Istnieją też organizacje, w których właściciele produktu funkcjonują jako osobna struktura, często podlegająca bezpośrednio zarządowi.

Przeanalizujemy najczęściej spotykane modele i omówimy, jakie konsekwencje niesie za sobą każdy z nich. Nie chodzi o wskazanie, który układ jest najlepszy, ale o przedstawienie, z czym wiąże się każda z tych opcji.

Pierwszym punktem na tej osi, od którego warto zacząć, jest sytuacja, w której właścicielstwo produktowe nie jest wyraźnie zdefiniowane. Oznacza to, że trudno wskazać, w jakim konkretnym obszarze organizacji się znajduje – czy jest po stronie IT, czy po stronie biznesu.

Jak rozpoznać taki stan rzeczy? Najczęściej przejawia się to w braku spójnej odpowiedzialności za decyzje. Praca nad produktem odbywa się głównie poprzez realizację losowych zleceń, które przychodzą z różnych źródeł. W skrajnym przypadku taka sytuacja prowadzi do równoległego funkcjonowania wielu inicjatyw, projektów i zmian, które nie są ze sobą skoordynowane. Efektem tego jest ich wzajemna konkurencja, a nawet wykluczanie się nazwajem.

W rzeczywistości zawsze znajdzie się ktoś, kto podejmie decyzję, w jakim kierunku mają podążać zespoły wytwórcze. Problem pojawia się wtedy, gdy jest to osoba, która podejmuje decyzje z konieczności, a nie z faktycznej odpowiedzialności za produkt.

Często rolę tę przejmuje ktoś bez kontekstu biznesowego, kto skupia się wyłącznie na priorytetyzacji zadań w sposób reaktywny, na przykład minimalizując ryzyko niezadowolenia różnych interesariuszy. W praktyce oznacza to, że lider zespołu czy inna osoba pełniąca tę rolę nie kieruje się myśleniem produktowym, lecz stara się jedynie zbalansować różne zlecenia, projekty i zmiany, tak by uniknąć problemów.

Podkreślamy to, ponieważ model, w którym nie ma wyraźnego właścicielstwa produktowego, ma głównie wady. Rozumiemy, że niektóre organizacje mogą się w takim stanie znajdować, ale jest to sytuacja, którą warto zmienić. 

Jest to krok w dobrą stronę, ponieważ w organizacji pojawia się osoba, którą można wskazać jako odpowiedzialną za zarządzanie pracami zespołu. Może to być Product Owner, lider zespołu, a czasem nawet Product Manager, choć w tym przypadku nazewnictwo bywa różne. Taka osoba znajduje się po stronie IT, jest częścią konkretnego zespołu, albo funkcjonuje w niewielkiej strukturze w ramach działu technologii. Jej rola polega na zbieraniu inicjatyw i zleceń od interesariuszy biznesowych, organizowaniu projektów oraz przekazywaniu ich do zespołu.

Jednak w tym modelu kluczową kwestią jest to, że osoba zarządzająca Backlogiem nie tworzy produktu ani nie ma realnego wpływu na jego kształt. Jej rola sprowadza się do koordynowania przepływu zadań i dbania o ich realizację, ale bez faktycznej sprawczości produktowej.

Należy zaznaczyć, że w tym artykule, nawet gdy używamy określeń takich jak Backlog czy Product Owner, nie odnosimy się stricte do Scruma. Te pojęcia na tyle mocno przeniknęły do firm, że stały się naturalnym sposobem opisywania ról i procesów w organizacjach.

W przypadku modelu zarządcy Backlogu kluczowe jest to, że taka osoba nie podejmuje decyzji o tym, co zostanie zrealizowane. Jej rola sprowadza się raczej do biernego wykonywania oczekiwań interesariuszy, bez realnego wpływu na kształt produktu. 

Warto uczciwie przyznać, że rola zarządcy Backlogu w IT, mimo swoich ograniczeń, ma pewne zalety w porównaniu do modelu, w którym właścicielstwo produktowe w ogóle nie istnieje. Przede wszystkim daje szansę na ucywilizowanie strumienia prac, na uporządkowanie zgłaszanych inicjatyw, minimalną dyskusję z interesariuszami oraz ewentualne grupowanie lub dzielenie inicjatyw w bardziej sensowne części. 

Trzeci model to zarządzanie produktem po stronie IT. W przeciwieństwie do wcześniejszego podejścia, w tym przypadku mamy już wyraźnie określoną rolę, którą można nazwać Product Ownerem. Nie jest to jedynie osoba pasywnie realizująca oczekiwania interesariuszy, lecz ktoś, kto rzeczywiście zarządza produktem. Może posiadać własną wizję, roadmapę, a nawet określone wskaźniki mierzące postęp.

Choć taka osoba nadal funkcjonuje w strukturach IT i musi uwzględniać potrzeby różnych interesariuszy, to jednak jej rola wykracza poza mechaniczne realizowanie napływających zadań. W tym modelu pojawia się już myślenie długofalowe, a decyzje dotyczące produktu zaczynają być bardziej świadome i strategiczne.

Jest to model, w którym zarządzanie produktem staje się aktywne i opiera się na realizacji konkretnej wizji. Osoba odpowiedzialna za produkt może mieć realny wpływ na kierunek jego rozwoju, a nawet prawo do odrzucania niektórych pomysłów czy oczekiwań poszczególnych interesariuszy. Dzięki temu możliwe jest skupienie się na priorytetach i konsekwentne podążanie za przyjętą strategią, zamiast realizowania przypadkowych zachcianek.

Po stronie korzyści znajduje się możliwość konsekwentnej realizacji spójnej wizji. W niektórych produktach ma to kluczowe znaczenie, ponieważ pozwala eliminować przypadkowe inicjatywy i skupić się na istotnych aspektach. Istnieje jednak ryzyko oddalenia się od kontekstu biznesowego, strategii firmy czy współpracy z działami takimi jak sprzedaż, marketing czy wsparcie klienta.

Dodatkowym zagrożeniem jest skłonność do preferowania rozwiązań technologicznych. Często pojawiają się zarzuty, że osoby zarządzające produktem od strony IT wybierają priorytety w postaci migracji systemu, aktualizacji technologii czy pełnej refaktoryzacji, zamiast dostarczenia nowych funkcji, które mogłyby przełożyć się na korzyści biznesowe.

Jednocześnie są produkty, w których taki model jest optymalny. W szczególności dotyczy to rozwiązań technologicznych, produktów infrastrukturalnych lub firm dostarczających wysoce zaawansowane technologie, gdzie naturalnym miejscem dla zarządzania produktem pozostaje struktura IT.

Model czwarty, umiejscowiony dokładnie na środku omawianej osi, to podwójne właścicielstwo. Niektóre organizacje, często pod wpływem doradców i firm konsultingowych, zdecydowały się na takie rozwiązanie, aby uniknąć dylematu dotyczącego umiejscowienia właścicielstwa produktowego.

W tym modelu funkcjonuje dwóch właścicieli produktu – jedna osoba po stronie biznesu i druga po stronie technologii. W założeniu ma to pozwolić na podział odpowiedzialności: osoba z biznesu wnosi perspektywę strategiczną i rynkową, natomiast właściciel techniczny dba o kwestie funkcjonalne, bezpieczeństwo, wydajność oraz długoterminowe koszty utrzymania systemu. Chodzi o to, aby uzupełnić kompetencje i zapewnić, że kluczowe aspekty produktu nie zostaną pominięte.

W praktyce oznacza to, że w tym modelu istnieje dwóch Product Ownerów, którzy muszą wspólnie podejmować decyzje dotyczące rozwoju produktu. Ich stanowiska mogą różnie się nazywać, jednak istotą rozwiązania jest konieczność uzgadniania priorytetów i współdecydowania o kierunku działań. To może prowadzić zarówno do lepszego bilansu interesów, jak i do potencjalnych wyzwań związanych z procesem decyzyjnym.

Gdybyśmy mieli wskazać największe zagrożenie lub ryzyko tego modelu, to na pewno byłby to dualizm decyzyjny. W skrajnym, negatywnym scenariuszu dwie osoby odpowiedzialne za produkt mogą nie współpracować, wysyłać zespołowi sprzeczne sygnały i ciągnąć produkt w różnych kierunkach.

Mocny przedstawiciel biznesu może ignorować potrzeby technologiczne, na przykład zaniedbywać spłatę długu technologicznego lub odkładać aktualizację bibliotek czy frameworków, które wymagają zmian ze względów bezpieczeństwa. Z kolei dominujący lider techniczny może skupić się wyłącznie na aspektach technologicznych, zaniedbując potrzeby biznesowe, co w efekcie może hamować rozwój produktu w kontekście rynkowym.

Kolejny model, który przybliża nas do przeciwnego końca osi, to zarządzanie produktem po stronie biznesowej. W tym przypadku za produkt odpowiada osoba o silnym profilu biznesowym – może to być Product Manager lub Product Owner wywodzący się z biznesu. Taka osoba ma pełne zrozumienie produktu i patrzy na niego w szerszym kontekście – nie traktuje go jedynie jako aplikacji czy rozwiązania technologicznego, ale jako część większego ekosystemu.

Taki lider rozumie, po co istnieje produkt, jaki jest jego cel i jakie wartości ma dostarczać. Dzięki temu wnosi do zespołu głęboką perspektywę biznesową. Jeśli do tej pory zespołowi brakowało takiego kontekstu, to taka osoba potrafi w stosunkowo krótkim czasie przekazać go zespołowi, pokazując, dlaczego realizowane działania są istotne. Dzięki temu praca zespołu nabiera nowego sensu i głębszego znaczenia, co może pozytywnie wpłynąć na jego zaangażowanie i motywację.

Nadal istnieje wyraźne rozróżnienie – jest ktoś, kto posiada wiedzę, ma dostęp do strategii i zarządu, i to ta osoba przekazuje ją zespołowi. Oczywiście można to zrobić w odpowiedni sposób, z dbałością o współpracę, ale wciąż występuje dynamika, w której jedna strona ma pełne zrozumienie kontekstu i decyduje o kierunku działań, a druga strona te decyzje realizuje. Nadal można to ulepszyć, a poniżej wyjaśniamy w jaki sposób.

W wielu organizacjach ten model ma również swoje zalety, ponieważ wzmacnia mechanizm wspólnej odpowiedzialności zarówno struktur biznesowych, jak i technologicznych. Strona biznesowa decyduje o priorytetach, podczas gdy technologia zajmuje się sposobem realizacji, efektywnością i produktywnością zespołu. Wszyscy są w ten proces zaangażowani, a ewentualne korekty wymagają współpracy menedżerów ze wszystkich obszarów organizacji.

W porównaniu do wcześniejszych układów mamy tutaj interdyscyplinarny zespół, który łączy kompetencje produktowe, biznesowe, technologiczne oraz szeroko rozumiane wsparcie. Członkowie zespołu wspólnie tworzą rozwiązania, a ich role nie są wyraźnie rozgraniczone według pionów organizacyjnych – w praktyce trudno określić, kto reprezentuje którą część organizacji.

Wszyscy zaangażowani uczestniczą zarówno w fazie kreatywnej, jak i w realizacji. Nadal istnieje funkcja lidera produktu, jednak jego rola jest bardziej włączająca – nie przynosi on gotowych rozwiązań, lecz współpracuje z resztą zespołu i podejmuje ostateczne decyzje. W efekcie granica między biznesem a technologią zaciera się, a cały zespół działa wspólnie, dążąc do realizacji strategii i wizji produktu.

Gdyby wskazać ryzyka czy słabsze strony tego modelu, to największym problemem jest jego realna trudność w osiągnięciu. Wymaga on istotnych zmian na poziomie mentalnym organizacji. Wymaga też innego profilu kompetencyjnego u członków zespołu – najlepiej sprawdzają się osoby o profilu T, cechujące się dużą otwartością.

W takich zespołach trudno jednoznacznie określić, kto pochodzi z jakiego działu. Przykładowo, o użyteczności aplikacji może wypowiadać się zarówno tester, jak i developer, a niekoniecznie osoba dedykowana do obszaru UX. Jest to kosztowny model, a jeśli nie funkcjonował od samego początku istnienia firmy, to jego wdrożenie może być trudne i bolesne.

Dla organizacji, które znajdują się na wcześniejszych etapach naszej osi i nie mają jeszcze jasno określonego właścicielstwa produktowego, przejście na ten model może być zbyt dużym skokiem. Mogą pojawić się pytania i wątpliwości dotyczące odpowiedzialności, co wymaga dużych zmian mentalnych i kulturowych w organizacji.Jeśli chcesz pogłębić wiedzę jeszcze bardziej, możesz znaleźć nasze płatne materiały na stronie porzadnyagile.pl/sklep

Pierwsza porada jest dość prosta – określ, w jakim miejscu się znajdujesz. Sprawdź, gdzie na przedstawionej przez nas osi lub na własnej, jeśli masz inne podejście, plasuje się Twoja organizacja. Warto oprzeć się nie tylko na własnej intuicji, ale także zebrać opinie zespołów, interesariuszy biznesowych i managerów, aby uzyskać pełniejszy obraz sytuacji. Jednym z największych zagrożeń jest błędne postrzeganie własnej organizacji – gdy wydaje się, że jest się na poziomie 5 lub 6, podczas gdy w rzeczywistości firma dopiero osiągnęła poziom 2. Każdy model wymaga odrębnej strategii zmiany, dlatego kluczowe jest dokładne zrozumienie punktu wyjścia.

Ma to szczególne znaczenie w większych organizacjach, gdzie różne zespoły mogą znajdować się na różnych etapach dojrzałości produktowej. Często zdarza się, że w jednej firmie istnieją zespoły bardziej progresywne, funkcjonujące w sprzyjającym środowisku, podczas gdy inne obszary wciąż pozostają na wcześniejszym etapie rozwoju. Firmy obsługujące różne rynki czy posiadające wiele linii biznesowych mogą mieć odmienne potrzeby i poziom zaawansowania, co wymaga szczególnej uwagi przy planowaniu zmian.

Dlatego kluczowe jest właściwe określenie punktu startowego, aby nie narzucać zbyt ambitnych zmian, które w niektórych obszarach mogą okazać się nierealne – np. jeśli firma nigdy nie miała jasno określonego właścicielstwa produktowego, próba natychmiastowego wdrożenia zespołów produktowych może być zbyt dużym skokiem i zakończyć się fiaskiem.

W praktyce może to oznaczać, że wprowadzane zmiany nie obejmą całej organizacji, lecz będą dotyczyć wybranego fragmentu struktury. Może to być konkretny obszar, określony value stream lub inna jednostka organizacyjna funkcjonująca w Twojej firmie. W takiej sytuacji zmiana będzie miała bardziej ograniczony zasięg, niż początkowo można by zakładać.

Warto określić spodziewane efekty w sposób jak najbardziej konkretny i mierzalny. Im precyzyjniejsze wskaźniki, tym łatwiej będzie ocenić skuteczność przeprowadzanych działań. Przykładem takich mierników mogą być lead time lub cycle time, czyli – upraszczając – czas od pomysłu do realizacji lub czas od rozpoczęcia pracy do jej zakończenia. To aspekty, które można stosunkowo łatwo zmierzyć i śledzić w czasie.

Jednak oprócz mierzalnych parametrów warto uwzględnić również czynniki trudniejsze do ujęcia w liczbach, ale mające istotny wpływ na funkcjonowanie organizacji. Przykładem mogą być odczucia zespołów dotyczące sensu ich pracy czy subiektywna ocena realizacji potrzeb biznesowych. Choć trudno je wyrazić w konkretnych wartościach liczbowych, nadal stanowią istotne aspekty, które warto uwzględnić jeszcze przed rozpoczęciem procesu zmiany.

Istnieją organizacje, w których pomiary są na wysokim poziomie, co pozwala na wybór odpowiednich wskaźników do monitorowania oraz określenie poziomu aspiracji i oczekiwanych rezultatów po wprowadzeniu zmian. Jednak nie wszystkie firmy dysponują dobrze rozwiniętym systemem mierników, co może utrudniać ocenę efektów transformacji.

W takich przypadkach warto rozważyć wdrożenie nowych metod pomiaru jako element zmiany w zakresie umiejscowienia właścicielstwa produktowego czy funkcjonowania zespołów produktowych. Może to obejmować wykonanie pomiaru bazowego przed wprowadzeniem zmian, aby później, po ich wdrożeniu i ustabilizowaniu, możliwe było dokonanie rzetelnego porównania. Przykładem takiego podejścia może być mierzenie poziomu satysfakcji ze współpracy w zespołach – przeprowadzenie ankiety przed i po zmianie pozwoli określić, czy przyniosła ona oczekiwane rezultaty.

Aby móc realnie ocenić, czy sytuacja się poprawiła, warto z wyprzedzeniem określić, jakie aspekty będą mierzone, oraz przygotować odpowiednie narzędzia do ich monitorowania, zwłaszcza jeśli obecnie firma lub jej część strukturalna nie posiada rozwiniętego systemu pomiarowego.

Trzecia porada może wydawać się nieco przewrotna – określ argumenty przemawiające za utrzymaniem obecnego stanu rzeczy. Warto zastanowić się, co może powodować opór wobec zmiany, ponieważ każda transformacja – zwłaszcza strukturalna – spotka się z pewnym poziomem sprzeciwu. Dotyczy to szczególnie sytuacji, w której właścicielstwo produktowe przechodzi na stronę biznesową, ponieważ taki ruch niesie ze sobą całą pulę potencjalnych wyzwań.

Dobrze jest więc z góry przewidzieć możliwe źródła oporu, określić, jakie argumenty mogą się pojawić przeciwko zmianie i kto może je podnosić. Pozwoli to lepiej zaplanować proces komunikacji, zarówno pod kątem przedstawienia racjonalnych argumentów, jak i opracowania mechanizmów wspierających transformację. Dzięki temu możliwe będzie odpowiednie zarządzanie obawami oraz dostarczenie kontrargumentów lub wskazanie korzyści, które przewyższą potencjalne trudności. Kluczowe jest, aby każdy uczestnik zmiany dostrzegł w niej wartość i miał poczucie, że nowy model przynosi mu konkretne korzyści.

Biznes nie rozumie IT. To często pojawiająca się obawa, która prowadzi do utrzymania status quo – na zasadzie: „My zajmujemy się biznesem, a IT niech robi swoje, i lepiej nie wchodźmy sobie w drogę.”

W takiej sytuacji warto zainwestować w zwiększenie wzajemnego zrozumienia. Osoby rozwijające produkty w firmach technologicznych nie muszą być ekspertami ani umieć programować, ale powinny rozumieć podstawowe aspekty technologiczne i konsekwencje decyzji technicznych. W drugą stronę, osoby odpowiedzialne za technologię powinny znać kontekst biznesowy i rozumieć realne potrzeby użytkowników oraz strategię firmy.

Na rynku istnieją specjaliści, którzy łączą oba światy, ale takie kompetencje można też rozwijać wewnętrznie. Dobrym rozwiązaniem może być także zapewnienie wsparcia w postaci ról takich jak architekt czy Tech Lead, którzy będą partnerami dla osób biznesowych i pomogą im stopniowo lepiej rozumieć kwestie technologiczne.

Biznes i IT nie mówią tym samym językiem, więc musi być ktoś, kto będzie ich tłumaczem. W szczególności dotyczy to modeli, w których Product Owner pozostaje po stronie technologii i pełni funkcję pośrednika. Zwolennicy tego podejścia często argumentują, że tacy Product Ownerzy rozumieją zarówno biznes, jak i technologię, więc lepiej, aby to oni nadal pełnili tę rolę.

To argument, który można skutecznie podważyć. Fakt, że dzisiaj obie strony mogą mieć trudności w komunikacji, nie oznacza, że tak musi pozostać. Zbliżenie biznesu i IT, o którym pisaliśmy w odcinku 130, może w dużej mierze rozwiązać ten problem.

Kluczowe działania to:

Oczywiście, przesunięcie właścicielstwa produktowego do biznesu może oznaczać pewien okres przejściowy, w którym pojawią się tarcia, nieporozumienia czy śmieszne sytuacje wynikające z różnic w interpretacji tych samych terminów. Jednak w dłuższej perspektywie zespół nauczy się efektywnej komunikacji i nie będzie potrzebował tłumacza między dwiema stronami.,

Trzecim często spotykanym argumentem przeciwko zmianie jest przekonanie, że Biznes nie ma czasu na angażowanie się w pracę z zespołami produktowymi. To podejście stanowi istotne ograniczenie. W jednej z firm, z którą mieliśmy styczność, prezes jasno zakomunikował: „Transformujmy się, zmieniajmy, ale osoby z biznesu nie będą pracować z zespołami – nie mają na to czasu”.

Ta decyzja spowodowała, że w rolę Product Ownerów biznesowych weszli Project Managerowie. Było to jakieś rozwiązanie – na pewno lepsze niż brak właścicielstwa produktowego. Jednak brak prawdziwego kontekstu biznesowego sprawił, że zespoły produktowe cierpiały. W praktyce rola Product Ownera została sprowadzona do przekazywania wymagań i pilnowania ich realizacji, a nie do faktycznego zarządzania produktem w sposób uwzględniający potrzeby rynku i strategię firmy.

Czwartym często podnoszonym argumentem przeciwko zmianie jest przekonanie, że tylko technologiczny Product Owner zagwarantuje, że aspekty technologiczne będą odpowiednio priorytetyzowane i zaopiekowane.W niektórych organizacjach towarzyszy temu obawa, że jeśli odpowiedzialność za priorytety zostanie przekazana stronie biznesowej, to wszystkie najważniejsze kwestie technologiczne,  takie jak migracje, automatyzacje czy spłata długu technicznego, zostaną natychmiast odrzucone.

Może pojawić się presja, aby dostarczać rozwiązania szybciej, kosztem jakości i długofalowego utrzymania systemów.Kluczową rolę odgrywa tutaj jasna umowa między liderami technologicznymi a liderami biznesowymi. Organizacja powinna wypracować mechanizmy zapewniające odpowiednią równowagę między potrzebami biznesowymi a koniecznością dbania o stabilność i rozwój technologiczny.Formalna alokacja części przepustowości zespołu na zadania technologiczne. W jednej z organizacji przyjęto zasadę, że 20% zasobów zespołu zawsze jest przeznaczane na kwestie technologiczne.

W takim układzie Product Owner z biznesu może decydować o priorytetach wewnątrz tej puli, ale nie może jej całkowicie wyeliminować. Warto zadbać o przejrzyste Definition of Done, które określa niepodlegający negocjacjom standard jakości. To chroni zespoły przed presją na przyspieszanie kosztem długoterminowej stabilności systemów i pozwala uniknąć scenariusza, w którym „zrobimy to szybko teraz, a poprawimy później” – bo w praktyce często to „później” nigdy nie następuje.

Istnieje wiele sposobów na zabezpieczenie równowagi między biznesem a technologią. Kluczowe jest, aby organizacja świadomie wypracowała model, który pozwoli zaopiekować obie te sfery, zamiast przyjmować założenie, że tylko technologiczny Product Owner może o nie zadbać.

Zachęcamy jednak do samodzielnego przeanalizowania sytuacji w swojej organizacji, ponieważ w Twojej firmie mogą występować inne powody lub dodatkowe obawy, które nie zostały tutaj wymienione.

Nie sposób wyczerpać wszystkich możliwych argumentów, dlatego warto świadomie pochylić się nad tą kwestią, aby zrozumieć, co może powodować opór wobec zmian i jak najlepiej na te obawy odpowiedzieć.

Czwarta porada dotyczy sposobu na skuteczną zmianę właścicielstwa produktowego w organizacji. Zbudowanie mapy sojuszników i przeciwników zmiany pozwala lepiej zrozumieć układ sił i zaplanować działania tak, aby zmiana miała większe szanse powodzenia.

Zdefiniuj kluczowe osoby – zastanów się:

Takie zmiany, zwłaszcza te dotyczące przesuwania odpowiedzialności w strukturze organizacyjnej, często budzą sprzeciw. Ważne jest, aby rozpoznać zależności i wpływy, a następnie budować krąg sojuszników, którzy pomogą przekonać osoby sceptyczne.

Jeśli mówimy o stworzeniu mapy, dosłownie warto ją narysować. Może tu pomóc technika Stakeholder Bottleneck Mapping opisana m.in. w materiale wideo Geoffa Watsa  https://www.youtube.com/watch?v=B_WfnnNUC6o, . To proste narzędzie, które często prowadzi do odkrycia złożonych zależności w organizacji.

Ciekawym wnioskiem może być to, że nawet przeciwnicy zmiany mają w swoim otoczeniu osoby, które na nich wpływają. Może to być przełożony wyższego szczebla, ale też ktoś, kogo opinię dana osoba ceni. Identyfikacja takich powiązań pozwala na bardziej strategiczne działanie – jeśli nie możesz przekonać kogoś bezpośrednio, możesz znaleźć osobę, która ma na niego wpływ.

Warto więc zaplanować sprytną, dyplomatyczną akcję, aby zbudować poparcie dla zmiany i przeprowadzić ją skutecznie.

Przedostatnia porada dotyczy postrzegania struktury organizacyjnej jako dynamicznego, ewoluującego bytu, a nie finalnego, niezmiennego ustawienia.

Nie należy zakładać, że zmiana modelu właścicielstwa produktowego lub przesunięcie się po omawianej wcześniej osi to jednorazowy proces. W rzeczywistości organizacje stale ewoluują, a struktury zmieniają się w odpowiedzi na nowe potrzeby, wyzwania i możliwości.

Z doświadczenia wynika, że apetyt na usprawnienia rośnie. Organizacje, które odniosły sukces, nie przywiązują się zbyt mocno do aktualnego modelu, lecz iteracyjnie doskonalą sposób, w jaki produkty są rozwijane i zarządzane.

Warto przyjąć otwartość na przyszłe zmiany, bo w dobrze funkcjonujących organizacjach ciągła refleksja nad strukturą prowadzi do kolejnych usprawnień. Z czasem pojawiają się nowe pomysły na to, jak można zwiększyć efektywność, skrócić czas dostarczania wartości i lepiej organizować współpracę.

Dlatego zamiast traktować nowy model jako ostateczny, warto myśleć o nim jako o kolejnym kroku w kierunku doskonalenia organizacji.To, że struktura produktowa podlega zmianom, nie jest błędem – wręcz przeciwnie, to naturalna część planu.

Otoczenie rynkowe jest zmienne, strategia organizacji może ewoluować, a niektóre produkty mogą się rozwijać szybciej lub zmieniać swoje miejsce na rynku. Wszystkie te czynniki są racjonalnymi argumentami za tym, by nieustannie doskonalić i dostosowywać strukturę produktową – a czasami nawet cofać wprowadzone zmiany, jeśli okazują się one mniej efektywne, niż zakładano.

Dodatkowym aspektem, który ma kluczowe znaczenie, jest wyczucie właściwego momentu na wprowadzenie zmiany. Czasami pojawia się okienko możliwości – nowy lider w organizacji, wyraźna potrzeba korekty procesów lub inna okazja, którą można wykorzystać do usprawnienia modelu zarządzania produktem. W takich sytuacjach warto działać szybko i odpowiednio reagować na kontekst biznesowy.

Z drugiej strony, mogą zdarzyć się sytuacje, w których lepszym wyborem jest wstrzymanie zmian i przeczekanie do bardziej sprzyjających warunków. Najlepszym podejściem jest posiadanie wizji stanu docelowego, przemyślany plan kilku kroków naprzód, ale jednocześnie elastyczność w dostosowywaniu tempa zmian. Daty wdrożenia nie powinny być sztywne – może się okazać, że niespodziewane okoliczności wymagają zarówno przyspieszenia, jak i wstrzymania transformacji.

Choć każdy z modeli ma swoje plusy i minusy, a umiejscowienie właścicielstwa produktowego w organizacji może być mniej lub bardziej efektywne, to przejście z modelu całkowitego braku właścicielstwa na jakikolwiek model – nawet niedoskonały – jest krokiem naprzód.

Nawet jeśli organizacja jest na etapie, gdzie jedyną możliwą opcją jest zarządzanie Backlogiem po stronie IT, to nadal jest to lepsze rozwiązanie niż brak odpowiedzialności i funkcjonowanie w chaotycznym modelu bez jasno określonego kierunku.

Jeśli w Twojej firmie lub strukturze właścicielstwo produktowe praktycznie nie istnieje, warto zastanowić się, co stoi na przeszkodzie jego wprowadzeniu i spróbować pokonać te bariery. Nawet minimalne właścicielstwo może przynieść znaczną poprawę, niezależnie od tego, czy zostanie ono umiejscowione po stronie IT, czy po stronie biznesu. Najważniejsze jest, aby wykorzystać najlepsze możliwe rozwiązanie, na jakie organizacja jest gotowa w danym momencie.

Jeśli czujesz, że potrzebujesz pomocy we wdrożeniu takich zmian u siebie, wspieramy liderów technologicznych w skutecznych transformacjach konkretnie i praktycznie. Pomagamy dostosować modele do specyfiki Twojej organizacji i działamy razem z Tobą. Porozmawiamy. Napisz na adres [email protected]

Jeśli właściciel produktu jest za daleko od biznesu – decyzje mogą nie uwzględniać realnych potrzeb. Jeśli jest oderwany od technologii – może nie rozumieć ograniczeń i możliwości. Kluczem jest znalezienie równowagi, by produkt był skutecznie zarządzany i dostarczał realną wartość.

Brak jasnej odpowiedzialności za produkt prowadzi do chaosu: konflikty priorytetów, przeciągające się decyzje i duża ilość „gaszenia pożarów”. Efekt? Wolniejsze dostarczanie wartości dla klienta i frustracja zespołów.

Zarządca Backlogu IT przekazuje zadania od biznesu do zespołu, ale nie ma realnego wpływu na produkt. Product Owner aktywnie kształtuje wizję, podejmuje decyzje i patrzy na zmiany z perspektywy wartości.

Brzmi to jak kompromis, ale w praktyce może oznaczać walkę o priorytety i sprzeczne decyzje. Dlatego lepszym rozwiązaniem jest jeden decydent, który holistycznie patrzy na produkt.

Kluczowe jest osadzenie właściciela produktu w rzeczywistości biznesowej i technologicznej. Powinien rozumieć zarówno potrzeby klientów, jak i ograniczenia zespołu.

Każda zmiana napotyka opór. Kluczem jest zrozumienie, kto może wspierać zmianę, kto jest obojętny, a kto się jej sprzeciwia. Stworzenie mapy sojuszników i przeciwników pozwala lepiej zaplanować komunikację i strategię wdrażania zmian.

Zdecydowanie nie! Organizacja, rynek i potrzeby klientów stale się zmieniają, więc struktura produktowa też powinna ewoluować. Myśl o strukturze jak o żyjącym bycie – bądź gotów na adaptację i elastyczne decyzje.

Brak właścicielstwa produktowego oznacza wolniejsze podejmowanie decyzji i zespoły działające „na oślep”. Nawet jeśli model, który wprowadzasz, nie jest idealny – już sama próba zdefiniowania odpowiedzialności to duży krok naprzód.

Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”.

Jacek: Rozmawiałem ostatnio z szefem produktu, który dołączył do nowej firmy. Chwilę rozmawialiśmy o tym, jak wygląda środowisko pracy. Wspomniał, że jest tam dosyć spory podział, taki klasyczny między IT i biznesem. I temat, któremu poświęciliśmy najwięcej uwagi, to była dyskusja o właścicielstwie produktowym. Gdzie to właścicielstwo produktowe powinno być umieszczone w organizacji oraz porozmawialiśmy o możliwych rozwiązaniach.

Kuba: I abstrahując od tej konkretnej Jacka rozmowy, postanowiliśmy wspólnie, że to jest dobry temat na szeroki, konkretny, pełnoskalowy odcinek. Więc poopowiadam o tym, gdzie umiejscowić właścicielstwo produktowe i ewentualnie jak je zmienić, jeśli w Twojej organizacji czujesz, że zmiana powinna nastąpić. I co mamy na myśli, gdy mówimy w ogóle o właścicielstwie produktowym?

Mamy tutaj na myśli umiejscowienie osób, a w zasadzie ich raportowanie w strukturze, konkretna podległość służbowa osób, które zarządzają produktem, jakkolwiek te osoby w Twojej firmie są nazwane. To mogą być Product Ownerzy, to mogą być Product Managerowie. W niektórych organizacjach z różnych przyczyn te stanowiska mogą się jeszcze jakoś inaczej nazywać. Nie będziemy tutaj świadomie za długo wyliczać tych możliwych kombinacji, ale powiedzmy w miarę możliwości zamiennie będziemy mówić właśnie Product Ownerzy, Product Managerowie i mamy na myśli również na przykład specjalisty rozwoju, funkcjonalności albo tego typu odmiany.

No i spotykamy różne organizacje, modele funkcjonują różne. Te osoby mogą być bardziej po stronie IT czy technologii, jakkolwiek to w firmie się nazywa, czasami są po stronie biznesu, czasami są osobną strukturą gdzieś zaczepioną pod zarządem. Zarysujemy tutaj te możliwe pozycje strukturalne według takich najpopularniejszych modeli, jakie spotykamy. Trochę też scharakteryzujemy te przypadki. Na pewno nie chcemy powiedzieć, że który jest lepszy lub gorszy, ale po prostu pokazujemy, co naszym zdaniem wiąże się z takim, a nie innym układem.

Jacek: I dlaczego w ogóle ten temat jest ważny? Jest to naszym zdaniem ważny kawałek układanki dotyczącej tego, jak blisko bądź jak daleko współpracuje ze sobą biznes i IT. No, mamy tutaj z Kubą wyraźną preferencję. Nasze doświadczenie pokazuje, że im bliżej te dwa byty funkcjonują, im bardziej to jest taka naturalna współpraca ponad granicami departamentów czy strukturalnych, tym po prostu jest lepiej.

Nie będziemy o samych korzyściach zbliżania biznesu i IT rozmawiać w tym odcinku, bo mamy cały odcinek nagrany tylko o tym temacie. Jeżeli jesteś zainteresowany tym tematem, to odsyłamy do odcinka „Jak zbliżyć do siebie biznes i IT”. Jest to odcinek numer 130.

Kuba: Do znalezienia pod adresem porzadnyagile.pl/130. Ale taka teza, która jest gdzieś z tyłu tego odcinka, to to, że odpowiednie umiejscowienie właścicielstwa produktowego może wpływać na zaangażowanie zespołu wspólną, odpowiedzialność czy takie poczucie odpowiedzialności, sprawność podejmowania decyzji i pewnie jeszcze parę innych kwestii. Więc jest to aspekt ważny i przejdźmy teraz do konkretnych. O czym opowiem w tym odcinku?

Jacek: Spis treści na dzisiaj. Opowiemy, jakie widzimy możliwe modele umiejscowienia właścicielstwa produktowego w organizacji. W drugiej części nagrania podzielimy się tym, jak w praktyce podejść do zmiany właścicielstwa produktowego.

Kuba: Ok, to zaczynając od pierwszego rozdziału, jakie są możliwe modele umiejscowienia właścicielstwa produktowego?

Jacek: Tak, no to pierwszym punktem na tej osi, takim punktem startowym, to jest brak jasnego właścicielstwa. Oznacza to, że ono nie jest wyraźnie zdefiniowane, czyli nie możemy powiedzieć, że jest w jakimś konkretnym obszarze organizacji. W szczególności nie możemy powiedzieć, czy jest bardziej po stronie IT, czy po stronie biznesu. Po czym poznać taką sytuację?

Jest to bardziej praca, która jest realizowana na losowych zlecaniach, na zasadzie one skądś przychodzą, pewnie jest jakaś osoba, której zależy, ale tak na koniec dnia nie ma pełnej jasności, gdzie leży odpowiedzialność za decyzje. W takim gorszym scenariuszu może to oznaczać, że w organizacji jednocześnie toczy się wiele inicjatyw, czy wiele projektów, czy wiele zmian, które mogą ze sobą bądź konkurować, a czasem w też przez brak koordynacji i takiego spojrzenia z lotu ptaka mogą się nawet wzajemnie wykluczać.

Kuba: Realnie pewnie ktoś istnieje, kto na końcu podejmie pewną decyzję, czym się zajmują zespoły wytwórcze, ale może być to ktoś, kto robi to z musu, robi to osoba, która na przykład nie ma żadnego kontekstu biznesowego, tylko po prostu zajmuje się priorytetyzacją zadań, na przykład na minimalizację krzyku. Czyli na przykład lider zespołu skupia swoją uwagę na tym, żeby jak najmniej podpaść i jakoś tam balansuje między zapytaniami, zleceniami, projektami, jakimiś zmianami, ale tak naprawdę tam nie ma żadnego myślenia produktowego, jest co najwyżej gdzieś tam kierowanie strumieniem prac.

Tak chcemy to może uwypuklić, bo jednak na początku trochę powiedzieliśmy, że będziemy oceniać, tak wydaje się, że ten model, w którym nie ma w ogóle żadnego właścicielstwa, od niego zaczynamy, on raczej głównie ma wady i ma mało zalet. Rozumiem organizacje, w których w takim stadium istnieją, funkcjonują, ale ten akurat stan na pewno warto zmienić, o czym będziemy mówili w drugim rozdziale.

Kuba: Drugi model to zarządca Backlogów IT. Tu już jest trochę lepiej, gdyby kogoś zapytać, kto tutaj zarządza produktem, to być może przynajmniej część członków zespołu i być może część reszty organizacji powiedziałaby: No jest taki ktoś, może to jest Product Owner, może to jest lider zespołu, może to jest nawet Product Manager, chociaż najczęściej takich akurat nazw na to bym nie dawał. Jest ktoś, kto siedzi po stronie IT, albo jest częścią konkretnego jednego zespołu, albo jest częścią jakiejś dodatkowej niewielkiej struktury w ramach struktury całego IT czy technologii.

Jest to osoba, która gromadzi zlecenia, zbiera inicjatywy od interesariuszy biznesowych, realizuje te projekty, odbiera i przekazuje do zespołu, tak chcę może to trochę wypuklić, realnie nie tworzy produktu. Realnie tylko jakby skupia się na tym, żeby wiedzieć, czego się oczekuje od zespołów w miarę sprawnie przekazać to do realizacji. Nie ma tam żadnej sprawczości produktowej.

Jacek: Taki generalny komentarz do tego odcinka, nawet jak mówimy Backlog, czy jak mówimy Product Owner, to nie mamy tutaj na myśli Scruma. Natomiast te pojęcia tak bardzo już przeniknęły do firm, że właściwie są stosowane jako takie naturalne określenia. Drugi komentarz jest taki, że tutaj w szczególności w tym przypadku ten zarządca Backlogu raczej nie decyduje o tym, co jest realizowane, więc jest takim trochę bezwiednym realizatorem tego, co chcą ludzie w oku, interesariusze.

Co też może prowadzić do tego, że trochę te krzyki, o których Kuba powiedział, ten nacisk, będą wygrywać te osoby, które będą miały większą siłę przebicia, a to niekoniecznie będzie przekładać się na wartość dostarczonego rozwiązania czy produktu. Ale dla bycia fair powiedzmy, że ma to już pewną zaletę.

Kuba: Ale dla bycia fair warto dodać, że takich zarządca w Backlogu w IT, no to w porównaniu do poprzedniego modelu, gdzie nie ma w ogóle żadnego właścicielstwa, ma już tę zaletę, że być może jest szansa na jakieś ucywilizowanie strumienia prac, być może jakieś poukładanie, chociaż minimalną dyskusję z tymi interesariuszami, może jakieś łączenie tych inicjatyw w jakieś większe sensowne kawałkialbo świadome ich dzielenie, ale w każdym razie minimalne wpływanie na ten strumień.

I to już jest coś, to tutaj bądźmy fair, jakkolwiek może krytycznie przed chwilą to charakteryzowaliśmy. Taki model najczęściej jest in plus w momencie, gdy się go wprowadzi w porównaniu do poprzedniego etapu.

Jacek: Trzeci model, zarządzanie produktem po stronie IT. Czyli tutaj w porównaniu do poprzedniego modelu, mamy jednak jakiegoś, już nazwijmy to Product Ownera, czyli kogoś, kto nie jest pasywnym realizatorem wizji okolicznych interesariuszy, tylko jednak samodzielnie zarządza. Może ma jakąś wizję, może ma jakąś własną Road mapę, może nawet ma jakieś wskaźniki. W każdym razie już próbuje w zależności od umiejętności i możliwości tym produktem zarządzać.

Nadal on jest po stronie IT, więc chcąc nie chcąc, na pewno ma jakąś grupę interesariuszy, których musi opanować, którymi musi zarządzić, ale już nosi to jakieś takie znamiona tego, że ktoś spędza czas na tym, żeby o produkcie myśleć trochę bardziej długofalowo, niż tylko róbmy taski, bo ktoś chce i te taski do nas spływają.

Kuba: Jest to model, w którym to zarządzanie produktem już jest aktywne, to jest realizacja konkretnej wizji, to jest model, w którym ten zarządzający produktem być może nawet ma prawo odmawiać konkretnie, skupiać się tylko na tym, co sobie wymyślił czy wymyśliła, niezależnie od tego, co konkretny jakiś inny interesariusz sobie marzy.

Po stronie plusów jest już faktycznie realizacja konkretnej wizji, ta wizja w niektórych produktach jest super istotna, bo pozwala odrzucać wiele zachcianek. Ewentualnym zagrożeniem czy ryzykiem takiego modelu pozostaje oddalenie się od kontekstu biznesowego, od strategii firmy, od pozostałych zespołów biznesowych, jakichś sprzedaży, jakiegoś marketingu, jakiegoś wsparcia, jakkolwiek to wygląda w danej firmie i w jej specyfice branży.

No i jest też takie zagrożenie, że być może będą preferowane rozwiązania technologiczne. To spotykamy takie narzekanie na tych Product Ownerów czy managerów technologicznych, że wybrali migrację systemu, update kolejnej wersji języka, czy totalny refactoring, zamiast dołożyć jeszcze kolejną funkcję, za którą by w tym roku albo w tym kwartale dało się jeszcze trochę zarobić biznesowo. Więc tutaj istnieje zagrożenie takiej świadomej intencji preferowania rozwiązań technologicznych.

I kontra do samego siebie, ale są też produkty, w których to jest absolutnie taki end state, to już jest ten moment i to umiejscowienie, które jest właściwe, no bo chociażby rozwiązania bardzo technologiczne z jakichś takich może niższych warstw albo w firmach, które zapewniają bardzo technologiczne produkty albo chociażby w którejś z produktów. Po prostu to będzie naturalne umiejscowienie zarządzania produktem właśnie w zespole technologicznym.

Kuba: Model czwarty, taki jak powiedzieliśmy o osi, to model ewidentnie na samym środku tej osi, to podwójne właścicielstwo. Są organizacje, tutaj są doradcy, konsultingi, które to podpowiadają, żeby tak właśnie to rozwiązać, które wybrnęły z dylematów, gdzie umiejscowić się właścicielstwo produktowe w dosyć niezbyt fajny sposób, bo tutaj nie ukrywam, że mam zdanie na ten temat. Po prostu ustanowiono podwójnego na przykład Product Ownera, właściciela produktu, zarówno osobę z biznesu i drugą osobę po stronie technologicznej.

No i w takim powiedzmy pozytywnym świetle, patrząc na sprawę, no to chodzi o to, żeby ustanowić pewną odpowiedzialność biznesową u kogoś, kto przychodzi z tego świata biznesowego i ta osoba ma współdecydować o rozwiązaniu razem z właścicielem technicznym, który właśnie skutkuje się na tych aspektach, które wymieniałem też w poprzednim modelu.

Czyli jakieś kwestie związane na przykład z wymaganiami funkcjonalnymi, bezpieczeństwem, wydajnością, kwestiami związanymi z kosztami utrzymania systemu w drugim okresie, czyli tak naprawdę jakby takie uzupełnienie tych rzeczy, o których można się spodziewać, że osoba ze strony biznesowej albo nie będzie do końca rozumieć, albo nie będzie uznawać ich wielkich wagi.

Więc realnie taki zespół w tym modelu ma po prostu dwóch Product Ownerów. Oni mogą się różnie nazywać, bo też my tutaj nie bawimy się w etykiety, ale po prostu jest dwóch decydentów o tym, co jest ważne i ci decydenci się w jakiś sposób muszą dogadać, żeby faktycznie ostatecznie zespół dostał priorytet.

Jacek: Gdybym miał wskazać takie z mojej perspektywy największe zagrożenie czy ryzyko tego modelu, no to na pewno ten dualizm. Czyli w takim skrajnym, negatywnym przypadku, no to te dwie osoby mogą nie współpracować. Mogą dawać zespołowi sprzeczne sygnały, no i mogą bardzo mocno ciągnąć produkt w swoją stronę. Czyli mocny biznesowiec może trochę zagłodzić potrzeby technologiczne, np. potrzeby spłaty długu albo zmiany jakiejś biblioteki czy frameworka, który już wymaga np. ze względów bezpieczeństwa zmiany, ale też w drugą stronę silny, techniczny, może ciągnąć we wszystkie te rzeczy, zagładzając z kolei potrzeby biznesowe.

Jacek: Kolejny model i już dosyć mocno tutaj zbliżamy się do przeciwnego końca osi, to model, w którym zarządzanie produktem występuje po stronie biznesowej. Czyli mamy tutaj osobę odpowiedzialną biznesowo, jakiegoś Product Managera, Product Ownera, który pochodzi z biznesu, jest osobą biznesową i absolutnie czuje, o co chodzi z produktem. Patrząc na produkt, patrzę na niego szerzej, to nie jest tylko apka, to nie jest tylko rozwiązanie technologiczne, ale rozumie tak naprawdę cały ekosystem. Rozumie, po co jest ta aplikacja, częścią, jakiego większego produktu ona jest.

No i tak naprawdę czuje po co, dlaczego i w jakim celu pewne rzeczy są realizowane. Taka osoba przynosi takie bardzo mocne spojrzenie biznesowe do zespołu, więc jeśli zespół dotychczas nie miał takiego kontekstu, no to taka osoba potrafi w miarę w dosyć krótkim okresie czasu zarazić zespół, pokazać po co, dlaczego, dać ten szerszy obrazek, który spowoduje, że praca w tych zespołach może nabrać kompletnie nowego sensu i nowego wymiaru.

Kuba: Jeśli myślisz, że to jest już ostatni i ten piękny obraz, no to ja tutaj zwrócę uwagę na słowo przynosi, którego Jacek użył. Mimo wszystko ten model ma pewną wadę w związaniu z tym, że jest nadal jakieś takie odróżnienie, że jest ktoś, kto wie, ktoś, kto jest mądry, ktoś, kto ma połączenie ze strategią z odpowiednio wysokimi zarządzającymi i to ta osoba do tego zespołu przynosi właśnie, jakby oznajmię, pokazuje.

Oczywiście można to zrobić na miękko, można to zrobić w dobrej otoczce, ale nadal jest tego rodzaju dynamika, że jest ktoś, kto wie, ktoś, kto myśli, ktoś, kto jest dobrze wtajemniczony i ten ktoś przenosi pewną wytyczną do zespołów.

Nadal da się lepiej, za chwilę opowiemy jak. Oczywiście w wielu organizacjach ten model jest też dla równowagi bardzo korzystny, bo tak faktycznie uruchamia mechanizm odpowiedzialności wspólnej zarówno struktur biznesowych, jak i tych struktur technologicznych za sukces, no bo tak naprawdę o priorytetach tego, co jest realizowane, decyduje strona biznesowa, o sposobie dostarczenia, o takiej też może wydajności czy produktywności zespołu, no to siłą rzeczy pozostaje odpowiedzialność technologiczna i w pewnym sensie wszyscy są w to zamieszani. Są w to włączeni i ewentualne korekty też tego modelu, wymagają już też zaangażowania wszystkich managerów z każdej możliwej takiej stereotypowej struktury Biznesu i IT.

Kuba: No i zapowiedziany ostatni model to umocowane zespoły produktowe. W porównaniu do poprzedniego układu mówimy tutaj o sytuacji, gdzie tak naprawdę stworzony został mocny, interdyscyplinarny zespół, posiadający kompetencje zarówno te produktowe, biznesowe, szeroko rozumiane wsparciowe, jak i technologiczne. Wszyscy razem tworzą zespół i tak naprawdę nie do końca, gdyby wejść na jakąś sesję kreatywną, warsztatową, to byśmy tak bardzo odróżniali, kto jest z którego pionu.

Chyba że stereotypowo jedni noszą swetry, a inni nie. Ale wracając na poważnie, wszyscy są zaangażowani, starają się zarówno uczestniczyć w tej fazie kreatywnej wymyślania rozwiązania, jak i poświęcają swoją energię również na te etapy dostarczenia. I faktycznie w zespole prawdopodobnie pozostaje jakaś osoba naznaczona jako lider produktu, ale ta osoba jest bardzo mocno demokratycznie wciągnięta w całą resztę. Powiedziałbym, jest to osoba, która ostatecznie decyduje, a nie przynosi, jak w poprzednim Jacek modelu to zarysował.

Więc tutaj takie umocowane zespoły produktowe zacierają tę granicę biznesu i technologii. Tak naprawdę wszyscy razem staramy się zaopiekować i przesunąć produkt w pożądanym kierunku, zgodnym ze strategią, zgodnym z wizją całego produktu.

Jacek: Gdybym miał wskazać ryzyka czy jakieś takie słabsze elementy tego modelu, wydaje mi się, że chyba największym problemem jest to, że to jest realnie dosyć trudne do osiągnięcia. Wymaga sporych zmian na poziomie mentalnym w organizacji.

Trochę myślę też innego profilu kompetencyjnego, jeśli chodzi o ludzi w zespole. Szukałbym pewnie tutaj osób o tym profilu kompetencji, typu T, osób o dużej otwartości. Tak jak Kuba mówił, często na tych sesjach, gdzie pracują, trudno powiedzieć, kto jest skąd, z jakiego macierzystego działu, bo na przykład o użyteczności aplikacji wypowiada się i tester, i developer, a niekoniecznie na przykład osoba, którą byśmy gdzieś tam wsadzili do ogródka UX-owego.

Więc myślę, że jest to kosztowny dosyć model, do którego jeżeli on od początku powstania firmy nie funkcjonuje, no to przejście może być dosyć bolesne, no bo wyobraźmy sobie, że rozmawiamy o firmie, które jest na początku naszej osi, nie ma w ogóle jasnego właścicielstwa, no to dojście do tego, że są umocowane zespoły produktowe, to w ogóle może być zbyt duży przeskok na zasadzie, jak to możliwe, wszystkie te teksty, jak nikt jeden konkretny nie odpowiada, to kto odpowiada i tak dalej.

Tak więc na pewno jest to model, który jest sporym wyzwaniem, żeby po prostu mentalnie i kulturowo do niego w organizacji dotrzeć. 

Kuba: I zanim przejdziemy do drugiej części nagrania, przypominam, że jeżeli chcesz pogłębić wiedzę, jeszcze bardziej niż robimy to w podcaście, to znajdziesz nasze płatne produkty na stronie porzadnyagile.pl/sklep

Jacek: Powiedzieliśmy, jakie są naszym zdaniem modele, oczywiście to jest nasza definicja, nasza oś, pewnie mogłabyś/mógłbyś stworzyć taki model, taką ośkę po swojej stronie. Natomiast teraz skupimy się na tym, jak w praktyce podejść do zmiany właścicielstwa produktowego. Co byś, Kuba, radził?

Kuba: Pierwsza porada jest dosyć prosta. Zdefiniuj sobie, gdzie w ogóle jesteś. I chodzi o to, żeby na narysowanej przez nas osi, albo swoje własnej, jeśli czujesz, że masz lepsze podejście lub pożyczone od jeszcze kogoś innego mądrzejszego od nas, zobacz, gdzie jesteś. Umiejsców swoją organizację, ale może też wyjść poza swoją własną intuicję i odczucie, ale też zbierz feedback.

Zapytaj zespoły, zapytaj interesariuszy biznesowych, zapytaj managerów, żeby sobie wyrobić zdanie, bo jedno z gorszych zjawisk, jakie może być, to jest przesuwanie się między punktem 5 a 6 w swoich oczach, gdzie tak naprawdę w organizacji jesteś raptem na punkcie 2. i te modele niestety, wymagają swojej oddzielnej taktyki do zmiany i też z tego powodu lepiej wiedzieć, co w ogóle naprawiasz i gdzie w tej chwili jesteś.

To ma też o tyle istotne znaczenie, że zwłaszcza w większej organizacji może się tak zdarzyć, że firma w różnych częściach jest na różnych etapach dojrzałości. I sam tego jestem często świadkiem. Jedna sprawa to to, że zawsze się znajdą takie trochę bardziej zespoły, trochę bardziej progresywne, może z trochę lepszym klimatem, może się dobór osobowy też zrobił jakiś taki w miarę szczęśliwy, że po prostu mogą i robią trochę więcej.

Ale też mogą być organizacje, które mają więcej linii biznesowych, mają na przykład trochę różne rynki, które obsługują i to wszystko może rzutować na to, że ta dojrzałość produktowa może być różnorodna i to tym bardziej wtedy jeszcze jest wyższa szkoła jazdy, żeby sobie zdefiniować, jaką ona w zasadzie jest.

Żeby czasami nie aplikować na przykład wytycznej, użyjmy tego przykładu ostatniego, że od teraz wszyscy tworzymy zespoły produktowe, a gdzieś tam w firmie może się okazać, że oni tam nawet nie mają właścicielstwa i nigdy do tej pory nie mieli, więc w ogóle rozmawiamy jakieś bajki o smokach i nie jesteśmy w stanie tego przeprowadzić.

Jacek: I w praktyce może to oznaczać, że zmiany, które będziesz przeprowadzać czy przeprowadzała, to nie będzie taka zmiana globalna dotycząca całej organizacji, może być tak, że tylko pewien wybrany wycinek struktury, jakiś konkretny obszar, jakiś konkretny value stream, jakkolwiek to jest nazwane w Twojej firmie, to będzie ten obszar Twojego zainteresowania i zmiana będzie prowadzona w trochę mniejszej skali, niż można byłoby mieć tak pierwotnie apetyt.

Jacek: Druga porada, ustal, jakich rezultatów oczekujesz po zmianie. Mamy tutaj na myśli taki stan, w którym postaramy się nazwać spodziewane efekty. Konkretnie im bardziej jesteśmy w stanie to zrobić na namacalnych miernikach, tym lepiej. Jednak też z drugiej strony warto pamiętać, że są też takie trochę mniej mierzalne aspekty, które również mogą mieć znaczenie, czyli przykładowo coś, co jest bardzo mierzalne, to może być jakaś odmiana lead time’u czy cycle time’u, czyli upraszczając bardzo mocno, jak długo czekamy od pomysłu do realizacji, czy jak szybko od podjęcia pracy jest ona realizowana.

I to jesteśmy w stanie bardzo łatwo zmierzyć. Ale takie bardziej niemierzalne aspekty, mniej liczbowe, no to mogą być jakieś takie odczucia, na przykład zespołów, czy czują, albo w jakim stopniu czują, że ich praca ma sens, to mogą być też z drugiej strony reakcja czy ocena taka ze strony biznesowej, na ile ich potrzeby są realizowane, to może być bardziej takie opisowe, może bez jakiejś konkretnej cyferki w tle, ale nadal mogą to być bardzo istotne aspekty, na które warto zwrócić uwagę i wziąć je w ogóle pod uwagę, zanim zaczniemy przeprowadzać zmianę.

Kuba: Istnieją organizacje bardzo dobrze pomierzone, w których po prostu trzeba wybrać, który spośród mierników będzie tym, który obserwujemy, jaki mamy poziom aspiracji, czy co jest naszą ambicją, żeby było po pewnej zmianie. W innych organizacjach aż tak różowo nie jest, jeśli chodzi o tę sferę mierzenia.

No i być może w ramach zmiany sposobu umiejscowienia właścicielstwa produktowego, czyli całego funkcjonowania zespołów produktowych, trzeba również uruchomić nowe pomiary, zrobić jakiś pomiar bazowy, do którego będziemy się porównywać, na przykład, jaki jest obecny poziom satysfakcji ze współpracy w zespołach, no i powtórzyć to po jakimś czasie już po zmianie, jak się zmiana ustabilizuje, jak wtedy zespół oceni, na przykład w jakiejś ankiecie satysfakcji, współpracy czy inne kwestie, które Jacek już też po kolei wymieniał.

Czyli żeby później powiedzieć, czy jest lepiej, musisz przewidzieć, co w ogóle chcesz mierzyć i chcesz sobie przygotować odpowiednie pomiary, jeśli firma lub Twoja część struktury na razie tego nie ma.

Kuba: Trzecia porada jest dosyć przewrotna. Określ argumenty przemawiające za utrzymaniem obecnego stanu rzeczy. To jest taka trochę trikowa kwestia, żeby się zastanowić, co takiego może być argumentem za oporem przed zmianą. Będzie opór. Takie zmiany są bardzo trudne. One są najczęściej strukturalne, zwłaszcza jeśli mówimy o tym magicznym przeskoczeniu przez środek, że na przykład właścicielstwo produktowe przechodzi do strony biznesowej, to z automatu możemy mówić o całej puli problemów.

Kilka wymienimy. I dobrze jest wiedzieć, dobrze jest sobie przewidzieć, dobrze jest sobie wyczuć, co to w ogóle mogłoby być, nazwać sobie te powody, żeby też ewentualnie w ramach zarówno komunikacji takiej racjonalnej, jak i też przygotowania pewnych mechanizmów przewidzieć, co może stawiać opór, kto może widzieć jakieś problemy, no i się odpowiednio zaplanować pod kątem właśnie przewalczenia tego oporu, powiedzmy wysunięcia kontrargumentów czy podkręcenia narracji w stronę korzyści, które przykryją problem z tym oporem. Żeby każdy widział interes w tej zmianie i każdy poczuł, że jest w tym coś dla mnie.

Kuba: Jakie to mogą być argumenty przemawiające za tym, żeby się nie zmieniać?

Jacek: Podzielimy się czterema takimi popularnymi, to nie jest zamknięta lista. Pierwsze, biznes nie rozumie IT. To może być taki argument, który usłyszymy, argument, który ma utrzymać aktualny podział, na zasadzie my róbmy biznes, wyróbcie IT i tam sobie za bardzo w drogę nie wchodźmy. Co możesz tutaj zrobić? Warto zainwestować w to, żeby to zrozumienie po obu stronach rosło.

Moim zdaniem osoby rozwijające produkty w firmach technologicznych muszą rozumieć technologię. Nie muszą być ekspertami, nie muszą umieć programować itd., ale muszą rozumieć, co się do nich mówi. Muszą rozumieć, jakie są konsekwencje pewnych wyborów technologicznych. I w drugą stronę, czyli osoby odpowiedzialne za technologię muszą rozumieć kontekst biznesowy. Takie osoby są na rynku. Takie osoby można też rozwijać w ramach organizacji. Być może też rozwiązaniem jest zapewnienie odpowiedniego wsparcia na zasadzie, czy od strony technologii to jest jakiś architekt, czy Tech lead. Ktoś, kto będzie wsparciem i supportem dla takiej osoby biznesowej, po to, żeby ona stopniowo coraz lepiej rozumiała całą tę otoczkę technologiczną.

Kuba: I coraz lepiej rozumiała to mój kontrargument, bo pojawia się też pewna odmiana tego, co ja sobie wymienił, że biznes i IT się nie rozumieją, nie mówią odpowiednim językiem, więc musi być ktoś pomiędzy, kto będzie to tłumaczył. To zwłaszcza takie modele, w których ten Product Owner jest taki jakby wyspecjalizowany, ale jednak pozostaje po stronie technologii, mogą być bronione właśnie pod tym kątem, że mamy takich fajnych Product Ownerów, którzy rozumieją zarówno biznes, jak i rozumieją stronę technologiczną i tak powinno pozostać.

Nie zmieniajmy tego, bo ci biznesowcy to się zrażą, albo zespoły się obrażą, bo biznesowiec mówi jakimś dziwnym innym językiem. To jest taki argument dla mnie do zbicia, ale rozumiem, dlaczego on się pojawia. Tutaj cała sfera związana ze zbliżeniem biznesu i IT odcinka wspomnianego 130. Właśnie jest też o tym, zintegrujmy te zespoły, zróbmy sobie wspólny słownik, zawiążmy też kontrakt, dajmy sobie sposób dla zespołu, oczekujemy, że zespół sam sobie to znajdzie oczywiście. Umieją się dogadać, umieją sobie zadać pytanie, umieją się zatrzymać, umieją poprosić o parafrazę i tego typu rozwiązania.

Czyli fakt, że dzisiaj się nie dogadują, fakt, że dzisiaj może nie mają wspólnego słownika, jest tylko pewną przestrogą, ok, ta zmiana, zbliżenie się, na przykład przesunięcie właścicielstwa w stronie biznesu może wiązać się z takim okresem przejściowym, będzie trochę trudniej, będzie trochę niedoskonale, być może będą odrobinę tarcia, czy nawet takie dosyć śmieszne niedogadania się. No bo, po prostu to samo słowo znaczyło dla dwóch stron, układamy trochę co innego i z tego powodu cały kawałek prac poszedł nie w tę stronę, co trzeba.

Jacek: Trzeci taki argument, który można usłyszeć, biznes nie ma czasu. Nie zawracajcie nam głowy, jesteśmy zajęci, róbcie te swoje rzeczy, to co potrzebujecie wam dane, ale nie ma szans, że się zaangażujemy mocniej. Moim zdaniem to jest spore ograniczenie. Pracowałem w jednej z firm, gdzie wyraźnym sygnałem od szefa, od prezesa było coś w stylu zmieniajcie się, transformujmy się, ale nie ma opcji, że osoby z biznesu będą pracować z zespołami, nie mają na to czasu.

I to była taka wyraźna linia odcięcia, co spowodowało, że w rolę Product Ownerów, takich biznesowych, weszli Project Managerowie. No i jakby słuchając całego tego odcinka, zapewne domyślasz się, że było to jakieś rozwiązanie, pewnie lepsze niż brak zupełny właścicielstwa, no ale niestety zespoły cierpiały i brakowało tego prawdziwego kontekstu biznesowego. Trochę bardziej było to przekazywanie pewnych wymagań do zespołu, które mają zostać zrealizowane.

Kuba: Czwarty pojawiający się często powód, który wymienimy, to taki argument, tylko technologiczny Product Owner zapewni, że sprawy technologiczne będą równie ważne i zaopiekowane. Trochę już to sygnalizowaliśmy wcześniej i ten argument w wybranych organizacjach się pojawia. W jednej z nich to czułem takie dosyć ciężkie dyskusje, że no nie, biznes w pierwszej chwili, jak tylko opisze mnie odpowiedzialność za priorytety, wywali natychmiast te wszystkie migracje, te wszystkie automatyzacje, te wszystkie usuwania długu. Zamknie nam te wszystkie ważne dla nas rzeczy technologiczne, zaczną napierać, żebyśmy robili to byle jak i tego typu argumenty. No i jakby nie neguję takiej obawy.

Natomiast ja myślę tutaj o rozwiązaniu takim wyprzedzającym, które powinno to zabezpieczyć. Ważne, żeby zwłaszcza liderzy organizacji, w każdym z tych pionów, więc liderzy technologiczni, liderzy biznesowi, bardzo twardo ustawili sobie jakąś umowę na temat tego, jak zaopiekowane będą rzeczy technologiczne, jeśli priorytety nadaje strona biznesowa. W idealnym świecie to Jacek już wspominał, siłą rzeczy ci właściciele biznesowi zostaną zaznajomieni z tą technologią.

Jeśli dać im dobre wsparcie, to w długim okresie będą rozumieli, że dług technologiczny trzeba usuwać, że rzeczy technologiczne wymyślone przez zespół są ważne. No, ale jeśli taka nadzieja to za mało, no to wszedłbym w jakieś twarde umowy. W jednej z organizacji po prostu zostało to zadekretowane, przyjęte jako pewna umowa obowiązująca, jako taka twarda reguła, że 20% przepustowości zespołu idzie na rzeczy technologiczne i tutaj, no jakby Product Owner z biznesu nie może tego zanegować, co najwyżej może wpływać na priorytety wewnątrz tego strumienia prac.

Nie każdej organizacji je sugeruje, żeby ustawić sobie aż taką sztywną regułę, ale to może być jeden z kierunków, czyli takie pomyślenie o tym, że mamy pewną umowę na temat tego, jakie prace w ogóle w zespole są prowadzone.

A druga rzecz, która też może być super istotna, to zadbanie o to, żeby było bardzo klarowne i bardzo jakby respektowane przez całą organizację Definition of Done. Umowa na temat tego, jaki standard jakości jest absolutnie nie do obniżenia, żeby nie było tej presji biznesowej na to, że no to teraz weźcie, przyspieszcie, robicie to byle jak, a później się poprawi i się nigdy nie poprawia. Więc jest kilka rozwiązań, jest kilka praktyk na to, żeby zapewnić czy wyprzedzić tę obawę, że jak technologiczny Product Owner nie zadba, to już nikt nie zadba. Warto się tym dogadać.

Jacek: To, co Kuba powiedział, to był taki czwarty, ostatni powód, który chcieliśmy wymienić w ramach określania, zachęcenia do tego, żeby określić argumenty przemawiające za utrzymaniem obecnego stanu rzeczy. Natomiast zapewne w Twojej firmie mogą to być albo inne powody, albo tych powodów może być więcej. Nie wyczerpiemy tutaj wszystkich wątków. Zdecydowanie rekomendujemy, żebyś zastanowił się, zastanowiła się no i po prostu podjął czy podjęła decyzję na temat tego, jakie to są argumenty samodzielnie.

Kuba: No to czas czwartą poradę, jak można zmienić właścicielstwo produktowe, jak zmienić umiejscowienie właścicielstwa w organizacji. Porada brzmi narysuj mapę sojuszników i przeciwników zmiany. Zdefiniuj sobie, kto przewidujesz, że będzie wspierał zmianę, kto będzie być może bardzo neutralny i ani nie wesprze, ale też na szczęście nie będzie przeciwnikiem. Takie zmiany, zwłaszcza trudne, zwłaszcza z przesuwaniem odpowiedzialności w ramach struktur, mogą mieć też swoich przeciwników ze swoimi argumentami, o których wymieniliśmy kilka chwil temu.

Narysuj to zrozum, zobacz jak to wygląda, zastanów się też, jakie są zależności i na tej bazie spróbuj sobie zaplanować pracę taką właśnie polityczną, dyplomatyczną ze zbudowaniem kręgu sojuszników, którzy będą wspierać tę zmianę i wpływać na te osoby, które są niechętne.

Jak mówię, narysuj mapę, mam dosłownie na myśli narysowanie sobie mapy, tutaj może się przydać taka technika, która nazywa się Stakeholder battle mapping. Jest ona do znalezienia między innymi na YouTube, podlinkujemy filmik na ten temat autorstwa Geoffa Wattsa w notatkach do tego odcinka. Proste narzędzie, wykorzystałem je kilka razy, najczęściej fajnym efektem tego ćwiczenia było wow, nie zdawaliśmy sobie sprawy, jaka to jest plątanina zależności, ale też jednym z obiecujących elementów jest to, że nawet ci, którzy są przeciwni naszej zmianie, mają kogoś, kto na nich wpływa.

To może być przełożony wyższego szczebla, to jest prosty przypadek, ale to też mogą być osoby, które np. dany przeciwnik uważa za istotne w podejmowaniu decyzji osoby, których opinia jest dla tej osoby ważna. Może się okazać, że tak pośrednio jesteśmy w stanie znaleźć sposób na wpłynięcie na te osoby niechętne i zaplanowanie takiej naprawdę cwanej, dyplomatycznej, sprytnej akcji, żeby przekonać nieprzekonanych, żeby podjąć wspólnie pewną decyzję i faktycznie odważyć się na konkretne kroki.

Jacek: Przedostatnia porada, myśl o strukturze jako żyjącym bycie, a nie w finalnym ustawieniu. Nie spodziewałbym się, że jakakolwiek zmiana modelu czy przesuwanie się po tej osi, o której z Kubu mówiliśmy, że to jest coś, co się wykonuje raz i koniec, raczej bądź gotów i gotowa na to, że te modele będą się zmieniać. Myślę, że apetyt może rosnąć. Przynajmniej raczej w tę stronę widzę, że organizacje się przesuwają.

Więc moim zdaniem nie ma co zbytnio przywiązywać się do aktualnego stanu czy do tego nowego stanu, który właśnie się w organizacji pojawił, bo najlepsze organizacje, które widziałem, raczej iterują na temat tego, jak ustawiona jest struktura pod kątem wytwarzania produktów i raczej zbyt długo nie są w stanie usiedzieć w tym modelu, w którym aktualnie się znajdują. No bo bardzo szybko na skutek refleksji pojawiają się pomysły usprawnieniowe, co można usprawnić, co można zrobić lepiej, żeby praca była bardziej efektywna, żeby dostarczać szybciej więcej wartościowych rzeczy.

Kuba: I fakt, że struktura produktowa żyje, to nie jest błąd, tylko to jest część planu. Zmienia się otoczenie rynkowe, być może strategia organizacji się też trochę zmienia, karząc pewnym produktom być większym, albo przesunąć się na jakieś inne pole, to wszystko są bardzo racjonalne argumenty za tym, żeby ciągle to poprawiać, ciągle to zmieniać i ewentualnie nawet cofać, bo to też może mieć miejsce.

A z drugiej strony, oprócz tego, co Jacek powiedział, jest też tak, że takie zmiany są strasznie podatne na moment, czyli taką regułę najlepszy moment jest teraz, zróbmy tę zmianę, bo się otworzyło jakieś okienko, ktoś zarządzający właśnie nowy przyszedł, albo jest jakaś niedoskonałość procesowa i możemy się wstrzelić w okazję.

Więc tutaj zarządzający mogą mieć fajne plany, mogą być gotowi, mogą to gdzieś może rozłożyć mocno w czasie i tydzień później będzie jakieś spotkanie, na którym trzeba szybko zareagować i wskoczyć do odpowiedniego pociągu ze zmianą, albo wyczuć, że teraz trzeba te zmiany zapauzować, bo to nie jest po prostu czas na to.

Więc tutaj zachęcamy do takiej elastyczności w podejściu. Najlepiej byłoby mieć wizję stanu docelowego i pewne przemyślenie na temat paru kroków w przód, ale nie przywiązywać się zwłaszcza do dat w tym planie, bo zarówno może nastąpić poważne przyspieszenie, jak i też zapauzowanie pewnych marzeń do lepszych okoliczności.

Kuba: I ostatnia porada z trochę innego poziomu abstrakcji, tak podsumowująca również wszystko to, co powiedzieliśmy. Przyjmij, że lepsze jakiekolwiek właścicielstwo niż jego brak. O ile widzimy plusy i minusy różnych modeli i różnego umiejscowienia organizacji na osi, którą zarysowaliśmy w pierwszej części, tak zdecydowanie zgadzamy się, że przejście z modelu brak właścicielstwa na jakiekolwiek, na jakie stać organizacje, nawet jeśli to jest ten model super niedoskonały, związany z zarządzaniem Backlogu, zleceń po stronie IT, to i tak jest lepsze niż nic.

Więc tutaj mocno zachęcamy do tego, że zwłaszcza jeśli słuchasz nas i czujesz, że jesteś w tej okolicy albo część, chociaż Twojej struktury jest w okolicy i z tego samego braku właścicielstwa produktowego to naprawdę rozważ, co cię stopuje i spróbuj pokonać tę barierę, żeby choć minimalne właścicielstwo powołać w ramach swojej struktury technologicznej albo oczekiwać, że Twoja struktura IT, jeśli jesteś po tej stronie biznesowej, że chociaż takie właścicielstwo powoła, najlepsze na jakie stać organizacje na ten moment.

Jacek: Podsumowując. Jak w praktyce podejść do zmiany właścicielstwa produktowego? Zdefiniuj sobie, gdzie w ogóle jesteś. Ustal, jakich rezultatów oczekujesz po zmianie. Określ argumenty przemawiające za utrzymaniem obecnego stanu rzeczy.

Kuba: Narysuj mapę sojuszników i przeciwników zmiany. Myśl o strukturze jak o żyjącym bycie, a nie finalnym ustawieniu. Przyjmij, że lepsze jest jakiekolwiek właścicielstwo niż jego brak.

Jacek: Być może po przesłuchaniu tego odcinka czujesz, że potrzebujesz pomocy we wdrożeniu takich zmian u siebie. Wspieramy z Kubą liderów technologicznych w skutecznych transformacjach konkretnie i praktycznie. Pomagamy dostosować modele do specyfiki Twojej organizacji i działamy razem z Tobą. Porozmawiamy. Napisz na adres [email protected]

Kuba: Notatki do tego odcinka, artykuł, transkrypcje, wspomniany link do Stakeholder mapingu, zapis wideo znajdziesz na stronie porzadnyagile.pl/133

Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.

———

To była pełna transkrypcja odcinka podcastu „Porządny Agile”. Dziękujemy za lekturę!

Ostatnia aktualizacja: 29 grudnia 2025

Czy masz wrażenie, że Twój zespół wykonuje zadania, ale nie czuje realnej odpowiedzialności za produkt? Brakuje u nich inicjatywy, zaangażowania i proaktywnego podejścia? Pokażemy Ci sprawdzone sposoby na wzmacnianie odpowiedzialności zespołów – bez micromanagementu i bez frustracji. To konkretna pigułka wiedzy dla liderów, którzy chcą budować silne, samodzielne i zaangażowane zespoły.

Spis treści

• Wyznaczaj ambitne cele
• Nieustannie przypominaj strategię firmy i produktu
• Włączaj zespoły w kreowanie rozwiązań
• Wyjaśniaj kontekst biznesowy swoich decyzji
• Pozwalaj eksperymentować i popełniać błędy
• Oczekuj efektów, a nie dowożenia zakresów
• Zapewnij zespołom dostęp do feedbacku od klientów 
• Znajdź czas na pracę 1 na 1 ze swoimi ludźmi
• Stwórz ścieżki rozwoju dla członków zespołu
• Zaplanuj proces wzmacniania odpowiedzialności
• FAQ: Jak szef produktu buduje odpowiedzialność zespołów?
• 📄Transkrypcja podcastu „Jak szef produktu buduje odpowiedzialność zespołów?”

W ramach naszego podcastu, nagraliśmy odcinek o budowaniu odpowiedzialności za produkt, skierowany głównie do Product Ownerów i Scrum Masterów. Możesz go znaleźć na stronie www.porzadnyagile.pl/31, pod tytułem: „Wzmacnianie odpowiedzialności zespołu za produkt”. Dziś podejmujemy podobną tematykę, ale w zupełnie innych okolicznościach i z myślą o osobach zarządzających większymi strukturami – kilkoma zespołami, produktami lub całą strukturą produktową.

Mamy dla Ciebie dziesięć porad dotyczących tego, co osoba zarządzająca strukturą produktową może zrobić, aby budować odpowiedzialność zespołów wytwórczych za produkt, nad którym pracują.

Wszystko zaczyna się od konkretnego, ambitnego i mierzalnego celu. Warto przy tym wykazać się wizjonerskim podejściem, pokazując zespołom perspektywę wykraczającą poza to, co obecnie są w stanie dostrzec. Takie podejście wiąże się z wyższymi oczekiwaniami, które motywują do poszukiwania mniej oczywistych rozwiązań.

Aby osiągnąć ambitny cel, zespół powinien poświęcić czas na przemyślenie sposobów realizacji i wzięcie odpowiedzialności za efekt końcowy. Ograniczenia – na przykład czasowe – mogą skłonić do kreatywnego podejścia: radykalnych uproszczeń, sięgnięcia po nowe technologie lub zastosowania nieszablonowych rozwiązań, które w danej organizacji będą zaskakujące i świeże.

Jeśli żaden z przypadków wymienionych wcześniej nie dotyczy Twojej sytuacji, ta porada jest tym bardziej dla Ciebie. W roli szefa produktu warto czasem samodzielnie stworzyć lub zasymulować warunki, w których pojawi się ambitny cel. Chodzi o świadome sprowokowanie sytuacji, która postawi zespoły przed wyzwaniem.Mamy na myśli odwrócenie niekorzystnej sytuacji, gdy zespoły są lekko rozleniwione, nie mają wyzwań, a cele, które przed nimi stoją, są miałkie, lekkie i letnie. Brak ambitnych celów może przyczyniać się do rozluźnienia i podejścia w stylu: „zrobię swoje, jakoś to się wszystko później złoży, będzie dobrze”.

Mamy jednak bardzo pozytywne doświadczenia z różnych organizacji, w których pojawienie się wyzwania – rozumianego jako ambitna aspiracja, a nie problem – działało motywująco. To właśnie taki cel sprawia, że zespół musi się zmobilizować, zebrać, przestać lekceważyć pewne sprawy, wysilić się i poszukać kreatywności. W efekcie zaczyna brać sprawy w swoje ręce i stara się osiągnąć coś, co na pierwszy rzut oka może wydawać się zbyt duże, zbyt trudne lub nierealne do wykonania w danym czasie.

Zakładamy, że zarówno strategia firmy, jak i produktu istnieje – w większości organizacji faktycznie tak jest. Jednak równie często zdarza się, że choć strategia jest dobrze znana na wyższych poziomach zarządzania i stanowi ich codzienność, to niekoniecznie dociera do zespołów operacyjnych ani liderów pierwszej linii. Właśnie dlatego rolą szefa produktu jest regularne, konsekwentne – a z perspektywy niektórych może nawet nadmierne – przypominanie, na czym polega strategia i dlaczego została przyjęta w takiej formie.

Warto też zaznaczać, czego w strategii nie ma oraz wyjaśniać, jak poszczególne tematy się ze sobą łączą i w jaki sposób podejmowane decyzje wpisują się w szerszy kontekst. O samych decyzjach powiemy więcej w kolejnych punktach.

Nieustanne przypominanie o strategii to w praktyce łączenie kropek między tym, co organizacja chce osiągnąć na poziomie strategicznym, a tym, co faktycznie dzieje się w zespołach. Z perspektywy codziennej pracy członkowie zespołu często koncentrują się na pojedynczych zadaniach, a w najlepszym wypadku – na realizowanych projektach, inicjatywach czy zmianach w produkcie. Brak jasnego powiązania między tymi działaniami a szerszym kontekstem strategicznym może prowadzić do niezrozumienia podejmowanych decyzji czy opracowania rozwiązań, które nie są tak trafne, jak mogłyby być.

Zrozumienie, dlaczego pewne działania są priorytetowe, a inne zostały odłożone na później lub całkowicie pominięte, pozwala zespołom lepiej dopasować swoje działania do kierunku, w jakim zmierza firma. Znajomość strategii firmy i produktu nie tylko ułatwia podejmowanie trafnych decyzji, lecz także wzmacnia poczucie odpowiedzialności w zespole – bo kiedy rozumiemy sens działań, łatwiej nam się z nimi utożsamić i brać za nie odpowiedzialność.

Głównym przesłaniem tej porady jest zachęta, aby nie traktować zespołów jak podwykonawców – czyli grupy, której zleca się precyzyjne zadania i oczekuje jedynie ich wykonania. Warto zamiast tego podejść do zespołu jak do partnera, który posiada samodzielność i świadomość celu. Zespół, rozumiejąc strategię firmy oraz produktu, powinien mieć przestrzeń do kreowania rozwiązań – takich, które najlepiej odpowiadają na potrzeby organizacji, uwzględniając dostępny czas, możliwości, a także ograniczenia technologiczne. Dobrze zbudowany zespół wytwórczy potrafi podejmować trafne decyzje operacyjne, często lepiej niż osoby spoza jego struktury. Wynika to z faktu, że wiele decyzji dotyczy szczegółów, które mogą umknąć radaru osobom zarządzającym wyższymi szczeblami. Właśnie dlatego tak ważne jest umożliwienie zespołowi wpływu na to, jak realizowane są zadania.

Oznacza to, że zespoły mogą być włączone w proces budowania roadmapy oraz aktywnie konsultowane podczas definiowania celów, większych inicjatyw czy kolejnych kroków rozwojowych, które mają zrealizować. W rozmowach na ten temat z osobami zarządzającymi często pojawia się jednak obawa o podejście zero-jedynkowe – słyszę wtedy: „Nie będę ich włączać, bo źle to wymyślą.” Warto więc podkreślić, że ta porada brzmi: włączaj zespoły, a nie przerzuć na zespoły całą odpowiedzialność.

W większości organizacji pełne oddelegowanie tematu rozwiązań na zespoły nie jest w pełni realne. Jeśli w Twojej firmie jest inaczej – to świetnie. W praktyce jednak wiele organizacji znajduje się w innym miejscu. Dlatego mówimy o współtworzeniu – o takim podejściu, w którym zarówno wyższa kadra zarządzająca, jak i zespoły oraz liderzy produktów angażują się we wspólne wypracowanie rozwiązań. Chodzi o unikanie sytuacji, w której zespołom zleca się z góry narzucone, zamknięte rozwiązanie – bez możliwości wpływu na jego kształt.

Ten temat pojawił się już przy omawianiu strategii, ale warto do niego wrócić. W trakcie rozwoju produktu pojawia się wiele decyzji biznesowych – niektóre mogą być dla zespołu niezrozumiałe, inne sprzeczne z wcześniejszymi ustaleniami. Czasami są to decyzje niepopularne, a nawet trudne do przyjęcia. Przykłady? Zamknięcie produktu, rezygnacja z obsługi konkretnego segmentu rynku lub przekazanie części biznesu innemu produktowi w ramach organizacji. Tego typu zmiany potrafią silnie zdemotywować zespół, a w skrajnych przypadkach prowadzić do biernego oporu, jawnego lub ukrytego sabotowania działań czy błędnych interpretacji podejmowanych kroków.

Dlatego tak ważne jest wyjaśnianie zespołom kontekstu podejmowanych decyzji. Pokaż szerszą perspektywę – to, co dla Ciebie jest oczywiste, wcale nie musi być zrozumiałe dla innych. Brak wiedzy o przyczynach danej decyzji może zadziałać demotywująco, a z kolei dobre wyjaśnienie potrafi zbudować zrozumienie i zaangażowanie. To działa także w drugą stronę – jeśli podejmujesz pozytywną decyzję, która otwiera nowe możliwości, pokaż zespołowi, skąd się wzięła. Pozwól im poczuć satysfakcję i entuzjazm, który towarzyszy ci w danym momencie.

Patrząc na tę poradę w dłuższej perspektywie, regularne wyjaśnianie kontekstu biznesowego sprawia, że zespoły z czasem znacznie lepiej rozumieją środowisko, w którym funkcjonują. Wiedzą, dlaczego z pewnych działań się rezygnuje, a inne należy realizować w określony sposób.Nic nie demotywuje tak bardzo jak komunikat: „Od teraz robimy tak” – bez podania przyczyn czy szerszego uzasadnienia. W praktyce często prowadzi to do frustracji. Zespoły, które wielokrotnie spotykają się z takim podejściem, zaczynają reagować z sarkazmem i dystansem. W skrajnych przypadkach pojawia się przekonanie: „Cokolwiek powiemy, i tak zrobią po swojemu”. To z kolei prowadzi do postawy: „Wykonujemy swoje zadania, ale efekt końcowy nas nie interesuje”. Taki zespół potrzebuje zrozumieć powody decyzji. To pozwala mu utożsamiać się z celem, podejmować lepsze decyzje na co dzień i realnie dbać o rezultat końcowy.

W tej poradzie pojawiają się dwa istotne elementy: eksperymentowanie i popełnianie błędów. Eksperymentowanie zazwyczaj przychodzi z łatwością, ale akceptacja ewentualnych pomyłek już niekoniecznie. W organizacjach, w których odpowiedzialność produktowa jest niska, zespoły często unikają podejmowania decyzji. Gdy dopytujemy, z czego to wynika, okazuje się, że w tle pojawiają się wspomnienia sytuacji, w których popełnione błędy spotkały się z nieprzychylną reakcją. Może to dotyczyć nietrafionych pomysłów produktowych, rozwiązań procesowych, które okazały się nieefektywne, albo decyzji prowadzących do problemów.

Przy budowaniu odpowiedzialności trzeba pamiętać, że nie każda decyzja zespołu będzie idealna. Błędy są częścią procesu i należy się ich spodziewać, szczególnie gdy zespół dopiero zaczyna podejmować samodzielne decyzje. Warto zacząć od mniejszych tematów, które w razie niepowodzenia nie spowodują dużych strat. Nawet jeśli pojawią się potknięcia, to będzie okazja do nauki.

Kluczowe jest to, by zespół miał przestrzeń do eksperymentowania, czuł wsparcie i wiedział, że ktoś mu ufa. Chodzi o to, by stopniowo budować odwagę i samodzielność, a jednocześnie zachować zdrowy balans. Szef produktu powinien pełnić rolę bezpiecznika – zadbać, by decyzje nie były podejmowane chaotycznie, bez przemyślenia.

Przy popełnionych błędach ważne jest, by zamiast skupiać się na pytaniu „dlaczego się pomyliliście?”, zapytać „czego się nauczyliście?” i „co możecie zrobić, żeby to się nie powtórzyło?”. Systematyczne wyciąganie wniosków z błędów jest kluczowe. W przypadku problemów procesowych chodzi o to, by zidentyfikować przyczynę i znaleźć rozwiązanie zapobiegające podobnym sytuacjom w przyszłości.

Jeśli chcesz jeszcze bardziej pogłębić swoją wiedzę zajrzyj na stronę porzadnyagile.pl/sklep. Znajdziesz tam nasze płatne produkty, które pomogą ci jeszcze skuteczniej rozwijać Twoje umiejętności. 

Esencją tej porady jest myśl, że zespoły funkcjonują zupełnie inaczej, gdy mają od A do Z rozpisane, co dokładnie mają zrobić, w porównaniu do sytuacji, gdy stawia się im poprzeczkę wyżej. Najważniejsze są efekty – nie sposób, w jaki zespół zrealizuje założenia.

Przekazanie odpowiedzialności za osiągnięcie konkretnego rezultatu i pozostawienie zespołowi decyzji, jak do niego dojść, to moment, w którym rodzi się prawdziwa odpowiedzialność. Pojawiają się pomysły, koncepcje, a zespół zaczyna czuć więź z wypracowanymi rozwiązaniami. W efekcie wzrasta zaangażowanie i zmienia się podejście do pracy – jeśli coś jest „nasze”, bardziej nam na tym zależy. Małe sukcesy cieszą, a porażki stają się osobistą motywacją do poprawy.

Takiego podejścia często brakuje, gdy zespół pracuje w trybie „klepania tasków” – wykonuje zadania bez refleksji, czy wyjdzie dobrze, czy nie. Przesunięcie odpowiedzialności w stronę zespołu i pozwolenie mu decydować, jak osiągnąć cele, może diametralnie zmienić poziom zaangażowania i jakość pracy.

Zarządzającym bardzo łatwo zgodzić się z tą poradą – wielu może mieć odruch, że przecież stosują to od dawna. W praktyce jednak diabeł często tkwi w szczegółach. Przykład (wymyślony, niepowiązany z żadnym klientem): wielu zarządzających uważa, że dodanie funkcji do aplikacji to efekt. Tymczasem to jedynie zakres prac. Efektem będzie dopiero np. wzrost sprzedaży, który ta funkcja umożliwi.

Warto dać zespołom przestrzeń do szukania skrótów i odcinania się od utartych wyobrażeń. Nawet jeśli wydaje się, że konkretne elementy zakresu są kluczowe, priorytetem powinny być rezultaty biznesowe. Wracając do przykładu aplikacji – zwłaszcza w dużych organizacjach zespoły technologiczne często słyszą: „postawcie platformę” czy „zbudujcie aplikację” jako oczekiwany efekt. Tymczasem prawdziwym celem może być pierwsza sprzedaż na platformie, pozyskanie puli klientów czy osiągnięcie dochodu z oferowanych funkcji.

Takie spojrzenie poszerza perspektywę. Praca zespołu technologicznego to tylko część układanki. Efekt końcowy wymaga także marketingu, sprzedaży, wsparcia prawnego i operacyjnego. To z kolei mocno nawiązuje do tematu współpracy biznesu i IT, o którym pisaliśmy w jednym z wcześniejszych artykułów.

Chodzi o to, aby zespół miał stały dostęp do regularnych informacji zwrotnych – poprzez odpowiednie rozwiązania, narzędzia i systemy. Feedback od klientów jest kluczowy dla budowania poczucia odpowiedzialności. Nie mówimy tutaj wyłącznie o okazjonalnym wglądzie w wyniki badań, jednorazowych grupach fokusowych czy sporadycznym pytaniu kilku osób o opinię. Istotne jest stworzenie systemu, który umożliwi zespołom łatwe i ciągłe zbieranie informacji zwrotnej.

Zespół powinien mieć możliwość konsultacji oraz testowania swoich pomysłów z rynkiem – zarówno w przypadku rozwiązań będących w fazie rozwoju, jak i tych już funkcjonujących. Ważne jest odejście od ideii „wymyślić, wdrożyć i zapomnieć” na rzecz stałego kontaktu z klientem docelowym. Zaznaczając również, kto jest docelowym klientem. 

Choć można oczekiwać, że zespoły same będą myśleć w ten sposób, to rolą szefa produktu jest stworzenie w organizacji warunków do regularnego pozyskiwania prawdziwego feedbacku. Chodzi o informacje pochodzące bezpośrednio od klientów – a nie tylko od szefa, członka zarządu czy innej ważnej osoby w firmie. To właśnie głos klientów powinien być głównym źródłem wiedzy dla zespołów.

Po pierwsze – im bardziej bezpośredni i oryginalny jest feedback, tym lepiej. Chodzi o to, aby zespoły miały dostęp do rzeczywistych słów klientów, a nie do informacji przefiltrowanych przez kolejne osoby w organizacji. Bezpośrednie rozmowy, konkretne ankiety czy rzeczywiste wypowiedzi klientów są znacznie bardziej wartościowe niż przekazany „głuchym telefonem” komentarz, który może być już zniekształcony.

Po drugie – choć ta porada może brzmieć oczywiście, w praktyce nie zawsze jest tak łatwo wdrożyć ją w życie. W wielu firmach, mimo dostępu do danych i feedbacku, system pracy zespołów jest zorganizowany w taki sposób, że sięganie po te informacje wydaje się zbędne lub postrzegane jest jako strata czasu. Priorytetem staje się programowanie, testowanie czy projektowanie, a analiza danych od klientów spychana jest na dalszy plan. Warto więc zwrócić uwagę, czy zespoły rzeczywiście korzystają z możliwości pozyskiwania feedbacku. Jeśli nie – warto zrozumieć, co stoi za takim podejściem i co sprawia, że mimo dostępnych danych, zespoły po nie nie sięgają.

To wskazówka z innego poziomu – bardziej managerska – ale niezwykle istotna. Choć może wydawać się oczywista, nasze doświadczenia pokazują, że takie rozmowy nie odbywają się tak często, jak mogłyby. Wiele osób pracujących w rolach produktowych lub technologicznych, zwłaszcza na poziomie zespołów, przyznaje, że ich przełożeni nie znajdują dla nich czasu. Słyszymy komentarze w stylu: „Mój szef za bardzo ze mną nie rozmawia” albo „Nie ma dla mnie czasu”.

Mówiąc o rozmowach jeden na jeden, mamy na myśli regularne spotkania – najlepiej raz w tygodniu lub co dwa tygodnie. Tymczasem w wielu organizacjach takie rozmowy odbywają się co kwartał lub jedynie podczas oficjalnych podsumowań. Trudno oczekiwać, że zespół przejdzie naturalną drogę od braku odpowiedzialności do jej pełnego przejęcia, jeśli nie ma okazji do regularnych rozmów, wymiany myśli i wspólnego reflektowania nad pracą.

Rozmowy z przełożonym, który staje się mentorem i inspiruje do działania, mają ogromne znaczenie. Co ważne, to niewielka inwestycja – wystarczy poświęcić czas i pełną uwagę,. Dlatego szczególnie zachęcamy do wprowadzenia tej praktyki, zwłaszcza jeśli do tej pory takich spotkań nie organizujesz. Regularny dialog to jedno z najprostszych, a zarazem najskuteczniejszych narzędzi budowania odpowiedzialności i zaangażowania w zespole.

Każdy ma swój styl prowadzenia rozmów jeden na jeden. Są jednak dwa kluczowe elementy, które warto w takich spotkaniach uwzględnić.

Tego typu spotkania to również świetna okazja, by poruszyć tematy, o których mówiliśmy wcześniej: przypomnieć strategię, wyjaśnić podjęte decyzje – zwłaszcza te mniej popularne – czy omówić popełnione błędy i wyciągnięte z nich wnioski. 

To wskazówka mocno managerska, wynikająca z częstego przekonania, które często słyszymy od osób kierujących zespołami: „Mój zespół nie może dostać większej odpowiedzialności, bo jeszcze nie jest na to gotowy.” Taka opinia zwykle opiera się na konkretnej historii – może dotyczyć zbyt małego doświadczenia, braku udziału w dużych inicjatywach lub niewystarczająco rozwiniętych umiejętności. Czasem odnosi się do pojedynczych Product Ownerów, czasem do liderów zespołów, a bywa, że dotyczy całych struktur.

Rozwiązaniem tego problemu jest zaplanowany, długofalowy rozwój członków zespołu. Chodzi o to, by już na etapie zatrudnienia – nawet przy przyjmowaniu juniora – mieć wizję tego, jak dana osoba może się rozwijać. Może dziś nie jest gotowa, może za dwa lata wciąż będzie potrzebować wsparcia, ale z odpowiednim planem i pracą za pięć lat może stać się kluczowym członkiem zespołu gotowym na większą odpowiedzialność.

W niektórych organizacjach od razu zatrudnia się doświadczonych specjalistów. W innych – ze względu na budżet, specyfikę firmy lub sytuację rynkową – nie zawsze jest to możliwe. Bez względu na podejście, warto rozwijać pracowników nawet wtedy, gdy są już na wysokim poziomie. Dobrze zaplanowana ścieżka rozwoju pozwala im osiągać kolejne szczeble kariery i przejmować coraz bardziej odpowiedzialne role.

Zarządzając zespołem, warto również myśleć o budowaniu następców. To ważne zwłaszcza dla osób na wyższych stanowiskach managerskich. Brak kogoś, kto może przejąć obowiązki, często blokuje awanse. Z kolei posiadanie przygotowanego następcy otwiera drzwi do nowych możliwości – zarówno dla przełożonego, jak i dla całej organizacji.

Ścieżki rozwoju mogą być w różnych firmach traktowane na wiele sposobów. Często mają one charakter ogólny – na przykład dla Product Managera istnieje jasno zdefiniowana ścieżka z poziomami rozwoju, od juniora do eksperta. To podejście jest pomocne, ale nie wyklucza bardziej indywidualnego podejścia do rozwoju konkretnej osoby.

Pracując z członkami zespołu jeden na jeden, warto ustalać także spersonalizowane cele. Jacek w swojej pracy managerskiej, gdy zarządzał strukturą Product Ownerów, stosował właśnie takie podejście. Oprócz standardowej ścieżki rozwoju, opracowanej we współpracy z działem HR, Jacek uzgadniał z poszczególnymi osobami dodatkowe cele dopasowane do ich bieżących wyzwań i potrzeb. Te indywidualne cele nie były sprzeczne ze ścieżką rozwoju – raczej ją uzupełniały, wypełniając najważniejsze luki kompetencyjne.

Jak dojść do tego, co warto rozwijać? Kluczowe są rozmowy oraz moja dobra znajomość projektów, w których dana osoba uczestniczy. Dzięki temu łatwo jest określić, jakie konkretne umiejętności są potrzebne w danym momencie. Ustalasz wspólnie, co należy wzmocnić, wyznaczasz ramy czasowe i określasz, jakie wsparcie będzie potrzebne, aby osiągnąć zamierzony cel.

Wspomnieliśmy już o tym wcześniej, ale ten punkt podkreśla, że przekazywanie odpowiedzialności nie jest czymś, co wydarzy się z dnia na dzień. To proces zmiany, którym warto świadomie zarządzać. Przede wszystkim potrzebna jest decyzja, że chcesz nad tą zmianą pracować. Kluczowe będzie przeprowadzenie rozmów z osobami, których ta zmiana dotyczy. Ich zrozumienie i wsparcie są niezbędne, a na drodze pojawi się zapewne wiele wątpliwości, które należy zaadresować.

Budowanie odpowiedzialności wiąże się również z koniecznością zdobycia odpowiedniej wiedzy i umiejętnością jej praktycznego wykorzystania. Istotne jest także monitorowanie efektów tego procesu. Warto celebrować momenty, w których wzmocnienie odpowiedzialności przyczynia się do widocznych sukcesów zespołu. Jednocześnie należy być przygotowanym na sytuacje, w których zmiany nie przynoszą oczekiwanych rezultatów – wtedy dobrze mieć gotowy plan działań korygujących.

Jednym z elementów planowania procesu przekazywania odpowiedzialności może być jawne pokazanie uprawnień decyzyjnych. Warto określić, kto i w jakich sytuacjach ma prawo podejmować decyzje. Czasami zespół może decydować od razu, innym razem uprawnienia te będą przekazywane stopniowo, w miarę rozwoju kompetencji.

W praktyce pomocne może być narzędzie Delegation Board – jedno z rozwiązań proponowanych w nurcie Management 3.0. Pozwala ono jasno wypisać konkretne przypadki i obszary, w których podejmowane są decyzje. Celem jest osiągnięcie pełnej przejrzystości oraz uniknięcie nieporozumień w zespole. Taki dokument może również stać się punktem wyjścia do długofalowej rozmowy o tym, co musi się wydarzyć, by zespół mógł decydować samodzielnie, a także w jakich sytuacjach potrzebna będzie konsultacja czy akceptacja przełożonego.

Zachęcamy do tego, by nie odkładać tego tematu i nie zakładać, że odpowiedzialność „zbuduje się sama”. Warto podejść do niej świadomie, stopniowo przekazując ją poszczególnym osobom lub zespołom, wspierając ich rozwój i jednocześnie dbając o stabilność całej struktury.

W ramach tego punktu przypomina nam się sytuacja z początków pracy jako konsultanta w 202 Procent. Wspieraliśmy wtedy firmę, która mierzyła się z interesującym problemem. Product Ownerzy twierdzili, że nie mają odpowiedzialności, natomiast osoba z zarządu odpowiedzialna za ich pracę komunikowała, że „oni w ogóle nie biorą odpowiedzialności”. Sprzeczne sygnały z obu stron były dość zaskakujące.

Rozwiązaniem okazały się dwie rozmowy z wykorzystaniem narzędzia Delegation Board, o którym wspominaliśmy wcześniej. Technika ta pomogła wyjaśnić wzajemne oczekiwania: Product Ownerzy uświadomili sobie, że mają znacznie większe możliwości decyzyjne, niż zakładali, a osoby zarządzające zobaczyły, że można bez obaw przekazać część odpowiedzialności zespołom.

To pokazuje, że temat ten wcale nie jest oczywisty. Warto o nim rozmawiać i doprecyzować, gdzie leżą granice odpowiedzialności – dla dobra obu stron i sprawniejszego funkcjonowania organizacji.

Podsumowując, wzmacnianie odpowiedzialności za produkt przez szefa produktu polega na wyznaczaniu ambitnych celów, regularnym przypominaniu strategii firmy i produktu, angażowaniu zespołów w kreowanie rozwiązań oraz wyjaśnianiu kontekstu biznesowego podejmowanych decyzji.

Równocześnie warto umożliwiać eksperymentowanie i dbać o to, żeby z tych eksperymentów były wyciągane wnioski. Kluczowe jest oczekiwanie efektów zamiast realizowania sztywnych zakresów. Pomocne może być również zapewnienie zespołom dostępu do feedbacku od klientów, regularna praca jeden na jeden oraz stworzenie ścieżek rozwoju.

Jeżeli Twoja firma korzysta z technik pracy zespołowej inspirowanej Scrumem i masz poczucie, że efektywność pracy twoich zespołów wymaga poprawy, odezwij się do nas po diagnozę i eksperckie rekomendacje dotyczące procesu wytwórczego. Dopasujemy nasze porady do konkretnego kontekstu Twojej firmy i wesprzemy zmiany, których potrzebujesz. Sprawdź naszą ofertę na stronie porzadnyagile.pl/diagnoza.

Ambitne cele motywują zespół do poszukiwania nowych, kreatywnych rozwiązań i wychodzenia poza utarte schematy. Dają poczucie sensu i pozwalają zespołowi poczuć, że ich praca ma realny wpływ na rozwój produktu.

Regularne przypominanie strategii pozwala zespołom lepiej rozumieć swoje działania w szerszym kontekście. Dzięki temu łatwiej podejmują decyzje zgodne z długoterminowymi celami firmy, zamiast skupiać się jedynie na bieżących zadaniach.

Zrozumienie kontekstu pozwala zespołowi lepiej ocenić priorytety i podejmować świadome mniejsze decyzje. Brak tej wiedzy może prowadzić do błędnych założeń, frustracji i braku motywacji do realizacji zmian.

Organizacje, które pozwalają na eksperymentowanie i wyciąganie wniosków z błędów, budują środowisko sprzyjające innowacjom. Zbyt surowe podejście do pomyłek sprawia, że ludzie boją się podejmować inicjatywę i wybierają bezpieczne, ale mniej efektywne rozwiązania.

Regularny kontakt z opiniami użytkowników pozwala zespołom na szybsze dostosowywanie produktu do realnych potrzeb. Brak takiej informacji sprawia, że zespoły pracują „w próżni”, podejmując decyzje na podstawie domysłów zamiast faktów.

Warto obserwować, czy zespół podejmuje inicjatywę, rozwiązuje problemy samodzielnie i potrafi wyciągać wnioski z błędów. Gotowość do większej odpowiedzialności objawia się również w proaktywnym podejściu do strategii i długoterminowych celów.

Spotkania 1:1 pomagają liderom lepiej zrozumieć potrzeby i wyzwania swoich pracowników. To również okazja do przekazywania konstruktywnego feedbacku i wspólnego szukania rozwiązań, co wzmacnia poczucie odpowiedzialności.

Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”.

Jacek: Dawno temu nagraliśmy z Kubą odcinek o budowaniu odpowiedzialności za produkt. Ale był to odcinek kierowany bardziej do Product Ownerów i do Scrum Masterów. Znajdziesz go pod adresem porzadnyagile.pl/31. Tytuł brzmiał: „Wzmacnianie odpowiedzialności zespołu za produkt”. Był to jeden z naszych ostatnich odcinków przed covidem, przed lockdownem. Pamiętam nagrywany w aucie zaparkowanym gdzieś w jakimś lasku koło opuszczonej żwirowni. Dzisiaj chcemy nagrać w trochę innych realiach podobną tematykę, ale adresowaną świadomie do osób zarządzających kilkoma zespołami, kilkoma produktami czy większą strukturą produktową.

Kuba: Mamy dla Ciebie 10 porad na temat tego, co zarządzający taką strukturą produktową może zrobić, żeby zbudować odpowiedzialność zespołów wytwórczych za produkt, którym się zajmują te jego zespoły.

Jacek: Spis treści na dzisiaj jest następujący. Jakie mamy porady dla szefa produktu, by budować odpowiedzialność zespołów? Wyznaczaj ambitne cele. Nieustannie przypominaj strategię firmy i produktu. Włączaj zespoły w kreowanie rozwiązań. Wyjaśniaj kontekst biznesowy swoich decyzji.

Kuba: Pozwalaj eksperymentować i popełniać błędy. Oczekuj efektów, a nie dowożenia zakresów. Zapewnij zespołom dostęp do feedbacku od klientów. Znajdź czas na pracę jeden na jeden ze swoimi ludźmi. Stwórz ścieżki rozwoju dla członków zespołu i zaplanuj proces wzmacniania odpowiedzialności.

Jacek: I mówimy w tym odcinku szef produktu i sobie to tak zdefiniowaliśmy, że w ten sposób będziemy komunikować, o kim myślimy, podczas nagrywania tego odcinka. Natomiast to może oznaczać zbiór bardzo różnych funkcji, które przyjmują różne nazwy w filmach. To może być Chief Product Owner, to może być jakiś taki wyżej gdzieś zamocowany Product Manager, to może być osoba, która ma tytuł Head of Product, to może być Product Director, to może być Head of Product and Technology, więc jakby bardzo pojemna grupa osób, których dla uproszczenia, no bo każda struktura jest inna, nazywamy po prostu szefem produktu. Opisowo chodzi nam tutaj o osoby, które zarządzają Product Ownerami, Product Managerami, całymi zespołami rozwijającymi produkt. Osoby, które są odpowiedzialne nie tylko za poszczególny produkt czy produkty, ale też za cały proces wytwarzania, strukturę, która jest z tym procesem powiązana oraz pewną filozofię, filozofią zarządzania rozwojem.

Kuba: Ok, to przechodząc do konkretu, pierwsza porada z naszej strony. Jak szef produktu może wzmocnić odpowiedzialność zespołów za produkt?

Jacek: Pierwsza porada, którą przygotowaliśmy, brzmi wyznaczaj ambitne cele. Wszystko zaczyna się od konkretnego, ambitnego, namacalnego celu i chcemy tutaj podkreślić, że warto w tej kwestii być wizjonerem, pokazywać trochę dalszy obrazek niż być może zespoły na ten moment są w stanie zobaczyć. To jest też powiązane z tym, że chcielibyśmy oczekiwać więcej i sprawiać, że zespół w kontekście rozwiązywania tego ambitnego celu będzie musiał poszukać jakiegoś mniej oczywistego rozwiązania. Czyli troszeczkę się napracować i troszeczkę się zastanowić, jak do tego rozwiązania podejść, co jak słyszysz, już jest pewną taką zachętą do tego, żeby wziąć sprawy w swoje ręce, żeby tą odpowiedzialność budować. Te rozwiązania mogą być nieoczywiste, natomiast może jest jakieś ograniczenie czasowe i trzeba się zastanowić, jak przy ograniczonym czasie stworzyć coś, co ma sens. Może będzie trzeba dokonać jakichś radykalnych uproszczeń, może będzie trzeba sięgnąć na jakąś nową technologię, albo zrobić coś, co z perspektywy organizacji, w której jesteś, jest nieoczywiste, jest nowe, jest czymś zupełnie zaskakującym i świeżym.

Kuba: A jeśli czujesz, że żaden z tych przypadków wymienionych przez Jacka akurat u Ciebie nie ma miejsca, to tym bardziej ta porada jest dla Ciebie, bo być może z perspektywy szefa produktu trochę tę sytuację trzeba utworzyć, zasymulować, tak troszkę sprowokować czy postawić zespoły w takiej sytuacji, w której jednak ten ambitny cel się pojawia. Bo mamy tu na myśli odwrócenie tej sytuacji, taką niekorzystną sytuację, gdy zespoły są takie troszkę rozleniwione, nie mają wyzwań, te cele, które są przed nimi, są takie miałkie, takie lightowe, takie letnie. No i wtedy te cele, brak tych ambitnych celów między innymi przyczynia się do jakiegoś takiego rozluźnienia i takiego poczucia, dobra, zrobię swoje, jakoś to tam się wszystko później złoży, będzie dobrze. A sami mamy doświadczenia bardzo pozytywne z bardzo różnych organizacji, że coś, co jednak jest jakimś rodzajem wyzwania, w tym pozytywnym znaczeniu nie problemu, tylko jakiegoś rodzaju pewnej dosyć ambitnej aspiracji, są jednym z takich bazowych fundamentów tego, że zespół jednak musi się ogarnąć, zebrać, nie żartować z pewnymi sprawami, wysilić, poszukać kreatywności i w efekcie faktycznie wziąć sprawę w swoje ręce i spróbować osiągnąć coś, co może na pierwszy rzut oka wydaje się trochę za duże, za trudne albo za krótki horyzont czasowy.

Kuba: Druga porada. Nieustannie przypominaj strategię firmy i produktu. Z zasady w tej poradzie przyjmujemy założenie, że ta strategia i dla firmy, i dla produktu jest i to w większości organizacji jest prawda, ale też dla wielu organizacji prawdą jest to, że ta strategia firmy i produktu, choć żyje na wyższych poziomach zarządzania i jest jakąś codziennością, to niekoniecznie jest znane na pamięć i niekoniecznie żyją tym konkretne zespoły czy konkretne osoby będące liderami pierwszych poziomów. Dlatego rolą szefa produktu może być ciągłe, nieustanne, może nawet troszkę nadmierne z tej perspektywy tej osoby przypominanie, co jest w tej strategii i dlaczego jest właśnie to w strategii. Może też z taką dopowiedzią, a czego nie ma, albo jak pewne tematy się ze sobą łączą, czy pewne decyzje się układają. Ale o decyzjach jeszcze powiemy za chwilę.

Jacek: Teraz nieustanne przypominanie, ja bym to tak nazwał, że to jest takie łączenie kropek pomiędzy tym, co organizacja chce strategicznie osiągnąć i dokąd zmierza, a tym, co się dzieje faktycznie na poziomie zespołu, gdzie jednak ludzie patrzą na prace trochę bardziej z perspektywy, jakieś zadań, tasków, może patrząc nawet trochę wyżej pewnych być może jednak projektów, inicjatyw czy zmian, które są realizowane w produkcie. Natomiast brak tego połączenia może powodować, że pewne decyzje będą niezrozumiałe, pewne rozwiązania będą stworzone nie tak dobrze, jak mogłyby być stworzone, gdyby ktoś rozumiał bardzo dobrze, w jaki sposób to będzie wykorzystywane, dlaczego to robimy tak, a nie inaczej, czy też łatwiej jest zrozumieć decyzję, że z pewnych rzeczy rezygnujemy, chociaż ktoś mógłby mieć apetyt na to, żeby jakieś konkretne funkcje do produktu dołożyć. Więc znajomość tego, jaka jest strategia firmy, jaka jest strategia produktu, pomaga podejmować decyzje i też umożliwia budowanie poczucia odpowiedzialności. No bo tak naprawdę zaczynamy rozumieć, po co to wszystko się dzieje.

Jacek: Trzecia porada dla szefa produktu to włączaj zespoły w kreowanie rozwiązań. Myślę, że taką główną myślą, która stoi za tą poradą, jest myśl, żeby nie traktować zespołów jak podwykonawców, czyli taką grupę, której zleca się bardzo precyzyjnie, co jest do zrobienia no i oczekujemy, że po prostu zostanie ta praca wykonana. A raczej chciałbym tutaj mieć raczej do współpracy zespół, który ma pewną samodzielność, ma pewną świadomość i chciałbym pozwolić takiej grupie nie tylko wykonywać pracę, ale też rozumiejąc strategię firmy, produktu, rozumiejąc cel, kreować rozwiązania. Kreować najlepsze możliwe rozwiązania, biorąc pod uwagę dostępny czas, dostępne możliwości, ale też pewne szanse czy ograniczenia, które wynikają z technologii. Nikt lepiej, jak dobrze skonstruowany zespół wytwórczy, nie będzie w stanie podjąć pewnych decyzji. Bo są to decyzje zwykle dosyć niskopoziomowe, które po prostu mogą być troszeczkę poniżej radaru osób znajdujących się powyżej poziomu zespołów.

Kuba: Oznacza to też, że zespoły mogą być włączone w proces budowania Roadmap’y, w jakiś mocny sposób konsultowane też w tym procesie kreowania celów, konkretnych większych inicjatyw, które to są zrobienia czy pewnych kroków rozwojowych, jakie te zespoły mogą zrealizować. Natomiast takie zastrzeżenie, gdy rozmawiam w guście tej porady z niektórymi zarządzającymi, to często widzę, że mój rozmówca słyszy takie bardzo zero-jedynkowe podejście, że nie, nie będę ich włączał, bo oni źle to wymyślą. Jednak akcent położymy na to, jak brzmi ta porada, włączaj zespoły, a nie przerzuć całość zespołom. W większości organizacji pewnie będzie to nie do końca realne, żeby całkowicie oddelegować temat rozwiązań na zespoły i zostawienia im pełnej swobody. Jeśli w twojej organizacji tak jest, to gratuluję. W większości organizacji jednak jest w trochę innym miejscu. No i tutaj mamy na myśli jakiś rodzaj bycia współrealizatorem pewnego procesu. Zarówno wyższy zarządzający, zespoły, liderzy produktów w tych zespołach, wszyscy razem mogą być w jakiś mądry i ciągle doskonalony sposób angażowani, włączani w to, żeby uniknąć tego, od czego Jacek zaczął, czyli takiego zjawiska po prostu zlecenia zespołom z góry zamkniętego kawałka rozwiązania.

Kuba: Czwarta porada, wyjaśniaj kontekst biznesowy swoich decyzji. Trochę już to zaznaczyliśmy przy strategii i tutaj jakby temat wraca. W czasie rozwoju produktu będzie wiele decyzji biznesowych, niektóre z nich niezrozumiały dla zespołu, niektóre być może sprzeczne z poprzednimi decyzjami. Będą też decyzje bardzo niepopularne, żeby tutaj z najgrubszego kalibru rzucić rzeczy. Zamknięcie produktu, rezygnacja z pewnego segmentu rynkowego, do którego przestajemy adresować nasze rozwiązania, czy na przykład decyzja o tym, że jakiś inny produkt, jaki jest w portfelu tej organizacji, przejmuje jakiś kawałek biznesu. To są wszystko rzeczy, które powodują sporą demotywację w zespołach. Mogą być też jawnie lub niejawnie sabotowane, czy powodować jakieś błędne zachowania w zespołach. Dlatego tutaj mocna porada, mocna przestroga. Wyjaśniaj te decyzje, pokaż większy obrazek. Pokaż to, co dla Ciebie jest oczywistością, bo zapadła taka decyzja i wiesz, dlaczego tak jest. Ale w zespołach może to być niezrozumiane, źle odebrane i na tej bazie akurat demotywująco działać na zespoły. Ale w drugą stronę też może to zadziałać, czyli jeśli są jakieś ciekawe, fajne potencjały, to pokażmy tę szansę. Pokażmy, dlaczego zapadła pewna też pozytywna decyzja, żeby zespoły poczuły ten sam smak satysfakcji, czy jakiejś takiej emocji pozytywnej, jaką też Ty czujesz w tej sytuacji.

Jacek: I długoterminowo patrząc na tę poradę, no to po pewnym czasie zespoły będą o wiele lepiej rozumieć środowisko biznesowe, w którym się poruszają, doskonale wiedząc, dlaczego z pewnych rzeczy rezygnujemy, doskonale rozumiejąc, dlaczego pewne rzeczy powinniśmy realizować w jakiś tam konkretny sposób. Myślę, że nie ma nic bardziej demotywującego, niż komunikat z góry od teraz jest tak, bez wyjaśnienia kontekstu. Wielokrotnie doświadczałem frustracji w zespołach, które w pewnym momencie już po prostu zaczynają podśmiechiwać się i tak trochę sarkastycznie z przekąsem komentować, że cokolwiek powiedzą to zrobimy, no i po prostu robią swoje, ale to nie jest taki zespół, o którym my w tym odcinku mówimy, to nie jest zespół, który jest odpowiedzialny, który jest zmotywowany, tylko niestety każda taka bezkontekstowa decyzja, niewyjaśniona raczej moim zdaniem, spycha ich na tę stronę. Będziemy robić to, co nam każą i w sumie nie interesuje nas rezultat końcowy.

Jacek: Piąta porada, pozwalaj eksperymentować i popełniać błędy. Jest to taka porada, która jest powiązana z tym, że odpowiedzialność, czy jak przy przekazywaniu odpowiedzialności, budowanie odpowiedzialności jest pewnym procesem, no i musisz być gotowy na to, że decyzje, które będą podejmowane przez zespół, nie zawsze będą idealne, nie zawsze będą właściwe. Mogą pojawić się błędy, mogą pojawić się drogi, które okażą się ślepymi uliczkami, ale to jest część procesu. Oczywiście należy przemyśleć, jakie decyzje dawać zespołowi w pierwszej kolejności, na początku ich przygody. No i pewnie będą to decyzje czy zmiany mniejszego kalibru, które spowodują, że nawet jeżeli zespół się potknie, nawet jeżeli popełni błąd, jeżeli wyjdzie na przykład w procesie wytwarzania jakiejś zmiany, że zabrakło pewnego kontekstu, która dla Ciebie jest oczywista, no to nadal to jest OK. W tej poradzie zachęcamy do tego, żeby była przestrzeń na eksperymenty, żeby zespół poczuł pewną autonomię, że mogą, że ktoś im ufa, żeby troszeczkę ich też, tak bym powiedział, rozkręcić w tym, żeby coraz śmielej funkcjonować. No ale pamiętajmy nadal, jako szef produktu jest też bezpiecznikiem, który zapewnia, że z tego nie zrobi się jakieś YOLO i podejmowanie losowych decyzji. No tylko, że jednak to będzie pewien uporządkowany proces i odpowiedzialność stopniowo i w jakiś tam konkretny, sensowny, zaplanowany sposób będzie na poziomie zespołu się zwiększać.

Kuba: A ja tak trochę z przekąsem zaakcentuję mocniej, że w poradzie są dwa zjawiska łącznie, czyli eksperymentowanie i popełnianie błędów, bo eksperymentowanie przychodzi z łatwością, zgoda na eksperymentowanie, ale niekoniecznie łatwo idzie za nią zgoda na to, że mogą się pojawić błędy. Jak patrzę na organizacje, w których ta odpowiedzialność produktowa nie jest na wystarczającym poziomie, to jednym ze zjawisk, jak się zaczynam pytać głębiej, z czego wynika to, że na przykład nie bierzecie na siebie pewnych decyzji, albo boicie się zaryzykować, boicie się wejść w coś bardziej kreatywnego niż takie z góry zlecone kawałki, to dosyć często się pojawia jednak jakieś wspomnienie, na przykład niekorzystnych reakcji na to, że jednak ta decyzja była błędna, jednak jakiś pomysł produktowy nie wyszedł, jakieś rozwiązanie procesowe okazało się kłopotliwe albo wręcz szkodliwe. Więc tutaj bardzo ważne komunikaty, które warto ciągle powtarzać, to to, że zwłaszcza jeśli zespół ma być innowacyjny, kreatywny, jeśli zespół ma brać na siebie pewne ryzyko, to częścią tego ryzyka również będzie popełnianie błędów i to jest ok, że te błędy są popełnione. Ważne, że z nich są wyciągnięte wnioski, więc to, co Jacek na samej końcówce mówiłeś, że jest jakby systematyczność pewna, to nie chodzi o systematyczność w unikaniu błędów, tylko systematyczność w tym, żeby błędy dawały wnioski. Czyli bardziej nie dopytuj, dlaczego popełniono błąd, a może większy nacisk postaw na to, czego nauczyliście się z tego błędu i może ewentualnie i co zrobicie, żeby ten błąd się nie powtórzył. Zwłaszcza jeśli to jest coś procesowego, bo eksperymenty z rynkiem pewnie ciągle będą miały przygody, ale już zwłaszcza takie rzeczy, że popełniliśmy jakiś błąd i z tego powodu mieliśmy awarie, to to jest dobry temat. Ok, to, czego się nauczyliście i na tej bazie co zrobicie, żeby to już się nie powtórzyło albo żeby nawet podobne przypadki również przewidzieć i uniknąć ich w przyszłości.

Kuba: I, zanim przejdziemy do szóstej porady, przypominamy, że jeżeli chcesz pogłębić wiedzę jeszcze bardziej, niż robimy to w podcaście, to nasze płatne produkty znajdziesz na stronie porzadnyagile.pl/sklep.

Jacek: Szósta porada, oczekuj efektów, a nie dołożenia zakresów. Esencją tej porady jest taka myśl, że zupełnie inaczej funkcjonują zespoły, które od A do Z mają rozpisane dokładnie, co mają zrobić, a zupełnie inaczej zespoły, którym stawiamy poprzeczkę wyżej. Czyli na koniec dnia nie interesuje mnie, w jaki sposób zrealizujecie pewne założenia, mnie tak naprawdę interesują efekty. W momencie, kiedy przekazujemy tę odpowiedzialność, że jest pewien efekt do osiągnięcia, a w zespole, po stronie zespołu pozostaje decyzja, w jaki sposób do tego dojdziemy, to to jest to miejsce, gdzie zaczyna się rodzić odpowiedzialność. Rodzą się pewne pomysły, rodzą się pewne koncepcje, zespół czuje więź z tymi pomysłami, to jest ich, zależy im na tym no i jest zupełnie inny poziom zaangażowania, zupełnie inny poziom podejścia do pracy. Jeżeli to jest nasze, jeżeli mamy na to wpływ, bo wtedy każdy mały sukces cieszy, każda porażka jest odbierana tak bardzo osobiście, na zasadzie musimy to zrobić lepiej za kolejnym razem. No i niestety nie obserwuję tak głębokiego zaangażowania, jeżeli zespół jest po prostu w trybie klepania tasków. Robią, wyjdzie dobrze, nie wyjdzie trudno i to jest to miejsce, gdzie można bardzo dużo ugrać, przesuwając suwaczek trochę mocniej w stronę tego, że to zespół decyduje, w jaki sposób pewne rzeczy zostaną zrealizowane. 

Kuba: I zarządzającym bardzo łatwo zgodzić się z tą poradą, a może nawet wielu ma odruch, przecież już od dawna to stosuje, natomiast w praktyce może czasami tkwić pewien diabeł w tych szczegółach. Użyje takiego dosyć wymyślonego przykładu, to nie jest powiązane z żadnym z klientów, z którym współpracuję. Wielu zarządzających niestety myśli, że np. dodanie pewnej funkcji do aplikacji to jest efekt, a to jest tylko i wyłącznie pewien zakres albo jakiś uogólniony kawałek zakresu. No bo efektem będzie np. dodatkowa sprzedaż, która ta funkcja w tej aplikacji uruchomi. Dajmy zespołom wymyślić się jakieś ścieżki na skróty, dajmy im możliwość odcięcia pewnych wyobrażeń, nawet jeśli jest mocne przypuszczenie, że pewne kawałki zakresu są superważne, niech priorytetem, niech taką osią wszystkiego, co zespół realizuje, są rezultaty biznesowe. I wracając do tej aplikacji, może też jest często tak, zwłaszcza w zespołach technologicznych, które są częścią większych struktur, większych organizacji, no to dochodzi też do takiego uproszczenia, postawcie mi platformę, zbudujcie tą appkę albo dodajcie coś do appki jako efekt oczekiwany, a nie to, że na tym wszystkim ma być zbudowany pewien biznes. I zwłaszcza jeśli tym efektem ma być np. pierwsza sprzedaż na tej platformie, funkcjonowanie jakichś puli klientów na tej aplikacji lub faktyczny dochód z jakichś funkcji, które są sprzedawane, to też fajnie to otwiera czy rozszerza perspektywę, że to wszystko, co zespół technologiczny zrobi, musi być jeszcze opakowane w marketing, w sprzedaż, we wsparcie, w oprawę prawną, co bardzo mocno wraca do naszego odcinka o wsparciu czy zbliżeniu współpracy biznesu i IT.

Kuba: Siódma porada brzmi, zapewnij zespołom dostęp do feedbacku od klientów. Istotą tego jest to, żeby zespół miał stały dostęp, regularne jakieś rozwiązania, narzędzia, systemy do feedbacku od klientów. Feedback od klientów jest istotą takiej pracy w poczuciu odpowiedzialności, ale nie chodzi nam w tej poradzie wyłącznie o to, że okazjonalnie jest jakiś wgląd w jakieś badanie, albo raz na jakiś czas zrobimy jakąś grupę fokusową, czy zapytamy parę osób, tylko o to, żeby tak ustawić system, tak rozwiązać jakieś narzędzia, struktury, całą filozofię zarządzania, całą organizacją, żeby zespoły miały na wyciągnięcie ręki temat feedbacku. Możliwość konsultacji, możliwość iterowania z rynkiem, włącznie z tym, co jest dopiero jeszcze w trakcie, ale również z rozwiązaniami, które już od dawna są funkcjonujące. Czyli zerwanie z ideą, zrealizowania tej pracy tak bardzo projektowo, wymyślić, wdrożyć i zapomnieć, ale bycie w takim ciągłym kontakcie. Ciągłe pamiętanie o tym, kto jest tym klientem docelowym. I teraz można tego oczekiwać od zespołów, żeby w ten sposób myślały, ale tutaj szef produktu może zrobić wiele, żeby w całej organizacji po prostu były do tego rozwiązania, które zapewniają, że zespoły stale łatwo dostają dostęp do informacji zwrotnej. I to tej informacji zwrotnej, tej prawdziwej, która się liczy. Nie od szefa, prezesa, członka zarządu, czy innej ważnej osoby z ważnego gabinetu, tylko od tych prawdziwych klientów docelowych.

Jacek: Tak, i tu dwa komentarze do tego. Taka trochę parafraza tej ostatniej myśli, Twojej Kuba, czyli im bardziej to jest bezpośredni, oryginalnie brzmiący feedback, a nieprzekształcony przez jakiś tam głuchy telefon, tym lepiej. Czyli konkretne słowa, których używa klient, te konkretne ankiety, ten konkretny człowiek, z którym mogę porozmawiać, a nieprzefiltrowane, no bo to zawsze będzie jakiś tam efekt już zniekształcający. Natomiast druga sprawa, ta porada też brzmi tak bardzo, oczywiście na zasadzie, w czym problem. Spotkałem wiele firm, w których był dostęp do takich feedbacków i do klientów, natomiast systemowo praca zespołów była tak zorganizowana, że nikomu do głowy nie przyszłoby marnować czas, no bo tak naprawdę cały system krzyczy, masz programować, masz robić testy, masz tworzyć designy i takie sięgnięcie do tych danych może być traktowane jako strata czasu, jako coś nie na teraz, na kiedyś, na później. Więc z jednej strony banalna porada, a z drugiej zwróć uwagę, czy ludzie korzystają z tej możliwości. Jeśli ludzie nie korzystają, to myślę, że bardzo ciekawe może być zrozumienie przyczyn, dlaczego jest tak, że mamy te dane, ale jednak z jakiegoś powodu do nich nie sięgamy.

Jacek: Kolejna porada, znajdź czas na pracę jeden na jeden ze swoimi ludźmi. Jest to taka porada troszeczkę z innego poziomu, porada taka bardziej managerska, natomiast bardzo ważna i bardzo istotna. Również może się wydawać, że to jest oczywiste, jednak obserwacja nasza z Kubą jest taka, że jednak te rozmowy jeden na jeden nie są tak często prowadzone, jak mogłyby być. Ja osobiście spotykam wiele osób, które są w rolach produktowych, czy w rolach technologicznych na poziomie zespołów. No i smutny komentarz od tych osób, które słyszę, jest taki, że za bardzo mój szef ze mną nie rozmawia, za bardzo nie ma dla mnie czasu. Jak ja mówię o jeden na jeden, to bardziej mam na myśli taką częstotliwość w stylu raz na tydzień, raz na dwa tygodnie, a tam częściej słyszę raz na kwartał, albo rozmawiamy na podsumowaniach. Trudno jest oczekiwać, że nastąpi jakaś zmiana, że zespół będzie poddany jakiejś tam dłuższej ścieżce zdrowia pod tytułem, no dzisiaj nie bierzemy odpowiedzialności, ale kiedyś byśmy chcieli jednak, żeby ta odpowiedzialność rosła, jeżeli ktoś nigdy wcześniej tego nie robił. W takim momencie możliwość usłyszenia tego od przełożonego, który może stać się mentorem, osobą, która inspiruje, jest nieocenione. I z drugiej strony jednak dosyć tanie, w sensie no potrzebujemy tylko czas i skupienie na to, żeby tę mądrość transferować, inspirować, żeby po prostu rozmawiać. Natomiast tak jak mówię, nie jest to zbyt oczywiste, więc jakby do tej porady tak osobiście czuję, że w szczególności chciałbym Cię zachęcić, jeśli teraz takich rozmów jeden na jeden nie prowadzisz.

Kuba: I każdy ma swój styl realizacji takich jeden na jeden. Natomiast jeśli miałyby być dwie rzeczy, które warto w tego typu spotkaniach uwzględnić to jakieś rodzaj pytania o to, jakie są bieżące rozterki, jakie są bieżące potrzeby czy wyzwania tej konkretnej osoby, bo to jeden na jeden tej konkretnej osoby, z którą się aktualnie pracuje. No i druga rzecz to bieżące przekazywanie informacji zwrotnej. Nie kiszenie tego, nieczekanie na jakiś tam cykl półroczny, roczny, czy jaki funkcjonuje w danej organizacji HR-owo. Tylko jednak jeśli jest coś, co się zauważa, to przekazanie czy rozpoczęcie pewnej rozmowy tak wcześniej, tak spokojnie jak to tylko możliwe. Co się wiąże bardzo mocno z wieloma innymi poradami z tego odcinka, że tak naprawdę wiele z tych wątków to się świetnie nadaje na to, żeby w trakcie właśnie rozmowy jeden na jeden wyjaśnić, czy przypomnieć strategię, wyjaśnić podjęte niepopularne decyzje, porozmawiać o popełnionych błędach i wnioskach z nich wynikających. To są wszystko rzeczy, które się świetnie realizuje właśnie w formacie jeden na jeden.

Kuba: Przedostatnia porada, którą mamy, to stwórz ścieżki rozwoju dla członków zespołu. Też porada bardzo managerska, ale wynikająca z pewnego bardzo poważnego założenia, które bardzo często słyszę. „Mój zespół nie może dostać większej odpowiedzialności”, to cytat z jakiejś osoby zarządzającej pewną większą strukturą, ponieważ oni nie są jeszcze na to gotowi. I tu się pojawia jakaś konkretna szczegółowa historia o tym, że na przykład są jeszcze zbyt młodzi, albo jeszcze nie wzięli udział w takiej wielkiej inicjatywie. To może dotyczyć pojedynczych Product Ownerów, to może dotyczyć konkretnych liderów zespołów, albo nawet i całych struktur zespołów, gdzie na przykład w całym moim zespole nie ma wystarczająco mocnych osób, żeby zdelegować im odpowiedzialność za rozwiązanie, więc muszę się mocno w to angażować. No i tutaj rozwiązanie bardzo długofalowe oczywiście to, żeby rozwój tych osób był zaplanowany, było to przewidziane, żeby tak naprawdę już od świeżo zatrudnionego juniora mieć tę perspektywę, że teraz jeszcze nie i za dwa lata też jeszcze nie, ale już za pięć, być może ta osoba będzie na tyle cierpliwie rozwijana, będzie na tyle z nią prowadzona pewna praca i przechodzenie przez kolejne stopnie, żeby tą odpowiedzialność mogła na siebie wziąć i w efekcie całe zespoły mogły też tę odpowiedzialność brać. I w niektórych organizacjach po prostu zatrudnia się od razu osoby, które już są tak rozwinięte jak trzeba, w innych nie bardzo można sobie na to pozwolić, albo też po prostu sytuacja rynkowa na to nie pozwala, że na rynku nie ma takich osób, żeby brać gotowych, ale nawet w tych firmach, które mogą sobie pozwolić na już naprawdę porządnie rozwiniętych ludzi, dalej ma to znaczenie, żeby te osoby rozwijać, również na kolejne poziomy bym powiedział organizacyjne. Czyli nawet jak już mam super świetnego szefa produktu, no to pytanie, co nas broni przed tym, żeby tę osobę wciągnąć na wyższy poziom, tu taka już z doświadczenia porada bardzo managerska, managerska wyższego stopnia, jak mam swoich następców, to mogę awansować, a jak nie mam komu przekazać swojego obszaru, to być może decyzja o awansie zostanie powstrzymana, no bo po prostu jestem niezastąpiony w swoim obszarze.

Jacek: Ścieżki rozwoju mogą być w różnych firmach traktowane w różny sposób. Czyli na przykład może być ścieżka rozwoju taka bardzo generyczna, czyli jest na przykład ścieżka rozwoju dla Product Managera, która ma ileś tam poziomów. Od jakiegoś takiego absolutnego juniora do eksperta. Natomiast to, co jest myślę istotne, to to, że to nie wyklucza tego, że pracując osobą jeden na jeden, możesz z tą osobą umawiać się też na cele spersonalizowane. To jest sposób, który wykorzystywałem w swojej pracy managerskiej, gdy zarządzałem między innymi strukturą Product Ownerów. Oprócz rozwoju Product Ownera, która wynikała ze ścieżki rozwoju, która była stworzona między innymi przy pomocy osób, które funkcjonowały w obszarze HR, umawiałem się też z tymi osobami na indywidualne cele. To nie były cele, które stały w sprzeczności ze ścieżką rozwoju, a raczej bym powiedział, były takim dopełnieniem, takimi brakującymi, najbardziej istotnymi puzzlami dla danej osoby w tym konkretnym momencie. No i skąd wiedziałem, co jest tym brakującym puzzlem, jak do tego dochodziliśmy? Po prostu rozmawialiśmy, ja bardzo dobrze wiedziałem, co się dzieje w projektach, które te osoby prowadzą z konkretnymi klientami. Stąd też bardzo łatwo było nam dojść do porozumienia, że oprócz tego, co widzisz na tej oficjalnej ścieżce, to musisz rozwinąć jakieś tam konkretne kompetencje no i dajemy sobie na to jakiś tam czas i wsparcie, które będzie do tego potrzebne.

Jacek: Ostatnia porada dzisiejszego odcinka, zaplanuj proces wzmacniania odpowiedzialności. Trochę o tym powiedzieliśmy już w tym odcinku, natomiast ten punkt akcentuje to, że proces przekazywania odpowiedzialności to nie jest coś, co się wydarzy z dnia na dzień. Jest to pewna zmiana, no i jak z każdą zmianą, warto taką zmianą zarządzić. Wymaga to przede wszystkim pewnej świadomości, że od dzisiaj chcielibyśmy nad taką zmianą pracować, wymaga to rozmowy z ludźmi, których ta zmiana będzie dotyczyć. Na pewno będziemy potrzebowali ich zrozumienia, ich wsparcia. Tam może być cała masa wątpliwości. Należałoby te wszystkie wątpliwości zaadresować. Odpowiedzialność wiąże też się z pewną wiedzą, którą trzeba zdobyć. Tę wiedzę trzeba umieć wykorzystać w praktyce, no i dobrze by też było, żebyśmy w tym procesie byli w stanie oceniać efekty. Celebrować te momenty, kiedy odpowiedzialność w widoczny sposób pomogła zespołowi uzyskać jakieś efekty, ale żebyśmy byli też gotowi na to, że jeżeli to nie idzie tak, jak byśmy się spodziewali, no to żeby zaplanować działania korygujące.

Kuba: Jedną z rzeczy, która może być częścią takiego zaplanowania procesu przekazywania odpowiedzialności, może być też bardzo jawne pokazanie uprawnień decyzyjnych. Kto kiedy, w jakich sytuacjach ma prawo, o czym decydować? Ma prawo decydować teraz, ma prawo decydować, być może za jakiś czas, czyli jakby jak ewolucyjnie będziemy te uprawnienia decyzyjne przekazywać. W praktyce, gdyby szukać konkretnego narzędzia, tej konkretnej praktyki, to tutaj często rekomenduję, często mi się sprawdza Delegation Board. Jedno z narzędzi jest nurtu Management 3.0. I tutaj upraszczając, chodzi o to, żeby bardzo jawnie wypisać konkretne przypadki, konkretne sytuacje czy konkretne obszary, w których podejmowane są pewne decyzje, czy następują jakieś procesy związane z decyzjami i jasne sobie powiedzenie między osobami w strukturze, kto, na jakim poziomie ma jaki poziom zdelegowania odpowiedzialności. Tak, żeby w ogóle na pierwszym, w pierwszym kroku, żeby w ogóle mieć tutaj jasność i brak nieporozumień pomiędzy poszczególnymi osobami, ale również, żeby rozpocząć rozmowę taką długotrwałą. OK, to co musi się wydarzyć, żebyście zupełnie samodzielnie o czymś decydowali? Co musi się wydarzyć, żebym ja się czuł spokojnie jako zarządzający strukturą? Kiedy potrzebuję, żebyście jednak na przykład przyszli się skonsultować albo przyszli pokazać jakiś pomysł, żebym się w jakiś sposób z nim zgodził albo pod nim podpisał. Więc tutaj mocno zachęcamy do tego, żeby nie odkładać tematu, nie zakładać, że on się wydarzy sam albo że jest oczywisty, tylko jednak budować tę odpowiedzialność cierpliwie, trwale, wraz z rozwojem swoich ludzi, również kroczek po kroczku ją przekazywać do konkretnych osób czy do konkretnych zespołów.

Jacek: W ramach tego punktu przypomina mi się historia z początku moich działań jako konsultant w ramach 202 Procent, gdy wspierałem pewną firmę, która borykała się z następującym problemem. Product Ownerzy komunikowali mi, że nie dostali odpowiedzialności, natomiast osoba z zarządu, która odpowiadała za opiekę nad nimi, dostawałem komunikat, oni w ogóle nie biorą odpowiedzialności. I to było takie bardzo wyjątkowe usłyszeć, takie trochę sprzeczne komunikaty z obu stron i okazało się, że jedna, dwie rozmowy właśnie przy użyciu Delegation Board, techniki, o której przed chwilą Kuba wspomniał, pozwoliło rozwiązać ten problem. Na zasadzie Product Ownerzy odkryli, że mogą o wiele więcej, natomiast osoby zarządzające dostrzegły, że jest przestrzeń na to, żeby to osoby faktycznie pewną odpowiedzialność wzięły. Więc tak, to nie jest oczywiste i tak zdecydowanie warto o tym rozmawiać i sobie ten temat przegadać.

Kuba: Ok, podsumowując. Wzmacnianie odpowiedzialności za produkt przez szefa produktu polega na wyznaczaniu ambitnych celów. Regularnym przypominaniu strategii firmy i produktu. Angażowaniu zespołów w kreowanie rozwiązań oraz wyjaśnianiu kontekstu biznesowego podejmowanych decyzji.

Jacek: Równocześnie warto umożliwiać eksperymentowanie i zadbać o to, żeby z tych eksperymentów były wyciągane wnioski. Oczekiwać efektów, zamiast tylko realizować sztywne zakresy. No i pomocna może być zapewnienie dostępu do feedbacku od klientów. Regularna praca jeden na jeden oraz stworzenie ścieżek rozwoju.

Kuba: Wzmacnianie odpowiedzialności to proces, który warto dobrze zaplanować i systematycznie realizować.

Jacek: Jeżeli twoja firma korzysta z technik pracy zespołowej inspirowanej Scrumem i masz poczucie, że efektywność pracy twoich zespołów wymaga poprawy, odezwij się do nas po diagnozę i eksperckie rekomendacje na temat procesu wytwórczego w twoich zespołach. 

Kuba: Dopasujemy nasze porady do konkretnego kontekstu Twojej firmy i wesprzemy zmiany, których potrzebujesz. Sprawdź naszą ofertę na stronie porzadnyagile.pl/diagnoza.

Jacek: I na koniec takie trochę luźniejsze ogłoszenia, ale istotne zarówno dla mnie i dla Kuby, jak i dla Słuchaczy. Warto zaakcentować pewną taką świadomą zmianę, którą wprowadziliśmy ostatnio w naszym podcaście. Jeżeli śledzisz nas regularnie, możesz zauważyć, że ostatnie kilka odcinków ma trochę inną tematykę. Jest to z naszej strony świadome i chcemy jawnie zadeklarować i obiecać, że będziemy kolejne materiały kierować głównie do osób zarządzających zespołami, organizacją oraz produktem. Siłą rzeczy może to oznaczać trochę mniej adekwatne tematy dla członków konkretnych zespołów.

Kuba: Ale jeśli jesteś Scrum Masterem, Scrum Masterką, Product Ownerem, Product Ownerką i jesteś z nami długo, to mimo wszystko zachęcamy do pozostania z nami, bo te tematy być może niedługo będą również dotyczyć Ciebie, bo prędzej czy później przydarzy się jakiś awans właśnie na grono zarządzające. A może jesteś w relacji z osobami zarządzającymi i możesz pewne rzeczy doradzić, poradzić, słuchając tego, jak my to robimy. Być może możesz w jakiś sposób odtworzyć pewien ciąg myślowy i również zainspirować swojego przełożonego czy swoją szefową.

Jacek: Natomiast niezmiennie notatki do tego odcinka, artykuł, transkrypcję oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/132.

Kuba: I to by było wszystko na dzisiaj. Dzięki Jacek.

Jacek: Dzięki Kuba.

Kuba: I do usłyszenia. Wkrótce.

———

To była pełna transkrypcja odcinka podcastu „Porządny Agile”. Dziękujemy za lekturę!

Ostatnia aktualizacja: 29 grudnia 2025