Domniemanie (nie)wiedzy

Miałem w głowie dwa potencjalne tytuły dzisiejszego wpisu: “Domniemanie (nie)wiedzy” oraz “Tylko powiedz, o co Ci chodzi”. Znacie tę sytuację, kiedy podczas spotkania ktoś pyta “Wszystko jasne?”. Albo z uczelni, gdzie wykładowca chce się upewnić czy dobrze przekazał wiedzę pyta “Kto nie rozumie?”. No właśnie. Wszyscy znamy tę sytuację, to domniemanie (nie)wiedzy!

 

Trud

Przekazanie jakieś informacji zawsze wiąże się z wysiłkiem. Można bowiem odbębnić swoje i żyć w satysfakcji “No co, przecież powiedziałem”. Można też pójść drogą opisaną powyżej, zadać pytanie, na które i tak w słabo zaangażowanym w prace zespole nie uzyskamy żadnej odpowiedzi. Bo kto zada sobie trudu, żeby poprosić o doszczegółowienie jakiś informacji? Często nikt!

Nie jest to oczywiście sytuacja pożądana. Umówmy się, powoduje ona, że nie możemy być w żaden sposób przekonani o poprawnym przekazaniu informacji. Często nawet odpowiedź “Tak” na zadane wcześniej pytania będzie nieprawdziwa. Jak więc rozmawiać, co zrobić, aby uzyskać prawdziwą informacją zwrotną od zaangażowanych w swoją pracę ludzi?

Metod oczywiście jest wiele, wszystkie one jednak wymagają przygotowania. I to właśnie w tym miejscu często upadają mity o powszechnym rozumieniu wszystkich i wszystkiego.

 

“Tylko powiedz, o co Ci chodzi”

Podobnie rzecz ma się z oczekiwaniem czegoś od innej osoby. Czynimy domniemanie, że znamy się już na tyle dobrze, że powinniśmy rozumieć się bez słów. “Jak to nie wiesz o co mi chodzi?”. Powyższa rzecz powoduje, że często nie otrzymujemy tego, co było naszą potrzebą co budzi niepotrzebne frustracje zarówno i oczekującego jak i realizującego. A przecież wcale tak dużo nie trzeba, aby dogadać się w dużo lepszy sposób.

Nie bez powodu Scrum został zbudowany wokół pętli informacji zwrotnych. Stanowią one ważny element wytwarzania Produktu i w swoim zamiarze mają właśnie maksymalnie wyeliminować efekt domniemania. Na nic się jednak nie zdadzą w sytuacji, w której nasz współrozmówca, współuczestnik spotkania nie będzie chciał nam tej informacji udzielić. Możemy zrobić najlepsze Sprint Review, przeprowadzić super Retrospektywę, ale jeśli nie będzie zaangażowania, zrozumienia i chęci to na nic się one nie zdadzą.

Innym, ważnym elementem jest transparentność, szczerość i otwartość. Bez zapewnienia tych elementów nie ma mowy nie tylko o udzieleniu informacji zwrotnej, ale również o jakiejkolwiek efektywnej współpracy między wszystkimi zainteresowanymi.

 

Wspólne rozumienie

Należy więc zadbać o wspólne rozumienie domeny, o której dyskutujemy. Jej rozumienie nie może być wąskie, powinniśmy więc zatroszczyć się o pokrycie maksymalnie dużego obszaru zainteresowania. Wszak jak mówi polskie przysłowie “Co dwie głowy to nie jedna”, “Od przybytku głowa nie boli”, choć z drugiej strony “Gdzie kucharek sześć, tam nie ma co jeść”. Pamiętajmy również o pragmatyzmie. Istnieje gdzieś granica, której nie powinniśmy przekraczać.

