Efekt Dunninga-Krugera i jak on się ma do zespołu deweloperskiego?

Im bardziej poznajesz daną dziedzinę, tym bardziej zdajesz sobie sprawę, że jej nie znasz. Zauważasz niewiadome, zadajesz więcej pytań. Postępujący czas zwiększa poziom Twojej wiedzy, jednak czujesz, że wiesz coraz mniej. Z drugiej strony osoby dopiero poznające dane zagadnienie nie mają tego problemu. Są one przekonane, że świetnie rozumieją temat i bez skrępowania chwalą się swoją wiedzą. 

Zjawisko to jest znane jako efekt Dunninga-Krugera.

Reklama



Czym jest efekt Dunninga-Krugera?

Cytując Wikipedię, “efekt Dunninga-Krugera to hipotetyczne zjawisko psychologiczne polegające na tym, że osoby niewykwalifikowane w jakiejś dziedzinie życia mają tendencję do przeceniania swoich umiejętności w tej dziedzinie, podczas gdy osoby wysoko wykwalifikowane mają tendencję do zaniżania oceny swoich umiejętności.

Obrazuje to poniższy rysunek.

Jak pokazuje to powyższy rysunek, jeżeli jesteś na początku drogi w poznawaniu danej dziedziny, nie masz wystarczającej wiedzy, aby ocenić swoje umiejętności. Z tym wiąże się jeszcze jeden element – nie potrafisz poprawnie ocenić poziomu wiedzy innych osób. Pomóc w tym może, paradoksalnie, zwiększenie Twojej wiedzy – podnosząc kwalifikacje zaczynasz trafniej oceniać swój poziom, jak i poziom innych.

Efekt Dunninga-Krugera jest zjawiskiem powszechnym, występującym w każdym aspekcie życia. Przykładowo większość kierowców uważa się za lepszych od innych. Jednak gdyby tak było naprawdę, (prawie) nikt nie jeździłby źle. Już ponad 150 lat temu Karol Darwin stwierdził, że niewiedza (ignorancja) znacznie częściej wywołuje poczucie pewności siebie, niż jej posiadanie.

Kruger i Dunning postawili hipotezę, że w przypadku umiejętności, którą każdy może posiąść w większym lub mniejszym stopniu, osoby niekompetentne:

  • nie dostrzegają swojego niskiego poziomu umiejętności,
  • nie potrafią prawidłowo ocenić poziomu umiejętności u siebie,
  • nie potrafią prawidłowo ocenić poziomu umiejętności u innych,
  • rozpoznają swój niski poziom umiejętności dopiero po nabyciu większej wiedzy.

Późniejsze badania wskazują, że efekt Krugera-Dunninga jest wynikiem m.in. błędu poznawczego zwanego złudzeniem ponadprzeciętności. Jest to błąd poznawczy objawiający się skłonnością do przeceniania swoich umiejętności i cech w stosunku do innych ludzi. 

Jak się to przekłada na życie zespołu deweloperskiego?

Zastanawiasz się, jak to przełożyć na życie zespołu deweloperskiego? Nie jest tutaj istotne w jakiej roli jesteś. Istotne jest, aby dostrzegać ten efekt i móc temu zaradzić

  • dostrzegać ten efekt znaczy zrozumieć zachowanie swoje lub innej osoby,
  • zaradzić znaczy poszukać takich elementów / zachowań, które mogą ten efekt ograniczyć lub przyspieszyć przejście do fazy samo-świadomości (tj. pozyskania dużej wiedzy w danej dziedzinie, a co za tym idzie świadomości (swojej) niewiedzy)

Przykładem bazującym na moim doświadczeniu, są testy nowych funkcji (funkcjonalności).

Patrząc na tablicę Scrumową (Kanbanową) z “wypalaniem” zadań w bieżącym Sprincie (SBL – Sprint Backlog), bardzo często możesz dojść do wniosku, że wąskie gardło w procesie dewelopmentu pojawia się na kroku związanym z testami. 

