1. Przejawy klątwy wiedzy

1.1. Klątwa wiedzy a Ty

Jeśli tłumaczysz komuś jak ma wypełnić PIT a ktoś zadaje pytanie świadczące o tym, że zupełnie nie rozumie o co chodzi - to spotykasz się z klątwą wiedzy. Jeśli w projekcie znowu programista i product owner się nie dogadali, najpewniej klątwa wiedzy uderzyła ponownie.

Ten artykuł skupia się na wyjaśnieniu dlaczego ludzie mający różne doświadczenia mają problemy z komunikacją. Pokazuje też - z przykładami - co Ty możesz zrobić by zwiększyć szanse, że się dogadasz z rozmówcą.

Zrozumienie tematu ułatwią nam krokodyle i ogórki.

1.2. Jak zrobić jadalne krokodyle z ogórków?

Wyobraź sobie, że dziecko prosi Cię o instrukcje jak zrobić z ogórków takie atrakcyjne wizualnie krokodyle do zjedzenia. Nie możesz po prostu powiedzieć „najpierw obierz ogórka ze skórki i zrób serię krzyżowych nacięć”, prawda? Czegoś takiego dziecko najpewniej nie zrozumie i nie przeprowadzi poprawnie.

Dziecko potrzebuje instrukcji typu „teraz obierz skórkę W TEN SPOSÓB (tu demonstracja), potem weź TEN nóż i trochę natnij skórkę W TEN SPOSÓB. Nie za mocno, nie za lekko”.

Dlaczego?

1.3. Ogórek abstrakcyjny, ogórek konkretny

Jakkolwiek to zabrzmi, „obierz ogórek ze skórki” jest poleceniem abstrakcyjnym. Zauważ - w zależności od owocu czy warzywa to polecenie będzie wykonane inaczej. Zupełnie inaczej obiera się ze skórki ananas, inaczej ogórka. Dziecku brakuje kontekstu i wiedzy jak ma obrać ogórek ze skórki.

Pokazanie dziecku jak obiera się ogórek ze skórki jest działaniem konkretnym. Po kilku takich demonstracjach dziecko zbuduje sobie w głowie model – ziemniaki i ogórki obiera się w taki sposób, mandarynki i pomarańcze w taki sposób a cytryny w ogóle się nie obiera.

Niestety, najczęściej zapominamy o rozróżnieniu między poleceniem abstrakcyjnym a działaniem konkretnym w kontekście biznesowym. A szkoda.

1.4. Jedna chwila w projekcie

 

Początkujący programista stanął przed trudnym dla siebie zadaniem – musi podpiąć sterownik czytnika kart do reszty aplikacji przez WCF. Nie ma pojęcia jak to zrobić, więc idzie do Weteranki.

Weteranka zna dobrze ten projekt. Zapytana przez Początkującego jak wykorzystać sterownik wyciągnęła kilka diagramów i pokazała gdzie oraz jak to powinno być użyte. W jej świecie jest to wystarczająca odpowiedź.

Niestety, Początkujący nie potrafi przełożyć tego diagramu na swój świat. W głębi serca ma nadzieję, że Weteranka podejdzie do jego komputera i pokaże mu – palcem, konkretnie – co i jak ma zrobić. Te diagramy są niezrozumiałe. No ale dobrze, jakoś sobie poradzi. Musi jednak od czegoś zacząć.

Początkujący próbuje więc ograniczyć zakres pytania - pyta Weteranki jak rozwiązać technologicznie to połączenie przez WCF. Ona w odpowiedzi wysyła mu kolejny abstrakt – tutorial znaleziony w Google.

Początkujący nadal nie ma pojęcia jak wykorzystać tą odpowiedź. Nie wie, gdzie w kodzie to się znajduje i jak ten konkretny tutorial mapuje się na jego konkretny problem. W tej chwili Początkujący czuje się jak ostatni idiota i żałuje, że kiedykolwiek Weteranki o coś spytał.

Weteranka chce pomóc – po prostu nie rozumie z czym Początkujący tak naprawdę ma problem. Jeśli z lokalizacją problemu, to przecież diagramy pomogą. Jeśli z technologią, to tamten tutorial pokaże jak wykorzystywać WCFa. W jej świecie, udzieliła najlepszych możliwych odpowiedzi.

To jak to było z tymi krokodylami i ogórkami?