Wspólne rozumienie tematu odkrywać możemy na wiele różnych sposobów. Pierwszym, podstawowym i zawsze polecanym jest rozmowa. Im bardziej uda nam się zakopać dołki “my-oni”, “Pan-Pani”, tym lepiej dla całego procesu. Zdajemy sobie jedna sprawę, że w wielu miejscach, pomimo zwinności trudno dochować takich standardów. Z pomocą przychodzą nam wtedy narzędzia wspierające proces poznania.

Event Storming, User Story Mapping, User Stories, Impact Mapping, Product Vision Board, a nawet Planning Poker to tylko niektóre z narzędzi, dzięki którym jesteśmy angażowani w rozmowę. Ma ona zaowocować właśnie wspólnym rozumieniem omawianego tematu. Jest to niezbędne, aby nie doprowadzić do sytuacji, które opisywałem już powyżej.

Nie jestem zwolennikiem wprowadzania narzędzi “na start”. Moim skromnym zdaniem powinny być one odpowiedzią na potrzebę. Zacznijmy od rozmowy, jeśli zauważymy, że nie doprowadza nas ona do celu, zaproponujmy coś nowego, wprowadźmy np. jedną z zaproponowanych technik.

 

Domniemanie (nie)wiedzy

Jeśli miałbym wskazać powody nieporozumień pomiędzy członkami zespołów deweloperskich, w projektach, czy między biznesem i IT to domniemanie (nie)wiedzy zajmowałoby naprawdę wysoką pozycję. Czy jest to działanie celowe? Raczej nie, wynika to z m. in. braku czasu czy braku chęci zrozumienia (empatii) wobec drugiej osoby. Czy powinniśmy na to pozwalać? Sami znacie odpowiedź na to pytanie.

Założenie, że druga strona wie dokładnie to samo co my jest z góry obarczone ryzykiem. Owszem, może się zdarzyć, że porozumiewamy się dokładnie tym samym językiem, ale jak pokazuje praktyka znaczniej częściej mamy do czynienia z sytuacją, gdzie tego zrozumienia nie ma. Nie bez powodu np. Event Storming mówi o nie używaniu specjalistycznego języka, mamy posługiwać się definicjami zrozumiałymi przez wszystkich. Ma to pomóc w komunikacji, co więcej, to naprawdę działa!

Nie spoczywajmy więc na laurach, przekazując informacje zróbmy wszystko, aby upewnić się czy zostaliśmy dobrze zrozumiani. Zaoszczędzi to nieporozumień, czasem zapobiegnie konfliktom a już na pewno zaoszczędzi czas, który musielibyśmy spędzić na korygowaniu źle zrozumianych rozwiązań.

Łukasz Bręk

15 lat doświadczenia w IT, 8 lat doświadczenia w metodykach zwinnych, PSM, PSPO, Scrum Master zespołów zwinnych, Product Owner, analityk biznesowy/systemowy, Agile Coach, trener Scrum. Swój warsztat szlifował na projektach waterfallowych, dziś skupiony wokół zwinnego dostarczania Produktu.

Click Here to Leave a Comment Below

Walery - 10 sierpnia 2021

Przypomniałem sobie podejście jednego z wykładowców akademickich do kończenia wykładu. Nie zadawał pytań w stylu – czy wszystko wiadomo lub czy ktoś czego nie zrozumiał i czy nie potrzebuje dodatkowego wyjaśnienia. Jego podejście opierało się na podsumowaniu wykład w punktach i zwykle jednym pytaniu, np. który punkt według was wymaga doprecyzowania? Co chcecie aby doprecyzował na kolejnym wykładzie?

I zwykle ktoś zgłaszał taką prośbę 🙂

Co do domniemania (nie)wiedzy – zgadzam się, bardzo ważna jest komunikacja oparta na transparentości, szczerości i otwartości, którą uzupełniłbym o otwartość na dzielenie się informacjami ze styku biznesu, IT, wsparcia klienta itp. Rozmawiać o produkcie w sposób holistyczny.

Reply
Leave a Reply: