All we do is looking for some way to fulfill our needs.

czwartek, 25 września 2014

Tagged under: , , , , , , , ,

(Polish) Nie daj się konfliktom

.

Intro
Kiedyś na rozmowie rekrutacyjnej kandydat na lidera zespołu stwierdził, że udaje mu się pełnić swoją rolę bez konfliktów. To wyznanie budzi podejrzenia. Brak konfliktów, to symptom, który wymaga szczególnej uwagi. Życie projektowe jest pełne konfliktów i należy im pozwolić zaistnieć, aby w efekcie móc znaleźć rozwiązanie, które będzie satysfakcjonować obydwie strony. 

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. Sytuacja nawarstwiała się przez wiele miesięcy aż przyszedł taki moment, kiedy niemal każde spotkanie kończyło się nerwową wymianą zdań i brakiem rzeczowych ustaleń. Zespół techniczny narzekał na zbyt dużą ilość dokumentacji, którą musiał tworzyć, gdy tymczasem kierownicy chcieli jej jeszcze więcej. Programiści chcieli więcej czasu na refaktoryzację, kierownicy chcieli, 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 przedstawionych problemów. Zaprosiłem na spotkanie przedstawicieli obu stron i poprosiliśmy o przedstawienie argumentów. Kiedy tylko jedna strona zaczynała przedstawiać swoje racje, druga natychmiast ripostowała i dyskusja przeradzała się w kłótnię. Po bardzo żmudnej i długiej pracy udało się wypracować jakieś rozwiązanie, ale było ono dalekie od ideału. Nie byliśmy z niego w pełni zadowoleni.

Tak się dzieje zazwyczaj wtedy kiedy w przypadku konfliktu, obie strony próbują racjonalnie przekonać siebie nawzajem. Problem tkwi w tym, że przedstawiają argumenty ze swojego punktu widzenia, które zazwyczaj nie docierają do drugiej strony. W większości przypadków doprowadza to do kłótni, ewentualnie tylko jedna ze stron wygrywa, a w najlepszym przypadku dochodzi do kompromisu.
Kluczem do sukcesu jest zasada, iż „konfliktu nie można rozwiązać na poziomie, na którym powstał”. Trzeba rozwiązania szukać na wyższym poziomie. A co to znaczy?

Prosty przykład
Załóżmy, że pewna para mieszkająca razem, chce pomalować pokój. On chce pomalować go na niebiesko a ona na biało. Co w takim przypadku? Mogą wypracować kompromis – dwie ściany niebieskie a dwie białe. Pewnie żadne z nich do końca nie będzie zadowolone. Niektórzy mówią, że w takich sytuacjach zawsze kończy się rozwiązaniem zaproponowanym przez kobietę. My będziemy bardziej ambitni. Spróbujmy zadać 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 ważne dla ciebie, 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 poprawnych odpowiedzi. Dobra jest taka, która dla obu stron jest satysfakcjonująca. Jeśli na końcu jest zgoda, to znaczy, że udało się rozwiązać konflikt.

To co zostało przedstawione za pomocą powyższego dialogu, możemy przestawić za pomocą następującego schematu:


Większość konfliktów opiera się na tym, iż każda ze stron ma określone stanowisko w zadanym temacie. To stanowisko to stwierdzenie: chcę X, rozwiązanie Y będzie najlepsze. 

Żeby rozwiązać konflikt poszukujemy intencji lub potrzeby, która stoi za stanowiskiem, do czego prowadzi wariacja pytania „Dlaczego to jest dla ciebie ważne?”. Jeśli dotrzemy do intencji, która zazwyczaj jest bardziej ogólna, jest sformułowana na wyższym poziomie abstrakcji, to mamy większą przestrzeń do poszukiwania potencjalnych rozwiązań, które będą satysfakcjonować obie strony.


Nasz schemat uzupełnijmy o elementy struktury (zaznaczenie stanowisk oraz potrzeb i intencji):

Struktura

Sama struktura rozwiązywania konfliktu wygląda następująco:

Kilka uwag praktycznych:
  •   może się okazać, że czasami trzeba zadać kilka razy 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 są forma intencji);
  •  potrzeby i intencje są subiektywne i nie należy ich oceniać w jakikolwiek sposób, szczególnie w kategoriach prawidłowe-nieprawidłowe;
  •  obie strony muszą mieć chęć znalezienia rozwiązania, również takiego, które może się różnić od początkowo przedstawionego;
  •  czasami intencje mogą po obu stronach wydawać się 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?
  •     Jak jest twoja intencja?

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 zastosowanie.
  3. Rozpocznij od sprecyzowania stanowisk.
  4. Dla każdego ze stanowisk poszukaj intencji lub potrzeby.
  5. Na bazie intencji lub potrzeb obu stron poszukaj innego rozwiązania.
  6. Jeśli nowe rozwiązanie nie jest satysfakcjonujące, dowiedz się dlaczego i na nowo zdefiniuj intencję (lub potrzebę). Wróć 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. 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 bardziej się orientowali w technikaliach, to ł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 będzie najlepiej wybrać.
