Cos'è l'effetto IKEA?
Sopravvalutare ciò che si è costruito con le proprie mani, anche quando vale oggettivamente meno di quanto sembri.
L'effetto IKEA è la tendenza ad attribuire a qualcosa che si è costruito con le proprie mani più valore di quanto ne abbia oggettivamente, anche quando il risultato è mediocre e anche quando chi lo valuta si aspetta che altri condividano quel giudizio. Prende il nome dai mobili IKEA, ma la fatica non deve essere manuale: vale per un foglio di calcolo messo insieme in casa, un'integrazione scritta un weekend, una piattaforma interna nata per colmare un buco del gestionale. La sopravvalutazione compare solo se il lavoro arriva a un risultato completo: se il compito resta a metà, o se chi l'ha costruito lo smonta, l'effetto sparisce. A generare affetto è il senso di aver portato a termine qualcosa da sé, ed è quel senso di paternità a rendere difficile giudicare con distacco ciò che si è costruito, indipendentemente da quanto davvero funzioni.
Leggi anche: Fallacia dei costi sommersi · La fallacia dei costi sommersi è l'errore di finanziare un progetto per quanto già speso e non recuperabile, invece che per il risultato che può ancora dare.
Perché il lavoro genera affetto
Il termine nasce dallo studio di Michael I. Norton, Daniel Mochon e Dan Ariely, "The IKEA effect: when labor leads to love", pubblicato nel 2012 sul Journal of Consumer Psychology (vol. 22, n. 3). Negli esperimenti i partecipanti che assemblavano da soli scatole IKEA, origami o costruzioni Lego valutavano il proprio manufatto quanto quello di un artigiano esperto, e si aspettavano che anche un estraneo lo giudicasse allo stesso modo: chi piegava origami per la prima volta attribuiva alla propria creazione lo stesso prezzo che un compratore avrebbe pagato per una realizzata da un professionista. L'effetto però non compariva quando il compito restava incompiuto o quando chi l'aveva costruita la smontava: non basta aver lavorato, serve averlo portato a termine. È un meccanismo diverso dalla fallacia dei costi sommersi: lì il bias tiene in vita un progetto per la spesa già fatta, qui gonfia il valore di ciò che è già stato consegnato, indipendentemente da quanto sia costato. Parente stretto, ma diverso, è la sindrome del "non inventato qui": lì si scarta una soluzione esterna perché non è stata costruita in casa, qui si sopravvaluta ciò che si è già costruito.
Un esempio enterprise
Il caso enterprise è il tool interno che nessuno vuole spegnere. Un team dati costruisce in tre settimane un cruscotto proprietario per monitorare le pipeline invece di adottare una piattaforma di osservabilità già matura, e un anno dopo lo difende in ogni revisione del budget anche quando copre metà dei casi d'uso e accumula debito tecnico che nessuno fuori dal team che l'ha scritto sa gestire. Il vibe coding e gli agenti di sviluppo abbassano il costo di costruire in proprio quasi a zero, e questo non riduce l'effetto: lo sposta più a monte, sulla decisione di costruire piuttosto che comprare.
Perché conta per chi decide
Chi ha costruito uno strumento interno non è la persona più adatta a valutarne l'adozione, perché il suo giudizio parte già alterato dalla paternità. Il correttivo pratico ha due mosse, entrambe economiche: far valutare la soluzione fatta in casa da chi non ha contribuito a scriverla, e fissare i criteri di scelta (costo di manutenzione, copertura dei casi d'uso, tempo di onboarding di un nuovo membro del team) prima che il prototipo esista, non dopo averlo visto funzionare, con lo stesso rigore di un business case rifatto da zero. Chi decide su un build-vs-buy dovrebbe inoltre chiedersi se difenderebbe la stessa soluzione se l'avesse scritta un fornitore esterno: se la risposta cambia, il valore che si sta difendendo è quello del lavoro fatto, non quello del risultato ottenuto.
Termini correlati
- Fallacia dei costi sommersi · La fallacia dei costi sommersi è l'errore di finanziare un progetto per quanto già speso e non recuperabile, invece che per il risultato che può ancora dare.
- Vibe coding · Sviluppare software descrivendo all'AI cosa si vuole e accettando il codice senza leggerlo davvero. Veloce per i prototipi, rischioso in produzione.
- Debito tecnico · La metafora di Ward Cunningham: ogni scorciatoia nel codice è un prestito, e gli interessi si pagano a ogni modifica successiva.
- Business case e ROI dell'AI · Il metodo per stimare il ritorno di un progetto AI con tre scenari espliciti, contando i costi che di solito restano fuori.
- Bias cognitivo · Una deviazione sistematica del giudizio rispetto alla logica o alla probabilità, prevedibile e ripetibile.
Se è una scelta tecnica che stai rimandando, è la decisione che ti aiuto a prendere.
VEDI TOOL CUSTOM E GOVERNANCE