[{"data":1,"prerenderedAt":727},["ShallowReactive",2],{"has-blog-posts":3,"post-riscrivere-software-da-zero":4,"related-riscrivere-software-da-zero":228,"datemod-riscrivere-software-da-zero":726},true,{"id":5,"title":6,"body":7,"category":209,"date":210,"description":211,"extension":212,"image":213,"meta":214,"navigation":3,"path":215,"published":3,"seo":216,"seoTitle":217,"slug":218,"stem":219,"tags":220,"updated":226,"__hash__":227},"blog/blog/2026-01-22-riscrivere-software-da-zero.md","Riscrivere un software da zero: quando ha senso e quando no",{"type":8,"value":9,"toc":188},"minimark",[10,17,20,25,28,31,34,37,41,46,49,52,56,59,62,66,75,82,86,89,92,100,104,108,111,114,118,121,124,128,136,140,143,147,150,158,162,165,168,171,175,182,185],[11,12,13],"p",{},[14,15,16],"strong",{},"\"Questo codice è irrecuperabile. Dobbiamo riscrivere tutto da zero.\" Ecco, questa frase costa quanto poche altre nel mondo dello sviluppo software. Ogni volta che la senti, puoi scommettere che la riscrittura è già costata il triplo del previsto, ha preso il doppio del tempo, e alla fine ti ritrovi con gli stessi vecchi compromessi di prima — solo che adesso si chiamano in un altro modo.",[11,18,19],{},"Riscrivere tutto da capo è la tentazione più forte, e anche la più rischiosa, per un team di sviluppo. Chi prende decisioni sul prodotto dovrebbe trattare questa scelta come tratterebbe un investimento da centinaia di migliaia di euro. Perché, alla fine, è esattamente quello.",[21,22,24],"h2",{"id":23},"perché-il-team-vuole-riscrivere","Perché il team vuole riscrivere",[11,26,27],{},"Prima di tutto, questa voglia di cancellare tutto e ripartire non viene dal nulla. Quando il team dice che il codice è un disastro, non sta inventando. Il debito tecnico esiste, le nuove feature richiedono troppo tempo, i bug spuntano come funghi, e la frustrazione di lavorare su quel codice difficile è reale.",[11,29,30],{},"Però c’è un salto logico tra “questo codice è ingestibile” e “dobbiamo buttare via tutto”. Sarebbe come dire: “la casa ha problemi all’impianto idraulico, quindi demoliamola.” A volte serve davvero. Quasi sempre, no.",[11,32,33],{},"Riscrivere da zero è così allettante perché ti fa sognare un foglio bianco. Tutti gli errori del passato spariscono, niente più compromessi, niente più codice incomprensibile. Stavolta faremo tutto bene.",[11,35,36],{},"Peccato che quel “tutto bene” sia solo un’illusione.",[21,38,40],{"id":39},"perché-le-riscritture-vanno-male","Perché le riscritture vanno male",[42,43,45],"h3",{"id":44},"il-vecchio-sistema-sa-più-di-quanto-pensi","Il vecchio sistema sa più di quanto pensi",[11,47,48],{},"Joel Spolsky l’ha detto nel 2000 e non è cambiato nulla: quel codice brutto, pieno di hack e workaround, contiene anni di conoscenza nascosta. Ogni if strano, ogni commento oscuro, ogni pezzo di codice scritto in emergenza rappresenta un problema già scoperto e risolto, una regola di business che nessuno si ricorda più, ma che è fondamentale.",[11,50,51],{},"Riscrivendo da zero butti via tutto questo. E lo riscopri nel modo peggiore: un cliente alla volta che ti segnala un bug che il vecchio sistema, per quanto brutto, gestiva.",[42,53,55],{"id":54},"i-requisiti-non-aspettano","I requisiti non aspettano",[11,57,58],{},"Mentre il team riscrive, il resto dell’azienda non si ferma. I clienti vogliono ancora nuove feature. I competitor lanciano aggiornamenti. Il mercato si muove.",[11,60,61],{},"A quel punto hai due scelte, nessuna delle due bella: o blocchi lo sviluppo del vecchio sistema per concentrarti sulla riscrittura (e il prodotto non evolve per mesi), oppure porti avanti entrambi insieme (il team si divide, le energie si dimezzano, e la riscrittura sembra non finire mai).",[42,63,65],{"id":64},"le-stime-sono-sempre-sbagliate","Le stime sono sempre sbagliate",[11,67,68,69,74],{},"Gli sviluppatori ",[70,71,73],"a",{"href":72},"/blog/stime-sviluppo-sbagliate-perche","sbagliano a stimare quasi per definizione",", ma quando si parla di riscritture è ancora peggio. Il team conta solo le cose visibili: le feature. Peccato che il vero lavoro sia tutto quello che non si vede: gestione degli errori, casi limite, integrazioni, migrazioni dati, performance.",[11,76,77,78,81],{},"La verità? ",[14,79,80],{},"Prendi la stima del team e moltiplica per tre."," Se dicono sei mesi, preparati a diciotto. Non è pessimismo: è la media di come vanno davvero le riscritture che ho visto.",[42,83,85],{"id":84},"i-compromessi-torneranno","I compromessi torneranno",[11,87,88],{},"Ecco la parte più dura da accettare.",[11,90,91],{},"I compromessi nel vecchio codice non ci sono perché chi c’era prima era incapace. Sono nati perché il business aveva limiti reali: scadenze, budget, richieste che cambiavano all’ultimo. Quei limiti sono ancora qui. Anche il nuovo team, sotto pressione, finirà per fare le stesse scelte.",[11,93,94,95,99],{},"Dai due anni, e il codice \"nuovo\" avrà già il suo debito tecnico, i suoi workaround, e qualcuno proporrà: \"Riscriviamo tutto da zero.\" È la stessa dinamica per cui ",[70,96,98],{"href":97},"/blog/costi-manutenzione-software","il software ha costi di manutenzione continui",".",[21,101,103],{"id":102},"cosa-fare-invece-di-riscrivere","Cosa fare invece di riscrivere",[42,105,107],{"id":106},"refactoring-incrementale","Refactoring incrementale",[11,109,110],{},"Non buttare via tutto. Migliora il sistema un pezzo alla volta. Questo è il refactoring incrementale: cambiare e ripulire il codice senza riscrivere l’intero prodotto da capo. Parti dai moduli che causano più problemi, quelli pieni di bug e quelli dove ogni nuova feature è un incubo, e sistemali uno dopo l’altro.",[11,112,113],{},"Il bello di questo approccio? Il prodotto continua a funzionare, il team continua a consegnare, e ogni passo avanti si vede davvero. Non è emozionante come un foglio bianco, ma funziona.",[42,115,117],{"id":116},"strangler-fig-pattern","Strangler fig pattern",[11,119,120],{},"Se davvero c’è una parte che non si salva, estraila. Costruisci il nuovo componente accanto al vecchio, sposta il traffico poco alla volta, e quando il nuovo funziona (con utenti veri, in produzione), spegni il vecchio.",[11,122,123],{},"È la versione più pragmatica della riscrittura: non butti mai tutto insieme, non rischi mai di restare senza sistema funzionante, e puoi fermarti quando vuoi, con qualcosa che già funziona.",[42,125,127],{"id":126},"investi-nel-testing-prima-di-toccare-il-codice","Investi nel testing prima di toccare il codice",[11,129,130,131,135],{},"Se il team ha paura di cambiare perché “potremmo rompere qualcosa”, il primo investimento è una ",[70,132,134],{"href":133},"/blog/test-coverage-cosa-misura","suite di test",", non la riscrittura. Quando i test coprono i flussi critici, il refactoring diventa sicuro. Senza test, sia la riscrittura che il refactoring sono solo una scommessa.",[42,137,139],{"id":138},"scrivi-le-regole-di-business","Scrivi le regole di business",[11,141,142],{},"Il vero problema, spesso, sta nelle regole di business che nessuno sa davvero spiegare, più che nel codice. Prima di pensare a una riscrittura, fermati e documenta tutte le regole di business. Parla con chi usa il prodotto, con chi lo ha progettato, con chi si occupa dei casi limite. Quella documentazione vale più di qualsiasi nuova versione del codice.",[21,144,146],{"id":145},"quando-la-riscrittura-ha-senso-davvero","Quando la riscrittura ha senso davvero",[11,148,149],{},"Ci sono casi in cui riscrivere è una scelta legittima. Se il tuo prodotto gira su una tecnologia abbandonata, che nessuno sa più mantenere e da cui non esiste una migrazione praticabile, la riscrittura può essere l’unica strada. Lo stesso vale quando il dominio è cambiato davvero: magari hai costruito un tool interno che ora deve diventare un SaaS multi-tenant con migliaia di utenti, e l’architettura originaria non regge più. In quel caso non stai inseguendo il refactoring di un difetto, stai affrontando un cambio di natura del prodotto.",[11,151,152,153,157],{},"La riscrittura può anche avere senso se il codebase è ancora piccolo. Un ",[70,154,156],{"href":155},"/blog/cos-e-un-mvp-software","MVP nato in pochi mesi"," si può rifare; cinque anni di lavoro, molto meno. In quasi tutti gli altri casi, però, il refactoring incrementale resta la strada più sensata.",[21,159,161],{"id":160},"le-domande-da-farsi-prima-di-dire-sì-a-una-riscrittura","Le domande da farsi prima di dire sì a una riscrittura",[11,163,164],{},"Se il tuo team propone di buttare tutto e ricominciare, le domande da fare sono molto concrete. Che cosa non funziona esattamente? Se la risposta resta vaga, del tipo “è un casino”, bisogna fermarsi e pretendere un’analisi precisa. Avete già provato a migliorare il codice poco per volta? Se no, vale la pena capire perché.",[11,166,167],{},"Poi c’è il lato economico: quanto ci costa non fare nulla per sei mesi? Quanti bug finiscono in produzione, quanto tempo in più richiede ogni feature, quanti soldi perdiamo? E quali funzionalità smetteremo di sviluppare mentre il team riscrive tutto? Questo è il costo opportunità che quasi nessuno considera.",[11,169,170],{},"Infine c’è la domanda più pratica di tutte: come spostiamo dati e utenti? Se il team non ha un piano preciso, non è pronto a riscrivere.",[21,172,174],{"id":173},"riscrivere-tutto-è-spesso-il-sintomo-di-un-problema-di-processo-non-la-sua-soluzione","Riscrivere tutto è spesso il sintomo di un problema di processo, non la sua soluzione.",[11,176,177,178,181],{},"Lo so, è dura da accettare, ma è la verità. Se il team vuole riscrivere tutto, ",[14,179,180],{},"qualcosa si è rotto nel processo — non solo nel codice."," Manca il refactoring continuo. Mancano standard. Nessuno trova il tempo per la manutenzione. È debito tecnico che si accumula sprint dopo sprint, senza mai pagarlo.",[11,183,184],{},"La riscrittura non aggiusta questo problema. Lo azzera per un po’, tutto qui. Se il processo resta com’era, tra due anni sarai di nuovo nello stesso punto.",[11,186,187],{},"Meglio investire nel processo. Meglio investire in refactoring continuo. Meglio dare al team il tempo per lavorare bene, davvero. Costa meno di una riscrittura, e porta più lontano.",{"title":189,"searchDepth":190,"depth":190,"links":191},"",2,[192,193,200,206,207,208],{"id":23,"depth":190,"text":24},{"id":39,"depth":190,"text":40,"children":194},[195,197,198,199],{"id":44,"depth":196,"text":45},3,{"id":54,"depth":196,"text":55},{"id":64,"depth":196,"text":65},{"id":84,"depth":196,"text":85},{"id":102,"depth":190,"text":103,"children":201},[202,203,204,205],{"id":106,"depth":196,"text":107},{"id":116,"depth":196,"text":117},{"id":126,"depth":196,"text":127},{"id":138,"depth":196,"text":139},{"id":145,"depth":190,"text":146},{"id":160,"depth":190,"text":161},{"id":173,"depth":190,"text":174},"Architettura","2026-01-22","Riscrivere un software da zero costa più del previsto e spesso non risolve il problema reale. Quando conviene davvero, quando no, e le alternative che funzionano (strangler pattern, refactoring incrementale).","md","/images/blog/riscrivere-software-da-zero.jpg",{},"/blog/2026-01-22-riscrivere-software-da-zero",{"title":6,"description":211},"Riscrivere software da zero: rischi, costi e alternative","riscrivere-software-da-zero","blog/2026-01-22-riscrivere-software-da-zero",[221,222,223,224,225],"riscrivere-software","refactoring","debito-tecnico","modernizzazione","scelta-tecnica",null,"YH7WnS8KEx1p1cOymUvdU_p35mcpCJLl1XacAZPNOYI",[229,421,581],{"id":230,"title":231,"body":232,"category":209,"date":405,"description":406,"extension":212,"image":407,"meta":408,"navigation":3,"path":409,"published":3,"seo":410,"seoTitle":411,"slug":412,"stem":413,"tags":414,"updated":226,"__hash__":420},"blog/blog/2026-04-16-quanto-costa-un-software-custom.md","Quanto costa un software custom? Differenze tra 5K, 18K e 50K",{"type":8,"value":233,"toc":385},[234,240,243,255,259,262,266,269,273,276,279,283,286,289,292,295,303,306,310,313,316,322,326,329,333,337,340,344,347,351,354,358,365,369,372,375,378,382],[11,235,236,239],{},[14,237,238],{},"Tre preventivi per lo stesso software: 5.000 euro, 18.000 euro, 50.000 euro."," Stessa richiesta, stesso risultato apparente: un gestionale per i tuoi ordini. Il costo dello sviluppo software varia così tanto perché qualità e approccio dietro ogni preventivo sono profondamente diversi. In pratica stai guardando tre soluzioni completamente differenti.",[11,241,242],{},"Nel software, due prodotti che “fanno la stessa cosa” in superficie possono essere costruiti in modi radicalmente differenti. E ognuno di questi modi ha senso in un contesto specifico.",[11,244,245,246,249,250,254],{},"La vera questione è capire ",[14,247,248],{},"cosa stai comprando davvero",". E come ho scritto parlando di ",[70,251,253],{"href":252},"/blog/preventivo-software-partire-dal-budget","preventivo software e budget",", partire dal vincolo economico rende la conversazione molto più utile.",[21,256,258],{"id":257},"cosa-compri-con-un-preventivo-da-5000-euro","Cosa compri con un preventivo da 5.000 euro",[11,260,261],{},"In genere compri una soluzione basata su strumenti già esistenti: un CMS configurato, un pannello CRUD predefinito, cioè un’interfaccia standard per creare, leggere, modificare e cancellare dati, una piattaforma low-code adattata alle tue esigenze. Il lavoro principale è di configurazione e integrazione.",[42,263,265],{"id":264},"vantaggi","Vantaggi",[11,267,268],{},"I vantaggi sono evidenti: in poche settimane puoi essere operativo, il costo resta contenuto, le funzionalità standard sono già collaudate e il rischio tecnico è basso perché la base è ampiamente testata.",[42,270,272],{"id":271},"limiti","Limiti",[11,274,275],{},"Il rovescio della medaglia è che sei tu ad adattarti al software, le personalizzazioni restano limitate alla struttura prevista dallo strumento e, se in futuro emergono esigenze fuori dallo standard, potresti dover cambiare soluzione.",[11,277,278],{},"Per molte attività che hanno processi simili a quelli della maggior parte delle aziende, questa è una scelta razionale ed efficace. Spendere di più, in questi casi, non porta un reale vantaggio.",[21,280,282],{"id":281},"cosa-compri-con-un-preventivo-da-50000-euro","Cosa compri con un preventivo da 50.000 euro",[11,284,285],{},"Qui non stai comprando una configurazione, ma un progetto su misura. Prima viene analizzato il tuo modo di lavorare, poi viene progettata una struttura software adatta a quel contesto, e infine viene sviluppato codice specifico per te.",[42,287,265],{"id":288},"vantaggi-1",[11,290,291],{},"In questo caso il software riflette i tuoi processi e le tue regole, mantiene una flessibilità molto più alta nel tempo, nasce con un’architettura pensata per crescere insieme al business e ti lascia proprietà e controllo completi sul sistema.",[42,293,272],{"id":294},"limiti-1",[11,296,297,298,302],{},"Naturalmente aumentano costi e tempi, cresce la dipendenza dalla qualità del fornitore e, se ",[70,299,301],{"href":300},"/blog/agenzia-abbandona-progetto-software","il fornitore si sfila a metà progetto",", il rischio diventa alto. Inoltre serve una fase di analisi molto più approfondita.",[11,304,305],{},"Questa scelta ha senso quando il modo in cui lavori è parte del tuo vantaggio competitivo, oppure quando prevedi che il tuo business cambierà molto nei prossimi anni.",[21,307,309],{"id":308},"la-fascia-intermedia-18000-euro","La fascia intermedia: 18.000 euro",[11,311,312],{},"Questa soluzione spesso combina una base preesistente con parti sviluppate su misura. Funziona bene quando gran parte delle tue esigenze rientra nello standard, le personalizzazioni sono limitate e ben isolate e il fornitore sa distinguere chiaramente cosa resta standard e cosa diventa custom.",[11,314,315],{},"Diventa problematica quando si forza uno strumento standard a fare cose per cui non è stato progettato. In questi casi, il risultato è un sistema difficile da mantenere e da evolvere.",[11,317,318,319],{},"La domanda chiave qui è: ",[14,320,321],{},"quanto del tuo processo rientra davvero nello standard?",[21,323,325],{"id":324},"perché-i-numeri-sono-così-diversi","Perché i numeri sono così diversi",[11,327,328],{},"I preventivi non stanno valutando la stessa cosa. Quello basso misura soprattutto la capacità di configurare strumenti esistenti, quello alto valuta la capacità di progettare e costruire una soluzione su misura, quello intermedio cerca un equilibrio tra le due cose. Nessuno ti sta ingannando: la differenza sta nell’approccio di ogni fornitore.",[21,330,332],{"id":331},"le-domande-da-farsi-prima-di-scegliere","Le domande da farsi prima di scegliere",[42,334,336],{"id":335},"il-tuo-processo-è-standard-o-specifico","Il tuo processo è standard o specifico?",[11,338,339],{},"Se lavori come la maggior parte delle aziende del tuo settore, una soluzione standard è spesso sufficiente. Se il tuo modo di lavorare è particolare e distintivo, questo dovrà emergere nel software.",[42,341,343],{"id":342},"quanto-cambierà-il-tuo-business-nei-prossimi-due-anni","Quanto cambierà il tuo business nei prossimi due anni?",[11,345,346],{},"Se prevedi cambiamenti frequenti, la flessibilità diventa un fattore importante. Se il tuo modello è stabile, puoi privilegiare rapidità e costo.",[42,348,350],{"id":349},"quanto-valore-genera-questo-software","Quanto valore genera questo software?",[11,352,353],{},"Se il software serve solo a semplificare un’attività amministrativa marginale, una soluzione economica ha senso. Se il software è il cuore del tuo prodotto o dei tuoi ricavi, l’investimento deve essere proporzionato.",[42,355,357],{"id":356},"quanto-ti-costerà-cambiare-soluzione-in-futuro","Quanto ti costerà cambiare soluzione in futuro?",[11,359,360,361,364],{},"Una soluzione economica che dopo un anno non è più adeguata può diventare più costosa di un investimento iniziale maggiore ma più duraturo. È il motivo per cui ",[70,362,363],{"href":97},"i costi di manutenzione software"," pesano spesso più del costo iniziale.",[21,366,368],{"id":367},"lerrore-più-comune","L’errore più comune",[11,370,371],{},"L’errore più comune è scegliere un preventivo con aspettative che non corrispondono a quello che offre.",[11,373,374],{},"Una soluzione economica può essere perfetta se sai che stai comprando velocità e standardizzazione. Una soluzione costosa può essere un ottimo investimento se sai che stai comprando flessibilità e adattabilità.",[11,376,377],{},"Il problema nasce quando si acquista una soluzione aspettandosi caratteristiche che non può avere.",[21,379,381],{"id":380},"in-sintesi","In sintesi",[11,383,384],{},"Preventivi molto diversi per lo stesso software indicano che stai valutando approcci diversi alla soluzione del problema. Capire quale approccio ha senso per il tuo caso conta molto più del semplice confronto tra i numeri.",{"title":189,"searchDepth":190,"depth":190,"links":386},[387,391,395,396,397,403,404],{"id":257,"depth":190,"text":258,"children":388},[389,390],{"id":264,"depth":196,"text":265},{"id":271,"depth":196,"text":272},{"id":281,"depth":190,"text":282,"children":392},[393,394],{"id":288,"depth":196,"text":265},{"id":294,"depth":196,"text":272},{"id":308,"depth":190,"text":309},{"id":324,"depth":190,"text":325},{"id":331,"depth":190,"text":332,"children":398},[399,400,401,402],{"id":335,"depth":196,"text":336},{"id":342,"depth":196,"text":343},{"id":349,"depth":196,"text":350},{"id":356,"depth":196,"text":357},{"id":367,"depth":190,"text":368},{"id":380,"depth":190,"text":381},"2026-04-16","Tre preventivi da 5.000 a 50.000 euro per lo stesso software indicano approcci molto diversi. Come capire cosa compri davvero e quale ha senso per il tuo caso.","/images/blog/quanto-costa-un-software-custom.jpg",{},"/blog/2026-04-16-quanto-costa-un-software-custom",{"title":231,"description":406},"Quanto costa un software su misura (preventivi da 5K a 50K)","quanto-costa-un-software-custom","blog/2026-04-16-quanto-costa-un-software-custom",[415,416,417,418,419],"budget","preventivi","software custom","scelta fornitore","costi","ru6eiZdyD7iLoP-cD1vdeUZy1WUohHUalUsXXWEjT2I",{"id":422,"title":423,"body":424,"category":209,"date":565,"description":566,"extension":212,"image":567,"meta":568,"navigation":3,"path":569,"published":3,"seo":570,"seoTitle":571,"slug":572,"stem":573,"tags":574,"updated":226,"__hash__":580},"blog/blog/2026-04-14-digitalizzare-processi-aziendali.md","Digitalizzare i processi aziendali: prima fai ordine, poi il software",{"type":8,"value":425,"toc":552},[426,432,435,438,442,448,451,454,458,462,465,468,472,475,478,482,485,489,496,503,507,514,517,521,524,531,534,538,541,543,546,549],[11,427,428,431],{},[14,429,430],{},"Un cliente aveva centinaia di clienti, ognuno con logiche di prezzo diverse: a peso, a pezzo, con forfait, con sconti storici, con accordi presi a voce negli anni."," Voleva un software che \"automatizzasse tutto\". La digitalizzazione dei processi aziendali senza prima fare ordine produce esattamente questo: un sistema pieno di eccezioni, con decine di logiche di calcolo diverse, che nessuno riesce davvero a spiegare.",[11,433,434],{},"Quel software non era scritto male. Era la trasposizione fedele di un business senza regole chiare.",[11,436,437],{},"Ed è qui il punto: il software codifica quello che già esiste. Se a monte manca ordine, a valle troverai solo una versione più rigida della stessa confusione.",[21,439,441],{"id":440},"il-software-è-uno-specchio","Il software è uno specchio",[11,443,444,445],{},"C’è una verità poco comoda: ",[14,446,447],{},"il software amplifica i problemi organizzativi, rendendoli più evidenti e più rigidi.",[11,449,450],{},"Se il tuo processo è chiaro ma manuale, il software lo velocizza. Se il tuo processo è lento ma ben definito, il software lo automatizza. Se invece il tuo processo è fatto di eccezioni, decisioni caso per caso e regole implicite, il software trasformerà tutto questo in una rete di condizioni difficili da capire e ancora più difficili da modificare.",[11,452,453],{},"Il codice ha bisogno di regole esplicite. Se tu non riesci a spiegare come funziona il tuo processo senza dire “dipende” ogni due frasi, chi sviluppa dovrà tradurre ogni “dipende” in una condizione diversa. E il risultato sarà un sistema che riflette esattamente quella confusione.",[21,455,457],{"id":456},"segnali-che-il-problema-sta-a-monte-del-software","Segnali che il problema sta a monte del software",[42,459,461],{"id":460},"ci-servono-molte-eccezioni","“Ci servono molte eccezioni”",[11,463,464],{},"Durante l’analisi, se ogni requisito è seguito da “sì, ma in questo caso è diverso”, non sei davanti a un processo: sei davanti a una serie di abitudini stratificate nel tempo.",[11,466,467],{},"Un sistema sano ha poche eccezioni ben definite. Un sistema caotico è composto quasi solo da eccezioni.",[42,469,471],{"id":470},"non-riesco-a-spiegarti-come-funziona","“Non riesco a spiegarti come funziona”",[11,473,474],{},"Prova a scrivere su un foglio le regole del tuo business: come si calcola il prezzo, come si applicano gli sconti, come funziona la fatturazione, come gestisci gli ordini.",[11,476,477],{},"Se non riesci a farlo in modo lineare, probabilmente non stai descrivendo un processo, ma una serie di decisioni prese caso per caso nel tempo.",[42,479,481],{"id":480},"ogni-cliente-è-un-caso-a-sé","“Ogni cliente è un caso a sé”",[11,483,484],{},"C’è una differenza netta tra personalizzazione strutturata e caos. Nel primo caso hai pochi modelli chiari combinabili tra loro; nel secondo ogni cliente ha condizioni uniche, negoziate a voce e mai formalizzate. La prima situazione si può automatizzare. La seconda va prima ricondotta a regole.",[21,486,488],{"id":487},"cosa-succede-quando-digitalizzi-il-caos","Cosa succede quando digitalizzi il caos",[11,490,491,492,99],{},"Nella pratica si vedono sempre gli stessi effetti. Il software diventa difficile da mantenere, perché ogni nuova funzionalità deve tenere conto di tutte le eccezioni precedenti e le modifiche diventano lente, rischiose e costose. Il sistema finisce per diventare ",[70,493,495],{"href":494},"/blog/software-fragile-regressioni","fragile e ogni deploy, cioè ogni rilascio di una nuova versione, diventa fonte di tensione",[11,497,498,499,99],{},"Nel frattempo il team continua a lavorare “a parte”. Le persone evitano il software perché per certi casi è ancora più veloce fare a mano, quindi fogli Excel ed email continuano a vivere in parallelo. E naturalmente i costi crescono più del previsto: il costo del software dipende dalla complessità delle regole, non dalla dimensione dell'azienda. Poche regole chiare portano a un sistema semplice, mentre molte regole implicite portano a un sistema costoso e difficile. Del resto ",[70,500,502],{"href":501},"/blog/semplicita-nel-software","costruire qualcosa di semplice è già di per sé la cosa più difficile",[21,504,506],{"id":505},"prima-organizzi-poi-digitalizzi","Prima organizzi, poi digitalizzi",[11,508,509,510,513],{},"Prima di iniziare un progetto software, spesso conviene fare un lavoro preliminare molto più semplice di quanto sembri: chiarire le regole. È lo stesso principio per cui ",[70,511,512],{"href":72},"le stime di sviluppo sono spesso sbagliate",": senza regole chiare, non si può stimare nulla con precisione.",[11,515,516],{},"La prima domanda utile riguarda il listino. Se la risposta è “dipende dal cliente”, allora la domanda successiva è se possa dipendere da meno fattori: fasce, categorie, criteri ripetibili che coprano la maggior parte dei casi. La seconda riguarda il rapporto tra regole ed eccezioni. Se le eccezioni sono più delle regole, non sei pronto per un software; sei pronto per semplificare il processo. La terza domanda è cosa puoi standardizzare senza perdere valore, perché molte differenze percepite come fondamentali in realtà non lo sono. Il cliente vede il risultato finale, non il metodo interno con cui lo ottieni.",[21,518,520],{"id":519},"il-ruolo-di-chi-progetta-il-software","Il ruolo di chi progetta il software",[11,522,523],{},"Il lavoro più prezioso sta nell'aiutare a riformulare i requisiti prima ancora di tradurli in codice.",[11,525,526,527,530],{},"“Ogni cliente ha il suo prezzo” può diventare “abbiamo un sistema di fasce con alcune deroghe documentate”.",[528,529],"br",{},"\n“Ogni progetto è diverso” può diventare “abbiamo un modello con opzioni configurabili”.",[11,532,533],{},"Questa fase è chiarificazione del modello di business.",[21,535,537],{"id":536},"una-checklist-pratica","Una checklist pratica",[11,539,540],{},"Se riesci a spiegare il tuo processo principale senza usare “dipende” più di una volta, se le eccezioni sono poche e sai elencarle, se le regole che applichi oggi sono scritte da qualche parte, se due persone diverse nella tua azienda descrivono il processo nello stesso modo e se un nuovo collaboratore potrebbe impararlo leggendo quelle regole, allora probabilmente sei pronto a digitalizzare. Se molte di queste risposte sono negative, il lavoro da fare è prima di tutto organizzativo.",[21,542,381],{"id":380},[11,544,545],{},"Il software è un acceleratore. Accelera quello che già esiste.",[11,547,548],{},"Se esiste ordine, accelera l’ordine. Se esiste confusione, accelera la confusione.",[11,550,551],{},"Mettere ordine prima di digitalizzare è il modo più efficace per evitare un software costoso che riflette problemi invece di risolverli.",{"title":189,"searchDepth":190,"depth":190,"links":553},[554,555,560,561,562,563,564],{"id":440,"depth":190,"text":441},{"id":456,"depth":190,"text":457,"children":556},[557,558,559],{"id":460,"depth":196,"text":461},{"id":470,"depth":196,"text":471},{"id":480,"depth":196,"text":481},{"id":487,"depth":190,"text":488},{"id":505,"depth":190,"text":506},{"id":519,"depth":190,"text":520},{"id":536,"depth":190,"text":537},{"id":380,"depth":190,"text":381},"2026-04-14","Il software amplifica quello che già esiste. Se i tuoi processi hanno troppe eccezioni, digitalizzarli li renderà solo più rigidi. Prima le regole, poi il codice.","/images/blog/digitalizzare-processi-aziendali.jpg",{},"/blog/2026-04-14-digitalizzare-processi-aziendali",{"title":423,"description":566},"Digitalizzazione processi aziendali: prima ordine, poi software","digitalizzare-processi-aziendali","blog/2026-04-14-digitalizzare-processi-aziendali",[575,576,577,578,579],"digitalizzazione","processi-aziendali","analisi-requisiti","organizzazione","preparazione-progetto","XYmF3lYSbrYlw4F4rMEBQZ9jol8E24Yg3tiVi6OSO8Y",{"id":582,"title":583,"body":584,"category":209,"date":710,"description":711,"extension":212,"image":712,"meta":713,"navigation":3,"path":714,"published":3,"seo":715,"seoTitle":716,"slug":717,"stem":718,"tags":719,"updated":226,"__hash__":725},"blog/blog/2026-04-09-semplicita-nel-software.md","Semplicità nel software: perché costa più di quanto sembri",{"type":8,"value":585,"toc":699},[586,592,595,599,603,606,613,616,620,623,626,633,637,644,647,650,654,657,660,668,672,675,678,681,684,688,691,693,696],[11,587,588,591],{},[14,589,590],{},"\"Voglio un software semplice. Che basti fare click.\""," È una richiesta legittima, spesso anche la più corretta. Ma la semplicità nel software è un punto di arrivo, mai di partenza. E di solito costa più di quanto chi commissiona si aspetti, perché richiede di prendere molte decisioni al posto dell'utente e gestire in modo invisibile decine di scenari.",[11,593,594],{},"Nel software vale una regola pratica: è facile aggiungere opzioni, campi, passaggi. È più difficile toglierli senza perdere informazioni importanti, senza creare errori e senza aumentare le eccezioni.",[21,596,598],{"id":597},"perché-semplice-è-una-richiesta-costosa","Perché “semplice” è una richiesta costosa",[42,600,602],{"id":601},"dietro-ogni-click-ci-sono-molte-decisioni","Dietro ogni click ci sono molte decisioni",[11,604,605],{},"Quando l’utente preme un bottone e “succede tutto”, la complessità è stata spostata dietro le quinte.",[11,607,608,609,612],{},"Ogni scelta che l’utente ",[14,610,611],{},"non"," fa più (perché non vede un campo, non sceglie un’opzione, non legge un’istruzione) è una scelta che il sistema fa per lui. E per farla bene serve capire contesto, regole, eccezioni, priorità.",[11,614,615],{},"Esempio tipico: “un click per generare la fattura”. Dietro a quel gesto ci sono l’identificazione corretta del cliente e del contesto, i calcoli coerenti con le regole del caso, la numerazione progressiva, la generazione del formato richiesto e l’invio ai sistemi esterni, oltre alla gestione degli esiti e alla comunicazione all’utente. A chi usa il prodotto interessa un click; al team interessa che quel click non produca una fattura sbagliata, un invio fallito o uno stato incoerente. È qui che si annida il costo.",[42,617,619],{"id":618},"togliere-richiede-capire-aggiungere-richiede-soprattutto-implementare","Togliere richiede capire. Aggiungere richiede soprattutto implementare.",[11,621,622],{},"La strada “veloce” verso una prima versione spesso è: mostrare tutto e chiedere tutto all’utente (più campi, più opzioni, più passaggi). Funziona, ma scarica complessità e rischio sull’utilizzatore.",[11,624,625],{},"La strada verso la semplicità, invece, richiede analisi: capire quali informazioni sono davvero necessarie, quali si possono dedurre, quali si possono precompilare, quali si possono rimandare, quali non servono proprio.",[11,627,628,629,632],{},"Questo è il motivo per cui molte richieste di “semplicità” richiedono più iterazioni rispetto a una UI “piena di opzioni”. Perché richiede più decisione che codice. Ed è anche il motivo per cui ",[70,630,631],{"href":72},"le stime di sviluppo sono spesso imprecise",": la complessità sta nelle decisioni, prima che nel codice.",[21,634,636],{"id":635},"il-paradosso-della-semplicità","Il paradosso della semplicità",[11,638,639,640,99],{},"Una UI, cioè l’interfaccia che l’utente vede e usa, complessa è spesso il risultato “naturale” di un progetto: si aggiunge quello che serve, poi un’eccezione, poi un’altra, poi un caso particolare. Alla fine si consegna qualcosa che \"fa tutto\", ma che richiede training e supporto. È la dinamica tipica dello ",[70,641,643],{"href":642},"/blog/scope-creep-progetti-agile","scope creep",[11,645,646],{},"Una UI semplice, al contrario, è il risultato di un lavoro di riduzione: capire cosa è essenziale, togliere il superfluo, automatizzare il resto, e verificare con persone reali che ciò che sembra ovvio lo sia davvero.",[11,648,649],{},"È per questo che “semplice” è un obiettivo di prodotto, non una scorciatoia di sviluppo.",[21,651,653],{"id":652},"semplice-e-subito-raramente-convivono","“Semplice” e “subito” raramente convivono",[11,655,656],{},"Qui nasce la tensione tipica: chi commissiona vuole un’esperienza “a prova di click” e tempi stretti.",[11,658,659],{},"Quando i tempi sono compressi, la probabilità più alta è questa: si consegna una versione che funziona ma è più “carica”, perché non c’è stato spazio per iterare, testare, rivedere e togliere.",[11,661,662,663,667],{},"La soluzione più onesta, di solito, è: partire con poco, farlo funzionare bene, e semplificare in iterazioni successive. È la logica del ",[70,664,666],{"href":665},"/blog/quando-lanciare-un-prodotto","lanciare presto e migliorare",", applicata alla UX: le prime versioni devono essere affidabili, poi diventano davvero semplici.",[21,669,671],{"id":670},"come-si-costruisce-davvero-la-semplicità","Come si costruisce davvero la semplicità",[11,673,674],{},"Molte richieste nascono dal desiderio di “digitalizzare ciò che facciamo oggi”. Ma replicare un processo esistente spesso significa replicarne anche i difetti. La domanda utile è un’altra: qual è il risultato che vogliamo ottenere, e qual è il percorso più diretto per arrivarci?",[11,676,677],{},"In analisi conviene togliere prima di aggiungere. Ogni “e se” introduce complessità, e dopo dieci “e se” il software che doveva essere semplice diventa un gestionale completo. La regola pratica è chiedersi, per ogni feature proposta, se il flusso principale funzionerebbe anche senza. Se la risposta è sì, quella feature può restare fuori dalla versione 1.",[11,679,680],{},"La semplicità poi va provata con utenti reali, presto. Non si decide in riunione. Si verifica sul campo, mettendo anche un prototipo grezzo davanti alle persone che useranno davvero il prodotto. Se la cosa principale si capisce senza spiegazioni, sei sulla strada giusta. Se servono istruzioni o manuali, la complessità è ancora tutta in superficie.",[11,682,683],{},"Infine bisogna accettare che la semplicità è un processo. La versione 1 raramente è davvero semplice; la versione 3 spesso lo è di più, la versione 5 ancora di più. La differenza la fanno le iterazioni guidate da osservazione e feedback, non la quantità di feature inserite fin dall’inizio.",[21,685,687],{"id":686},"euristiche-pratiche-per-chi-commissiona-software","Euristiche pratiche per chi commissiona software",[11,689,690],{},"Quando chiedi un software “semplice”, ci sono alcune domande che aiutano a evitare metà dei fraintendimenti. Bisogna chiarire semplice per chi, perché l’esperienza di un operatore esperto non è quella di un utente occasionale o di un cliente finale. Bisogna capire dove deve essere semplice: nel flusso principale, nelle eccezioni, nella configurazione, nell’onboarding. Vale la pena chiedersi anche cosa può andare storto e come il sistema dovrebbe reagire, che cosa è accettabile rimandare per non appesantire la prima versione e soprattutto qual è il costo dell’errore. Se l’errore costa molto, come succede con fatture, pagamenti o dati delicati, la semplicità richiede più rigore e più test.",[21,692,381],{"id":380},[11,694,695],{},"Un’interfaccia con 30 campi spesso costa meno da costruire nel breve periodo. Un’interfaccia con 3 campi e un bottone spesso costa di più perché richiede analisi, decisioni e gestione invisibile degli edge case. Ma nel medio periodo, la seconda riduce formazione, errori, supporto e frustrazione.",[11,697,698],{},"Se il team è prudente quando sente “semplice”, è consapevolezza del lavoro necessario per farlo bene.",{"title":189,"searchDepth":190,"depth":190,"links":700},[701,705,706,707,708,709],{"id":597,"depth":190,"text":598,"children":702},[703,704],{"id":601,"depth":196,"text":602},{"id":618,"depth":196,"text":619},{"id":635,"depth":190,"text":636},{"id":652,"depth":190,"text":653},{"id":670,"depth":190,"text":671},{"id":686,"depth":190,"text":687},{"id":380,"depth":190,"text":381},"2026-04-09","La semplicità nel software è il punto di arrivo, non di partenza. Un prodotto dove basta un click richiede analisi, decisioni e gestione degli scenari.","/images/blog/semplicita-nel-software.jpg",{},"/blog/2026-04-09-semplicita-nel-software",{"title":583,"description":711},"Semplicità nel software: perché costa più di quanto pensi","semplicita-nel-software","blog/2026-04-09-semplicita-nel-software",[720,721,722,723,724],"prodotto","user-experience","analisi","strategia","sviluppo-software","eKjezR-10nziaTmheUGUAF0h9BJDF4LQ-IY3GWFP5_c","2026-03-12",1776715330093]