Wyjaśnienia Weteranki pochodziły ze świata abstrakcyjnego a Początkujący potrzebuje komunikacji na poziomie świata konkretnego.

Jeśli Weteranka nie pokaże Początkującemu kilka razy czego oczekuje, Początkujący nie ma dość kontekstu by zbudować sobie adekwatne modele w głowie.

Innymi słowy, doszło do wymiany zdań, ale nie było komunikacji. I w ten sposób dochodzimy do Klątwy Wiedzy.

2. Klątwa wiedzy

2.1. Abstrakcje ratują nas przed złożonością

W jaki sposób ludzie radzą sobie ze złożonością rzeczywistości? Jeżeli prawdą jest, że naraz potrafimy ogarnąć i opanować 5-7 rzeczy w naszej głowie – jak radzimy sobie z ogromnymi rzeczami z dużą ilością zmieniających się elementów? Odpowiedź jest prosta - upraszczamy sobie świat budując wzory i abstrakcje.

  • Jeżeli zaczynamy pracę w nowej domenie, operujemy na czystych konkretach i przykładach. Każdy problem jest unikalny i nowy. Każdy musimy rozwiązać wymyślając od zera.
  • Jeżeli pracujemy przez pewien czas z daną domeną, zaczynamy widzieć pewne podobieństwa między problemami. Zaczynamy budować sobie w głowie modele i wzory. To bardzo przyspiesza naszą pracę i umożliwia nam operowanie na „większych” konstrukcjach w głowie.
  • Po pewnym czasie na podstawie tych modeli budujemy kolejne modele i abstrakcje.

Innymi słowy: im bardziej jesteśmy doświadczeni w danym obszarze, tym bardziej abstrakcyjnie o nim myślimy. Konkretne problemy jakie napotykamy są po prostu przejawami lub przykładami pewnej abstrakcji, z którą już się kiedyś spotkaliśmy.

2.2. Złożoność robienia soku jabłkowo-marchwiowego

Załóżmy, że poproszę Cię o pomoc w zrobieniu soku jabłkowo-marchwiowego. Twoje pierwsze pytanie? Najpewniej „gdzie jest nóż”.

Ale co ma nóż do soku?

Ty wiesz, że żeby zrobić sok jabłkowo-marchwiowy potrzebne są następujące kroki:

  • Obrać owoce
  • Pokroić owoce na kawałki
  • Wrzucić kawałki owoców do sokowirówki

Ale to jest tylko najwyższy poziom abstrakcji. W rzeczywistości:

  • Pod słowem „owoce” kryją się „odpowiednie owoce i warzywa” – nie każdy owoc obieramy (np. winogrono lub agrest), nie każde warzywo się nadaje (np. marchewka TAK, ziemniak NIE)
  • „Obrać owoce” oznacza odpowiednie użycie noża lub obieraczki. Ale nie każde narzędzie się nada - np. młotek już się nie przyda. Co więcej, niektóre części niektórych owoców się wycina (np. gniazdo z jabłka czy końcówki z banana).
  • …i tak dalej

2.3. Sok jabłkowo-marchwiowy przydaje się w biznesie

„Jak zrobić sok jabłkowo-marchwiowy” jest czymś co raczej większość dorosłych potrafi zrobić. Wybrałem ten prosty przykład, bo jeżeli złożoność tak bardzo eksploduje dla czegoś tak prostego, to tym bardziej będzie eksplodować dla dziedzin takich jak:

  • Programowanie
  • Marketing
  • Prowadzenie szkoleń
  • Budowanie procesów…

Za każdym razem budujemy abstrakcje na abstrakcjach na kolejnych abstrakcjach, a gdzieś tam na samym dole znajduje się zbiór konkretnych doświadczeń z których wyciągnęliśmy te pierwsze abstrakcje.

To właśnie jest nasz mechanizm radzenia sobie ze złożonością i uczenia się nowych rzeczy. I to sprawia, że im bardziej doświadczony nasz weteran, tym bardziej abstrakcyjnie myśli o problemie.

2.4. Sok jabłkowo-marchwiowy a doświadczenie w branży

Doświadczonego weterana od początkującego odróżnia właśnie ilość warunków brzegowych, które posłużyły do zbudowania abstrakcji najwyższego rzędu:

  • Jeżeli ktoś nigdy nie widział obieraczki, jedyne sposoby obierania owoców to „nóż” (dla owoców ze skórką) oraz „ręka” (dla bananów).
  • Jeżeli ktoś nigdy nie obierał ananasa, najpewniej nie ma pojęcia jak się do tego zabrać.

I to jest właśnie powód, dla którego im bardziej ktoś jest doświadczony tym trudniej jest przekazać wiedzę komuś niedoświadczonemu.

Na pewnym poziomie abstrakcji nie zauważamy już, że to, co my uważamy za konkretne i oczywiste jest dla osoby z której rozmawiamy niezrozumiałą abstrakcją , bełkotem pozbawionym kontekstu konkretnego zadania stojącego przed tą osobą.

Co więcej, w zależności od różnorodności doświadczeń możemy mieć zupełnie inne abstrakcje mimo podobnej (teoretycznie) wiedzy podstawowej. Dwóch różnych “frontend developerów” może mieć zupełnie inne doświadczenia i niewiele wspólnych abstrakcji.

Tak więc sam fakt, że w ogóle potrafimy się czasem skomunikować to w ogóle jest powód do dumy i chwały.

2.5. Kiedy mamy do czynienia z klątwą wiedzy na co dzień?

Można powiedzieć, że klątwa wiedzy jest ogromnym problemem i pojawia się bardzo często:

  • Gdy ekspert w jednej dziedzinie próbuje skomunikować się z ekspertem w drugiej dziedzinie
  • Gdy bardziej doświadczona osoba próbuje przekazać wiedzę mniej doświadczonej osobie
  • Gdy próbuję wytłumaczyć o co mi chodzi, zwłaszcza w grupie

To powyżej jest bardzo abstrakcyjne, prawda? Przenieśmy przykłady na coś bliższego, co można zobaczyć na co dzień (by ujednolicić nasz kontekst i pokonać klątwę wiedzy):

  • Gdy doświadczony lider projektu próbuje przekazać problem biznesowy doświadczonemu programiście (różne konteksty -> różne abstrakcje -> różne modele w głowie)
  • Gdy początkujący programista przychodzi po radę do weterana; początkujący może być weteranem w innej firmie, ale z konkretnym obszarem w tej firmie nie miał jeszcze do czynienia
  • Gdy piszę artykuł, ja dokładnie wiem jaką ideę mam w głowie. Jednocześnie, nie zawsze zejdę z abstrakcjami odpowiednio nisko byśmy my – Ty i ja – mieli wspólny kontekst i wspólne klocki naszej komunikacji

Wiedząc już o czym mówimy, teraz uprośćmy definicję i zbudujmy wspólny model - pojęcie klątwy wiedzy. Tak więc - klątwa wiedzy pojawia się za każdym razem gdy się komunikują ludzie mający w głowie inne abstrakcje i inne modele. Może to wynikać z pochodzenia z różnych światów, z pełnienia innych ról lub z posiadania innych doświadczeń.

Jeśli pomyślicie o abstrakcjach jako o „klockach/wzorcach myślenia”, klątwa wiedzy pojawia się wtedy, gdy komunikujący się ludzie nie mają dość wspólnych klocków by zbudować wspólny kontekst. Jeszcze raz ten sam rysunek dla zobrazowania sytuacji:

Jak zatem można sobie z tym poradzić?

3. Pokonać klątwę wiedzy

3.1. Bardzo konkretne konkrety

Początkujący operuje tylko na poziomie konkretnych przykładów. Ekspert może operować na poziomie przykładów oraz na poziomie abstrakcji. To oznacza, że jeżeli nie mamy możliwości działania na poziomie wspólnej abstrakcji to Ekspert musi zejść do bardzo konkretnych konkretów.

To nie oznacza, że rozmówca Eksperta jest „głupi”. To tylko oznacza, że ich abstrakcje się do tego stopnia różnią, że komunikowanie się w abstrakcjach może wprowadzić ogromne pole nieoznaczoności.

Jakby się tak zastanowić, 85% problemów z tworzeniem oprogramowania dla biznesu jest powiązana z tym punktem:

  • Nie wiem, jak przetestować tą funkcjonalność (więc nie wiem co robię; to wymaga podania konkretnych przypadków testowych i przykładów; jestem za wysoko w abstrakcji)
  • Nie wiem, czy spełniam oczekiwania w firmie (bo nie wiem, czego konkretnie ode mnie się oczekuje; nie mam obserwowalnych i mierzalnych KPI)
  • Nie wiem, co to jest „ładny i wydajny software” (bo nikt mi nie powiedział po czym KONKRETNIE poznam sukces)

Parafrazując – jeżeli uważasz, że między Tobą i kimś pojawił się problem komunikacyjny, musicie w komunikacji zejść do tak konkretnego poziomu by ów problem zniknął. A najlepiej i najłatwiej wykryć to i ujednolicić przez przykłady.

3.2. Odpowiednie media i środki w odpowiednim kontekście

Gdy próbuję zrozumieć całkowicie nowe koncepty lub poszerzyć fundamenty tych, które już mam to czytam książki. Jako przykład, tego artykułu by nie było gdyby nie dwie doskonałe książki: „Made to Stick” braci Heath oraz „Efficiency in Learning: Evidence-Based Guidelines to Manage Cognitive Load” Clark, Nguyen, Sweller.

Jednak gdy np. próbuję skonfigurować Visual Studio Code lub sprawdzić jak nagrywa się filmik to wykorzystuję filmy na Youtube.

Dlaczego? Mówiąc prozaicznie, za dużo „alt-tab”. Spójrz proszę na ten tutorial jak zrobić proste makro w Wordzie.

Ten tutorial jest moim zdaniem dobry. Pokazuje co mam znaleźć i co mam kliknąć. Ale nie pokazuje gdzie to jest – to, co widzę na moim komputerze wygląda tak:

Gdybym miał to w formie filmiku, nie musiałbym cały czas skakać pomiędzy tutorialem a makrem. Mógłbym obejrzeć sobie filmik raz oraz wrócić do tego fragmentu którego nie potrafiłbym powtórzyć.

Innymi słowy, gdy potrzebna mi jest procedura, wolę oglądać ją dynamicznie – z całym kontekstem narzędziowego ekosystemu w którym się znajduję. Jeśli konfiguruję Visual Studio Code to chcę widzieć jakie dostanę odpowiedzi od narzędzia na każdym etapie konfiguracji.

Gdy chcę zrozumieć złożony koncept, wolę przyswoić to statycznie – w formie tekstu i obrazu, w swoim czasie – z kontekstem „mentalnym” tego konceptu. Innymi słowy, jeśli próbuję zrozumieć Klątwę Wiedzy, chcę móc przeczytać kilka przykładów demonstrujących to zjawisko i móc do tych przykładów wrócić jeśli są mi w danym momencie potrzebne.

Jak to wykorzystać? Jeśli słowa nie pomagają, narysuj koncept i poproś o pokazanie z czym Twój rozmówca ma problem. Jeśli ważna jest konkretna sekwencja czynności, użyj filmiku a nie tekstu. Jeśli ważne jest konkretne miejsce w kodzie, pokaż je zamiast mówić o nim.

Innymi słowy, określ co jest ważnego w tej wymianie zdań i skup się na owym ważnym obszarze używając odpowiedniego medium. Jeśli nie wiesz które medium jest odpowiednie, tak długo eksperymentuj aż znajdziesz właściwe.

3.3. Nie przeskoczysz kilku poziomów abstrakcji

W jaki sposób wytłumaczyć bardzo początkującemu programiście, nie wiedzącemu jeszcze co to są pętle i zmienne coś takiego jak wykorzystanie „strategii” czy „mediatora”? (przy założeniu, że skupiamy się na korzyściach wykorzystania)

Lub w jaki sposób wyjaśnić początkującemu pracownikowi znaczenie tego, że zadowolenie ekspertów w kluczowej dla firmy technologii zaczyna spadać i że nic z tym nie zrobimy? (przy założeniu, że bonusy dla managementu są powiązane z działaniami prowadzącymi do tego spadku zadowolenia).

Nie jesteś w stanie. Możesz to powiedzieć, ale czy zrozumieją i będą umieli wykorzystać?

Mówiąc całkowicie brutalnie, nie da się przeskoczyć pewnego poziomu abstrakcji. Bez zrozumienia i zinternalizowania kontekstu przez odbiorcę nie masz możliwości wyjaśnienia konceptów ze zbyt wysokiego poziomu abstrakcji.

Swego czasu po raz pierwszy spotkałem się z książkami i dziełami Toma Gilba. Na początku była to dla mnie mieszanka „to jest oczywiste” oraz „to jest dziwne, nie rozumiem czemu on tak robi”.