M: A czy potrzebujecie, aby kierownicy mieli głęboką wiedzę techniczną?
P: Nie. Ważne jest to, żeby mieli pewną orientację w temacie.
M: (do kierowników) Dlaczego nie ma dla was sensu, aby znać się na szczegółach technicznych? Co wtedy możecie robić w zamian?
KP: Nie musząc znać i angażować się w szczegóły techniczne, mamy więcej czasu, aby ogarniać projekt i wspierać wszystkie działania, które mają doprowadzić jest do celu?
M: Czy dobrze słyszę, że kluczowe jest dla was do, aby projekt zakończył się powodzeniem?
KP: No tak.
M: Chciałbym podsumować. Dla was (do programistów) ważne jest to, aby kierownicy 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, że nie wchodzić w szczegóły techniczne, ale jednocześnie wspierać swoimi działaniami powodzenie projektu?
KP: Tak, żeby nie wchodzić w szczegóły, ale móc wspierać.
M: Co można zrobić, żeby spełnić jedną i drugą potrzebę?
KP: Może jesteśmy w stanie nabyć jakąś minimalną wiedzę niedużym kosztem? Może jakiś bardziej biznesowy programista przygotowałby miniszkolenie w tym temacie?
P: Ma sens. Można spróbować.

Myślę, że nie mieliście problemu, aby odnaleźć elementy struktury rozwiązywania konfliktów w tych dialogach. Dla jasności została ona przedstawiona poniżej:

Ćwiczenie

Praktyka jest matką wszelkich umiejętności. Mamy dla ciebie ćwiczenie.
Znajdź aktualną sytuację konfliktową, która dotyczy cię bezpośrednio. Sprecyzuj stanowiska. Znajdź dla nich intencje oraz potencjalne rozwiązanie, używając struktury rozwiązywania konfliktów.

Gdzie jeszcze?

Najbardziej bezpośrednie zastosowanie tego schematu to konflikty personalne – w zespole, między zespołami, między konkretnymi osobami. A w jakich sytuacjach jeszcze można użyć tej struktury:
·         w przypadku ustalania reguł zespołowych;
·         w przypadku wybieranie jednego z dwóch rozwiązań technicznych;
·         w przypadku dyskusji o wymaganiach z klientem.

Zatem do dzieła! Czyńmy świat piękniejszym :)

środa, 24 września 2014

Tagged under: , , , , ,

Agile Prague 2014 notes

.

It's been almost a week since Agile Prague finished. It was a great time of interesting discussions and meetings. I have had a privilege to talk with Linda Rising about patterns, their history and current state (still under development). She also gave wonderful talks about Agile mindset and trust.

It was also a pleasure to discuss with Paul Klipp and take part in his talk about communication - the subject I am always interested in.

Another two interesting subject I listened to were ones presented by:
  • Vasco Duarte - about NoEstimates approach, which in my opinion is not exactely about not doing estimation, but to extremeley simplify the way you do it. In short: estimate an item with 1 point. If it is too big (should be more than 1), split it.
  • Louis Goncalves - about getting rid of performance appraisals.
I have also a privilege to give my talk about Natural Course of Refactoring. You can find slides here.
I had a very nice and positive feedback.


See you soon at Warsjawa.

środa, 3 września 2014

Tagged under: , , , , , , , ,

JDD, Warsjawa, Agile Prague and Cambridge Agile conferences

Vacation time is over and it is time to start to hard work :) I have a privilege to speak at 3 conferences so if you would like to meet me and talk, don't hesitate - join the conferences as soon as possible.

 My first talk will be about refactoring and concept of Natural Course of Refactoring in Prague on 16th September. There is a big chance that I will show more advanced example with many tricky and non-trivial transformation.
More details about the event can be found at http://touchmyconference.com/AP2014/#sessions


 The second activity will be a workshop on Soft Skill for Tech guy in Cambridge on 2nd October. So if you want to learn how to use very useful model to handle conflicts just come.
More details about the event can be found at http://agilecambridge.net/ac2014/programme/ 


In addition to that I will be talking at great Polish conference in Cracow called JDD that I have been with for ages (from the beginning). The talks will be held in Polish. The first one will be "How your code speaks to you" and the second one with Michał Bartyzel about "Strategic refactoring".
More details about the event can be found at http://14.jdd.org.pl/.

Ohh... I forgot. Warsjawa! Yes. There will be great opportunity to put hand on keyboard and repair legacy code during "Working with legacy code" workshop.
More details about the event you can find here http://warsjawa.pl/

Ouch! Now I realized that it will be very busy time :)