Technical Leadership Od Eksperta Do Lidera Mariusz Sieraczkiewicz Helion.pl

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.
com
Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości
lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione.
Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie
książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie
praw autorskich niniejszej publikacji.
Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi

bądź towarowymi ich właścicieli.
Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte

w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej
odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne
naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION
nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe
z wykorzystania informacji zawartych w książce.
Redaktor prowadzący: Magdalena Dragon-Philipczyk

Projekt okładki: Jan Paluch
Ilustracje: Maria Pankowska
Wydawnictwo HELION
ul. Kościuszki 1c, 44-100 GLIWICE
tel. 32 231 22 19, 32 230 98 63
e-mail: onepress@onepress.pl
WWW: http://onepress.pl (księgarnia internetowa, katalog książek)
Drogi Czytelniku!
Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres
http://onepress.pl/user/opinie/techle_ebook
Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.
ISBN: 978-83-283-2562-3
Copyright © Mariusz Sieraczkiewicz 2016
 Poleć książkę na Facebook.com  Księgarnia internetowa
 Kup w wersji papierowej  Lubię to! » Nasza społeczność
 Oceń książkę
helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com

48eeaddb8dc8638900bd3169e19eae86
4
Najbliższym — żonie Kamili, dzieciom Poli i Filipowi oraz rodzicom

4
4
SPIS TREŚCI
Od autora .................................................................................................... 9
Rozdział 1. Rola lidera technicznego ......................................................... 11

Typowa ścieżka kariery w IT ................................................................................ 12
Definicja lidera technicznego ............................................................................... 13
Model Technical Leadership ................................................................................ 14
Wizja ........................................................................................................................ 16
Stereotyp lidera ....................................................................................................... 17
Typy przywództwa ................................................................................................. 18
Grzechy główne liderów technicznych ............................................................... 20
Podsumowanie ....................................................................................................... 23
Rozdział 2. Ekspert a lider ......................................................................... 25

Między ekspertem a liderem ................................................................................. 25
Autorytet wiedzy i postawy .................................................................................. 28
Jak pogodzić prace techniczne i nietechniczne? ................................................ 29
Podsumowanie ....................................................................................................... 35
Rozdział 3. Od wizji do działania ............................................................... 37

Strategia Disneya .................................................................................................... 37
Definiowanie wizji środowiska z użyciem strategii Disneya ............................ 39
Przykłady ................................................................................................................. 40
Podsumowanie ....................................................................................................... 42

4
6 Technical Leadership. Od eksperta do lidera
Rozdział 4. Motywacja ............................................................................... 43

Teoria X i Y ............................................................................................................. 43
Co mnie motywuje? ............................................................................................... 44
Czynniki motywacyjne .......................................................................................... 45
Kryteria .................................................................................................................... 47
Kwantyfikatory ilościowe ...................................................................................... 47
Profil motywacyjny ................................................................................................ 49
Jak to wpleść w codzienne życie zespołu? ........................................................... 51
Analiza motywatorów ........................................................................................... 51
Skupienie ................................................................................................................. 52
Codziennik .............................................................................................................. 53
Wysoka energia ...................................................................................................... 55
Czynniki motywacyjne i higieniczne ................................................................... 56
Co motywuje programistów? ............................................................................... 57
Złam wszelkie zasady ............................................................................................. 58
Drive ........................................................................................................................ 59
Elementy angażującego środowiska .................................................................... 61
Slack ......................................................................................................................... 65
Podsumowanie ....................................................................................................... 65
Rozdział 5. Praca z zespołem ..................................................................... 69

Model Cynefin ........................................................................................................ 69
Oczekiwania i reguły .............................................................................................. 71
Fazy rozwoju grupy ................................................................................................ 72
Przywództwo sytuacyjne ....................................................................................... 74
Dysfunkcje zespołu ................................................................................................ 76
Podsumowanie ....................................................................................................... 78
Rozdział 6. Proces i inżynieria .................................................................... 81

Podział odpowiedzialności ................................................................................... 81
Wizja i cele projektu .............................................................................................. 82
Wymagania i decyzje biznesowe .......................................................................... 83
Właściciel procesu .................................................................................................. 83
Proces ....................................................................................................................... 84
Retrospekcje ............................................................................................................ 85
Codzienne spotkania ............................................................................................. 87
Oznaczanie problemów ......................................................................................... 87
Kryteria jakościowe ................................................................................................ 88
Podsumowanie ....................................................................................................... 89

4
Spis treści 7
Rozdział 7. Zarządzanie wiedzą ................................................................. 91

Wprowadzanie osoby do zespołu ........................................................................ 91
Spójne zasady .......................................................................................................... 92
Wymiana doświadczeń w zespołach ................................................................... 93
Przeglądy kodu ....................................................................................................... 93
Aktualizacja wiedzy o systemie ............................................................................ 94
Ciągły rozwój .......................................................................................................... 95
Mantra architektoniczna ....................................................................................... 97
Co to jest mantra architektoniczna? .................................................................... 97
Podsumowanie .....................................................................................................102
Rozdział 8. Relacja z biznesem ................................................................ 105

Antywzorce współpracy ......................................................................................105
Dobre praktyki ......................................................................................................107
Budowanie sieci wsparcia ...................................................................................108
Ustalanie zasad współpracy ................................................................................109
Indeks zadowolenia ..............................................................................................111
Mapa relacji ...........................................................................................................111
Analiza potrzeb .....................................................................................................113
Podsumowanie .....................................................................................................115
Rozdział 9. Informacja zwrotna ............................................................... 117

Praktyki związane z informacją zwrotną ..........................................................117
Dlaczego nie udzielamy informacji zwrotnej
i jakie są tego konsekwencje? ...........................................................................118
Korzyści .................................................................................................................118
Podstawowy błąd ..................................................................................................118
Feedback i feedforward .......................................................................................119
Wskazówki co do udzielania informacji zwrotnej ...........................................120
Kanapka informacji zwrotnej .............................................................................121
Zespołowa informacja zwrotna ..........................................................................121
Trudna informacja zwrotna ................................................................................122
Podsumowanie .....................................................................................................122
Rozdział 10. Trudne rozmowy ................................................................. 125

Skąd się biorą emocje? .........................................................................................125
Co niszczy kontakt? .............................................................................................127
Elementy klarownego komunikatu ...................................................................129
Druga pozycja .......................................................................................................133
Podsumowanie .....................................................................................................135

4
Rozdział 11. Konflikty i ich technikalia .................................................... 137

Pewna historia ......................................................................................................137
Prosty przykład .....................................................................................................138
Struktura ................................................................................................................140
Przykładowe pytania ............................................................................................140
Algorytm ...............................................................................................................141
Gdzie jeszcze? .......................................................................................................143
Podsumowanie .....................................................................................................143
Rozdział 12. Lider jako coach ................................................................... 145

Dlaczego ludzie nie lubią, gdy udziela się im rad? ...........................................145
Coaching ................................................................................................................146
Moc pytań .............................................................................................................147
Rodzaje i siła pytań ..............................................................................................148
Intencja ..................................................................................................................149
Konkretyzacja .......................................................................................................149
Prowadzenie rozmowy ........................................................................................151
Model problemu ...................................................................................................155
Trening zadawania pytań ....................................................................................159
Podsumowanie .....................................................................................................159
Rozdział 13. Efektywne spotkania ........................................................... 161

Podstawy efektywnych spotkań .........................................................................161
Dlaczego to nie wystarcza? ..................................................................................163
Struktury i ich zastosowanie ...............................................................................164
Gamestorming ......................................................................................................169
Ramy spotkania ....................................................................................................169
Schemat spotkania ...............................................................................................170
Podsumowanie .....................................................................................................171
Rozdział 14. Pytania i odpowiedzi ........................................................... 173
Literatura ................................................................................................. 179

4
OD AUTORA
Niniejsza książka została napisana z myślą o liderach, którzy zaczynają przygodę pracy
z własnym zespołem, niemniej jednak jestem przekonany, że także bardziej doświad-
czeni w tym zakresie czytelnicy znajdą tu wiele przydatnych informacji, które pozwolą
im usystematyzować posiadane umiejętności. Chciałem, aby treść publikacji nie była
zbyt rozbudowana — to raczej ma być esencja informacji oraz źródło przydatnych na-
rzędzi do natychmiastowego zastosowania. Toteż główną zawartością każdego z roz-
działów jest opis różnego rodzaju użytecznych technik przydatnych w pracy z zespołem.
Temat pełnienia funkcji lidera zespołu programistów jest bardzo szeroki i ta książka
z pewnością go nie wyczerpuje. Jestem jednak przekonany, że stanowi dobre wprowa-
dzenie i daje czytelnikowi przegląd zagadnień, które później może bardziej szczegółowo
zgłębić, sięgając do literatury (zestawienie bibliografii zostało podane na końcu publikacji).
Oddawanej do rąk czytelnika książce towarzyszy strona internetowa
http://TechnicalLeadership.pl
na której znajduje się najbardziej aktualny zestaw przedstawianych w tekście narzę-
dzi, artykułów oraz wydarzeń związanych z tematem Technical Leadership.
Ta publikacja powstała we współpracy z wieloma osobami, dzięki którym zyskała swoją
obecną postać. Chciałem podziękować Michałowi Bartyzelowi za inspirację i dyskusje,
bez których prawdopodobnie nie byłoby tej książki. Podziękowania kieruję też do Pawła
Wrzeszcza, Piotra Szymury, Tomasza Żeleznego i Sławomira Ungiera — do osób, które
przeczytały pierwszą wersję tekstu i dołożyły swoją cegiełkę do udoskonalenia treści.
Oczywiście książka nie powstałaby bez wsparcia moich najbliższych — żony oraz
wspaniałych dzieci, którym dedykuję to dzieło.

4
10 Technical leadership. Od eksperta do lidera

4
Rozdział 1.
ROLA LIDERA TECHNICZNEGO
Niedawno się przeprowadzałem. W jednym z pudełek, które pozostało nieotwarte po

wcześniejszej przeprowadzce, znalazłem mały pomarańczowy album z charaktery-
stycznym logo na okładce. Powróciły wszystkie pozytywne uczucia z tamtego okresu.
Otworzyłem album na pierwszej stronie i zacząłem czytać: „Dzięki za ogrom inspiracji
i wzbudzenie pasji do programowania”. Przypomniałem sobie Tomka… Na następnej
stronie znalazłem następujący tekst: „Za każdym razem, kiedy będę miał problem, za-
stanowię się, co Ty zrobiłbyś w tej sytuacji”. To był wpis Mateusza…
Czytałem kolejne wpisy od kolejnych osób. Ten album dostałem na pożegnanie od
swojego pierwszego zespołu, w którym byłem liderem. To była niesamowita przygoda,
chociaż niełatwa.
Liderem zostałem sam na własne życzenie. Pracowałem w firmie specjalizującej się
w doradztwie biznesowym, w której dwuosobowy dział informatyki stanowił jedynie
wsparcie rozbudowanej organizacji. Natomiast z czasem, kiedy w firmie przybywało
rozwiązań informatycznych, stawało się jasne, że dwie osoby nie wystarczą. Wtedy za-
proponowałem mojemu ówczesnemu przełożonemu: „A może stworzyć zespół pro-
gramistyczny, który będzie rozwijał tego typu projekty na dużą skalę?”. Ten, niewiele
się zastanawiając, odpowiedział: „Świetny pomysł!”. Sam się zdziwiłem, że poszło tak
łatwo, i zacząłem się ekscytować wizją pracy profesjonalnego zespołu nad zaawansowa-
nymi rozwiązaniami technicznymi. W ciągu kilku tygodni pozyskaliśmy parę osób do
zespołu i rozpoczęliśmy prace.
Wtedy zaczęły się schody. Okazało się, że nie wszyscy chętnie się godzą na moje
wspaniałe pomysły, że poczynione ustalenia każdy rozumie inaczej, że w rozwiąza-
niach różnych osób brakuje spójności. Miałem poczucie, że marnujemy mnóstwo

4
energii, a ja mam coraz mniej czasu na programowanie. Poza tym doszło mi wiele
nowych obowiązków: spotkania, raportowanie, rozwiązywanie problemów. W pewnym
momencie zacząłem żałować swojej decyzji i zdałem sobie sprawę, że nie byłem goto-
wy do roli lidera. Nie wiedziałem, jak powinienem pełnić tę funkcję. To był trudny czas.
Na szczęście mój przełożony był coachem. Postanowiłem to wykorzystać, by dowie-
dzieć się, na co powinienem zwracać uwagę. I wówczas rozpoczęła się moja podróż
w stawaniu się liderem, pełna problemów i trudnych sytuacji, zwątpień i momentów
ekscytacji, sukcesów i porażek. Zwieńczeniem tej drogi było pożegnanie z moim pierw-
szym zespołem i wpisy w pomarańczowym albumie. Kiedy się żegnałem z moimi pierw-
szymi współpracownikami, już wiedziałem, że było warto.
Sam temat zainspirował mnie do tego stopnia, że zacząłem go zgłębiać, a z czasem
również zająłem się szkoleniami w tym zakresie i pracą z liderami, czego zwieńczeniem
jest niniejsza książka.
Typowa ścieżka kariery w IT

Większość liderów technicznych zaczyna swoją karierę jako eksperci techniczni —
programiści, testerzy, projektanci. Jako juniorzy uwielbiają poznawać nowe narzę-
dzia, biblioteki, rozwiązania, szkielety i pasjami rozwiązywać problemy. Po nabyciu
doświadczenia stają się pełnoprawnymi ekspertami, którzy bardziej pragmatycznie
podchodzą do problemów, a w efekcie zostają seniorami sceptycznie spoglądającymi
na różne nowinki, doświadczenie podpowiada im bowiem, że kolejne narzędzie nie-
wiele zmieni. Aż pewnego dnia ktoś w organizacji stwierdza, że już czas na to, aby
zostali liderami (rysunek 1.1).
Rysunek 1.1. Typowa ścieżka kariery w IT
Dla większości osób etap wejścia w rolę lidera to trudny czas, bo oto ze świata zero-
-jedynkowego wkraczają w obszar, w którym reguły są rozmyte, a zachowania ludzi
nieprzewidywalne. I to jest trudne. Strategie, które się świetnie sprawdzały podczas
rozwiązywania problemów technicznych, teraz w ogóle nie zdają egzaminu. Młodzi
liderzy czują się bezradni, nieprzygotowani do pełnienia nowej funkcji, a ich frustrację
pogłębia poczucie, że z czasem tracą swoje kompetencje techniczne. I zastanawiają
się: „Czy to na pewno jest dla mnie? A może ja się do tego nie nadaję? Czy jest jakaś
inna droga?”. Trudno jest im odnaleźć spełnienie w nowej roli, więc towarzyszy im
ciągła frustracja.

4
Rozdział 1. Rola lidera technicznego 13
Definicja lidera technicznego

Co to znaczy być liderem? Kim jest lider techniczny? Czy trzeba się nim urodzić?
A może można się tego nauczyć? To są pytania, które najczęściej przychodzą nam do
głowy, kiedy zastanawiamy się nad tą rolą.
Problem z definicją lidera technicznego jest taki, że każda organizacja inaczej rozumie
tę rolę. Dla niektórych jest to najbardziej doświadczona osoba techniczna i jej zadaniem
jest rozwiązywanie kluczowych problemów technicznych. W innych organizacjach
jest to lider, którego zadaniem jest doprowadzenie do efektywnego funkcjonowania
zespołu, a w jeszcze innych to osoba, która jest kierownikiem projektu. Najczęściej jed-
nak rola lidera technicznego stanowi kombinację wyżej wymienionych elementów.
Oto kilka przykładowych definicji, które usłyszałem w trakcie pracy z zespołami pro-
gramistycznymi. Te definicje obrazują różnorodność perspektyw postrzegania roli li-
dera w różnych firmach1:
„Lider techniczny to osoba posiadająca odpowiednią wiedzę i kompetencje, których
nie zawaha się użyć, aby pomóc kierownikowi projektu ukończyć projekt wysokiej
jakości od strony technicznej spełniający wymogi biznesu”.
„LIDER = SPRAWCA. Osoba odpowiedzialna za to, żeby rzeczy się działy”.
„Lider techniczny to często osoba od brudnej roboty. Ojciec sukcesów i porażek, gdyż
wymaga tego od niego zarówno zarząd, jak i deweloperzy”.
„Lider techniczny:
 wie, co jest do zrobienia;
 wie, jak to osiągnąć;
 potrafi przekonać innych do realizacji jego wizji”.
„Lider techniczny pomaga, żeby grupa niezależnych osób stała się zespołem”.
„Mentor, człowiek pokazujący kierunek w projekcie innym”.
„Lider techniczny to osoba, która potrafi zdobyć sobie szacunek w zespole za swoją
wiedzę, a jednocześnie potrafi powiedzieć otwarcie, że czegoś nie wie i potrzebuje
pomocy”.
„Lider — osoba, która potrafi pogodzić ze sobą zarządzanie zespołem (umiejętności
miękkie) z wiedzą techniczną. Idealny — programista z wrodzonym genem przy-
wództwa”.
„Lider techniczny — osoba, która zarówno potrafi pokierować pracą zespołu, zorga-
nizować ją bądź pomóc zespołowi zorganizować się samodzielnie i dba o pomyślne
zakończenie projektu, jak i zapewnia zespołowi spokojną, zorganizowaną i rozwija-
jącą pracę”.
1
Wypowiedzi zachowane w formie oryginalnej.

4
Ponieważ w tych definicjach brakuje spójności i nie każda odpowiada w pełni mojemu
rozumieniu roli lidera technicznego, na potrzeby tej książki podam własną definicję.
Zacznę od samego słowa lider. Pochodzi ono od angielskiego słowa lead — prowa-
dzić. Lider powinien prowadzić, więc również istotni są ci, których prowadzi. A jeśli
lider prowadzi, to powinien prowadzić do czegoś. Tym czymś jest wizja — pewne
wyobrażenie docelowego stanu, sytuacji, wyraźny obraz tego, do czego lider chciałby
doprowadzić. Wizja może dotyczyć projektu, produktu i środowiska, w którym pra-
cuje zespół.
Moja historia
Kiedy zostałem liderem, kompletnie nie wiedziałem, co powinienem robić, jednak
miałem wyobrażenie tego, jak miałby funkcjonować mój zespół. Oto jak sobie to wy-
obrażałem: widziałem siebie jako osobę pewną siebie, która pomaga członkom zespołu
rozwiązywać ich problemy. Myślałem, że będziemy dzielić się wiedzą, przeprowa-
dzać wewnętrzne szkolenia, że ustalimy zasady odnośnie do stylu programistycznego
i dopilnujemy tego za pomocą specjalnych narzędzi. Chciałem, żebyśmy projektowali
rozwiązania zgodnie ze sztuką inżynieryjną, używając wzorców projektowych i archi-
tektonicznych. Planowałem, że będziemy pracowali według zasad określonych przez
Extreme Programming. Członkowie zespołu mieli zwyczajnie się lubić i być dla siebie
nie tylko znajomymi w pracy, ale i po pracy. Wyobrażałem sobie, że kiedy trzeba,
będziemy potrafili się zmobilizować, ale również że będzie miejsce na żarty i luźną
atmosferę.
Nie była to sformalizowana wizja, a jedynie klarowne wyobrażenie. Poniżej znajdziesz
podpowiedź, jak można to zrobić w bardziej systematyczny sposób.
Model Technical Leadership

W swojej praktyce odnajduję poniższy model jako niezwykle przydatny w budowaniu
wyobrażenia na temat tego, do czego lider chce doprowadzić.
Na rysunku 1.2 znajdziesz model Technical Leadership — obrazuje on kluczowe ob-
szary, które leżą w kręgu zainteresowań lidera technicznego. Te obszary nazywa się
środowiskiem funkcjonowania zespołu. W tym kontekście można określić, że lider to
osoba mająca stworzyć środowisko sprzyjające efektywnemu realizowaniu pro-
jektów, w którym to środowisku ludzie chcą pracować (rysunek 1.3)2.
2
Jest to parafraza definicji lidera przedstawionej przez Roberta Diltsa w książce Przywództwo z wizją.

4
Rysunek 1.2. Model Technical Leadership
Rysunek 1.3. Metafora definicji lidera
A co z aspektem technicznym? Co czyni lidera technicznego wyjątkowym? Tę rolę

wyróżnia przede wszystkim kontekst, czyli te aspekty, które są typowe dla środowiska
technicznego: zespół, inżynieria, procesy. Do szczególnych wyznaczników można
zaliczyć to, że:
 technologie, a co za tym idzie: wiedza i umiejętności szybko się zmieniają —
rozwiązania, które były dobre kilka lat temu, teraz często są nieefektywne;
 środowisko techniczne to takie, w którym ogromną rolę odgrywa innowacyjność
— cały czas potrzebne są nowe rozwiązania umożliwiające stawienie czoła
konkurencji;

4
 kluczowe kompetencje, które są niezbędne w tym środowisku, to umiejętność

rozwiązywania problemów technicznych i biznesowych — zadaniem świata IT
jest głównie rozwiązywanie problemów.
I w tym świecie musi poradzić sobie lider techniczny.
Wizja
Stworzenie wizji polega na spisaniu lub narysowaniu docelowej sytuacji, co będzie
wymagać odpowiedzi na różne pytania w kontekście pracy zespołu, praktyk inżynie-
ryjnych, procesu wytwórczego i współpracy z resztą organizacji. Przykładowe pytania
dotyczące obszarów wyróżnionych w modelu Technical Leadership znajdziesz poniżej.
Praca zespołu
 Jakim chcę być liderem?
 Co powinienem wiedzieć?
 Czego chciałbym się nauczyć?
 Jak chciałbym się zachowywać?
 Jaki poziom motywacji powinien towarzyszyć członkom zespołu?
W jaki sposób w zespole będzie udzielana informacja zwrotna?
 Jak będą rozwiązywane problemy?
 Jak będą rozwiązywane konflikty?
 Jak będą podejmowane decyzje?
 Jaka ma być atmosfera?
Praktyki inżynieryjne
 Jakie praktyki inżynieryjne będą stosowane (np. czysty kod, testy jednostkowe,
przeglądy kodu, wzorce projektowe, Domain-Driven Design3)?
 Jakie standardy jakościowe będą utrzymywane (np. poprzez zdefiniowanie
Definition of Done4)?
 Jak będzie budowana wiedza w zespole, a dalej: jak będzie ona rozpowszech-
niana i jak przechowywana?
 Jakie narzędzia będą używane do ciągłej integracji (continuous integration)
i ciągłego wdrażania (continuous deployment)?
3
Metoda projektowania aplikacji oparta na paradygmacie obiektowym.
4
Narzędzie używane w Scrumie i określające kryteria jakościowe rozwiązania.

4
 Jakie będzie używane zintegrowane środowisko pracy?

 Jakie będzie używane środowisko kompilacji i budowania kodu?
Proces wytwórczy
 Jakiej metodyki będziesz używać (jeśli masz na to wpływ)?
 Jak będą mierzone efekty działań w zespole?
 Jak będzie analizowana efektywność pracy?
 Jakiego typu spotkania będą organizowane?
 W jaki sposób będą stawiane cele i jak będą monitorowane?
 Jak będzie organizowany podział, szacowanie i realizacja zadań?
Współpraca z organizacją
 Jak będzie wyglądać relacja z biznesem lub klientem?
 Jak będzie wyglądać relacja z pozostałymi zespołami w organizacji?
 Jak będzie budowana ta relacja?
 Jak będą rozwiązywane problemy?
Szczegółowy przykład tego, jak stworzyć wizję pracy zespołu, znajdziesz w rozdziale 3.
„Od wizji do działania”.
Stereotyp lidera
Kiedy ekspert staje się liderem, w sposób dość oczywisty pojawia się pytanie, czy liderem
nie trzeba się czasem urodzić. W końcu nie każdy ma takie naturalne umiejętności,
jak: zdolność kwiecistego przemawiania, talent inspirowania innych, umiejętność wznie-
cania dużych pokładów energii. Nie każdy urodził się Napoleonem, Kennedym, Mar-
tinem Lutherem Kingiem czy Lechem Wałęsą.
Również mnie towarzyszyło od samego początku to pytanie, ponieważ z natury byłem
osobą introwertyczną, raczej małomówną, zawsze mającą sporo pytań i wątpliwości.
Nie byłem urodzonym liderem.
Po wielu latach pracy z liderami w różnych firmach zaskakujący stał się dla mnie następu-
jący wniosek: spora część liderów technicznych wcale nie wyróżnia się stereotypowymi ce-
chami przywódczymi. To osoby, które często na spotkaniach siedzą gdzieś z boku, uważ-
nie przysłuchują się temu, co się dzieje, nie są najbardziej aktywnymi osobami na
spotkaniu, a mimo to wśród pozostałych członków zespołu mają duży szacunek.
Chciałbym Ci zaproponować ćwiczenie, które pozwoli Ci zweryfikować stereotyp lidera.

4
Ć W I C Z E N I E 1.
Przypomnij sobie sytuację w swoim życiu zawodowym, kiedy współpracowałeś z kimś,
o kim mógłbyś powiedzieć, że to jest lider. Czym charakteryzował się ów lider?
Poniżej znajdziesz odpowiedzi, które miałem okazję wielokrotnie usłyszeć w trakcie
warsztatów.
 Przejawiał następujące zachowania: zadawał pytania, analizował sytuację, był
mediatorem, nie narzucał własnego rozwiązania, przeciwdziałał pożarom, mo-
nitorował dotrzymywanie zobowiązań, sam się angażował, podejmował trudne
decyzje, przypominał cel.
 Mówił: „To, co mamy do zrobienia, jest ważne, ale nie przejmuj się” albo:
„Skoncentrujmy się na rozwiązaniu problemów”.
 Charakteryzowały go: nastawienie na cel, pewność siebie, otwartość, umiejęt-
ność budowania relacji z innymi, spokój, odwaga, wiedza i doświadczenie,
pozytywna komunikacja, wytrwałość i cierpliwość.
 Do jego umiejętności zaliczyć można było: mediowanie, podejmowanie ryzyka,
negocjowanie.
 Można by go nazwać: dobry wujek, opiekun.
Wśród powyższych stwierdzeń niewiele znajdziesz cech typowych dla charyzma-
tycznych przywódców znanych z kart podręczników historii. A to dlatego, że przy-
wództwo ma wiele odcieni.
Typy przywództwa
Istnieje przynajmniej kilka typologii przywództwa utworzonych m.in. przez: Kurta
Lewina, Maxa Webera, Jamesa Burnsa, Arthura Carmazziego. Przyjrzyj się bliżej
wybranym typom przywództwa, pomoże Ci to lepiej zrozumieć, co jest przydatne
w kontekście przywództwa technicznego.
Przywództwo charyzmatyczne
To stereotypowy rodzaj przywództwa. Najczęściej dotyczy liderów na wysokich sta-
nowiskach — polega na wzbudzaniu energii i pasji szczególnie potrzebnych w sytu-
acjach, kiedy racjonalne argumenty tracą rację bytu. Liderzy tego typu potrafią świetnie
posługiwać się językiem i emocjami, budując motywację w zespole. Ważny jest dla
nich wygląd zewnętrzny, a także stan duszy i ciała. Taki lider to zwykle atrakcyjna
osobowość potrafiąca budować relacje i przekonywać do swoich racji. Dla chary-
zmatycznego przywódcy ważny jest cel, do którego jest w stanie dążyć za wszelką ce-
nę, co w skrajnych przypadkach może prowadzić do bezwzględnych decyzji. Pozytyw-
nym przykładem może być tutaj Martin Luther King, a negatywnym Adolf Hitler.

4
Zakłada się, że charyzma jest budowana w młodości. Można kształtować ją później,

jednak jest to wtedy powolny proces.
Przywództwo transakcyjne
To rodzaj przywództwa, w którym pozycja lidera opiera się przede wszystkim na po-
zycji zajmowanej w organizacji. Taki lider jest skupiony na realizacji zadań oraz roz-
liczaniu efektów prac na zasadzie kar i nagród (główne narzędzia motywacyjne).
Najczęściej temu stylowi towarzyszy zarządzanie poprzez wyjątki. Jest to styl, który
zwykle przypisany jest w biznesie do stanowiska kierownika. Tacy liderzy mówią:
„Zrób to, a będziesz miał większą premię”, „Jeśli nie zrobisz tego na czas, zostaniesz
zwolniony”. Sprawdzi się dobrze w przewidywalnym i nieskomplikowanym środowi-
sku, natomiast nie zda egzaminu w przypadku grup pasjonatów, którzy chcą zrobić coś
sami z siebie.
Przywództwo transformacyjne
Dla liderów transformacyjnych kluczowa jest spójność deklaracji i działań, są to oso-
by o wysokiej inteligencji emocjonalnej. Utrzymują silną motywację poprzez two-
rzenie współdzielonej wizji, inspirowanie innych oraz dbanie o komunikację. Odzna-
czają się samoświadomością, autentycznością, empatią i skromnością. Mają wysokie
poczucie odpowiedzialności. Ustalają jasne cele i rozwiązują konflikty. Dla tego ty-
pu liderów ważne są potrzeby innych. Podają w wątpliwość status quo.
Przywództwo wizjonerskie
W tym przypadku przywódca jest osobą kreatywną, potrafi tworzyć atrakcyjne wizje
oraz przedstawiać je zespołowi w sposób obrazowy. W każdej sytuacji widzi potencjał.
Ważniejsze jest to, co się może stać, niż to, co jest. Zaraża innych wizją. W skrajnym
przypadku lider wizjoner będzie się skupiał na stworzeniu wizji, zaś realizacja nie
będzie dla niego atrakcyjna.
Przywództwo służebne
Jest to rodzaj przywództwa, które nabiera coraz większego znaczenia, szczególnie
w związku ze wzrostem popularności metodyk zwinnych. Lider tego typu skupia się
przede wszystkim na potrzebach członków zespołu oraz na wsparciu w realizacji za-
łożonych celów. Charakterystyczny dla tego stylu jest coachingowy charakter oddzia-
ływania. Ta strategia będzie efektywna w przypadku, gdy członkowie zespołu są
samodzielni i gdy wartości i etyka mają duże znaczenie. To podejście wymaga czasu
i cierpliwości.

4
ĆWICZENIE 2.
Spróbuj określić, który styl przywództwa jest Ci najbliższy. Jak możesz wykorzystać
pozytywne aspekty danego stylu, a jak zniwelować negatywne? Którego stylu chciałbyś
się nauczyć?
Jak widać, nie ma jednego przepisu na przywództwo. Idealnie byłoby umieć się po-
sługiwać różnymi stylami w zależności od sytuacji. W kontekście roli lidera technicz-
nego zazwyczaj nie ma większego zastosowania przywództwo charyzmatyczne, a za to
dużo bardziej przydatne są te style, które wspierają kreatywność, rozwój członków ze-
społu i poszukiwanie motywacji opartej na potrzebach — połączenie stylu transforma-
cyjnego, wizjonerskiego i służebnego. I takie założenie towarzyszy tej książce. Przed-
stawię główne modele mentalne i narzędzia, które wspierają ten sposób działania.
Grzechy główne liderów technicznych

Do tej pory pisałem o tym, co warto robić. Tym razem skupię się na tym, na co warto
uważać, będąc liderem technicznym. Jest to subiektywna lista błędów często popeł-
nianych przez liderów.
Uciekanie w zadania techniczne

Bądźmy ze sobą szczerzy: większość z nas lubi zadania techniczne. Szczególnie w sytu-
acjach, kiedy jeszcze nie czujemy się pewni w roli lidera, zadanie techniczne to bez-
pieczny azyl, w którym można się ukryć. Zawsze znajdzie się jakiś pretekst ku temu,
żeby wziąć na siebie dane zadanie („Bo nie ma czasu, żeby robił to ktoś inny”, „Bo ja
to zrobię najlepiej”). Wiele razy spotykałem się z sytuacją, w której zespół pozostał bez
wsparcia i podjętych decyzji, tylko dlatego że lider zajął się zadaniami technicznymi.
Odpuszczanie reguł w przypadku pożarów

Często jako liderzy ambitnie wprowadzamy do pracy zespołu różne praktyki, takie jak:
codzienne spotkania, ustalone standardy jakościowe czy przeglądy kodu. Wszystko
jest w porządku do momentu, aż pojawią się problemy w projekcie. Brak czasu powo-
duje, że zaczynamy rezygnować z przyjętych praktyk. A to zazwyczaj jest pierwszy
krok do tego, aby całkowicie je odpuścić.
Nierobienie retrospekcji
W wielu metodykach istnieje forma ciągłego udoskonalania sposobu pracy i wpro-
wadzania zmian na podstawie nabytych doświadczeń w postaci retrospekcji, lessons
learned czy after action review. Jest to moim zdaniem jedna z najważniejszych praktyk

4
związanych z realizacją projektów i pracą zespołu. Ku mojemu zdziwieniu jest ona

bardzo często pomijana, a ta praktyka to w zasadzie jedyna szansa, aby regularnie
usprawniać pracę zespołu. Główne powody rezygnowania z tej praktyki to: brak zro-
zumienia jej celu i brak umiejętności jej przeprowadzania, co może być szczególnie
trudne w zespole, w którym jest niewielki poziom zaufania. Jest jeszcze jeden powód,
który bardziej szczegółowo został opisany poniżej.
Niewdrażanie wyników retrospekcji

Czasami bywa tak, że retrospekcje się odbywają, ich efektem jest zestaw wniosków na
temat tego, co działa, a co nie działa w zespole, powstaje nawet wiele pomysłów, co
należałoby zrobić z usterkami. Tymczasem na kolejnej retrospekcji okazuje się, że
nic się nie zmieniło. I na kolejnej również. Po trzech lub czterech takich sytuacjach
członkowie zespołu tracą wiarę, że retrospekcje mają sens, i przestają się w nie anga-
żować.
Zbyt wiele rzeczy jednocześnie

Organizacje generują wiele zadań i problemów, które należy rozwiązywać. Zawsze
brakuje czasu, toteż zazwyczaj ratujemy się równoległą realizacją wielu zadań —
swoich i zespołu — co w rezultacie prowadzi do bardzo nieefektywnej wielozada-
niowości. Spotykałem kilkuosobowe zespoły, które realizowały w danym momencie
kilkanaście projektów. Zazwyczaj ulegamy presji klienta oraz złudzeniu, że wieloza-
daniowość jest bardziej efektywna. Warto przyswoić sobie i stosować regułę: „Przestań
zaczynać, zacznij kończyć”.
Brak asertywności
Asertywność to umiejętność numer jeden w świecie biznesowym. Podlegamy naci-
skom ze strony klienta, przełożonego, a nawet członków zespołu. Często osoby pra-
cujące po stronie klienta są doskonale wyszkolone w asertywności i świetnie sobie
radzą z naciskami, natomiast w środowisku ekspertów technicznych rzadko się to
ćwiczy. W efekcie albo ulegamy naciskom, albo jesteśmy skrajnie asertywni, a w zasa-
dzie agresywni — nerwowo i oschle reagując na to, co się dzieje w projekcie.
Brak czynnika ludzkiego

Jest to pochodna silnego zakorzenienia w roli eksperta. Rola eksperta polega przede
wszystkim na dobrym wykonaniu zadania, czemu często towarzyszy silna potrzeba
działania autorytarnego. W przypadku roli lidera to się nie sprawdza, gdyż członkowie
zespołu mają poczucie, że są traktowani w sposób przedmiotowy. W niektórych
przypadkach ten deficyt prowadzi do przeciążania zespołu zadaniami, których to zadań
nie jest w stanie zrealizować.

4
Zbytnia miękkość
Z kolei ta przypadłość jest odwrotnością poprzedniej. Część osób, przechodząc z roli
eksperta do roli lidera, zakłada, że członkowie ich zespołu są wystarczająco dorośli, by
sobie poradzić. Nie chcą ingerować w działania poszczególnych osób.
Brak umiejętności odniesienia się bezpośrednio do problemu

Powyższemu zagadnieniu towarzyszy często nieumiejętność radzenia sobie z trudnymi
sytuacjami interpersonalnymi, kiedy ogólnie wiadomo, że jest problem, ale ten temat
nie jest poruszany przez lidera.
Brak umiejętności radzenia sobie z konfliktem

Jako osoby techniczne rzadko szkolimy się z radzenia sobie z sytuacjami konfliktowymi,
a jest to nieuniknione w każdym poważniejszym projekcie. Z braku wyszkolenia albo
zaogniamy konflikt i jeszcze bardziej dzielimy zespół, albo ignorujemy problem, nie
wiedząc, jak sobie z nim poradzić.
Branie zbyt wielu rzeczy na siebie

Rola eksperta wymaga realizowania zadań od początku do końca i wysokiej jakości
pracy, rola lidera każe znaleźć sposób efektywnego wykorzystania zasobów całego ze-
społu. Silne zakorzenienie w roli eksperta powoduje, że mamy opory przed oddaniem
komuś zadania, jeśli jesteśmy przekonani, że sami wykonamy je szybciej lub lepiej. Cza-
sami może to być spowodowane nieumiejętnością proszenia o pomoc.
Brak informowania
To bardzo duży problem, szczególnie wśród osób technicznych. Praca eksperta tech-
nicznego co do zasady to zazwyczaj praca w pojedynkę, w zamkniętej przestrzeni
czasowej, we własnym świecie. W tej sytuacji nie ma dużej potrzeby informowania
o wykonywanej pracy i podejmowanych decyzjach. Jednak w przypadku roli lidera
konieczna jest inna umiejętność: trzeba efektywnie przekazywać informacje, tak aby
docierały one do wszystkich zainteresowanych. Bo jak powiedział kiedyś Kent Beck5:
większość problemów w projektach wynika z tego, że ktoś komuś czegoś nie powie-
dział. Często się zdarza, że zespół nie wie zbyt wiele o wizji produktu, że liderzy za-
pominają przekazać zespołowi kluczowe decyzje projektowe.
5
Współtwórca Extreme Programming i Test-Driven Development.

4
Podsumowanie
Typowa ścieżka kariery w IT prowadzi od eksperta do lidera, co budzi wiele frustracji,
często dlatego, że ekspertom technicznym brakuje odpowiednich umiejętności i genu
przywództwa. Tymczasem w przypadku zespołów technicznych wcale nie chodzi o ste-
reotypowe przywództwo, ale o tworzenie miejsca, w którym inni chcą pracować, po-
przez ciągłe udoskonalanie sposobu pracy zespołu, praktyk inżynieryjnych, procesu
czy relacji z biznesem. Zadaniem lidera jest stworzenie wizji, a w efekcie planu działań,
dzięki któremu środowisko pracy zespołu będzie sprzyjać efektywności.
Nie ma jednego sposobu na bycie liderem — można być liderem charyzmatycznym,
transakcyjnym, transformacyjnym, służebnym lub wizjonerem. Właściwy styl należy
dobrać odpowiednio do kontekstu i swoich predyspozycji. W przypadku zespołów
programistycznych najlepiej się sprawdzają style transformacyjny, służebny i wizjo-
nerski.
Eksperci, którzy stali się liderami, często starają się stosować te same strategie działania,
które się dobrze sprawdzały w przypadku zadań technicznych, co często nie przynosi
dobrych efektów i prowadzi do popełniania błędów. Dokonaj autoanalizy i odpo-
wiedz sobie na pytanie, które z grzechów głównych liderów popełniasz i jak możesz
im zaradzić.
Rysunek 1.4 przedstawia mapę myśli podsumowującą zagadnienia z tego rozdziału.
Rysunek 1.4. Podsumowanie rozdziału

4

4
Rozdział 2.
EKSPERT A LIDER
Zanim staniemy się liderami, wcześniej pracujemy jako eksperci — mamy dużą wiedzę
i doświadczenie w danym zagadnieniu. Większość wypraktykowanych przez nas sposo-
bów działania dotyczy prac programistycznych, testerskich czy — ogólniej mówiąc
— technicznych, które w sposób automatyczny próbujemy przenieść na grunt pracy
z zespołem. Często się zdarza, że liderzy techniczni muszą jednocześnie pełnić w projek-
cie funkcję eksperta, co jeszcze bardziej komplikuje sytuację.
Między ekspertem a liderem

Zazwyczaj w realiach codzienności projektowej role eksperta i lidera się przenikają,
dlatego postaramy się je nieco sztucznie rozdzielić, żeby znaleźć sposoby działania ade-
kwatne do kontekstu. Różnice między ekspertem a liderem pokazano w tabeli 2.1.
Podsumowując zawartość tabeli, można powiedzieć, że ekspert skupia się na rozwi-
janiu własnej wiedzy i poprawnym rozwiązaniu zadania, natomiast uwaga lidera skie-
rowana jest na zespół i jego sukces.
Czy można łączyć te role? A jeśli tak, to w jaki sposób? Jak odnaleźć się w sytuacji,
kiedy organizacja oczekuje, aby odgrywać obie role jednocześnie? Na to pytanie nie
ma jednoznacznej odpowiedzi, gdyż wiele zależy od indywidualnych preferencji osoby
będącej liderem oraz od oczekiwań organizacji. Powyższe zagadnienie można rozpatry-
wać jako kontinuum, w którym przeciwstawnymi skrajnościami są bycie wyłącznie
ekspertem oraz bycie wyłącznie liderem.

4
Tabela 2.1. Porównanie roli eksperta i lidera
Ekspert Lider
Co jest ważne Rozwijanie swojej wiedzy. Sprawne działanie zespołu.
w danej roli? Skutecznie wykonywanie zadania. Sukces zespołu.
JA. MY.
Jakie umiejętności Umiejętność dobrego rozwiązywania Umiejętności miękkie, m.in.
są kluczowe? zadań technicznych. rozwiązywanie konfliktów,
Wiedza i doświadczenie w obszarze budowanie zespołu.
eksperckim. Tworzenie atmosfery.
Jakie działania Analiza problemu lub zadania. Obserwacja pracy zespołu.
są kluczowe? Znajdowanie rozwiązań i ich Wychwytywanie problemów.
implementacja. Wspieranie działań zespołu.
Poniżej przedstawiam analizę kilku podejść (rysunek 2.1). Ostateczna decyzja, który
model wybierzesz, należy do Ciebie.
Rysunek 2.1. Różne strategie realizacji roli eksperta i lidera
Silny ekspert
Szczególnie na początku drogi stawania się liderem chcemy pozostawać ekspertami
z dużą wiedzą. Jest to założenie zrozumiałe, jednakże bardzo trudne w realizacji. Bycie
ekspertem i bycie na bieżąco z branżowymi nowinkami wymaga dużych nakładów
czasu, co przy obowiązkach związanych z rolą lidera wymaga ogromnego wysiłku.
Osoby, które decydują się na to podejście, zazwyczaj poświęcają mnóstwo czasu po
pracy na rozwijanie swojej wiedzy eksperckiej.
W tym podejściu lider jest jednocześnie mentorem dla członków zespołu.

4
Rozdział 2. Ekspert a lider 27
Tylko lider
Jest to strategia najprostsza w realizacji, jednak wymaga ogromnej zmiany nastawienia
do pracy, która to zmiana polega na całkowitej rezygnacji z ambicji utrzymywania
wyspecjalizowanej wiedzy eksperckiej. Zazwyczaj zdecydowanie się na ten krok wy-
maga czasu. Bycie tylko liderem nie oznacza rezygnacji z kompetencji technicznych
— taki lider zachowuje przecież swoją dotychczasową wiedzę i doświadczenie, które będą
stanowić świetną bazę do pracy z zespołem.
Coach lub mentor

O ile skrajności są prostsze, jeśli chodzi o podejmowanie decyzji, o tyle zazwyczaj są
mało efektywne. Natomiast podejściem świetnie sprawdzającym się w praktyce może
być postawa coacha lub mentora.
Coach to osoba, która przede wszystkim zadaje pytania, po to aby pomóc rozwiązać
problemy projektowe. Ta strategia dobrze funkcjonuje w przypadku doświadczonych
zespołów. W tym podejściu lider pracuje z daną osobą nad zadaniem i jego rolą jest
głównie zadawanie pytań, aby pomóc znaleźć pomysły na znalezienie rozwiązania.
Mentor to osoba, która sama sugeruje rozwiązania potem realizowane przez członków
zespołu. Ta strategia sprawdzi się w przypadku mniej doświadczonego zespołu. W trak-
cie implementacji rozwiązania lider spotyka się z daną osobą, aby przedyskutować
przebieg prac. Na końcu lider analizuje rozwiązanie i w przypadku zastosowania
technologii, cechy, rozwiązania, którego nie zna, może zapytać o szczegóły. W ten
sposób wykorzystuje wiedzę zdobytą przez innych w trakcie rozwiązywania zadania
do poszerzenia własnej wiedzy. Jest to świetna strategia pozwalająca łączyć role li-
dera i eksperta.
Czas
Na kontinuum ekspert – lider występuje również pewna dynamika. Czynnikiem, który
należy dodatkowo uwzględnić, jest czas. W miarę upływu czasu w sposób naturalny
będziesz zmierzał w stronę roli lidera, gdyż Twój zespół będzie się powiększał, a Twój
zakres obowiązków będzie się powiększał.
Bycie liderem czy bycie ekspertem

A co zrobić, jeśli zostałeś liderem, choć wcale nie chcesz nim być? Warto się nad tym
wnikliwie zastanowić. Wejście w rolę lidera to często duża zmiana, a każda zmiana
budzi naturalny lęk i stąd może się brać Twoja niechęć do nowej roli. Zanim podejmiesz
decyzję, przeanalizuj plusy i minusy roli lidera.

4
Co może Ci dać bycie liderem?

 Masz większy wpływ na to, co się dzieje w projekcie.
 Zaczynasz decydować.
 Możesz pomagać innym.
 Możesz przekazywać innym swoją wiedzę.
 Rośnie Twoje znaczenie w organizacji.
 Rośnie gratyfikacja finansowa.
 Masz szerszą perspektywę patrzenia na to, co się dzieje w projekcie.
 Masz większą odpowiedzialność.
 Masz większą wolność działania.
Z drugiej strony jeśli przez pewien czas jesteś liderem i masz poczucie, że to nie jest dla
Ciebie, przedstaw swoje wątpliwości odpowiedniej osobie w organizacji. Może rze-
czywiście lepszym rozwiązaniem dla wszystkich będzie Twój powrót do roli eksperta,
gdyż nie ma nic bardziej nieefektywnego, jak trwanie w stanie frustracji wynikającym
z braku zgody na wyznaczoną rolę.
Która rola ważniejsza?

Warto też zadać sobie pytanie, która z tych dwóch ról jest ważniejsza, gdy przychodzi
odgrywać je obydwie. Co będzie mieć dla Ciebie bardziej nieprzyjemne konsekwencje:
kiedy zaniedbasz zadania liderskie czy gdy zaniedbasz zadania eksperckie? Odpowiedź
może zależeć od kontekstu. Niemniej jednak w większości przypadków zaniedbanie
zadań lidera ma większe negatywne skutki, gdyż dotyczy całego zespołu i są to zadania,
których nikt poza Tobą nie będzie w stanie wykonać.
Na przykład masz wybór: zorganizować spotkanie, na którym zostanie ustalone, w jaki
sposób zespół będzie weryfikował zakończenie zadania, lub wykonać zadanie, które
pozwoli na ukończenie funkcjonalności w systemie. W pierwszym przypadku brak
ustalenia powoduje, że cały zespół pracuje nieefektywnie, co jest spowodowane tym,
że wielokrotnie trzeba wracać do zadań, które zostały już pozornie zakończone. W drugim
przypadku jest szansa, że zadanie wykona ktoś inny.
Dlatego przy podejmowaniu decyzji odnośnie do priorytetów warto pamiętać o tym,
że najczęściej to rola lidera ma większe znaczenie.
Autorytet wiedzy i postawy

Stawanie się liderem to proces. To nie jest kwestia pojedynczej decyzji i zmiany sta-
nowiska. Często potrzeba wielu miesięcy, a nawet lat, zanim ktoś odnajdzie się w nowej
roli. Co sprawia największy problem w tym procesie? Przywiązanie do autorytetu wie-
dzy. Ponieważ przez wiele lat swoją wartość zawodową budowałeś na fundamencie
wiedzy i doświadczenia eksperckiego, stając się liderem, tracisz to, co było do tej pory

4
fundamentalne, a jednocześnie zadajesz sobie pytanie: „Jak w takim razie mam zbu-
dować autorytet w zespole?”.
Dopóki będziesz chciał opierać swój autorytet na posiadanej wiedzy technicznej, dopóty
będziesz toczyć wewnętrzną walkę o to, jak pogodzić role lidera i eksperta. Uwolnie-
nie od dylematu przychodzi wtedy, gdy zaczyna się rozumieć, że w przypadku lidera
dużo ważniejsza niż wiedza jest postawa, czyli sposób działania i budowania relacji
z zespołem.
Jak możesz budować autorytet postawy? Oto sposoby:
 dostarczaj członkom zespołu aktualnych informacji na temat oczekiwań wobec
nich oraz na temat wizji, celów i sposobów ich realizacji, sytuacji projektu, orga-
nizacji, rynku, alternatywnych sposobów działania;
 wysłuchuj informacji dotyczących oczekiwań członków zespołu wobec Ciebie,
proponowanych przez Ciebie rozwiązań, nieoczekiwanych zdarzeń i problemów;
 doceniaj zdolności członków zespołu do samodzielnego działania, uczenia się
nowych rzeczy, podejmowania wyzwań, dokonywania zmian;
 w jasny sposób ustalaj zasady, nie akceptuj zachowań agresywnych, pozytywnie
wzmacniaj oraz dbaj o sprawiedliwość.
Jak pogodzić prace techniczne i nietechniczne?

Powyżej pisałem, jak można łączyć role eksperta i lidera, a teraz przyjrzę się bliżej temu,
jak organizować swój czas, żeby pogodzić prace techniczne i nietechniczne. Warto
najpierw zadać sobie pytanie, co takiego sprawia, że trudno jest połączyć te dwa ro-
dzaje prac. Oto główne przyczyny:
 prace techniczne liderskie i eksperckie wymagają innego trybu pracy — trudno
się przełączać między tymi trybami;
 zadania i priorytety w ciągu dnia bardzo szybko się zmieniają;
 jest za dużo zadań do wykonania;
 powstaje wrażenie, że nic nie się nie zrobiło przez cały dzień.
Poniżej omawiam bliżej te przyczyny.
Zadania liderskie i eksperckie wymagają innego trybu pracy

Zadań liderskich jest wiele, wymagają szybkiego przełączania się między nimi i czę-
sto trzeba się komunikować z innymi osobami. Jest to stan, któremu bliżej do roz-
proszenia niż skupienia. Zadania eksperckie wymagają głębokiego wejścia w temat,
wysokiego poziomu skupienia i osiągnięcia pewnego stanu umysłu nazywanego strefą
programisty (programmer’s zone) lub bardziej ogólnie stanem przepływu (flow). Przełą-
czanie się z jednego trybu w drugi jest bardzo kosztowne.
Jak można sobie z tym radzić? Możesz zastosować poniższe techniki.

4
Wyspy czasowe lub harmonogram dnia

Ustal czas w ciągu dnia, który przeznaczasz osobno na zadania techniczne i nietech-
niczne. Ilość czasu, przedział godzinowy i konsekwencje realizacji tego ustalenia musisz
dopasować do swojej organizacji, zespołu i innych osób, z którymi współpracujesz.
Ważne jest, żeby poinformować inne osoby o poczynionych założeniach, szczegól-
nie jeśli może to wpłynąć na ich pracę. Warto rozważyć wcześniejsze skonsultowanie
tego pomysłu —pamiętaj wtedy o przedstawieniu intencji, z jaką chcesz wprowadzić
tę praktykę (tzn. wyjaśnij, że zależy Ci na efektywnym realizowaniu zadań).
Możesz np. zarezerwować czas w godzinach 8.00 – 10.00 oraz 12.00 – 14.00 na zadania
techniczne, jeśli potrzebny jest Twój dość duży udział w projekcie, lub odwrotnie: możesz
zarezerwować określony przedział czasowy na zadania liderskie (rysunek 2.2).
Rysunek 2.2. Harmonogram dnia
Pomodoro
Inną opcją jest zastosowanie w zespole techniki pomodoro, która polega na wprowa-
dzeniu taktów pracy: każdy z nich zajmuje 30 min, z czego 25 min to nieprzerwana
praca, a 5 min jest przeznaczone na przerwę i ewentualne rozmowy (rysunek 2.3). Wte-
dy jako lider możesz wybrać takty, które przeznaczysz na zadania techniczne i nietech-
niczne.
Rysunek 2.3. Minutnik, który może odmierzać takty pomodoro
Oczywiście w realiach organizacji biznesowych potrzebna jest pewna doza elastycz-

ności, warto jednak się trzymać przyjętych założeń.

4
Mapa myśli
Kiedy musisz przerwać zadanie i w żaden sposób nie możesz tego odroczyć, warto zro-
bić zrzut (snapshot) wszystkiego, co masz w danym momencie w głowie. Można np.
zapisać kolejne kroki, które chciałeś wykonać. Przydatnym narzędziem mentalnym
może być w tym przypadku mapa myśli (rysunek 2.4), która świetnie się nadaje do
robienia tego rodzaju zrzutów pamięci. Jej zaletą jest to, że nie musisz wymyślać żadnej
konkretnej struktury, aby zawrzeć to, co w danej chwili masz w głowie.
Rysunek 2.4. Przykładowa mapa myśli
Zadania i priorytety w ciągu dnia bardzo szybko się zmieniają

Kiedy jesteś liderem, liczba tematów, z którymi masz do czynienia, sukcesywnie rośnie.
Jeśli chcesz panować nad sytuacją, powinieneś koniecznie wdrożyć jakiś system do
zarządzania zadaniami. Być może w Twojej organizacji jest już coś, co możesz wykorzy-
stać. Dwie bardzo przydatne techniki pracy z zadaniami to Getting Things Done oraz
Personal Kanban — a narzędzi wspierających ich codzienne stosowanie możesz znaleźć
wiele (rysunek 2.5).
Poniżej daję kilka podstawowych wskazówek odnośnie do pracy z zadaniami:
 Każde zadanie powinieneś zapisywać — nic bardziej nie obciąża Twojego mózgu
niż dziesiątki zadań, o których musisz pamiętać.
 W większych organizacjach prawdopodobnie będziesz miał kilka źródeł zadań,
np.: poczta elektroniczna, bugtracker, komunikator, system do zarządzania za-
daniami w projekcie; powinieneś doprowadzić do tego, aby wszystkie zadania
lądowały ostatecznie w jednym miejscu. Czasami może to oznaczać trochę
pracy z przenoszeniem ich w jedno miejsce, ale warto to zrobić, bo tylko wtedy
będziesz miał pełny i spójny obraz sytuacji.

4
Rysunek 2.5. Przykładowe narzędzie wspierające Getting Things Done
 Zebrane zadania przeglądaj przynajmniej raz dziennie i dokonuj ich wstępnej

selekcji. Niech kolejność zadań na liście będzie wyrazem kolejności, w jakiej
chciałbyś się nimi zająć — najlepiej jeśli planowanie będzie pierwsza rzeczą,
którą robisz każdego dnia.
 Jeśli coś możesz zrobić w ciągu 2 minut, zrób to natychmiast, nie tworząc
nowego zadania, jednak bądź ostrożny w przypadku odpowiadania na maile
(być może efektywniej będzie porozmawiać osobiście lub zadzwonić).
 To, co masz do zrobienia, zapisuj w konkretnej postaci — unikaj skrótowych
zapisów. Dobra treść zadania powinna zawierać informację o konkretnej
czynności, która ma być wykonana (powinna zawierać czasownik).
Stosując narzędzia oparte na technice Personal Kanban, możesz wizualizować to,
czym się zajmujesz, oraz stosować ograniczenia liczby realizowanych zadań, aby mini-
malizować nieefektywność wielozadaniowości.
Zbyt dużo zadań do wykonania

Nieważne, ile czasu spędzisz na realizacji zadań, i tak masz wrażenie, że nawet gdybyś
pracował 24 godziny na dobę, nie byłbyś w stanie zrealizować wszystkich. Powodów
może być kilka:
 nie organizujesz zbyt dobrze swojego czasu;
 bierzesz zbyt wiele rzeczy na siebie;
 masz zbyt wiele zadań do wykonania.

4
Co do pierwszego powodu: mogą Ci pomóc opisywane tutaj techniki. Co do drugiego

— przydatna może być technika krytycznej analizy zadania. A co do ostatniego
punktu: być może sprawdzi się analiza czasu pracy.
Krytyczna analiza zadania

Kiedy pojawia się zadanie do wykonania, które jest skierowane do Ciebie lub Twojego
zespołu, zadaj sobie trzy pytania:
 Dlaczego ja?
 Dlaczego teraz?
 Dlaczego w ten sposób?
Dlaczego ja? — przeanalizuj, czy to zadanie na pewno powinno trafić do Ciebie. W śro-
dowiskach złożonych i chaotycznych niektóre decyzje są przypadkowe i nie do końca
przemyślane.
Dlaczego teraz? — w świecie szybkich zmian wszystko jest na już lub na wczoraj.
Jednak w wielu przypadkach zadania nie są tak pilne, jak się wydaje. Czy nie doświad-
czyłeś sytuacji, kiedy coś trzeba było koniecznie zrobić do końca dnia, a na drugi dzień
się okazało, że nikt nie miał czasu, żeby obejrzeć efekty Twoich prac? Pomocne może
być pytanie: „Teraz zajmuję się tym i tym (tu można przedstawić listę swoich zadań).
Jeśli się zajmę nowym zadaniem, będę musiał odłożyć wykonywane zadania. Czy będzie
to problem, jeśli zajmę się tym pojutrze?”.
Dlaczego w ten sposób? — w sytuacji, kiedy ktoś proponuje lub narzuca konkretny
sposób rozwiązania, warto zapytać, dlaczego akurat takie rozwiązanie powinno być
zastosowane. W ten sposób poznasz kryjącą się za zadaniem potrzebę lub intencję.
To może być dobry punkt wyjścia do zaproponowania innego rozwiązania.
Analiza czasu pracy

Kiedy masz wrażenie, że nie jesteś w stanie lepiej zorganizować swojego czasu, umów
się ze sobą, że będziesz możliwie jak najbardziej szczegółowo przez tydzień zapisywał
to, co robisz (rysunek 2.6). Po tygodniu zbierania informacji dokonaj ich analizy.
Być może dostrzeżesz pewne wzorce swojego działania, które pochłaniają dużą część
Twojego czasu — np. ponieważ bardzo lubisz wspierać swoją wiedzą członków zespołu,
masz problem z zauważeniem momentu, kiedy już powinieneś zaprzestać pomocy,
albo dużą część Twojego czasu pochłania poczta elektroniczna i można ją zamienić na
więcej komunikacji bezpośredniej.

4
Rysunek 2.6. Przykładowe zapiski do analizy czasu dnia
Mam wrażenie, że niczego nie zrobiłem przez cały dzień

Efekt wykonania zadania technicznego jest zazwyczaj konkretny i mierzalny. W przy-
padku zadań nietechnicznych często brakuje mierzalnych wyników, czemu towarzyszy
poczucie, że po intensywnym dniu pracy trudno określić, co się zrobiło. Dlatego warto
szukać sposobów wizualizacji wykonywanej pracy.
Tablica kanbanowa
Jednym z takich sposobów jest użycie tablicy kanbanowej (rysunek 2.7), która od-
wzorowuje stan realizowanych zadań za pomocą karteczek. Możesz ją dopasować do
procesu, który obowiązuje w Twoim projekcie. W metodyce Scrum popularnym roz-
wiązaniem jest specjalna tablica dla Scrum Mastera nazywana Rejestrem blokad, która
obrazuje to, czym zajmuje się Scrum Master.
Narzędzie do przechowywania zadań

Drugim sposobem jest zastosowanie narzędzia do zapisywania i przechowywania zadań
(np.: Todoist, Remember the milk, Microsoft Outlook) oraz przeglądanie historii
wpisów raz w tygodniu, aby uświadomić sobie ilość wykonywanej pracy.

4
Rysunek 2.7. Tablica kanbanowa
Codzienna retrospekcja
Na koniec dnia postaraj się spisać, co zrobiłeś danego dnia i czego się nauczyłeś. Z cza-
sem będziesz potrafił coraz precyzyjniej odtwarzać to, co robiłeś, i w efekcie będziesz
miał lepsze wyobrażenie tego, co robisz.
Zadanie dnia
Na początku dnia zastanów się, które z zadań na dany dzień jest najważniejsze.
Upewnij się, że znajdziesz na nie czas. Dobrą praktyką jest zaczynanie od „zadania
dnia” nawet jeszcze przed sprawdzeniem poczty elektronicznej.
Podsumowanie
Ekspert w swojej pracy skupia się przede wszystkim na dobrym wykonaniu zadania
oraz na rozwijaniu swojej wiedzy. Dla lidera miarą sukcesu jest sukces całego zespołu
oraz kluczowe są umiejętności miękkie. W realiach projektowych liderzy często odgry-
wają również rolę ekspertów i pogodzenie tych dwóch ról nie jest łatwe. Aby znaleźć
równowagę, zacznij stosować podejście coacha i mentora — w ten sposób możesz
pomagać zespołowi realizować zadania, a z drugiej strony możesz cały czas rozwijać
swoją wiedzę ekspercką.
Przełomowym momentem w procesie stawania się liderem jest zmiana sposobu bu-
dowania autorytetu poprzez przeniesienie koncentracji z wiedzy na postawę.

4
Bycie liderem to również duże wyzwanie związane z zarządzaniem czasem. Zacznij

w sposób systematyczny używać odpowiednich narzędzi — wysp czasowych do roz-
graniczania zadań technicznych i liderskich, mapy myśli do zapisywania informacji,
gdy musisz przerwać pracę wymagającą skupienia, podejścia Getting Things Done do
codziennego zarządzania wieloma zadaniami czy tablicy kanbanowej do wizualizacji
tego, co robisz.

4
Rozdział 3.
OD WIZJI DO DZIAŁANIA
W rozdziale 1. „Rola lidera technicznego” wspominałem o tym, że lider tworzy wizję,

którą chciałby urzeczywistnić. Z kolei ten rozdział ma charakter czysto praktyczny.
Zachęcam Cię do zdefiniowania własnej wizji i określenia sposobu jej realizacji.
Można to zrobić na wiele sposobów. Przedstawię tutaj narzędzie, które może w tym
pomóc, zwane strategią Disneya.
Strategia Disneya
Myślę, że niemal każdy zna nazwisko Walta Disneya, który sprawił, że filmy animowane
stały się prawdziwymi dziełami sztuki. Disney był rysownikiem, ale przede wszystkim
był świetnym liderem i kreatywnym menedżerem. Wypracował m.in. metodę pracy
nad produkcjami animowanymi, która składała się z trzech faz:
 Faza marzyciela — faza kreatywna, burza mózgów, w czasie której generowane
były pomysły bez analizowania ich sensowności, nie wolno było krytykować.
Spotkanie zazwyczaj odbywało się w wybranym specjalnie pomieszczeniu,
w przyjemnej atmosferze, tak aby każdy uczestnik mógł się czuć zrelaksowany.
 Faza realisty — faza konkretyzacji i planowania, w czasie której zastanawiano
się, co by było potrzebne, aby urzeczywistnić wcześniejsze pomysły. W przy-
padku filmów animowanych narzędziem, które temu służyło, był storyboard
— szkielet fabuły. Spotkanie odbywało się w biurze, w pomieszczeniu, które było
kojarzone z codzienną pracą.

4
 Faza krytyka — faza analizy ryzyka i doszukiwania się braków w wypracowanej

koncepcji. W przypadku filmów animowanych zastanawiano się, czy film będzie
zabawny, czy fabuła będzie logiczna. Spotkanie odbywało się w pomieszczeniu,
w którym było nieprzyjemnie — było zbyt zimno lub zbyt ciepło, meble były
niewygodne, przyciemniano światła.
Kluczowe w strategii Disneya jest to, że w początkowym okresie krytyk nie spotyka
się bezpośrednio z marzycielem. Dopiero po przejściu wszystkich trzech faz, wraca
się do fazy marzyciela, która służy temu, aby odnieść się do krytyki (rysunek 3.1).
Rysunek 3.1. Cykl strategii Disneya
Główne założenia tego podejścia można wykorzystać w codziennej pracy, wszędzie

tam, gdzie wychodząc od pomysłów, trzeba wypracować realistyczny plan działania
uwzględniający ryzyka. Ogromną zaletą tej techniki jest zrównoważenie trzech dia-
metralnie różnych perspektyw. Zazwyczaj mamy jakieś własne naturalne preferencje
— np. ktoś jest realistą, krytykiem lub marzycielem — i swój sposób myślenia, w któ-
rym domyślnie działamy. Jeśli spotkają się dwie osoby o różnych preferencjach, jest to
naturalne zarzewie sytuacji konfliktowej. Na przykład osoba z preferencją marzyciela
będzie generować pomysły, które zostaną natychmiast zanegowane przez osobę z pre-
ferencją krytyka. Jeśli takie osoby nie są tego świadome bądź nie posłużą się strategią
Disneya, prawdopodobnie nie wypracują satysfakcjonującego rozwiązania.
Być może zauważyłeś, że osoby reprezentujące kierownictwo częściej mają preferencję
w kierunku marzyciela, zaś osoby techniczne w kierunku krytyka. To w uproszczony
sposób pokazuje, dlaczego tak trudno wyższemu kierownictwu porozumieć się z IT.
Poszczególne fazy strategii Disneya mogą wpływać na nasz poziom energii. Faza ma-
rzyciela zazwyczaj dodaje energii do działania, faza krytyka ją odbiera, faza realisty
daje poczucie konkretności, sprawczości, jasności co do sposobu działania.
Strategia Disneya to idealne narzędzie do tworzenia wizji, ale może być zastosowane
w wielu innych sytuacjach, takich jak: tworzenie planu rozwoju produktu, ustalanie
planu rozwoju członków zespołu, analiza pomysłów, które się pojawiają w trakcie reali-
zacji projektu, czy wybór rozwiązania.

4
Rozdział 3. Od wizji do działania 39
Definiowanie wizji środowiska

z użyciem strategii Disneya
Poniżej znajduje się instrukcja pomocna w samodzielnym definiowaniu wizji — ta in-
strukcja może być przydatna dla Ciebie i Twojego zespołu. Zamieszczam również plan
jej realizacji. W przeprowadzeniu tego procesu liczyć się będzie udział innych osób.
Marzyciel
Usiądź wygodnie w miejscu, w którym się dobrze czujesz, jesteś zrelaksowany (np. chill-
out room, fotel, kanapa w pokoju dziennym). Szukaj pomysłów. Określ docelową sytu-
ację. Zapisuj i rysuj pomysły na papierze. Pamiętaj: żadnych ograniczeń, żadnej krytyki.
Pytania główne:
 Co chciałbym osiągnąć, gdyby wszystko było możliwe?
 Do czego chciałbym doprowadzić w obszarze pracy zespołu, inżynierii, procesu,
relacji z klientem, relacji z innymi zespołami (wykorzystaj model Technical
Leadership)?
Pytania pomocnicze:
 Jaka sytuacja przekroczyłaby moje najśmielsze oczekiwania?
 Jak bym się czuł w tej sytuacji? Co ona by mi dała?
 Jak bym się wtedy zachowywał? Co by spowodowało, że tak się zachowuję?
 Jakimi umiejętnościami bym wtedy dysponował? Co musiałbym wcześniej zrobić,
żebym miał te umiejętności?
 Kim wtedy będę?
 Dla jakiej idei chcę osiągnąć cel?
Realista
Zmień miejsce. Najlepiej przejdź do innego pomieszczenia. Usiądź wygodnie tam,
gdzie zazwyczaj pracujesz, np. przy biurku. Patrząc na opis marzenia, myśl jak realista.
Spośród pomysłów, które wypisałeś, wybierz trzy, które Twoim zdaniem mają szansę
najwięcej zmienić. Zapisz je w formie konkretnych celów (możesz się posłużyć mo-
delem SMART1). Dla każdego z celów wypisz przynajmniej trzy pierwsze działania,
które należy podjąć.
Pytania główne:
 Które trzy pomysły wniosą najwięcej?
1
SMART to kryteria dobrze określonego celu. Cel powinien być konkretny (specific), mierzalny (mea-
surable), w zasięgu wpływu (achievable), realistyczny (realistic), ograniczony w czasie (time-bound).

4
 Jak będą brzmiały (użyj SMART)?

 Jakie są pierwsze działania, które należy podjąć?
Pytania pomocnicze:
 Czego potrzeba do realizacji tego projektu?
 Ile jest potrzebnych godzin pracy? Jakiej pracy?
 Jakie są dostępne zasoby, a jakie będą potrzebne?
 Co trzeba wykonać? W jakim terminie?
Krytyk
Zmień miejsce. Znów przejdź do innego pomieszczenia, ponurego, z ciemnymi kolorami.
Takiego, w którym łatwo się krytykuje pomysły. Zacznij krytykować to, co wymyślili
marzyciel i realista.
Pytanie główne:
 Co się może nie udać?
Pytania pomocnicze:
 Czego brakuje?
 Co zostało pominięte?
 Kto może się na to nie zgodzić?
 Jakie części planu mogą zawieść?
Przykłady
Pomysły z fazy marzyciela:
 Chciałbym wdrożyć praktyki continuous deployment.
 Chciałbym, żeby członkowie zespołu byli bardziej zmotywowani.
 Chciałbym wprowadzić architektoniczną mantrę w zespole.
 Chciałbym wprowadzić kanban do pracy zespołu.
 Chciałbym wprowadzić stosowanie zasad czystego kodu w zespole.
 Chciałbym usystematyzować robienie przeglądów kodu.
 Chciałbym, żeby członkowie zespołu byli bardziej samodzielni.
 Chciałbym nawiązać współpracę z zespołem utrzymania.
 Chciałbym wprowadzić stosowanie metryk weryfikujących jakość kodu.
 Chciałbym zmniejszyć liczbę zadań, którymi zespół się zajmuje w danym mo-
mencie.
W tabelach 3.1, 3.2 i 3.3 został przedstawiony efekt zastosowania strategii Disneya
w przypadku wybranych celów.

4
Rozdział 3. Od wizji do działania 41
Tabela 3.1. Przykładowy cel poddany procesowi określonemu przez strategię Disneya
Marzyciel Chciałbym wdrożyć praktyki continuous deployment.

Realista — cel W ciągu najbliższego pół roku doprowadzić do sytuacji, w której wdrożenie
nowej wersji na serwery produkcyjne zajmuje mniej niż 30 min i wymaga
użycia tylko jednej komendy.
Realista  Zebrać listę zadań, które w trakcie wdrażania trzeba wykonać ręcznie.
— pierwsze  Opracować pomysły, jak zautomatyzować to, co jest robione ręcznie.
kroki  Oszacować ilość czasu, który byłby potrzebny na wprowadzenie
automatyzacji.
Krytyk  Nie będzie na to czasu.
 Ze względu na ograniczenia dostawcy infrastruktury i kwestie
bezpieczeństwa nie uda się całkowicie zautomatyzować procesu.
 Obecnie zajmuje nam to 8 godzin, nie damy rady zejść do 30 min.
Marzyciel  Przekonać Product Ownera, żeby pracę nad continuous deployment
— druga tura włączyć do Product Backlogu.
 Dowiedzieć się, jakie są możliwości automatyzacji po stronie dostawcy
oraz jakie dodatkowe założenia powinny być poczynione.
 Obejrzeć prezentację z konferencji o praktyce wdrażania continuous
deployment.
Marzyciel Chciałbym, żeby członkowie zespołu byli bardziej samodzielni.

Realista — cel W ciągu najbliższych 3 miesięcy ilość czasu, który poświęcam na pomoc
w rozwiązywaniu problemów technicznych członków zespołu, zmniejszy się
z ok. 20 godzin do 10 godzin tygodniowo.
Realista —  Zorganizować spotkanie i zapytać członków zespołu, co jest potrzebne,
pierwsze kroki aby mogli bardziej samodzielnie rozwiązywać problemy. Na spotkaniu
zastosować strategię Disneya.
 Zacząć robić krótkie osobiste retrospekcje na koniec dnia, żeby stworzyć
typologie sytuacji, w których zbyt dużo czasu poświęcam na pomoc.
 Nauczyć się stosować zadawanie pytań, które będą naprowadzały
na rozwiązanie, zamiast podawać gotowe rozwiązania.
Krytyk  Członkom zespołu może nie zależeć na tym, aby samodzielnie rozwiązywać
problemy.
 Zbyt dużo czasu będzie im zajmować samodzielne wykonywanie zadań.
Marzyciel —  Zapytać członków zespołu, co o tym myślą, czy widzą jakieś problemy.
druga tura  Rozłożyć w czasie proces usamodzielniania członków zespołu (nie robić
tego od razu w jednym kroku).

4
Marzyciel Chciałbym wprowadzić architektoniczną mantrę w zespole.

Realista — cel W ciągu najbliższego roku doprowadzić do sytuacji, w której: (1) każda osoba
w zespole ma jasność co do architektury w różnych częściach systemu;
(2) w pokoju, w którym pracuje zespół, wiszą rysunki obrazujące kluczowe
elementy architektury.
Realista  Zorganizować spotkanie w zespole, w czasie którego ustalimy wspólną
— pierwsze definicję bloków budujących w systemie.
kroki  Narysować bloki budujące i powiesić rysunki.
 Ustalić części systemu, w których będzie obowiązywać spójna mantra,
oraz te części, gdzie nie będzie obowiązywać.
Krytyk  W ferworze prac projektowych mantra nie będzie przestrzegana.
 Nasz system jest zbyt skomplikowany, aby ustalić jedną mantrę.
 Rysunki będą zwracać uwagę tylko na początku, później wszyscy się
do nich przyzwyczają.
Marzyciel —  Wprowadzić comiesięczne retrospekcje projektowe na temat spraw
druga tura technicznych, gdzie stosowanie mantry będzie monitorowane.
 Ustalić kilka mantr lub ustalić jedną i ograniczyć jej zakres stosowania
do wybranych modułów lub pakietów.
 Od czasu do czasu przerysowywać szkice i inaczej je rozmieścić.
Podsumowanie
Strategia Disneya to wspaniałe narzędzie, które pozwoli Ci oddzielić trzy różne i za-
zwyczaj przemieszane perspektywy patrzenia na sytuację. Kiedy będziesz się zasta-
nawiał nad jakimś pomysłem, spójrz na niego oczami:
 marzyciela, dla którego nie ma żadnych ograniczeń;
 realisty, który przekuje pomysły w działania;
 krytyka, który weźmie pod uwagę konieczne do uwzględnienia ryzyka.

4
Rozdział 4.
MOTYWACJA
Każdy lider chciałby mieć w zespole zmotywowane osoby — takie, które się same roz-
wijają, chętnie biorą odpowiedzialność za swoje działania, a następnie robią wszystko,
żeby się wywiązać ze swoich zadań. Nie zniechęcają się, nawet kiedy wykonują żmudne,
powtarzalne czynności, pracują przez kilka lat z przestarzałymi technologiami i nie
poddają się, mimo że organizacja mocno ogranicza możliwości ich działania. W do-
datku cały czas szukają sposobów, jak udoskonalić proces, którego są częścią, i popy-
chają innych do rozwoju. Któż nie chciałby mieć takich członków zespołu? Jednak nie
wszyscy pracownicy są tacy; niektórzy nie chcą się zaangażować, a im bardziej będziesz
próbował ich do tego nakłonić, tym bardziej mogą stawiać opór.
Prawdopodobnie zdziwi Cię stwierdzenie, że nie można TRWALE nikogo do niczego
zmotywować. Jeśli będziesz próbował na kogoś naciskać, to efekt Twojego działania
będzie trwał do czasu, kiedy ustanie oddziaływanie. Jeśli odpuścisz, motywacja minie,
gdyż była to motywacja zewnętrzna.
Teoria X i Y
W latach 60. ubiegłego wieku Douglas McGregor sformułował koncepcję motywacji
zwaną teorią X i Y. Jeśli myślimy według teorii X, uważamy, że pracownicy są leni-
wi, chcą nas oszukać, szukają sposobów, jak się nie narobić, unikają brania odpowie-
dzialności za zadania, a tym, co ich głównie interesuje, są pieniądze. W związku z tym
trzeba cały czas ich kontrolować, nadzorować, nie można im zaufać. Potrzebują ze-
wnętrznego czynnika, który będzie powodował, że będą wypełniać swoje obowiązki.

4
Kiedy myślimy według teorii Y, zakładamy, że pracownicy chcą się realizować w pracy,
że szukają możliwości rozwoju, chcą czerpać przyjemność z obowiązków zawodo-
wych, angażując się, uznajemy, że pieniądze nie są kluczowym czynnikiem, który po-
woduje, że pracują. Ta teoria zakłada, że ludzie mają wewnętrzną motywację do działa-
nia i jeśli tylko dostaną takie możliwości, wykorzystują tę motywację w swojej pracy.
Są to skrajne koncepcje stanowiące granice pewnego kontinuum. Prawda leży gdzieś
pomiędzy tymi skrajnościami i zależy m.in. od indywidualnej historii życiowej, która
mogła wpłynąć na ukształtowanie się jednej z tendencji. Na przykład pracownicy
wcześniej intensywnie doświadczający sytuacji, w których ich inicjatywa, zdanie, opinia
na temat wykonywanej pracy były ignorowane, mogą mieć profil motywacyjny bliższy
opisowi z teorii X. Jeśli ktoś był wcześniej zachęcany do wyrażania swoich opinii, miał
autonomię w działaniu albo sam potrafił ją sobie wywalczyć, wtedy jego profil mo-
tywacyjny będzie bliższy opisowi teorii Y.
Prawdopodobnie rodzimy się z postawą odpowiadającą teorii Y, co widać w zacho-
waniach dzieci, których nie trzeba w żaden sposób motywować, żeby uczyły się chodzić,
biegać czy mówić. Z czasem dzieci przechodzą trening społeczny (tzn. rodzice uczą
je zachowań, które są pożądane w społeczeństwie) i są wtedy zmuszane do zrezygno-
wania z naturalnych dążeń, które nie zawsze są akceptowane przez dorosłych. Dziecko
jest mniej lub bardziej ograniczane, a jego naturalna motywacja jest tłumiona. Dzieci
uczą się, że dostają nagrody, np. pochwały opiekunów, kiedy spełniają oczekiwania do-
rosłych. W ten sposób uczą się zachowań zgodnych z teorią X, które można by spro-
wadzić do stwierdzenia: jeśli będziesz robił to, co będą mówić dorośli (rodzice,
dziadkowie czy nauczyciele), dostaniesz nagrodę lub unikniesz kary.
Dlatego w rzeczywistości najczęściej mamy do czynienia z połączeniem zachowań
teorii X i Y, przy czym badania wykazały, że dla zawodów, które wymagają pracy inte-
lektualnej (knowledge work), skuteczniejsze jest posługiwanie się myśleniem w kate-
goriach teorii Y.
Stwierdzenie przedstawione na samym początku tego rozdziału staje się teraz bardziej
uzasadnione — jeśli będziesz próbował zmotywować kogoś do czegoś zewnętrznie,
efekt będzie krótkotrwały. Są też osoby, które w ten sposób co najwyżej zdemotywujesz.
Co zatem możesz zrobić? Kluczem jest odnalezienie wewnętrznej motywacji osób,
z którymi pracujesz.
Co mnie motywuje?
Zanim jednak zaczniesz poszukiwać preferencji innych osób, zacznij od siebie i od
zdefiniowania tego, co Ciebie samego motywuje. By odnaleźć wewnętrzną motywację,
przywołaj sytuację z przeszłości, kiedy byłeś zmotywowany. Spróbuj przypomnieć
sobie możliwie jak najwięcej szczegółów. Zadaj sobie pytania: Na czym polegało za-
danie? Z kim współpracowałem? Co musiałem zrobić? Czego musiałem się nauczyć?

4
Rozdział 4. Motywacja 45
Czym się różnił ten cel od innych, które były mało motywujące? Kim był mój lider? Jaka
była moja odpowiedzialność? I kluczowe pytanie: Co powodowało, że mi się chciało, że
byłem zmotywowany?
Jeden z liderów tak opisał swoją sytuację:
Pamiętam to jak dziś, kiedy dostałem pod opiekę swój pierwszy zespół. Myślałem,
że mnie rozsadzi, miałem masę pomysłów, jak mogę rozwinąć ten zespół, jak po-
móc ludziom się rozwinąć, jak wprowadzić nowoczesne praktyki typu Test-Driven
Development, wzorce projektowe, Behaviour-Driven Development, Domain-
-Driven Design, standard kodowania, metryki kodu, przeglądy kodu. Miałem to
wszystko przed oczami, mimo że potrzebne było kilka miesięcy, żeby doprowadzić
do tej wizji. Nie miałem łatwej sytuacji: nasz Product Owner ciągle się czepiał,
szczególnie na początku, bo zespół nie miał dobrej opinii. Musiałem doprowa-
dzić do tego, żeby nabrał większego zaufania do zespołu. Skupiliśmy się na
zmniejszeniu liczby wypuszczanych błędów i deklarowaniu zrobienia tylko tego,
co rzeczywiście jesteśmy w stanie wykonać w zadanym czasie. Przy okazji mu-
siałem się dużo nauczyć, bo wiele z praktyk technicznych znałem tylko w ogól-
nych zarysach, a teraz trzeba było to poskładać w działającą całość. A do tego
cały czas musieliśmy rozwijać system. Było to nie lada zadanie, jednak widok
postępów oraz polepszającej się atmosfery w zespole były ogromną nagrodą.
Co mnie głównie motywowało? Spore wyzwanie, co do którego miałem pewne
wyobrażenie, jak je zrealizować. Dużo musiałem się uczyć, a lubię się uczyć. Byłem
świadomy ogromnego postępu, którego dokonywałem. Fenomenalna była praca
z ludźmi i patrzenie, jak się rozwijają.
Czynniki motywacyjne
Są pewne rzeczy, które wszystkich motywują, i takie, które są bardzo indywidualne.
Poniżej znajdziesz czynniki charakterystyczne dla stanu motywacji.
1. Konkretny cel, który jest dużym wyzwaniem, i poczucie, że uda się go zrealizować.
Większość osób, wspominając okres bardzo wysokiej motywacji, wiąże ten stan z ko-
niecznością zmierzenia się z dużym wyzwaniem — zrobieniem czegoś pierwszy raz,
wejściem w nową rolę, nauczeniem się czegoś. Warto to zestawić z tym, że większość
z nas dąży do stabilizacji i przewidywalności, czyli środowiska mało motywującego.
2. Poczucie wpływu i odpowiedzialności za efekt.

Wiele osób w czasie, kiedy były zmotywowane, miało poczucie, że odpowiedzialność
leży przede wszystkim po ich stronie. Tacy ludzie sami podejmowali decyzje i mieli
swobodę wyboru sposobu rozwiązania problemu.

4
3. Widoczność postępu.
Kolejnym czynnikiem jest możliwość zobaczenia postępu — np. w formie jasnego
planu i realizowanych zadań, powstającego produktu i jego kolejnych funkcjonalności,
zwiększonej wydajności, dobrej atmosfery w zespole. Ważne jest, aby efekt działań
był w jakiś sposób widoczny, namacalny.
4. Realizowanie rzeczy ważnej dla danej osoby.

Poprzednio wymienione czynniki są dość uniwersalne; istnieje również grupa czyn-
ników indywidualnych, charakterystycznych dla poszczególnych osób, takich jak: moż-
liwość rozwoju, współpraca z ludźmi, podejmowanie ryzyka, prestiż, które to czyn-
niki nazywam wartościami. Każdy ma swój zindywidualizowany podzbiór takich
wartości, które determinują wewnętrzne poczucie sensu tego, co robi na co dzień.
Kluczem do zrozumienia wewnętrznej motywacji jest rozpoznanie wartości, którymi
kieruje się dana osoba. Odnosząc się do przytoczonej wcześniej wypowiedzi, możemy
powiedzieć, że kluczowe dla tamtego lidera były następujące wartości:
 rozwój (możliwość uczenia się nowych rzeczy);
 praca z ludźmi;
 wkład w rozwój innych osób.
Jeśli więc uda się stworzyć warunki, w których będą spełnione kluczowe czynniki
motywacyjne, i ów lider będzie miał możliwość realizowania przytoczonych wartości,
jest duża szansa, że będzie to dla niego motywujące środowisko.
Nazw wartości jest wiele, można wyodrębnić ich nawet kilkadziesiąt. Poniżej znaj-
dziesz przykładowe typowe wartości w kontekście zawodowym:
 wyzwania — realizuję zadania, które są trudne;
 rozwój — zdobywam nowe umiejętności i wykorzystuję je w praktyce;
 bezpieczeństwo — mogę eksperymentować i popełniać błędy;
 zaufanie — członkowie zespołu mówią szczerze i bezpośrednio, co czują i co
jest dla nich ważne w danej sytuacji;
 współpraca — mogę pracować z innymi ludźmi, socjalizować się z nimi i wspól-
nie rozwiązywać problemy;
 autonomia — mam bezpośredni wpływ na to, co robię, i mogę w dużym za-
kresie samodzielnie podejmować decyzje;
 status — moja wiedza i doświadczenie są doceniane, o czym świadczy m.in.
nazwa mojego stanowiska;
 porządek — istnieją zdefiniowane zasady, które są respektowane;
 wpływ — mam wpływ nie tylko na swoją pracę, ale też na to, co się dzieje w ze-
spole i organizacji.
Pamiętaj: różne osoby mogą preferować różne zestawy wartości i mogą je inaczej de-
finiować.

4
Kryteria
Wartości to pojęcia bardzo szerokie i dla różnych osób mogą oznaczać trochę coś
innego, dlatego należy określić kryteria, czyli warunki, które muszą być spełnione,
żeby dana osoba miała poczucie, że realizuje daną wartość.
Kryteria to odpowiedź na pytania: co muszę zobaczyć, co musi się wydarzyć lub po
czym poznam, że realizuję daną wartość.
W tabeli 4.1 znajdziesz przykłady, jak lider, którego opinię przytoczyłem wyżej, subiek-
tywnie zdefiniował swoje wartości.
Tabela 4.1. Przykładowe definicje wartości
Rozwój  Uczę się czegoś nowego (nowego narzędzia, nowej umiejętności) lub
zaczynam głębiej rozumieć temat, który już znam.
 To, czego się uczę, mogę bezpośrednio zastosować w swojej pracy
— jest to użyteczne.
 Dostaję informację zwrotną, że robię postępy.
Praca z ludźmi  Mogę razem z innymi osobami wymyślać i konsultować pomysły
na rozwiązywanie zadań.
 Poznaję nowe osoby i nawiązuję relacje.
 Pracuję z osobami, z którymi mam wspólny cel — za ten cel wszyscy
ponosimy odpowiedzialność.
Wkład w rozwój  Mogę swoją wiedzą i doświadczeniem wspomagać innych w rozwiązywaniu
innych osób problemów (poprzez wsparcie w formie mentoringu lub coachingu).
 Dostaję informację zwrotną, że moja pomoc jest przydatna.
 Widzę, że osoby, z którymi współpracuję, robią postępy.
Kwantyfikatory ilościowe
Mówiąc o wartościach czy nawet kryteriach realizacji wartości, posługujemy się po-
jęciami rozmytymi i subiektywnymi. Nawet jeśli wiesz, że dla kogoś jest ważne, aby
dostawać informację zwrotną, że jego pomoc jest przydatna, warto byłoby dookreślić,
co to znaczy dostawać informację zwrotną — w jakiej formie musiałby ją dostać i jak
często miałoby się to dziać. Poza tym jeśli chciałbyś pracować nad zmianą w tym obsza-
rze, powinieneś mieć jakiś punkt odniesienia, żeby wiedzieć, gdzie jesteś i gdzie
chciałbyś być.
W tym celu można się posłużyć wirtualną skalą, aby zdefiniować, jaki jest poziom
realizacji wartości przez daną osobę. Jest to bardzo prosty i jednocześnie potężny
mechanizm.

4
Jeśli ktoś Ci powie: „Chce mi się pić”, to jest to mało konkretna informacja. Najczęściej
zakłada się, że ktoś koniecznie potrzebuje się napić w tym momencie. Jednak rzeczywi-
stość nie jest zero-jedynkowa. Jeśli chciałbyś być precyzyjniejszy i lepiej zrozumieć,
w jakiej sytuacji jest Twój rozmówca, możesz poprosić go o określenie poziomu pra-
gnienia w skali od –10 do 10, gdzie –10 oznacza, że w ogóle nie chce mu się pić, a 10 — że
jest w stanie zrobić niemal wszystko, żeby się napić. Wtedy zdasz sobie sprawę, że to
samo stwierdzenie może w efekcie oznaczać za jednym razem poziom 3, a za innym
razem poziom 9.
Kiedy sam stwierdzasz, że jesteś zdemotywowany, zmęczony, zaniepokojony, lub ktoś
Ci mówi, że tak się czuje, dopiero liczbowe określenie poziomu daje bardziej wiary-
godny obraz sytuacji. Przy czym warto pamiętać, że wspomniana skala jest wirtualna
i subiektywna. To nie jest matematyka. Zależności pomiędzy wartościami nie muszą
być liniowe i dzisiaj poziom 3 może oznaczać dla danej osoby co innego niż poziom 3
w następnym tygodniu. Dlatego traktuj tę skalę jako narzędzie pomagające rozmawiać
i znajdować rozwiązania, a nie jako narzędzie służące do precyzyjnych pomiarów.
Wracając do wartości i kryteriów, można się posłużyć kwantyfikatorami ilościowymi
w celu wyklarowania sytuacji (rysunek 4.1). Zapytaj: „Gdybyś miał w skali od 0 do 10
określić, jaki jest poziom realizacji tej wartości na dzisiaj, to ile by to było?”. Zero
oznacza całkowity brak realizacji tej wartości, a dziesięć pełną realizację.
Rysunek 4.1. Kwantyfikatory ilościowe
Załóżmy, że usłyszałeś „Trzy”. Następnie zapytaj: „A gdzie chciałbyś się znaleźć na

tej skali? Co by to miało oznaczać?”. I ostatecznie zapytaj: „Co by się musiało wydarzyć,
żebyś mógł się znaleźć w danym miejscu na skali? Co musiałbyś zrobić? Do czego do-
prowadzić? Co miałbyś zmienić w środowisku? Co musiałbyś zmienić w sobie? Czego
musiałbyś się nauczyć?”. W ten sposób szukasz konkretnych sposobów na stworzenie
takich warunków, w których dana osoba będzie zmotywowana.

4
Rysunek 4.2. Notatka zbierająca informacje dotyczące profilu motywacyjnego
Profil motywacyjny
Opisane poprzednio kroki układają się w technikę umożliwiającą stworzenie profilu
motywacyjnego (rysunek 4.2), czyli odnalezienie czynników, które motywują daną
osobę, kryteriów i sposobów, jakimi można zwiększyć jej motywację. Szkielet algo-
rytmu zbudowania profilu przedstawia się następująco:
1. Przypomnij sobie szczegółowo trzy sytuacje z przeszłości, kiedy byłeś zmoty-
wowany.
2. Wypisz wartości, które dawały Ci motywację do działania.
3. Zdefiniuj kryteria — subiektywną definicję każdej wartości.
4. Określ na wirtualnej skali, gdzie jesteś i gdzie chciałbyś być.
5. Poszukaj pomysłów na to, jak dotrzeć do tego miejsca, w którym chciałbyś być.
Jeśli jesteś w sytuacji, w której brakuje Ci motywacji (lub ktoś z Twojego zespołu nie
jest zmotywowany), masz dwie możliwości — spróbować to zmienić albo zmienić
pracę. To drugie rozwiązanie traktowane jest jako ostateczność. Przyjrzyjmy się temu,
na czym może polegać zmiana. Bardzo często w sytuacjach, kiedy czujesz się zdemo-
tywowany, nie dostrzegasz sposobów, jak znaleźć w tym, co robisz, to, co jest dla Ciebie
ważne. Żeby to dostrzec, potrzebne jest:
 spojrzenie z innej perspektywy na sytuację;
 stworzenie pomocniczych celów, dzięki którym będziesz mógł to zrealizować.

4
Przykład
Wspomniany wcześniej lider po kilku latach był w nieco innej sytuacji. Pracował
z zespołem utrzymaniowym, który wykonywał dość powtarzalne, w ocenie członków
zespołu, mało rozwojowe zadania. W dodatku klient, który zlecał zadania, był w in-
nym kraju i lokalny zespół był traktowany z góry przez zleceniodawcę — poziom
współpracy był niewielki, brakowało pola do negocjacji w sytuacjach spornych. Lider
miał poczucie, że się nie rozwija, miał możliwość pracowania z ludźmi, ale nie czuł,
że jest w stanie cokolwiek wnieść do ich rozwoju. Spora część członków zespołu też nie
znajdowała satysfakcji w tym, co robiła.
Razem z tym liderem zaczęliśmy szukać sposobów, jak można wzbogacić pracę jego
i zespołu, aby odnaleźć na nowo pasję w działaniu. W tamtym momencie lider nie reali-
zował swoich wartości — rozwoju i wkładu w rozwój innych. Szukaliśmy pomysłów
na to, jak to zmienić. Zrobiliśmy burzę mózgów i ostatecznie ze wszystkich propozycji
najbardziej odpowiednia wydała się koncepcja, by lider zaczął pracować z zespo-
łem jako coach. Zastosowanie coachingu pomogłoby mu odnaleźć motywacje po-
szczególnych członków zespołu, dzięki czemu w zespole można by było wprowadzić
zmiany w sposobie działania, używanych narzędziach czy w podejściu, tak aby praca
dawała wszystkim dużo więcej satysfakcji niż dotąd. Ponieważ lider nie miał umie-
jętności coachingowych, miał się zastanowić, czy wybierze się na szkolenie z tego te-
matu, czy może odbędzie dłuższy kurs i sam będzie pracował pod opieką coacha. Wraz
z pomysłem pojawiły się nowe możliwości:
 rozwój (nowa kompetencja);
 możliwość zastosowania nowej umiejętności do tego, by wnieść wkład w rozwój
innych osób.
Lider zaczął też tworzyć wizję, jak zespół mógłby funkcjonować po wprowadzonej
zmianie.
Powyższy przykład pokazuje, w jaki sposób można wykorzystać wcześniej przedsta-
wiony model motywacyjny, a w szczególności jak może pomóc znajomość wartości
danej osoby. Zwróć uwagę na to, że nie jest to działanie narzucone z zewnątrz, jest
ono zgodne z daną osobą i to ona samodzielnie poszukuje rozwiązania.
Może się zdarzyć, że nie będziesz miał pomysłów, jak daną wartość zrealizować w kon-
tekście Twojego zespołu czy organizacji. Wtedy możesz wypróbować kilka strategii:
a) daj sobie parę dni, żeby temat popracował (najwięcej pomysłów na temat pracy
przychodzi nam do głowy pod prysznicem);
b) poproś o pomoc kogoś z zewnątrz (np. coacha), kto pomoże znaleźć więcej
pomysłów;
c) zrób burzę mózgów w większym gronie, w czasie której będziecie szukać uspraw-
nień pracy dla całego zespołu.

4
Jak to wpleść w codzienne życie zespołu?

Mogą pojawić się pytania: Tylko jak mam to zrobić w swoim zespole? Jak to zastosować
do innych osób? Czy to nie jest jakaś manipulacja?
Odnosząc się do ostatniego pytania: dużo zależy od tego, jak to zrobisz i w jakim
stopniu uszanujesz to, co jest ważne dla innych osób. Przede wszystkim o motywacji
zawsze rozmawiaj bezpośrednio. Każdemu zależy na tym, aby być zmotywowanym.
Czy znasz kogoś, kto przychodzi do pracy z założeniem, że chce wykonywać coś nie-
angażującego i nieinteresującego? Umów się na rozmowę jeden na jeden i powiedz
mniej więcej coś takiego: Zależy mi na tym, aby każdy w zespole odnajdował to, co jest
dla niego ważne i co motywuje go do pracy. Chcę ci zaproponować, żebyśmy porozma-
wiali o tym, co cię motywuje i co możemy zrobić, żeby stworzyć w zespole odpowiednie
ku temu warunki. Może nie mogę obiecać, że wszystko da się uskutecznić, ale już sama
rozmowa może nas naprowadzić na ciekawe pomysły. Co ty na to?
Tutaj członek zespołu może odpowiedzieć:
a) „OK, porozmawiajmy, zobaczmy, co z tego wyjdzie” — to pozytywny scenariusz,
wtedy po prostu opowiedz, co chciałbyś zrobić (tzn. przedstaw model motywa-
cyjny i powiedz, że chciałbyś przeprowadzić przedstawione powyżej ćwiczenie).
b) „A o czym konkretnie mielibyśmy rozmawiać?” — osoba jest bardziej dociekliwa,
a może nie czuje się bezpiecznie, więc podobnie jak w punkcie a powiedz, co
chciałbyś zrobić.
c) „Nie wiem, czy mam ochotę o tym rozmawiać” — trudniejsza sytuacja, ozna-
czająca, że dana osoba ma obiekcje. Ważne jest, żeby się dowiedzieć, po prostu
o to pytając, np.: „Możesz mi więcej powiedzieć o tym, dlaczego nie masz ochoty
rozmawiać?”. A jeśli masz podejrzenia, skąd może wynikać ta niechęć, najpierw
zajmij się przyczynami tej reakcji, a dopiero później wróć do rozmowy o mo-
tywacji.
Analiza motywatorów
Wcześniej pokazywałem, jak można zbudować profil motywacyjny. Jest to potężne
narzędzie i wymaga dość dużego zaangażowania i czasu. Mimo to namawiam do tego,
abyś przygotował taki profil dla siebie i dla osób w Twoim zespole.
Możesz użyć innego narzędzia, prostszego, choć nieco bardziej powierzchownie ba-
dającego problem — to narzędzie to analiza motywatorów1. Jego konstrukcję poka-
zano na rysunku 4.3.
1
Analiza motywatorów to ćwiczenie stworzone przez Jurgena Appelo pod nazwą Moving motivators
i dostępne pod adresem https://management30.com/product/moving-motivators/.

4
Rysunek 4.3. Analiza motywatorów
ĆWICZENIE 1.
1. Dla najbardziej typowych wartości — status, akceptacja, porządek, wolność,
współpraca, zasady, mistrzostwo, wpływ, poczucie misji, ciekawość — przy-
gotuj karteczki z wizualizacją tych wartości.
2. Karteczki ułóż poziomo w jednym rzędzie; mają być uporządkowane według
subiektywnego odczucia od najbardziej istotnego do mniej istotnego. Kluczo-
wych jest zazwyczaj kilka pierwszych wartości.
3. Następnie przeanalizuj, co znaczą te wartości i co byłoby potrzebne, żeby
zwiększyć ich poziom realizacji.
4. Możesz również wykorzystać wymiar pionowy ustawienia kartek:
a) aby wyrazić poziom realizacji danego motywatora (im wyżej, tym wyższy;
im niżej, tym niższy) — podobny mechanizm jak w przypadku kwantyfi-
katorów ilościowych;
b) aby przeanalizować wpływ zmiany, która dotyczy danej osoby — w jakim
stopniu zmiana wpłynie na realizację motywatorów.
To ćwiczenie możesz wykorzystać w indywidualnej pracy z członkiem zespołu. Równie

dobrze może to być ćwiczenie zespołowe, które pozwoli osobom w jednej grupie lepiej
się poznać i zrozumieć różnice w preferencjach motywacyjnych.
Skupienie
Utrzymanie motywacji to duże wyzwanie w obszarze motywacji. Łatwiej jest wywo-
łać motywację niż ją utrzymać. Główna strategia utrzymania motywacji polega na
sprawieniu, aby temat, którym chcesz się zająć, stał się dla Ciebie ważny, żeby
zajmował znaczącą część Twojej uwagi. Tak! Kluczowe jest tu kryterium ilościowe
— ilość poświęconego czasu ma znaczenie!

4
Co możesz zrobić, aby utrzymywać skupienie, a w efekcie motywację? Oto kilka po-
mysłów do zastosowania w dowolnej kombinacji:
a) ustal zadania, które chcesz wykonać w najbliższym czasie;
b) umów się z kimś, komu będziesz regularnie relacjonował swoje postępy;
c) zobowiąż się wobec znajomych, zespołu, przełożonego;
d) ustal deadline i ogłoś go publicznie;
e) zacznij tworzyć blog, czytać fora na temat, czytać książki, występować na kon-
ferencjach, nawiązując do danego zagadnienia;
f) znajdź innych ludzi, którzy zajmują się danym tematem, i prowadź z nimi dyskusję;
g) znajdź coacha lub mentora.
Ponadto regularnie sprawdzaj postęp swoich prac oraz to, czy Twój cel cały czas jest
aktualny — np. na cotygodniowych indywidualnych retrospekcjach.
Codziennik
Środowisko współczesnych organizacji to wiele konkurencyjnych celów, zadań i prio-
rytetów, w których łatwo się zgubić. Nie zawsze decyzje i działania, które podejmujemy,
są trafione, rzadko jednak wyciągamy z nich wnioski — nie poświęcamy temu uwagi,
gdyż jedno zadanie goni drugie. Popełniamy te same błędy, nie będąc ich świadomi.
Żeby zobaczyć swoje potknięcia, potrzebujemy się zatrzymać i spojrzeć z pespektywy
na to, co się wydarzyło.
Narzędziem, które pomoże ocenić z dystansu to, co się wydarzyło, wyciągnąć wnioski,
a do tego utrzymać skupienie na wybranym celu, może być Codziennik — codzienne
retrospekcje, które są zapisywane w zeszycie, notatniku czy innym narzędziu elek-
tronicznym. Tego typu retrospekcja polega na zadaniu następujących pytań:
1. Co się dzisiaj wydarzyło, co utkwiło mi w głowie?
2. Czego się nauczyłem? Co zrobiłbym inaczej?
3. Co dzisiaj zrobiłem, żeby zrealizować swoje cele?
4. Na jakie pytanie chciałbym znaleźć odpowiedź?
Pierwsze pytanie służy do tego, aby przypomnieć sobie najistotniejsze wydarzenia i mieć
dobrą bazę do wyciągania wniosków.
Drugie pytanie to czas na to, aby wyciągnąć wnioski i podjąć decyzje odnośnie do
sposobu działania. Na przykład może zechcesz zmodyfikować sposób pracy z pocztą
elektroniczną.
Trzecie pytanie ma na celu podtrzymanie skupienia na celach, które sobie postawiłeś,
przypomnienie o nich i szukanie sposobów na zwiększenie szansy ich realizacji.

4
Czwarte pytanie ułatwia szukanie odpowiedzi na nietrywialny problem, na który czę-

sto nie ma prostej recepty. Natomiast samo postawienie pytania pozostawia otwartą pę-
tlę, którą nasz umysł będzie chciał zamknąć, tzn. będzie poszukiwał wskazówek
w tym, co się dzieje na co dzień, pomagających poradzić sobie z danym zagadnieniem.
To ten sam mechanizm, który sprawia, że gdy jesteś w trakcie poszukiwania samo-
chodu do kupienia i już masz upatrzony model, nagle zaczynasz dostrzegać na ulicy
dziesiątki aut tego rodzaju — Twój umysł zaczyna filtrować informacje pod tym kątem.
Tak samo jest z otwartymi pytaniami. Jeśli będziesz je regularnie zadawać, Twój umysł
zacznie wychwytywać te sytuacje, które pozwolą na nie odpowiedzieć.
Kiedyś nurtowało mnie pytanie, czym jest zaufanie w zespole. Odpowiedzi, które znaj-
dowałem w książkach i internecie, nie satysfakcjonowały mnie, dlatego postanowiłem
zadawać sobie to pytanie codziennie. To pytanie powstało w kontekście współpracy
z jednym członkiem zespołu. Miałem wątpliwości, czy dobrze wykonuje swoją pracę
i czy robi to efektywnie. Często się spieraliśmy. Nie miałem do niego pełnego zaufania.
Zgodnie z moim ówczesnym rozumieniem zaufanie polegało na oddaniu autonomii
i decydowania o zadaniach, jednak ta sytuacja nie do końca mi pasowała. Naryso-
wałem sobie sytuację między mną a tą osobą (rysunek 4.4) i zdałem sobie sprawę, że
nasza relacja jest niesymetryczna, że brakuje strzałki w jedną stronę. Zacząłem się
zastanawiać, co by oznaczała taka dorysowana strzałka. Uświadomiłem sobie, że
tym, czego potrzebuję, jest wiedza, jak przebiega realizacja zadania i na podstawie
jakich przesłanek dana osoba podejmuje decyzje. Chodziło mi o to, żeby w naszej
relacji istniało przyzwolenie na zadawanie trudnych pytań. Pełny obraz sytuacji przed-
stawia rysunek 4.5. Żeby całość mogła funkcjonować i być przyjazna dla obu stron,
potrzebne było jeszcze założenie pozytywnej intencji: że członek zespołu wykonuje
swoją pracę w najlepszej możliwej wierze i że ja zadaję pytania, żeby zrozumieć, a nie
żeby się przyczepić. Swoim odkryciem podzieliłem się bezpośrednio z zainteresowa-
nym i zapytałem, czy byłby skłonny wypróbować ten sposób współpracy. Zgodził
się, a nasza relacja zmieniła się na korzyść.
Rysunek 4.4. Na czym polega zaufanie cz. 1

4
Rysunek 4.5. Na czym polega zaufanie cz. 2
Wysoka energia
Motywacja to również pewien poziom energii, który nam towarzyszy. Kiedy brakuje
nam motywacji, zazwyczaj mamy niski poziom energii. I odwrotnie: kiedy jesteśmy
zmotywowani, poziom energii jest wysoki. Z drugiej strony niektóre osoby są bardziej
dynamiczne (ekstrawertycy), a inne mniej (introwertycy). Poziom energii bywa zaraź-
liwy i udziela się członkom zespołu, dlatego czasami warto wzbudzić w sobie dodat-
kowe pokłady energii.
Czy można na to wpłynąć? Jak to zrobić?
Poziom energii jest wyrazem stanu, w jakim jesteś, a na ten z kolei składają się nastę-
pujące elementy:
 fizjologia — jak się poruszasz, czy w ogóle się poruszasz, jak bardzo żwawy
jest ten ruch;
 to, na czym się skupiasz — na co zwracasz uwagę, co wychwytujesz z tego, co
się dzieje dookoła Ciebie;
 używane słownictwo — w jaki sposób etykietujesz to, co się dzieje; czy uży-
wasz słów, które budzą pozytywne emocje; czy wymawiasz je z pozytywną
intonacją.
Godzina mocy
Poniższe ćwiczenie2 pozwoli Ci wygenerować wysoki stan energetyczny poprzez wpływ
na wszystkie składniki stanu psychofizycznego. Najlepiej wykonywać je rano.
2
Ćwiczenie w postaci audio w języku angielskim możesz znaleźć w internecie, wpisując hasło Hour
of Power.

4
ĆWICZENIE 2.
1. Zacznij dzień od ruchu. Energicznie wstań z łóżka. Zrób krótki i szybki spacer.
2. Wykonuj energiczne wdechy i wydechy w rytmie: 4 krótkie wdechy, a po nich
4 krótkie wydechy. Jeśli połączysz to ze spacerem lub biegiem, efekt będzie
zwielokrotniony. W ten sposób wpływasz na swoją fizjologię.
3. Zastanów się nad tym, z czego jesteś zadowolony w kontekście rodziny, pracy,
toczących się projektów, zainteresowań. W ten sposób skupiasz się na tym, co
jest pozytywne w Twoim życiu, a to doda Ci energii.
4. Stwórz inkantację — zdanie, które chciałbyś zinternalizować, które mogłoby
być Twoją wizytówką. Powtarzaj je z dużą energią, na głos, z emocjami, które
są związane z tym zdaniem. Zdanie może brzmieć: „Potrafię rozwiązać każdy
problem!”, „Z każdym dniem jestem coraz bliżej swoich celów”. Zdanie należy
wypowiadać rytmicznie. W ten sposób używasz słownictwa, które dodaje ci
energii.
Czynniki motywacyjne i higieniczne

A co z pieniędzmi? Ich temat budzi emocje i rodzi pytanie, czy motywują, czy też nie.
Otóż pieniądze motywują głównie w sposób negatywny, tzn. demotywują, kiedy ich
poziom jest zbyt niski w odniesieniu do oczekiwań (np. stawek rynkowych, posiada-
nych kompetencji, potrzeb życiowych) — rysunek 4.6. Ponadto każdy z nas ma mental-
ny poziom przychodów, który zaspokaja kluczowe potrzeby, i dalszy wzrost wyna-
grodzenia nie przyczynia się znacząco do wzrostu motywacji, a jeśli on występuje,
jest tymczasowy.
Rysunek 4.6. Pieniądze głównie demotywują,

jeśli ich poziom nie pozwala zaspokoić kluczowych potrzeb
Szereg badań pokazuje, że pieniądze w sposób pozytywny wpływają na efektywność

pracy tylko w przypadku zadań nieskomplikowanych, które nie wymagają wykorzy-
stania umiejętności poznawczych.

4
Tutaj warto przytoczyć dwuskładnikową teorię motywacji, która dzieli rzeczy moty-
wujące na dwie grupy: motywatory i czynniki higieniczne. Motywatory zwiększają
motywację i zalicza się do nich:
 pracę stanowiącą wyzwanie,
 osiągnięcia,
 rozwój osobisty,
 uznanie,
 odpowiedzialność.
Jak widać, są to omawiane wcześniej wartości.
Czynniki higieniczne to te składniki, które przyczyniają się do zmniejszenia motywacji,
kiedy ich poziom jest niewystarczający w subiektywnym odczuciu danej osoby, i zali-
czamy do nich:
 bezpieczeństwo pracy,
 wynagrodzenie,
 status,
 warunki pracy,
 zasady panujące w firmie,
 świadczenia.
Jeśli pełnisz funkcję lidera, warto, byś miał świadomość tego rozróżnienia, abyś lepiej
rozumiał, z czego może wynikać ewentualny aktualny poziom motywacji osób w Twoim
zespole.
Co motywuje programistów?
Do tej pory opisywałem koncepcje związane z motywacją, które są dość uniwersalne.
A jak to się wszystko ma do programistów, którzy tworzą swego rodzaju zawodową
subkulturę? Praca nad projektami programistycznymi wymaga dużej kreatywności,
znajomości wielu szczegółowych zagadnień technicznych (jak np. języki, technolo-
gie, bazy danych, wydajność, bezpieczeństwo) i ciągłego pogłębiania swojej wiedzy.
Nie jest to praca dla wszystkich, dlatego też przyciąga osoby pewnego typu — raczej
introwertyczne, analityczne, o dużych umiejętnościach uczenia się. Poniżej znajdziesz
przykładowe wypowiedzi programistów, którzy mówią o tym, co ich motywuje.
Robię coś, z czego korzystają inni, coś, co ułatwia innym pracę.
Mój produkt jest rozpoznawalny.
Słyszę słowa uznania od osób spoza zespołu, które biorą udział w projekcie.
Klienci lub użytkownicy mówią mi „Dziękuję”.

4
Oprogramowanie, które jest tworzone w ramach projektów programistycznych, jest

częścią większych przedsięwzięć. Świadomość, że oprogramowanie przyspieszy dzie-
sięciokrotnie generowanie raportu, pozwoli zaplanować podróż komunikacją miejską,
wystawić przedmiot na aukcji, umożliwi wirtualne zwiedzanie muzeum lub znajdzie
się jako jedna z funkcjonalności w telefonie, nadaje sens wykonywanej pracy. W niektó-
rych projektach wytwarzana wartość jest oczywista, w innych jest mniej jasna, więc
ważne jest, żeby ją uwypuklić.
Cztery godziny mijają tak, jakby to było 10 minut.
Programowanie to rodzaj pracy, który pochłania w naturalny sposób — i jest to na-
groda sama w sobie. Warto zadbać o to, aby tego stanu skupienia zbyt często nie za-
kłócać, co w efekcie może negatywnie wpływać na efektywność pracy.
Jestem traktowany jak człowiek, a nie jak zasób.
Brak stałych zespołów, połowa czasu w jednym projekcie, a połowa w drugim, prze-
rzucanie zadań między działami, brak informacji zwrotnej, skupienie wyłącznie na za-
daniach — to kilka sposobów mogących doprowadzić pracowników do odczucia, że
są traktowani jak zasób.
Mogę rozwijać swoje umiejętności techniczne i nietechniczne, mogę się uczyć,
mogę używać najnowszych technologii.
Nowe technologie, nowe narzędzia i ogrom wiedzy związanej z IT sprawiają, że
uczenie się jest integralną częścią pracy programistycznej. Przeradza się to w rodzaj
uzależnienia od konieczności bycia na czasie. Liderzy mają szczególnie trudne zadanie
w sytuacjach, kiedy projekt nie jest rozwojowy i polega np. na utrzymywaniu kilku-
letniego systemu. W takich przypadkach należy znaleźć sposób, jak członkowie ze-
społu mogliby się cały czas rozwijać. Zaniedbanie tego obszaru najczęściej prowadzi
do dużej rotacji.
Znajduję rozwiązania trudnych problemów, dostaję zaufanie w krytycznych
sytuacjach.
Wiele problemów technicznych jest niebanalnych i wymaga stworzenia rozwiązań,
do których konieczne są ponadprzeciętna wiedza i doświadczenie. To daje ogromną
satysfakcję z wykonanej pracy.
Złam wszelkie zasady

Często wydaje się, że stworzenie warunków, w których będzie się można czuć zmo-
tywowanym, wymaga dużego wysiłku, tymczasem wcale tak nie musi być. Instytut
Gallupa przez wiele lat prowadził badania dotyczące zaangażowania i motywacji pra-
cowników w środowisku pracy3. Jeden z kluczowych wniosków, które płynęły z tego
3
Marcus Buckingham, Curt Coffman, Po pierwsze: Złam wszelkie zasady, MT Biznes, Warszawa 2011.

4
badania, był następujący: pracownicy głównie odchodzą z firm z powodu napiętej

relacji z przełożonym oraz braku informacji zwrotnej na temat swojej pracy. To po-
kazuje, jak istotna może być rola lidera, szczególnie jeśli ten będzie umiał budować
zdrowe relacje z członkami zespołu i będzie udzielał konstruktywnych informacji
zwrotnych.
Instytut Gallupa zidentyfikował 12 kluczowych czynników, które mogą sprawić, że
pracownicy będą bardziej zaangażowani w pracę. Te czynniki mogą być dobrą bazą
do przeprowadzenia dyskusji w zespole. Dla lidera stanowią przypomnienie o działa-
niach, które często nie wymagają zbyt dużego wysiłku, a o których łatwo jest zapo-
mnieć. Poniżej znajduje się ich lista.
1. Wiem, czego się ode mnie oczekuje.
2. Mam materiały i sprzęt, które umożliwiają mi rzetelne wykonywanie pracy.
3. Mam możliwość robienia tego, co potrafię najlepiej.
4. W ciągu ostatnich siedmiu dni otrzymałem słowa uznania lub pochwałę w związ-
ku z wykonaną pracą.
5. Mój przełożony lub inna osoba z organizacji interesuje się mną jako człowiekiem.
6. Jest ktoś w organizacji, kto zachęca mnie do rozwoju.
7. Moje opinie w pracy zdają się być brane pod uwagę.
8. Misja lub cel działania firmy sprawia, że postrzegam swoją pracę jako ważną.
9. Osoby, z którymi współpracuję, z zaangażowaniem wykonują swoją pracę,
zachowując wysoką jej jakość.
10. Mam najlepszego przyjaciela w pracy.
11. W ciągu ostatnich sześciu miesięcy ktoś rozmawiał ze mną o moich postępach.
12. W ciągu ostatniego roku miałem możliwość rozwijania się lub nauczenia się cze-
goś nowego.
Prawda, że nie jest to nic skomplikowanego? Część z tych punktów wymaga jedynie
uważności. Przynajmniej raz w miesiącu wracaj do tej listy, weryfikując podejmowane
działania w tym obszarze.
Drive
Trudno byłoby mówić o motywacji i pominąć książkę Drive Daniela Pinka. Warto
znać przedstawioną w niej koncepcję, która może być przydatna w kontekście budo-
wania angażującego środowiska.
Główna teza książki pokrywa się z przedstawionym już wcześniej założeniem, że
motywowanie z użyciem kar i nagród zazwyczaj nie sprawdza się w przypadku, kiedy
mamy do czynienia z zadaniami wymagającymi umiejętności poznawczych. Prze-
prowadzono wiele eksperymentów, w czasie których uczestnicy dostawali do wyko-

4
nania zadania wymagające wysiłku intelektualnego i najlepsi mieli być nagrodzeni.

Okazywało się, że wizja nagrody powodowała, że uczestnicy wolniej rozwiązywali
swoje zadania lub popełniali więcej błędów. Natomiast jeśli zadania wymagały wykorzy-
stania mechanicznych umiejętności i podążania za instrukcjami, schemat kar i nagród
się sprawdzał.
Daniel Pink, powołując się na liczne badania w obszarze psychologii, socjologii
i ekonomii, przekonuje, że powinniśmy się odwoływać do motywacji wewnętrznej,
a ta jest najsilniejsza, kiedy pracownicy mogą samodzielnie podejmować decyzje od-
nośnie do sposobu wykonania swoich zadań i wpływać na to, co się wokół nich dzieje,
mogą rozwijać swoje kompetencje oraz mają poczucie większego celu, co autor sprowadza
do trzech głównych wartości: autonomii, mistrzostwa i poczucia sensu swojej pracy.
Autonomia
Oznacza przede wszystkim możliwość wpływania na sposób realizacji zadań, sposób
funkcjonowania zespołu oraz przebieg projektu. Nie jest synonimem działania w poje-
dynkę, ale równowagi pomiędzy tym, jak wykonuje się swoją pracę, a tym, jak przebiega
współpraca z innymi. Autonomia jest promowana w podejściach zwinnych w tworzeniu
oprogramowania (agile methods), gdzie zespoły samoorganizują się, co znaczy, że
członkowie zespołu wspólnie decydują o tym, jak zrealizują postawiony przed nimi cel.
Sposób organizacji pracy zespołu nie jest narzucony z zewnątrz. Autonomia może
również oznaczać możliwość decydowania o swoim czasie pracy w zadanych granicach
— w wielu firmach można przyjść o dowolnej godzinie do pracy, pod warunkiem że
jest się dostępnym w godzinach 9.00 – 15.00.
Mistrzostwo
Dlaczego ludzie poświęcają swój czas, żeby rozwijać oprogramowanie open source,
udzielać się na forach i tworzyć Wikipedię? Przecież nikt im za to nie płaci, a często
są to specjaliści w swojej dziedzinie. Dzieje się tak dlatego, że dzięki temu mogą wy-
korzystać jeszcze lepiej swoją wiedzę i umiejętności oraz mogą rozwijać swoje kom-
petencje. Mogą poprawić swoje CV i mieć wkład w realizację większego celu. Pink na-
zywa tę potrzebę mistrzostwem.
Większy cel
Celem organizacji komercyjnych jest zarabianie pieniędzy, a większość firm progra-
mistycznych to organizacje komercyjne. Kiedy jednak wypracowanie zysku finansowe-
go staje się jedynym punktem skupienia wszystkich wysiłków lub wszystkie działania
są mu podporządkowane, prowadzi to zazwyczaj do wypaczenia zasad i wartości,
które są wyznawane w firmie. Przykładem może być zdobywanie certyfikatów jako-

4
ściowych przez firmy, co powinno służyć uwiarygodnieniu się przed klientami. Tym-
czasem często sprowadza się to do przygotowania organizacji na audyt, tak aby uzyskać
pozytywną ocenę. Zatem szczytna idea podążania za jakością zostaje zaprzepaszczona.
Ludzie muszą mieć poczucie, że większy cel, na którym rzeczywiście zależy organizacji,
jest autentyczny i nie sprowadza się tylko do uzyskania jak największych przychodów
czy odpowiedniego certyfikatu. Chcą mieć poczucie, że są częścią czegoś większego.
Tak jak w pewnej historii. Dawno temu przez jeden z krajów przechadzał się wędrowiec
i na swojej drodze spotkał człowieka, który łupał kamienie.
— Co robisz? — zapytał wędrowiec.
— Jak to co? — odpowiedział zdziwiony robotnik. — Przecież widać, że łupię kamienie.
— Ach. Nie o to mi chodziło. Powiedz mi, dlaczego łupiesz te kamienie?
— Wiesz, mam żonę, dwójkę dzieci i muszę ich jakoś wyżywić.
— Aha. To już wiem trochę więcej, ale tak naprawdę chciałem się dowiedzieć, po co
łupiesz te kamienie.
— A, o to pytasz! — powiedział robotnik, wyprostował się i odparł z dumą. — Buduję
katedrę.
Codzienna praca jest żmudna i pełna wyzwań — czasami przypomina łupanie kamie-
ni. Tylko możliwość odniesienia tego, co robimy, do czegoś większego, nadaje jej sens.
Dlatego warto dbać o to, aby członkowie zespołu mieli świadomość większego celu,
do którego dążą.
Elementy angażującego środowiska

W poprzednim podrozdziale opisałem trzy czynniki, które istotnie wpływają na
motywację w pracy, i zapewne pojawia się teraz pytanie, w jaki sposób przełożyć to
na praktykę i jakie działania można podjąć, aby zwiększyć szansę na to, że środowisko
będzie sprzyjało budowaniu zaangażowania. Poniżej znajdziesz wiele pomysłów w każ-
dym obszarze. Opisuję tu różne praktyki, które z powodzeniem są stosowane w róż-
nych firmach. Należy je traktować jako zbiór inspiracji w poszukiwaniu pomysłów.
Autonomia
Slack time
Dawaj możliwość rozwoju (np. cztery godziny w tygodniu, jeden dzień w miesiącu):
czas, w którym można wykonywać pracę niezwiązaną z projektem. Temu tematowi
został poświęcony osobny punkt tego rozdziału.

4
Zaproszenie do współdecydowania
Często liderzy mają poczucie, że to oni muszą wymyślić rozwiązanie problemu i podjąć
decyzję, gdy tymczasem można to zrobić razem z całym zespołem lub przynajmniej
się skonsultować.
Zespołowe retrospekcje
Retrospekcje umożliwiają całemu zespołowi wyciągnięcie wniosków z tego, co się
działo, i zaproponowanie zmiany. Dbaj o to, aby się odbywały i aby zmiany były
wprowadzane w życie.
Samozarządzający się zespół

W świecie biznesu coraz częściej się mówi o samozarządzających się zespołach, a w meto-
dykach zwinnych jest to jedna z podstawowych zasad — członkowie zespołu decydują,
w jaki sposób osiągną postawiony przed nimi cel.
Wspólne planowanie
Częstą praktyką tradycyjnego kierownika zespołu jest wydzielanie zadań, ich osza-
cowywanie oraz rozdzielanie między członków zespołu. Dlaczego zespół nie miałby
robić tego sam?
Organizacja zadań w modelu pull

W modelu push to kierownik rozdziela zadania, w modelu pull członek zespołu wy-
biera swoje zadanie, mając na uwadze projektowe priorytety. To zwiększa poczucie
identyfikacji z zadaniem.
Podejście coachingowe
Niewiele osób, a już szczególnie specjalistów, lubi, gdy podaje się im gotowe rozwiąza-
nia. Naucz się pracować w stylu coachingowym, byś używając pytań, mógł stymulować
członków zespołu do samodzielnego poszukiwania pomysłów.
Rejestr usprawnień
Wprowadź kulturę pracy, w której są mile widziane wszelkie pomysły na temat
usprawnień. Możesz wprowadzić rejestr — tablicę, pudełko, wiki, gdzie można zgła-
szać pomysły, które będą omawiane na retrospekcji.
Elastyczny czas pracy

Czy wszyscy muszą być o ósmej rano w pracy? Osoby, które mają rodziny i dzieci,
często rano mają dużo obowiązków i może to być dla nich bardzo niewygodny wymóg.
Być może ktoś chciałby regularnie chodzić na zajęcia jogi, które odbywają się o siódmej
trzydzieści rano i są w bardzo dobrej cenie. Określ czas, w którym wszyscy powinni
być, i jeśli trzeba, ustal formę informowania o swojej dostępności. Daj członkom ze-
społu możliwość decydowania o godzinach przebywania w biurze.

4
Mistrzostwo
Narzędzia mentalne i refaktoryzacja

W profesji programisty dużo czasu poświęca się dobrym praktykom, co objawia się
chociażby poprzez ruch Software Craftsmanship4. Umożliwiaj programistom stoso-
wanie tych praktyk, a będą mieli poczucie, że są profesjonalistami.
Praca parami
Praca w parze bardziej stymuluje do kreatywności i do wychodzenia poza utarte
schematy niż praca w pojedynkę. Poza tym jest to jedna z lepszych form rozpo-
wszechniania wiedzy. Praca parami nie musi oznaczać ciągłego działania w ten sposób,
a jedynie współdziałanie w wybranych momentach, np. w czasie wymyślania koncepcji,
planowania i podsumowania prac.
Hackaton
Hackaton to coraz bardziej popularna forma integracji i energetyzacji zespołów pro-
gramistycznych zaczerpnięta z praktyk społecznościowych. Grupa osób z danej fir-
my przez dzień lub dwa pracuje nad wymyślonym projektem według określonych
zasad (np. stosując technikę Test-Driven Development).
Robimy coś więcej niż standard

W jednym ze swoich zespołów zainicjowałem kiedyś dobrowolne ćwiczenia rozcią-
gające odbywające się na dziedzińcu budynku, w którym pracowaliśmy. Po kilku ty-
godniach w ćwiczeniach uczestniczyły również osoby z innych działów. Wymyśl coś,
o czym osoby w Twoim zespole będą mogły opowiadać swoim znajomym.
Wymiana wiedzy
Organizuj szkolenia wewnętrzne, w czasie których członkowie zespołu będą się dzie-
lić nabytymi umiejętnościami lub poznanymi narzędziami. Tematem takich spotkań
może być również hack tygodnia — nietypowe rozwiązanie trudnych problemów.
Tworzenie bazy wiedzy

Na wiki stwórzcie bazę dobrych praktyk związanych z technologią, językiem, pro-
jektem, narzędziami, współpracą z klientem.
Wychodzenie poza swoją specjalizację

Wprowadź roszady między różnymi specjalizacjami: niech programista przez tydzień
będzie testerem i odwrotnie — niech tester przez tydzień wykonuje prace programisty.
4
Software Craftsmanship — ruch promujący stosowanie dobrych praktyk, takich jak Test-Driven
Development, czy zasad czystego kodu w tworzeniu oprogramowania jako przejawu profesjonalizmu.

4
Blog zespołowy, konferencje

Jeśli w zespole masz pasjonatów programowania, którzy lubią się dzielić swoją wiedzą,
stymuluj ich do współtworzenia bloga zespołu i do występowania na konferencjach.
Wewnętrzny plan rozwoju

Ustalajcie cele związane z rozwojem i regularnie je weryfikujcie.
Bycie mentorem lub coachem

Osoby, które lubią się dzielić swoją wiedzą, mogą chcieć pełnić funkcję mentora lub
coacha. Dzięki temu zespół będzie się rozwijał, a oni będą mogli realizować swoją
istotną potrzebę.
Większy cel
Przypominanie wizji
Dbaj o to, aby cały czas przypominać wizję odnośnie do produktu, który rozwijacie.
Często się zapomina o wizji wraz z upływem czasu pracy nad produktem.
Cel ortogonalny
Bez względu na to, jaki jest cel związany z produktem, warto w zespole utrzymywać
cel ortogonalny, czyli cel dodatkowy, do którego chce dążyć cały zespół. Przykładem
takiego celu jest dążenie do doskonałości technicznej (w programowaniu może to
być wprowadzanie praktyk związanych z Software Craftsmanship).
Świętowanie
Po zakończonym wydaniu znajdź sposób, aby świętować finalizację danego etapu prac.
Tym samym członkowie zespołu będą mieli odczucie, że udało się wykonać pewną
część prac, a przy okazji będą mogli się lepiej zintegrować.
Wizualizacje
W codziennej pracy łatwo zapomnieć o szerszym kontekście. W pokoju zespołu umieść
wizualizacje związane z realizowanym projektem: wizję produktu, mapę architektury,
fragmenty projektu, zrzuty ekranowe, zdjęcia użytkowników.
Pokaż, jak klienci używają produktu

Jednym z głównych motywatorów jest świadomość, że ktoś używa produktu. Zorga-
nizuj wycieczkę do klienta lub nagranie filmu, tak aby członkowie zespołu mogli zo-
baczyć, jak produkt jest używany.

4
Cele sprintu, iteracji i wydania

Dbaj o to, aby cele zawsze były zdefiniowane i żeby były konkretne. Cel jest ważniej-
szy niż realizacja poszczególnych zadań. I nawet jeśli nie wszystkie zadania zostaną
zrealizowane, a cel mimo to będzie osiągnięty, zespół osiągnie sukces. Unikaj celów
w rodzaju: naprawić błędy, zwiększyć usability — one nie dają wytycznych, które
umożliwiają podejmowanie decyzji.
Współuczestniczenie w rozwoju produktu

Zespoły techniczne często sprowadzane są do roli wykonawców i choć same chętnie
przystają na taką rolę, to ta sytuacja sprzyja postawie nieidentyfikowania się z wizją
rozwoju produktu. Zaangażuj członków zespołu w spotkania, podczas których decy-
duje się dalszy rozwój produktu.
Slack
Na koniec przyjrzymy się tematowi, który został wcześniej wspomniany w kontekście
autonomii — koncepcja wolnego czasu (slack time). Dość kontrowersyjnym pomysłem
wydaje się dawanie kilku godzin w tygodniu do wykorzystania na uczenie się lub
wykonywanie dowolnego projektu. Ten koncept został bardziej szczegółowo opisany
w książce Toma DeMarco o tytule Slack, a Google było jednym z prekursorów tego
podejścia. Podstawowy problem polega na tym, że dość często w kontekście bizne-
sowym mylimy wydajność z efektywnością. Organizacje i ich menedżerowie robią
wszystko, aby w pełni wykorzystać czterdziestogodzinny tydzień pracy i wypełnić go
po brzegi zadaniami. Tymczasem wysoka wydajność stoi w opozycji do kreatywności.
Kiedy czas jest w pełni wykorzystany, nie ma miejsca na nowe pomysły, na planowanie
oraz na rozwijanie wiedzy i umiejętności, co w efekcie powoduje wypalenie i demo-
tywację pracowników. Dlatego istotne jest, żeby stwarzać przestrzeń, zasoby czasowe,
aby uwalniać kreatywność niezbędną w pracy nad projektami programistycznymi.
Rozważ zatem i przedyskutuj ze swoim przełożonym wartość i możliwość realizacji
takiego podejścia.
Podsumowanie
Nie można nikogo trwale zmotywować, używając zewnętrznego oddziaływania. Praw-
dziwa motywacja pochodzi z wewnątrz, a jej wyrazem są preferowane przez daną
osobę wartości. Jako lider powinieneś się starać zrozumieć, jakie wartości są kluczowe
dla członków zespołu, i możesz do tego użyć procesu tworzenia profilu motywacyj-
nego lub ćwiczenia analizy motywatorów, a później razem z zainteresowaną osobą szu-
kać wspólnie sposobów na zwiększenie atrakcyjności środowiska pracy. Nie mniej
ważne są uniwersalne zasady, o których przypomina lista pytań przygotowana przez
Instytut Gallupa — korzystaj z niej regularnie, a zwiększysz szansę na to, że będziesz
miał zmotywowany zespół.

4
Buduj środowisko, które wspiera zaangażowanie, w którym można realizować takie

wartości, jak: autonomia, mistrzostwo i większy cel. Zaproś zespół do współdecydowa-
nia, przeprowadzaj regularne retrospekcje, zapewniaj możliwość uczenia się i wy-
miany wiedzy, wprowadzaj do pracy zespołu eksperymentalne praktyki, a to z pew-
nością przyniesie duże ożywienie.
Rozważ wprowadzenie wolnego czasu, który będzie poświęcony na działania niepo-
wiązane ściśle z celami projektu, ale dające możliwość odświeżenia codziennej pracy.

4

4

4
Rozdział 5.
PRACA Z ZESPOŁEM
Zmieniła się Twoja rola. Z eksperta stałeś się liderem. Teraz kluczowy jest dla Ciebie
zespół i osiągane przez niego cele. Dla dużej części liderów technicznych praca z ze-
społem jest najtrudniejszą częścią nowej roli. Dzieje się tak m.in. dlatego, że to, co się
świetnie sprawdzało przy zadaniach eksperckich, w przypadku pracy z zespołem może
nie zadziałać. W tym obszarze brakuje zero-jedynkowych reguł, które zagwarantowały-
by sukces, nie ma procedur, które dadzą pewność, że uda się stworzyć zespół marzeń.
Żeby to lepiej zrozumieć, przyjrzyjmy się modelowi Cynefin.
Model Cynefin
Główna myśl modelu Cynefin jest następująca: zagadnienia, z którymi mamy do czy-
nienia, nie są sobie równe i można je podzielić ze względu na ich złożoność (rysunek
5.1). Każdej tego typu kategorii będą odpowiadać inne sposoby działania. Bazą podziału
na kategorie jest zależność między przyczyną a skutkiem przez nią wywołanym. Wyróż-
nia się w ten sposób cztery obszary złożoności problemów (systemów):
 Proste (simple) — to systemy, w których jednoznacznie można powiązać przy-
czynę ze skutkiem. Do tego obszaru należą dobrze rozpoznane, opisane dzie-
dziny problemowe, gdzie dostępna jest wiedza, gdzie występujące problemy nie
wymagają złożonej interpretacji czy doświadczenia. Jeśli właśnie nabyłeś nowy
telefon i chcesz go skonfigurować na bazie podręcznika użytkownika, to masz
do czynienia z dziedziną prostą (jeśli podręcznik użytkownika rzeczywiście
wystarczy). W tym obszarze lokują się wszelkie receptury, najlepsze strategie
oraz modele, które można bezpośrednio zastosować w praktyce mimo braku
wcześniejszego doświadczenia.

4
 Skomplikowane (complicated) — są to systemy, w których istnieje powiązanie

między przyczyną a skutkiem, ale nie jest ono proste do wykrycia. Znalezienie
rozwiązania problemu wymaga wiedzy eksperckiej, dużego doświadczenia oraz
złożonej analizy. Ponadto system tego typu jest statyczny lub przynajmniej mało
zmienny (zmienność można przewidzieć i przeanalizować). Przykładami takiego
systemu mogą być: zegarek, samochód, dom. Są one mało zmienne, ale żeby
je wymyślić, naprawić lub rozwiązać problem z nimi związany, potrzebna jest
wiedza ekspercka.
 Złożone (complex) — są to systemy, w których nie ma jednoznacznych powią-
zań między przyczyną a skutkiem — można je wykryć poprzez eksperymenty
i analizowanie obecnego stanu rzeczy. Wiedza ekspercka nie jest wystarczająca,
aby znaleźć rozwiązanie problemu. Potrzebna jest ciągła analiza efektów po-
dejmowanych działań. System tego typu to system żywy, organiczny, zmienny
w czasie. Zazwyczaj tam, gdzie mamy do czynienia z ludźmi, stykamy się z sys-
temami złożonymi. Systemy złożone to także: giełda, mózg, układ odpornościowy,
społeczności.
 Chaotyczne (chaotic) — są to systemy, w których brakuje powiązań między przy-
czyną a skutkiem. Wszelkie sytuacje alarmowe, pożary, katastrofy są przykła-
dami takich systemów.
 Nieporządek (disorder) — to sytuacja, w której nie jesteśmy w stanie określić,
z jakiego typu systemem mamy do czynienia.
Rysunek 5.1. Model Cynefin
Zadania techniczne zazwyczaj lądują w kategorii problemów prostych i skomplikowa-

nych, zaś praca z zespołem mieści się w kategoriach problemów złożonych. W przy-
padku zadań technicznych wystarczy solidna wiedza i odrobina doświadczenia, aby

4
Rozdział 5. Praca z zespołem 71
osiągać sukcesy — dlatego już po kilku miesiącach nauki można zacząć programować.
Z kolei w sytuacji pracy z zespołem wiedza i doświadczenie nie dają gwarancji sukcesu
— dopiero eksperymentowanie, dostosowywanie sposobu działania, wyciąganie
wniosków z popełnianych błędów mogą nas zbliżyć do sukcesu.
Dlatego pracując z zespołem, bądź cierpliwy i nie zrażaj się pierwszymi niepowodze-
niami. Zmieniaj sposób działania, testuj różne strategie i narzędzia i szukaj takich,
które najlepiej się sprawdzają w Twoich warunkach. W tym rozdziale znajdziesz kilka
narzędzi i procesów, które pozwalają zrozumieć zasady funkcjonowania zespołów.
Oczekiwania i reguły
Przypomnę tu moją niegdysiejszą rozmowę z liderem jednego z zespołów. Zaczął tak:
— Chciałbym, żeby członkowie mojego zespołu po wymyśleniu rozwiązania
przychodzili do mnie, żeby je przedyskutować, a tego nie robią…
— A czy prosiłeś ich o to, żeby tak robili?
— Nie…
Być może ten przykład wydaje się banalny, ale bardzo dobrze obrazuje powszechny
problem: liderzy nie komunikują zespołowi, czego by chcieli, a później są rozczaro-
wani, że to się nie dzieje. Warto zadbać o to, aby wszyscy w zespole poznali wzajemnie
swoje oczekiwania i na tej podstawie wypracowali wspólne reguły pracy.
Zorganizuj spotkanie, na którym każdy będzie miał okazję przedstawić swoje ocze-
kiwania. Jego przebieg może wyglądać następująco:
1. Każda osoba dostaje kilkanaście karteczek samoprzylepnych oraz długopis.
Na karteczkach zapisuje, czego by oczekiwała od innych w trakcie pracy. Jedno
oczekiwanie — jedna karteczka.
2. Po kolei każda osoba przedstawia to, co zapisała na kartkach, i przykleja je na
flipcharcie.
3. Cały zespół wyodrębnia wspólne i indywidualne tematy.
4. Każdy temat jest dyskutowany w zespole — rozważa się, czy i jakie zmiany
mają być wprowadzone.
5. Ustalenia z punktu 4. są zapisywane na osobnej dużej kartce.
6. Lider z zespołem uzgadnia, w jaki sposób będzie następować weryfikacja, czy
ustalenia rzeczywiście funkcjonują.
Reguły mogą dotyczyć np. odpowiedzi na pytania „Co robimy, gdy…:
 …czegoś nie rozumiemy lub nie wiemy?
 …nie mamy jasnych informacji?
 …nie zgadzamy się z czyimś pomysłem?

4
 …prawdopodobnie nie zdążymy z wykonaniem zadania?

 …spóźnimy się?
 …pojawi się konflikt?”.
Fazy rozwoju grupy

Zespół żyje, podlega dynamicznym zmianom, które mogą być spowodowane przez
korekty w założeniach biznesowych, w składzie osobowym reprezentantów klienta czy
wreszcie w wewnętrznej strukturze i składzie zespołu technicznego. Tutaj przyjrzę
się bliżej tym ostatnim czynnikom. W tym celu wykorzystam model Tuckmana, który
próbuje wyjaśnić proces rozwoju grupy osób (w tym także zespołów). W tym modelu
wyróżnia się cztery fazy (rysunek 5.2):
 Formowania (forming) — członkowie zespołu poznają się, dowiadują się, na
czym polega cel, który mają zrealizować, badają relacje w zespole, zapoznają
się z procedurami czy bazowym procesem wytwarzania.
 Docierania (storming) — jest to faza, która się uaktywnia, gdy:
 zespół lub poszczególni członkowie podlegają pewnej presji (np. zbliżającego
się terminu, sprzecznych oczekiwań, pociągnięcia do odpowiedzialności);
 to, co się dzieje, jest wyraźnie sprzeczne z przekonaniami osób w zespole
lub pojawiają się różne interpretacje zaistniałej sytuacji (np. odpowiedzial-
ności ról).
Rysunek 5.2. Model Tuckmana rozwoju grup
Jest to faza narastającego konfliktu, który powinien być rozwiązany.

 Normowania (norming) — zostają wypracowane wspólne zasady i rozwiązuje
się kluczowe konflikty; powstaje konsensus odnośnie do ról i odpowiedzialności;
członkowie zespołu zaczynają działać jako jedność; w zespole pojawia się otwartość
i bezpośrednie rozmowy o tym, co się dzieje w projekcie.
 Realizacji (performing) — proces, narzędzia, role i odpowiedzialności stają się
drugoplanowe; celem staje się efektywna praca zespołu jako całości.

4
Każda z tych faz wymaga nieco innego sposobu działania i zaangażowania ze strony
lidera, co przedstawia tabela 5.1.
Tabela 5.1. Sposoby działania w zależności od fazy procesu grupowego
Faza Zadania lidera

Formowanie Ustalenie struktury zespołu.
Jasne przedstawienie celów.
Prowadzenie i egzekwowanie procesu.
Pomoc we współpracy.
Docieranie Uwypuklanie i rozwiązywanie konfliktów.
Praca z pojedynczymi osobami nad ich efektywnością.
Wsparcie w doskonaleniu sposobu działania.
Normowanie Pomoc w ustaleniu norm.
Wsparcie w doskonaleniu praktyk technicznych.
Wsparcie w efektywnej komunikacji między członkami zespołu.
Wspieranie myślenia o zespole jako całości — w pierwszej kolejności
promowanie dobra zespołu.
Realizacja Eliminowanie dysfunkcji zespołu.
Wspieranie samoorganizacji zespołu.
Wspieranie wymiany wiedzy w zespole.
Warto dodać kilka uwag praktycznych odnośnie do tego modelu:

 Powyższy cykl odbywa się wielokrotnie — każda istotniejsza zmiana w zespole
(np. nowa osoba w zespole, zmiana kluczowej osoby po stronie klienta, zmiana
w organizacji) może uruchomić kolejną iterację tego cyklu.
 Szczególnie ważne jest zadanie lidera w fazie docierania; konflikty, które po-
jawiają się w zespole, powinny być rozwiązane — niezdrowe jest ignorowanie
lub bagatelizowanie konfliktów.
 W fazie realizacji — lider zaczyna być zdecydowanie mniej potrzebny, należy
uważać na własną niechęć przed oddaniem zespołowi pola do samoorganizacji.
 W przypadku gdy zespół współpracuje ze sobą przez dłuższy czas, może się po-
jawić tzw. myślenie grupowe, które oznacza sytuację, kiedy członkowie ze-
społu zaczynają myśleć w ten sam sposób i brakuje krytycznego spojrzenia na
podejmowane decyzje; użyteczna w tym przypadku może być strategia Disneya
zawierająca jawną fazę zrównoważonej krytyki; innym rozwiązaniem jest celo-
we wprowadzanie zmian w zespole.

4
Przywództwo sytuacyjne
Kolejne trudne pytanie, które zadają liderzy, dotyczy tego, w jak dużym stopniu na-
leży instruować członków zespołu i jaki zakres spraw zostawić ich samodzielnym de-
cyzjom. Dość nośnym tematem w kontekście metodyk zwinnych jest samoorganizacja
zespołu, która polega na założeniu, że to zespół decyduje, w jaki sposób zostaną osią-
gnięte cele. Jednak wiele zespołów nie jest gotowych na samoorganizację, gdyż ta może
nastąpić w sytuacji, gdy:
 członkowie zespołu są wystarczająco kompetentni, żeby w pełni samodzielnie
realizować zadania, i do tego stopnia zaangażowani, że chcą wziąć za nie od-
powiedzialność;
 w sposób jasny i konkretny zdefiniowane są ograniczenia, w jakich funkcjonuje
zespół (np. długość iteracji, ilość pracy, której zespół jest się w stanie podjąć,
zakres prac);
 w sposób jasny i konkretny jest zdefiniowany cel do zrealizowania.
W tym rozdziale odniosę się do pierwszego z powyższych punktów, analizując model
przywództwa sytuacyjnego według Kena Blancharda i Paula Herseya (rysunek 5.3).
Rysunek 5.3. Model przywództwa sytuacyjnego
W realiach codziennej pracy nie wszystkie osoby w zespołach są jednakowo zaanga-

żowane i kompetentne. W zależności od poziomu tych dwóch parametrów lider powi-
nien dobrać sposób współpracy z daną osobą w zespole. Tabela 5.2 obrazuje, czym należy
się kierować, wybierając sposób działania.

4
Tabela 5.2. Sposoby działania w zależności od poziomu zaangażowania i kompetencji pracownika
Charakterystyka sytuacji Sugerowane działanie

Niskie kompetencje, Zazwyczaj dotyczy to nowych Instruuj — w tym przypadku
duże zaangażowanie osób w zespole, z niewielkim członek zespołu potrzebuje jasnych
doświadczeniem zawodowym, wytycznych, w jaki sposób powinno
kiedy to niskim kompetencjom być wykonane zadanie; lider
towarzyszy duży entuzjazm. podejmuje decyzje odnośnie
do sposobu rozwiązania danego
problemu.
Niskie kompetencje, Dzieje się to w sytuacjach, Sprzedaj — lider najpierw
niewielkie kiedy dana osoba wykonuje rozmawia z daną osobą o zadaniu,
zaangażowanie zadanie, do którego jest szukając rozwiązań, i ostatecznie
negatywnie nastawiona; dąży do tego, aby było ono
często przesunięcie do tego wykonane w konkretny sposób;
poziomu wynika z nadmiaru jest to obszar, w którym istotnym
pracy lub niewspierającego elementem jest przekazywanie
środowiska pracy. wiedzy.
Wysokie kompetencje, Ta sytuacja może być skutkiem Coaching — lider zadaje pytania,
niewielkie znudzenia realizowanymi aby znaleźć rozwiązanie problemu,
zaangażowanie zadaniami lub brakiem wiary próbuje zrozumieć źródło frustracji
w to, że posiadane członka zespołu; celem działania
kompetencje są wystarczające, w tym obszarze jest wspólne
aby zrealizować zadanie. wypracowanie rozwiązania,
przy czym ostateczną decyzję
podejmuje członek zespołu.
Wysokie kompetencje, Samodzielny i doświadczony Monitoruj — zaangażowanie lidera
duże zaangażowanie członek zespołu, który sam powinno być niewielkie, polegające
bierze odpowiedzialność na monitorowaniu przebiegu prac;
za powierzone zadania. koncepcja i sposób realizacji powinny
pozostać po stronie członka zespołu.
Odpowiedni sposób działania będzie zależał od rodzaju zadania, gdyż różne zadania
wymagają od danej osoby różnych kompetencji i budzą różne jej zaangażowanie.
Prezentowany model ma bardzo bezpośrednie zastosowanie praktyczne. Wykonaj
poniższe ćwiczenie.
ĆWICZENIE 1.
Każdą osobę z Twojego zespołu spróbuj przypisać do jednej z przedstawionych na
rysunku 5.3 ćwiartek, mając na uwadze obecnie wykonywane przez nią zadanie. Za-
stanów się, czy Twój obecny sposób współpracy z tą osobą jest adekwatny do jej za-
angażowania i kompetencji.

4
Dysfunkcje zespołu
Osiągnięcie dobrej współpracy w zespole nie jest łatwe. Wiele potencjalnych proble-
mów może stanąć na drodze do dobrze współpracującego zespołu. Patrick Lencioni ze-
brał i ustrukturyzował pięć dysfunkcji działania zespołu, składając je w model poka-
zany na rysunku 5.4.
Rysunek 5.4. Dysfunkcje pracy zespołowej
W tym modelu każdy poziom dysfunkcji prowadzi do innych problemów następują-

cych po nim (innych poziomów dysfunkcji), np. brak zaufania prowadzi do obawy
przed konfliktem, a to z kolei do braku zaangażowania i odpowiedzialności. Poniżej
przyjrzymy się bliżej poszczególnym dysfunkcjom.
Brak zaufania
W zespole, który sobie ufa, ludzie są w stanie powiedzieć sobie prosto w oczy:
„Nie znam odpowiedzi”.
„Potrzebuję twojej pomocy”.
„Myślę, że zawaliłem sprawę”.
„Jesteś dużo mądrzejszy ode mnie”.
„Możesz mnie tego nauczyć?”.
„Przepraszam, to, co wczoraj powiedziałem, było kompletnie bez sensu”.
Niezwykle ważna jest tutaj postawa lidera: dopóki on nie pokaże, że sam ma słabe stro-
ny, prawdopodobnie nikt inny tego nie zrobi. Pokazanie, że nie zawsze jest się dosko-
nałym, wspiera budowanie szacunku. Stwórz środowisko, w którym słabość nie jest
napiętnowana.

4
Co można zrobić, aby przeciwdziałać tej dysfunkcji?

 Jeśli masz taką możliwość w organizacji, przeprowadź badanie profilów oso-
bowości (np. MBTI) i przedyskutujcie je w zespole. Możesz skorzystać z ćwi-
czenia „Analiza motywatorów”.
 Przeprowadź ćwiczenie w zespole, gdzie dyskutujecie o wzajemnych ocze-
kiwaniach.
 Przeprowadź ćwiczenie „Historia osobista” (szczególnie przydatne w przypadku
nowego zespołu i nowych osób).
ĆWICZENIE 2.
Każda z osób w zespole przygotowuje trzyminutową prezentację pt. „Historia osobista”
i mówi o następujących sprawach:
 rodzinne miasto;
 szkoła podstawowa i średnia;
 powód wybrania uczelni lub szkoły średniej;
 doświadczenie zawodowe — firmy, odpowiedzialności;
 jedna rzecz, o której nikt w tej grupie nie wie.
Obawa przed konfliktem

Konflikt to wbrew powszechnym obawom dobra rzecz. Jeśli jednak brakuje zaufania,
konflikt przeradza się w politykę i walkę o to, jak wygrać. Zdrowym stanem jest sytuacja,
w której ludzie w zespole nie obawiają się ze sobą nie zgodzić. Jakość relacji w dużym
stopniu odzwierciedla to, czy pojawiają się konflikty. Kiedy się z kimś spieramy, to
oznacza, że właśnie próbujemy rozwiązać jakiś problem.
Zadaniem lidera jest wyciąganie konfliktów na wierzch i pomoc w ich rozwiązaniu.
Pamiętaj, że chwilowy brak komfortu wynikający z konfliktu jest naturalną częścią
całej sytuacji.
Brak zaangażowania
Często mamy przekonanie, że aby zespół się zaangażował w realizację celu, potrzebne
jest rozwiązanie, które będzie odpowiadało wszystkim. Tymczasem jest wiele problemów,
które nie mają rozwiązań satysfakcjonujących wszystkich. Co ciekawe, wiele osób wcale
niekoniecznie oczekuje, że ich pomysł zostanie zrealizowany, chcą jedynie, by przy-
najmniej został przedyskutowany. Warto wprowadzić zasadę wypracowaną w Intelu:
Disagree and commit (wyraź swój brak zgody i zaangażuj się). W przypadku gdy ze-
spół nie może wybrać jednego z rozwiązań, możesz jako lider zaproponować którąś
opcję lub wręcz poprosić o zgodę na autorytarną decyzję w myśl zasady, że lepsza jest

4
nie najlepsza decyzja niż brak decyzji. Rzadko decyzje są nieodwracalne i z czasem
można zmienić kierunek działania. Opóźnianie decyzji prowadzi do paraliżu i utraty
pewności siebie.
Jako lider dąż do ustalania jasnych i osiągalnych terminów. Analizuj z zespołem pe-
symistyczne przypadki wydarzeń — to redukuje strach i pokazuje, że nawet w trudnych
sytuacjach da się coś zrobić. Kiedy zespół wkroczył w impas decyzyjny, naciskaj na
podjęcie decyzji.
Unikanie odpowiedzialności
Pojawia się wtedy, gdy brakuje zaangażowania oraz kiedy ludzie chcą uniknąć nie-
komfortowych sytuacji. Najlepszy rodzaj odpowiedzialności to taka, która wynika z pre-
sji pozostałych członków zespołu. Aby takiej odpowiedzialności nauczyć innych, jako
lider musisz poruszać trudne tematy.
Oto działania sprzyjające budowaniu postawy odpowiedzialności:
 Publicznie ogłaszaj cele i standardy — to daje jasność, co jest oczekiwane, i ni-
weluje wątpliwości.
 Często dokonuj z zespołem przeglądu postępu — niech zespół zdecyduje, jak
wrócić na dobrą ścieżkę.
 Jako lider pozwól, aby to zespół był głównym źródłem egzekwowania odpo-
wiedzialności, i działaj tylko wtedy, kiedy to się nie dzieje.
Nieprzywiązywanie wagi do rezultatów

Trudna sytuacja jest wtedy, kiedy zespół nie skupia się na tym, aby osiągnąć założone
cele. Dzieje się tak zazwyczaj, gdy indywidualne interesy członków zespołu są sta-
wiane wyżej niż dobro wszystkich, gdy brakuje wspólnych celów.
Oto działania sprzyjające budowaniu skupienia na rezultatach:
 Dąż do tego, aby zespół publicznie deklarował, jakie chce osiągnąć rezultaty.
 Sugeruj używanie zaimka „my” zamiast „ja”, gdy zespół omawia cele.
 Jako lider odnoś bieżące efekty działań zespołu do spodziewanych rezultatów.
Podsumowanie
Niniejszy rozdział stanowił przegląd kluczowych modeli związanych z pracą z ze-
społem. Model Cynefin uwrażliwia na to, że praca z zespołem to zagadnienie złożone
(complex), w którym nie ma jednoznacznych odpowiedzi, a rozwiązania należy wy-
pracować na bazie doświadczenia i przeprowadzanych eksperymentów. Model Tuck-
mana mówi o tym, że zespół podlega pewnemu procesowi rozwojowemu, w którym

4
zdarzają się konflikty, konieczne jest normowanie zasad i efektywna realizacja, a za-
daniem lidera jest wspieranie tego procesu. Z kolei model przywództwa sytuacyjnego
podpowiada, jak dobierać sposób współpracy z członkami zespołu w zależności od
indywidualnego poziomu kompetencji i zaangażowania związanego z danym zadaniem
każdej osoby. Na końcu przedstawiłem kluczowe dysfunkcje zespołu oraz sposoby
radzenia sobie z nimi.

4

4
Rozdział 6.
PROCES I INŻYNIERIA
W jednej z firm miałem okazję zastanawiać się nad kwestią, jaki powinien być zakres
odpowiedzialności zespołu, a co powinno być po stronie kierownika projektu lub
klienta. Po dłuższej dyskusji uświadomiłem sobie, że duża część liderów i wraz z nimi
członkowie zespołów nie mają punktu odniesienia pozwalającego im zinterpretować
sytuację, w której się znajdują — czy trudności, których doświadczają, wynikają z kon-
tekstu, czy są kwestią niedociągnięć organizacyjnych.
Ten rozdział ma stanowić wprowadzenie do procesów wytwarzania oprogramowania,
na które możemy próbować wpływać. Siła wpływu może zależeć zarówno od Twojego
umocowania w organizacji, jak i od wielkości samej organizacji. Prawdopodobnie w du-
żej korporacji będziesz miał mniejszy wpływ na to, co się dzieje, niż w kilkuosobowym
start-upie.
Omówię kluczowe elementy procesu i pewne najważniejsze założenia. Pamiętaj jed-
nak, że każda firma jest inna, i nie wszystkie z podawanych zaleceń będą mieć równie
duże uzasadnienie w Twoim przypadku.
Podział odpowiedzialności
Niemal każdy proces wytwarzania oprogramowania definiuje role. Z rolami najczę-
ściej wiąże się określona odpowiedzialność. Z jednej strony należy dążyć do tego, żeby
było jak najmniej wydzielonych ról, z drugiej powinna być jasność, jakie są te role i jakie
są przypisane do nich zakresy odpowiedzialności lub jakie odpowiedzialności są
współdzielone. Dla przykładu w Scrumie mamy do czynienia z trzema rolami:

4
 Product Owner, który odpowiada za decyzje biznesowe, w tym ustalenie prio-

rytetów i dostarczenie wymagań;
 Scrum Master — odpowiada za proces i opiekę nad problemami, które się poja-
wiają w czasie pracy;
 zespół — osoby, które wykonują pracę nad produktem.
Jak widać, w tym przypadku jest jasne rozgraniczenie odpowiedzialności za część bizne-
sową, proces i sposób wytwarzania oprogramowania. Niemniej jednak w samym ze-
spole nie ma konieczności wyznaczania ściśle określonych ról, gdyż z założenia zespół
według metody Scrum powinien być samoorganizujący się, więc role w zespole są
drugoplanowe.
Bez względu na to, jakie role zostały zdefiniowane, kluczowa jest jasność reguł. Naj-
lepiej jeśli te reguły będą ustalone na samym początku współpracy między stronami,
później może to już być trudniejsze. W kolejnych podrozdziałach znajdziesz podpo-
wiedzi, co szczególnie warto zdefiniować, jeśli chodzi o odpowiedzialności.
Wizja i cele projektu

Wiele zespołów pracuje nad poszczególnymi funkcjonalnościami w systemach in-
formatycznych, nie mając świadomości, jaka jest docelowa wizja produktu — czemu on
służy, kto jest jego odbiorcą, co jest jego wyróżnikiem, jaka jest rola części systemu,
nad którą trwają prace. Często rozważania na temat celów związanych z produktem
zatrzymują się na dziale marketingu lub gdzieś wyżej w organizacji, a to błąd, gdyż
świadomość wizji nadaje sens pracy, a ta z kolei wpływa na motywację członków ze-
społu, o czym można przeczytać więcej w rozdziale 4. „Motywacja”.
Od kilku lat prowadzę firmę, która m.in. zajmuje się działalnością szkoleniową. Jest
przynajmniej kilka szkoleń, które prowadzimy od lat, niemniej jednak co najmniej raz
w roku zastanawiamy się, czy założenia dotyczące danego tematu, cały czas są aktualne,
i na podstawie takiej analizy wprowadzamy zmiany. Zdarzyło się kilkakrotnie, że po
trzech latach prowadzenia danego szkolenia założenia diametralnie się zmieniały —
zmieniła się wizja produktu. Choć wizja powinna być stabilna, nie należy uznawać, że raz
ustalona będzie zawsze dobra. Trzeba przynajmniej raz, dwa razy w roku wracać do
kluczowych założeń.
Kiedy się rozmawia o wizji, warto skonkretyzować m.in. następujące tematy:
 Kto jest odbiorcą systemu, kodu? Kto jest klientem?
 Jakie potrzeby zaspokaja produkt? Dlaczego jest on potrzebny klientom?
 Jakie korzyści osiąga klient, korzystając z produktu? Co może dzięki niemu
zrobić łatwiej, szybciej, a może bardziej ekonomicznie?

4
Rozdział 6. Proces i inżynieria 83
 Jakie są alternatywy w przypadku danego rozwiązania? Jak to rozwiązanie się

prezentuje w odniesieniu do propozycji konkurencji?
 Co wyróżnia produkt? Co sprawia, że akurat na ten system warto zwrócić uwagę?
Wymagania i decyzje biznesowe

Wiele problemów, z którymi mierzą się zespoły projektowe, wynika z braku jasnego
ustalenia, gdzie zaczyna się odpowiedzialność zespołu, a gdzie odpowiedzialność klienta,
co w efekcie prowadzi do niezadowolenia po obu stronach. Z tego powodu w każdym
projekcie programistycznym muszą być jasno określone zasady współpracy z klien-
tem. Jakie są kryteria takiej relacji z punktu widzenia procesu?
1. Jest jeden biznesowy punkt decyzyjny — jeden człowiek lub jeden byt podej-
mujący decyzje odnośnie do dalszych losów projektu oraz wymagań. Często
problemem jest to, że wymagania przychodzą z wielu źródeł (np. z różnych
departamentów), i to zespół, a najczęściej lider musi sobie z tym poradzić. To
nie jest dobre. Zespół w większości przypadków nie ma odpowiedniej perspek-
tywy biznesowej, żeby takie decyzje podejmować. Decydowanie o priorytetach
i ostatecznym kształcie wymagań należy do klienta. Nie znaczy to, że członkowie
zespołu mają być bierni w tym zakresie. Zespół powinien wspierać i doradzać
— może podpowiadać, sugerować pewne decyzje lub przekonywać do nich,
szczególnie jeśli mogą być one istotne z technicznego punktu widzenia ze wzglę-
du na ich wpływ na architekturę, spójność lub prostotę rozwiązania.
2. Klient jest dostępny na konkretnych zasadach — ideałem byłaby dostępność
klienta, który pracuje bezpośrednio z zespołem. Nie zawsze jest to w pełni moż-
liwe, jednak ważne jest, żeby ustalić:
 kiedy zespół może się komunikować z osobą decyzyjną;
 z jakimi sprawami może się zgłaszać;
 jakiego zaangażowania ze strony tej osoby potrzebuje zespół;
 jak będą rozstrzygane sytuacje sporne;
 jak będą rozwiązywane problemy;
 jak będą uwzględniane zmiany w wymaganiach;
 w jaki sposób będzie podawana informacja zwrotna.
Właściciel procesu
Właściciel procesu to osoba, której zadaniem jest monitorowanie, czy proces wytwa-
rzania jest realizowany według przyjętych wcześniej założeń. W świecie rzeczywistym
można spotkać wiele wariantów tej roli. Czasami odgrywa ją kierownik, czasami li-
der zespołu, a w metodzie Scrum jest to Scrum Master.

4
W świecie inżynierów oprogramowania nie brakuje świetnych pomysłów. Można

powiedzieć, że jest ich aż nadto. Programiści, projektanci, architekci to ludzie ogromnie
kreatywni. Jednak dobre pomysły same w sobie nie mają zbyt dużej wartości. Mówi
się, że dobrymi intencjami wybrukowane jest piekło — podobnie jest z dobrymi pomy-
słami. Nie wystarczy je mieć. Pomysły, żeby miały wartość, trzeba wdrażać oraz
wkładać energię w to, aby zostały zrealizowane mimo pojawiających się trudności. Po-
dam pewien przykład: kiedyś pracowałem z zespołem nad zmianami w architekturze.
Po godzinie pracy dowiedziałem się, że zespół ma już opracowany całkiem sensowny
projekt zmian narysowany w formie diagramów. Tak przebiegała rozmowa:
— A kiedy powstały te diagramy?
— No… ponad pół roku temu…
— A ile spędziliście nad tym czasu?
— No, były tego jakieś dwa tygodnie czterech osób.
— I co z tym później zrobiliście?
— No… nic, jakoś tak nie było jak się za to zabrać…
— Czyli nic nie zrobiliście?
— No… tak…
Jako osoby techniczne lubimy rozwiązywać zagadki, problemy i tworzyć rozwiąza-
nia, ale jeśli chodzi o ich wdrażanie, szczególnie gdy potrzebny jest szerszy plan i in-
terakcje z innymi ludźmi, bywa już gorzej. I po to jest właściciel procesu — ktoś, kto
dba o to, żeby coś się dalej działo z pomysłami. Nie musi być kierownikiem, po prostu
pilnuje tego, czy sprawy idą do przodu. Podsumowując, powinien być ktoś, kto dba
o podążanie za procesem i pomaga rozwiązać problemy.
Proces
Kolejnym elementem, który powinien być ustalony i klarowny, jest proces, zgodnie
z którym prowadzone są prace nad produktem lub nad projektem. Jeśli proces jest nie-
precyzyjnie zdefiniowany lub nie istnieje, proponuję zapoznać się z procesami zwin-
nymi (np. Scrum), gdyż te zazwyczaj są proste w swojej konstrukcji i stanowią dobry
punkt odniesienia.
Bez względu na to, jakiego procesu użyjesz, z pewnością będą tam takie elementy, jak:
 ustalenie zakresu projektu i przypadku biznesowego;
 określenie wymagań;
 architektura i projekt techniczny;
 implementacja;

4
 weryfikacja jakości;
 wdrożenie;
 utrzymanie.
W procesach tradycyjnych dominuje podejście do tych elementów jako do faz nastę-
pujących po sobie. Procesy zwinne proponują prace w iteracjach nad mniejszymi ele-
mentami systemu, co powoduje, że część powyższych punktów jest realizowana rów-
nolegle. Dobrze zdefiniowany proces powinien dawać jasność co do:
 ról, które określają odpowiedzialności;
 spotkań, które stanowią napęd dla procesu;
 artefaktów, tj. narzędzi i dokumentów wspierających realizację prac;
 samego procesu — jego przebiegu i założeń.
Retrospekcje
Nie ma procesów doskonałych, nie ma zespołów doskonałych, nie ma liderów do-
skonałych. Można jednak dążyć do doskonałości poprzez ciągłe przyglądanie się własnej
pracy i wprowadzanie zmian. Poniżej (rysunek 6.1) znajdziesz model zaproponowany
w latach 50. przez Williama Edwardsa Deminga, zwany cyklem Deminga lub cyklem
PDCA (Plan-Do-Check-Adapt). Zakłada on, że praca odbywa się w cyklach:
1. Zaplanuj (Plan).
2. Wykonaj (Do).
3. Zbadaj (Check).
4. Wprowadź zmiany (Adapt).
Rysunek 6.1. Model ciągłego udoskonalenia
Punkt 3. to miejsce na retrospekcje — spotkanie, które służy refleksji i poszukiwaniu

pomysłów na udoskonalenie pracy. Może przyjmować różne formy i różny przebieg.
Ponieważ retrospekcja służy analizie tego, co się udało zrobić, i tego, czego się zrobić
nie udało, warto rozpocząć ją preambułą takiej treści: Celem tego spotkania jest wy-
ciągnięcie wniosków ze sposobu naszego działania i wprowadzenie zmian. Mimo że

4
chcemy znaleźć rzeczywiste przyczyny problemów, z którymi się borykamy, to nie za-
mierzamy szukać winnych. Zakładamy, że wszelkie działania odbywały przy dobrej
wierze osób w nich uczestniczących. Pozwoli to ukierunkować rozmowę na szukanie
konstruktywnych rozwiązań, zamiast na szukanie winnych. Zadaniem prowadzącego
jest egzekwowanie tejże preambuły.
A oto przykładowy scenariusz tego typu spotkania (zob. też rysunek 6.2):
1. Przypomnienie postanowień z ostatniego spotkania retrospekcyjnego i pod-
sumowanie efektów podjętych działań.
2. Każda osoba na małych karteczkach zapisuje główne wydarzenia, które utkwiły
jej w głowie od ostatniego spotkania. Jedna karteczka — jedno zdarzenie. Następ-
nie podchodzi do flipchartu, na którym narysowana jest linia czasu, i umieszcza
zanotowane przez siebie wydarzenia, krótko wyjaśniając, o co chodzi.
3. Na osobnym flipcharcie są spisywane pomysły:
a) Co przestać robić?
b) Co zacząć robić?
c) Co kontynuować?
3. Zespół wybiera kilka tematów, które chce wdrożyć do czasu następnego spo-
tkania. Przy czym lepiej jest wybrać mniej, aby rzeczywiście można było spełnić
zamierzenia.
4. Zespół planuje, w jaki sposób wybrane w punkcie 4. tematy włączy do swoich
prac i kto się zaangażuje w ich realizację.
Rysunek 6.2. Schemat spotkania retrospekcyjnego

4
Codzienne spotkania
Codzienne spotkania to praktyka, która jest powszechnie stosowana w zwinnych
procesach. Nawet jeśli nie używasz żadnej z metod zwinnych, namawiam Cię do or-
ganizowania takich spotkań. Dlaczego warto?
1. Praca programisty to praca w transie (zwanym czasami strefą programisty —
programmer’s zone) — tracimy kontakt z rzeczywistością i świadomość celu,
nad którym pracujemy. Codzienne spotkania wymagają spojrzenia na wykony-
waną pracę z szerszej perspektywy i zastanowienia się nad tym, w jakim stopniu
zbliżamy się do obranego celu.
2. Programowanie jest bardzo absorbujące i powoduje, że większość osób tech-
nicznych spędza niewiele czasu na komunikowaniu się z innymi osobami za-
angażowanymi w projekt. Codzienne spotkania, z góry zaplanowane i odby-
wające się zawsze, powodują, że w zespole następuje wymiana informacji między
członkami zespołu.
3. Codzienne spotkania to planowanie na małą skalę. Motywują do odpowiedzi
na trzy pytania:
a) Co zrobiłem od poprzedniego spotkania?
b) Co zrobię do następnego spotkania?
c) Jakie problemy napotykam?
Rolą organizatora takich spotkań jest upewnienie się, że zebranie nie będzie polegać
na odpytywaniu i rozliczaniu z wykonanych zadań, ale na wymianie informacji między
członkami zespołu.
Jednak codzienne spotkania to tylko przykład praktyki. Kluczowe jest znalezienie
sposobu na to, aby techniczni członkowie zespołu wychodzili regularnie z transu,
przechodzili na wyższy poziom myślenia o realizowanych zadaniach i często rozma-
wiali z liderem, klientem i ze sobą nawzajem o tym, co robią i z czym mają problemy.
Oznaczanie problemów
Oprócz typowych zadań technicznych, które są do zrealizowania w projekcie, poja-
wiają się różnego rodzaju problemy do rozwiązania i Ty jako lider jesteś najczęściej
za nie odpowiedzialny. Poza tym sporą część Twojej pracy stanowią zadania nie-
techniczne, z których członkowie zespołu często nie zdają sobie sprawy. Żeby kla-
rownie przedstawić to, czym się zajmujesz i co się dzieje z problemami, wprowadź ta-
blicę, która będzie to wizualizować (rysunek 6.3). Tablicę tego typu możesz również
wykorzystać do przedstawienia stanu realizacji zadań, które powstały w wyniku re-
trospekcji.

4
Rysunek 6.3. Przykładowa tablica kanbanowa do śledzenia stanu problemów
Kryteria jakościowe
Typowy problem występujący w większości zespołów to syndrom „u mnie działa”
lub to, że zadanie zostało już zakończone, ale nie zostało domknięte: nie stworzono
dokumentacji, nie umieszczono zmienionych plików konfiguracyjnych w repozytorium
lub zignorowano dziesiątki błędów zgłaszanych przez narzędzie statycznej analizy kodu.
Aby wyeliminować subiektywność oceny tego, kiedy zadanie jest zakończone, warto
stworzyć listę kontrolną czynności, które należy wykonać, żeby mieć pewność, że
wszystko zostało zrobione. Ta lista powinna zostać wypracowana wspólnie z zespołem.
Poniżej znajdziesz przykładowe punkty, które można na niej umieścić:
 funkcjonalność działa na najważniejszych przeglądarkach;
 konfiguracja serwera została zaktualizowana;
 została wykonana dokumentacja techniczna;
 został napisany odpowiedni fragment podręcznika użytkownika;
 zostały napisane testy jednostkowe z pokryciem >60%;
 stworzone rozwiązanie zostało zrefaktoryzowane;
 wszystkie testy integracyjne i jednostkowe kończą się pomyślnie;
 stworzono plik migracyjny do bazy danych;
 poziom ostrzeżeń zgłaszanych przez narzędzie statycznej analizy kodu jest
<10 per klasa;
 kod został połączony z HEAD;
 rozwiązanie zostało zaakceptowane przez klienta.

4
To przykładowe pozycje. Na liście kryteriów zakończenia warto umieścić wszystko,

o czym łatwo zapomnieć. Ustal z zespołem, w jaki sposób będziecie korzystać z tej listy.
Oto kilka opcji:
 każda osoba sama weryfikuje swoje zadania, do wspólnej weryfikacji kryteriów
się wraca, jeśli pojawiają się problemy w projekcie;
 kryteria weryfikuje osoba, która nie brała udziału w pracach nad zadaniem,
dzięki czemu proces staje się bardziej obiektywny;
 weryfikacja jest przeprowadzana wspólnie i następuje przed zakończeniem itera-
cji, w ten sposób odpowiedzialność za jakość staje się tematem zespołowym.
Podsumowanie
Wiele problemów, z którymi mają do czynienia liderzy, wynika z niedoprecyzowa-
nego lub nieprzestrzeganego procesu. Zadbaj o to, aby były jasne odpowiedzialności
poszczególnych ról, aby było wiadomo, kto decyduje o wymaganiach, kto monito-
ruje proces i w jaki sposób następuje komunikacja między stronami uczestniczącymi
w projekcie. Organizuj codzienne spotkania, które będą centrum codziennej wymia-
ny informacji, a problemy wymagające rozwiązania wizualizuj za pomocą tablicy kan-
banowej.
Bez względu na to, jak precyzyjnie zostanie zdefiniowany proces, rzeczywistość wie-
lokrotnie zaskoczy Ciebie i Twój zespół. Dbaj o to, aby regularnie odbywały się re-
trospekcje — są one narzędziem, które ma na celu dostosowanie procesu do sytuacji
w projekcie.
Stwierdzenie, czy zadanie zostało w pełni zakończone, bywa kwestią subiektywną.
Ustalcie w zespole kryteria jakościowe, które pozwolą obiektywnie i bez zbędnych
emocji stwierdzić wykonanie zadania.

4

4
Rozdział 7.
ZARZĄDZANIE WIEDZĄ
Obszar zarządzania wiedzą w zespole jest często zaniedbywany w zespołach progra-

mistycznych. Istnieje ciche założenie, że „to” się dzieje samo. I rzeczywiście, w pewnym
stopniu się dzieje, bo programiści są przyzwyczajeni do tego, że jeśli chodzi o tech-
nologie, muszą cały czas poznawać nowe rzeczy, żeby pozostać atrakcyjni na rynku
pracy. Jednak to nie jest efektywna strategia. Potrzebna jest spójna i aktualna wiedza
w zespole, przy czym spójność ma tu szczególne znaczenie, gdyż wpływa na łatwość
współpracy i prostotę komunikacji. Najlepiej funkcjonujące zespoły, które miałem oka-
zję spotkać, miały bardzo dobrze rozwinięty sposób zarządzania wiedzą w zespole.
W tym rozdziale znajdziesz przykłady występujących w firmach problemów oraz pro-
ponowane rozwiązania tych problemów.
Wprowadzanie osoby do zespołu

Niewiele zespołów ma ustaloną i praktykowaną ścieżkę wprowadzania nowej osoby.
Najczęściej przyjęcie nowego członka zespołu polega na kilkudniowych chaotycznych
działaniach, które w większości przypadków sprowadzają się do przedstawienia pro-
cedur firmowych, skonfigurowania środowiska i przekazania dostępu do repozytorium.
Czasami ktoś w zespole opowie kilka słów o systemie i doda: „…a resztę znajdziesz
w plikach”. Co się dzieje dalej? Powierzchownie wprowadzona osoba poznaje system na
podstawie kodu. Zamiast dwóch tygodni spędza nad tym trzy miesiące1, żeby mniej
więcej się zorientować, jak zbudowany jest system, z jakich bloków się składa, jakie
rozwiązania są preferowane w danym zespole, a które są uważane za błędne, na czym
1
W praktyce czas potrzebny na zrozumienie systemu zależy od złożoności tegoż systemu.

4
polega dziedzina problemowa. Poznawanie systemu samodzielnie trwa kilkakrotnie

dłużej niż wprowadzenie w temat przez bardziej doświadczoną osobę z zespołu.
Jakie praktyki warto stosować w tym przypadku?
Mentoring — osoba wprowadzana ma opiekuna mentora, który przez pierwsze ty-
godnie pomaga jej zrozumieć działanie systemu, architekturę i zależności. Przydatną
praktyką w tym przypadku może być praca w parze.
Plan wprowadzenia — zostaje ustalona ścieżka doboru zadań w taki sposób, aby dana
osoba mogła poznać standardy stosowane przez zespół. Przykład takiej ścieżki:
1. Używane narzędzia i cykl pracy z repozytorium.
2. Założenia architektoniczne.
3. Założenia związane ze standardami kodowania i tworzenia kodu (dotyczące
czystości kodu i refaktoryzacji).
4. Systemy zewnętrzne, z którymi integruje się system.
5. Praktyki w zespole związane z testami automatycznymi.
Mantra architektoniczna — to pewien sposób na zarządzanie wiedzą o architekturze
opisany w osobnym podrozdziale.
Spójne zasady
Jednym z kluczowych elementów wpływających na działanie zespołu jest spójność stoso-
wanych zasad. W przypadku zespołów programistycznych można do nich zaliczyć m.in.:
 standard kodowania;
 zasady tworzenia czystego kodu;
 stosowane wzorce implementacyjne;
 bloki budujące związane z zastosowanym podejściem architektonicznym;
 sposób pisania testów automatycznych.
Jeśli powyższe zasady nie zostały ustalone i nie są monitorowane, na dłuższą metę
można się spodziewać erozji architektury poprzez powstające niespójności. W począt-
kowym okresie rozwoju produktu jest to nieodczuwalne, jednak wraz ze wzrostem
skali projektu oraz z upływem czasu obserwuje się efekt kuli śnieżnej. Jakie zatem za-
stosować praktyki?
Ustal z zespołem zasady tworzenia kodu i w prosty sposób zapisz je w formie do-
kumentu, a jeszcze lepiej na flipcharcie — niech zawiśnie na ścianie pomieszczenia,
w którym pracuje zespół. Co jakiś czas wracajcie do tych zasad, aby zweryfikować ich
sensowność.
Mantra architektoniczna — opisana w osobnym podrozdziale.

4
Rozdział 7. Zarządzanie wiedzą 93
Wymiana doświadczeń w zespołach

Zdarza się, że brakuje czasu czy też pieniędzy na szkolenia, natomiast nie doceniamy
najcenniejszego zasobu, jakim dysponujemy — wiedzy i doświadczenia członków ze-
społu, które zostały zdobyte w czasie projektu?
Zbudowanie środowiska ciągłej nauki powinno być jednym z głównych Twoich ce-
lów. Będziesz miał zmotywowanych i efektywnych ludzi, którzy będą tworzyć spójne
rozwiązania. Czego możesz się spodziewać, jeśli nie zorganizujesz takiego procesu?
Będą powstawać implementacje tych samych mechanizmów w różnych miejscach.
Będziesz miał problem, kiedy ktoś odejdzie z zespołu, bo wiedzą i doświadczeniem
będą dysponowały pojedyncze osoby. Brak wymiany wiedzy to brak motywacji, nudne
środowisko, większa rotacja pracowników, co w efekcie spowoduje spadek średniego
poziomu wiedzy i doświadczenia w Twoim zespole.
Jakie praktyki zastosować?
Niech częścią retrospekcji będzie zgłaszanie dobrych rozwiązań, które warto roz-
powszechniać.
Stwórz bazę przykładów kodu (np. jak wygląda dobrze napisany serwis, kontroler).
Stymuluj organizowanie wewnętrznych szkoleń typu „czego się nauczyliśmy, ko-
rzystając z biblioteki X”.
Umożliwiaj pracę parami — nawet jeśli nie cały czas, to na początku i na końcu
tworzenia rozwiązania. Ponieważ nie wszyscy programiści potrafią dobrze pracować
razem, czasem trzeba włożyć wysiłek w nauczenie ich tego — chociażby w zakresie
ustalania wspólnego rozwiązania, kiedy pojawiają się różne zdania.
Przeglądy kodu
Przeglądy kodu to jeden z ciekawszych sposobów rozpowszechniania, współdzielenia
i uspójniania wiedzy. Postaraj się, aby przeglądy kodu były stałą praktyką. Nie chodzi
o to, aby przejrzeć każdy fragment kodu, który trafi na produkcję, ale by następowała
wzajemna wymiana doświadczeń. Lepiej stosować częste, ale krótsze przeglądy kodu
— ich efektywność jest wtedy większa. Proces powinien być jak najprostszy — im
bardziej będzie skomplikowany, tym większe jest prawdopodobieństwo, że zespół będzie
go uważał za przeszkodę. Przykładowy proces może wyglądać tak:
1. Programista skończył pisać funkcjonalność i wysyła kod do repozytorium.
2. Prosi jedną z osób w zespole o przeprowadzenie przeglądu (to ustalenie może
być zrobione podczas rozpoczęcia pracy nad funkcjonalnością).
3. Recenzent poświęca maksymalnie 15 – 30 min na przegląd kodu. Uwagi przeka-
zuje autorowi:

4
 bezpośrednio,
 poprzez odpowiednie komentarze w kodzie,
 poprzez użycie systemu wspierającego przeglądy kodu.
4. Autor dokonuje zmian w kodzie.
5. Funkcjonalność może być przekazana do testów.
Przydatne jest użycie narzędzia, które automatyzuje ten proces, np.: Gerrit, Assembla,
Github, Kiln, Code Collaborator, Atlassian Bitbucket, Codebrag.
Oprócz bieżących przeglądów kodu warto wdrożyć dwa typy działań:
1. Inspekcje kodu — dwóch, trzech najbardziej doświadczonych programistów
robi przegląd większego fragmentu kodu i przedstawia na poświęconym temu
spotkaniu efekty analizy. Inspekcje kodu warto robić raz na 2 – 4 tygodnie.
2. Wspólne przeglądy kodu — cały zespół wspólnie analizuje wybrany fragment
kodu. Tego typu spotkanie może się odbywać raz na 2 – 4 tygodnie. Może być
prowadzone naprzemiennie z inspekcjami kodu.
Bez względu na to, jaką formę wybierzesz, należy pamiętać o kilku rzeczach, aby prze-
glądy kodu były przyjemnością:
 każdy powinien mieć równy głos w dyskusji, aby bardziej doświadczeni pro-
gramiści nie zdominowali spotkania;
 nie dopuszczaj do tego, aby przeglądy polegały na wytykaniu błędów i szukaniu
winnych — główny cel to uspójnianie wiedzy i stosowanych rozwiązań;
 walcz z dogmatyzmem i perfekcjonizmem — jeśli rozwiązanie jest wystarczająco
dobre, nie poprawiajcie go, nie chodzi o szukanie najlepszego z możliwych
rozwiązań;
 bądź ostrożny z formalizmami — nie powinny one spowalniać procesu (przy-
kładem może być uzależnienie zatwierdzenia kodu — commit — w repozytorium
od poprawnego przeglądu kodu);
 bądź ostrożny z metrykami — osiągnięcie pewnych wartości wybranych metryk
nie jest celem samym w sobie, przesadne skupianie się na metrykach może
w efekcie prowadzić do tworzenia rozwiązań, które są nieadekwatne, ale dają
dobre wyniki metryki.
Aktualizacja wiedzy o systemie

Każdy programista czy lider, który ma już kilka lat doświadczenia za sobą, wie, że
systemy się zmieniają — dużo szybciej, niż się wydaje, i najczęściej w innym kierunku
niż przewidziany. Toteż ustalenia odnośnie do architektury systemu, stosowanych
bibliotek, mechanizmów będą modyfikowane. Liderzy zwykle zapominają o tym, że
trzeba włożyć energię, aby tego typu zmiany zostały wdrożone i utrzymane. Często

4
występującym błędem jest to, że tylko liderzy i główni architekci wiedzą, w którą
stronę zmierza system i jaka jest obecnie przyjęta postać architektury. Czasem napiszą
mail lub wyślą dokument… A to za mało.
Zatem jeśli chcesz, żeby zmiany wprowadzane do architektury czy sposobu pisania
kodu rzeczywiście były stosowane, to:
1. Zorganizuj spotkanie, na którym zostaną przedstawione zmiany.
2. Przeprowadź dyskusję na temat tego, jakie trudności zespół może widzieć we
wprowadzaniu nowych pomysłów. W tym przypadku warto zastosować struktu-
ry prowadzenia spotkań opisane w rozdziale 13. „Efektywne spotkania”.
3. Regularnie dokonuj retrospekcji dotyczących wprowadzanych zasad, aby zbierać
i usuwać potencjalne problemy, które się pojawiają w trakcie pracy.
Przykład pełnego procesu wprowadzania spójnego podejścia w zakresie architektury
znajdziesz w podrozdziale dotyczącym mantry architektonicznej.
Ciągły rozwój
Wiele firm stosuje podejście: „U nas ludzie sami się uczą, nie potrzebujemy szkoleń”.
Samodzielne zdobywanie wiedzy jest chwalebną praktyką, lecz jeśli jest jedyną, można
narazić się na kłopoty.
Jeśli uczysz się sam, ograniczasz się tylko do kontekstu, który znasz. W związku z tym
jest trudniej o istotnie inne od obecnie stosowanego podejście do rozwiązywanych
problemów, gdyż Twoja percepcja będzie ograniczona poprzez dotychczasowe do-
świadczenia. Ponadto samodzielne uczenie się najczęściej ma charakter fragmenta-
ryczny — zdobywa się dużo informacji, ale trudno je zsyntetyzować w spójną całość.
Dlatego samouczenie prowadzi do wrażenia, że cały czas jeszcze trzeba bardzo dużo
się dowiedzieć z danego tematu. Trudno określić, co jest rzeczywiście ziarnem, a co
chwastem. Często potrzeba kilku lat doświadczenia, aby nabrać umiejętności rozróż-
niania i stwierdzenia: „To już wystarczy”. Zatem wychodź poza swój kontekst. Kontakt
z osobami spoza własnego środowiska jest świetnym źródłem inspiracji, której nie
zapewni praca indywidualna. Większość innowacyjnych pomysłów ma źródło w kon-
taktach z innymi osobami. Dlatego szkolenia, konferencje czy wydarzenia, które nie
są w 100% związane z tym, czym zajmują się na co dzień programiści, mają ogromną
wartość. Kiedy członek Twojego zespołu wróci ze szkolenia, Twoim zadaniem będzie
zogniskowanie zdobytej wiedzy poprzez pytanie: „Jak to, czego się dowiedziałeś, możesz
wykorzystać w codziennej pracy?”. I nie daj się zbyć szybkimi, prostymi odpowie-
dziami. Drąż, a zdobędziesz bardziej świadomego członka zespołu.
Jakie praktyki zastosować?
Plan szkoleń — z każdym członkiem zespołu ustal szkolenia, w których powinien
wziąć udział. Poświęć temu osobne spotkanie.

4
Plan konferencji — podobnie jak w przypadku szkoleń, konferencje są ciekawym

źródłem informacji. Plan szkoleń uzupełnij o plan konferencji.
Poniżej (rysunek 7.1) znajdziesz wizualizację tego, w jaki sposób można zaradzić pro-
blemom związanym z rozpowszechnianiem wiedzy w zespole.
Rysunek 7.1. Problemy związane z zarządzaniem wiedzą i przydatne narzędzia

4
Mantra architektoniczna
Na koniec kilka słów o procesie, który opisuje, w jaki sposób systemowo doprowadzić
do rozpowszechniania i uspójniania wiedzy o architekturze.
Mam dla Ciebie propozycję: zrób w swoim zespole prosty test. Zadaj pytanie: „Z jakich
elementów (bloków budujących) składa się system i jakie są ich zakresy odpowie-
dzialności?”. Ja robiłem to wielokrotnie, w rozmaitych organizacjach i od różnych osób
dostawałem odpowiedzi, które od siebie odbiegały, czasami nawet znacząco. Te różnice
sprawiają, że architektura systemu z czasem zaczyna erodować, powstają drobne od-
stępstwa od reguł i nawet doskonale zaprojektowana architektura musi polec w takich
okolicznościach. Im więcej czasu upływa, tym zniszczenia są większe.
Co to jest mantra architektoniczna?

Gdyby chcieć zdefiniować cel za pomocą metafory, wyglądałoby to tak: o trzeciej nad
ranem każda osoba w zespole jest w stanie bez zająknięcia powiedzieć, z jakich blo-
ków budujących składa się system i jakie są ich zakresy odpowiedzialności. I wszyscy
odpowiedzą to samo. Ambitne? Bardzo. I właśnie o to chodzi. To trzeba wypracować.
Być może nie stanie się to od razu, jednak wkładając nieco wysiłku i dając sobie czas,
można się zbliżyć do tego ideału.
W osiągnięciu tego celu ma pomóc mantra architektoniczna, która ma trzy składowe
(rysunek 7.2):
1. Wizualizacja bloków budujących.
2. Definicja odpowiedzialności bloków.
3. Napędzanie procesu.
Rysunek 7.2. Model mantry architektonicznej

4
Zwizualizuj
Narysuj bloki, z których składa się system. Może to być UML, odręczny rysunek, coś,
co będzie zrozumiałe dla zespołu. Następnie umieść rysunek w takim miejscu, żeby
był dla wszystkich widoczny, np. na ścianie, żeby w każdym momencie można było do
niego podejść i dyskutować. Zadbaj o jego dostępność.
Czasami może Ci się wydawać, że przy stosowaniu np. podejścia Domain-Driven Design
(DDD) bloki budujące powinny być oczywiste. Nic bardziej mylnego. Poniżej znaj-
dziesz przykładowe rysunki — jeden według podejścia DDD (rysunek 7.3), a drugi we-
dług klasycznej architektury warstwowej (rysunek 7.4). Kluczem jest to, żeby stworzyć
rysunek unikalny dla waszego systemu.
Rysunek 7.3. Przykład wizualizacji architektury według podejścia DDD
Rysunek 7.4. Przykład wizualizacji architektury warstwowej

4
A jak to wygląda u Ciebie (rysunek 7.5)?
Rysunek 7.5. Jakie elementy pojawią się na Twoim rysunku?
Jeśli architektura wykorzystuje wzorzec Domain Model, warto zwizualizować klasy

dziedziny. Jeśli system komunikuje się z innymi systemami, należy zwizualizować
powiązania z innymi systemami, tak aby łatwiej można było prześledzić konsekwencje
interakcji w systemie. Te rysunki mają być podstawą komunikacji — miejscem, przy
którym toczą się dyskusje o rozwiązaniach (rysunek 7.6).
Rysunek 7.6. Dodatkowe wizualizacje modelu i kontekstu
Zdefiniuj
Kiedy już elementy architektury zostaną narysowane, następnym krokiem jest okre-
ślenie ich odpowiedzialności:
 jaką rolę odgrywają w systemie;
 jakie operacje powinny być przez nie wykonywane;
 jakie operacje nie powinny być przez nie wykonywane.
Oto kilka przykładów definicji odpowiedzialności.

4
Value Object
 Grupuje dane należące do pewnej całości.
 Nie jest trwale przechowywany.
 Pozwala nazwać konkretny byt z domeny.
 Nie jest unikatowy.
 Przykłady: NumerTelefonu, KodPocztowy.
 Implementowany na podstawie wzorca Immutable.
 …
Entity
 Obiekt, który musi być unikatowy.
 Ma dane oraz zachowanie biznesowe.
 Jest trwale przechowywany.
 Unikatowość obiektu zależy od konkretnego kontekstu i domeny.
 …
Repository
 Wyznacza warstwę do trwałego przechowywania danych.
 Abstrahuje od konkretnego sposobu persystencji.
 Zachowuje interfejs kolekcji.
 …
Application Service
 Mieści się w warstwie aplikacji.
 Wykonuje przetwarzanie wyznaczone przez przypadki użycia (kroki).
 …
Co się powinno dziać — przykłady:
Controller
 Przyjmuje żądanie.
 Dokonuje złożonej walidacji.
 Składa dane do wywołania serwisu.
 Wywołuje serwis.
 Wynik pakuje w JSON-a.
 Określa kolejny widok.

4
Czego nie powinno być — przykłady:

Controller
 Prostej walidacji (gdyż do tego celu wykorzystuje się biblioteki widoku).
 Złożonego przetwarzania JSON-a (z serwisu nie powinien przychodzić JSON).
 Logiki dziedzinowej, np. decydowanie na podstawie danych, czy zlecenie ma
być wykonane.
Powyższe definicje mają być jak najmniej książkowe, a w jak największym stopniu
zaczerpnięte z tego, co się dzieje w projekcie. Szczególnie ważne jest to, żeby określić,
czego nie powinno się robić w danym bloku budującym. To jest bardzo cenna informa-
cja o często popełnianych błędach. To ta część mantry, która jest najbardziej żywa.
Napędzaj
O tym się najczęściej zapomina. To tej części zawdzięczamy nazwę mantra. Żeby ar-
chitektura żyła w głowach członków zespołu, żeby się rozwijała, musi się ciągle o niej
mówić, musi się wokół niej cały czas coś dziać. Tymczasem uważamy, że wystarczy
wymyślić koncepcję, a reszta stanie się sama. Trzeba działać i to przynajmniej na kilku
frontach.
1. Zdefiniuj, jak jest i jak powinno być.

Zaangażuj cały zespół lub kluczowe osoby, aby zdefiniować główne elementy mantry
zgodnie z pierwszymi dwoma punktami. Odróżnij dwa stany rzeczy: jak jest i jak po-
winno być. Zdarza się tak, że spora część osób doskonale wie, jak powinno być, a mimo
to założenia architektoniczne nie są realizowane.
2. Rozpowszechnij.
Zwołaj spotkanie i przedyskutuj mantrę. Ustal, od kiedy obowiązuje. Zorganizuj uwi-
docznienie mantry w formie fizycznej (rysunki na flipchartach) lub w formie elek-
tronicznej w przypadku dużych zespołów. Jeśli trzeba, roześlij maile informacyjne.
Niech to będzie wydarzenie.
3. Monitoruj.
Jeśli używasz Definition of Done2, dodaj jako jeden z punktów weryfikację, czy roz-
wiązanie jest zgodne z mantrą. Analogicznie dla przeglądów kodu — niech to będzie
jeden ze sprawdzanych elementów.
4. Rób retrospekcje.
Rób regularne spotkania, w czasie których w zespole dyskutujecie, w jakim zakresie
mantra jest realizowana i czy jest to stan satysfakcjonujący, a jeśli nie, to co należy
zmienić. Niech te retrospekcje będą poświęcone wyłącznie architekturze.
2
Lista kryteriów jakościowych wykonania zadania.

4
5. Modyfikuj
Mantra to żywy byt. Musi się rozwijać. Szczególnie sekcja „Czego się nie powinno
robić?”. Ona powstaje na bazie doświadczeń. Wcześniej wymieniona retrospekcja to
również czas na zadanie sobie pytań: „Czy obecna postać architektury jest wystar-
czająca? Może należy wprowadzić istotną zmianę? Może dla wybranej części systemu
należy wprowadzić inne rozwiązanie (np. maszynę stanową albo osobny model)?”.
Kod z historią
A jak zastosować koncepcję mantry w kodzie, który ma już za sobą długą historię
rozwoju? Nierzadko zdarza się tak, że pierwsze wiersze systemu były pisane w C,
później w C++, następnie w Javie, a potem dołożono do tego szynę ESB. Każde z tych
podejść powodowało, że stosowano inne techniki do rozwiązywania podobnych pro-
blemów. W takich przypadkach w systemie pojawia się wiele różnych rozwiązań.
Często brakuje ustalenia, co powinno się robić w przypadku modułu X, w którym
dominują praktyki z C++, a co w module Y, gdzie większość kodu przypomina język C.
W takim razie stosuje się kilka mantr, różnych dla różnych części systemu (rysunek 7.7).
Rysunek 7.7. Wiele mantr architektonicznych w kodzie z historią
Podsumowanie
Zarządzanie wiedzą to obszar, którym trzeba zarządzić i bez świadomego działania
można się spodziewać co najwyżej problemów. Powinieneś zadbać o stworzenie spójnej
ścieżki wprowadzania nowych osób do zespołu, ustalenie jednolitych zasad pracy z ko-
dem, organizować wydarzenia, które będą sprzyjać wymianie doświadczeń, wprowadzać
praktykę stosowania przeglądów kodu. Aby tchnąć nieco energii w członków zespołu,
zadbaj o to, by raz na jakiś czas mogli wziąć udział w szkoleniu lub konferencji, które
są dobrymi źródłami inspiracji. A przede wszystkim koniecznie wdróż mantrę archi-
tektoniczną, która pomaga uspójnić wiedzę o projekcie oraz pozwoli ją na bieżąco
aktualizować.

4

4

4
Rozdział 8.
RELACJA Z BIZNESEM
Relacja między klientem a IT to zagadnienie wymagające szczególnie dużo uwagi ze

strony lidera. To najczęściej w tym miejscu zaczynają się kluczowe problemy projekto-
we. Jeśli nie ma ustalonych reguł współpracy często zdarza się, że jedna ze stron zaczyna
dominować. W skrajnych przypadkach może to oznaczać uległość lub terror ze strony IT.
Antywzorce współpracy
Poniżej zostały opisane przykłady często występujących problemów w relacji biznes
– zespół oraz typowe objawy tych problemów.
Uległość zespołu technicznego

 Zespół realizuje każde wymaganie biznesu, bez względu na konsekwencje i wagę
biznesową tych wymagań.
 Zespół nie ma realnego udziału w decyzjach projektowych — nie są brane pod
uwagę aspekty istotne z punktu widzenia technicznego, takie jak: rozwój ar-
chitektury, refaktoryzacja, brakuje odniesienia decyzji biznesowych do kon-
sekwencji technicznych.
 Różne jednostki biznesowe walczą o zasoby zespołu niewybrednymi środkami
(np. poprzez nieuzgadniane rozszerzanie zakresu, nieuwzględnianie możliwości
przerobowych zespołu, zapewnianie partykularnych interesów poza oficjalnymi
kanałami komunikacji).

4
Terror ze strony zespołu technicznego

 Zespół forsuje własne rozwiązania w produktach, a aspekty biznesowe schodzą
na dalszy plan.
 Zespół zmusza biznes do posługiwania się nomenklaturą techniczną.
 Zespół jednostronnie stwierdza, że danego rozwiązania nie da się wprowadzić.
 Zespół odmawia wykonywania priorytetowych zadań, zasłaniając się dużą ilością
pracy.
Gry projektowe
 Wśród kierowników projektów panuje przekonanie: „Programiści zawsze prze-
szacowują, więc ja to dzielę na pół. Nie wiem, dlaczego szacują coraz bardziej
pesymistycznie”.
 Stosuje się arytmetykę opartą na osobodniach — np. kiedy dana osoba pracuje
w dwóch projektach, zakłada się, że będzie to 0,5 osobodnia w projekcie A i 0,5
osobodnia w projekcie B.
 Kierownik projektu naciska na nieuwzględnianie ryzyka w wycenie zadań, a póź-
niej rozlicza zespół, jeśli to ryzyko się zmaterializuje.
 Zespół przeszacowuje, żeby mieć bufor bezpieczeństwa.
Brak zaangażowania
 Klient jest niedostępny, przez co zespół sam musi podejmować decyzje o prio-
rytetach i wymaganiach.
 Klient jest niedecyzyjny — decyzje są odwlekane, co powoduje, że później jest
niewiele czasu na ich wdrożenie.
 Klient nie interesuje się działaniami zespołu w trakcie realizacji, odbiory są po-
wierzchowne, a problemy są identyfikowane długo po czasie wdrożenia i naj-
częściej eskalowane.
IT jako źródło kosztów

 Podejmowane są odgórne decyzje, do zespołu docierają szczątkowe informacje.
 Zespół nie może podjąć żadnego działania, którego nie da się wprost zaliczyć
w koszt projektu.
 Zespół jest zmuszany do niedoszacowywania swojej pracy, aby zrealizować
założony budżet.

4
Rozdział 8. Relacja z biznesem 107
 Brakuje zainteresowania realizacją technicznych aspektów rozwoju systemu,

takich jak uspójnianie architektury czy refaktoryzacja systemu, i przyzwolenia
na te aspekty.
Relacja przyjacielska
 Współpraca oparta jest na luźnych, nie do końca jasno określonych zasadach.
 Problemy i ryzyka nie są konkretyzowane.
 Terminy się przesuwają lub brakuje zobowiązań.
 Są tolerowane niedociągnięcia i niska jakość.
 Brakuje procesu poprawy efektywności pracy
Dobre praktyki
Jak widać, potencjalnych problemów może być wiele, jednak jako liderzy możemy
mieć realny wpływ na przebieg prac i zapobiegać kłopotom. Kluczowe działania, które
warto podejmować:
 Wspólne zdefiniowanie relacji między klientem a IT — jakie są odpowie-
dzialności po obu stronach, gdzie są one wyraźnie rozdzielone, a gdzie granice
odpowiedzialności się zacierają; jakie role i przez kogo są reprezentowane.
 Ustalenie zasad współpracy — przykłady: określenie, w jaki sposób reagujemy
na sytuacje problemowe, jak w takich momentach podejmowane są decyzje,
w jaki sposób weryfikujemy ostateczne zakończenie zadania, jak się rozliczamy,
jak często się spotykamy, jeśli dana osoba jest mało dostępna; w jaki sposób
będzie przebiegać komunikacja i jak będą zapadać decyzje.
 Zaangażowanie zespołu w procesy decyzyjne i nadanie zespołowi faktycz-
nego prawa głosu — zespół jest jednym z interesariuszy projektu i powinien
wpływać na kształt zadań — nie tylko od strony technicznej, ale również od strony
zakresu, szczególnie gdy po stronie IT jest skumulowana wiedza biznesowa.
 Wprowadzenie zwyczaju regularnych retrospekcji — bez względu na to, jak
dobry mamy proces i zasady współpracy, należy je regularnie rewidować i dopa-
sowywać do charakteru obu stron; retrospekcje są do tego dobrym narzędziem.
 Zakwestionowanie praktyki pełnego wykorzystania zasobów — współcześnie
jednym z głównych problemów osób zarządzających jest chęć pełnego wyko-
rzystania posiadanych zasobów, w tym osób pracujących w projektach. Czę-
sto jest to zgubna praktyka, która w efekcie może powodować nieefektywność
w funkcjonowaniu procesu (np.: czekanie na decyzje, na efekty pracy, potrzeba
wielokrotnego poprawiania błędów).

4
Budowanie sieci wsparcia

Gdy jesteś liderem, Twój wpływ na to, co się dzieje, nie ogranicza się tylko do ze-
społu, ale również obejmuje inne działy czy klienta, z którym współpracujesz. Szcze-
gólnie w większych organizacjach jest wiele zasobów (takich jak: wiedza, informacje,
narzędzia, decyzje), o które trzeba zabiegać, gdyż nie są rozdzielane w sposób równo-
mierny. Ważną umiejętnością staje się networking. Badania pokazują, że liderzy, którzy
są pozytywnie oceniani przez współpracowników, spędzają średnio 70% czasu więcej
nad działaniami networkingowymi niż pozostali, dzięki czemu są lepiej poinformo-
wani, bardziej kreatywni, bardziej wydajni oraz łatwiej rozwiązują problemy, które
wymagają współpracy wielu stron. Poniżej znajdziesz kilka wytycznych, które ułatwią
Ci tworzenie efektywnych sieci wsparcia w Twojej organizacji.
Zrozum i wykorzystaj swój indywidualny styl — nie musisz być ekstrawertyczny,
żeby budować kontakty. Wybierz sposób, który Ci najbardziej odpowiada. Jeśli jesteś
introwertykiem, prawdopodobnie bardziej będą Ci na rękę spotkania w niewielkim
gronie.
Dowiedz się jak najwięcej o swojej organizacji — o jej strukturze, o osobach decy-
zyjnych, o zależnościach. Postaraj się porozmawiać o tym ze swoim przełożonym, który
prawdopodobnie lepiej zna organizację niż Ty. Przedyskutuj, które osoby w organizacji
mogą być dla Ciebie kluczowe i w jaki sposób możesz na nie wpłynąć.
Zorganizuj spotkania z osobami kluczowymi — powodem do zorganizowania spo-
tkania może być chęć poznania perspektywy drugiej strony, aby dowiedzieć się, co
przeszkadza, co się podoba i jakie są oczekiwania odnośnie do współpracy z Twoim
zespołem. Dowiedz się, co jest ważne dla drugiej strony. Jeśli będziesz to wiedział,
zastanów się, w jaki sposób w dłuższej perspektywie możesz pomóc w tym obszarze.
Spotkania mogą być formalne lub nieformalne — wykorzystaj do tego celu: lunche,
spotkania firmowe w większym gronie, wydarzenia firmowe, uczestnictwo w konfe-
rencjach, na które wybierają się inne osoby z organizacji. Z drugiej strony starannie
dobieraj swoje działania, gdyż nie wszystkie wydarzenia są jednakowo istotne.
Poproś swojego przełożonego lub inną osobę w organizacji, z którą masz dobre relacje,
abyś mógł się pojawiać na spotkaniach, które dotyczą Twojego projektu, na wyższym
poziomie niż ten, na którym się znajdujesz.
Znajdź mentora — osobę, która ma większy niż Ty staż w organizacji i może Ci
pomóc nawiązać kontakty lub stworzy pretekst do spotkań z innymi osobami w Twojej
firmie.
Givers gain — zacznij od siebie. Jeśli chcesz otrzymać wsparcie w organizacji, wyjdź
z inicjatywą. Zastanów się, w jaki sposób możecie Ty i Twój zespół pomóc innym
zespołom. Może niedużym kosztem Twój zespół programistyczny może pomóc zauto-
matyzować proces testowania dla testerów. Zastanów się, jaką wartość jesteś w stanie
dostarczyć innym: może to być czas, informacje, wiedza lub umiejętności.

4
Zacznij od angażowania współpracujących zespołów w małe rzeczy, które nie są

pracochłonne, a spowodują nawiązanie współpracy (np. dostarczenie pewnych danych,
które mogą być dla Ciebie przydatne).
Zainicjuj wielozespołowy projekt, który wszystkim przyniesie wartość (np. wdrożenie
podejścia zwinnego w realizacji projektów), a wymaga zaangażowania kilku zespołów.
Organizuj spotkania lub uczestnicz w zebraniach, na których zespoły mogą pre-
zentować efekty swojej pracy. Bądź ciekaw, z jakimi problemami radzą sobie inne ze-
społy, a w czym mogą potrzebować pomocy. Analogicznie zaprezentuj swój zespół
— naucz się mówić o osiągnięciach swoich i Twojego zespołu, w ten sposób inni będą
mieli okazję lepiej Cię poznać.
Powyższe działania powinny być podejmowane regularnie. Stwórz plan działania, spo-
sób weryfikacji postępów — potraktuj to jako projekt. Budowanie prawdziwej sieci to
zadanie długotrwałe, które trwa wiele miesięcy. Uzbrój się w cierpliwość i nie oczekuj
natychmiastowych efektów.
Ustalanie zasad współpracy

Jakiś czas temu zatrudniłem osobę do przeprowadzenia niewielkiego remontu w moim
mieszkaniu. Oczywiście zatrudniłem ją, licząc na to, że profesjonalnie wykona swoje
zadanie. Szybko zdałem sobie sprawę, że oprócz tego miałem różnego rodzaju ocze-
kiwania:
 żeby przychodziła na czas;
 żeby nie przesuwała mebli bez mojej zgody;
 żeby nie paliła w mieszkaniu;
 żeby nie używała mojego odkurzacza do usuwania brudu będącego efektem
remontu;
 żeby nie myła pędzli w umywalce, która znajduje się w łazience;
 żeby każdą zmianę wykonania konsultowała ze mną co najmniej telefonicznie;
 żeby na koniec każdego dnia sprzątała po swojej pracy.
Nie uzgodniliśmy tych zasad wcześniej, toteż często zdarzały nam się konfliktowe
sytuacje, które negatywnie wpływały na kształt współpracy.
Podobnie bywa również w przypadku projektów programistycznych, szczególnie na
styku współpracy klienta i IT. Każda ze stron przychodzi z niewypowiedzianymi
oczekiwaniami, które niezrealizowane powodują irytację i frustrację. Dlatego zachęcam
do tego, aby ustalić zasady wzajemnych relacji. Najlepiej jeśli wydarzy się to na po-
czątku współpracy, wtedy można uniknąć wielu nieprzyjemnych rozmów. Niemniej
jednak również warto to zrobić, jeśli już jakiś czas współdziałacie ze sobą — wtedy
można bazować na dotychczasowych doświadczeniach.

4
Poniżej znajdziesz scenariusz spotkania, którego celem jest wypracowanie zasad

współpracy.
1. Zaproś wszystkie zaangażowane strony, które uczestniczą bezpośrednio w pra-
cach (zespół i osoby po stronie klienta). Można wykorzystać do tego celu re-
trospekcję.
2. Wyjaśnij cel ustalenia zasad współpracy. Dobrze jest przedstawić propozycje,
które mogą się pojawić na liście zasad.
3. Poproś każdego uczestnika o zapisanie na kartkach samoprzylepnych oczeki-
wań (jedna kartka — jedno oczekiwanie).
4. Poproś, aby każdy przeczytał to, co zapisał, oraz uzupełnił komentarzem, jeśli
to potrzebne.
5. Następnie wspólnie pogrupujcie tematy i nadajcie im nazwy.
6. Przydziel każdemu 3 – 5 głosów i poproś o zagłosowanie na najistotniejsze jego
zdaniem zagadnienia.
7. Przedstaw zagadnienia, które uzyskały największą liczbę głosów, i jeśli potrzeba,
razem z uczestnikami skonkretyzuj sposób ich realizacji. Efekty pracy zapisz
na flipcharcie.
8. Ustal z uczestnikami spotkania, jak często będziecie monitorować realizowanie
zasad. Może się to odbywać w ramach retrospekcji.
9. Umieść zasady współpracy w miejscu, gdzie pracuje zespół, tak aby były dla
wszystkich widoczne.
Na liście z zasadami może się pojawić niemal wszystko, co ma znaczenie dla którejś
ze stron. Oto kilka przykładów:
 Zanim zmiana w sposobie działania systemu zostanie zaakceptowana, powin-
na być przedyskutowana z zespołem na osobnym spotkaniu.
 Jeśli reprezentant klienta nie może być na spotkaniu planistycznym, najpóźniej
dzień wcześniej przesyła mailem swoje wytyczne spełniające założenia Definition
of Ready1.
 Zespół, gdy tylko jest świadomy, że założony zakres prac nie zostanie zreali-
zowany, natychmiast informuje o tym klienta.
 Jeśli jest konieczność zrealizowania nowego wymagania w trakcie iteracji, jest
to ustalane z zespołem oraz w efekcie inne wymaganie powinno zostać usu-
nięte z listy zadań zaplanowanych do realizacji.
 Kiedy okaże się, że na jednym z nowych urządzeń nie działa oprogramowanie,
należy to traktować jako nową funkcjonalność do wykonania, a nie jako błąd
programistyczny.
1
Jeden z artefaktów szkieletu Scrum określający kryteria, które musi spełniać wymaganie, aby mogło
być zrealizowane przez zespół.

4
 Szacowanie nie jest zobowiązaniem. Jeśli zespół źle oszacował zadanie, np.
pod wpływem nacisku klienta, nie ma obowiązku ukończenia zadania w zało-
żonym terminie.
Indeks zadowolenia
Bez względu na to, jak dobra jest relacja między stronami, podlega ona dynamicznym
zmianom, które warto monitorować i reagować w przypadku dużych zmian. Do tego
celu może posłużyć bardzo proste narzędzie, jakim jest Indeks zadowolenia (Happiness
index). Świetnie się nadaje jako narzędzie retrospekcyjne.
Każda z osób odpowiada na pytania::
1. Jak bardzo jesteś zadowolony ze współpracy (w skali 1 – 5)?
2. Co ci się najbardziej podoba?
3. Co ci się najmniej podoba?
4. Co mogłoby zwiększyć twoje zadowolenie?
5. Inne komentarze.
Ostateczny wynik to średnia całego zespołu dla pierwszego pytania (rysunek 8.1),
natomiast pozostałe odpowiedzi są źródłem tematów do dyskusji.
Rysunek 8.1. Wizualna forma przedstawienia Indeksu zadowolenia
Mapa relacji
Zachęcam Cię do skorzystania z niezwykle prostego narzędzia, jakim jest Mapa relacji.
Czasami to, co trudno jest dostrzec na co dzień, łatwiej jest zobaczyć naszkicowane
w formie prostego rysunku (rysunek 8.2).

4
Rysunek 8.2. Przykładowa Mapa relacji
Weź kartkę papieru i narysuj wszystkie osoby, które biorą czynny udział w projekcie.
Zaznacz strzałkami relacje między poszczególnymi osobami (jeśli takowe zachodzą).
Niech wielkość, kolor, grubość strzałki w jakiś sposób odzwierciedlają charakter re-
lacji. Poświęć na stworzenie rysunku kilkanaście minut i postaraj się zawrzeć na nim
jak najwięcej szczegółów. Następnie zostaw rysunek na kilka dni, po to aby później
spojrzeć na niego świeżym okiem.
Spróbuj teraz zinterpretować rysunek.
 Co mógłbyś wywnioskować z tego rysunku?
 Jak zinterpretowałbyś strzałki i ich grubość?
 Jak zinterpretowałbyś relacje pomiędzy osobami? Może któreś z nich są odse-
parowane od innych? Może postaci na rysunku są większe niż inne albo
mniejsze? Co to może oznaczać?
 Czy na schemacie jest równowaga? A może jest wyraźna asymetria? Na czym
ona polega?
 Co zmieniłbyś na tym rysunku? Narysuj go jeszcze raz ze zmianami. Co
zmiany na rysunku oznaczałyby w rzeczywistości? Jak do tego doprowadzić?
Odpowiedzi na te pytania pozwolą Ci bardziej obiektywnie spojrzeć na bieżącą sytuację,
a także zastanowić się, jak możesz wpłynąć na to, co się dzieje. Proponuję Ci jeszcze
inne wariacje na temat tego ćwiczenia.
1. Poproś inną osobę, aby zadała Ci powyższe pytania. Najlepiej taką, która jest
zaznajomiona z coachingiem. Niech będzie dociekliwa.
2. Poproś inną osobę, aby zinterpretowała rysunek. Może ktoś inny zobaczy coś,
co Tobie trudno jest zobaczyć.
3. Wykonaj to ćwiczenie razem z zespołem i wspólnie dokonajcie analizy.

4
Kiedy możesz wykorzystać to narzędzie?

 jeśli chcesz stworzyć plan działań nad zmianą istniejących relacji — może to
być część Twojej wizji;
 jeśli chcesz bezpośrednio z klientem omówić Twoją perspektywę istniejącej
sytuacji — możesz poprosić klienta o zrobienie tego ćwiczenia, aby poznać
perspektywę zespołu, z którym współpracujesz;
 rysunek może być dobrą bazą do prowadzenia retrospekcji.
Analiza potrzeb
Mówi się, że nic tak nie wpływa pozytywnie na relacje, jak spojrzenie na sytuację
oczami drugiej strony. W tym obszarze poznasz dwa przykładowe narzędzia, które
mogą być użyte do tego celu.
Poziomy logiczne
Poziomy logiczne zostały bardziej szczegółowo opisane w rozdziale 13. „Efektywne
spotkania”. Jako przykład poniżej pokażę, jak można użyć poziomów logicznych, żeby
lepiej zrozumieć motywację działu biznesowego, który bezpośrednio współpracuje
z klientem,. Odpowiadając na poniższe pytania, staraj się znajdować pozytywne intencje
towarzyszące osobom, z którymi współpracujesz.
1. Jak opisałbyś środowisko?
 Dział utrzymania klienta — pracowników przyjęto nazywać konsultantami.
 Pięćdziesiąt osób w dziale, dwóch koordynatorów i jeden przełożony.
 Osoby, które mają wiedzę bankową.
 Osoby, które mają bezpośredni kontakt z klientem.
 Każda z osób pracuje niezależnie.
 Zadania, które nam dostarczają, pochodzą bezpośrednio od klientów.
2. Jak opisałbyś zachowania konsultantów?
 Na bazie informacji uzyskanych od klienta konsultanci piszą specyfikację.
 Konsultanci muszą podać klientowi czas wykonania zadania, które zostało
zgłoszone.
 Konsultanci wykonują testy akceptacyjne z dużymi opóźnieniami.
 Konsultanci w pierwszej dekadzie miesiąca mają dużo więcej pracy ze względu
na przygotowywanie raportów dla klientów.
 Konsultanci zgłaszają zadania, które nie zawsze potrafią wytłumaczyć.

4
3. Jakie konsultanci mają umiejętności? Jakich nie mają?

 Znają dobrze dziedzinę bankowości.
 Potrafią komunikować klientowi rodzące problemy sytuacje.
 Mają trudność ze zrozumieniem rzeczywistych potrzeb klienta.
4. Co jest ważne dla konsultantów? Jakie przekonania im towarzyszą?
 Chcą dotrzymać za wszelką cenę zobowiązań złożonych klientom.
 Chcą dostarczyć klientowi rzetelnych i poprawnych danych.
 Są nastawieni na spełnianie oczekiwań klientów.
 Mówią: „Klientowi nie można odmówić”.
5. Tożsamość:
 Są doradcami.
Teraz zadaj sobie pytania:
 Co w Twoim postrzeganiu sytuacji zmienia ta analiza? Jakie pozytywne aspekty
w niej znajdujesz?
 Jak możesz pomóc, aby było realizowane to, co jest ważne dla Twoich współ-
pracowników?
 Czy możesz nauczyć drugą stronę czegoś, co by ułatwiło dalszą współpracę?
Mapa empatii
Drugie narzędzie, które może pomóc zrozumieć drugą stronę, to Mapa empatii (ry-
sunek 8.3). Przygotuj większą kartkę (A3 lub A4) i podziel ją na 4 części, które zobrazują
postrzeganie świata z perspektywy drugiej strony. Postaraj się zrozumieć drugą stronę
poprzez zadanie sobie następujących pytań:
1. Co robi i mówi — zapisz, jakie działania podejmuje, zacytuj wypowiedzi, określ
prezentowaną postawę.
2. Co myśli i czuje — określ, czego się obawia, jakie ma aspiracje i przekonania,
jakie emocje jej towarzyszą.
3. Co słyszy — sprecyzuj, co mówią inni, co mówi ich przełożony, co twierdzą
autorytety.
4. Co widzi — zastanów się, co zauważa w swoim otoczeniu, co zauważa u współ-
pracowników.
5. Czego unika — określ, jakie są jej frustracje i jakim przeszkodom musi stawiać
czoła.
6. Czego chce — zapisz, czego potrzebuje, do czego dąży, jakie ma kryteria sukcesu.

4
Rysunek 8.3. Przykładowa Mapa empatii
Jako ćwiczenie proponuję Ci stworzyć mapę empatii dla osoby lub zespołu, z którym
współpracujesz.
Podobnie jak w przypadku poziomów logicznych, zadaj sobie pytania:
 Co w Twoim postrzeganiu sytuacji zmienia ta analiza?
 Jak możesz pomóc, aby było realizowane to, co jest ważne dla Twoich współ-
pracowników?
 Czy możesz nauczyć drugą stronę czegoś, co by ułatwiło dalszą współpracę?
Podsumowanie
Dbanie o relacje z biznesem to pięta achillesowa liderów IT. W organizacjach wystę-
puje wiele dysfunkcji, w tym pewne formy uległości lub terroru ze strony zespołu,
brak zaangażowania lub relacja przyjacielska, które prowadzą do obniżenia standardów
pracy. Kluczem do sukcesu jest chęć spojrzenia na sytuację z perspektywy drugiej

4
strony. Aby to było możliwe, w pierwszej kolejności należy tworzyć i utrzymywać

relacje poprzez nieustające działania networkingowe. Dalej: warto udzielać informacji
zwrotnej i pytać o nią, tak aby na bieżąco rozwiązywać zaistniałe problemy. Pomocne
może być ustalenie wspólnych zasad, które doprecyzowują wzajemne oczekiwania.
Wreszcie: warto regularnie wczuwać się w sytuację drugiej strony i zadawać sobie pyta-
nie: „A jak to wygląda z ich perspektywy”, używając poziomów logicznych lub Mapy
empatii.

4
Rozdział 9.
INFORMACJA ZWROTNA
Praktyki związane z informacją zwrotną

Otrzymywanie informacji zwrotnej to podstawowa potrzeba każdego pracownika.
Tak jak wspominałem w rozdziale 4. „Motywacja”, brak informacji zwrotnej od
przełożonego jest jednym z głównych powodów odejść pracowników z firmy. Mimo
to jest to praktyka traktowana przez liderów po macoszemu — albo nie udzielają oni in-
formacji zwrotnej, albo robią to w sposób, który bardziej demotywuje niż motywuje.
Do udzielania informacji zwrotnej można podejść dwojako: przekazuje się ją na bieżąco
lub raz na jakiś czas, najczęściej w formie rozmów okresowych. Ja sam mam wiele za-
strzeżeń do tej drugiej strategii: trudno wtedy odwoływać się do konkretnych sytuacji
i faktów, gdyż wydarzenia zdążyły się już dawno zatrzeć w pamięci. Dlatego tego typu
informacja zwrotna jest często nieefektywna, stanowi niewielką rzeczywistą wartość dla
osoby, której jest udzielana. Zdecydowanie bardziej efektywne jest przekazywanie in-
formacji zwrotnej jak najszybciej po zaistnieniu sytuacji, której informacja dotyczy.

4
Dlaczego nie udzielamy informacji zwrotnej

i jakie są tego konsekwencje?
Mimo iż wiemy, że informacja zwrotna jest ważna dla wszystkich, często jej nie przeka-
zujemy. Oto kilka powodów:
 obawiamy się, że możemy kogoś urazić poprzez niezręczne sformułowanie
opinii;
 uważamy, że każdy jest dorosły i odpowiada za swoje poczynania;
 obawiamy się, że reakcja drugiej strony może być bardzo emocjonalna;
 mimo braku informacji zwrotnej nie odczuwamy bezpośrednio negatywnych
konsekwencji takiego sposobu działania.
Poniżej możesz znaleźć konsekwencje, które mogą towarzyszyć nieudzielaniu infor-
macji zwrotnej:
 odbierasz innym szansę rozwoju — jeśli nie powiesz komuś, że jego praca jest nie-
efektywna, ta osoba może być święcie przekonana, że wszystko jest w porządku;
 brak informacji zwrotnej może być zinterpretowany jako brak zainteresowania;
 jeśli jesteś niezadowolony z czyjejś pracy, Twoje napięcie będzie narastać i za-
reagujesz emocjonalnie w najmniej odpowiednim momencie.
Korzyści
Jakie zatem korzyści może nieść informacja zwrotna? Oto kilka przykładów:
 osoba, która otrzymała informację zwrotną, może zmodyfikować swoje działanie;
 jeśli zachowa się odpowiednią formę informacji zwrotnej, dla obu stron taka
rozmowa będzie mieć wartość;
 po udzieleniu informacji zwrotnej opada napięcie;
 udzielając informacji zwrotnej, możesz mieć realny wpływ na to, co się dzieje
w zespole, i na współpracę z innymi.
Podstawowy błąd
Jeśli spojrzysz na rodziców, którzy chcą wychować swoje dzieci, usłyszysz zdania
zbliżone do poniższych:
 Nie wchodź na te schody!
 Nie rozlewaj zupy!
 Nie rozpraszaj się!
 Nie podchodź do psa!
 Nie wieszaj się na poręczy!

4
Rozdział 9. Informacja zwrotna 119
Cały czas dzieci słyszą: nie rób tego, nie rób tamtego, rzadko otrzymują komunikat,
który jasno by przekazywał, czego się od nich oczekuje. Poniżej znajdziesz kilka cy-
tatów przedstawiających przykłady informacji zwrotnych udzielanych w kontekście
zawodowym:
 Ale ten kod jest fatalny!
 Nie bądź taki pasywny na spotkaniach.
 Nie podważaj mojego zdania!
 Za długo czekałeś, zanim poinformowałeś, że jest poważny problem.
Jak widzisz, podobieństwo co do formy jest duże. Wielokrotnie się zdarza, że brakuje
jasnej informacji na temat tego, czego się oczekuje od drugiej strony, zakłada się bo-
wiem, że to jest oczywiste lub rozmówca domyśli się, o co chodzi.
Pamiętaj również o tym, żeby informacji zwrotnej udzielać zarówno w tych sytuacjach,
które odbierasz jako pozytywne, jak i interpretowanych jako negatywne. Niektóre
osoby udzielają np. tylko negatywnej informacji zwrotnej, zapominając o pochwałach,
co w efekcie daje poczucie braku równowagi. Na przykład w IT utarło się, że kiedy
wszystko działa poprawnie, jest to sytuacja neutralna, a kiedy coś nie działa, to jest
źle (rysunek 9.1). Bilans w takim przypadku jest negatywny, co w konsekwencji de-
motywuje zespół.
Rysunek 9.1. Negatywno-neutralna informacja zwrotna
Feedback i feedforward
Powyżej powiedziałem, że kluczowym błędem jest komunikacja negatywna, nakiero-
wana na to, czego druga osoba ma nie robić. Z tego powodu pamiętaj o podstawowej
zasadzie udzielania informacji zwrotnej:
Jasno definiuj, czego oczekujesz w określonych sytuacjach.
Zamiast się skupiać na tym, czego dana osoba ma nie robić, określ, czego byś oczekiwał.

4
Techniką, która może być przydatna w tym przypadku, jest feedback i feedforward.
Główne założenie jest takie: kiedy odnosisz się do sytuacji, którą odbierasz jako po-
zytywną, udzielasz informacji zwrotnej, przywołując przeszłość (feedback). Przykład:
To był bardzo dobry pomysł. Użyłeś tutaj wzorca strategii, dzięki czemu kod jest przy-
gotowany na kolejne wersje algorytmu szyfrowania.
W przypadku sytuacji, którą odbierasz jako negatywną, wypowiedź powinna się
składać z dwóch części:
1. Odniesienie do konkretnej sytuacji, co do której są uwagi.
2. Jasne określenie oczekiwań dotyczących przyszłości (feedforward).
Twoje oczekiwanie powinno być wykonywalne, tzn. Twój rozmówca powinien mieć
jasność, jakiego konkretnego działania oczekujesz. Spójrz na kilka przykładów, które
nie są wykonywalne:
 Chciałbym, żebyś lepiej zapamiętywał ustalenia ze spotkania.
 Chciałbym, żebyś był bardziej efektywny.
 Chciałbym, żebyś pisał lepszy kod.
Powyższe stwierdzenia są wieloznaczne i nie dają jasnej informacji odnośnie do
oczekiwań. Zamiast nich można użyć takich stwierdzeń:
 Chciałbym, żebyś po spotkaniu przygotowywał notatki i rozsyłał je uczestnikom
zebrania (zakładamy, że w taki sposób rozmówca lepiej zapamięta to, co było
treścią spotkania).
 Chciałbym, żebyś codziennie rano planował swoje zadania na dany dzień.
 Chciałbym, żebyś zastosował wskazówki generowane przez narzędzie do sta-
tycznej analizy kodu.
Wyróżnikiem dobrej informacji zwrotnej jest konkretność oczekiwania. W ostatnich
przykładach nie występują wieloznaczne słowa (np. efektywny, lepszy kod).
Wskazówki co do udzielania informacji zwrotnej

Poniżej znajdziesz kilka wskazówek dotyczących sposobu udzielania informacji
zwrotnej:
 Jeśli informacja zwrotna jest związana z sytuacją negatywną, przeprowadź ją
w cztery oczy.
 Informacji zwrotnej pozytywnej warto udzielić publicznie, jeśli jest to adekwatne
do danej sytuacji i nie będzie kłopotliwe dla osoby, której dotyczy.
 Posługuj się faktami, cytuj wypowiedzi, odnoś się do dat — wtedy to, co mówisz,
nie będzie budziło niepotrzebnych emocji.

4
 Na koniec poproś swojego rozmówcę o podsumowanie tego, co usłyszał — czę-

sto zakładamy, że nasza wypowiedź została zinterpretowana tak, jak byśmy
tego chcieli, co w rzeczywistości zdarza się rzadko.
Kanapka informacji zwrotnej

Dość popularną techniką udzielania informacji zwrotnej jest technika kanapki, w której
informację negatywną przekazuje się, niejako opakowując ją w pozytywne stwier-
dzenia. Główna struktura wygląda następująco:
1. Powiedz coś pozytywnego, co dotyczy Twojego rozmówcy
2. Przekaż docelową informację zwrotną.
3. Powiedz, coś pozytywnego, co dotyczy Twojego rozmówcy.
Jest to technika, co do której mam spore wątpliwości — ma charakter manipulacyjny,
gdyż próbuje się zmiękczyć to, co ma zostać powiedziane. Poza tym osoba, która otrzy-
muje tego rodzaju informację zwrotną, po pewnym czasie rozpoznaje schemat i za-
czyna traktować pozytywne elementy jako nieszczere lub dorzucone tylko na potrzeby
techniki.
Zespołowa informacja zwrotna

Poprzednio omówiłem udzielanie informacji zwrotnej indywidualnie. Ale warto dążyć
do tego, aby w całym zespole stworzyć kulturę udzielania sobie informacji zwrotnej.
Mogą Ci w tym pomóc poniżej opisane techniki.
Feedback każdy do każdego

Członek zespołu udziela każdemu z pozostałych współpracowników informacji zwrot-
nej na kartce, uzupełniając następujące zdania:
 W pracy z tobą podoba mi się…
 W pracy z tobą chciałbym, abyś…
Następnie w grupie każdy przedstawia podsumowanie na swój temat:
 omawia, jakie kwestie się pojawiły;
 mówi, z czym się zgadza;
 tłumaczy, co chciałby zmienić w związku z uwagami;
 odnosi się do tematów, które chciałby wyjaśnić, lub umawia się na rozmowę
w cztery oczy.

4
Metafora zespołu
Podgrupy wymyślają metaforę zespołu, która jest następnie przedstawiana lub ryso-
wana (np. błyszczący samochód bez silnika; łódź, w której każdy wiosłuje w innym
kierunku; taczki, które przemieszczają się bez załadunku). Potem następuje dyskusja:
 Co ta metafora mówi o sytuacji w zespole?
 Jakie są wspólne elementy zaproponowanych metafor?
 Jakie zdarzenia wpłynęły na taki obraz zespołu?
 Co chcielibyśmy zmienić?
Trudna informacja zwrotna

Udzielenie informacji nie zawsze jest łatwe i temu procesowi mogą towarzyszyć duże
emocje. Jeśli chciałbyś poznać nieco bardziej złożone podejście pomagające udzielić
informacji zwrotnej, przeczytaj rozdział 10. „Trudne rozmowy”.
Podsumowanie
Informacja zwrotna jest podstawowym narzędziem w pracy lidera, mimo to często się
o niej zapomina. Z jednej strony daje szanse skonkretyzowania i wyjaśnienia wzajem-
nych oczekiwań, a z drugiej jest wyrazem zainteresowania pracą drugiej osoby. Kiedy
udzielasz informacji zwrotnej, powinieneś się skupić przede wszystkim na tym, czego
oczekujesz, a nie poprzestawać na wypowiedzeniu tego, co Ci nie odpowiada. Warto
również rozwijać kulturę udzielania informacji zwrotnej w zespole. Mogą się tu przydać
techniki: feedback każdy do każdego lub metafora zespołu.

4

4

4
Rozdział 10.
TRUDNE ROZMOWY
Skąd się biorą emocje?

Współpraca z ludźmi jest złożona i bez względu na to, co będziemy robić, będą się
zdarzać sytuacje, w których ktoś będzie niezadowolony, sfrustrowany lub trudno będzie
uzyskać porozumienie. W tego typu relacjach pojawiają się emocje, które powodują,
że zamiast zmierzać do wypracowania rozwiązania, rozmowa staje się niemerytoryczna.
Poprzez trudne rozmowy będziemy rozumieć sytuacje, w których pojawiają się emocje.
Podam przykład, żeby łatwiej było zilustrować mechanizmy towarzyszące trudnym
rozmowom. Oto opowieść jednego z liderów:
Niedawno mieliśmy spotkanie zespołu i zastanawialiśmy się, jak zmienić nasz
sposób pracy. Od kilku tygodni myślałem nad wprowadzeniem Scruma i stwier-
dziłem, że to dobry moment, żeby o tym porozmawiać. Opowiedziałem zespołowi
o moim pomyśle. Jeden z członków zespołu stwierdził wtedy:
— Scrum w naszym przypadku jest kompletnie bez sensu.
— Rozmawiałem już z kilkoma znajomymi, którzy używają tego podejścia, i uwa-
żam, że się bardzo dobrze sprawdzi — odpowiedziałem zdenerwowany.
— A ja myślę, że stracimy tylko niepotrzebnie czas na wprowadzanie zmian —
usłyszałem w odpowiedzi.

4
Zdenerwowałem się jeszcze bardziej, bo miałem poczucie, że mój autorytet jest

zagrożony, a mój rozmówca nie wykazuje szacunku do mnie jako lidera, i w efek-
cie odpowiedziałem:
— Myślę, że boisz się zmiany i stąd twoja reakcja.
— Niczego się nie boję. Wiem, jak będzie. Pewnie się nasłuchałeś bajek o tym,
jak Scrum świetnie działa. Wprowadzimy go, a i tak nic się nie zmieni.
Sytuacja zrobiła się już naprawdę gorąca. Emocje zaczęły rosnąć.
Zestawmy opis tej sytuacji z modelem (rysunek 10.1), który przedstawia mechanizm
powstawania emocji1:
Rysunek 10.1. Model powstawania emocji
Na początku coś się dzieje lub się nie dzieje, coś zobaczymy lub coś usłyszymy.
W naszym przykładzie wydarzeniem, które spowodowało zdenerwowanie lidera, było
wypowiedzenie przez członka zespołu słów: „Scrum w naszym przypadku jest kom-
pletnie bez sensu”.
Obserwacja dociera przez zmysły do mózgu i ten próbuje ją zinterpretować.
Jeśli interpretacja wskazuje na to, że nasze potrzeby są zagrożone, powstaje emocja, któ-
ra ostatecznie jest pewnym odczuciem fizycznym ostrzegającym przed zagrożeniem.
W naszym przykładzie lider zinterpretował zaistniałą sytuację jako podważenie au-
torytetu i brak szacunku, co w efekcie spowodowało jego zdenerwowanie.
Jeśli interpretacja jest neutralna, nie ma żadnej reakcji.
Jeśli interpretacja jest pozytywna (tzn. występuje poczucie, że jedna z potrzeb zosta-
nie zaspokojona), pojawiają się pozytywne emocje.
1
Jest to uproszczony model postawania emocji.

4
Rozdział 10. Trudne rozmowy 127
Przedstawiony powyżej mechanizm sugeruje, że sami jesteśmy źródłem emocji, które

powstają wskutek interpretacji danej sytuacji. To samo wydarzenie może powodować
u dwóch różnych osób całkowicie różne reakcje. Kluczem do opanowania sztuki pro-
wadzenia trudnych rozmów jest odnalezienie potrzeb, których zaspokojenie zostało
zagrożone po obu stronach.
Co niszczy kontakt?
W sytuacjach emocjonalnych często używamy sformułowań powodujących, że druga
strona zamiast nas zrozumieć, przestaje słuchać i myśli nad ripostą. Warto mieć świa-
domość, co może powodować wzmożone emocjonalne reakcje rozmówcy, dlatego
omawiam poniżej kilka często popełnianych błędów. Należy jednak pamiętać, że odbiór
komunikatu w dużym stopniu zależy od kontekstu, w którym się pojawił — od relacji
z drugą osobą, konkretnej sytuacji lub od tego, co się wydarzyło wcześniej.
Przerzucanie odpowiedzialności za własne emocje

Zdenerwowałeś mnie.
Poczułem się zaatakowany.
Te zdania zawierają niebezpośredni zarzut, że to druga strona jest winna wywołania
negatywnych emocji.
Sugerowanie intencji, która towarzyszy drugiej stronie

Myślę, że zrobiłeś to na złość.
Myślę, że nie przemyślałeś tego rozwiązania.
Te wypowiedzi zawierają interpretację motywacji rozmówcy.
Niemówienie jasno, czego się chce

Nie akceptuję twojego podejścia.
W tym stwierdzeniu brakuje jasnej informacji, czego mówiący oczekuje. Zamiast tego
komunikat określa, czego nie chce.
Niemówienie konkretnie, czego się chce

Powinieneś być bardziej proaktywny.
Jest niejasne, co kryje się za wyrazem: proaktywny.

4
Udzielanie rad
W takich sytuacjach powinieneś rozpocząć od projektu na kartce.
Wiele osób odbiera tego typu komunikat jako pouczanie, co budzi w nich negatywne
emocje. Jednak w relacji mentor – uczeń taka wypowiedź z pewnością zostanie ode-
brana neutralnie.
Pocieszanie
Myślę, że następnym razem będzie lepiej.
W niebezpośredni sposób została podana informacja, że komuś coś nie wyszło.
Załatwianie spraw za kogoś

Wyślij mi kawałek kodu, w którym nie możesz znaleźć przyczyny błędu.
Takie podejście może być odebrane jako brak przekonania, że druga strona może sobie
poradzić z danym tematem.
Litowanie się
Ten PM wyraźnie uwziął się na ciebie.
Dokonano interpretacji, co zmniejsza szansę na dotarcie do sedna problemu.
Ocenianie, opinie, interpretacje

Teraz masz problem, bo powierzchownie podszedłeś do tematu.
Wypowiadający zdanie stawia się w roli kogoś uprawnionego do wydawania opinii
w danej sprawie.
Licytowanie się
A ile masz zwrotów? Ja tylko dwa.
Próba obniżenia statusu drugiej strony.

4
Elementy klarownego komunikatu

Powyższe zdania to przykłady typowych błędów, jednak trudno na co dzień pamiętać
o wszystkich możliwościach. Z tego powodu skupię się na tym, w jaki sposób warto
formułować komunikat. Przedstawię schemat postępowania — jego zastosowanie sprawi,
że będzie bardziej prawdopodobne, iż to, co powiesz, nie zostanie odebrane jako atak.
Może masz wątpliwości, czy jest sens posługiwać się takim wzorcem, który na co dzień
może brzmieć sztucznie. Otóż nie chodzi o stosowanie go w codziennych rozmowach,
a jedynie o używanie tego schematu jako narzędzia do ćwiczeń — dzięki niemu w czasie
trudnych rozmów dużo łatwiej będziesz mógł formułować klarowne komunikaty, uży-
wając codziennego języka. To tak jak z nauką gramatyki języka obcego: po pewnym
czasie przestaje się o niej myśleć i staje się ona integralną częścią wypowiadanych
przez uczącego się zdań.
Omawiany schemat składa się z czterech kroków (rysunek 10.2):
1. Co zaobserwowałeś?
2. Co w związku z tym czujesz?
3. Dlaczego to jest dla ciebie ważne?
4. O co prosisz?
W przypadku sytuacji, która została opisana na początku, można by było następująco
sformułować wypowiedź:
(1) Kiedy powiedziałeś, że w naszym przypadku Scrum jest kompletnie bez sensu,
(2) poczułem zdenerwowanie,
(3) bo zależy mi na tym, aby nasza rozmowa była rzeczowa,
(4) toteż chciałbym, żebyś wyjaśnił, dlaczego uważasz, że Scrum się u nas nie
sprawdzi.
Zdenerwowanie lidera wynikało z tego, że jego propozycja została skrytykowana bez
odwołania się do konkretnych argumentów i faktów. Powyższe zdanie klarownie to
wyraża.
Poniżej omawiam osobno każdy z tych elementów.
Obserwacja
Jednym z elementów klarownego komunikatu jest obserwacja. Często w sytuacjach,
kiedy emocje biorą górę, zaczynamy używać zniekształceń typu: „nigdy”, „ty zawsze”,
„nie zależy ci na tym projekcie”, „nie przyłożyłeś się”. Są to stwierdzenia, z którymi
druga strona najprawdopodobniej zacznie polemizować, i zamiast rozmawiać o sed-
nie sprawy, zaczniecie się spierać o to, czy „zawsze”, czy „nie zawsze” ktoś coś robi.
Dlatego staraj się opisać w sposób obiektywny sytuację, która doprowadziła do emocji.

4
Określ konkretny moment, który sprawił, że pojawiła się emocja — co się stało tuż
przed. Opisz, co byś zobaczył na nagranym filmie, który przedstawiałby tę sytuację.
Na filmie nie widać „zawsze”, „nigdy”, „nie zależy ci”, za to być może będzie słychać
czyjąś wypowiedź, być może będzie widać konkretny ruch, wydarzenie. Opisz to,
opierając się na faktach. Żeby sobie pomóc, możesz zacząć od słów:
Kiedy widzę…
Zobaczyłem…
Kiedy słyszę… (zacytuj czyjąś wypowiedź)
Usłyszałem… (zacytuj czyjąś wypowiedź)
Wydarzyło się…
W przypadku sytuacji, która ma dłuższą historię, przytocz główne punkty historii:
Rozmawialiśmy trzy miesiące temu o podwyżce i ustaliliśmy, że dostanę ją, gdy
przyjmę rolę lidera i zakończy się projekt Y. Projekt się zakończył, a podwyżki
nie dostałem…
W tabeli 10.1 znajdziesz przykłady sformułowanych opinii, interpretacji i innych znie-
kształceń oraz odpowiadające im obserwacje, tak abyś mógł lepiej zrozumieć różnicę.
Rodzące emocje słowa zostały pogrubione.
Tabela 10.1. Przykłady zniekształceń oraz odpowiadających im obserwacji
Opinia, interpretacja, zniekształcenie Obserwacja

Kiedy zarzuciłeś, że Scrum jest do niczego… Kiedy powiedziałeś, że „w naszym przypadku
(interpretacja) Scrum jest kompletnie bez sensu”…
Nigdy nie przesyłasz mi raportów na czas! W piątek minął termin przesłania raportu
(generalizacja) i do dzisiaj go nie otrzymałem.
Ciągle się spóźniasz na standupy. Trzeci raz w tym tygodniu przyszedłeś
(generalizacja) 5 minut po rozpoczęciu standupu.
Nigdy nie odpisujesz na moje maile. Wysłałem ci w tym tygodniu trzy maile w sprawie
(generalizacja) klienta X i nie otrzymałem odpowiedzi.
Czuję się oszukany, że nie chcesz mi dać Rozmawialiśmy trzy miesiące temu o podwyżce
podwyżki mimo naszych wcześniejszych i ustaliliśmy, że dostanę ją, gdy obejmę rolę
ustaleń. (interpretacja) lidera i zakończy się projekt Y. Tak się stało,
a podwyżki nie dostałem…

4
Emocje
Drugim elementem klarownego komunikatu są emocje. W sytuacjach zawodowych nie
jesteśmy przyzwyczajeni do mówienia o emocjach. Niektórzy nawet myślą, że to może
być nieprofesjonalne. Z drugiej strony nazwanie emocji powoduje, że do rozmówcy
dociera w ten sposób informacja „To jest dla mnie ważne”.
Ponieważ rzadko nazywamy emocje, nasze słownictwo często jest dość ubogie w tym
obszarze. Poniżej znajdziesz zestawienie, które pozwoli Ci bardziej adekwatnie na-
zywać swoje uczucia.
Poirytowany Zaskoczony Sfrustrowany
Zestresowany Przytłoczony Obawiam się
Zmartwiony Rozczarowany Zmęczony
Wystraszony Znudzony Podenerwowany
Bezsilny Zniecierpliwiony Zmieszany
Zdesperowany Zniechęcony
Ważne, żeby mówić z perspektywy „ja”, mówić o swoich emocjach i o sobie jako źró-
dle emocji, gdyż jak pisałem wcześniej, emocje są wynikiem naszej subiektywnej in-
terpretacji. Nie przerzucaj odpowiedzialności na drugą stronę, gdyż zostanie to odebra-
ne jako atak.
(ja) Zdenerwowałem się.
Ale nie:
Zdenerwowałem się przez ciebie (ty).
To, co zrobiłeś (ty), zdenerwowało mnie.
(ty) Zdenerwowałeś mnie.
Potrzeby
To jeden z trudniejszych elementów tej techniki, ponieważ wymaga jasnego określenia
tego, na czym Ci zależy. Pamiętaj, że kiedy pojawiają się emocje, najczęściej oznacza
to, że dzieje się coś ważnego.
W tym przypadku możesz rozpocząć zdanie od „Zależy mi…” lub „Ważne jest dla
mnie…”. Skupiaj się przede wszystkim na tym, co jest dla Ciebie istotne, a nie na
tym, czego byś nie chciał. W tabeli 10.2 znajdziesz kilka przykładów, jak w sposób kla-
rowny wyrazić swoje potrzeby.

4
Tabela 10.2. Przykłady jasnego wyrażania swoich potrzeb
Zamiast… Powiedz…
Mam wrażenie, że i tak zrobisz po swojemu. Zależy mi na tym, aby mieć jasność, czego
(w czasie rozmowy, podczas której lider mogę się spodziewać…
proponuje swoje rozwiązanie, a programista
się nie odzywa)
Przestań mi mówić, co mam robić. Chciałbym wywiązać się z podjętych wcześniej
(po usłyszeniu wypowiedzi, w której druga zobowiązań.
osoba próbuje wymusić wykonanie zadania
w trybie natychmiastowym)
Mój szef lawirował co do mojej podwyżki. Chciałbym mieć jasność, czego mogę się
(osoba opowiada o tym, jak jej przełożony spodziewać w tej sprawie…
nie chciał podjąć decyzji o podwyżce)
Nie chcę się spóźnić. Chcę się wywiązać ze zobowiązania wobec
klienta.
Przestań się obijać. Chciałbym mieć pewność, że wszyscy są
zaangażowani.
Prośba
Ostatnim krokiem jest jasna informacja, czego konkretnie oczekujesz. Jakie działanie
powinna wykonać druga strona, żebyś miał poczucie, że Twoje potrzeby zostaną za-
spokojone. Prośba powinna być tak sformułowana, żeby druga strona miała jasność,
co miałaby zrobić. W tabeli 10.3 znajdziesz przykłady niekonkretnie określonej prośby
(pogrubiono budzące emocje sformułowania) oraz ich odpowiedniki.
Tabela 10.3. Przykłady klarownego wyrażania prośby
Zamiast… Powiedz…
Chciałbym, żebyś był bardziej proaktywny. Chciałbym, żebyś zaczął zgłaszać pomysły zmian
(niekonkretne) na retrospekcji…
Chciałbym, żebyś lepiej zapamiętywał to, Chciałbym, żebyś zapisywał to, o czym mówimy
o czym mówimy na spotkaniach. na spotkaniach, i przysyłał mi podsumowanie.
(jak miałby to zrobić?)
Chciałbym, żebyś pisał czystszy kod. Chciałbym, żebyś zaczął się stosować do
przyjętego standardu kodowania i wprowadzał
zmiany zgłoszone w ramach przeglądu kodu.
W tabeli 10.4 znajdziesz rozwinięcie kilku wcześniej przytaczanych przykładów o prośbę.

4
Tabela 10.4. Przykłady wyrażania prośby osadzone w kontekście potrzeby
Potrzeba… Prośba…
…zależy mi na tym, aby mieć jasność, …więc powiedz mi, czy wykonasz zadanie
czego się mogę spodziewać… według mojego, czy twojego pomysłu.
(programista nie zareagował w żaden
sposób na propozycję rozwiązania)
…chciałbym wywiązać się z podjętych …więc daj mi pół godziny, żebym mógł
wcześniej zobowiązań… przeanalizować, czy jestem w stanie podjąć
(a druga strona próbuje wrzucić zadanie na już) się tego zadania w tym terminie.
…chciałbym mieć jasność, czego się mogę …chciałbym, żebyśmy ustalili jasne kryteria
spodziewać w tym temacie… podwyżki i czas ich weryfikacji.
(szef nie chce dać podwyżki)
…chcę się wywiązać ze zobowiązań wobec …zorganizujemy spotkanie, na którym
klienta… zweryfikujemy i zmodyfikujemy nasz plan,
(termin zakończenia projektu jest zagrożony) tak aby skupić się na priorytetach.
…chciałbym mieć pewność, że wszyscy są …powiedz mi, co sądzisz o pomyśle

zaangażowani… wprowadzenie Scruma w zespole?
(osoba nie odzywa się na spotkaniu)
Druga pozycja
Wiesz już, w jaki sposób sformułować komunikat, żeby był klarowny i nie wzbudzał
niepotrzebnie emocji. Niemniej jednak nie jesteś w stanie przewidzieć reakcji drugiej
strony i mimo starań rozmowa może się rozwijać nie po Twojej myśli. Jest bardzo
prawdopodobne, że w dużej części przypadków tak będzie. Nie należy się tym przej-
mować, gdyż jest to szansa na lepsze zrozumienie drugiej strony.
Jeśli po usłyszeniu prośby druga strona zareagowała emocjonalnie, jej potrzeby nie
są zaspokojone. Żeby miała ochotę Cię słuchać, musisz najpierw ją usłyszeć. Stosując
poprzedni schemat, reagowałeś na sytuację z zamiarem uwypuklenia własnej per-
spektywy. Taki komunikat został wyrażony z tzw. pierwszej pozycji (perspektywy ja).
Teraz czas na użycie drugiej pozycji (perspektywy ty), co w praktyce oznacza: „Chcę
zrozumieć, jaka jest twoja intencja”.
Twoim zadaniem tym razem będzie wejście w skórę rozmówcy i próba określenia
pozytywnej intencji, która mu towarzyszy. Jest to niełatwe zadanie, gdyż zazwyczaj
w czasie rozmów, w których pojawiają się emocje, przypisujemy negatywne intencje
naszym rozmówcom, co jest główną barierą w porozumieniu.

4
W tym celu należy nieco zmodyfikować schemat prowadzenia trudnych rozmów:

(1) Co zobaczyłeś, co usłyszałeś?
(2) Co w związku z tym wydaje ci się, że czuje druga strona?
(3) Jak myślisz, dlaczego to jest ważne dla drugiej strony?
Wracając do naszego głównego przykładu:
(1) Kiedy powiedziałeś, że w naszym przypadku Scrum jest kompletnie bez sensu,
(2) poczułem zdenerwowanie,
(3) bo zależy mi na tym, aby nasza rozmowa była rzeczowa,
(4) toteż chciałbym, żebyś rozwinął swoją myśl, dlaczego uważasz, że Scrum u nas
się nie sprawdzi.
Załóżmy, że otrzymujesz taką odpowiedź:
Przecież powiedziałem — Scrum się nie nadaje do naszego kontekstu.
Wtedy możesz powiedzieć:
(1) Czy kiedy mówisz, że Scrum nie nadaje się do naszego kontekstu,
(2) to czujesz irytację,
(3) bo chciałbyś, abyśmy stosowali taką metodę pracy, która będzie adekwatna do
naszej sytuacji?
Próbowałeś zrozumieć perspektywę swojego rozmówcy — to, jakie towarzyszą mu
emocje (czy czujesz irytację) oraz co jest dla niego ważne (aby metoda pracy była ade-
kwatna). Ważne jest, aby Twoje sformułowanie miało charakter pytania, w przeciwnym
razie mogłoby to zostać odebrane jako próba narzucenia własnej interpretacji sytuacji
czy też wmówienia drugiej osobie jej intencji, co, jak mówiłem na początku, może
tylko pogorszyć sytuację.
W związku z tym, co powiesz, Twój rozmówca może się z Tobą zgodzić (Tak, zależy
mi na tym, aby wybrana metoda pracy była adekwatna do naszej sytuacji) albo nie
zgodzić, wtedy niemal na pewno będzie próbował sprostować Twój domysł i usły-
szysz jego rzeczywistą intencję (np. Nie, tak naprawdę nie wierzę, że Scrum zadziała,
bo u znajomego w firmie już tego próbowali i im nie wyszło).
Bez względu na to, co się wydarzy, będziesz znać już intencje — własną i drugiej
strony. Teraz możesz szukać takiego rozwiązania, które uwzględni obydwie potrzeby.
W tym przypadku:
(ja) zależy mi na rzeczowej rozmowie.
(ty) chcę mieć pewność, że użyjemy adekwatnej metody.

4
Mógłbyś też zaproponować coś takiego:

To wyjaśnij mi (intencja: rzeczowa rozmowa), dlaczego masz obawy, że Scrum
będzie nieadekwatny w naszej sytuacji (intencja: mieć pewność, że metoda będzie
adekwatna).
Możesz usłyszeć taką odpowiedź:
Uważam, że nasz klient nie będzie współpracował z nami według zasad Scruma.
Zaczynacie rozmawiać o konkretnej obawie, dalej można już prowadzić rzeczową
rozmowę.
Rysunek 10.2. Perspektywa ja i ty a cztery kroki
Powyższy przykład daje pewne wyobrażenie tego, jak można się posługiwać schema-
tem prowadzenia trudnych rozmów (używając perspektyw ja i ty). Chcę uprzedzić, że
nie jest to jedyny sposób. W przypadku komunikacji nie istnieje „najlepsze rozwiązanie”.
Każde rozwiązanie, które pozwala się porozumieć, jest poprawne. Metoda, którą
przedstawiłem, nazywa się porozumieniem bez przemocy (nonviolent communication).
W tym przypadku przemoc oznacza założenie, że druga strona ma negatywne intencje.
Dodatkowe informacje znajdziesz w literaturze.
Podsumowanie
Trudnym rozmowom towarzyszą emocje, a te najczęściej są efektem subiektywnej
interpretacji zaistniałej sytuacji. Dzieje się tak, gdy nie odnosimy się do faktów, pró-
bujemy wmawiać intencje rozmówcy czy w jakikolwiek sposób zakładamy, że wina jest
po drugiej stronie. Dlatego warto używać klarownego języka, który zwiększa szansę
na to, że w sposób jasny, zwięzły i niebudzący niepotrzebnych emocji wyrazimy to-
warzyszącą nam intencję i prośbę wobec drugiej osoby. Z pomocą mogą nam przyjść
cztery składniki jasnego języka:

4
(1) Obserwacja.
(2) Emocja.
(3) Potrzeba.
(4) Prośba.
Ostatecznie kluczem do porozumienia się jest chęć zrozumienia drugiej strony i wy-
słuchanie jej w pierwszej kolejności, zanim spróbujemy jej przekazać to, co jest ważne
dla nas.

4
Rozdział 11.
KONFLIKTY I ICH TECHNIKALIA
Kiedyś na rozmowie rekrutacyjnej kandydat na lidera zespołu stwierdził, że udaje mu

się pełnić swoją funkcję bez konfliktów. To wyznanie wzbudziło moje podejrzenia.
Brak konfliktów to symptom, który wymaga szczególnej uwagi. Życie projektowe jest
pełne konfliktowych sytuacji i należy pozwolić im zaistnieć, aby w efekcie znaleźć
rozwiązanie, które będzie satysfakcjonować obydwie strony sporu.
Pewna historia
Jakiś czas temu miałem okazję pracować z firmą, w której kierownicy projektów nie
dogadywali się z zespołem programistów. Problemy nawarstwiały się przez wiele ty-
godni, aż przyszedł taki moment, że niemal każde spotkanie kończyło się nerwową
wymianą zdań i brakiem rzeczowych ustaleń. Zespół techniczny narzekał na zbyt
wiele dokumentacji, którą musiał tworzyć, a kierownicy chcieli jej jeszcze więcej.
Programiści domagali się więcej czasu na refaktoryzację, natomiast kierownicy żądali,
aby cały czas był w pełni poświęcany na rozwój funkcjonalności. Zespół techniczny
narzekał na brak jakiejkolwiek wiedzy technicznej wśród kierowników projektów.
Moim zadaniem było znalezienie rozwiązania tych problemów. Zaprosiłem na spotka-
nie reprezentantów obu stron i poprosiłem o przedstawienie argumentów. Kiedy
tylko jedna strona zaczynała wyłuszczać swoje racje, druga natychmiast ripostowała
i dyskusja przeradzała się w kłótnię. Po bardzo żmudnej i długiej pracy udało się wypra-
cować rozwiązanie, ale było ono dalekie od ideału. Nie byłem z niego w pełni zado-
wolony.

4
Tak się dzieje zazwyczaj wtedy, gdy obie strony próbują racjonalnie przekonać siebie
nawzajem. Problem tkwi w tym, że przedstawiają swój punkt widzenia, a takie argu-
menty zazwyczaj nie docierają do drugiej strony. W większości przypadków prowadzi
to do kłótni, ewentualnie jedna ze stron wygrywa, a w najlepszym razie dochodzi do
kompromisu.
Kluczem do sukcesu jest zasada, iż „konfliktu nie można rozwiązać na poziomie, na
którym powstał”. Rozwiązania trzeba szukać wyżej.
Prosty przykład
Załóżmy, że pewna para mieszkająca razem chce pomalować pokój. On chce wybrać
kolor niebieski, a ona biały. Co się dzieje w takim przypadku? Mogą wypracować
kompromis — dwie ściany niebieskie, a dwie białe. Pewnie żadne z nich nie będzie do
końca zadowolone. Niektórzy mówią, że w takich sytuacjach zawsze kończy się roz-
wiązaniem zaproponowanym przez kobietę. My będziemy bardziej ambitni. Zadamy
każdej ze stron pytanie: „Dlaczego to jest dla ciebie ważne?”.
On: Ja chciałbym pomalować pokój na niebiesko.
Ona: Grrrr… A ja na biało.
Mediator: Dlaczego to jest dla ciebie ważne, aby pomalować pokój na niebiesko?
On: Bo nie chcę mieszkać w szpitalu. (nie chce białego)
Mediator: A ty dlaczego chcesz pomalować na biało?
Ona: Bo chciałabym mieć pokój w jasnych kolorach.
Mediator: Jeśli ty nie chcesz białego, a ty chcesz jasny, to może — różowy?
On: Nie lubię różowego. Tak samo jak białego.
Mediator: To może inny jasny kolor? Jasny fiolet?
Ona: OK.
On: Dobra, niech będzie.
W przypadku konfliktów nie ma jedynie słusznych odpowiedzi. Dobra jest taka, która
satysfakcjonuje obie strony. Jeśli na końcu następuje zgoda, udało się rozwiązać konflikt.
To, co zostało przedstawione w powyższym dialogu, można pokazać schematycznie
(rysunek 11.1).
Większość konfliktów polega na tym, iż każda ze stron ma określone stanowisko
w zadanym temacie: chcę X, rozwiązanie Y będzie najlepsze. Żeby rozwiązać konflikt,
poszukujemy intencji lub potrzeby, która stoi za stanowiskiem, prowadzi do tego pyta-
nie: „Dlaczego to jest dla ciebie ważne?”. Jeśli dotrzemy do intencji, która zazwyczaj jest

4
Rozdział 11. Konflikty i ich technikalia 139
Rysunek 11.1. Przykład poszukiwania rozwiązania konfliktu
bardziej ogólna, jest sformułowana na wyższym poziomie abstrakcji, mamy większą

przestrzeń do poszukiwania potencjalnych rozwiązań, które będą satysfakcjonować
obie strony.
Uzupełnijmy powyższy rysunek o elementy struktury (oznaczenie stanowisk oraz
intencji) — zob. rysunek 11.2.
Rysunek 11.2. Schemat rozwiązywania konfliktu na bazie przedstawionego przykładu

4
Struktura
Sama struktura rozwiązywania konfliktu wygląda jak na rysunku 11.3.
Rysunek 11.3. Struktura poszukiwania rozwiązania konfliktu
Kilka uwag praktycznych:

 może się okazać, że czasami kilka razy trzeba zadać pytanie o intencję, aby
móc znaleźć rozwiązanie;
 w przypadku konfliktów między różnymi zespołami czy działami można się
posłużyć wartościami organizacji (które to wartości są formą intencji);
 potrzeby i intencje są subiektywne i nie należy ich oceniać, szczególnie w ka-
tegoriach prawidłowe – nieprawidłowe;
 obie strony muszą chcieć znaleźć rozwiązanie, również takie, które może się
różnić od początkowo przedstawionego;
 czasami intencje mogą się po obu stronach wydawać podobne, wtedy warto je
skonkretyzować (np. jeśli intencją jest wysoka jakość kodu, zadaj pytanie: „Co
konkretnie oznacza dla ciebie jakość kodu?”).
Przykładowe pytania
Poniżej znajdziesz przykładowe pytania, które możesz zadać w celu poszukiwania
intencji:
 Dlaczego to jest dla ciebie ważne?
 Czego potrzebujesz w tej sytuacji?
 Jaka jest twoja intencja?

4
Algorytm
Algorytm rozwiązywania konfliktów przedstawia się następująco:
1. Upewnij się, że uczestnicy rozmowy chcą znaleźć rozwiązanie, które będzie
satysfakcjonować wszystkie strony.
2. Przedstaw strukturę rozwiązywania konfliktów i uzyskaj zgodę na jej zasto-
sowanie.
3. Rozpocznij od sprecyzowania stanowisk.
4. Dla każdego ze stanowisk poszukaj intencji.
5. Na bazie intencji obu stron poszukaj innego rozwiązania.
6. Jeśli nowe rozwiązanie nie jest satysfakcjonujące, dowiedz się, dlaczego tak się
dzieje, i na nowo zdefiniuj intencję (lub potrzebę). Wróć do punktu 5.
Przykład
Kierownicy projektu nie mają nawet minimalnej wiedzy technicznej
Konflikt dotyczy sytuacji, w której programiści (P) wystosowali zarzut, iż kierownicy
projektów (KP) nie mają nawet minimalnej wiedzy technicznej. Rozmowę prowadzi
mediator (M).
P: Nie macie żadnej wiedzy technicznej!
KP: Nie jesteśmy od tego, aby znać się na szczegółach technicznych.
M: (do programistów) Dlaczego to jest dla was ważne?
P: Gdyby się lepiej orientowali w technikaliach, łatwiej byłoby rozmawiać
o wymaganiach i ich konsekwencjach.
M: Co dzięki temu będzie możliwe?
P: Będzie łatwiej rozmawiać o tym, jakie rozwiązanie byłoby najlepiej wybrać.
M: A czy potrzebujecie, aby kierownicy mieli głęboką wiedzę techniczną?
P: Nie. Ważne jest, żeby mieli pewną orientację w temacie.
M: (do kierowników) Dlaczego według was nie ma potrzeby, aby znać się na
szczegółach technicznych? Co możecie robić w zamian?
KP: Jeśli nie musimy znać technikaliów ani angażować się w szczegóły techniczne,
mamy więcej czasu, aby ogarniać cały projekt i wspierać wszystkie działania,
które mają doprowadzić do celu.
M: Czy dobrze słyszę, że kluczowe jest dla was, aby projekt zakończył się po-
wodzeniem?
KP: No tak.

4
M: Chciałbym podsumować. Dla was (do programistów) ważne jest to, aby kie-
rownicy mieli orientacyjną wiedzę techniczną, aby można było łatwiej decydować
o najbardziej korzystnych rozwiązaniach?
P: Zgadza się.
M: A dla was (do kierowników) ważne jest to, żeby nie wchodzić w szczegóły tech-
niczne, ale jednocześnie wspierać swoimi działaniami powodzenie projektu?
KP: Tak, żeby nie wchodzić w szczegóły, ale móc wspierać.
M: Co możemy zrobić, żeby zaspokoić jedną i drugą potrzebę?
KP: Może jesteśmy w stanie nabyć jakąś minimalną wiedzę niedużym kosztem?
Może jakiś bardziej komunikatywny programista przygotowałby miniszkolenie?
P: Można spróbować.
Mediator nie jest konieczny, choć bywa pomocny. Możesz jako strona konfliktu
prowadzić taką rozmowę — w tym przypadku przyda się trochę wprawy. Myślę, że
bez problemu odnalazłeś elementy struktury rozwiązywania konfliktów w tym dialogu.
Dla jasności została ona przedstawiona na rysunku 11.4.
Rysunek 11.4. Przykład zastosowania struktury poszukiwania rozwiązania konfliktu

4
ĆWICZENIE 1.
Praktyka jest matką wszelkich umiejętności. Mam dla Ciebie ćwiczenie: wybierz jakąś
obecnie trwającą sytuację konfliktową, która Cię bezpośrednio dotyczy. Sprecyzuj
stanowiska. Znajdź dla nich intencje oraz potencjalne rozwiązanie, używając struktury
rozwiązywania konfliktów.
Gdzie jeszcze?
Najbardziej bezpośrednie zastosowanie struktury rozwiązywania konfliktów to kon-
flikty personalne — w zespole, między zespołami, między konkretnymi osobami. Mo-
żesz także użyć tej struktury:
 w przypadku ustalania reguł zespołowych;
 w przypadku wybierania jednego z dwóch rozwiązań technicznych;
 w przypadku dyskusji o wymaganiach z klientem.
Podsumowanie
Konflikty są nieodłączną częścią współpracy między ludźmi i nie należy się ich obawiać.
Przepracowanie konfliktu powoduje, że strony udoskonalają swój sposób działania.
Aby zmierzać w stronę rozwiązania, wyklaruj stanowiska każdej ze stron, a następnie
określ intencje, które im towarzyszą. Kluczowe pytanie brzmi: „Dlaczego to jest dla
ciebie takie ważne?”. Warto pamiętać, że konflikty nie zawsze muszą oznaczać krwawe
starcia. Mamy z nimi do czynienia w dużo łagodniejszej formie: kiedy ktoś mówi
„nie”, kiedy obie strony nie potrafią wypracować wspólnego rozwiązania, kiedy ktoś
ma inne zdanie. Również w tym przypadku możesz się posłużyć przedstawionym
w tym rozdziale modelem.

4

4
Rozdział 12.
LIDER JAKO COACH
Dlaczego ludzie nie lubią, gdy udziela się im rad?

Programiści nie lubią, kiedy ktoś im mówi, jak powinni pisać swój kod, jakie rozwiąza-
nie jest lepsze, jaki wzorzec projektowy wykorzystać. Tym bardziej że ocena tego, jak
coś powinno być zrobione, jest dość subiektywna. W przypadku inżynierii oprogra-
mowania często trudno mówić o jednym dobrym rozwiązaniu, dobre praktyki bardzo
szybko się rozwijają, podejścia do tworzenia systemów się zmieniają, coś, co było popu-
larne kilka lat temu, zostało już dawno skrytykowane.
Jednak nie tylko programiści nie lubią, kiedy udziela się im rad, dotyczy to większości
ludzi. Dzieje się tak dlatego, że ludzie:
 są przekonani do swojego pomysłu, którego przepracowaniu poświęcili sporo
czasu;
 widzą problem z innej perspektywy niż udzielający im rad i zwracają uwagę
na inne rzeczy;
 chcą wierzyć, że są w stanie sami rozwiązać problem;
 obawiają się krytyki;
 udzielanie rad może być odebrane jako brak wiary w ich kompetencje;
 jest to rodzaj relacji nauczyciel – uczeń, która niesie ze sobą wiele negatywnych
konotacji z czasów szkolnych.

4
Im bardziej doświadczona i kompetentna jest dana osoba, tym mniej działa udzielanie
jej rad. Zadaniem lidera jest poskromienie swojego ego, wstrzymanie się z własnymi
pomysłami i zrozumienie rozwiązania zaproponowanego przez członka zespołu
oraz stojących za tym rozwiązaniem intencji. Głównym narzędziem, które może
być w tym pomocne, jest coaching.
Coaching
Czym jest coaching? To słowo zyskało na popularności w ciągu ostatnich kilku lat,
jednak powstało wokół niego wiele nieporozumień, dlatego poświęcę chwilę na to,
żeby sformułować definicję coachingu.
Zakłada się, że słowo coaching pochodzi od Kocs, nazwy węgierskiej miejscowości,
gdzie od XV w. produkowano wygodne pojazdy kołowe — koczi. Ta nazwa została za-
pożyczona przez inne języki wraz z rozpowszechnianiem się tego typu pojazdów w Eu-
ropie. Powstały odpowiedniki: angielski coach, niemiecki Kutsche czy też hiszpański,
portugalski i francuski coche, natomiast coachingiem nazywano usługę przewożenia
pasażerów.
W XIX w. coachem zaczęto nazywać tutora, który przeprowadzał bezpiecznie studenta
przez egzaminy, a także trenera sportowego, który pomagał swoim podopiecznym osią-
gać dobre wyniki.
W 1974 r. została wydana książka Timothy’ego Gallweya pt. Wewnętrzna gra: tenis.
Autor, trener tenisistów, postawił w tej publikacji tezę, że kluczowe w osiąganiu dobrych
wyników sportowych jest przezwyciężenie wewnętrznych ograniczeń danej osoby.
Zgodnie z tym założeniem każda gra składa się z dwóch części: gry zewnętrznej
z przeciwnikiem i gry wewnętrznej — walki z własnymi wątpliwościami, lękami i my-
ślami. Z kolei w 1992 r. John Whitmore, kierowca rajdowy, w książce Coaching. Trening
efektywności przedstawił bardziej sportowe podejście do pracy coachingowej, która we-
dług niego powinna przynosić mierzalne wyniki. W tym samym roku Thomas Le-
onard założył Coach University. Leonard jako doradca finansowy zauważył, że jego
klienci oprócz profesjonalnej porady potrzebują zwykłej partnerskiej, przyjacielskiej
rozmowy.
Definicji coachingu jest wiele. Na potrzeby tej książki użyję następującej: coaching to
sztuka pomagania innym w osiąganiu wyników, uczeniu się i rozwijaniu.
Nawiązując do pierwotnego znaczenia coachingu, mówi się o tym, że tak jak powóz
pomagał przewieźć pasażera do miejsca przeznaczenia, tak coach wspiera podopiecz-
nych w dotarciu do celu — rola coacha polega głównie na odpowiednim zadawaniu
pytań.

4
Rozdział 12. Lider jako coach 147
Moc pytań
Nie jest moim celem zgłębianie niuansów coachingu, zajmę się za to kluczowymi umie-
jętnościami, czyli słuchaniem i zadawaniem pytań. Pytania mogą nam służyć do tego,
aby zrozumieć daną sytuację, ale również do tego, aby zmotywować kogoś do zasta-
nowienia się nad jakąś kwestią. Zadane pytanie to otwarta pętla, którą nasz mózg chce
w jakiś sposób zamknąć — znaleźć odpowiedź. Główny schemat rozmowy coachingo-
wej jest następujący: najpierw zrozum, a następnie zadaj pytanie, które pobudza do my-
ślenia, do spojrzenia na sytuację z innej perspektywy.
Głównym narzędziem niezbędnym w tym procesie są pytania. Podstawowy sposób
podziału pytań to: pytania zamknięte i pytania otwarte.
Pytania zamknięte
To najprostsze pytania, które mają ograniczoną liczbę odpowiedzi, a najczęściej tymi
odpowiedziami są: „tak” lub „nie”.
Czy napisałeś test do tego kodu? Czy pobrałeś najnowszą wersję biblioteki? Użyłeś
dziedziczenia czy polimorfizmu? Czy sprawdzasz, jak zachowuje się metoda, kiedy
nie będzie połączona z bazą danych?
Pytania tego typu pozwalają bardzo konkretnie sprawdzić naszą hipotezę. Zazwyczaj
te pytania mają sens, kiedy dobrze znamy sytuację i kiedy rozmawiamy o faktach,
które chcemy skonkretyzować. Przydatne mogą być również wtedy, gdy nie mamy
pewności, czy rozmówca wie, co mamy na myśli (np. w przypadku pytania: Czy użyłeś
w tej metodzie pętli while, czy for?).
Ale pytania zamknięte są nieużyteczne i przypominają strzelanie na oślep, gdy sytuacja
jest złożona i nie mamy jasności, o czym mówi rozmówca: A może nie zainicjowałeś
zmiennej? A może nie zainicjowałeś wyjątku? Należy również uważać na pytania po-
zorne, które w rzeczywistości są stwierdzeniami sugerującymi odpowiedź: Czy myślałeś
o tym, żeby rzucać w tej metodzie wyjątek?
Pytania otwarte
To pytania, na które można usłyszeć wiele różnych odpowiedzi, trudnych do przewi-
dzenia. Zazwyczaj pobudzają do myślenia i pozwalają lepiej zrozumieć, jak daną sytu-
ację postrzega druga strona. To pytania, które zaczynają się od słów: dlaczego, kiedy,
gdzie, po co, kto, w jaki sposób, co. Przykłady tego typu pytań:
 Dlaczego zastosowałeś ten wzorzec?
 W jaki sposób zabezpieczyłeś się przed nullem?
 W jakim celu stworzyłeś tę dodatkową klasę?
 Co masz na myśli, kiedy mówisz, że to rozwiązanie jest bardziej skalowalne?

4
Rodzaje i siła pytań

Przedstawię teraz metaforę, która pozwoli lepiej zrozumieć, jakie oddziaływanie mogą
mieć pytania. Wyobraź sobie, że prowadzenie z kimś rozmowy jest jak gra typu RTS
(real time strategy). Na początku widzisz tylko niewielką część pola i Twoim zadaniem
jest odkryć go jak najwięcej, aby mieć jasność sytuacji i lepiej podejmować decyzję
odnośnie do tego, co dalej zrobić. W czasie rozmowy sposobem na odkrywanie tego
pola jest zadawanie pytań, przy czym różne pytania odkrywają pole w różnym zakresie.
Kiedy zadajesz pytania zamknięte, odkrywasz małe punkciki, kiedy zadajesz pytania
otwarte, odsłaniasz większe przestrzenie. Przedstawia to rysunek 12.1.
Rysunek 12.1. Zadawanie pytań jest jak odsłanianie mapy
Przeprowadzono kiedyś badanie na temat mocy zadawanych pytań albo inaczej wielko-
ści pola, które zostanie przez nie odkryte. Stworzono klasyfikację, którą odzwierciedla
piramida z rysunku 12.2.
Rysunek 12.2. Hierarchie mocy pytań
Pytanie Dlaczego? jest na samej górze piramidy, gdyż ono najlepiej pomaga zrozu-
mieć sposób postrzegania przez rozmówcę danej sytuacji i jego motywację. W drugiej
kolejności są pytania Co? Jak?, które pozwalają zrozumieć cele i sposoby osiągania celów
przez pytanego. Następnie znajdują się pytania Gdzie? Kiedy?, które skupiają się na fak-
tach i pozwalają na klarowny opis sytuacji. Na końcu znajdują się pytania zamknięte.

4
Intencja
Im wyżej znajduje się pytanie w hierarchii przedstawionej w poprzednim podroz-
dziale, tym większe zaufanie jest potrzebne między rozmówcami, aby padła warto-
ściowa odpowiedź. Dlatego zanim zada się pytanie z górnej części piramidy, warto
poprzedzić je wyjawieniem intencji, informując drugą stronę o przyczynie zadania
pytania — ilustruje to rysunek 12.3.
Rysunek 12.3. Intencja a pytanie
Na przykład pytanie Dlaczego? Zamiast zapytać:

 Dlaczego zrobiłeś to w taki sposób? (co może być odebrane jako atak)
zadaj pytanie:
 Wiesz co, chciałbym lepiej zrozumieć to, co się wydarzyło. Czy mógłbyś mi
powiedzieć, dlaczego zrobiłeś to w taki sposób?
Pierwsza część tego zdania to wspomniana wcześniej intencja. Kilka innych przykładów:
 Chciałbym, żebyśmy przeanalizowali ryzyko włamania przez SQL Injection.
W jaki sposób twój kod to robi?
 Nie bardzo rozumiem działanie tego kodu, a chcę zrobić jego przegląd. Możesz
mi wytłumaczyć, co tu się dzieje?
 Analizujemy różne rozwiązania, żeby podjąć ostateczną decyzję. Możesz mi
wytłumaczyć, co zyskamy, stosując tę bibliotekę?
W codziennych rozmowach często zapominamy o wyrażaniu intencji albo zakładamy,
że jest ona oczywista. Komunikacja jest klarowniejsza i druga strona chętniej udzieli
Ci odpowiedzi, jeśli w sposób bezpośredni powiesz, dlaczego zadajesz pytanie, unikając
w ten sposób podejrzliwości swojego rozmówcy.
Konkretyzacja
Język naturalny, którym się posługujemy, pozwala na niejednoznaczności. Formu-
łowane przez nas zdania są naszpikowane zniekształceniami powodującymi wiele
problemów komunikacyjnych, a czasami wręcz uniemożliwiającymi porozumienie.
Przyjrzyj się poprzedniemu zdaniu, które przeczytałeś — słowa takie jak naszpikowane,
wiele, czasami, wręcz są niekonkretne i dają duże pole do subiektywnej interpretacji.
Kiedy prowadzimy swobodne rozmowy, zazwyczaj nie stanowi to większego pro-
blemu, ale kiedy próbujemy rozwiązać problem, wypracować rozwiązania lub wspólnie
coś ustalić, takie słowa nie służą załatwieniu sprawy.

4
Lingwistyka jest działem nauki, który szerzej zajmuje się tym tematem. W tabeli 12.1
znajdziesz zestawienie zniekształceń, ich przykłady oraz pytania, które pomogą rozwi-
kłać te zniekształcenia.
Tabela 12.1. Przykłady zniekształceń językowych
Zniekształcenie Przykład Pytania

Niedookreślony On zna się na rzeczy.  Na jakiej rzeczy?
rzeczownik  Co dokładnie o niej wie?
Niedookreślony To działa nie tak jak trzeba.  Co konkretnie nie działa?
czasownik  W którym miejscu w wymaganiach
zostało to sprecyzowane?
System ma raportować wynik  W jaki sposób system ma
sprzedaży. raportować?
 Jak ma wyglądać raport?
Porównania System Excalibur ma być lepszy  Lepszy i szybszy od czego?
i szybszy.  Jak należy to zmierzyć?
Nowy system utrudni nam pracę.  Które zadania utrudni?
 Jak to zmierzysz?
 Jakie pomiary były wykonywane
wcześniej, a jakie są planowane?
Sądy Klienci nie lubią takich kolorów.  Jacy klienci?
 Jakie kolory lubią?
Nominalizacje Wykonanie tego systemu wiąże  Kto jest odpowiedzialny,
(przekształcenie się z ogromną odpowiedzialnością. za co i przed kim?
procesu
w rzeczownik)
Przyczyna Zbieranie wymagań jest zbędne.  Które momenty i aspekty zbierania
i skutek wymagań są zbędne?
 Skąd wiadomo, że są zbędne?
Pisanie testów spowolni naszą pracę.  W jaki sposób?
 Który etap pracy zostanie
spowolniony?
 Czy inne etapy zostaną
przyspieszone?
 Jak pisanie testów wpłynie na cały
projekt?
Czytanie Widzę, że nie podoba wam się  Co konkretnie widzisz?
w myślach pomysł tego systemu.  W jaki sposób wyciągnąłeś ten
wniosek?
Złożona Nie chcesz się zgodzić na  W jaki sposób niezgoda oznacza to,
równoważność przesunięcie terminów, że cię nie lubię?
bo mnie nie lubisz.

4
Tabela 12.1. Przykłady zniekształceń językowych — ciąg dalszy
Zniekształcenie Przykład Pytania

Możliwość Nie wolno w ten sposób pisać  Kto tak powiedział?
testów.  Co to spowoduje?
Nie da się.  Skąd wiesz?
 Po czym to poznajesz?
Konieczność To wymaganie musi być  Dlaczego?
zaimplementowane w tej iteracji.  A jeśli nie będzie, to co się stanie?
Zawsze trzeba pisać testy  W każdym przypadku?
jednostkowe.  A jeśli nie, to co się stanie?
Kwantyfikator Projekty IT zawsze się opóźniają.  Które projekty?
ogólny  Ile razy się opóźniły, a ile razy nie?
Nikt nie wie, jak to  A kogo pytałeś?
zaimplementować.  Gdzie poszukiwałeś informacji?
Kiedy w czasie rozmowy zauważasz, że Twój rozmówca użył zniekształcenia, zadaj

pytanie konkretyzujące. Poniżej kilka przykładów — załóżmy, że przychodzi do Ciebie
inny lider i zadaje pytanie:
1. W jaki sposób przekazać ludziom wartość testów?
A jaką ty widzisz wartość w testach? Jak byś zdefiniował tę wartość?
2. Jak pobudzić członków zespołu do aktywnego działania?
Co dla ciebie oznacza aktywne działanie? Po czym poznasz, że członkowie zespołu
działają aktywnie?
3. Jak pracować z osobami nieprzychylnymi?
A co konkretnie masz na myśli, kiedy mówisz, że są nieprzychylni? Możesz podać
przykłady?
4. Jak znaleźć kompromis między menedżerem a zespołem?
Co dla ciebie oznacza kompromis w tej sytuacji? Do czego chciałbyś doprowadzić?
Prowadzenie rozmowy
Zadawanie pytań to kluczowa umiejętność, jednak potrzebnych jest jeszcze kilka ele-
mentów, które pozwolą wynieść z rozmowy jak najwięcej.
Zwolnij
Dużą przeszkodą w rozwiązywaniu problemów jest pośpiech. Kiedy się spieszymy,
nie słuchamy zbyt uważnie tego, co mówi rozmówca. Nie tylko my sami musimy
zwolnić, ale również powinniśmy sprawić, aby osoba, z którą rozmawiamy, zwolniła.

4
Dopiero zatrzymanie się na problemie pozwala spojrzeć na niego z innej perspektywy.

Delektuj się zadawaniem pytań. Bądź ciekawy tego, czego się możesz dowiedzieć. Oto
jak jeden z coachów opisuje ten stan:
Mam wrażenie, że wszystko się dzieje w zwolnionym tempie. Z niczym się nie
spieszę. Nie oceniam odpowiedzi. Oddycham głęboko i powoli. Czuję, jak krew
pulsuje mi w głowie. Czuję pełen spokój, który pozwala mi wziąć pojedynczy ele-
ment rozmowy i rozkładać go na jeszcze mniejsze części. Mam poczucie, że na
wszystko mam czas.
Drąż i konkretyzuj
Język pozwala formułować myśli w sposób wieloznaczny. Często trudność w rozwiąza-
niu problemu wynika z tego, że dana osoba mówi, niejasno formułując myśli. Dlatego
podczas rozmowy:
 bądź bardzo uważny, aby wychwycić niekonkretne sformułowania — zadawaj
sobie pytanie, czy w pełni rozumiesz to, co słyszysz;
 nie pozwalaj rozmówcy przejść dalej w swoim wywodzie, jeśli nie zrozumiałeś
tego, co zostało powiedziane;
 parafrazuj to, co mówi druga strona;
 sprawdzaj, czy wszystkie elementy, które się składają na problem, zostały
wymienione.
Prowadź rozmowę, mając na uwadze następujące elementy:
1. Czy jest jasne, co stanowi temat rozmowy? — w przypadku problemów, które
budzą silne emocje, dość charakterystyczne jest pojawianie się wielu wątków
i zbaczanie z tematu. Czasami rozmówca ma trudność z doprecyzowaniem, o co
mu w rzeczywistości chodzi. Pytaj: Na jakie pytanie szukamy w tym momencie
odpowiedzi?
2. Co ten temat konkretnie oznacza?
3. Czy to, co zostało powiedziane, definiuje cały temat?
Zapisuj
Myśli, które pozostają w naszej głowie, są niestabilne. Zmieniają się, zostają wyolbrzy-
mione, zdeformowane, przekształcone. Dlatego rób notatki, aby nadać kształt temu,
o czym rozmawiasz. Po pierwsze, zapisuj. Po drugie, wizualnie grupuj, zaznaczaj za-
leżności, tak aby Twoje notatki miały unikalną strukturę, która pozwoli się przyjrzeć
tematowi z pewnej perspektywy.

4
Przykład
W tabeli 12.2 znajdziesz przebieg przykładowej rozmowy prowadzonej przez lidera
w sposób coachingowy (C). Jeden z doświadczonych programistów w zespole (P) od
pewnego czasu zgłasza, że zespół rozwija zbyt wiele systemów i że najbardziej doświad-
czone osoby powinny się skupić na systemie core’owym, a reszty systemów warto się
jakoś pozbyć, np. oddając je pod opiekę zewnętrznej firmie.
Tabela 12.2. Przykładowy dialog coachingowy
Kto Dialog Komentarz

P Uważam, że rozwijamy zbyt wiele systemów.
Powinniśmy się skupić na systemie core’owym i pozbyć
się systemów dodatkowych, zbudowanych na bazie
gotowych narzędzi.
C Co konkretnie masz na myśli, mówiąc, że rozwijamy C konkretyzuje sformułowanie
zbyt wiele systemów? zbyt wiele systemów.
P Jako zespół zrobiliśmy już kilka projektów i musimy je P opisuje, jak doszło do obecnej
utrzymywać, a jednocześnie powstają nowe, zazwyczaj sytuacji, ale cały czas brakuje
każdy kolejny jest tworzony za pomocą innego zestawu jasności, na czym polega problem.
narzędzi, w innej architekturze, innej technologii.
C A w czym konkretnie widzisz problem? C poprzez pytanie dąży
do zdefiniowania problemu.
P No, problemów jest kilka. Stosujemy w efekcie parę P wymienia kilka problemów.
różnych rozwiązań, więc ich utrzymanie jest bardziej
pracochłonne. Trzeba zapewniać utrwalanie wiedzy
w zespole. Obniża się jakość, gdyż nie mamy czasu
na to, aby mieć dobrze opanowanych kilka systemów.
C Okej. To są pewne hipotezy. A weźmy dla przykładu C wybiera jeden problem (jakość)
jakość. Co musiałoby się wydarzyć, żeby przy i próbuje określić, czego P
obecnych warunkach jakość pozostawała oczekuje w tym obszarze.
na odpowiednim poziomie?
P (po chwili zastanowienia) P wymienia kilka kryteriów
Powinna być osoba, która będzie w to stale rozwiązania, które powinny
zaangażowana. Musielibyśmy zatrudnić kogoś, być spełnione.
kto zna się na Hibernate i Springu. Musielibyśmy
ustandaryzować podejście do tworzenia aplikacji,
nawet jeśli piszemy je w różnych technologiach.
C Okej. Wymieniłeś kilka rzeczy. W takim razie C kieruje rozmowę na jedno
skupmy się na tym, co oznacza, że jakaś osoba kryterium.
powinna być w to stale zaangażowana.
P To znaczy, że ty albo ja musimy być w to zaangażowani, P określa konsekwencje
a to odrywa od prac projektowych. zaangażowania.

4
Tabela 12.2. Przykładowy dialog coachingowy — ciąg dalszy

C Rozumiem. A jakie sytuacje wymagają od ciebie C stara się dalej zrozumieć,
zaangażowania się? co oznacza zaangażowanie dla P
poprzez prośbę o przykład sytuacji.
P Wtedy, kiedy trzeba naprawić jakiś błąd, a system jest P podaje przykład.
bardzo połatany.
C A który system jest najbardziej połatany? C dalej konkretyzuje, tym razem
chodzi o określenie połatany
system.
P Hm… No system core’owy. Te dodatkowe systemy są Do P dociera, że problem tkwi
całkiem nieźle skonstruowane i w dużym stopniu zajmuje w systemie core’owym (tzn.
się nimi zespół zewnętrzny — chwila zawieszenia. że w zasadzie jest problem
— Czyli ich eliminacja niewiele zmieni. z jednym systemem).
C To co cię najbardziej angażuje? C próbuje zrozumieć, jak
poprzednie spostrzeżenie
ma się do „zaangażowania”.
P Hm… Łatanie rzeczy w systemie core’owym. I mam P przedstawia założenie, które
przekonanie, że tylko ja albo ty możemy to zrobić stoi u podstaw jego frustracji
dobrze, bo mamy odpowiednią wiedzę i doświadczenie. (w tym momencie zostaje
dobrze zdefiniowany problem).
C A nie jest tak, że bazową część logiki biznesowej C próbuje się odwołać
napisał Marek, a nie my? I zrobił to, nie mając do przeszłości, która przeczy
ogromnej wiedzy na temat systemu? wcześniejszemu założeniu P.
P No, rzeczywiście… A więc może to wcale nie my jako P zaczyna postrzegać inaczej
jedyni musimy się tym zajmować? swoje założenie.
C Może… Z tego, co obserwuję, chyba jesteś C sugeruje inne źródło problemu.
ostatnio trochę zawalony pracą…
P No, jestem… P potwierdza (co nie musiało się
wcale stać).
C Jak teraz patrzysz na początkowe stwierdzenie, C chce się upewnić, jak w tym
że rozwijamy zbyt wiele systemów? momencie P postrzega wyjściowy
problem.
P Hm… Teraz widzę, że po prostu w ostatnim czasie P sam proponuje rozwiązanie.
jestem mocno zarobiony i może chodzi o to, żeby
pomyśleć, jak część tej pracy rozłożyć na zespół.
Jak widać, przebieg takiej rozmowy może obfitować w wiele niespodzianek i bardzo
często to, do czego się dociera, ma niewiele wspólnego z tym, od czego się zaczyna. Na
podstawie tego przykładu można również zobaczyć, że nie została wyeksplorowana
cała przestrzeń poruszanych tematów (np. jak utrwalać wiedzę w zespole), a mimo to
pojawił się znaczący wniosek. I to na ten moment jest wystarczające, gdyż widać sedno

4
problemu, który dręczył bohatera dialogu (jest przeciążony zadaniami). Chciałbym

również, żebyś zauważył na powyższym przykładzie, że rozmowa może być prowa-
dzona za pomocą pytań, bez sugerowania rozwiązań czy dawania rad. Wprawdzie
pod koniec dialogu pojawiły się pewne sugestie (np. Czy nie jesteś ostatnio zawalony
pracą? Czy Marek nie napisał bazowej części logiki?), ale padły wtedy, gdy dużo jaśniej-
szy był już kontekst sytuacji.
Model problemu
Już samo zadawanie pytań powoduje, że możesz pomóc członkowi zespołu spojrzeć
na sytuację z innej perspektywy. Teraz przejdę krok dalej i zajmę się coachingiem
ukierunkowanym — posłużę się konkretną strukturą w celu prowadzenia rozmowy.
Często mówimy o tym, że chcemy rozwiązać jakiś problem, używając słowa „problem”
intuicyjnie. A czym jest problem? Jedna z definicji brzmi następująco: problem to
różnica między stanem obecnym a stanem pożądanym. Na bazie tej definicji można
zbudować model rozwiązywania problemów (rysunek 12.4).
Rysunek 12.4. Model rozwiązywania problemu
Posługując się tym założeniem, można powiedzieć, że w celu rozwiązania problemu

należy zdefiniować obecną sytuację, cel, do którego chce się doprowadzić, oraz to, co
jest potrzebne, aby ten cel osiągnąć. Poniżej zostanie szczegółowo omówiony każdy
z punktów.
Analiza obecnej sytuacji

Lubimy udzielać rad. Często już po usłyszeniu pierwszego zdania mamy gotowe roz-
wiązanie. To jest moment, w którym przestajemy słuchać tego, co ma nam do powie-
dzenia nasz rozmówca, i oddalamy się od rzeczywistego rozwiązania problemu. Za-
miast tego na początku zapytaj o szczegóły związane z omawianym zagadnieniem:
kto, gdzie, kiedy, z kim, w jaki sposób. Staraj się tak długo zadawać pytania, aż będziesz
w stanie wyobrazić sobie lub narysować to, o czym mówi rozmówca.

4
Bazowanie na przykładach
Dobrze jest poprosić rozmówcę o podanie przykładów związanych z opisywanymi sytu-
acjami. Operowanie na przykładach daje pewność, że mowa jest o rzeczywistym, a nie
o wyabstrahowanym problemie.
Intencja
Postaraj się zrozumieć powód, który sprawia, że obecna sytuacja się utrzymuje. Dlacze-
go cały czas funkcjonuje takie a nie inne rozwiązanie? Być może przynosi ono komuś
korzyści? Być może za jego zasadnością kryją się jakieś przyczyny?
Pytania powinny krążyć wokół kwestii: Dlaczego utrzymuje się obecna sytuacja?
Konsekwencje
Badanie konsekwencji jest rozwinięciem poprzedniego pytania o intencję. Świat rzadko
bywa czarno-biały i każda sytuacja ma swoje pozytywne i negatywne konsekwencje.
Żeby je przeanalizować, zadaj pytania:
 Co jest możliwe w obecnej sytuacji?
 Co nie jest możliwe w obecnej sytuacji?
Analiza sytuacji docelowej

Tak jak starałeś się zrozumieć obecną sytuację, tak postaraj się zrozumieć sytuację
docelową — czego Twój rozmówca by chciał. Analogicznie do analizy stanu obecnego
poproś o przykład, postaraj się odnaleźć intencję i sprawdź konsekwencje nowej sytuacji.
Zasoby
Kiedy masz jasność co do tego, jaka jest sytuacja obecna, a jaka pożądana, zadaj py-
tanie: To co by było potrzebne, żeby osiągnąć sytuację docelową? Nazywa się to szukaniem
zasobów, czyli środków potrzebnych do osiągnięcia celu.
Rysunek 12.5 przedstawia przykłady zasobów, które mogą być potrzebne do rozwią-
zania problemu.
 Decyzje — być może potrzebna jest czyjaś decyzja lub zgoda.

 Działania — być może trzeba stworzyć plan działań oraz wybrać osoby, które
będą zaangażowane w jego realizację.
 Umiejętności — być może trzeba posiąść pewne umiejętności (np. umiejętność
negocjowania, asertywność).

4
Rysunek 12.5. Potrzebne zasoby
 Ludzie — być może potrzebne są dodatkowe osoby, aby zrealizować cel.

 Narzędzia — być może potrzebne są dodatkowe narzędzia.
 Wsparcie — być może potrzebne jest wsparcie innych osób: coacha, mentora,
innego lidera.
Przykład
Wyobraź sobie taką sytuację: przychodzi do Ciebie sfrustrowany członek zespołu,
który twierdzi, że zajmuje się bezsensowną dokumentacją i nie chce tego robić. Na bazie
tego przykładu będziesz mógł prześledzić, jak został wykorzystany powyższy model do
przeprowadzenia rozmowy. Modelowy dialog programisty (P) z coachem (C) przed-
stawia tabela 12.3.
Tabela 12.3. Przykładowa rozmowa coachingowa

P Ta dokumentacja, którą tworzymy, jest bez sensu. P formułuje problem.
Tracimy tylko niepotrzebnie czas.
C Widzę, że frustruje cię tworzenie dokumentacji. C stara się wczuć w sytuację P,
Chciałbym dokładniej zrozumieć, co masz na myśli. wyjawia swoją intencję i zadaje
Powiedz mi, jaką dokumentację tworzysz w tym pytanie, które pozwala lepiej
momencie? zrozumieć obecną sytuację
(pytanie konkretyzujące).
P Wypełniam szablon przypadków użycia — na 16 wierszy! P zaczyna konkretyzować,
Idiotyczne. Piszę również podręcznik użytkownika, co rzeczywiście jest problemem.
kiedy ukończę funkcjonalność, oraz tworzę diagram
klas i aktywności po skończonej implementacji.
C A ile czasu nad tym spędzasz? C dalej konkretyzuje, aby
lepiej zrozumieć zależność
czasową.

4
Tabela 12.3. Przykładowa rozmowa coachingowa — ciąg dalszy

P Mniej więcej dwa dni na każde dwa tygodnie.
C A ile byłoby dla ciebie akceptowalne? C pyta o szczegół sytuacji
docelowej.
P Myślę, że jeden dzień na dwa tygodnie bym zniósł.
C Rozumiem. Wiesz co, zadam ci teraz może trochę C pyta o intencję obecnej
dziwne pytanie. Jak myślisz, dlaczego w ogóle tworzymy sytuacji — potrzebę
tę dokumentację? tworzenia dokumentacji.
P Hm… Nie wiem… Przypadki użycia opisują nam
funkcjonalności do wykonania. Ale 16 wierszy? Podręcznik
użytkownika jest oczywiście dla użytkowników,
ale moglibyśmy się pozbyć tych diagramów, szybko
się dezaktualizują i nikt z nich później nie korzysta.
C Czy widzisz jakieś korzyści z tak prowadzonej C pyta o konsekwencje
dokumentacji? pozytywne.
P Nie no, użytkownicy z niej korzystają, więc to ma sens.
My też czasami wracamy do przypadków użycia, żeby
się upewnić, jak dana funkcjonalność powinna działać.
C A jakie widzisz negatywne skutki tego, że tworzysz tę C pyta o konsekwencje
dokumentację? negatywne.
P Nie mam czasu na programowanie i refaktoryzację!
C Okej. To jak chciałbyś, żeby było? C pyta o sytuację docelową.
P Chciałbym nie pisać dokumentacji. P wraca do początkowego
stwierdzenia.
C W ogóle? Z tego, co mówisz, wynika, że nie chcesz C pomaga skonkretyzować
niepotrzebnie wypełniać 16 wierszy szablonu ani sytuację docelową.
rysować diagramów klas i aktywności.
P No tak.
C Załóżmy, że tak by się stało. Jakie byłyby pozytywne C pyta o pozytywne
skutki tego, że nie musiałbyś pisać dokumentacji? konsekwencje sytuacji
docelowej.
P No, miałbym więcej czasu na funkcjonalności
i refaktoryzację.
C A co będzie niemożliwe, jeśli będziesz pisał mniej C pyta o negatywne skutki
dokumentacji? sytuacji docelowej.
P Może się nie dowiemy, jaki był konkretny pomysł
na napisanie danej funkcjonalności.
C Czyli, o ile dobrze rozumiem, chcemy znaleźć sposób C podsumowuje cel związany
na wyeliminowanie niepotrzebnej dokumentacji, z sytuacją docelową.
a nie całej?

4
Tabela 12.3. Przykładowa rozmowa coachingowa — ciąg dalszy

P No, w zasadzie tak.
C To co proponujesz?
P Zorganizujmy spotkanie z analitykami, żeby P sam podaje rozwiązanie.
przedyskutować zasadność obecnego szablonu.
A drugie spotkanie zorganizujmy z programistami
na temat diagramów.
Trening zadawania pytań

Teraz możesz przystąpić do treningu. Kiedy będziesz w sytuacji, w której ktoś z ze-
społu poprosi Cię o pomoc w rozwiązaniu jakiegoś problemu, zanim zaczniesz szukać
odpowiedzi, potrenuj przez pewien czas zadawanie pytań. Potraktuj to jak zabawę,
a sam się zdziwisz, jak wiele kwestii może być rozwiązanych tylko poprzez zadawanie
pytań. Pamiętaj, że Twoim celem nie jest rozwiązanie problemu, ale jak najlepsze
zrozumienie tego, z czym przyszedł Twój rozmówca.
Stopniowanie trudności
Umiejętne zadawanie pytań i świadome pilnowanie, żeby nie udzielać przedwcześnie
rad, jest trudne. Wymaga sporo praktyki. Daj sobie przyzwolenie na popełnianie
błędów. Może Twoje pytania nie wniosą zbyt wiele. Nie zaczynaj od najtrudniejszych
przypadków, dobrze jest stopniować trudność. Wypróbuj takie podejście:
1. Rozpocznij od swoich znajomych lub najbliższych. Zaproponuj swojemu part-
nerowi lub dobremu znajomemu bezpieczne przećwiczenie zadawania pytań.
Bądź ciekawy, co z tego wyjdzie.
2. Jeśli poczujesz się pewniej, zacznij eksperymentować w trakcie rozmów z oso-
bami w zespole, z którymi masz dobre relacje.
3. Jeśli zauważysz, że idzie Ci coraz lepiej, możesz przenieść tę praktykę do rozmów
ze swoim szefem, klientem lub osobami z innych części organizacji.
Podsumowanie
Kiedy jeden z członków zespołu ma jakiś problem, zazwyczaj staramy się mu podać
na tacy gotowe rozwiązanie. Paradoksalnie osoba, która zgłasza tego typu temat, często
nie chce bezpośredniej pomocy i zamiast słów podziękowania możemy usłyszeć, że
zaproponowany pomysł nie jest dobry. A nawet jeśli chce, to dość szybko pojawi się
w zespole syndrom wyuczonej bezradności, kiedy każdy problem będzie Tobie zgłaszany
bez podejmowania prób samodzielnego poradzenia sobie z nim. Dlatego warto się
nauczyć coachingu, który polega przede wszystkim na umiejętnym zadawaniu pytań.

4
Należy odpowiednio dobierać pytania, gdyż niektóre pytania (zamknięte) co najwyżej

mogą Ci pomóc w utwierdzeniu się co do postawionej hipotezy, a dopiero pytania
Dlaczego? Co? Jak? dadzą większe możliwości dotarcia do rozwiązania. Pytania, za
pomocą których chcesz dojść do sedna zagadnienia, warto poprzedzić przedstawieniem
Twoich intencji, co spowoduje, że rozmówca nie będzie się czuł jak na przesłuchaniu.
Rozmowę można poprowadzić również według modelu rozwiązywania problemu, po-
legającego na określeniu sytuacji obecnej, docelowej i środków potrzebnych do do-
konania zmiany. Coaching to umiejętność, która wymaga wprawy, dlatego zaczynaj od
prostych sytuacji i stopniowo przenoś je na bardziej skomplikowane.

4
Rozdział 13.
EFEKTYWNE SPOTKANIA
Zmorą niemal każdego projektu są spotkania. Gdy zostaniesz liderem, będziesz prowa-
dził wiele spotkań. Zabierają one mnóstwo czasu wielu osób i często kończą się brakiem
konkretnych ustaleń. To sprawia, że większość z nas nie lubi brać udziału w takich
zdarzeniach. Bardzo często zebrania kończą się fiaskiem, ponieważ nie są dobrze
przygotowane, więc w tym rozdziale omówię dokładniej, co można zrobić, żeby były
bardziej efektywne.
Podstawy efektywnych spotkań

Na początku kilka podstawowych zasad, o których warto pamiętać:
 Upewnij się, czy spotkanie jest potrzebne — spotkania są kosztowne, uczestniczy
w nich wiele osób. W pierwszej kolejności zastanów się, czy danego tematu
nie można omówić w inny sposób.
 Zdefiniuj jasny cel — Twoje spotkanie zawsze powinno mieć konkretny cel:
musisz mieć jasne wyobrażenie na temat tego, czym ma się zakończyć. Warto
sobie zadać pytanie: jakie decyzje mają zostać powzięte do zakończenia spotkania.
Przykładowe cele:
 Zaplanowanie prac zespołu w najbliższej iteracji (można wnioskować, że
spotkanie powinno się zakończyć gotowym planem).
 Ustalenie strategii logowania zdarzeń (spotkanie powinno się zakończyć
ustaleniem zbioru zasad odnośnie do logowania).

4
 Stworzenie projektu rozwiązania dla raportów zagnieżdżonych (spotkanie

powinno się zakończyć wymyśleniem rozwiązania technicznego zilustro-
wanego diagramem klas i czynności).
 Ustalenie sposobu priorytetyzowania zadań (spotkanie powinno się zakoń-
czyć uzgodnieniem kryteriów i algorytmu wyznaczania priorytetów).
 Określ agendę — ustal listę punktów, które określają przebieg spotkania; agendę
możesz uzupełnić o szacowany czas poszczególnych części zebrania, dzięki
czemu wszystkie zaangażowane osoby będą mogły udzielić informacji zwrotnej,
jeśli będą miały poczucie, że spotkanie odbiega od pierwotnego planu.
Przykładowa agenda spotkania retrospekcyjnego może wyglądać następująco:
1. Preambuła — przedstawienie zasady pozytywnej intencji.
2. Przypomnienie wydarzeń z ostatniej iteracji.
3. Zebranie pomysłów: co zacząć, co przestać robić, a co kontynuować.
4. Wybranie tematów do realizacji.
5. Zaplanowanie działań.
 Wyślij wszystkim zaproszenia przynajmniej dzień wcześniej, szczególnie jeśli
zapraszasz na spotkanie osoby, które mają sporo zajęć (inni liderzy, kierownicy,
klienci). Na większe, ważniejsze i trudniejsze spotkania wysyłaj zaproszenia
kilka dni wcześniej. Staraj się zapraszać tylko tych, którzy są potrzebni do
zrealizowania celów spotkania, szczególnie jeśli będziecie na nim rozmawiać
o szczegółach zadań do wykonania. Na przykład w metodyce Scrum w większo-
ści spotkań uczestniczy cały zespół, aby każdy miał świadomość, dlaczego
zostały podjęte określone decyzje, oraz aby każdy mógł mieć na nie wpływ.
 Przygotuj się do spotkania — nic tak nie frustruje, jak nieprzygotowany pro-
wadzący lub uczestnik zebrania. Jeśli prowadzisz spotkanie, przekaż wcześniej
informacje, co i w jakiej formie należy przygotować. Również warto pamiętać
o takich prozaicznych rzeczach, jak rezerwacja sali, rzutnika czy flipcharta, któ-
rych brak może zniweczyć każde spotkanie.
 Ustal ograniczony czas przeznaczony na spotkanie — zebrania mają tendencje
do tego, żeby się przedłużać, więc określaj z góry czas ich trwania. Wybieraj
krótsze przedziały czasowe. Jeśli możesz, nie organizuj spotkań dłuższych niż
1,5 godziny, a jeśli muszą trwać dłużej, to rozbijaj je na części. W przypadku
dłuższych spotkań rób przerwy co ok. 1,5 godziny.
 Moderuj spotkanie — bez względu na to, jak dobrze zaplanujesz spotkanie,
nie masz pewności, że wszyscy się do tego planu zastosują. Jeśli prowadzisz ze-
branie, powinieneś to robić aktywnie, czyli:
 Przerywaj, jeśli ktoś odchodzi od tematu, wchodzi w szczegóły lub nie
trzyma się ustalonych reguł.
 Przypominaj o celu spotkania.

4
Rozdział 13. Efektywne spotkania 163
 Nakłaniaj uczestników do podejmowania decyzji.

 Jeśli uczestnik spotkania się nie wypowiada, poproś go o opinię na dany
temat.
 Co jakiś czas przypominaj o agendzie, aby sprawdzać, czy jest ona reali-
zowana.
 Jeśli agenda jest zagrożona lub pojawia się temat, który jest istotniejszy dla
wszystkich niż ustalony wcześniej cel, przerwij dyskusję i uzgodnij ze wszyst-
kimi, co robicie dalej; możesz np. zaproponować zmianę agendy lub głów-
nego tematu, co jednak należy traktować jako sytuację wyjątkową.
 Bez przerwy monitoruj czas, informuj uczestników spotkania, ile go jeszcze
zostało.
 Jeśli masz poczucie, że może zabraknąć czasu, ustal z uczestnikami, co na
ten moment jest najważniejsze, a co można pominąć; uzgodnij priorytety i nie
próbuj robić wszystkiego, bo plan zostanie zrealizowany powierzchownie,
a w efekcie nikt nie będzie zadowolony.
 Jeśli w ustalonym czasie mimo powyższych działań nie udało się osiągnąć
zamierzonego celu, zaproponuj termin następnego spotkania.
 Ustal zadania i wskaż, kto będzie za nie odpowiedzialny — kluczem do efek-
tywnych spotkań są podjęte decyzje i uzgodnione działania, które będą pro-
wadzone po zakończeniu spotkania. W końcowej części spotkania zarezerwuj
czas na te czynności. Ważne, żeby było wiadomo: co zostanie zrobione, przez kogo
i do kiedy.
 Zadbaj o to, aby zostały spisane wnioski — nawet najbardziej udane spotkanie
może się okazać stratą czasu, jeśli się okaże, że po kilku dniach nikt nie pamięta
szczegółów poczynionych ustaleń. Dlatego przed rozpoczęciem spotkania
uzgodnij, kto się zajmie spisaniem podsumowania zebrania. Możesz pominąć
ten punkt, jeśli sam spiszesz wnioski po spotkaniu.
Dlaczego to nie wystarcza?

Pomimo dobrego przygotowania spotkanie może nie przynieść oczekiwanych efek-
tów. Oto kilka powodów:
 problem do rozwiązania jest bardzo złożony i trudno wypracować koncepcję;
 przynajmniej jedna z osób próbuje zrealizować swoje ukryte cele, które nie są
związane z tematem spotkania (tzw. drugie dno);
 pojawia się wiele pobocznych wątków, które powodują, że trudno poczynić
rzeczowe ustalenia;
 uczestnicy spotkania nie słuchają się nawzajem;
 brakuje struktury spotkania.

4
Szczególnie może zdziwić ostatni punkt, gdyż wcześniej wspominałem o agendzie.

Agenda w niektórych przypadkach może nie wystarczyć — jeśli sytuacja jest bardziej
złożona, potrzebny będzie bardziej wyszukany pomysł na przeprowadzenie spotkania
i tu z pomocą mogą przyjść struktury prowadzenia spotkań.
Struktury i ich zastosowanie

Struktura to pewien schemat, który nakreśla ramy spotkania. Może Ci być potrzebna
np. w przypadku, gdy istnieje konflikt między uczestnikami spotkania, trzeba roz-
wiązać złożony problem, chcesz zaplanować z zespołem skuteczny sposób poradzenia
sobie ze zmianą organizacyjną, chcesz uzgodnić złożony plan działań lub przeprowadzić
retrospekcję. Poniżej znajdziesz opis kilku przykładowych struktur, które możesz
wykorzystać do tego celu.
Rozwiązywanie konfliktów
Struktura pomagająca przeprowadzić tego typu spotkania została dokładniej opisana
w rozdziale 11. „Konflikty i ich technikalia”, jej wizualizację dla przypomnienia za-
mieszczam na rysunku 13.1.
Rysunek 13.1. Struktura rozwiązywania konfliktu
Tę strukturę można wykorzystać w sytuacji, gdy istnieją przynajmniej dwie grupy,

które mają sprzeczne cele, lub gdy są różne propozycje rozwiązań danego problemu.
Jak można użyć tej struktury? Poniżej znajdziesz przykładowy przebieg spotkania
opartego na tym schemacie dla dwóch skonfliktowanych grup.

4
1. Obie grupy, każda osobno, określają konkretnie swoje stanowisko — do jakiego

pomysłu dążą. Można poprosić o to jeszcze przed spotkaniem, traktując to ja-
ko element przygotowania do niego.
2. Każda z grup osobno prezentuje swoje stanowisko (jeśli to jest potrzebne, po-
wołuje się na fakty i konkretne wydarzenia). W tym czasie druga grupa się nie
odzywa.
3. Obie grupy, każda osobno, określają intencję, która stoi za przedstawionym
stanowiskiem.
4. Każda z grup prezentuje intencję. W tym czasie druga grupa się nie odzywa.
5. Grupy są mieszane i tworzy się nowe podgrupy, a te następnie na zasadzie burzy
mózgów grupy szukają pomysłów, które mają szansę nawiązać do intencji wyra-
żonych przez obie strony.
6. Każda z grup przedstawia swoje pomysły, które zbierane są w jednym miejscu.
7. Każda z osób oddaje swój głos na pomysł, który najbardziej jej odpowiada. Do
realizacji jest wybierany pomysł z największą liczbą głosów (można zastosować
inny sposób wyboru tematu).
RAZEM
Tej struktury (rysunek 13.2) używa się w sytuacjach, kiedy lider z zespołem przygoto-
wuje się do nadchodzącej zmiany. Struktura pozwala rozwiać wątpliwości, obawy i od-
nieść się do frustracji wynikającej z niepewności wobec nadchodzącej zmiany.
Rysunek 13.2. Struktura analizy konsekwencji zmiany
W zespole następuje wspólna analiza kilku wymiarów związanych ze zmianą:

 Z czego będziemy musieli zRezygnować?
 Co będziemy musieli zaAkceptować?
 Jakich Zasobów będziemy potrzebować? Czyjej pomocy? Jakich decyzji? Do-
datkowych ludzi?

4
 W jaki sposób będziemy Ewoluować? Jaki plan działań jest nam potrzebny?
 W jaki sposób będziemy się Motywować?
Nazwa struktury stanowi akronim od pierwszych liter określeń analizowanych wy-
miarów.
Poniżej znajdziesz przykładowy przebieg spotkania zbudowanego na tym schemacie:
1. Podziel zespół na grupy trzy-, czteroosobowe. Każda z grup będzie pracować
w poszczególnych krokach niezależnie, a następnie będzie prezentować swoje
wnioski na forum.
2. Każda z grup opracowuje temat: „Z czego będziemy musieli zrezygnować?”.
Następnie reprezentanci grup przedstawiają wypracowane efekty, które są spi-
sywane na jednym flipcharcie.
3. Każda z grup opracowuje temat: „Co będziemy musieli zaakceptować?”. Na-
stępnie reprezentanci grup przedstawiają wypracowane efekty, które są spisywa-
ne na jednym flipcharcie.
4. Każda z grup opracowuje temat: „Jakich zasobów będziemy potrzebować?”.
Następnie reprezentanci grup przedstawiają wypracowane efekty, które są
spisywane na jednym flipcharcie.
5. Na bazie zebranych do tej pory tematów w efekcie burzy mózgów powstają
pomysły na działania, które pozwolą zespołowi efektywnie przejść przez zmianę.
6. Każdy z członków zespołu może oddać trzy głosy na wybrane tematy. W ten
sposób są ustalane priorytety i eliminowane pomysły, którymi zespół nie będzie
się zajmował.
7. Wybrane tematy są dzielone pomiędzy grupy ustalone na początku spotkania
i każda z grup tworzy szkic planu ich realizacji. Następnie plan jest prezento-
wany i dyskutowany.
8. W grupach powstają pomysły wokół kwestii: „Jak będziemy się motywować
w czasie zmiany?”. Pomysły są przedstawiane i dyskutowane.
W punkcie 3. można się posłużyć strategią Disneya, aby opracować plan działań.
Poziomy logiczne
Poziomy logiczne to struktura, której przede wszystkim używa się wtedy, gdy temat
spotkania dotyczy czynnika ludzkiego. Struktura pozwala analizować konkretną sytu-
ację i opiera się na założeniu stworzonym przez Gregory’ego Batesona i zaadaptowa-
nym przez Roberta Diltsa, że ta analiza może być prowadzona na różnych pozio-
mach abstrakcji, co pozwala na głębsze zrozumienie sytuacji, łatwiejsze wyciąganie
wniosków i podejmowanie działań. Wyodrębnione poziomy tworzą strukturę war-
stwową, tzn. poziomy znajdujące się wyżej bazują na tych, które znajdują się niżej
(analogicznie jak w modelu ISO/OSI komunikacji sieciowej). Jeśli następuje zmiana

4
na wyższym poziomie abstrakcji, to wpłynie ona na niższe poziomy, a w drugą stronę

niekoniecznie tak się stanie. Poziomy logiczne zostały przedstawione graficznie na
rysunku 13.3.
Rysunek 13.3. Poziomy logiczne
W tym modelu wyróżnia się następujące poziomy logiczne (poczynając od najniż-

szego poziomu abstrakcji):
 Środowisko — dotyczy otoczenia, w którym dana sytuacja jest analizowana,
tutaj najczęściej mamy do czynienia z faktami. Charakterystyczne pytania dla
tego poziomu to: co, kto, kiedy, gdzie. Jeśli przedmiotem analizy jest zespół
w kontekście realizowanego projektu, to do środowiska zaliczamy: narzędzia,
nazwę, cel projektu, osoby, które uczestniczą w jego realizacji, terminy, lokali-
zację, ograniczenia.
 Zachowania — jakie działania i reakcje można zaobserwować, np.: jaka jest
atmosfera w zespole, jak członkowie zespołu podchodzą do rozwiązywania
problemów, jak przekazują informacje, w jaki sposób odbywa się komunikacja
z innymi zespołami, co się mówi, co można zauważyć, obserwując pracę zespołu.
 Umiejętności — jakie strategie są używane; w przypadku zespołu: jakie kompe-
tencje są potrzebne w zespole, jakie heurystyki są używane, co potrafią człon-
kowie zespołu.
 Przekonania i wartości — co jest ważne; w przypadku zespołu: jakimi warto-
ściami się posługujemy, jakie przekonania możemy zaobserwować.
 Tożsamość — kim chcemy być, jak chcemy być postrzegani, jakie role przyj-
mujemy.
Tę strukturę możesz zastosować, gdy chcesz:
 w sposób świadomy pracować nad kulturą organizacyjną zespołu;
 chcesz lepiej zrozumieć motywacje klienta lub zespołu, z którym współpracujesz;
 zamierzasz lepiej się przygotować do nadchodzącej zmiany;
 chcesz wyciągnąć głębokie wnioski z sytuacji, która się wydarzyła.
Przykład użycia tej struktury znajdziesz w rozdziale 8. „Relacja z biznesem”.

4
Strategia Disneya
Jest to struktura, która ułatwia przeprowadzenie burzy mózgów, i powinien z niej
wyniknąć konkretny plan działań. Szczegółowo ta struktura została opisana w roz-
dziale 1. „Rola lidera technicznego”, dla przypomnienia ilustruje ją rysunek 13.4.
Rysunek 13.4. Struktura strategii Disneya
Plusy i minusy
Jest to bardzo znana struktura, która polega na zadaniu sobie następujących pytań:
 Jakie są plusy obecnej sytuacji?
 Jakie są minusy obecnej sytuacji?
 Co można by zmienić?
Rysunek 13.5 ilustruje strukturę plusy i minusy. Według tej struktury można popro-
wadzić spotkanie retrospekcyjne. Pytania zadaje się na zakończenie regularnych spo-
tkań, formułując je w następujący sposób:
 Co się udało w czasie tego spotkania?
 Co się nie udało w czasie tego spotkania?
 Jak inaczej powinniśmy poprowadzić to spotkanie?
Rysunek 13.5. Struktura plusy i minusy

4
Model problemu
Jeśli celem spotkania jest znalezienie rozwiązania problemu, można się posłużyć mode-
lem problemu szczegółowo przedstawionym w rozdziale 12. „Lider jako coach”. Na
rysunku 13.6 dla przypomnienia została przedstawiona jego graficzna ilustracja.
Rysunek 13.6. Struktura rozwiązywania problemu
Spotkanie może mieć trzy części:

1. Dokonujemy analizy sytuacji obecnej, używając pytań pomocniczych.
2. Dokonujemy analizy sytuacji docelowej, używając pytań pomocniczych.
3. Określamy, jaki rodzaj zmiany powinien nastąpić, aby przejść z sytuacji obecnej
do docelowej.
Gamestorming
Pomysł na to, aby prowadzić spotkania na podstawie struktur, został również opisany
w książkach: Gamestorming oraz Innovation Games. Te publikacje skupiają się głównie
na technikach służących do tworzenia innowacyjnych pomysłów. Znajdziesz w nich
więcej przykładów struktur, które mogą być przydatne podczas prowadzenia spotkań.
Ramy spotkania
Kiedy Twoim zadaniem jest poprowadzenie trudnego spotkania, w czasie którego
uczestnicy niekoniecznie będą chcieli ściśle współpracować, warto nadać ramy ze-
braniu, aby uprzedzić potencjalne problemy i obiekcje. Te problemy można wyłusz-
czyć na wstępie — zwiększa to szanse, że uda się uniknąć niepożądanych zachowań.
Oto przykłady:
 Być może trudno będzie mówić o problemach, dlatego zakładamy, że każdy
działał z pozytywną intencją… (jeśli się spodziewasz, że uczestnicy mogą mieć
obawę przed szczerym wypowiadaniem swojego zdania).

4
 Może ta forma będzie się wam wydawać dziwna, niemniej jednak chciałbym
zrobić eksperyment… (jeśli masz obawę, że zaproponowana struktura spotkania
może być nienaturalna dla uczestników).
 Może się pojawić ochota na poruszanie tematów spoza listy, jednak chciałbym,
żebyśmy się skupili na agendzie… (jeśli się spodziewasz, że może się pojawić
sporo tematów spoza agendy).
 Być może pojawi się impas podczas szukania rozwiązania, ale warto go prze-
czekać… (jeśli obawiasz się, że uczestnicy będą chcieli przerwać spotkanie, gdy
szybko nie zostanie wyłonione rozwiązanie).
Schemat spotkania
Poniżej znajdziesz bardzo użyteczny schemat prowadzenia spotkania z użyciem ele-
mentów opisanych w tym rozdziale.
1. Na początku przedstaw agendę i główny cel — czym powinno się zakończyć
spotkanie.
2. Następnie zaproponuj strukturę spotkania i jeśli uczestnicy jej nie znają, wy-
jaśnij jej zasady.
3. Zapytaj o zgodę na wprowadzenie ustalonych zasad.
4. Nadaj ramy spotkaniu — uprzedź problemy i obiekcje.
5. Moderuj spotkanie, tak aby zasady były respektowane, oraz sprawdzaj, czy
czas jest dobrze wykorzystywany, tzn. czy w założonym czasie uda się zreali-
zować cel.
6. Podsumuj spotkanie, jasno określając, jakie ustalenia zostały poczynione i jakie
z nich wynikają działania.
Graficzną ilustrację schematu znajdziesz na rysunku 13.7.

4
Rysunek 13.7. Schemat prowadzenia spotkania
Podsumowanie
Poprowadzenie efektywnego spotkania to duże wyzwanie, dlatego warto się przygo-
tować — jasno określić cel, spodziewane efekty oraz czas trwania. Być może uda się
dokonać ustaleń bez spotkania? Jeśli tylko jest taka możliwość, skorzystaj z niej, gdyż
spotkania są bardzo kosztowne.
Bez względu na to, jak dobrze przygotujesz spotkanie, nigdy nie będziesz wiedział, co
się wydarzy w jego trakcie. Jeśli masz do czynienia z bardziej złożonym tematem,
użyj odpowiedniej struktury, np. pomagającej rozwiązać konflikt, zaplanować sposób
zmierzenia się ze zmianą czy znaleźć wyjście z sytuacji. Jeśli spodziewasz się obiekcji,
uprzedź je, wtedy będziesz miał większe szanse, że niepożądane sytuacje nie wystąpią.

4

4
Rozdział 14.
PYTANIA I ODPOWIEDZI
W tym rozdziale zostały zebrane pytania, które miałem okazję usłyszeć w trakcie
pracy z różnymi zespołami. Wiele kwestii było inspiracją poszczególnych rozdziałów
tej książki. Poniżej nie znajdziesz pełnych odpowiedzi na pytania, gdyż byłoby to
powtórzeniem wcześniej omówionych treści. Przeczytasz za to wskazówki dotyczące
tego, które tematy powinieneś zgłębić bardziej szczegółowo, jeśli chcesz znaleźć od-
powiedź na dane pytanie.
Jak poukładać zespół?

To pozornie proste pytanie wymaga złożonej odpowiedzi, gdyż „poukładanie ze-
społu” to zagadnienie zawierające wiele aspektów, które ostatecznie muszą zafunk-
cjonować razem.
Powinieneś nauczyć się rozpoznawać motywację członków zespołu, co zostało przed-
stawione w rozdziale 4. „Motywacja”. Ponadto powinieneś znać główne procesy
związane z funkcjonowaniem zespołu (zostały opisane w rozdziale 5. „Praca z ze-
społem”) i na tej podstawie świadomie stworzyć plan działań. Powinieneś ustalić zasady
współpracy (opisane w rozdziale 5. „Praca z zespołem”) i udoskonalić proces wy-
twarzania oprogramowania (opisany w rozdziale 6. „Proces i inżynieria”), co da ze-
społowi jasność w zakresie kryteriów działania. Znajdź czas na to, aby zorganizować
proces zarządzania wiedzą (rozdział 7. „Zarządzanie wiedzą”). Zacznij regularnie
udzielać informacji zwrotnej (rozdział 9. „Informacja zwrotna”) oraz bądź coachem
dla swojego zespołu (rozdział 12. „Lider jako coach”).

4
Co zrobić, jeśli kultura organizacyjna nie sprzyja zaspokajaniu potrzeb?

W przypadku tego pytania należałoby sprecyzować, co oznacza stwierdzenie, że kultura
organizacyjna nie sprzyja zaspokajaniu potrzeb. Takie zdanie może wynikać z braku
umiejętności i narzędzi do poruszania się w organizacji. Proponowałbym zaplanowanie
świadomej pracy nad relacją z klientem (rozdział 8. „Relacja z biznesem”), przeprowa-
dzanie regularnych retrospekcji z klientem (rozdział 6. „Proces i inżynieria”) oraz naby-
cie umiejętności prowadzenia trudnych rozmów (rozdział 10. „Trudne rozmowy”).
Jeśli mimo wielu prób nie widzisz żadnej zmiany, może to dobry moment, aby się za-
stanowić, czy w danej organizacji jesteś w stanie realizować to, co jest dla Ciebie ważne.
Jak przekonać do pomysłów osobę po drugiej stronie?

W tym przypadku kluczowe jest, dlaczego chcesz przekonać do pomysłów osobę po
drugiej stronie, a w zasadzie — dlaczego ta druga strona miałaby słuchać. W takiej
sytuacji najlepiej byłoby się dowiedzieć, co jest ważne dla Twojego rozmówcy (możesz
wykorzystać mapę empatii lub poziomy logiczne opisane w rozdziale 8. „Relacja z biz-
nesem”). Jeśli wiesz, co jest ważne, spróbuj znaleźć powiązanie pomiędzy tym, co
chcesz zaproponować, a tym, co się liczy dla drugiej osoby. Proces pracy możesz
wzorować na sposobie rozwiązywania konfliktów opisanym w rozdziale 11. „Konflikty
i ich technikalia” lub na krokach rozmowy z rozdziału 10. „Trudne rozmowy”.
Jak zorganizować współpracę zespołu z klientem

(brak podporządkowania zawodowego)?
Współpraca z klientem to dość szeroki temat. Kluczowe jest to, aby jasno ustalić zasady
współpracy oraz dokonywać regularnych retrospekcji. Jeśli wystąpi konkretny problem
we współpracy, mogą Ci się przydać następujące narzędzia: mapa relacji, poziomy
logiczne, mapa empatii (opisane w rozdziale 8. „Relacja z biznesem”).
Czy zostać po stronie technicznej, czy nie?

Na początku drogi jest to pytanie, które zadaje sobie wielu liderów. Nie ma na nie
uniwersalnej odpowiedzi i trzeba ją znaleźć samodzielnie. W rozdziale 1. „Rola lidera
technicznego” możesz przeczytać rozważania na ten temat. Zachęcałbym Cię do tego,
abyś dał sobie szansę i spróbował ścieżki liderskiej, byś ostatecznie mógł stwierdzić,
czy to jest rola dla Ciebie. Stawanie się liderem to pewnego rodzaju podróż, na którą
nie jesteśmy przygotowani, toteż początki mogą nie być łatwe. Ta książka ma na
celu pomóc w tej podróży poprzez dostarczenie narzędzi wspierających pełnienie
funkcji lidera.
Jakie są cechy lidera? Czy są one wrodzone?

Dyskusję na temat cech lidera znajdziesz w rozdziale 1. „Rola lidera technicznego”.
Stamtąd również dowiesz się, że jest kilka rodzajów przywództwa i że w kontekście IT
liderem nie trzeba się urodzić.

4
Rozdział 14. Pytania i odpowiedzi 175
Jak pogodzić sprawy techniczne i nietechniczne?

Często liderzy techniczni uczestniczą w pracach zespołu, co jest dużym wyzwaniem.
Rozważanie tego, jak można sobie z tym radzić, zostało przedstawione w podrozdziale
„Jak pogodzić sprawy techniczne i nietechniczne?”.
Jak zmotywować zespół do samorealizacji?

Nie da się nikogo do niczego trwale zmotywować. To motto rozdziału 4. „Motywa-
cja”, który jest poświęcony temu zagadnieniu. Oto co możesz robić: lepiej poznawać
osoby, z którymi współpracujesz, poznawać ich motywatory i wspólnie szukać sposo-
bów, w jakie można się do nich odnieść.
Jak zmotywować siebie w przypadku trudnych projektów?

Odtwórz swój profil motywacyjny i poszukaj sposobów, jak możesz w danym pro-
jekcie realizować to, co jest dla Ciebie ważne. Więcej szczegółów znajdziesz w roz-
dziale 4. „Motywacja”.
Jak forsować pomysły techniczne?

Lepiej nie forsować, chyba że masz do czynienia z zespołem juniorów. Bardziej szcze-
gółową odpowiedź znajdziesz w następnym punkcie.
Jak zmotywować zespół, aby miał wiedzę biznesową?

Jak nakłonić członków zespołu do zrobienia czegoś?
Jak pracować z ekspertami, którzy robią coś po swojemu (programują strukturalnie)?
Te pozornie różne pytania dotyczą tego samego zagadnienia — jak przekonać kogoś
do czegoś. Po pierwsze, pozbądź się potrzeby nakłonienia kogoś za wszelką cenę. Po
drugie, przeprowadź dyskusję z zespołem lub daną osobą. Dowiedz się, co w ogóle
sądzi o danym temacie, na czym polegają jej obiekcje (tutaj przydadzą się umiejętności
coachingowe z rozdziału 12. „Lider jako coach”). Może się okazać, że członkowie ze-
społu nie są świadomi problemu lub mają pewne obawy. Jeśli będziesz znał te obawy,
możesz się do nich odnieść, używając strategii Disneya lub modelu rozwiązywania
problemów.
Jest jednak inna możliwość — być może próbujesz narzucić rozwiązanie, które druga
strona może wypracować sama. Jeśli tylko ma takie kompetencje, pozwól na to.
Członkowie zespołu zdecydowanie bardziej będą zaangażowani w wykonywanie wła-
snego niż Twojego pomysłu.
W jaki sposób przekazać ludziom wartość testów jednostkowych?

Na to pytanie nie ma prostej odpowiedzi, gdyż zdania na ten temat są w środowisku
programistycznym podzielone.

4
Niemniej jednak możesz spróbować przeprowadzić dyskusję. Poproś członków ze-

społu o spisanie tego, czego nie lubią w programowaniu, a następnie spróbuj pokazać,
w jaki sposób zastosowanie testów jednostkowych może pomóc rozwiązać zebrane
problemy.
Jak przekazać dobre idee zespołowi 45+?

Dobre idee to bardzo subiektywne stwierdzenie. Coś, co Tobie może się wydawać do-
bre, niekoniecznie musi być takie w oczach innych. Ważne jest, aby zrozumieć mo-
tywację drugiej strony, tzn. dowiedzieć się, na czym polegają jej obiekcje, i próbować się
do nich odnieść. Możesz to potraktować jak konflikt i zastosować strukturę rozwią-
zywania konfliktów.
Z drugiej strony możesz zastosować bardziej radykalne podejście, w którym okre-
ślasz, że oczekujesz od członków zespołu pewnego sposobu pracy. Działaj według za-
sady „Nie zgadzaj się, ale się zaangażuj” (opisanej w rozdziale 5. „Praca z zespołem”).
Jak pobudzić do aktywnego działania?

Zanim podejmiesz jakiekolwiek działania, dowiedz się, czym jest spowodowany brak
aktywnego działania. A może to tylko Twoje subiektywne wrażenie? Może to symptom
nierozwiązanego problemu. To oznacza, że masz do czynienia z niejawnym konfliktem,
który musisz jak najszybciej wydostać na wierzch i doprowadzić do zmiany sytuacji
(zob. rozdział 11. „Konflikty i ich technikalia”).
Jeśli brakiem aktywności jest monotonia w projekcie, możesz z zespołem wypróbo-
wać działania opisane w rozdziale 4., w podrozdziale „Elementy angażującego śro-
dowiska”.
Brak aktywności może być też spowodowany tym, że ludzie nie pracują jako zespół,
tylko niezależnie realizują zadania, co w efekcie obniża energię całej grupy. Zmień
sposób pracy zespołu tak, aby wszyscy pracowali nad wspólnymi celami — świetnie się
do tego nadają metody zwinne.
Jak pracować z osobami nieprzychylnymi?

Pierwsze pytanie, które warto sobie zadać: czy to nie jest subiektywna opinia, że dana
osoba jest nieprzychylna.
Na pewno jest jakiś powód zaistniałej sytuacji. Może być on dla Ciebie całkowicie
niezrozumiały, jednak dla drugiej strony ma on z pewnością sens. Przeprowadź rozmo-
wę, aby lepiej zrozumieć problem, używając narzędzi z rozdziału 12. „Lider jako coach”.
Powodów może być wiele, oto kilka z nich:
 Danej osobie na czymś zależy i robi wszystko, żeby to uzyskać — postaraj się
dowiedzieć, co jest dla niej ważne.

4
Rozdział 14. Pytania i odpowiedzi 177
 Dana osoba jest sfrustrowana jakąś dawną sytuacją — powróć do tematu, aby
oczyścić atmosferę;
 Macie zbyt słabą relację — daj sobie trochę czasu i zacznij świadomie pracować
nad rozwijaniem relacji.
Jak rozwiązywać konflikty spowodowane wyborem technologii?

Wybór rozwiązania technicznego, szczególnie jeśli jest kilka propozycji, to typowy
konflikt. Zorganizuj spotkanie, na którym spróbujecie rozwiązać ten konflikt (zob.
rozdział 11. „Konflikty i ich technikalia”). Może też być tak, że nie ma rozwiązania,
które będzie najlepsze w danej sytuacji — wtedy lepiej podjąć jakąkolwiek decyzję, niż
przedłużać impas. Przed spotkaniem ustalcie sposób, w jaki wybierzecie rozwiązanie.
Jak pogodzić relację programiści – testerzy?

Jak znaleźć kompromis pomiędzy zespołem a menedżerem?
W tym pytaniu brakuje informacji na temat tego, co jest kością niezgody. Może to
być konflikt, który należałoby zdefiniować i rozwiązać (zob. rozdział 11. „Konflikty
i ich technikalia”). Innym powodem potencjalnych problemów może być to, że liderzy
i testerzy pracują odseparowani od siebie, co zazwyczaj pogłębia nawet małe pro-
blemy i utrudnia zrozumienie perspektywy drugiej strony. Możesz zatem spróbo-
wać doprowadzić do sytuacji, w której testerzy i programiści będą pracować jako jeden
zespół w jednym pomieszczeniu, będą wspólnie planować zadania i odpowiadać razem
za końcowy efekt.
Być może jest konkretny problem do rozwiązania, taki jak np. zbyt niski poziom auto-
matyzacji, który utrudnia proces testowania po obu stronach. W takim przypadku
dokonaj analizy sytuacji na retrospekcji i wypracuj rozwiązanie. Możesz się posłużyć
do tego celu modelem problemu opisanym w rozdziale 12. „Lider jako coach”.
Podobne działania możesz zastosować, gdy problem występuje pomiędzy zespołem
a menedżerem lub właścicielem produktu.
Jak łagodzić konflikty?

W tym pytaniu jest niewypowiedziane założenie, iż konflikty trzeba łagodzić. Tym-
czasem rolą lidera jest coś zupełnie przeciwnego — uwypuklanie konfliktów tak, aby
doprowadzić do dialogu na ich temat. Od strony narzędziowej przydatne mogą być tech-
niki opisane w rozdziałach 10. „Trudne rozmowy” oraz 11. „Konflikty i ich technikalia”.
Jak nie poddawać się naciskom klienta lub innych zespołów?

To jest obawa, która towarzyszy wielu liderom. Przede wszystkim postaraj się zro-
zumieć intencje drugiej strony i dowiedzieć się, dlaczego ważne jest to, na co naciska
Twój rozmówca. Pamiętaj o szukaniu pozytywnej intencji. Ważne jest wypracowanie
dobrej relacji z klientem — wtedy łatwiej znajdować rozwiązania korzystne dla wszyst-
kich stron. Jeśli sytuacja jest szczególnie napięta, posłuż się metodą opisaną w roz-
dziale 10. „Trudne rozmowy”.

4

4
LITERATURA
1. Allen D., Getting Things Done, czyli sztuka bezstresowej efektywności,

Onepress, Gliwice 2013.
2. Appelo J., Management 3.0, Addison-Wesley, Boston 2011.
3. Bartyzel M., Oprogramowanie szyte na miarę. Jak rozmawiać z klientem, który
nie wie, czego chce, Helion, Gliwice 2013.
4. Blikle A., Doktryna jakości. Rzecz o skutecznym zarządzaniu, Helion,
Gliwice 2014.
5. Blanchard K. i in., Przywództwo wyższego stopnia, Wydawnictwo Naukowe
PWN, Warszawa 2007.
6. Buzan T., Mapa twoich myśli, AHA, Łódź 2007.
7. Coffman C., Buckingham M., Po pierwsze: złam wszelkie zasady, MT Biznes,
Warszawa 2011.
8. Cohn M., Succeeding with Agile: Software Development Using Scrum,
Addison-Wesley, Boston 2013.
9. DeMarco T., Slack: Getting Past Burnout, Busywork, and the Myth of Total
Efficiency, Broadway Books, Portland 2002.
10. DeMaria Barry T., Benson J., Personal Kanban: Mapping Work | Navigating
Life, CreateSpace, Seattle 2011.
11. Derby E., Agile Retrospectives: Making Good Teams Great, The Pragmatic
Programmers, Frisco 2012.
12. Dilts R., Od przewodnika do inspiratora, PINLP, Warszawa 2006.

4
13. Dilts R., Przywództwo z wizją. Kreowanie świata, do którego ludzie chcą
przynależeć, Neuroedukacja, Lublin 2007.
14. Gallwey T.W., Wewnętrzna gra: tenis, Galaktyka, Łódź 2015.
15. Gellert M., Nowak C., Zespół, GWP, Gdańsk 2008.
16. Goldsmith M., Feedforward: Comic Book, Barnes & Noble, New York 2012.
17. Gonçalves L., Linders B., Getting Value out of Agile Retrospectives, InfoQ,
Toronto 2013.
18. Gray D., Brown S., Macanufo J., Gamestorming. A Playbook for Innovators,
Rulebreakers, and Changemakers, O’Reilly, Sebastopol 2010.
19. Grzechy główne liderów.
a) Artykuł: http://msieraczkiewicz.blogspot.com/2012/11/6-grzechow-
-gownych-liderow-technicznych.html, data dostępu 28.08.2015.
b) Film: https://www.youtube.com/watch?v=nQxLIjmN6q4, data dostępu
28.08.2015.
20. Hohmann L., Innovation Games: Creating Breakthrough Products Through
Collaborative Play, Pearson Education, Boston 2006.
21. Holler I., Porozumienie bez przemocy. Ćwiczenia, Czarna Owca, Warszawa 2011.
22. Kaczor K., SCRUM i nie tylko. Teoria i praktyka w metodach Agile,
Wydawnictwo Naukowe PWN, Warszawa 2014.
23. Kniberg H., Happiness index, http://blog.crisp.se/2010/05/08/henrikkniberg/
what-is-crisp, data dostępu 28.08.2015.
24. Lencioni P., Pięć dysfunkcji pracy zespołowej, MT Biznes, Warszawa 2011.
25. Pink D., Drive. Kompletnie nowe spojrzenie na motywację, Studio EMKA,
Warszawa 2011.
26. Robbins A., Get the Edge: A 7-Day Program To Transform Your Life, Robbins
Research International, Inc., San Diego 2000.
27. Rosenberg M.B., Porozumienie bez przemocy. O języku serca, Czarna Owca,
Warszawa 2011.
28. Scrum.org, Scrum Guide, http://www.scrumguides.org, data dostępu 28.08.2015.
29. Seiwert L.J., Zarządzanie czasem. Bądź panem własnego czasu, Placet,
Warszawa 1998.
30. Sieraczkiewicz M., Mantra architektoniczna,
https://www.youtube.com/watch?v=SnUzX1ZObpk, data dostępu 28.08.2015.
31. Snowden D., The Cynefin Framework,
https://www.youtube.com/watch?v=N7oz366X0-8, data dostępu 28.08.2015.
32. Whitmore J., Coaching. Trening efektywności, G+J, Warszawa 2011.
33. Zarządzanie. Teoria i praktyka, red. A.K. Koźmiński, W. Piotrowski,
Wydawnictwo Naukowe PWN, Warszawa 2010.

4
4

Technical Leadership Od Eksperta Do Lidera Mariusz Sieraczkiewicz Helion.pl

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Technical Leadership Od Eksperta Do Lidera Mariusz Sieraczkiewicz Helion.pl

Uploaded by

Copyright:

Available Formats

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.

Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi

Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte

Redaktor prowadzący: Magdalena Dragon-Philipczyk

Copyright © Mariusz Sieraczkiewicz 2016

 Poleć książkę na Facebook.com  Księgarnia internetowa

 Kup w wersji papierowej  Lubię to! » Nasza społeczność

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com

Rozdział 1. Rola lidera technicznego ......................................................... 11

Rozdział 2. Ekspert a lider ......................................................................... 25

Rozdział 3. Od wizji do działania ............................................................... 37

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com

Rozdział 4. Motywacja ............................................................................... 43

Rozdział 5. Praca z zespołem ..................................................................... 69

Rozdział 6. Proces i inżynieria .................................................................... 81

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com

Rozdział 7. Zarządzanie wiedzą ................................................................. 91

Rozdział 8. Relacja z biznesem ................................................................ 105

Rozdział 9. Informacja zwrotna ............................................................... 117

Rozdział 10. Trudne rozmowy ................................................................. 125

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com

Rozdział 11. Konflikty i ich technikalia .................................................... 137

Rozdział 12. Lider jako coach ................................................................... 145

Rozdział 13. Efektywne spotkania ........................................................... 161

Rozdział 14. Pytania i odpowiedzi ........................................................... 173

Literatura ................................................................................................. 179

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com

ROLA LIDERA TECHNICZNEGO

Niedawno się przeprowadzałem. W jednym z pudełek, które pozostało nieotwarte po

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com

Typowa ścieżka kariery w IT

Rysunek 1.1. Typowa ścieżka kariery w IT

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com

Definicja lidera technicznego

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com

Model Technical Leadership

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com

Rysunek 1.2. Model Technical Leadership

Rysunek 1.3. Metafora definicji lidera

A co z aspektem technicznym? Co czyni lidera technicznego wyjątkowym? Tę rolę

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com

 kluczowe kompetencje, które są niezbędne w tym środowisku, to umiejętność

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com

 Jakie będzie używane zintegrowane środowisko pracy?

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com

Zakłada się, że charyzma jest budowana w młodości. Można kształtować ją później,

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com

Grzechy główne liderów technicznych

Uciekanie w zadania techniczne

Odpuszczanie reguł w przypadku pożarów

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com

związanych z realizacją projektów i pracą zespołu. Ku mojemu zdziwieniu jest ona

Niewdrażanie wyników retrospekcji

Zbyt wiele rzeczy jednocześnie

Brak czynnika ludzkiego

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com

Brak umiejętności odniesienia się bezpośrednio do problemu

Brak umiejętności radzenia sobie z konfliktem

Branie zbyt wielu rzeczy na siebie

helion kopia dla: 781-185-35-85 PREBIT Piotr Wozniak piotr.wozniak222@gmail.com