Znasz to uczucie? Kończy się Planowanie Sprintu. Zespół „zakomitował się” do celu. W Jirze (lub Azure DevOps) wszystko świeci się na niebiesko w kolumnie „To Do”. Wygląda to jak plan. Ale czy nim jest?
W rzeczywistości to tylko lista życzeń. Jira świetnie odpowiada na pytanie „CO” mamy do zrobienia. Ale milczy w kwestii tego, „JAK”, „KIEDY” i „Z KIM” to zrobimy.
Przez lata pracy jako Scrum Master, Agile Coach i Enterprise Transformation Coach w dużych organizacjach (od telekomów po bankowość) widziałem ten sam schemat: silosy kompetencyjne, efekt „ja swoje zrobiłem, teraz ty się martw” i panika w ostatnich dwóch dniach sprintu.
Dlatego stworzyłem rePlan. Narzędzie banalne w swojej konstrukcji, ale rewolucyjne w skutkach. To nie jest kolejny plugin. To zmiana mentalna.
Czym w ogóle jest rePlan?
Wyobraź sobie prostą siatkę.
Wiersze: To Twoi ludzie. Janek, Kasia, Bartek, Zosia.
Kolumny: To dni Sprintu. Poniedziałek, Wtorek… aż do Review.
To nie jest Gantt, którego tworzy manager i narzuca zespołowi. To plansza do gry zespołowej, którą zespół wypełnia sam. Podczas planowania nanosimy na nią:
Dostępność: Urlopy, szkolenia, wyjścia do lekarza (realna pojemność).
Zadania w czasie: Kreski oznaczające, kiedy planujemy pracować nad danym Story.
Zależności: Jeśli Kasia potrzebuje kodu od Janka, jej zadanie nie może zacząć się wcześniej, niż skończy się zadanie Janka.
Brzmi prosto? Siła tkwi w tym, co dzieje się później.
Efekt 1: Śmierć „Bohatera” i narodziny „Roju” (Swarming)
W tradycyjnym podejściu developer bierze zadanie i znika na 3 dni. Na rePlan widać to jako długą, samotną linię. Zespół od razu to widzi: „Hej, Marek, zajmujesz się tym gigantem przez pół sprintu sam. Co jak zachorujesz? Co jak utkniesz?”.
rePlan naturalnie wymusza Swarming (pracę roju). Zamiast jednej długiej linii, zespół zaczyna rysować dwie lub trzy krótsze, równoległe linie przy tym samym temacie.
Zysk: Wiedza nie jest uwięziona w głowie jednej osoby (Bus Factor), a zadania są zamykane szybciej.
Efekt 2: Daily Scrum przestaje być spowiedzią
Większość spotkań Daily Scrum to status meetingi: „Wczoraj zrobiłem X, dziś zrobię Y”. Nuda. I strata czasu.
Z rePlanem Daily zmienia się w taktyczną odprawę. Patrzymy na tablicę:
„Mieliśmy skończyć ten moduł wczoraj (widać koniec linii na wtorku), a jest środa i wciąż to robimy. Linia przesuwa się w prawo. Co to oznacza dla reszty sprintu?”
„Widzę, że jutro Zosia ma szkolenie, a Bartek czeka na jej Code Review. Mamy korek. Kto inny może to sprawdzić?”
Dyskusja przenosi się z przeszłości („co zrobiłem”) na przyszłość i zarządzanie ryzykiem („czy zdążymy”).
Efekt 3: Koniec z „Testing Squeeze”
Klasyczny problem: Developerzy kodują przez 8 dni sprintu, a Testerzy mają 2 dni na sprawdzenie wszystkiego. W Jirze tego nie widać, dopóki zadania nie wpadną do kolumny „Ready for Test”.
Na rePlan widać to w sekundę podczas planowania. Jeśli linie u Developerów są pełne do czwartku, a linie u Testerów puste na początku sprintu, a przeładowane na końcu – tablica krzyczy, że plan jest nierealny. Wymusza to wcześniejsze angażowanie testerów lub rozbijanie historyjek tak, by testować je od 2-3 dnia sprintu.
Dodatkowo zespół łatwo przechodzi do trybu pracy, kiedy to podczas rozpoczynania prac nad danym tematem testerzy zaczynają definiować jak będzie on testowany. W efekcie na koniec pozostaje tylko wykonanie zdefiniowanego już testu.
Case Study: Transformacja w finansach
Jako Enterprise Agile Coach pracowałem z dużym Tribe’em (ok. 16 zespołów), który zmagał się z brakiem przewidywalności i niskim zaangażowaniem.
Sytuacja PRZED: Zespoły dowoziły „punkty”, ale nie dowoziły wartości. Integracja rozwiązań następowała rzadko i boleśnie. Panował podział: „My devowie, Wy biznes”.
Wdrożenie rePlan: Wprowadziłem rePlan nie jako narzędzie kontroli, ale jako narzędzie uzgadniania rzeczywistości.
Na początku był opór. „To mikrozarządzanie!”. „Szkoda czasu na rysowanie kresek”.
Przełom nastąpił, gdy jeden z zespołów dzięki tablicy zauważył w połowie sprintu, że przez nieobecność kluczowego architekta nie dowiozą Celu. Zamiast udawać, że jest OK, zmienili zakres w trakcie sprintu, informując Product Ownera.
Sprint zakończył się sukcesem, bo dowieźli to, co najważniejsze, bez nadgodzin. Inne zespoły to zauważyły.
Efekty PO 3 miesiącach:
Time to Market (TTM) skrócony o 35%: Dzięki wizualizacji zależności zespoły przestały się blokować. Czas oczekiwania (Waste) został drastycznie zredukowany.
Wzrost zaangażowania o 40%: Ludzie poczuli, że mają wpływ na plan. To nie był plan managera, to był ich plan, ułożony na ich zasadach.
Kultura planowania z kontekstem celów: Zespoły przestały planować „zamykanie tasków”, a zaczęły planować „osiągnięcie celu” w konkretnym czasie.
Skalowanie: rePlan na poziomie wielu zespołów
Siła rePlan rośnie wykładniczo, gdy położymy kilka tablic obok siebie (np. na wirtualnej tablicy Miro dla całego Tribe’u).
Jeśli Zespół A buduje API dla Zespołu B, to na zwykłym planowaniu słyszymy: „Dostarczymy to w tym sprincie”. Na zintegrowanym rePlan widać:
Zespół A planuje skończyć API w piątek.
Zespół B planuje użyć tego API w środę.
Wizualizacja pokazuje kolizję zanim napisana zostanie pierwsza linijka kodu. Dzięki temu zespoły mogą negocjować kolejność prac przed startem sprintu, co jest kluczowe dla budowania zintegrowanego przyrostu w dużych organizacjach.
Podsumowanie: Od Silosów do Współpracy
rePlan leczy najcięższą chorobę zespołów Agile – samotność w tłumie. Rozbija silosy, bo pokazuje, że pusta kratka w moim wierszu to okazja, by pomóc koledze, który w swoim wierszu „tonie”.
Zmienia narrację z „Ja zrobiłem swoje zadanie” na „My zrealizowaliśmy nasz plan”. I o to w tym wszystkim chodzi.
Nie dawno mój znajomy, pilot z zawodu, powiedział mi: „To są tanie linie. Jak chcesz uprzejmości, to weź business jet”
To zdanie zatrzymało mnie na dłużej. Bo czy rzeczywiście w dzisiejszych czasach doszliśmy do momentu, gdzie uprzejmość staje się towarem premium? Gdzie podstawowa grzeczność wymaga dopłaty?
Anatomia tanich linii lotniczych
Model biznesowy tanich przewoźników to w gruncie rzeczy sztuka precyzyjnego cięcia kosztów. Każda usługa zostaje pokrojona na atomowe części, z których klient komponuje sobie własny pakiet. Chcesz wybrać miejsce? Dopłata. Chcesz kanapkę? Dopłata. Chcesz, żeby twoja walizka poleciała razem z tobą, a nie następnym samolotem? Dopłata.
W tej fabryce oszczędności najbardziej dotkliwie oberwała załoga. Ścisk czasowy, wielokrotne loty dziennie, minimalne przerwy – to wszystko sprawia, że uśmiech stewardesy zaczyna kosztować. I to nie tylko dosłownie (w sensie kosztów osobowych), ale i mentalnie. Ciężko być uprzejmym, gdy pracujesz na granicy wytrzymałości.
A pasażerowie? Cóż, tanio często znaczy nerwowo. Dodajmy do tego opóźnienia, ciasnotę i fakt, że wszyscy oszczędzali na bilecie, więc każda komplikacja boli podwójnie. Powstaje przepis na konflikt, w którym uprzejmość staje się pierwszą ofiarą.
Ekonomia uśmiechu
Czy uprzejmość rzeczywiście kosztuje? Na pierwszy rzut oka wydaje się, że nie. W końcu to tylko sposób komunikacji, prawda? Ale jak spojrzymy głębiej, okazuje się, że grzeczność wymaga zasobów:
Czasu – dłuższe rozmowy, wyjaśnianie, cierpliwość
Energii mentalnej – kontrola emocji, empatia, pozytywne nastawienie
Szkolenia – obsługa klienta to umiejętność, którą trzeba rozwijać
Bufora bezpieczeństwa – uprzejmy pracownik nie może być przeciążony
W świecie, gdzie każda minuta jest liczona, a każdy grosz ważony, te „miękkie” koszty stają się bardzo realne. Uprzejmość wymaga słaba w systemie, a słabów nie ma w modelach maksymalnej efektywności.
Premium as usual
W biznesie czy pierwszej klasie historia wygląda zupełnie inaczej. Tu obsługa ma czas, pasażerów jest mniej, wszyscy są (teoretycznie) mniej zestresowani. Uprzejmość staje się częścią produktu, za który klient świadomie płaci.
To prowadzi do paradoksalnej sytuacji: im więcej ktoś płaci, tym milszego traktowania może się spodziewać. Powstaje dwuklasowy system grzeczności, gdzie podstawowa ludzka przyzwoitość rezerwowana jest dla tych, których na nią stać.
Czy to tylko linie lotnicze?
Oczywiście, że nie. Spójrzmy na:
Call centra – podstawowy plan: automat i 20 minut czekania; premium: natychmiastowe połączenie z żywym człowiekiem
Bankowość – konto podstawowe: surowy formularz online; konto premium: osobisty doradca, który pamięta twoje imię
E-commerce – zwykła obsługa: standardowe odpowiedzi; premium: personalizowane rozwiązania
Wszędzie widzimy ten sam wzorzec: uprzejmość jako element różnicujący, dodatkowa wartość dla tych, których stać na więcej.
Czy da się tego uniknąć?
Tu dochodzimy do sedna sprawy. Czy uprzejmość musi kosztować? Czy naprawdę nie da się być miłym przy zachowaniu efektywności?
Myślę, że można – ale wymaga to zmiany filozofii biznesowej. Zamiast traktować grzeczność jako koszt, trzeba zacząć postrzegać ją jako inwestycję. Zadowolony klient wraca, poleca, nie generuje konfliktów. To też ma swoją wartość.
Niektóre firmy to rozumieją. Powstają modele, gdzie uprzejmość jest częścią DNA organizacji, nie luksusem dla wybranych. Ale wymagają one odwagi – odwagi, by nie konkurować tylko ceną, ale wartością.
Pytania na koniec
Czy zgadzamy się na świat, gdzie podstawowa przyzwoitość jest towarem premium? Gdzie uśmiech wymaga dopłaty, a grzeczność jest przywilejem bogatszych?
A może istnieje trzecia droga – taka, gdzie uprzejmość nie jest ani kosztem, ani luksusem, ale podstawowym standardem? Gdzie firma może być efektywna i jednocześnie ludzka?
To pytania, na które każdy z nas – jako konsument, pracownik czy przedsiębiorca – musi odpowiedzieć sobie sam. Bo w końcu to my decydujemy, jaki świat budujemy. I jaki świat kupujemy.
Kiedy miałem trzynaście lat, moja mama postanowiła, że pora zmienić meble w moim pokoju. Nie pytała o zdanie – po prostu pewnego dnia wróciłem ze szkoły i zastałem obcych ludzi wynoszących moje ulubione biurko. „To dla twojego dobra” – usłyszałem, gdy zacząłem protestować. Dwadzieścia lat później, pracując jako konsultant agile w korporacji usług finansowych, usłyszałem niemal identyczne słowa: „Ta transformacja jest dla dobra całej organizacji.”
Peter Senge miał rację: ludzie nie opierają się zmianie – opierają się temu, żeby być zmienianymi. A różnica jest fundamentalna.
Anatomia oporu – kiedy dobra zmiana spotyka złą komunikację
W owej korporacji finansowej trafiłem na sytuację, która idealnie ilustruje mechanizm oporu. Organizacja zatrudniała ponad 3000 specjalistów IT, z których większość przez lata pracowała w modelu kaskadowym. Zarząd podjął strategiczną decyzję o przejściu na metodyki agile – i słusznie, bo rynek finansowy wymaga dziś szybkości reakcji, jakiej waterfall po prostu nie gwarantuje.
Problem polegał na tym, że zmiana została ogłoszona, nie wprowadzona. Podczas jednego z pierwszych spotkań kierownik działu development powiedział mi wprost: „Dostaliśmy mail, że od przyszłego miesiąca pracujemy w scrumie. Gdzie tu miejsce na nasze zdanie?”
To był moment, w którym zrozumiałem, że nie walczę z oporem wobec agile. Walczę z oporem wobec bycia zmienianym bez udziału w procesie zmiany.
Gdy „oni” stają się „nami” – psychologia właścicielstwa
Ludzka psychika ma jedną fascynującą cechę: to, co tworzymy, automatycznie staje się częścią naszej tożsamości. Dlatego też najlepsze zmiany to te, w których ludzie czują się współtwórcami, a nie biernymi odbiorcami.
W tamtej korporacji postanowiłem więc zastosować strategię, którą nazywam „infiltracją od środka”. Zamiast narzucać gotowe rozwiązania, zacząłem od pytań:
Jakie problemy napotykają zespoły w obecnym modelu pracy?
Gdzie tracą najwięcej czasu?
Co frustruje ich najbardziej w codziennych procesach?
Okazało się, że ludzie doskonale wiedzą, co nie działa. Po trzech tygodniach warsztatów jeden z senior developerów powiedział: „Wie pan co, te nasze codzienne standupy to w zasadzie daily scrum, tylko nikt tego tak nie nazywał.”
Bingo. Nie wprowadzałem czegoś obcego – pomagałem nazwać i ustrukturyzować to, co już istniało.
Syndrom „nie wynaleziono tutaj”
Każda organizacja ma swoją kulturową DNA, swój sposób myślenia o sobie. W korporacjach finansowych to DNA często brzmi: „jesteśmy wyjątkowi, nasze procesy są skomplikowane, żadna metodyka z zewnątrz nie zrozumie naszej specyfiki.”
Ten syndrom wyjątkowości to jeden z najsilniejszych mechanizmów obronnych. Ludzie nie odrzucają zmiany per se – odrzucają zmianę, która ignoruje ich kontekst, ich wiedzę, ich doświadczenie.
Dlatego też kluczowym momentem w mojej pracy było pokazanie, że agile nie jest gotowym kostiumem, który trzeba włożyć, ale raczej tkaniną, z której można uszyć kostium na miarę. Zamiast mówić „tak robi się scrum”, mówiłem „spójrzmy, jak można by zaadaptować te praktyki do waszych potrzeb.”
Wpływ jako lekarstwo na opór
Najskuteczniejszym lekarstwem na opór jest poczucie wpływu. Gdy ludzie czują, że mają realny wpływ na kształt zmiany, opór zamienia się w zaangażowanie. To nie jest teoria motywacji – to podstawowa psychologia człowieka.
W tamtej organizacji przełomem był moment, gdy zespoły zaczęły same proponować modyfikacje standardowych praktyk agile. Product Owner z działu kredytów hipotecznych zaproponował, żeby w ich kontekście sprint review odbywał się w dwóch częściach: technical demo dla IT i business demo dla stakeholders. „Bo inaczej – tłumaczył – połowa ludzi się nudzi, a połowa nic nie rozumie.”
To było genialne. I co ważniejsze – to było ich pomysł.
Zmiana jako podróż, nie przeprowadzka
Myślimy o zmianie organizacyjnej jak o przeprowadzce: pakujesz stare rzeczy, przewozisz je w nowe miejsce, rozpakowujesz. Tymczasem zmiana to raczej stopniowa metamorfoza – proces, w którym stare i nowe współistnieją przez pewien czas, a ludzie mają przestrzeń na adaptację.
W praktyce oznaczało to, że nie narzucałem totalnej rewolucji. Zamiast tego wprowadzaliśmy zmiany iteracyjnie (jakże agile, prawda?). Zaczęliśmy od daily standupów w trzech pilotażowych zespołach. Potem dodaliśmy retrospektywy. Sprint planning przyszedł dopiero po miesiącu. Każdy element był testowany, dostosowywany, oswajany.
Komunikacja jako klej zmiany
Jednym z największych błędów w zarządzaniu zmianą jest założenie, że informacja równa się komunikacja. Informacja to „co się zmienia”. Komunikacja to „dlaczego się zmienia, jak to wpłynie na mnie i co mogę z tym zrobić”.
W tamtej korporacji pierwszym krokiem było stworzenie transparentnego kanału komunikacji. Nie kolejnego newsletter’a od management’u, ale rzeczywistego miejsca wymiany informacji. Stworzyliśmy wewnętrzną społeczność agile, gdzie ludzie mogli zadawać pytania, dzielić się obawami, proponować rozwiązania.
Najciekawsze były pytania typu: „A co będzie z moją rolę project managera?” czy „Czy scrum master to awans czy degradacja dla team lead’a?”. Te pytania pokazywały, gdzie naprawdę leży źródło oporu – w strachu przed utratą pozycji, kompetencji, tożsamości zawodowej.
Kultura błędu vs kultura strachu
W organizacjach z silną kulturą kontroli ludzie uczą się, że błąd to zagrożenie. Dlatego też każda zmiana, która wprowadza niepewność, spotyka się z oporem. Agile zakłada eksperymentowanie, uczenie się na błędach, adaptację – czyli wszystko to, co w tradycyjnych korporacjach postrzegane jest jako ryzyko.
Przełamanie tego paradoksu wymagało przeprogramowania sposobu myślenia o błędach. Zamiast mówić o „porażkach”, zaczęliśmy mówić o „lekcjach”. Zamiast o „problemach” – o „możliwościach do poprawy”. To może brzmi jak PR-owy newspeak, ale ma realny wpływ na psychologię zespołu.
Gdy opór staje się sprzymierzeńcem
Paradoksalnie, w pewnym momencie opór stał się naszym największym sprzymierzeńcem. Ludzie, którzy na początku byli najbardziej sceptyczni, po przekonaniu się do zmiany stali się jej najlepszymi ambasadorami. Dlaczego? Bo przeszli przez pełny cykl: od oporu, przez zrozumienie, po internalizację.
Senior developer, który na początku mówił „jeszcze jedna metodologia zarządzania projektami”, po trzech miesiącach pracy w scrumie zorganizował wewnętrzną konferencję agile. „Chcę, żeby inni zespoły też tego spróbowały” – powiedział. „Ale na swoich warunkach, nie dlatego że ktoś im każę.”
Lekcje z pierwszej linii frontu
Po sześciu miesiącach pracy w tamtej organizacji, kiedy patrzę wstecz na całą transformację, widzę kilka kluczowych prawd o oporze w organizacjach:
Opór nie jest wrogiem zmiany – to naturalny mechanizm obronny, który chroni organizację przed chaotycznymi, nieprzemyślanymi decyzjami. Inteligentny change management wykorzystuje opór jako informację zwrotną, nie walkę z nim jako z przeszkodą.
Ludzie nie boją się zmiany – boją się utraty kontroli nad swoim środowiskiem pracy. Daj im poczucie wpływu na kształt zmiany, a opór zamieni się w zaangażowanie.
Najlepsza zmiana to ta, którą ludzie czują jako swoją – nawet jeśli pierwotny impuls przyszedł z góry. Sztuka polega na tym, żeby przekształcić zewnętrzny nakaz w wewnętrzną motywację.
I w końcu: Peter Senge miał rację. Ludzie naprawdę nie opierają się zmianie – opierają się temu, żeby być zmienianymi. Różnica jest fundamentalna i ma ogromne konsekwencje praktyczne.
W końcu, zmiana organizacyjna to nie przeprowadzka mebli. To raczej jak przeprowadzka do nowego mieszkania – możesz zabrać ze sobą to, co cenne, ale musisz być gotowy na nowe otoczenie. I najlepiej, żeby ta decyzja była twoja.
Wprowadzam tę mikro-technikę od lat w różnych zespołach, i za każdym razem widzę te same zaskoczone miny: „Naprawdę? To takie proste?”. Tak, to takie proste. I właśnie w tej prostocie tkwi cała siła.
Pytanie: „Jak bardzo jesteśmy pewni, że dowieziemy cel sprintu?” Odpowiedź: kciuk w górę 👍 lub kciuk w dół 👎.
Zero dyskusji, zero niuansów – czysta binarka. Po minucie już wiemy, czy mamy zieloną, czy czerwoną lampkę. Nie ma „może”, „prawdopodobnie”, „zależy od…”. Jest pewność lub jej brak. Jest zespół, który czuje się komfortowo z obecnym stanem rzeczy, lub zespół, który sygnalizuje niepokój.
To nie jest głosowanie demokratyczne – to temperatura zespołu. Jeden kciuk w dół w pięcioosobowym zespole to już sygnał, że warto się zatrzymać i porozmawiać. Trzy kciuki w dół to sygnał, że sprint ma poważny problem.
Dlaczego to działa? (Zyski)
Błyskawiczna diagnoza zespołu
W 5 sekund widzisz temperaturę sprintu – termometr projektu bez wchodzenia w Jira-labirynt. Nie musisz analizować burn-down chartów, liczyć story pointów czy sprawdzać, ile tasków jest w kolumnie „In Progress”. Patrzysz na kciuki i od razu wiesz, czy zespół czuje się pewnie, czy ma wątpliwości.
Ta szybkość diagnostyki to nie tylko kwestia efektywności – to także kwestia psychologiczna. Zespół od pierwszej sekundy Daily wie, że będzie miał okazję wyrazić swoje obawy w bezpieczny sposób. Nie musi czekać na koniec, nie musi przerywać komuś opowieści o swoich taskach.
Psychologiczny „ice-breaker”
Palce rozgrzane, języki też – łatwiej zacząć konkretne rozmowy po symbolicznym geście. Jest w tym coś z rytuału, coś z zabawy, ale także coś z wspólnotowości. Wszyscy robimy ten sam gest, w tym samym momencie. To buduje poczucie, że jesteśmy jednym zespołem, a nie zbiorem indywidualnych wykonawców.
Zauważyłem, że po wprowadzeniu tej techniki ludzie częściej się uśmiechają na początku Daily. Może to przez ten element gamifikacji, a może przez to, że wiedzą – mają bezpieczną przestrzeń do wyrażania wątpliwości.
Wspólna odpowiedzialność za cel
Każdy kciuk to głos, „my” dowozimy cel, nie „oni z backendu” czy „frontend znowu nie nadąża”. To bardzo subtelne, ale potężne przesunięcie w myśleniu. Kiedy cały zespół pokazuje kciuk w dół, nikt nie szuka winnego – wszyscy czują się odpowiedzialni za znalezienie rozwiązania.
Wczesny system ostrzegawczy
Pierwszy 👎 często pojawia się kilka dni wcześniej niż pierwszy czerwony wykres w Sonarze czy pierwsze opóźnienie w harmonogramie. To jak kanarkowe ptaki w kopalni – zespół wyczuwa problemy intuicyjnie, zanim pojawią się w metrykach.
Przez lata obserwacji zauważyłem, że doświadczeni developerzy mają niesamowitą intuicję co do tego, czy sprint będzie udany. Często nie potrafią tego racjonalnie wytłumaczyć, ale czują, że coś jest nie tak. Kciuk w dół to kanał dla tej intuicji.
Lek na „Daily-sleepy-syndrom”
Ruch i micro-gamification podnoszą tętno spotkania. Zamiast ospalego mamrotania „wczoraj robiłem to, dziś będę robić tamto”, mamy moment aktywności, moment w którym wszyscy jednocześnie muszą się zastanowić nad stanem sprintu i wyrazić swoją opinię.
Skąd się biorą kciuki w dół? (Powody)
Niepewne wymagania
„Jeszcze nie wiemy, jakie pola ma mieć raport PDF… a już połowa sprintu za nami”. To klasyk – user story wydawała się jasna podczas planowania, ale w trakcie implementacji okazuje się, że kryje dziesiątki szczegółów, o których nikt nie pomyślał.
Symptomy: Deweloperzy zadają coraz więcej pytań, Product Owner odpowiada „sprawdzę i wrócę do Was”, a zadania wiszą w „In Progress” bez postępu.
Blokery techniczne
Środowisko testowe znowu wstało lewą VM-ą, API zewnętrznego dostawcy działa „czasami”, a baza danych testowa ma dane z epoki kamienia łupanego. Techniczne przeszkody, które paraliżują pracę zespołu.
Symptomy: Ludzie siedzą przed ekranami, ale nie mogą wykonać swojej pracy. Slack wypełnia się wiadomościami „u mnie też nie działa” i „ktoś już zgłosił do IT?”.
Nadmierny zakres
Klasyk: Product Owner dorzucił „tylko drobną poprawkę” wielkości Godzilli. Albo okazało się, że „proste” zadanie wymaga refactoringu połowy aplikacji. Scope creep w najczystszej postaci.
Symptomy: Zadania, które miały być „małe”, rosną jak na drożdżach. Estymaty okazują się śmiesznie niskie. Zespół ma wrażenie, że sprint się „rozlewa”.
Niedostępność kluczowej osoby
Dev Ops na urlopie, a my bez merge’ów jak bez kawy. Architekt zachorował w kluczowym momencie. Product Owner wyjechał na konferencję akurat wtedy, gdy potrzebujemy jego decyzji.
Symptomy: Decyzje się nie podejmują, praca stoi, ludzie improwizują rozwiązania, które mogą nie być optymalne.
Zbyt optymistyczne estymaty
Yesterday’s weather? Wczoraj chyba świeciło słońce na Marsie. Zespół niedoszacował złożoność, nie wziął pod uwagę wszystkich zależności, zapomniał o testach czy nie przewidział komplikacji integracyjnych.
Symptomy: Burn-down chart przypomina raczej „burn-up”, ludzie pracują nadgodziny, a mimo to zadania się nie domykają.
Kciuk w dół? Co dalej? (Scenariusze)
Kiedy widzisz kciuk w dół – lub kilka kciuków w dół – nie panikuj. To nie jest wyrok. To jest zaproszenie do rozmowy.
Pierwsza reakcja powinna być prosta: „Dlaczego?„
Nie „kto jest winny”, nie „co robiliśmy źle”, tylko po prostu: dlaczego czujesz, że możemy nie dowieźć celu sprintu? To pytanie powinno być zadane w bezpiecznej atmosferze, bez oskarżeń czy presji. Każdy kciuk w dół to cenny sygnał, a nie powód do wstydu.
Faza pierwsza: Zrozumienie
Daj zespołowi przestrzeń do wyrażenia obaw. Czasami okaże się, że to tylko mglisty niepokój – „coś mi się nie podoba, ale nie wiem co”. Czasami to konkretny problem – „API nie działa od wczoraj”. Czasami to intuicja – „mam wrażenie, że to zadanie jest większe niż myśleliśmy”.
Wszystkie te sygnały są wartościowe. Nawet mglisty niepokój często okazuje się dobrze uzasadniony, gdy zespół wspólnie go przeanalizuje.
Faza druga: Poszukiwanie rozwiązań
Po zrozumieniu problemu przychodzi czas na drugie kluczowe pytanie: „Co możemy zrobić?„
Nie „co powinniśmy zrobić” – to brzmi jak przykazanie z góry. Nie „co musimy zrobić” – to brzmi jak kara. Tylko „co możemy zrobić” – to brzmi jak zaproszenie do współpracy.
W tej fazie mogą pojawić się różne rozwiązania:
Zmniejszenie zakresu sprintu
Przeniesienie części zadań do następnego sprintu
Poproszenie o pomoc innych zespołów
Zmiana podejścia technicznego
Eskalacja blokera do management
Doprecyzowanie wymagań z Product Ownerem
Faza trzecia: Kolejny kciuk
Po przedyskutowaniu problemów i potencjalnych rozwiązań, zadaj pytanie ponownie: „Jak teraz czujecie się z celem sprintu?”
To nie jest formalność – to sprawdzenie, czy zespół naprawdę czuje się lepiej po rozmowie. Czasami okaże się, że dyskusja pomogła i kciuki idą w górę. Czasami okaże się, że problemy są głębsze i nadal mamy kciuki w dół.
Oba scenariusze są w porządku. Ważne, że mamy prawdziwą informację o stanie zespołu, nie iluzoryczną pewność.
Kiedy kciuki nadal są w dół
Jeśli po rozmowie i poszukiwaniu rozwiązań zespół nadal pokazuje kciuki w dół, to może oznaczać, że:
Problem jest poważniejszy niż początkowo sądziliśmy
Potrzebujemy więcej czasu na implementację rozwiązania
Cel sprintu rzeczywiście jest zagrożony
I to też jest wartościowa informacja. Lepiej wiedzieć o tym na początku tygodnia niż w piątek po południu.
Jak wprowadzić tę sztuczkę bez palców w drzwi?
1. Opowiedz historię
Ludzi przekonują anegdoty bardziej niż slajdy. Zamiast teoretyzować o korzyściach, opowiedz o konkretnym zespole, który dzięki tej technice uniknął katastrofy sprintowej. Albo o tym, jak kciuk w dół jednego developera uratował cały release.
2. Zacznij od siebie
Pierwszy podnieś kciuk (albo opuść, jeśli trzeba). Pokaż, że to normalne, że Scrum Master też może mieć wątpliwości. Jeśli zespół zobaczy, że nie boisz się pokazać niepewności, będzie mu łatwiej zrobić to samo.
3. Nie interpretuj publicznie pojedynczych kciuków
Czerwony palec ≠ czerwony Dev. Nie mów „widzę, że Michał ma wątpliwości”. Skup się na ogólnym obrazie: „widzę kilka kciuków w dół, porozmawiajmy o obawach zespołu”.
4. Dbaj o bezpieczeństwo psychologiczne
Palec w dół to prezent, nie wstyd. Podkreślaj, że sygnalizowanie problemów to odpowiedzialność każdego członka zespołu. Dziękuj za szczerość, nie krytykuj za „pesymizm”.
5. Śledź trend, nie punkt
Trzy kolejne sprinty na zielono? Można luzować pasek. Trzy czerwone? Czas na poważniejsze zmiany. Jeden kciuk w dół to informacja, trend kciuków w dół to sygnał do działania.
6. Dostosuj do kultury zespołu
W niektórych zespołach lepiej sprawdzi się pięć palców (od 1 do 5), w innych kolory (zielony/żółty/czerwony). Ważna jest idea – szybka, wizualna, bezpieczna komunikacja o stanie sprintu.
Podsumowanie
W dobie zaawansowanych dashboardów, AI-predictorów i innych cudów technologicznych, mały kciuk nadal może zdziałać cuda. To nie jest kolejny framework czy metodologia – to po prostu narzędzie do szybkiej komunikacji. Proste, skuteczne, ludzkie.
Spróbujcie jutro na Daily. Zadajcie pytanie, zobaczcie kciuki, porozmawiajcie o tym, co zobaczycie. Najwyżej… pokażecie mi kciuk w dół – i też będzie dobrze, bo coś się dowiemy. 😉
Pamiętajcie: cel to nie zielone kciuki za wszelką cenę. Cel to prawdziwa informacja o stanie sprintu i zespole, który czuje się komfortowo z mówieniem prawdy. Kciuk w dół to nie porażka – to starting point dla lepszego sprintu.
Dokument opisuje zasady prowadzenia ćwiczenia z zakresu budowania zespołu, które polega na przeprowadzeniu sesji tworzenia autoprezentacji w formie instrukcji obsługi. Pisząc ten dokument, myślę o zespole Agile z prowadzącym Scrum Masterem, ale może być aplikowany do dowolnych zespołów – od korporacyjnych po startup’owe, od zdalnych po tradycyjnie biurowe.
Jaki cel ma ćwiczenie?
Cel jest prosty jak budowa młotka: lepsze poznanie siebie i zespołu. Brzmi jak truizm? Może trochę, ale w praktyce okazuje się, że większość z nas pracuje ramię w ramię z ludźmi, o których wie tyle, ile o sąsiadach – czyli praktycznie nic poza tym, że są i czasem się odzywają.
Ćwiczenie ma na celu:
Przełamanie barier komunikacyjnych – bo łatwiej rozmawiać z kimś, kogo trochę znasz
Zrozumienie preferencji współpracy – jedni lubią cisze, drudzy burze mózgów, trzeci potrzebują kawy co godzinę
Odkrycie ukrytych talentów – może okaże się, że kolega z IT świetnie gra na gitarze, a koleżanka z HR ma patent na uspokajanie zdenerwowanych klientów
Stworzenie atmosfery zaufania – gdy ludzie wiedzą, że możesz „zwariować” po trzech nieudanych deploymentach, łatwiej ci pomoże
Zwiększenie empatii w zespole – rozumienie, że każdy ma swoje mocne i słabe strony
Jakich efektów można oczekiwać?
Efekty sprawdzają się jak szwajcarski zegarek – pod warunkiem, że zespół podchodzi do sprawy z otwartością większą niż okno w letni dzień.
Efekty krótkoterminowe (widoczne od razu):
Rozluźnienie atmosfery – ludzie się śmieją, żartują, okazuje się, że praca to nie tylko deadline’y i stres
Lepsze zrozumienie ról – każdy wie, kto za co odpowiada i w czym może pomóc
Wzrost komfortu komunikacji – łatwiej poprosić o pomoc, gdy wiesz, że druga osoba lubi pomagać
Odkrycie wspólnych zainteresowań – może znajdziecie się fani tej samej książki, filmu czy gry
Efekty średnioterminowe (po kilku tygodniach):
Poprawa jakości komunikacji – ludzie wiedzą, jak się do siebie zwracać, żeby być zrozumianym
Zwiększenie skuteczności współpracy – mniej nieporozumień, więcej synergii
Lepsze rozwiązywanie konfliktów – łatwiej zrozumieć punkt widzenia drugiej strony
Wzrost zaangażowania – ludzie chętniej współpracują z tymi, których znają
Efekty długoterminowe (po miesiącach):
Silniejsze więzi zespołowe – zespół staje się więcej niż sumą swoich części
Wyższa produktywność – mniej czasu na wyjaśnianie, więcej na działanie
Lepsze zarządzanie stresem – ludzie wiedzą, jak wspierać się nawzajem
Zwiększona retencja – ludzie zostają tam, gdzie czują się dobrze
Założenia
Zanim przejdziemy do konkretów, ustalmy zasady gry – bo bez nich to jak granie w piłkę bez bramek:
W ćwiczeniu bierze udział moderator i zespół – moderator to ten, który pilnuje, żeby nikt nie uciekł z sali
Zespół może brać udział zarówno lokalnie, jak i zdalnie – pandemia nauczyła nas, że można robić wiele rzeczy przez ekran
Sesja nie ma ograniczeń liczby osób – sprawdza się od 3 do 30 osób, choć z większymi grupami moderator potrzebuje więcej cierpliwości
Ćwiczenie jest prowadzone w formie lekkiej zabawy – żadnego korporacyjnego patosu, tylko luz i śmiech
Z ćwiczenia nie będą wyciągane konsekwencje – to nie jest ocena pracownicza, tylko poznawanie się
Instrukcje nie będą opracowywane poza zespołem – są pisane przez zespół i dla zespołu, punkt
Przebieg sesji
Sesja ma swoją choreografię – nie tak skomplikowaną jak balet, ale strukturę ma:
Wprowadzenie (10-15 minut)
Moderator tłumaczy cel ćwiczenia – lepsze poznanie siebie i zespołu, bez korporacyjnego bełkotu
Moderator przedstawia założenia – żeby wszyscy wiedzieli, na co się piszą
Moderator pokazuje przykładową instrukcję oraz proponowany szablon – bo bez wzorca to jak gotowanie bez przepisu
Moderator wzbudza dyskusję nad ćwiczeniem – zachęca do aktywnego udziału, ale nie zmusza jak sprzedawca odkurzaczy
Właściwe ćwiczenie (30-45 minut)
Ćwiczenie rozpoczyna się wyborem – „To kto chce być pralką?” – i tu zazwyczaj pada pierwsza seria śmiechu
Każdy pisze swoją instrukcję – może samodzielnie, w parach lub małych grupach
Moderator krąży i wspiera – odpowiada na pytania, dodaje otuchy, pilnuje czasu
Prezentacja i dyskusja (20-30 minut)
Zespół czyta instrukcje – każdy prezentuje swoją lub grupa prezentuje wspólną
Omawianie wniosków – bez głębokiej analizy, ale w formie zabawy
Komentarze i pytania – „Aha, więc dlatego zawsze prosisz o wszystko mailowo!”
Zakończenie (5-10 minut)
Całość instrukcji jest archiwizowana w zespole – można do nich czasem wracać, szczególnie gdy dołącza nowa osoba
Podsumowanie – krótkie, pozytywne, bez przemów
Zalecenia
Żeby nie wpaść w korporacyjne pułapki, warto pamiętać o kilku rzeczach:
Sesja powinna zostać wcześniej zapowiedziana, a udział w niej dobrowolny – nikt nie lubi niespodzianek, szczególnie w pracy
Moderator powinien mieć przygotowaną instrukcję – żeby wyznaczyć poziom, pokazać lekkość i oczekiwania od zadania
Posiadanie instrukcji nie zwalnia moderatora z pisania – jeśli chcesz, żeby inni się otworzyli, sam musisz dać przykład
Nie należy narzucać sposobu wykonania – może być samodzielny, w parach czy grupach, choć samodzielny jest najbardziej oczekiwany
Moderator powinien dostarczyć wzory – wydrukowane instrukcje obsługi sprzętów lub chociaż zdjęcia
Instrukcje powinny być zróżnicowane – pralka, telewizor, smartfon, ekspres do kawy – im więcej różnorodności, tym lepiej
Nowa osoba w zespole może uzupełnić zestaw – świetny sposób na integrację nowicjuszy
Przykładowy szablon instrukcji
Nazwa urządzenia: Roman 2000 Full-Stack Model: Programista uniwersalny z funkcją debugowania Klasa energetyczna: A+ (po kawie), C (przed poranną dawką kofeiny)
1. Przeznaczenie „urządzenia”
Roman 2000 Full-Stack to zaawansowany model programisty przystosowany do obsługi projektów od frontendu po backend. Idealny do pracy w zespołach Agile, gdzie wymagana jest elastyczność i szybkie przełączanie między różnymi technologiami. Posiada wbudowany moduł rozwiązywania problemów i funkcję automatycznego uspokajania zdenerwowanych klientów.
2. Zasady „instalacji”
Przed pierwszym użyciem:
Zapewnić dostęp do kawy wysokiej jakości (minimum 2 filiżanki dziennie)
Przygotować stanowisko z dwoma monitorami (trzeci monitor zwiększa wydajność o 30%)
Zainstalować Slack, ale ograniczyć powiadomienia do pilnych spraw
Umieścić w pomieszczeniu z naturalnymi źródłami światła
Zapewnić dostęp do internetu (urządzenie bez internetu to jak pralka bez wody)
Konfiguracja początkowa:
Pierwszego dnia pokazać, gdzie jest najlepsza kawa w biurze
Przedstawić zespół i jego specjalizacje
Udostępnić dokumentację projektów
Ustawić spotkanie 1:1 z bezpośrednim przełożonym
3. Opis funkcji i możliwości
Funkcje podstawowe:
Programowanie w JavaScript, Python, Java
Debugowanie kodu (własnego i cudzego)
Code review z konstruktywnymi komentarzami
Architektura systemów od zera
Funkcje dodatkowe:
Tłumaczenie wymagań biznesowych na język techniczny
Uspokajanie zdenerwowanych PM-ów
Automatyczne wykrywanie potencjalnych problemów w kodzie
Funkcja mentorowania juniorów (aktywuje się po 2 latach doświadczenia)
Tryby pracy:
Tryb głębokiego fokus – najwyższa produktywność, nie przeszkadzać
Tryb współpracy – dostępny do dyskusji i pair programmingu
Tryb kreatywny – generuje innowacyjne rozwiązania
Tryb awaryjny – uruchamia się automatycznie przy krytycznych bugach
4. Warunki użytkowania
Optymalne warunki pracy:
Temperatura: 20-22°C (może pracować w szerszym zakresie, ale narzeka)
Wilgotność: nie krytyczna, ale suche powietrze może powodować elektryzowanie się przy dotykaniu klawiatury
Oświetlenie: naturalne światło + lampka biurkowa
Poziom hałasu: maksymalnie średni (słuchawki z noise cancellation załączone w zestawie)
Godziny pracy:
Szczytowa wydajność: 9:00-12:00 i 14:00-17:00
Tryb slow-start: 8:00-9:00 (wymagana kawa)
Tryb awaryjny: dostępny po godzinach w krytycznych sytuacjach
Sposób komunikacji:
Slack dla szybkich pytań
Email dla formalnych spraw
Rozmowa twarzą w twarz dla skomplikowanych problemów
Karta Jira dla zadań do wykonania
5. Wykrywanie problemów
Sygnały ostrzegawcze:
Nadmierne używanie słów „refaktor” i „to trzeba przepisać”
Mamrotanie pod nosem podczas czytania cudzego kodu
Spontaniczne rysowanie diagramów na kartce/tablicy
Częste sprawdzanie Stack Overflow
Komunikaty błędów:
„To nie będzie działać” – oznacza konieczność przedyskutowania rozwiązania
„Hm, ciekawe…” – wykrył potencjalny problem, wymaga dalszej analizy
„Może spróbujmy inaczej” – obecne podejście wymaga zmiany
Cisza dłuższa niż 10 minut – prawdopodobnie wszedł w tryb głębokiego debugowania
6. Warunki gwarancji
Gwarancja zostanie utracona w przypadku:
Wymuszonego używania Internet Explorer do testowania
Zmian w kodzie bez code review
Spotkań dłuższych niż 1 godzinę bez konkretnego celu
Przerywania w trybie głębokiego fokus bez ważnego powodu
Braku aktualizacji dokumentacji przez dłuższy czas
Zalecane konserwacje:
Cotygodniowe spotkania 1:1 z przełożonym
Miesięczne retrospektywy zespołu
Kwartalne przeglądy kodu i architektury
Roczne szkolenia z nowych technologii
Aktualizacje:
Automatyczne pobieranie najnowszych wersji bibliotek
Regularne czytanie tech blogów i dokumentacji
Uczestnictwo w konferencjach programistycznych
Eksperymentowanie z nowymi technologiami w czasie wolnym
Ostrzeżenia:
Nie wystawiać na długotrwały kontakt z legacy kodem bez odpowiednich zabezpieczeń
Unikać pracy w trybie ciągłego crunch time – może prowadzić do wypalenia
Nie pozostawiać bez nadzoru przy dostępie do produkcyjnej bazy danych
Inne informacje
Rozróżnienie pojęć – bo precyzja to podstawa:
Ćwiczenie – całość działania od zapowiedzi przez wykonanie aż do konsumowania efektów
Sesja – konkretne spotkanie, na którym tworzone są instrukcje
Alternatywne podejście – jeśli zespół woli bardziej poważną formę, można zastosować podejście opisane przez Dominika Juszczyka, które zawiera elementy:
Kiedy jestem najlepszą wersją siebie – warunki, które pozwalają mi się rozwinąć
Wartość, jaką wnoszę do zespołu – moje mocne strony i umiejętności
Potrzebuję od Ciebie – co mi pomoże w pracy i współpracy
Możesz na mnie liczyć – w czym chętnie i skutecznie pomogę
Warto o mnie wiedzieć – dodatkowe informacje, ciekawostki, hobby
Podsumowanie
Instrukcja obsługi zespołu to nie kolejny korporacyjny wymysł, tylko praktyczne narzędzie poznania. Jak każde narzędzie – działa, gdy się go używa, a nie trzyma w szafie. Najważniejsze to pamiętać, że za każdym „urządzeniem” w zespole stoi człowiek z własnymi potrzebami, preferencjami i sposobem działania.
A może najważniejsze odkrycie będzie takie, że kolega z działu obok też nie lubi poniedziałkowych spotkań o 8:00 rano. Czasem to właśnie takie małe rzeczy budują najsilniejsze więzi zespołowe.
Nie czekaj na szefa, który cię zmotywuje – zadbaj o siebie sam. To brzmi jak porada z kalendarza motywacyjnego, ale ma w sobie więcej sensu, niż mogłoby się wydawać.
Zazwyczaj rozmawiamy o problemach motywacji w kontekście leaderów, którzy powinni zwracać uwagę na potrzeby oraz motywatory ludzi i zespołów, którym pomagają.
Tak, to jest ważne. Tak, to jest prawda. Tak, za mało się o to dba w firmach, ale… … każdy pracownik, każdy specjalista może też zadbać o siebie i jest to opłacalne. Dla wszystkich.
Sekret: szefowie, managerowie, koledzi a nawet większość tak zwanych leaderów: – nie znają się, – nie wiedzą, – nie mają umiejętności, – nie mają czasu, -… a jeśli wiedzą, to często zapominają po pewnym czasie.
jak Cię zmotywować
Pracując ze specjalistami „jeden na jeden” często pojawiają się hasła takie jak: zadowolenie, bycie szczęśliwym, zapierdol, praca, wyniki, podwyżki i awanse.
Okazuje się, że można je połączyć jednym nieoczywistym hasłem: motywacja.
Uwaga, ten artykuł jest długi. Jeśli Ci się nudzi czytanie, omiń dialog i przeskocz na koniec do pomysłów, na które zazwyczaj wpadają moi klienci.
Oto jedna z takich rozmów:
Mike: Co sprawia, że czujesz się zmotywowany w pracy?
Sebastian: Hmm… Chyba jak wiem, po co robię to, co robię. I jak mogę wpływać na to, jak to robię. Nie lubię, jak ktoś mi mówi dokładnie krok po kroku, co mam zrobić.
M: A kiedy ostatnio czułeś się tak naprawdę zaangażowany?
S: Było to jakieś pół roku temu. Pracowałem w tym nowym projekcje (…) i Tribe Leader mówił, jaki ma być cel biznesowy, mieliśmy sporo przestrzeni na wypracowanie architektury i zbudowanie dobrego rozwiązania. Plus dostawałem feedback na bieżąco, nie musiałem czekać miesiąc na ocenę.
M: Co jeszcze było ważne w tamtej sytuacji?
S: To, że wiedziałem, że to ma sens. Że użytkownicy naprawdę tego potrzebują. I że mogliśmy przy tym przejść na nową technologię i odbagnić architekturę.
M: A teraz? Jak wygląda twoja motywacja w obecnym projekcie?
S:wzdycha No właśnie… Teraz dostaję zadania bez kontekstu. „Zrób to i to”. Nie wiem, po co to robię. Szef sprawdza co godzinę, na jakim jestem etapie. I głównie naprawiam stare bugi, żadnej nowej wiedzy.
M: Brzmi frustrująco. A co by się stało, gdybyś powiedział szefowi, czego potrzebujesz, żeby być zmotywowanym?
S:pauza Nie wiem… Może pomyślałby, że jestem wybredny? Albo że nie chce mi się pracować?
M: A jak myślisz – czy twój szef chce, żebyś był zmotywowany i efektywny?
S: No pewnie tak… W końcu od tego zależy sukces projektu.
M: Więc gdybyś mu powiedział (poczekaj, podsumuję co zapisałem z tego co mówiłeś): „Jestem najbardziej zmotywowany, gdy wiem, po co robię zadanie, mogę wpływać na sposób wykonania i dostaję feedback na bieżąco” – czy to brzmi jak problem czy jak rozwiązanie?
S:moment zastanowienia Jak rozwiązanie. Ale… czy to nie jest dziwne, że mam mu mówić, jak ma mną zarządzać?
M: A czy to nie jest dziwne, że oczekujesz, że będzie zgadywał, co cię motywuje?
S:śmiech Racja. To jak… instrukcja obsługi?
M: Dokładnie. Co jeszcze mógłbyś mu powiedzieć o tym, co cię demotywuje?
S: Że mikromanagement mnie zabija. Że praca tylko nad bugami przez miesiące to koszmar. I że jak nie wiem, czy to, co robię, ma sens, to tracę energię.
M: A gdybyś to wszystko napisał i przedyskutował z szefem?
S: Myślę, że… że mógłby to zrozumieć. W końcu sam był kiedyś programistą i architektem. Może po prostu nie wie, że to dla mnie ważne.
M: Co jeszcze mógłbyś zrobić, żeby zadbać o swoją motywację?
S: Mogę też porozmawiać z zespołem. Może inni mają podobne potrzeby. I mogę prosić o konkretne rzeczy – na przykład o to, żeby dostać jeden dzień w tygodniu na naukę nowych technologii.
M: Brzmi jak plan. Co będzie twoim pierwszym krokiem?
S: Napiszę sobie listę tego, co mnie motywuje i co demotywuje. A potem umówię się z szefem na rozmowę. Muszę im powiedzieć, jak mnie motywować i pilnować, żeby się tego trzymali.
Nauka potwierdza intuicję
Badania pokazują, że motywacja wewnętrzna ma ogromny wpływ na efektywność. Zespół psychologów (dr. Christopher P. Cerasoli, prof. Jessica M. Nicklin oraz prof. Michael T. Ford z University) przeprowadził solidną metaanalizę opartą na 40-letnich badaniach związku między motywacją a efektywnością. Wyniki są jednoznaczne: Motywacja wewnętrzna okazała się średnio do silnie skorelowana z wydajnością (współczynnik korelacji ρ = 0.21-0.45). Co szczególnie istotne – ta korelacja pozostaje stabilna niezależnie od obecności zewnętrznych zachęt..
To oznacza, że jeśli znajdziesz sposób na to, żeby lubić to, co robisz, będziesz pracować znacznie efektywniej niż wtedy, gdy ktoś próbuje cię zmotywować tylko premią czy podwyżką.
Dodatkowo, badania wskazują, że na wystąpienie i rozwój motywacji wewnętrznej wpływają między innymi: poczucie znaczenia pracy, poczucie odpowiedzialności oraz znajomość wyników pracy. To są rzeczy, na które masz bezpośredni wpływ!
Konkretne metody samonapędzania
Metoda „Instrukcji Obsługi”
Napisz dosłownie instrukcję obsługi samego siebie. Może brzmieć dziwnie, ale działa. Oto przykład:
*”Jestem zmotywowany, gdy:
Wiem, po co robię konkretne zadanie (cel biznesowy)
Mogę wpływać na sposób wykonania zadania
Dostaję feedback w trakcie pracy, nie tylko na końcu
Pracuję nad rzeczami, które mają sens dla użytkowników
Mam czas na naukę nowych rzeczy”*
*”Jestem demotywowany, gdy:
Dostaję zadania bez kontekstu
Ktoś mikromanaguje każdy mój krok
Nie wiem, czy to, co robię, ma jakikolwiek sens
Pracuję tylko nad bugfixami przez miesiące”*
Metoda „Proaktywnej Rozmowy”
Zamiast czekać na roczną ocenę, umów się z szefem na kawę i powiedz:
„Chciałbym z tobą porozmawiać o tym, jak mogę być bardziej efektywny. Zauważyłem, że jestem najbardziej zmotywowany, gdy… A tracę energię, gdy… Czy możemy spróbować tak pokierować moimi zadaniami, żeby wykorzystać to, co mnie napędza?”
Metoda „Małych Eksperymentów”
Jeśli nie wiesz, co cię motywuje, eksperymentuj. Przez tydzień spróbuj pracować w inny sposób:
Zmień porę, o której robisz najtrudniejsze zadania
Poproś o feedback na początku i w połowie zadania zamiast na końcu
Zaproponuj inne podejście do problemu
Znajdź sposób na zmierzenie wpływu swojej pracy
Obserwuj, kiedy czujesz się bardziej energiczny i zaangażowany.
Dlaczego to działa?
Kiedy jesteśmy zmotywowani, wszystko się układa. Badania potwierdzają, że motywacja wewnętrzna jest związana z poczuciem znaczenia pracy, odpowiedzialnością i znajomością wyników. Gdy te elementy są na miejscu, naturalnie osiągamy lepsze rezultaty.
A lepsze rezultaty to nie tylko satysfakcja osobista i poczucie szczęścia. To też konkretne korzyści: podwyżki, awanse, ciekawsze projekty, lepsze relacje w zespole.
To się kręci jak koło zamachowe: -> im bardziej jesteś zmotywowany, -> tym lepiej pracujesz, -> tym więcej dostajesz, -> tym bardziej jesteś zmotywowany.
Odwaga w pracy
Takie odkrycie się budzi obawę: A co jeśli to wykorzystają przeciwko mnie? Nic się nie stanie. Gorzej nie będzie.
Osiągnięcie w pracy wyników / uznania / kasy / awansu (nie wiem co motywuje akurat Ciebie) i w związku z tym poczucia szczęścia wymaga sporo odwagi:
Odwagi, żeby powiedzieć szefowi, czego potrzebujesz.
Odwagi, żeby eksperymentować z nowymi sposobami pracy.
Odwagi, żeby przyznać, że niektóre rzeczy cię demotywują.
Ale alternatywa to latami siedzenie w pracy, która wysysa z ciebie energię, narzekanie na szefa, który „nie umie motywować” i czekanie na jakiś cud, który nagle sprawi, że będziesz kochać poniedziałki.
Jak jesteśmy zmotywowani, to wszystko się układa. Zadbajmy o siebie. Warto działać – bo nikt nie zrobi tego za nas, a szczęście w pracy to nie luksus, tylko podstawowa potrzeba każdego, kto spędza w pracy 8 godzin dziennie.
Wyobraź sobie sytuację: HR przysyła ci nowego kolegę z komunikatem „Oto wasz nowy członek zespołu. Ma świetne CV i przeszedł wszystkie etapy rekrutacji”. A ty patrzysz na niego i myślisz „Okej, ale czy będę z nim mógł pracować przez następne dwa lata?”. Brzmi znajomo?
Problem z tradycyjną rekrutacją
Klasyczna rekrutacja to trochę jak kupowanie butów przez internet – na zdjęciu wyglądają świetnie, ale dopiero gdy je założysz, okazuje się, że uciskają w palcach. HR sprawdza kompetencje, manager sprawdza doświadczenie, a zespół? Zespół dowiaduje się o nowym członku w poniedziałek rano.
Efekt? Nowy człowiek może być genialnym specjalistą, ale jeśli jego sposób komunikacji przypomina telegram z 1920 roku, a zespół lubi gadać o wszystkim i niczym podczas Daily – mamy problem. Albo odwrotnie – ktoś, kto potrzebuje ciszy jak mnich w klasztorze, trafia do zespołu, który dyskutuje każdy kawałek kodu jak eksperci od futbolu w telewizji.
Rekrutacja przez zespół – jak to działa w praktyce
W kilku firmach udało mi się przekonać ludzi do zupełnie innego podejścia. Proces wygląda tak:
Etap 0: Rekruterzy przedstawiają kandydatów (opcjonalny) Klasyczne przesiewanie CV. Nic nowego pod słońcem.
Etap 1: Krótka rozmowa techniczna Jeden ze specjalistów z zespołu rozmawia z kandydatem 30-45 minut. Cel? Sprawdzić poziom wiedzy i doświadczenia. Bez wchodzenia w szczegóły implementacji algorytmu sortowania bąbelkowego czy pytań typu „ile waży słoń w Javie”. Po prostu: czy ta osoba wie, o czym mówimy?
Etap 2: Rozmowa z całym zespołem I tu dzieje się magia. Kandydat spotyka się z całym zespołem, w którym ma pracować. Wszyscy zadają pytania, wszyscy obserwują, wszyscy podejmują decyzję. To nie jest przesłuchanie – to poznawanie się.
Etap 3: Rozmowa o kasie Manager liniowy ustala warunki finansowe. Koniec, kropka, podpis na umowie.
Dlaczego to ma sens?
Kiedy wprowadzałem ten system, zawsze pytałem kandydatów na koniec rozmowy: „Jak by się Pan/Pani czuł, gdyby następny etap to spotkanie z zespołem?”. I przedstawiałem argumenty:
Masz być częścią zespołu – więc niech zespół sprawdzi, czy twój charakter pasuje do tego, co sam o sobie opowiadasz
Masz przynieść wartość zespołowi – może pozwólmy zespołowi ocenić, czy widzi tę wartość
Jeśli zespół powie „Tak” – będziesz miał wsparcie od pierwszego dnia
Jeśli zespół powie „Nie” – cóż, nie ma sensu się męczyć
Reakcje? Zawsze pozytywne. „Nigdy nie byłem na takiej rozmowie, ale widzę duży sens”. Niektórzy wyrażali obawy, ale stwierdzali, że warto spróbować.
Przykłady z życia wzięte
Przypadek pierwszy: Senior Developer z problemem komunikacyjnym Kandydat miał świetne CV – 8 lat doświadczenia, znał wszystkie frameworki na pamięć. Podczas rozmowy technicznej błyszczał. Ale gdy spotkał się z zespołem, okazało się, że jego sposób komunikacji to seria monologów. Zespół pracował w trybie ciągłych konsultacji i współpracy. Verdict? „Świetny specjalista, ale nie dla nas”.
Przypadek drugi: Junior z potencjałem Młoda programistka, rok doświadczenia, CV skromne jak mniszka. Ale podczas spotkania z zespołem zadawała świetne pytania, słuchała uważnie, a jej energia była zaraźliwa. Zespół stwierdził: „Nauczymy ją wszystkiego, ale chcemy ją u siebie”. Rok później była jedną z najlepszych w zespole.
Przypadek trzeci: Ekspert, który nie pasował kulturowo Kandydat z 15-letnim doświadczeniem, guru w swojej dziedzinie. Ale podczas rozmowy z zespołem wyszło, że jego podejście to „ja wiem lepiej, a wy się uczcie”. Zespół cenił sobie równość i wzajemne uczenie się. Mimo kompetencji – nie przeszedł.
Co zespół sprawdza podczas takiej rozmowy?
Chemię zespołową Czy ta osoba będzie pasować do naszego sposobu gadania, żartowania, rozwiązywania konfliktów? To nie jest pytanie o kompetencje – to pytanie o to, czy będziemy się lubić przez następne lata.
Podejście do pracy Jeden zespół lubi długie dyskusje o architekturze, inny woli szybkie decyzje i iteracje. Jeden ceni sobie precyzję, inny eksperymentowanie. Kandydat może być genialny, ale jeśli jego styl pracy jest przeciwny do zespołowego – będzie cierpienie.
Motywację i wartości Czy ta osoba chce się rozwijać w tym samym kierunku co zespół? Czy ma podobne podejście do jakości kodu, testowania, dokumentacji? Czy będzie ciągnąć zespół do przodu, czy hamować?
Korzyści dla wszystkich
Dla zespołu:
Mają wpływ na to, kto do nich dołącza
Biorą odpowiedzialność za integrację nowej osoby
Czują się współodpowiedzialni za sukces rekrutacji
Dla kandydata:
Wie, z kim będzie pracować
Może ocenić, czy zespół mu odpowiada
Zaczyna z poparciem całej grupy
Dla firmy:
Mniejsze ryzyko nietrafionej rekrutacji
Szybsza integracja nowych ludzi
Lepsze dopasowanie kulturowe
Kiedy to nie działa?
Ten system ma sens tylko w zespołach, które rzeczywiście współpracują. Jeśli ludzie siedzą w swoich norach i kontaktują się tylko przez Slacka, to rekrutacja przez zespół to strata czasu. Ale jeśli pracujecie razem, planujecie razem, rozwiązywacie problemy razem – to zespół wie najlepiej, kogo potrzebuje.
Podsumowanie
Zespół wie najlepiej, stanowi sam o sobie, podejmuje decyzje, podejmuje odpowiedzialność. Kto spróbował tego podejścia, chyba nigdy już nie wrócił do klasycznej rekrutacji. Bo po co zgadywać, skoro można zapytać tych, którzy będą pracować z nową osobą każdego dnia?
Jak mówię zawsze – można budować zespoły na siłę, a można pozwolić im się budować samym. Drugie wyjście jest po prostu mądrzejsze.
Kto ze mną pracował wie, że często poruszam temat zaufania, odwagi i wrażliwości.
Teraz zbieram myśli, strukturyzuję je i chciałem Was zaprosić do pomyślenia ze mną nad tymi tematami. Będzie tych myśli niewiele – miej niż sześć, trochę więcej niż cztery, tak około pięć.
Myśl #1: Zaufanie to nie słabość – to inwestycja, która przynosi nieoczekiwane zyski
Wyobraź sobie, że jesteś kapitanem statku. Możesz albo stać przy każdym członku załogi i kontrolować każdy jego ruch, albo zaufać ich kompetencjom i skupić się na wyznaczaniu kursu. Która strategia doprowadzi Cię dalej? Odpowiedź może być zaskakująca dla tych, którzy wierzą w mikro-management.
Badania jednoznacznie wskazują, że zespoły o wysokim poziomie zaufania są aż o 50% bardziej produktywne od tych, gdzie króluje nieufność i kontrola. To nie jest opinia – to twarde dane. Stephen Covey nie bez powodu nazwał swoją przełomową książkę „Speed of Trust” – prędkość zaufania. Bo właśnie o to chodzi – zaufanie przyspiesza wszystko.
Innowacje nie rodzą się w atmosferze podejrzliwości
Kiedy umysł jest uwięziony w spirali podejrzeń, jego kreatywne moce zostają drastycznie ograniczone. To jak próba komponowania symfonii, podczas gdy ktoś ciągle zagląda ci przez ramię i kwestionuje każdą nutę. Badania Amy Edmondson z 1999 roku wykazały, że psychologiczne bezpieczeństwo i zaufanie w zespołach zwiększają innowacyjność nawet o 30%. Wyobraź sobie – o jedną trzecią więcej przełomowych pomysłów, rozwiązań i udoskonaleń tylko dlatego, że ludzie nie boją się dzielić swoimi koncepcjami!
W praktyce widziałem to niezliczoną ilość razy. Zespół, który czuje, że może bezpiecznie eksperymentować, generuje rozwiązania, o których istnieniu nikt wcześniej nawet nie marzył. A zespół, w którym każda porażka jest powodem do wstydu i obwiniania? Tam innowacje umierają w zarodku.
Autentyczne relacje biznesowe jako katalizator sukcesu
Harvard Business Review opublikował w 2018 roku badanie, które dla wielu menedżerów było prawdziwym szokiem: autentyczne relacje biznesowe mogą przyspieszyć realizację projektów nawet o 40%. Wyobraźcie sobie – ten sam projekt, ci sami ludzie, te same zasoby, ale wykonany o prawie połowę szybciej. Jak to możliwe?
Odpowiedź kryje się w czasie i energii, jakie poświęcamy na zabezpieczanie się przed potencjalnym rozczarowaniem. Ile razy pisałeś długi email, by „mieć wszystko na piśmie”? Ile spotkań spędziłeś na ustalaniu, kto za co dokładnie odpowiada (czytaj: kogo obwinimy, gdy coś pójdzie nie tak)? Ta „transakcyjna ostrożność” zjada czas, który mógłby być przeznaczony na faktyczną pracę.
Sen, zaufanie i wydajność – nieoczywiste powiązanie
A teraz coś, co może wydawać się niezwiązane, ale ma głęboki związek z naszym tematem. National Sleep Foundation przeprowadziła w 2020 roku badania, które wykazały, że lepsza jakość snu poprawia funkcje poznawcze i podejmowanie decyzji o 20-30%. Co to ma wspólnego z zaufaniem?
Kiedy nie ufasz swoim współpracownikom, twój mózg nawet podczas odpoczynku pracuje na zwiększonych obrotach. Analizuje, kalkuluje ryzyko, planuje awaryjne scenariusze. To wyczerpujące – zarówno fizycznie, jak i mentalnie. Rezultat? Gorszy sen, mniejsza jasność umysłu, słabsze decyzje.
Paradoks polega na tym, że wolimy tracić energię na kontrolę zamiast zainwestować ją w rozwój. Wyobraź sobie, ile mógłbyś osiągnąć, gdybyś tę samą energię, którą poświęcasz na nieufność, przekierował na kreatywne rozwiązywanie problemów? Gallup w 2017 roku wykazał, że liderzy budujący zaufanie nie tylko osiągają lepsze wyniki, ale także przyciągają najlepsze talenty, redukując rotację pracowników aż o 25%.
Zaufanie jako strategia biznesowa
Rozmawiamy tutaj nie o ciepłych, miękkich uczuciach, ale o twardej strategii biznesowej. Każda złotówka zainwestowana w budowanie zaufania zwraca się potrójnie – poprzez szybsze procesy, większą innowacyjność i wyższą retencję talentów.
Tak to działa: Zaufanie uwalnia potencjał kreatywny całego zespołu. Gdy przestajemy się bać, zaczynamy tworzyć przełomowe rozwiązania. To prosty mechanizm, który jednak wciąż jest niedoceniany w wielu organizacjach.
Praktyczne zastosowanie: od teorii do praktyki
Jak więc budować kulturę zaufania w praktyce? Oto kilka sprawdzonych przeze mnie strategii:
Zaczynaj od siebie – pokazuj swoją wrażliwość i przyznawaj się do błędów. Nic tak nie buduje zaufania jak autentyczność lidera.
Świętuj porażki jako lekcje – zespół, który wie, że może bezpiecznie popełniać błędy, będzie podejmować odważniejsze decyzje.
Eliminuj „politykę biurową” – jasne zasady awansów i doceniania eliminują potrzebę „gierek” i budują zaufanie do systemu.
Praktykuj „radykalną transparentność” – dziel się informacjami, które tradycyjnie były zarezerwowane dla wąskiego grona.
Inwestuj w relacje – znajdź czas na poznanie swojego zespołu jako ludzi, nie tylko jako zasobów.
Pytanie pobudzające: Masz przykłady dużej korzyści biznesowej, osiągniętej dzięki zaufaniu innym?
Myśl #2: Zaufanie to równanie, w którym wiarygodność jest zmienną, którą możemy kontrolować
Jestem z wykształcenia inżynierem, więc wybaczcie mi matematyczne podejście do tematu. Ale co jeśli zaufanie można przedstawić jako równanie? Co jeśli istnieje wzór, który pomoże nam zrozumieć, jak budować i wzmacniać zaufanie w naszych organizacjach?
Badania Mayera, Davisa i Schoormana z 1995 roku proponują fascynującą formułę:
Im wyższa wiarygodność, niezawodność i poziom otwartości, tym wyższe zaufanie. Im większa koncentracja na własnych interesach, tym niższe zaufanie.
Matematyka relacji międzyludzkich
Spójrzmy na to równanie z bliska. Wiarygodność to nasza ekspertyza i kompetencje – to, co wiemy i potrafimy. Niezawodność to konsekwencja w działaniu – dotrzymywanie obietnic i terminów. Intymność to poziom otwartości i szczerości w relacji. A orientacja na siebie? To stopień, w jakim koncentrujemy się na własnych korzyściach kosztem innych.
Co ciekawe, trzy pierwsze elementy mnożymy przez siebie, co oznacza, że jeśli którykolwiek z nich jest bliski zeru, całe zaufanie drastycznie spada. Z drugiej strony, orientacja na siebie znajduje się w mianowniku – im jest większa, tym mniejsze zaufanie.
Kouzes i Posner w swoich badaniach z 2012 roku potwierdzili, że wiarygodność budujemy poprzez konsekwentne działania i decyzje. To nie jednorazowe gesty czy wielkie deklaracje budują zaufanie, ale codzienna spójność między słowami a czynami.
Paradoks biznesowy kontroli
Tutaj pojawia się fascynujący paradoks biznesowy: dlaczego firmy inwestują miliony w kontrolę, zamiast w budowanie wiarygodności? Pomyśl o tym: ile kosztuje twoja organizacja systemy monitorowania, procedury zabezpieczające, wielostopniowe akceptacje? A ile inwestuje w rozwijanie wiarygodności swoich liderów i pracowników?
To jak budowanie coraz wyższego płotu zamiast zadbania o to, by nikt nie chciał uciekać. Widziałem organizacje, które wydają fortunę na systemy kontroli, a ignorują podstawowy fakt: nie możemy zmusić innych do ufności. Ale możemy systematycznie budować własną wiarygodność.
Projekt Arystoteles – naukowe potwierdzenie potęgi zaufania
W 2015 roku Google przeprowadził jedno z najbardziej fascynujących badań organizacyjnych naszych czasów, nazwane „Project Aristotle”. Przez dwa lata analizowano setki zmiennych wpływających na efektywność zespołów. Wyniki? Najbardziej efektywne zespoły nie były te złożone z największych geniuszy czy najlepiej opłacanych specjalistów. Kluczowym czynnikiem okazało się bezpieczeństwo psychologiczne – poczucie, że można podejmować ryzyko bez narażania się na wstyd czy karę.
Innymi słowy, zaufanie było fundamentem wydajności. W zespołach o wysokim poziomie bezpieczeństwa psychologicznego ludzie chętniej dzielili się pomysłami, przyznawali do błędów i współpracowali nad rozwiązaniami. Efekt? Szybszy rozwój produktów, lepsza obsługa klienta i większa innowacyjność.
Budowanie wiarygodności jako strategia biznesowa
Jak więc budować wiarygodność w praktyce? Oto kilka sprawdzonych strategii:
Konsekwencja w małych rzeczach – dotrzymuj obietnic, nawet tych drobnych. Punktualność na spotkaniach, odpowiadanie na maile, realizacja zobowiązań – to budulce wiarygodności.
Transparentność w niepowodzeniach – kiedy coś idzie nie tak, nie ukrywaj tego. Przyznaj się do błędu, wyciągnij wnioski, idź dalej.
Dziel się wiedzą – ekspertyza buduje wiarygodność, ale tylko jeśli jest widoczna i dostępna dla innych.
Spójność wartości i działań – upewnij się, że twoje decyzje odzwierciedlają wartości, które deklarujesz.
Doceniaj innych publicznie – wiarygodni liderzy nie boją się oddawać zasług zespołowi.
Wykładniczy wzrost zaufania
To, co fascynujące w zaufaniu organizacyjnym, to jego wykładniczy charakter. Badania pokazują, że zaufanie w organizacji rośnie wykładniczo z poziomem wiarygodności liderów. Jeden wiarygodny lider może zmienić kulturę całego działu, a kilku takich liderów może transformować całą firmę.
Przyszłość należy do organizacji, które rozumieją to równanie: wiarygodność zespołu × wzajemna ufność = sukces biznesowy. W świecie, gdzie coraz więcej pracy wymaga kreatywności, innowacji i współpracy, organizacje oparte na kontroli będą przegrywać z tymi budującymi zaufanie.
Pytania pobudzające:
- Jakie działania w Twojej organizacji najbardziej wpływają na budowanie wiarygodności?
- Czy widzisz w Twojej organizacji związek między poziomem zaufania a efektywnością zespołu?
Myśl #3: Zaczynam od pełnej kartki (100% kredytu zaufania), nie od pustej
Jestem człowiekiem, który notorycznie zapomina notatnika na spotkania. Dlatego często pożyczam kartkę od innych uczestników. Zastanówcie się – czy wolicie otrzymać czystą kartkę, czy taką z notatkami innej osoby? Większość wybierze czystą. Wolimy zaczynać od zera, mieć pustą przestrzeń do zapełnienia.
Z zaufaniem jest dokładnie odwrotnie. A przynajmniej powinno być.
Odwrócenie tradycyjnego myślenia
Konwencjonalna mądrość mówi: „Zaufanie trzeba zbudować”. Zaczynamy od zera i stopniowo, poprzez kolejne dowody wiarygodności, budujemy kapitał zaufania. Ale co jeśli to podejście jest fundamentalnie błędne? Co jeśli znacznie efektywniejsza strategia to zaczynać od pełnego zaufania – od 100% kredytu?
Badania Lewickiego i Bunkera z 1996 roku wykazały fascynującą prawidłowość: zespoły, które zaczynają od wysokiego poziomu wzajemnego zaufania, osiągają lepsze wyniki i szybszą spójność. Dlaczego? Bo od pierwszego dnia mogą skupić całą energię na zadaniu, zamiast na udowadnianiu swojej wartości.
Zaufanie jako samospełniająca się przepowiednia
Psycholog Julian Rotter już w 1980 roku zauważył, że zaufanie działa jak samospełniająca się przepowiednia. Kiedy dajesz ludziom kredyt zaufania, oni czują się zobowiązani, by na niego zasłużyć. To nie naiwność – to psychologiczny mechanizm, który wykorzystuje naszą naturalną tendencję do odwzajemniania pozytywnych oczekiwań.
Przykład z życia: w jednej z firm technologicznych, z którymi współpracowałem, nowy CEO wprowadził politykę nieograniczonych dni urlopowych. Tradycyjne myślenie przewidywało chaos i nadużycia. Co się stało? Pracownicy zaczęli brać MNIEJ dni wolnych niż wcześniej i planowali je z większą rozwagą. Dlaczego? Bo poczuli się obdarzeni zaufaniem i chcieli pokazać, że na nie zasługują.
Ryzyko braku zaufania
A co jeśli największym ryzykiem nie jest nadmierne zaufanie, lecz jego brak? Dirks i Ferrin w swoich badaniach z 2002 roku wykazali, że brak zaufania prowadzi do zwiększonych kosztów kontroli i obniżonej innowacyjności. Organizacje o niskim poziomie zaufania wydają więcej na monitorowanie, systemy kontroli i procedury zabezpieczające – wszystko to absorbuje zasoby, które mogłyby zostać przeznaczone na rozwój i innowacje.
Pomyśl o tym w ten sposób: jeśli zakładasz, że każdy może cię oszukać, ile czasu poświęcasz na zabezpieczanie się? Ile energii, która mogłaby iść na tworzenie wartości, idzie na ochronę przed potencjalnym oszustwem?
Praktyczne zastosowanie: 100% kredyt zaufania
Jak to działa u mnie? Kiedy zaczynam pracę z nowym zespołem lub osobą, daję im pełny kredyt zaufania. Zakładam ich kompetencje, dobre intencje i zaangażowanie. To nie oznacza braku struktury czy jasnych oczekiwań – wręcz przeciwnie. Ale w ramach tych oczekiwań daję maksymalną swobodę i autonomię.
Czy czasem się rozczarowuję? Oczywiście. Ale traktuję to jako koszt operacyjny, nie porażkę systemu. Statystycznie zyski z zaufania przewyższają straty – i to znacząco. To jak w inwestycjach – pojedyncze straty są nieuniknione, ale długoterminowa strategia przynosi zyski.
Wiara w ludzi jako motor rozwoju
Fascynujące jest to, jak twoja wiara w ludzi często staje się ich motywacją do rozwoju. Kiedy wyrażasz zaufanie do czyichś umiejętności i charakteru, tworzysz przestrzeń, w której mogą wzrastać. To jak danie komuś większych butów – na początku mogą się potykać, ale z czasem do nich dorosną.
Widziałem to wielokrotnie w praktyce coachingowej – liderzy, którzy ufają swoim zespołom, często są zaskoczeni tym, jak ludzie przerastają ich oczekiwania. Nie dlatego, że nagle stali się bardziej kompetentni, ale dlatego, że zaufanie odblokowało potencjał, który już w nich był.
Zaufanie jako waluta przyszłości
W ekonomii cyfrowej, gdzie współpraca i innowacja są kluczowe, zaufanie staje się walutą o rosnącej wartości. Wydając ją hojnie, paradoksalnie, powiększasz jej wartość. To jedyna waluta, której wartość rośnie, gdy ją wydajesz.
PS. To podejście zmienia nie tylko relacje, ale całe organizacje – zespoły z wysokim poziomem początkowego zaufania osiągają wyniki szybciej i działają efektywniej.
Pytanie pobudzające: Kiedy ostatnio dałeś komuś 100% kredytu zaufania od pierwszego dnia i jak to wpłynęło na waszą relację?
Myśl #4: Odbudowanie zaufania to proces – ale nie musi oznaczać ani naiwności, ani zemsty
Wszyscy doświadczyliśmy zdrady zaufania. Może partner biznesowy nie dotrzymał słowa, może współpracownik przypisał sobie Twój pomysł, a może przełożony nie stanął za Tobą, gdy tego potrzebowałeś. Co wtedy? Jak odbudować nadwątlone zaufanie bez popadania w dwie skrajności: naiwność („nic się nie stało”) lub zemstę („nigdy więcej nikomu nie zaufam”)?
Trzecia droga: granice bez murów
Między ślepą ufnością a całkowitą izolacją istnieje trzecia droga – stawianie granic bez budowania murów. Badania Mayera i jego zespołu z 1995 roku pokazują, że odbudowanie zaufania wymaga zarówno granic, jak i otwartości. Granice chronią nas przed dalszym zranieniem, a otwartość daje szansę na uzdrowienie relacji.
Wyobraź sobie, że zaufanie to jak most między dwoma brzegami. Gdy most zostaje uszkodzony, masz trzy opcje: możesz próbować przejść po nim tak, jakby nic się nie stało (naiwność), możesz go całkowicie zburzyć (zemsta), lub możesz go naprawić, jednocześnie budując tymczasową przeprawę w bezpieczniejszym miejscu (mądre granice).
Lekcja, nie wyrok
Fisher i Ury w swoim badaniu z 1981 roku zasugerowali fascynującą perspektywę: traktowanie zdrady jako lekcji, a nie wyroku na całe życie, znacząco poprawia odporność psychiczną. Kiedy postrzegamy bolesne doświadczenia jako źródło wiedzy, a nie dowód na złośliwość świata, jesteśmy w stanie szybciej się podnieść i mądrzej działać w przyszłości.
Często słyszę: „Już nigdy nikomu nie zaufam”. Ale czy to nie jak zamknięcie wszystkich drzwi, bo jedno się zatrzasnęło? To jak powiedzenie: „Raz się sparzyłem gorącą herbatą, więc już nigdy nic nie wypiję”. Odsunięcie się od osoby, która zdradziła, to nie izolacja od świata. To mądra ochrona siebie przy zachowaniu zdolności do zaufania innym.
Równowaga między ostrożnością a otwartością
Daniel Goleman, twórca koncepcji inteligencji emocjonalnej, w swoich badaniach z 1998 roku podkreślał, że utrzymanie równowagi między ostrożnością a otwartością prowadzi do zdrowszych relacji. Zbyt duża ostrożność i stajemy się cyniczni, odcięci od innych. Zbyt duża otwartość i narażamy się na ciągłe zranienia.
Jak znaleźć tę równowagę? Dla mnie pomocny jest model „otwartego serca, czujnego umysłu”. Pozostaję otwarty na nowe relacje i doświadczenia, jednocześnie będąc świadomym potencjalnych zagrożeń. Nie zakładam złych intencji, ale nie ignoruję też sygnałów ostrzegawczych.
Ludzie są z gruntu dobrzy
Dodatkowo: Ludzie są z gruntu dobrzy i ich złe zachowanie jest czymś spowodowane. Dobrze mi robi zrozumienie osoby, a potem ograniczenie do niej zaufania. Całkowita separacja nie pozwoliłaby mi się uczyć.
Ta perspektywa pozwala mi zachować wiarę w ludzkość, nawet gdy konkretna osoba mnie zawiedzie. Oddzielam konkretną osobę od całej ludzkości – jedna zdrada nie definiuje wszystkich. Zaufanie to umiejętność – możesz ją rozwinąć i udoskonalić. Wybierz świadomą otwartość zamiast ślepej ufności lub totalnej izolacji.
Praktyczne strategie odbudowy zaufania
Jak w praktyce odbudować zaufanie po trudnych doświadczeniach? Oto kilka sprawdzonych strategii:
Precyzyjnie nazwij, co się stało – zamiast ogólników („zawsze mnie zawodzisz”), nazwij konkretne zachowanie, które naruszyło zaufanie.
Wyraź swoje uczucia bez oskarżeń – „Poczułem się zdradzony, gdy…” zamiast „Zdradziłeś mnie, gdy…”.
Ustal jasne oczekiwania na przyszłość – czego potrzebujesz, by zacząć odbudowywać zaufanie?
Zacznij od małych kroków – odbudowa zaufania to proces, który zaczyna się od drobnych, ale konsekwentnych działań.
Doceniaj postęp – zauważaj i doceniaj każdy krok w dobrą stronę.
Moja zdolność do zaufania to zbyt cenny dar, by pozwolić jednemu człowiekowi ją odebrać. Dlatego nawet po bolesnych doświadczeniach, świadomie wybieram zaufanie – mądrzejsze, bardziej świadome, ale wciąż otwarte na piękno i potencjał relacji międzyludzkich.
Pytanie pobudzające: Jak udało ci się zachować zdrową równowagę między ostrożnością a otwartością po trudnych doświadczeniach?
Myśl #5: Zaufanie to nie słabość – to supermoc, która odmienia życie
Supermoce są super, bo dają moc i są super. Jest tylko jeden problem: To straszne, niebezpieczne, trudne i nienaturalne, tak ufać… tak się przynajmniej wydaje.
Stephen M.R. Covey w swojej książce z 2006 roku nazwał zaufanie „supermocą, która odblokowuje kreatywność i współpracę”. Czy to przesada? Moje doświadczenie mówi, że nie. Zaufanie naprawdę ma transformacyjną moc – zarówno w życiu osobistym, jak i zawodowym.
Paradoks kontroli i energii
Im bardziej się bronimy przed zranieniem, tym więcej energii tracimy na kontrolę. To fascynujący paradoks: próbując zabezpieczyć się przed wszystkimi możliwymi zagrożeniami, wyczerpujemy zasoby psychiczne, które mogłyby być spożytkowane na rozwój i kreatywność.
Brené Brown w swoich badaniach z 2012 roku wykazała, że odpuszczenie kontroli zmniejsza stres i zwiększa jasność umysłu. Gdy przestajemy obsesyjnie monitorować każdy aspekt naszego życia i pracy, uwalniamy ogromne pokłady energii. To jak przestawienie samochodu z hamulca na gaz – nagle możesz ruszyć do przodu zamiast walczyć o utrzymanie pozycji.
Zaufanie jako świadomy wybór
Schoorman i jego zespół w badaniach z 2007 roku podkreślali, że zaufanie to świadomy wybór, a nie naiwność. To kluczowa różnica – naiwność ignoruje ryzyko, podczas gdy świadome zaufanie rozpoznaje je, ale decyduje się działać pomimo niego.
Kiedy ostatnio zaufałeś komuś całkowicie i pozwoliłeś sobie na autentyczność? Jak często powstrzymujesz się przed zaufaniem, bo boisz się rozczarowania? To pytania, które regularnie zadaję sobie i innym. Odpowiedzi często pokazują, jak wiele tracimy z powodu strachu przed zranieniem.
Praktyczne zastosowanie: zaufanie w codziennym życiu
Jak to bardzo prosto działa: Zaufanie uwalnia umysł od ciągłego kalkulowania ryzyka. Gdy przestajemy się bać, zaczynamy tworzyć. W praktyce oznacza to:
Delegowanie bez mikromanagementu – przekaż zadanie i zaufaj, że zostanie wykonane dobrze.
Dzielenie się wrażliwymi informacjami – otwartość buduje wzajemne zaufanie.
Przyznawanie się do niewiedzy – paradoksalnie, pokazanie własnych ograniczeń zwiększa wiarygodność.
Dawanie drugiej szansy – rozczarowania są częścią procesu, traktuj je jako lekcje, nie porażki.
Okazywanie zaufania publicznie – wyrażaj zaufanie do innych w obecności zespołu.
Spokój umysłu zamiast iluzji kontroli
Jedną z największych korzyści z wyboru zaufania jest spokój umysłu. Iluzja kontroli jest dokładnie tym – iluzją. Nigdy nie możemy kontrolować wszystkiego. Możemy jednak wybrać, na czym skupiamy naszą uwagę i energię.
Czy wolisz spędzić swoje ograniczone zasoby na budowanie murów, czy na tworzenie mostów? Na zabezpieczanie się przed potencjalną zdradą, czy na budowanie wartościowych relacji? Na kontrolowanie innych, czy na wspieranie ich rozwoju?
Życie jest zbyt krótkie, byśmy spędzali je za murem nieufności. Bycie otwartym na ludzi szybko odkrywa, że większość z nich zasługuje na Twoje zaufanie.
Pytanie pobudzające: Jaką supermoc odkryłeś, gdy odważyłeś się zaufać w sytuacji, która wydawała się ryzykowna?
Czy kiedykolwiek widziałeś zespół Scrumowy, który z dumą prezentuje swoją tablicę Kanban z dziesiątkami kolumn i karteczkami wędrującymi od osoby do osoby? Ja widziałem. I za każdym razem czuję, jakbym obserwował powolną katastrofę – coś, co nazywam „Kanbanosis Acute”. To jak oglądanie kogoś, kto próbuje jeździć rowerem, jednocześnie grając na akordeonie – teoretycznie możliwe, ale po co się tak męczyć?
Tech Lead: „Obawiam się, że masz Kanbanosis Acute – ostrą odmianę kanbanozy.” Junior Dev: „Czy to poważne?” Tech Lead: „Zacząłeś organizować swoje testy jednostkowe, zamówienia kawy i emocje w kolumny Do Zrobienia, W Trakcie i Zrobione.”
Łączenie Kanbana ze Scrumem to jeden z tych pomysłów, które na pierwszy rzut oka wydają się sensowne. W końcu oba podejścia należą do rodziny Agile, prawda? Problem w tym, że często prowadzi to do więcej zamieszania niż korzyści, a w skrajnych przypadkach może być jednym z powodów upadku zespołów Scrumowych i odwrotu od Agile w organizacjach.
Dlaczego Kanban i Scrum to toksyczne małżeństwo?
Scrum ze swojego założenia został stworzony do dostarczania wartości przy rozwiązywaniu skomplikowanych i złożonych problemów. Kanban na odwrót – do prostych i powtarzalnych zadań.
Sprint vs Flow – fundamentalny konflikt
Scrum opiera się na sprintach, które z założenia zaczynają się „na czysto” (żadna praca nie jest w toku) i kończą się „na czysto” (wszystko zaplanowane jest wykonane). To jak przygotowywanie posiłków na cały tydzień w niedzielę – czysta lodówka na początku, pełna pojemników z jedzeniem na koniec.
Tymczasem Kanban to ciągły przepływ, gdzie zadania płyną przez system jak woda przez rurę. Kiedy próbujemy wtłoczyć flow Kanbana w ramy sprintów, tracimy główną zaletę Kanbana – możliwość mierzenia stałości przepływu. To jak próba mierzenia przepływu rzeki, ale tylko w określonych tygodniach roku – dane będą niekompletne i mało użyteczne.
Stabilizacja flow kosztem inspekcji i adaptacji
Chęć ustabilizowania przepływu w Kanbanie często prowadzi zespoły do wydłużania sprintów. „Hej, może zróbmy trzytygodniowe sprinty zamiast dwutygodniowych, żeby lepiej zarządzać flow?” – słyszałem to wielokrotnie. Problem w tym, że dłuższe sprinty oznaczają rzadsze okazje do inspekcji i adaptacji – fundamentalnych elementów Scruma.
To jak rzadsze wizyty u lekarza – możesz się czuć lepiej, bo rzadziej słyszysz złe wieści, ale nie oznacza to, że jesteś zdrowszy.
Zespół jako jednostka vs indywidualne kolumny
W Scrumie zespół powinien być traktowany jako jedna osoba ze wspólną odpowiedzialnością. Wszyscy razem wygrywają lub przegrywają. Tymczasem Kanban, szczególnie w tradycyjnym wydaniu, zachęca do tworzenia kolumn odpowiadających różnym etapom pracy, często przypisanym do konkretnych osób lub ról.
„Analiza”, „Rozwój”, „Testy”, „Wdrożenie” – każda kolumna to potencjalne silos, a zadania są przekazywane między nimi jak gorący kartofel. Handover pracy w kontekście jednego zespołu po prostu nie ma sensu – to jak podawanie sobie piłki między lewą a prawą ręką.
Specjalizacja vs cross-funkcjonalność
Budowanie kolumn i przypisywanie do nich osób utrudnia współdziałanie całego zespołu. Gdy mamy kolumnę „Testy” przypisaną do testerów, programiści naturalnie skupiają się tylko na kolumnie „Rozwój”. To prowadzi do specjalizacji, która jest przeciwieństwem cross-funkcjonalności, do której dążymy w Scrumie.
To jak mieć w domu osobę odpowiedzialną wyłącznie za odkurzanie, a inną tylko za mycie naczyń. Może i są ekspertami w swoich wąskich dziedzinach, ale co się stanie, gdy jedna z nich zachoruje?
Najczęstsze błędy przy stosowaniu Kanbana w Scrumie:
Zbyt wiele kolumn
Najprostszy i najczęstszy błąd: tworzenie zbyt wielu kolumn. Widziałem tablice z kolumnami takimi jak „Do zrobienia”, „Analiza”, „Projektowanie”, „Rozwój”, „Code Review”, „Testy”, „Dokumentacja”, „Wdrożenie”, „Zrobione”. To nie tablica Kanban, to mapa metra!
W większości przypadków wystarczą trzy kolumny: „Do zrobienia”, „W trakcie”, „Zrobione”. Wszystko ponad to często wprowadza sztuczne podziały i zachęca do przekazywania pracy zamiast współpracy.
Obsesja na punkcie mierników przepływu
Kanban oferuje wiele mierników: lead time, cycle time, throughput… Zespoły często skupiają się na tych miernikach kosztem tego, co naprawdę ważne – dostarczania wartości[3].
„Nasz cycle time spadł o 15%!” – świetnie, ale czy klienci są zadowoleni z produktu? Czy rozwiązujemy właściwe problemy? Mierniki są jak termometr – przydatne do diagnozy, ale same w sobie nie leczą choroby.
Push zamiast pull
W prawdziwym Kanbanie zadania są „ciągnięte” (pull) przez system, a nie „pchane” (push). Jednak w praktyce często widzę, jak programiści kończą swoje zadanie i natychmiast przesuwają je do kolumny „Testy”, nawet jeśli testerzy są już przeciążeni pracą.
To jak wrzucanie kolejnych naczyń do zlewu, mimo że jest już pełny – zamiast pomóc w zmywaniu. Prawdziwy Kanban wymaga dyscypliny i szacunku dla limitów pracy w toku (WIP), które często są ignorowane.
Kiedy nie stosować Kanbana
Zadania skomplikowane
Kanban świetnie sprawdza się w przewidywalnych, powtarzalnych procesach. Pisanie oprogramowania rzadko takie jest. Każde zadanie może napotkać nieoczekiwane problemy, wymagać głębszego zrozumienia lub zmiany podejścia w trakcie realizacji.
To jak stosowanie przepisu kulinarnego do eksperymentowania z nowymi potrawami – możesz mieć listę składników i kroków, ale prawdziwa magia dzieje się, gdy odchodzisz od przepisu i improwizujesz.
Zadania wymagające współpracy wielu specjalności
Jeśli twój zespół nie składa się wyłącznie z „pełnych stacków” (100% fullstack-QA-SEC-OPS), Kanban może prowadzić do silosów i opóźnień w handoverach. Współczesne wytwarzanie oprogramowania wymaga ścisłej współpracy między różnymi specjalnościami, a nie sekwencyjnego przekazywania pracy.
Realizacja celów zamiast zadań
User Stories, Epics i Features to nie są zadania, to cele użytkownika. Kanban jest świetny do zarządzania zadaniami, ale nie celami. Kiedy próbujemy wtłoczyć cele użytkownika w ramy Kanbana, często tracimy z oczu prawdziwy cel – dostarczanie wartości.
Kiedy warto stosować Kanban
Powtarzalne zadania
Kanban narodził się w fabrykach Toyoty, gdzie procesy są powtarzalne i przewidywalne. Świetnie sprawdza się w obsłudze serwisowej, produkcji przemysłowej czy innych scenariuszach, gdzie zadania są podobne i dobrze zrozumiane.
Proste zadania w dużej ilości
Jeśli masz do wykonania setki prostych, podobnych zadań (jak obracanie monety czy składanie pudełek 😉 ), Kanban może pomóc w zarządzaniu przepływem i identyfikacji wąskich gardeł.
Zadania wykonywalne przez każdego członka zespołu
Kanban działa najlepiej, gdy każde zadanie może być podjęte przez dowolną osobę w zespole. W przeciwnym razie powstają wąskie gardła i zadania czekają na konkretne osoby, co niweluje korzyści z płynnego przepływu.
Suma zgodności z powyższymi kryteriami
Kanban warto stosować tylko wtedy, gdy 100% wykonywanych zadań spełnia powyższe kryteria. W przeciwnym razie ryzykujemy stworzenie systemu, który działa dobrze dla części pracy, ale utrudnia realizację pozostałej.
Dodatkowe powody, by unikać Kanbana w Scrumie
Rozmycie odpowiedzialności zespołowej
Kanban może prowadzić do myślenia „to nie moje zadanie”, gdzie każdy odpowiada tylko za swoją kolumnę. To podważa fundamentalną zasadę Scruma o wspólnej odpowiedzialności zespołu za dostarczenie wartości.
Utrata przejrzystości sprintów
Sprinty w Scrumie dają jasną ramę czasową i zakres pracy, co ułatwia planowanie i zarządzanie oczekiwaniami. Dbanie o flow powoduje przenoszenie pomiędzy sprintami i nakładanie koncowych etapów na początek kolejnego sprintu. To z kolei rozwala przewidywalność zespołu i może powoli degradować zaufanie biznesu do developmentu.
Jak uniknąć Kanbanosis Acute?
Najlepiej… nie wprowadzaj Kanbana. a jeśli już musisz używać elementów Kanbana w Scrumie, oto kilka wskazówek:
Utrzymuj prostotę tablicy – trzy kolumny to często wszystko, czego potrzebujesz.
Zachowaj współpracę zespołową – unikaj przypisywania kolumn do konkretnych osób.
Szanuj limity WIP – to fundamentalna zasada Kanbana, bez której traci on sens.
Nie rezygnuj z ceremonii Scruma – Sprint Planning, Daily Scrum, Sprint Review i Sprint Retrospective są nadal kluczowe.
Pamiętaj o celu – dostarczanie wartości jest ważniejsze niż piękne wykresy przepływu.
Podsumowanie
Jestem wielkim fanem Kanbana – naprawdę! To potężne narzędzie, które zrewolucjonizowało produkcję przemysłową i może być niezwykle skuteczne w odpowiednich kontekstach. Jednak przy wytwarzaniu oprogramowania w podejściu Agile, gdzie wymagana jest współpraca, a nie handover, Kanban często wprowadza więcej problemów niż rozwiązań.
Zamiast ślepo łączyć Kanban ze Scrumem, zastanów się, co naprawdę chcesz osiągnąć. Jeśli twoim celem jest lepsza wizualizacja pracy, może wystarczy prosta tablica z trzema kolumnami. Jeśli chcesz poprawić przepływ, może warto skupić się na zmniejszeniu wielkości User Stories i lepszej współpracy zespołowej.
Pamiętaj, że metodyki są narzędziami, a nie religią. Używaj ich mądrze, dostosowując do swoich potrzeb, ale nie zapominaj o fundamentalnych zasadach, które stoją za nimi. W przypadku Scruma są to przejrzystość, inspekcja i adaptacja. W przypadku Kanbana – wizualizacja, ograniczenie pracy w toku i zarządzanie przepływem.
I jeśli kiedykolwiek zauważysz u siebie lub swojego zespołu objawy Kanbanosis Acute – nadmierne mnożenie kolumn, obsesję na punkcie przepływu kosztem wartości czy przekazywanie zadań zamiast współpracy – wiedz, że jest na to lekarstwo. Czasami najlepszym rozwiązaniem jest powrót do podstaw i przypomnienie sobie, po co właściwie stosujemy te metodyki.
Bo ostatecznie nie chodzi o to, czy używasz Kanbana, Scruma czy jakiejkolwiek innej metodyki. Chodzi o to, czy skutecznie dostarczasz wartość swoim klientom. A to wymaga współpracy, adaptacji i ciągłego uczenia się – niezależnie od tego, jak nazywasz swój proces.
Rozmawiałem z koleżanką na temat facylitacji spotkania, które ma organizować. Była to taka typowa „burza mózgów na temat burzy mózgów”, czyli odbicie myśli, żeby sprawdzić, czy poprawnie myślimy. I wiecie co? Odkryliśmy, że ten przypadek może dosięgnąć ciekawe zagrożenie nazywane przeze mnie nad-facylitacją. Brzmi trochę jak jakieś przewinienie drogowe, prawda? „Za nadmierną facylitację grozi mandat w wysokości jednego nieudanego spotkania i dwóch punktów karnych w reputacji zawodowej.”
Ale żarty na bok. Nad-facylitacja to sytuacja, gdy facylitator tak bardzo zakochuje się w swoim starannie przygotowanym planie, narzędziach i strukturze, że staje się ślepy i głuchy na faktyczne potrzeby grupy. Dochodzi wtedy do jednej z dwóch wpadek:
albo facylitator zupełnie przegapia, że uczestnicy chcieliby pójść inną drogą i uparcie prze do przodu ze swoim planem (jak kierowca GPS-u, który każe skręcać w prawo, mimo że droga jest zamknięta),
albo orientuje się, że jego struktura nie działa, ale nie ma w zanadrzu planu B, C czy nawet Z (jak kucharz, który umie gotować tylko jedno danie i wpada w panikę, gdy skończą się składniki).
W obu przypadkach wynik jest podobny – spotkanie nie osiąga swojego celu, uczestnicy czują się sfrustrowani, a facylitator wygląda jak człowiek, który przyszedł na bal przebierańców w garniturze.
Uważność – supermoce facylitatora
Jak więc temu zapobiec? Jednym z kluczowych elementów jest stan uważności, czyli, ujmując rzecz prosto, bycie w pełni obecnym „tu i teraz” podczas facylitacji spotkania. Nie chodzi tu o jakieś ezoteryczne praktyki (choć medytacja faktycznie pomaga), ale o zwykłą (a właściwie niezwykłą) zdolność do zauważania, co rzeczywiście dzieje się w pokoju.
Uważny facylitator to taki, który:
Obserwuje język ciała uczestników (czy przysypiają, czy pochylają się do przodu z zainteresowaniem)
Wyłapuje zmianę energii w grupie (nagłe ożywienie lub spadek zaangażowania)
Zauważa, gdy dyskusja spontanicznie skręca w innym kierunku niż zaplanowany
Rozpoznaje momenty „aha!” i potrafi je wykorzystać
Wyczuwa napięcia i konflikty, zanim staną się one widoczne dla wszystkich
Bycie uważnym to jak posiadanie radaru, który nieustannie skanuje przestrzeń spotkania, wyłapując sygnały, które mówią: „Hej, tu dzieje się coś ważnego!” lub „Uwaga, zbliżamy się do ściany, trzeba zmienić kurs!”
W praktyce oznacza to, że musisz mieć podzielną uwagę. Część mózgu śledzi proces i czas, a część jest całkowicie zanurzona w tym, co mówią i robią uczestnicy. To trochę jak jazda samochodem i jednoczesne prowadzenie ciekawej rozmowy – można to zrobić, ale wymaga to praktyki.
Aktywne słuchanie – więcej niż dwoje uszu
Siostrzaną umiejętnością uważności jest aktywne słuchanie. I nie, nie mówię tu o potakiwaniu głową i wtrącaniu „mhm” co kilka sekund, choć to też jest element tej układanki.
Aktywne słuchanie w kontekście facylitacji to:
Słuchanie nie tylko słów, ale też emocji i intencji, które za nimi stoją
Wychwytywanie tematów i wątków, które pojawiają się w wypowiedziach różnych osób
Rozumienie, co naprawdę jest ważne dla uczestników (często nie jest to to samo, co zostało zapisane w agendzie)
Zadawanie pytań, które naprawdę zgłębiają temat, zamiast prowadzić do z góry założonych odpowiedzi
Parafrazowanie i podsumowywanie, aby upewnić się, że dobrze zrozumiałeś intencje i potrzeby grupy
Dobry facylitator słucha tak, jakby od tego zależało jego życie – bo faktycznie zależy od tego życie spotkania!
Jednym z kluczowych sygnałów, że uczestnicy potrzebują innego przebiegu spotkania, jest moment, gdy dyskusja zaczyna krążyć wokół tematu, który nie był planowany, ale wyraźnie budzi zainteresowanie i energię grupy. Albo gdy przygotowane ćwiczenie spotyka się z oporem lub brakiem zaangażowania. W takich chwilach trzeba umieć powiedzieć: „Widzę, że ten temat jest dla was ważny. Czy chcecie, żebyśmy poświęcili mu więcej czasu, nawet kosztem innych punktów agendy?”
Arsenał facylitatora, czyli dlaczego jeden młotek to za mało
Dochodzimy do kluczowego punktu – konieczności posiadania wielu narzędzi, technik i podejść w swoim facylitacyjnym repertuarze. Wyobraź sobie, że jesteś elektrykiem, który przychodzi naprawić instalację mając przy sobie tylko śrubokręt. Albo lekarzem, który na każdą dolegliwość przepisuje ten sam lek. Tak właśnie wygląda facylitator, który zna tylko jedną metodę prowadzenia spotkań.
W moim „plecaku facylitatora” zawsze noszę kilka alternatywnych scenariuszy i narzędzi do każdego spotkania. Jeśli planowana burza mózgów nie wypala, mogę szybko przejść do techniki 6 kapeluszy myślowych. Jeśli dyskusja w całej grupie nie przynosi rezultatów, dzielę uczestników na mniejsze zespoły. Jeśli cyfrowe narzędzia zawodzą, mam zawsze pod ręką analogowe zamienniki.
Budowanie takiego arsenału to proces, który trwa latami, ale warto zacząć od kilku solidnych, uniwersalnych narzędzi, które sprawdzają się w różnych kontekstach. Z czasem będziesz dodawać kolejne, bardziej wyspecjalizowane, dostosowane do konkretnych sytuacji i grup.
Doświadczenie – nie da się tego ściągnąć z internetu
Wiedzieć, kiedy zmienić kurs, to jedna rzecz. Wiedzieć, NA CO zmienić kurs, to zupełnie inna sprawa. I tu właśnie wkracza doświadczenie.
Doświadczony facylitator widział już dziesiątki, jeśli nie setki spotkań. Widział co działa, a co nie. Widział, jak grupy reagują na różne techniki i podejścia. Widział, jak ratować spotkanie, które zmierza ku katastrofie, i jak wykorzystać nieoczekiwane możliwości, które pojawiają się w trakcie.
Ten rodzaj wiedzy nie da się łatwo przekazać w artykule czy książce – musisz go zdobyć w praktyce. Ale mogę ci powiedzieć, że każde prowadzone przeze mnie spotkanie, nawet to, które poszło nie tak, jak planowałem, było cenną lekcją, która wzbogaciła mój warsztat.
Improwizacja – czyli jazz w świecie facylitacji
Na koniec dochodzimy do umiejętności, która łączy wszystkie poprzednie – improwizacji. Doświadczeni facylitatorzy to wirtuozi improwizacji, którzy potrafią płynnie dostosowywać się do zmieniających się warunków, wykorzystując swój arsenał narzędzi i technik.
Improwizacja w facylitacji to nie to samo, co brak przygotowania. Wręcz przeciwnie – to właśnie solidne przygotowanie i bogaty repertuar pozwalają na swobodną improwizację. Tak jak jazzowy muzyk musi znać teorię muzyki i opanować instrument, aby móc improwizować, tak facylitator musi doskonale rozumieć procesy grupowe i mieć opanowane różne techniki, aby móc płynnie je modyfikować i dostosowywać do potrzeb grupy.
W praktyce improwizacja może oznaczać:
Zmianę kolejności punktów agendy, gdy grupa ma więcej energii do trudnego tematu niż zakładano
Modyfikację zaplanowanego ćwiczenia, gdy okazuje się, że nie pasuje ono do aktualnego składu grupy
Całkowitą zmianę podejścia, gdy pierwotny plan nie przynosi oczekiwanych rezultatów
Podchwycenie i rozwinięcie nieplanowanego wątku, który może prowadzić do wartościowych odkryć.
Podsumowanie – elastyczna doskonałość
Podsumowując, dobry facylitator to nie ten, który idealnie trzyma się planu, ale ten, który doskonale osiąga cel spotkania – nawet, jeśli droga do tego celu okazuje się zupełnie inna niż zakładał.
Uważność i aktywne słuchanie pozwalają mu rozpoznać, kiedy należy zmienić kurs. Bogaty arsenał narzędzi i technik daje mu możliwość wyboru alternatywnej drogi. Doświadczenie pomaga mu wybrać najlepszą opcję. A umiejętność improwizacji pozwala mu płynnie przeprowadzić grupę przez tę nieplanowaną podróż[7].
Czy to trudne? Owszem. Czy to możliwe do nauczenia? Absolutnie! W końcu nikt nie rodzi się facylitatorem – to rzemiosło, którego można się nauczyć i które można ciągle doskonalić.
Jeśli więc jesteś gotowy, by wzbogacić swój warsztat facylitatora o elementy uważności, elastyczności i improwizacji, lub szukasz eksperta, który pomoże twojej organizacji w prowadzeniu skutecznych spotkań i warsztatów – daj znać. Z przyjemnością podzielę się swoim doświadczeniem i pomogę ci osiągnąć mistrzostwo w facylitacji bez sztywnego kołnierzyka.
