Kognitivní zkreslení jsou naučená pravidla vnímání a chování. V podstatě jsou to mentální zkratky, které nevědomě používáme. Při práci nás tyto skryté předsudky mohou nemile překvapit, proto je nutné si uvědomovat, jak fungují, a vědomě jim předcházet. V tomto článku se podíváme na 5 hlavních zkreslení a na užitečné techniky, které lze použít pro jejich minimalizaci.
Optimistické zkreslení
Optimistické zkreslení (nebo také zaujatost) je tendence k přehnané optimističnosti ohledně okolních událostí. V softwarovém světě se vyskytuje hlavně při odhadech náročnosti úkolů, kdy můžeme přeceňovat vlastní dovednosti.
Běžně se může při poradě stát, že váš kolega prohlásí, že daný náhodný úkol zvládne lehce udělat a nezabere mu to skoro žádný čas. Přitom nemá žádnou předchozí znalost o úkolu a vše zakládá na přehnaném optimismu. Jak jste určitě ve světě software už viděli, tyto odhady se často ukážou jako těžce podceněné. A malou třešničkou na dortu je tzv. snadné-obtížné zkreslení, kdy lidé odhadují obtížné úkoly optimisticky a ty snadné zase pesimisticky.
Tomuto kognitivnímu zkreslení se dá vyhnout pomocí těchto přímých otázek:
- Vidíš na úkolu něco, co by mohlo způsobit problémy?
- Vidíš nějaký důvod, proč by tvoje řešení mohlo být nesprávné?
- Zamyslel ses nad závislostmi, které budou ovlivněny změnou tohoto kódu?
Konfirmační zkreslení
Konfirmační zkreslení je dalším dobře známým zkreslením. Značí, že máme tendenci věnovat pozornost pouze těm informacím, které potvrzují naše existující přesvědčení a názory a naopak ignorovat ty informace, které našim názorům protiřečí. V podstatě je to stejné jako mít hlavu v oblacích a utíkat před realitou. Bystrost našeho myšlení se pod vlivem tohoto zkreslení nijak nezlepšuje, právě naopak.
Řekněme, že jeden z programátorů v týmu pevně věří, že dědičnost byla vždy základem OOP. Jiný kolega předloží argument, že tomu tak není. Dědičnost nebyla přijata jen tak a je stále zdrojem debat. Aby první programátor dokázal svoji pravdu, vygooglí třeba “dědičnost základem OOP" a hned první výsledek mu potvrdí jeho názor. Avšak jeho kolega má pravdu. Ani Alan Key, jeden ze zakladatelů OOP, nechtěl implementovat dědičnost v první verzi jazyku Smalltalk.
Konfirmačnímu zkreslení se dá vyhnout následujícími způsoby
- Pokusit se nalézt problémy, které mohou vzniknout, a nehledat jen pozitivní případy. V případě příkladu s Googlem tedy hledat i opačný názor.
- Hledat logické opodstatnění každého předsudku (a nejlépe i zjistit, že jde o předsudek) a hledat i případy, při kterých může být logicky neplatný.
Kotvení
Kotvení popisuje skutečnost, kdy je přirozenou lidskou tendencí spoléhat se při rozhodovacím procesu na jednu informaci či skutečnost, od níž jsou poté odvozována další rozhodnutí. Tato informace však mnohdy vůbec nemusí být relevantní a může náš úsudek ovlivňovat negativním způsobem.
Toto zkreslení se může vyskytnout např. v následující situaci. Scrum master se zeptá týmu při odhadu pracnosti: “Jak dlouho zabere tenhle task? 2 týdny?". Díky efektu kotvení pak nebude záležet, jak je ten úkol ve skutečnosti obtížný, většina týmu se shodne na 2 týdnech. Byli ovlivněni první informací, kterou obdrželi. Stejná technika se využívá i při pohovorech, kdy je pro uchazeče klíčové navrhnout platové ohodnocení jako první.
A jak se kotvení zbavit?
- Neptat se přímo na odhad, ale na úkol samotný: “Kolik toho zvládnete udělat za 2 týdny?"
- Planning poker - všechny názory jsou dány anonymně ve stejný moment. Je to skvělá technika při scrumových odhadech!
Stádový efekt
Stádový efekt je jev, který jedince nutí jít s davem a spíše přistupovat na názory, které viděl u ostatních. Může také označovat oblibu módních trendů - stačí se podívat na dnešní instagramovou kulturu bezcharakterních lidí. Pokud je myšlenka sdílena většinou populace, nabývá na důvěryhodnosti nezávisle na pravdivosti. Sociální sítě jako Twitter a Reddit jsou na to také velice náchylné. Na Twitteru je to ještě podpořeno omezeným počtem znaků, který podporuje povrchní názory a myšlenky.
Z hlediska softwarového vývoje se podívejme opět na příklad s poradou. Charismatická team leaderka argumentuje, proč by celý tým měl přejít z REST API na GraphQL. V prezentaci demonstruje technické výhody nové technologie pro celou firmu. Kolegové také vypadají, že novou technologii chtějí. Bohužel jde o stádový efekt. Team leaderka ve skutečnosti jen způsobila rozruch okolo nové technologie, ale nedokázala hodnotu svého nápadu. Bude to zajímat zákazníka? Uvidí nějaký rozdíl při používání? Přinese to více času, zákazníků nebo peněz firmě? Když jde o novou technologii, jsou pochopitelně všichni nadšení.
Jak se zbavit tohoto kognitivního zkreslení? Těmito otázkami:
- Software vyvíjíme hlavně pro podporu firmy. Nemá smysl používat novou barevnou technologii, pokud nepřinese žádnou extra hodnotu
- Jaká je hodnota toho nápadu?
- Jak přinese nové zákazníky, čas nebo nějakou jinou výhodu?
- Převažují výhody nad cenou implementace?
Atribuční chyba
Atribuční chyba je zkreslení procesů přisuzování. Projevuje se tím, že při vysvětlování chování ostatních lidí má člověk sklon nadsazovat charakterové vlastnosti člověka a podceňovat kontext jeho životní situace nebo náhodnosti okolního prostředí.
Pro poslední zkreslení tohoto článku už vylezeme ze zasedačky a raději si sedneme zpět k práci. Při programování si však všimnete ošklivého bloku kódu. Pomocí git blame zjistíte, kdo je jeho autorem. Je to Lukáš. Samozřejmě. Lukáš je neopatrný, nezodpovědný a impulsivní. Nepřemýšlí nad tím co dělá. Vy byste to udělali lépe!
Ale uklidníte se a pokračujete v implementaci svojí feature. Za chvíli však narazíte na další blok otřesného kódu. Zase Lukáš, to je jasné! Avšak git blame tentokrát řekne jiný příběh - autorem jste vy. Všemožné otázky najednou naplní vaši mysl. Jsem špatný vývojář? Jsem jako Lukáš? Ale tyto pochyby ihned zahodíte a začnou přicházet výmluvy. Samozřejmě, že nejste špatný vývojář, byla zrovna deadline, nebylo dost času, měli jste zrovna rýmu, a psa jste měli u veterináře. To je ve zktrace atribuční chyba - podceňování kontextu životní situace při souzení jiných lidí.
Jak se vyhnout atribuční chybě?
- Obviňování autora nepomůže. Zkuste zjistit příčinu toho špatného kódu.
- Má Lukáš málo zkušeností v tomto segmentu vědění o programovacím jazyku/projektu?
- Byl zrovna pod stresem? Blížil se deadline? Byl přepracovaný? Byl víkendový crunch?
Pozvěte ďáblova advokáta
A to tedy bylo 5 hlavních kognitivních zkreslení. Co jsme se naučili? Kognitivní zkreslení se stávají nám všem. Co proti tomu můžeme dělat je naučit se všímat si jich a umět se jim vyhnout. Nejčastější zkreslení v softwarovém vývoji jsou optimistické, konfirmační a kotvící. Také je velice častý stádový efekt a atribuční chyba. Na softwarové projekty mohou mít katastrofální vliv. Hlavní metodou vyhnutí je vždy pečlivé zamyšlení se nad problémem a hraní si na "ďáblova advokáta" při jeho analýze, tedy snaha hledat nejen pozitivní případy, ale i ty opačné a negativní. Pro více informací o kognitivních zkresleních v softwarovém vývoji doporučují tuto studii, kterou jsem použil jako zdroj pro tento článek. Doufám, že jste si článek užili, a zase příště!
Jan Jileček
