20 najčešćih kognitivnih pristranosti koje iskrivljuju odlučivanje u tech poduzetništvu i razvoju softvera. Komplement mentalnim modelima — modeli govore kako razmišljati, pristranosti otkrivaju gdje razmišljanje zakazuje.
Tendencija da tražiš, interpretiraš i pamtiš informacije koje potvrđuju ono što već vjeruješ, dok ignoriraš ili umanjuješ dokaze koji proturječe. Ovo je najraširenija i najopasnija pristranost jer utječe na sve ostale — čak i kad znaš za nju, teško ju je izbjeći.
Osnivač je uvjeren da korisnici žele mobilnu aplikaciju. Provodi anketu, ali formulira pitanja tako da navode na potvrdan odgovor ("Koliko bi vam koristila naša mobilna aplikacija?" umjesto "Koji kanal preferirate?"). Ignorira podatke koji pokazuju da 90% korisnika pristupa isključivo preko desktopa.
Aktivno traži dokaze protiv svoje hipoteze. Prije važne odluke, zaduži nekoga u timu da igra "đavoljeg odvjetnika" — njegova jedina zadaća je naći razloge zašto je ideja loša. Kad čitaš podatke, prvo pogledaj anomalije i kontra-primjere, ne potvrde.
Pretjerano oslanjanje na prvu informaciju (sidro) koju dobiješ pri donošenju odluke. Jednom kad je sidro postavljeno, sve buduće procjene gravitiraju prema njemu, čak i kad je sidro potpuno proizvoljno ili irelevantno.
Na planiranju sprinta, tech lead kaže: "Ovo bi moglo trajati oko 3 tjedna." Ostatak tima automatski procjenjuje u rasponu 2-4 tjedna. Bez tog sidra, realna procjena bi možda bila 6-8 tjedana. Isto se događa kad klijent prvi spomene budžet — svaka daljnja kalkulacija se vrti oko tog broja.
Prije nego čuješ tuđe procjene, napravi svoju. Na planning meetingu, neka svaki član tima napiše svoju procjenu prije diskusije (planning poker). Kad procjenjuješ cijenu projekta, kreni od troškova i margine, ne od klijentovog budžeta.
Ljudi s malo znanja u nekoj domeni imaju tendenciju precjenjivati svoju kompetenciju, dok eksperti često podcjenjuju svoju. Rezultat: oni koji najmanje znaju su najsamopouzdaniji, a oni koji najviše znaju su najoprezniji.
Junior developer koji je upravo završio online tečaj o Kubernetesu insistira da tim treba migrirati cijelu infrastrukturu na K8s. Nije svjestan kompleksnosti mrežnog sloja, upravljanja certifikatima, monitoringa i operativnog tereta. Istovremeno, senior DevOps inženjer koji 5 godina radi s K8s preporučuje jednostavniji Docker Compose za trenutni scale.
Budi posebno oprezan kad se osjećaš vrlo samopouzdano u domeni koju si tek počeo učiti. Koristi "meta-znanje" test: "Mogu li nabrojati 10 stvari koje ne znam o ovoj temi?" Ako ne možeš — vjerojatno ne znaš dovoljno da bi procijenio koliko ne znaš.
Procjenjuješ vjerojatnost ili važnost nečega na temelju toga koliko lako ti primjeri dolaze na pamet. Dramatični, nedavni ili emocionalno nabijeni događaji djeluju vjerojatnijim nego što jesu, dok tihi, statistički značajni trendovi prolaze ispod radara.
Čitaš Hacker News i vidiš 3 članka o sigurnosnim probojima kroz SQL injection. Zaključuješ da je SQL injection najveća prijetnja i usmjeravaš cijeli sigurnosni budžet na to. U stvarnosti, tvoja najveća ranjivost su neažurirane npm ovisnosti o kojima nitko ne piše senzacionalističke članke.
Ne donosi sigurnosne, tehničke ili poslovne odluke na temelju anegdota i vijesti. Traži podatke: logove, metrike, izvješća industrije. Pitaj se: "Znam li ovo iz podataka ili iz priče koju sam nedavno čuo?" Ako je iz priče — idi po podatke.
Tendencija da prihvatiš ideje, trendove ili tehnologije zato što ih mnogi drugi prihvaćaju, bez vlastite kritičke evaluacije. Što je više ljudi "na brodu", to se brod čini sigurnijim — ali popularnost nije dokaz kvalitete ili prikladnosti.
"Svi prelaze na mikroservise, i mi moramo." "AI treba biti u svakom proizvodu." "Moramo koristiti Kubernetes jer svi to rade." Tim adoptira trending tehnologiju bez evaluacije odgovara li njihovom kontekstu — 5 developera, 1.000 korisnika, jedna domena. Rezultat: 6 mjeseci potrošeno na infrastrukturu umjesto na proizvod.
Za svaku tehnološku odluku postavi pitanje: "Koji specifični problem ovo rješava za nas?" Ako odgovor počinje s "svi to koriste" ili "to je budućnost" umjesto konkretnog problema — stani. Napravi lightweight evaluaciju: kontekst, trade-offovi, alternative.
Preferencija prema trenutnom stanju stvari, čak i kad bi promjena donijela objektivno bolje rezultate. Gubitak koji nastaje promjenom se percipira kao veći od potencijalne dobiti. Rezultat: sustavi, procesi i tehnologije ostaju dugo nakon što su prestali biti optimalni.
Tim i dalje koristi SVN jer "uvijek smo koristili SVN". Migracija na Git bi trajala tjedan dana i dramatično poboljšala workflow, ali nitko ne želi pokrenuti promjenu. Isto vrijedi za stare interne alate, zastarjele deploymente procese ili legacy kodne baze koje "rade, pa zašto dirati".
Jednom kvartalno napravi "zero-based" reviziju: "Da danas krećemo ispočetka, bismo li odabrali ovaj alat/proces/arhitekturu?" Ako ne — pokreni evaluaciju alternative. Kvantificiraj trošak neaktivnosti: koliko sati tjedno gubimo na workarounde oko zastarjelog sustava?
Sustavno podcjenjivanje vremena, troškova i rizika projekata, uz istovremeno precjenjivanje koristi. Čak i kad imaš iskustvo s prošlim projektima koji su kasnili, vjeruješ da će ovaj put biti drugačije. Optimizam pobjeđuje empiriju.
"Trebat će nam 2 mjeseca za MVP." Šest mjeseci kasnije, tim je još na 70%. Zašto? Jer nitko nije računao na: integraciju s legacy sustavom, promjene zahtjeva, bolovanja, onboarding novog člana, refaktoring kad se prvotni pristup pokazao krivim.
Koristi "reference class forecasting" — umjesto da procjenjuješ ovaj projekt iznutra, pogledaj koliko su trajali slični projekti u prošlosti i koristi to kao bazu. Dodaj 50% buffer na svaku procjenu. Ako tim kaže "2 mjeseca", planiraj za 3. Ako kažeš klijentu — planiraj za 4.
Kad nešto dobro razumiješ, postaje ti gotovo nemoguće zamisliti kako je ne razumjeti to. Pretpostavljaš da drugi imaju isti kontekst i znanje kao ti, pa komuniciraš na razini koja im je nerazumljiva.
Developer piše dokumentaciju za API koristeći interne akronime, pretpostavljajući poznavanje arhitekture i ne objašnjavajući osnovne koncepte. Novi članovi tima troše dane pokušavajući dešifrirati dokumentaciju. Isto se događa na demou klijentu kad developer objašnjava feature koristeći tehnički žargon.
Kad pišeš dokumentaciju ili držiš prezentaciju, zamisli svoju ciljanu publiku i piši za nju — ne za sebe. Koristi "mama test": objasni koncept nekome izvan struke. Ako ne razumiju — pojednostavni. Uvijek definiraj akronime pri prvom korištenju i daj kontekst.
Pridaješ neproporcionalno veliku vrijednost stvarima koje si sam napravio, neovisno o njihovoj objektivnoj kvaliteti. Trud uložen u izgradnju nečega stvara emocionalnu vezanost koja iskrivljuje procjenu vrijednosti.
Tim je 4 mjeseca gradio custom logging sustav. Objektivno, ELK Stack ili Grafana Loki bi bili bolji, jeftiniji i bolje održavani. Ali tim brani svoj sustav jer su ga sami izgradili: "Naš je brži za naš use case" (bez benchmarka), "Mi ga razumijemo bolje" (jer ga nitko drugi ne koristi), "Ima točno ono što trebamo" (i ništa drugo, uključujući dokumentaciju).
Kad evaluiraš build vs. buy odluke, isključi emociju uključenu u "build" dio. Pitaj se: "Kad bi netko drugi ovo napravio i ponudio mi, bih li to koristio?" Provedi objektivnu evaluaciju: usporedi feature-e, troškove održavanja, dokumentaciju, community podršku. Ako vlastito rješenje gubi — prihvati to.
Novije informacije i iskustva imaju neproporcionalno velik utjecaj na tvoje odluke u usporedbi sa starijim, jednako relevantnim podacima. Ono što se dogodilo prošli tjedan čini se važnijim od trenda kroz cijelu godinu.
Zadnji release je imao kritični bug u produkciji. Reakcija: "Moramo udvostručiti QA tim i dodati 3 nova sloja testiranja!" Realnost: prošlih 20 releaseova je prošlo bez problema, a ovaj bug je bio edge case koji nikakav manualni QA ne bi uhvatio. Bolje rješenje: dodati jedan automatizirani test za taj specifični scenarij.
Kad donosiš odluku nakon incidenta ili neočekivanog događaja, zaustavi se i pogledaj širu sliku. Pitaj se: "Je li ovo trend ili anomalija?" Pregledaj podatke za posljednjih 6-12 mjeseci, ne samo posljednji tjedan. Donosi strukturne promjene na temelju trendova, ne reakcije na jednu točku podataka.
Pozitivan dojam u jednoj dimenziji (karizmatičnost, dizajn, brand) preliva se na procjenu u potpuno nepovezanim dimenzijama (kompetencija, pouzdanost, kvaliteta koda). Isto vrijedi obrnuto — jedan negativan dojam baca sjenu na sve ostalo.
Kandidat na intervjuu ima GitHub profil s 5.000 zvjezdica na jednom open-source projektu. Tim ga ocjenjuje kao "odličnog inženjera" bez dulje evaluacije. U praksi se ispostavi da je taj projekt bio viralni one-liner, a kandidat nema iskustva s produkcijskim sustavima, timskim radom i code reviewom.
Razdvoji dimenzije evaluacije. Na intervjuima koristi strukturirane procjene: zasebno ocijeni tehničko znanje, komunikaciju, problem-solving i timski rad. Za proizvode i alate: ne biraj na temelju dizajna ili marketinga — napravi proof of concept i testiraj stvarnu funkcionalnost.
Način kako je informacija prezentirana (uokvirena) drastično utječe na odluku, čak i kad je sadržaj identičan. "90% uptime" zvuči dobro; "87.6 sati downtime godišnje" zvuči loše — a to je ista stvar.
Product owner prezentira metriku: "Naša konverzija je porasla 50%!" Tim slavi. Kontekst: konverzija je porasla s 0.2% na 0.3%. U apsolutnim brojevima: 2 korisnika više mjesečno. Isto se događa s izvješćima o performansama: "Smanjili smo response time za 40%" (s 500ms na 300ms — korisnik ne primjećuje razliku).
Uvijek traži apsolutne brojeve uz postotke. Kad ti netko prezentira metriku, pitaj: "Koliko je to u apsolutnim brojevima?" Kad sam prezentiraš podatke, uključi obje perspektive. Budi svjestan i vlastitog framinga — kad pitaš tim "Što mislite o ovom riskantnom pristupu?", već si uokvirio odgovor.
Gubitak boli otprilike dvostruko više nego što dobitak iste veličine raduje. Ovo nas tjera da izbjegavamo rizike čak i kad je očekivana vrijednost pozitivna, držimo se gubitničkih pozicija nadajući se oporavku i donosimo iracionalno konzervativne odluke.
SaaS ima feature koji koristi 3% korisnika, ali generira 15% support tiketa. Tim se boji maknuti feature jer "gubitak korisnika" zvuči strašno, čak i kad bi gašenje featurea oslobodilo 20% kapaciteta za razvoj nečeg što korisnici zapravo žele. Jednako: strah od podizanja cijena — "izgubiti ćemo korisnike!" — ignorira činjenicu da bi 10% povišica uz 5% churna donijela znatno više prihoda.
Kvantificiraj i gubitak i dobitak. Napravi tablicu: "Što gubimo ako promijenimo?" vs. "Što gubimo ako NE promijenimo?" Često je trošak neaktivnosti veći od troška promjene, ali je manje vidljiv. Formuliraj odluku kao izbor između dva gubitka, ne kao "promjena vs. sigurnost".
Želja za harmonijom i konsenzusom u grupi potiskuje kritičko mišljenje, alternativne ideje i realistične procjene rizika. Članovi grupe cenzuriraju vlastite sumnje, a grupa kolektivno donosi odluke koje nijedan pojedinac ne bi donio sam.
Na arhitektonskom reviewu, CTO predloži pristup. Nitko ga ne ospori — ne zato što je pristup dobar, nego jer je CTO taj koji ga predlaže. Svi kimaju, nitko ne pita "što ako ovo ne skalira?" ili "jesmo li razmotrili alternative?". Šest mjeseci kasnije, sustav se raspada pod opterećenjem i svi govore: "Ja sam znao da to neće raditi."
Uvedite "pre-mortem" praksu: prije početka projekta, zamislite da je projekt propao i svaki član tima anonimno napiše zašto. Osiguraj da najjunioriji član tima govori prvi na meetingu (tako ga ne može ušutkati seniorniji glas). Aktivno nagrađuj neslaganje: "Hvala što si podigao ovo pitanje."
Negativna iskustva, informacije i emocije imaju jači utjecaj na tvoje stanje i odluke od pozitivnih jednakog intenziteta. Jedan negativan komentar korisnika nadglasava 50 pozitivnih recenzija. Jedan bug report briše sjećanje na 20 uspješnih releaseova.
Na retrospektivi, tim je lansirao 5 novih featurea, smanjio response time za 60%, a korisničke ocjene su rekordne. Ali jedna ljutita email poruka od klijenta dominira cijelom diskusijom, a tim izlazi s osjećajem da je sprint bio neuspješan.
Strukturiraj retrospektive i donošenje odluka tako da prvo pregledaš pozitivne rezultate i metrike. Napravi "omjer": za svaku negativnu informaciju, aktivno pronađi 3-5 pozitivnih protuprimjera. Ne ignoriraj negativno — ali osiguraj da mu daješ proporcionalnu težinu u odnosu na ukupnu sliku.
Vrednuješ ono što posjeduješ više nego identičnu stvar koju ne posjeduješ. Kad je nešto "tvoje" — tvoj kod, tvoj proces, tvoj tim — postaje iracionalno skupo za "prodati" (odustati). Ovo je srodan, ali različit koncept od IKEA efekta: IKEA efekt dolazi iz truda uloženog u stvaranje, dok efekt posjedovanja dolazi iz samog vlasništva.
Tech lead je godinama gradio monolitnu arhitekturu. Objektivna analiza pokazuje da bi migracija na modularne servise ubrzala development za 40% i smanjila incidente. Ali tech lead procjenjuje vrijednost postojeće arhitekture kao "neprocjenjivu" jer ju je on dizajnirao i razumije svaki njezin dio.
Zamijeni pitanje "Koliko vrijedi ono što imamo?" s "Kad bismo kretali od nule, bismo li ovo kupili/izgradili po ovoj cijeni?" Ako ne — imaš problem efekta posjedovanja. Potražite evaluaciju od nekoga izvan tima tko nema emocionalnu vezu s postojećim sustavom.
Nakon što se nešto dogodi, čini ti se da si to "oduvijek znao" ili da je ishod bio očigledan. Ovo iskrivljuje učenje iz pogrešaka jer te sprečava da priznaš pravu nesigurnost koja je postojala u trenutku odluke.
Produkcijski incident: baza podataka je pala pod opterećenjem na Black Friday. Post-mortem: "Bilo je očigledno da ćemo imati 10x više prometa! Trebali smo skalirati unaprijed!" U trenutku odluke, podaci su govorili da će rast biti 2-3x (što je i bio prosjek prošlih godina). Nikad nije bilo "očigledno" — to je hindsight bias.
Dokumentiraj odluke i njihov kontekst u trenutku donošenja — ne naknadno. Zapisuj: "Odlučili smo X jer smo znali Y i pretpostavili Z." Kad evaluiraš prošle odluke, procjenjuj ih na temelju informacija koje su bile dostupne tada, ne onoga što znaš sada. Na post-mortemima pitaj: "Koji signal smo mogli realno uhvatiti?" — ne "zašto nismo znali?"
Tendencija da pridaješ veću težinu mišljenju autoriteta (šef, poznati developer, osoba s impresivnim CV-om) čak i kad njihov autoritet nije relevantan za temu o kojoj se odlučuje. Titula ili reputacija zamjenjuje kritičku evaluaciju argumenata.
CTO kaže "Trebamo prepisati backend u Rust." Tim se slaže bez diskusije. Ali CTO je ekspert za product strategy, nikad nije pisao Rust u produkciji, a njegova procjena se temelji na blogu koji je pročitao prošli vikend. Nitko ne pita: "Na temelju čega? Koji su podaci? Tko u timu zna Rust?"
Evaluiraj argument, ne osobu. Pitaj "Zašto?" neovisno o tome tko predlaže. Uvedite kulturu u kojoj je ok reći: "Razumijem tvoju poziciju, ali možeš li podijeliti podatke iza toga?" Posebno budi oprezan s eksternim autoritetima — poznati developer na konferenciji ne poznaje tvoj specifični kontekst.
Precjenjuješ koliko drugi ljudi primjećuju tvoje greške, nedostatke ili promašaje. Misliš da svi gledaju u tebe i sude ti, dok su zapravo zaokupljeni vlastitim problemima. Ovo paralizira donošenje rizičnih ali potencijalno korisnih odluka.
Developer izbjegava predlagati nove ideje na tehničkim meetinzima jer se boji da će reći nešto glupo. Product manager odgađa lansiranje MVP-ja jer "nije dovoljno dobar" i boji se javne kritike. Osnivač ne objavljuje blog postove o svom proizvodu jer "svi će vidjeti da smo mali". U stvarnosti: nitko ne obraća toliku pažnju koliko misliš.
Smanji ulog: lansiraj MVP brže, piši blog postove bez perfekcionizma, predloži ideju na meetingu. Najgore što se može dogoditi je obično daleko blaže od onoga što zamišljaš. Prakticiraj "100 dana odbijanja" mentalitet: svjestan izlazak iz zone komfora smanjuje strah od tuđeg suda.
Tendencija da odbiješ koristiti postojeća rješenja, alate ili ideje koje nisu nastale unutar tvog tima ili organizacije. Kombinacija efekta posjedovanja, IKEA efekta i ponosa — "mi to možemo napraviti bolje" — čak i kad objektivno ne možete.
Tim gradi vlastiti sustav za autentifikaciju umjesto da koristi Auth0 ili Keycloak. Vlastiti message queue umjesto RabbitMQ ili Kafka. Vlastiti CSS framework umjesto Tailwinda. Svaki od ovih projekata troši mjesece razvoja, zahtijeva održavanje, nema dokumentaciju i ima sigurnosne rupe koje etablirana rješenja su davno zakrpala.
Napravi "build vs. buy" matricu za svaki projekt: jezgrena kompetencija (build) vs. komoditet (buy). Ako nešto nije vaša jezgrena kompetencija i ne daje vam konkurentsku prednost — koristite postojeće rješenje. Uložite vrijeme u proizvod, ne u infrastrukturu. Jedini valjani razlog za "build" je specifičan zahtjev koji nijedno postojeće rješenje ne može zadovoljiti.
Uvedi "devil's advocate" ulogu. Na svakom važnom meetingu, jedna osoba ima zadatak aktivno osporavati dominantan prijedlog. Rotiraj ulogu — svi moraju vježbati kritičko mišljenje.
Dokumentiraj odluke u trenutku donošenja. Zapiši: što si znao, što si pretpostavio, koje alternative si razmatrao, zašto si odabrao ovaj put. Ovo sprečava hindsight bias i omogućuje učenje iz prošlih odluka.
Koristi "pre-mortem" tehniku. Prije početka projekta, zamisli da je prošlo 6 mjeseci i projekt je propao. Svaki član tima piše razloge zašto. Ovo aktivira inversion thinking i otkriva pristranosti koje grupno mišljenje sakriva.
Postavljaj "anti-confirmation" pitanja. Umjesto "Zašto je ovo dobra ideja?", pitaj "Pod kojim uvjetima bi ovo bila loša ideja?" Ovo forsira mozak da traži kontra-dokaze umjesto potvrda.
Odvoji emocije od podataka. Kad osjećaš jak otpor prema nekoj informaciji ili ideji, to je signal da je pristranost na djelu. Zaustavi se i pitaj: "Reagujem li na podatke ili na osjećaj?"
Razdvoji generiranje opcija od evaluacije. Prvo generiraj što više opcija bez prosudbe (brainstorming). Tek onda evaluiraj svaku prema jasnim kriterijima. Miješanje ova dva koraka aktivira anchoring, status quo i authority bias.
Koristi "10/10/10" test. Kako ću se osjećati oko ove odluke za 10 minuta? 10 mjeseci? 10 godina? Ovo pomaže prebroditi recency bias i loss aversion tako da staviš odluku u dugoročnu perspektivu.
Traži perspektivu izvana. Netko tko nije emocionalno vezan za tvoj proizvod, kod ili proces može vidjeti pristranosti koje ti ne možeš. Redovito traži feedback od ljudi izvan tima, posebno za strateške odluke.
Prati vlastite pristranosti. Vodi "bias journal" — kad prepoznaš da te je pristranost zavela (retrospektivno), zapiši: koja pristranost, u kojoj situaciji, kako je utjecala na odluku. S vremenom ćeš prepoznavati obrasce i postajati otporniji.
Ne pokušavaj eliminirati pristranosti — upravljaj njima. Kognitivne pristranosti su evolucijski ugrađene u naš mozak. Ne možeš ih isključiti. Ali možeš stvoriti sustave, procese i navike koji smanjuju njihov utjecaj na važne odluke.