Wyobraź sobie bardzo prosty proces, jak na rysunku poniżej:

Nałóż na to capacity zespołu (5 deweloperów, 2 testerów) oraz datę końca Sprintu (przykładowo – za dwa dni). Złożenie tych punktów daje Ci informację, że prawdopodobieństwo pozytywnego zakończenia Sprintu jest małe (przez pozytywne zakończenie rozumiem tutaj zrealizowanie (wypalenie) ca 80% zadań*). 

Pierwszym, najbardziej oczywistym krokiem podnoszącym wcześniej wspomniane prawdopodobieństwo, jest pomoc testerom, aby skończyć już wydewelopowane zadania. Aby tego dokonać, deweloperzy (programiści) “przerzucają” się na krok nazwany QA, zamiast realizować zadania z kroku WORKING.

I tutaj dochodzimy do efektu Dunninga-Krugera,  gdzie dla mnie jednym z jego kontekstów w pracy zespołu, jest model T-shape.

Generalnie model jest prosty:

  • oś pozioma pokazuje wszystkie kompetencje zespołu, które są wymagane aby mówić o samoorganizacji (w bieżącym Scrum Guide jest to szersze pojęcie, nazywane samozarządzanie).  
  • oś pionowa pokazuje natomiast “głębię” znajomości danej specyfiki pracy. 

Na przykład – jako specjalista UX znam proces dewelopmentu lub testów (“znam proces” oznacza w tym przypadku “mogę zrobić proste zadania z tych kroków”). Jednak moja wiedza jest szeroka i pogłębiona w temacie UX, czyli w zakresie badań ilościowych i jakościowych z użytkownikami, testów A/B, wyglądu i konstrukcji front-endu**.

I teraz wyobraź sobie dewelopera, który nie ma świadomości istnienia efektu Dunninga-Krugera i T-shape, a ma wykonać testy. Pierwszymi jego stwierdzeniami będą (z dużym prawdopodobieństwem):

  • “to zadanie nie jest adekwatne do mojego poziomu (eksperta)”, 
  • “to jest banalnie proste i nie wiem, z czym jest tutaj problem”,
  • “dlaczego ten krok procesu zabiera tak dużo czasu?”.

Co mogę zrobić?

Pierwszym elementem jest większa świadomość. 

Znajomość efektu Dunninga-Krugera i T-shape w zespole deweloperskim jest niezbędna, aby uzmysłowić sobie (zespołowi), z czym ma do czynienia. I że zachowania, które możecie jako zespół dostrzegać, mogą być efektem już przeanalizowanym i powszechnym.

Drugim elementem jest wejście merytoryczne w model T-shape. 

Czyli podzielenie się wiedzą, którą mają poszczególne role w zespole. I nie chodzi tu tylko o prezentację dotyczącą przebiegu testów czy dewelopmentu. Chodzi o praktykę – realizacja przez poszczególne osoby zadań, których do tej pory nie realizowali. Na początek bardzo prostych, z biegiem czasu coraz trudniejszych. Nie po to, aby przykładowi deweloperzy stali się ekspertami od testowania. Tylko aby mogli zastąpić testerów, wspomóc ich kiedy będzie taka potrzeba. A przede wszystkim zrozumieć od strony praktycznej ich pracę, minimalizując negatywne skutki efektu Dunninga-Krugera.

*) “pozytywne” zakończenie Sprintu nie zawsze oznacza zrealizowanie określonej liczby zadań – w bardziej dojrzałych zespołach powinno oznaczać to osiągnięcie założonej dla Użytkownika wartości (biznesowej)

**) Na potrzeby niniejszego wpisu celowo “spłycam” rolę UX. W bardziej rozwiniętej wersji każda z podanych specjalizacji (badania ilościowe i jakościowe z użytkownikami, testy A/B, wygląd i konstrukcja front-endu) jest odrębną domeną, posiadającą swojego własnego eksperta

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x