This content is also available in English
La verità scomoda che nessuno vuole ammettere nel mondo del software
Quando un cliente ci chiede di quotare lo sviluppo di un componente software custom, spesso ci troviamo di fronte a una delle domande più complesse dell’intero settore tecnologico. Non si tratta semplicemente di calcolare ore di lavoro per una tariffa oraria: stiamo parlando di stimare l’ignoto, di prevedere l’imprevedibile, di dare un prezzo a qualcosa che, per sua natura, è unico e irripetibile.
La realtà è che fare preventivi corretti nel software custom è praticamente impossibile, e i costi di un progetto si conoscono davvero solo quando è finito. Questa non è una confessione di incompetenza, ma il riconoscimento di una verità fondamentale che caratterizza l’industria del software: stiamo creando qualcosa che non è mai esistito prima, utilizzando tecnologie in continua evoluzione, per risolvere problemi che spesso si rivelano più complessi di quanto inizialmente immaginato.
Le statistiche parlano chiaro: secondo recenti studi del settore, il 70% dei progetti software supera il budget iniziale, con un overrun medio del 27% [1]. Ma questi numeri raccontano solo una parte della storia. Quando analizziamo più in profondità, scopriamo che i progetti IT in media sforano il budget del 45% mentre consegnano il 56% in meno del valore previsto [2]. È un paradosso che dovrebbe far riflettere chiunque si occupi di sviluppo software: spendiamo di più per ottenere di meno.
Il dilemma dei progetti piccoli: quando l’errore diventa proporzionalmente devastante
Contrariamente a quello che si potrebbe pensare, fare un preventivo accurato è molto più difficile nei progetti piccoli. I margini di errore sono proporzionalmente molto maggiori: sbagliare del doppio o del triplo su un’attività di una giornata è facile e devastante, mentre sui progetti da 20 o 50 giornate di lavoro c’è ampio margine per recuperare e correggere gli errori o gli imprevisti.
Prendiamo l’esempio di un semplice plugin custom per import/export di dati. In superficie, sembra un’attività straightforward: leggere dati da una fonte, trasformarli e scriverli in un’altra destinazione. Ma la realtà nasconde numerose incognite che emergono solo durante lo sviluppo. Il formato dei dati di origine è davvero quello documentato? Ci sono edge cases non previsti? Il sistema di destinazione ha limitazioni non documentate? Ogni risposta negativa a queste domande può moltiplicare il tempo necessario.
Questo fenomeno è amplificato dal fatto che le attività piccole coinvolgono comunque diverse interazioni tra persone diverse e controlli esterni. Il tempo impiegato è sempre maggiore di quello previsto, e le numerose interazioni costano tempo degli sviluppatori. In un progetto grande, questi costi vengono meglio diluiti; in uno piccolo, diventano proporzionalmente enormi.
L’anatomia dell’incertezza: perché il software custom sfugge alle previsioni
Il software custom, per definizione, è qualcosa che non esiste ancora. Non stiamo assemblando componenti standardizzati secondo un manuale di istruzioni; stiamo creando soluzioni uniche per problemi specifici. Questa unicità porta con sé un livello di incertezza che è impossibile eliminare completamente, indipendentemente da quanto dettagliata sia l’analisi preliminare.
Le fonti di incertezza sono molteplici e interconnesse. I changing requirements possono aumentare i costi del progetto fino al 50% [3], mentre la underestimated complexity contribuisce al 43% degli overrun nei progetti software [4]. Ma c’è di più: il concetto di technical debt introduce un ulteriore livello di complessità. Per ogni dollaro speso nello sviluppo di nuovo software, si accumulano in media $0.41 aggiuntivi in debito tecnico [5], costi che spesso emergono solo nelle fasi successive del progetto.
La scope creep rappresenta forse la sfida più insidiosa. Quello che inizia come una richiesta apparentemente semplice – “aggiungiamo solo un piccolo report” – può trasformarsi in una riscrittura sostanziale della logica di business. Il 57% dei progetti fallisce a causa della mancanza di comunicazione [6], spesso perché le aspettative non sono state allineate fin dall’inizio.
La differenza fondamentale: sviluppo a corpo vs assistenza tecnica
Per affrontare questa complessità intrinseca, in F.technology abbiamo sviluppato un approccio che distingue chiaramente tra due tipologie di attività: lo sviluppo software a corpo e l’assistenza tecnica oraria. Questa distinzione non è solo una questione di pricing, ma riflette due filosofie completamente diverse nell’approccio ai progetti software.
Sviluppo Software Custom: l’impegno verso l’eccellenza
Quando parliamo di sviluppo software custom, ci riferiamo ad attività che richiedono un’analisi preliminare approfondita delle specifiche del cliente, una documentazione dettagliata del processo, interventi sulla logica e struttura del software, e un processo di sviluppo “sicuro” con procedure rigorose di test e deploy.
Questo approccio coinvolge necessariamente un doppio ambiente (test/produzione) e controlli di almeno due diversi programmatori. Le attività di sviluppo sono normalmente più lente e richiedono una pianificazione nel calendario del team di sviluppo. Implicano sempre un doppio passaggio: prima dall’ambiente di test (stage/quality) con verifica del cliente finale, poi il deploy su ambiente di produzione.
Il nostro sistema di Sprint Points (SP) è stato progettato specificamente per gestire questa complessità. Come abbiamo spiegato nel nostro articolo dedicato [7], gli SP rappresentano più di una semplice metrica: sono un impegno per la qualità e la precisione. Ogni SP riflette il tempo e lo sforzo necessari per completare una specifica funzionalità, considerando non solo la codifica, ma anche l’analisi, la documentazione, i test e la garanzia di qualità.
Le attività di sviluppo sono quotate a funzione richiesta (Task#) a seguito di un’analisi preliminare e godono di garanzia per 90 giorni dalla data di rilascio. Questa garanzia non è solo un gesto commerciale, ma il riflesso della nostra fiducia nel processo di sviluppo strutturato che seguiamo.
Assistenza Tecnica: flessibilità e reattività
L’assistenza tecnica, d’altra parte, rappresenta un modello completamente diverso. Si tratta di attività di tipo “orario” che si eseguono in presenza di un pacchetto software prepagato. Queste attività si quotano rispetto al tempo effettivamente impiegato e documentato, e non sono soggette a preventivazione ma solo a stima di massima.
L’assistenza tecnica è progettata per essere più veloce nell’intervento e nella soluzione dei problemi. È il modello ideale per piccole modifiche, correzioni urgenti, o quando il scope del lavoro è troppo incerto per giustificare un’analisi approfondita. Tuttavia, questa velocità ha un prezzo: le attività di assistenza tecnica non godono di supporto extra in garanzia, e ogni intervento successivo viene conteggiato a tariffa oraria.
Il paradosso del controllo: perché pagare a ore e chiedere un preventivo fisso è un controsenso
Uno degli errori più comuni che vediamo nel mercato è la richiesta di pagare una tariffa oraria e contemporaneamente ottenere un preventivo di spesa a corpo. Questo approccio è non solo un controsenso logico, ma comporta anche grossi rischi sulla qualità del lavoro svolto.
Quando un programmatore è vincolato a stare dentro un budget che gli è stato chiesto di valutare, spesso con pochissimi elementi per poterlo prevedere, si crea una pressione che inevitabilmente impatta sulla qualità. Il developer si trova costretto a prendere scorciatoie, a evitare refactoring necessari, a rimandare la documentazione, pur di rispettare un budget che potrebbe essere stato sottostimato fin dall’inizio.
Questo fenomeno è particolarmente evidente nei progetti piccoli, dove la pressione del budget fisso può portare a soluzioni tecnicamente fragili. Il technical debt che si accumula in questi casi può consumare più del 20% della capacità del team di sviluppo [8], creando costi nascosti che emergeranno inevitabilmente in futuro.
La trasparenza come vantaggio competitivo
Molti fornitori di software preferiscono non esporre questi problemi, omettendo semplicemente di discutere le complessità intrinseche dello sviluppo software. Questo approccio può sembrare più “commerciale” nel breve termine, ma lascia i clienti impreparati ad affrontare le inevitabili sfide che emergeranno durante il progetto.
La nostra filosofia è diversa: crediamo che la trasparenza sia un vantaggio competitivo. Quando spieghiamo a un cliente perché un semplice plugin può costare tra i 3K e gli 8.5K euro, non stiamo cercando di giustificare un prezzo alto, ma di educare il cliente sulla reale complessità del lavoro che andremo a svolgere.
Questa trasparenza si estende anche al nostro processo di preventivazione. Quando dedichiamo 10 ore di lavoro e coinvolgiamo 3 persone solo per fare un preventivo, non stiamo sprecando tempo: stiamo investendo nell’analisi approfondita che ci permetterà di identificare le potenziali insidie prima che diventino problemi costosi durante lo sviluppo.
L’importanza dell’Application Maintenance: proteggere l’investimento nel tempo
Un aspetto spesso trascurato nella discussione sui costi del software è la manutenzione a lungo termine. I costi di manutenzione e aggiornamento possono rappresentare oltre il 60% del costo totale del software durante il suo ciclo di vita [9]. Non budgetare adeguatamente per la manutenzione continua può portare a spese impreviste sostanziali.
Il nostro approccio ai contratti di Application Maintenance (AM) [10] nasce proprio da questa consapevolezza. Un software custom, se non supportato adeguatamente, rischia di diventare rapidamente obsoleto o vulnerabile a problemi tecnici. Il mercato del software è estremamente fluido: i tool evolvono, i professionisti si muovono, e le tecnologie si aggiornano rapidamente.
Linguaggi di programmazione, framework e tool di sviluppo possono cambiare nel tempo, diventando obsoleti o meno supportati dal mercato. Anche le competenze tecniche all’interno di una software house possono variare: professionisti che cambiano azienda, aggiornamenti delle conoscenze tecniche o l’introduzione di nuove tecnologie possono impattare sulla continuità operativa.
Un contratto AM garantisce al cliente la sicurezza di avere sempre un team preparato e disponibile sulle tecnologie impiegate nel proprio software, assicurando interventi tempestivi e mirati per tutta la durata del prodotto.
Il sistema tariffario Sprint Points: trasparenza e scalabilità
Il nostro sistema tariffario basato su Sprint Points è stato progettato per offrire trasparenza e incentivare progetti di dimensioni adeguate. La struttura a scaglioni riflette le economie di scala che si ottengono nei progetti più grandi:
- 1-3 SP: 800€ per SP
- 4-9 SP: 625€ per SP
- 10-29 SP: 500€ per SP
- 30+ SP: 400€ per SP
Questa struttura non è arbitraria, ma riflette i costi reali di gestione dei progetti. I progetti più piccoli hanno costi fissi proporzionalmente più alti: setup dell’ambiente di sviluppo, analisi iniziale, documentazione, e overhead di gestione. Nei progetti più grandi, questi costi si diluiscono, permettendo tariffe più competitive.
Inoltre, i clienti con contratti AM attivi possono beneficiare delle tariffe più vantaggiose anche per acquisti più piccoli, riconoscendo il valore della partnership a lungo termine.
Quando scegliere sviluppo a corpo vs assistenza tecnica
La scelta tra sviluppo a corpo e assistenza tecnica non dovrebbe essere basata solo sul costo, ma sulla natura del lavoro da svolgere e sugli obiettivi del cliente.
Scegli lo sviluppo a corpo quando:
- Il lavoro richiede più di 8 ore di sviluppo
- Hai bisogno di garanzia sui risultati
- Il progetto coinvolge modifiche alla logica di business
- Vuoi documentazione completa del lavoro svolto
- La qualità è prioritaria rispetto alla velocità
Scegli l’assistenza tecnica quando:
- Hai bisogno di interventi rapidi e puntuali
- Il scope del lavoro è molto limitato (meno di 4 ore)
- Stai facendo troubleshooting o debugging
- La velocità di intervento è prioritaria
- Hai già un pacchetto ore prepagato
L’evoluzione verso la compliance: il caso del Cyber Resilience Act
Un esempio perfetto di come l’incertezza sia intrinseca nel software custom è rappresentato dall’introduzione di nuove normative come il Cyber Resilience Act (CRA) [11]. Questa normativa europea, che diventerà operativa entro il 2027, introduce nuovi requisiti di sicurezza per tutti i prodotti software venduti nell’UE.
Per i nostri clienti, questo significa che software sviluppato oggi dovrà essere aggiornato per rispettare nuovi standard di sicurezza. Chi avrebbe potuto prevedere questi costi tre anni fa? Eppure, sono diventati una realtà che impatta su tutti i progetti software custom.
Questo è un esempio perfetto di perché i contratti AM sono essenziali: non solo per la manutenzione ordinaria, ma per adattarsi a un panorama normativo e tecnologico in continua evoluzione.
Conclusioni: abbracciare l’incertezza come opportunità
La verità è che l’incertezza nel software custom non è un bug, è una feature. È il prezzo che paghiamo per l’innovazione, per la possibilità di creare soluzioni uniche che risolvono problemi specifici in modi che nessuno ha mai tentato prima.
Il nostro approccio in F.technology non è quello di eliminare questa incertezza – sarebbe impossibile – ma di gestirla in modo trasparente e professionale. Attraverso la distinzione tra sviluppo a corpo e assistenza tecnica, offriamo ai nostri clienti gli strumenti per scegliere l’approccio più adatto alle loro esigenze specifiche.
Quando scegliete di lavorare con noi, non state solo acquistando ore di sviluppo o funzionalità software. State investendo in un partnership che riconosce la complessità intrinseca del software custom e che ha sviluppato processi, metodologie e strumenti per navigare questa complessità con successo.
La prossima volta che vi trovate di fronte a un preventivo che sembra “troppo alto” per un’attività apparentemente semplice, ricordate che nel software custom, come in pochi altri settori, la semplicità apparente nasconde spesso una complessità profonda. E quella complessità, gestita correttamente, è ciò che trasforma un’idea in una soluzione software robusta, scalabile e di successo.
Riferimenti
This content is also available in English