Dziś sam stosuję część jego technik i uważam je za bardzo skuteczne w kontekście w którym zostały zaprojektowane i przeznaczone do użycia. Gdy się z nimi spotkałem po raz pierwszy, nie miałem odpowiedniej ilości porażek i doświadczeń by móc docenić znaczenie tych technik.

Jak wykorzystać tę wiedzę? Nie zawsze jesteś w stanie wytłumaczyć dlaczego coś robisz – czasami odbiorca nie ma odpowiednich abstrakcji które są potrzebne do zrozumienia przyczyn Twojego działania. Czasami jedyne co możesz zrobić to po prostu:

  • Zidentyfikować, że odbiorca potrzebuje konkretnej, dyrektywnej instrukcji
  • Odpowiedzieć na pytanie w kontekście problemu tej osoby
  • Wydać polecenie zamiast próbować coś wytłumaczyć

Bardzo dużo czasu mi zajęło dojście do tego wniosku. Jest to sprzeczne z moim naturalnym podejściem, ale to zjawisko często się pojawiało w moich doświadczeniach i w literaturze. W końcu musiałem uznać, że to nie przypadek.

Jest zatem miejsce na wyjaśnienia, ale jest też miejsce na dyrektywne, precyzyjne polecenia.

4. Podsumowując

Klątwa wiedzy jest efektem ubocznym naszego naturalnego mechanizmu radzenia sobie ze złożonością. Budujemy abstrakcje, by radzić sobie z mniejszą ilością przemieszczających się części. Dzięki temu mechanizmowi osoba doświadczona potrafi robić rzeczy, które dla niedoświadczonej wyglądają często jak magia.

Niestety, z uwagi na upiorną złożoność rzeczywistości nawet takie abstrakcje są niewystarczające. Dlatego budujemy abstrakcje na abstrakcjach, na bazie naszego doświadczenia oraz rzeczy z którymi się spotkaliśmy.

Te abstrakcje sprawiają, że jeżeli mamy do czynienia z ludźmi mającymi inne doświadczenia to mamy problemy komunikacyjne. Inni eksperci w danej dziedzinie z innymi doświadczeniami mogą mieć zupełnie różne opinie na dany temat niż my – bo spotkali się z innymi rzeczami w przeszłości.

Szczególnym przypadkiem tego wszystkiego są osoby wiedzące o danym zagadnieniu mniej niż my. Jeżeli wiedzą tylko „trochę mniej”, jesteśmy w stanie się z nimi porozumieć schodząc na jedną warstwę abstrakcji niżej. Gorzej, jeśli wiedzą dużo mniej niż my. W tym momencie to, co dla nas jest konkretne dla nich może być abstrakcyjnym bełkotem.

To zjawisko nazywamy klątwą wiedzy – im więcej wiesz, tym trudniej Ci coś przekazać osobom, które nie znają się na danym zagadnieniu.

Jak sobie z tym można poradzić?

  • Jeżeli chcesz pomóc komuś rozwiązać problem, zejdź do najniższego możliwego poziomu abstrakcji który oboje rozumiecie. To najpewniej będzie pojedynczy, namacalny przykład.
  • Nie jesteś w stanie przekazać wysokopoziomowego modelu komuś, kto wie w danym zakresie dużo mniej od Ciebie. Możesz jedynie wydać bezpośrednie instrukcje i polecenia lub odnieść się do konkretnego namacalnego przykładu.
  • Zweryfikuj z jakiego typu problemem masz do czynienia. Jeśli to coś wymagającego serii kroków w czasie, rozważ użycie filmiku lub przykładu bezpośredniego. Jeśli to coś bardziej statycznego (np. niezrozumienie diagramu), wyjaśnij to na przykładzie rysunku. Dopasuj medium do problemu.
  • Przykłady, przykłady, przykłady. Ten artykuł dotyczy bardzo trudnego i niezbyt intuicyjnego tematu, więc ma mnóstwo przykładów. Jeśli do Ciebie to trafia, to masz dowód, że ta metoda działa.

Przede wszystkim – nie denerwuj się, że Twój rozmówca „nie ogarnia”. To nie jest głupi człowiek. Po prostu w przeszłości ów rozmówca miał inne doświadczenia niż Ty i ma inny model abstrakcji w głowie. To jest coś, co można naprawić – ale niekoniecznie dzisiaj i niekoniecznie na tym poziomie na którym komunikujecie się teraz.

I tym optymistycznym akcentem chciałbym zakończyć ów artykuł. Powodzenia!