Evitate sforamenti superiori al 50%: RFP per lo sviluppo software pronta per gli acquisti

Una RFP per lo sviluppo software ottiene la proposta migliore di un fornitore quando indica il risultato aziendale che si vuole raggiungere, un intervallo di budget realistico e un piano di consegna articolato per fasi, incentrato innanzitutto su un MVP. Dovrebbe richiedere per iscritto l’approccio tecnico, le qualifiche del team, le tappe di consegna e gli impegni in materia di sicurezza di ciascun fornitore. Valuta le risposte con una griglia ponderata che attribuisca più peso all’idoneità tecnica e alla sicurezza rispetto all’offerta più bassa, seguendo le indicazioni degli esperti sui criteri di selezione dei fornitori di software.

Punti chiave

Un RFP per lo sviluppo software ben strutturato indica chiaramente i risultati aziendali, l’ambito e i requisiti, così da attirare proposte dettagliate e realistiche, in linea con gli obiettivi del progetto e gli standard di sicurezza.

Indice

• Cosa includere in una RFP per lo sviluppo software
• Una struttura e un modello pratici di RFP da inviare oggi
• Come valutare le proposte senza andare a intuito
• Includere i requisiti di sicurezza e della catena di fornitura
• Tempistiche, aspettative sui costi ed errori da evitare
• Considerazioni legali e contrattuali
• Come può aiutare Ridiculous Engineering
• Fonti
• Domande frequenti

Cosa includere in una RFP per lo sviluppo software

Una descrizione chiara del problema è la spina dorsale del documento. Indica il risultato aziendale che vuoi ottenere e collegalo a una metrica di successo misurabile, che si tratti di ridurre il tempo di elaborazione manuale, diminuire le richieste al supporto o raggiungere un determinato tasso di conversione. I fornitori elaborano proposte più precise quando sanno che cosa significa «completato» in termini aziendali, non soltanto in termini di funzionalità.

Segue l’ambito, e l’ambiguità in questa sezione causa più controversie sul budget di qualsiasi altro elemento del documento. Indica chiaramente ciò che rientra nell’ambito, ciò che ne è esplicitamente escluso e le ipotesi relative a dati, integrazioni e sistemi esistenti. Abbina a ogni funzionalità principale criteri di accettazione, così nessuno potrà discutere su che cosa significhi «finito» sei mesi dopo.

I requisiti funzionali risultano più chiari se formulati come brevi storie utente anziché come elenchi densi di funzionalità. Ecco alcuni esempi:

• In qualità di responsabile operativo, posso visualizzare i livelli di inventario in tempo reale in tutte le sedi dei magazzini.
• In qualità di cliente, posso reimpostare la mia password senza contattare il supporto.
• In qualità di amministratore, posso esportare report sull’utilizzo filtrati per intervallo di date e reparto.

I requisiti non funzionali meritano lo stesso livello di specificità. Un linguaggio vago come “il sistema dovrebbe essere veloce” non offre ai fornitori alcun parametro su cui formulare un’offerta. Questi numeri diventeranno in seguito i vostri test di accettazione, quindi è importante definirli correttamente fin da ora.

Infine, il livello contrattuale è importante quanto quello tecnico. Occorre disciplinare la titolarità della proprietà intellettuale (volete il codice, non una licenza per utilizzarlo), le finestre di assistenza, gli accordi sui livelli di servizio, le tempistiche per la risoluzione dei difetti e un processo definito di controllo delle modifiche per gli adeguamenti dell’ambito in corso d’opera. Saltare questa sezione è il modo in cui le “correzioni rapide” si trasformano in controversie sulla fatturazione.

Una struttura e un modello pratici di RFP da inviare oggi

Mantieni snello il documento principale e sposta il materiale di supporto nelle appendici. Un fornitore che valuta dieci proposte leggerà attentamente le prime tre pagine e scorrerà rapidamente il resto, quindi metti in primo piano ciò che conta.

1. Riepilogo esecutivo: un paragrafo sul problema aziendale e sul risultato desiderato.
2. Obiettivi: gli obiettivi misurabili che il progetto deve raggiungere.
3. Ambito: elementi inclusi nell’ambito, esclusi dall’ambito e ipotesi.
4. Requisiti: funzionali e non funzionali, come descritto sopra.
5. Deliverable: ciò che verrà consegnato e quando.
6. Criteri di accettazione: come verificherai ogni deliverable.
7. Modello di prezzo: un formato coerente che ogni fornitore compila nello stesso modo.
8. Criteri di valutazione: la griglia in base alla quale verranno valutati i fornitori.
9. Tempistiche: scadenze per le risposte, finestre per domande e risposte e avvio previsto.
10. Condizioni legali: proprietà intellettuale, riservatezza, responsabilità e clausole di risoluzione.

I diagrammi dell’architettura, i dati di esempio anonimizzati, le specifiche API e i profili degli utenti vanno inseriti nelle appendici, non nel corpo principale. In questo modo la RFP rimane leggibile, offrendo comunque ai fornitori qualificati la profondità tecnica necessaria per definire accuratamente l’ambito.

Un esempio di criterio di accettazione: “Il dashboard dei report deve caricare i risultati filtrati entro 2 secondi per dataset fino a 50.000 record ed esportarli in CSV senza perdita di dati.” È sufficientemente specifico da poter essere verificato, ma non al punto da imporre l’implementazione.

Per i prezzi, chiedi a ogni fornitore di compilare la stessa tabella: voce, descrizione, ore stimate, tariffa oraria o fissa e totale. Una formattazione coerente è l’unico modo per confrontare le offerte a parità di condizioni, invece di dover indovinare cosa sia incluso in ciascuna voce.

La maggior parte delle RFP ben gestite rimane al di sotto delle 15 pagine di contenuto principale, oltre alle appendici, con finestre di risposta tipiche di alcune settimane. Finestre più brevi favoriscono i fornitori che gonfiano le stime per evitare rischi, mentre finestre più lunghe raramente producono risposte migliori, ma solo risposte più tardive.

Come valutare le proposte senza tirare a indovinare

Una matrice di valutazione ponderata trasforma la valutazione delle proposte da una decisione istintiva in una decisione motivata e difendibile. Nota che il costo si trova quasi in fondo, non in cima. È una scelta intenzionale. Le migliori pratiche di approvvigionamento sconsigliano di selezionare il fornitore con l’offerta più bassa per i lavori software complessi, poiché prezzi troppo bassi spesso si traducono in seguito in scadenze mancate o debito di sicurezza.

Costruisci la tua griglia attorno a voci che obblighino i fornitori a essere specifici:

• Aderenza dell’architettura: lo stack proposto è adatto alla tua scala e alle tue esigenze di integrazione?
• Esperienza in progetti simili: hanno realizzato qualcosa di comparabile e possono dimostrarlo?
• Realismo del piano di delivery: le milestone sono supportate da una suddivisione credibile o consistono soltanto in un diagramma di Gantt con numeri arrotondati?
• Approccio a QA e test: qual è la loro filosofia sulla copertura dei test, al di là degli strumenti utilizzati?
• Maturità DevOps e CI/CD: come distribuiscono il codice e con quale frequenza?
• Controlli di sicurezza e preparazione all’SBOM: sono in grado di produrne uno e lo fanno già?
• Referenze e stabilità finanziaria: questo fornitore sarà ancora operativo tra 18 mesi?

Una volta ottenuti i punteggi, organizza un breve workshop conoscitivo o un giro di domande e risposte per chiarire i punti ancora aperti con i due o tre migliori finalisti. È qui che imparerai di più. I fornitori che pongono domande puntuali sul tuo modello di dati o contestano una scadenza irrealistica sono di solito quelli che ti diranno la verità a metà progetto, non solo al kickoff. I fornitori che accettano tutto senza fare una sola domanda di chiarimento meritano una seconda valutazione, ma per i motivi sbagliati.

Chiedete a ogni finalista i diagrammi dell’architettura e un cronoprogramma di implementazione basato sulle milestone, quindi valutate il realismo anziché la completezza. Una proposta che ammette l’incertezza in un’area e spiega come intende ridurre i rischi di solito è migliore di una che promette la perfezione sulla carta. Il nostro framework in 12 punti per scegliere un’azienda di sviluppo software personalizzato approfondisce questo aspetto, se desiderate un ulteriore punto di riferimento.

Integrare i requisiti di sicurezza e della catena di approvvigionamento

La sicurezza deve essere un requisito valutato nell’RFP, non un ripensamento aggiunto successivamente alle clausole legali. Fate riferimento al NIST Secure Software Development Framework, noto come SSDF o NIST SP 800-218, e chiedete ai fornitori di attestare l’adozione di pratiche allineate alle categorie Prepare, Protect, Produce e Respond, anziché imporre una toolchain specifica. I requisiti basati sui risultati invecchiano meglio degli elenchi di strumenti, perché gli strumenti cambiano ogni paio d’anni, mentre i risultati no.

Richiedete un software bill of materials, una policy documentata per la divulgazione delle vulnerabilità e l’applicazione delle patch, evidenze dei controlli di sicurezza della pipeline CI/CD e una tempistica dichiarata per la correzione delle vulnerabilità scoperte dopo il lancio. Guida CISA all’acquisizione del software raccomanda di rendere i fornitori responsabili dei risultati di sicurezza attraverso il linguaggio usato negli acquisti; integrare ora tale linguaggio nell’RFP è molto meno costoso che negoziarlo dopo una violazione. Le stesse linee guida suggeriscono di documentare le decisioni di accettazione del rischio con l’approvazione formale di un dirigente ogni volta che un fornitore non può soddisfare pienamente un controllo, così da avere un responsabile chiaro di quel compromesso, invece di un’alzata di spalle sei mesi dopo.

Suggerimento: Chiedete ai fornitori un esempio di SBOM proveniente da un progetto precedente, anziché una semplice promessa della loro capacità di produrne uno. Se non ne hanno mai generato uno, anche questa è un’informazione utile.

Valutate la sicurezza come riga autonoma della griglia e chiedete evidenze: policy di esempio, una descrizione di un incidente passato e di come è stato gestito, oppure una valutazione della sicurezza da parte di terzi, se disponibile.

Tempistiche, aspettative sui costi ed errori da evitare

Una tempistica realistica per un’RFP si articola in sei fasi: preparazione, domande e risposte dei fornitori, finestra per l’invio delle proposte, valutazione, negoziazione e kickoff. La maggior parte delle organizzazioni sottovaluta le fasi di valutazione e negoziazione, che insieme richiedono spesso tanto tempo quanto la finestra per la presentazione delle proposte.

Pubblicare subito una fascia di budget fa risparmiare tempo a tutti. I fornitori che non possono lavorare entro la vostra fascia si autoescludono prima di scrivere una proposta di 20 pagine e voi evitate l’imbarazzante conversazione in cui un’offerta apparentemente eccellente si rivela costare 3 volte il vostro budget. Un progetto IT su tre supera il budget del 50% o più: è esattamente il tipo di sforamento che una definizione più chiara dell’ambito e una fascia pubblicata mirano a prevenire.

Errori comuni da evitare:

• Criteri di accettazione ambigui che lasciano aperto il dibattito su cosa significhi «completato».
• Saltare i CV del team, finendo per valutare la brochure dell’azienda invece delle persone che scriveranno effettivamente il vostro codice.
• Trattare la sicurezza come una casella da spuntare anziché come un requisito valutato.
• Omettere le tappe di consegna, eliminando così l’unico sistema di allerta precoce disponibile.
• Specificare eccessivamente i dettagli dell’implementazione e imporre accidentalmente una soluzione tecnica peggiore.

Definisci un MVP iniziale o una Fase 1 incentrati su un unico risultato misurabile. È il modo più economico per verificare la reale capacità di consegna di un fornitore prima di firmare qualsiasi accordo di durata maggiore.

Aspetti legali e contrattuali

La sezione dei termini legali di una RFP stabilisce aspettative che è molto più costoso rinegoziare in seguito che definire correttamente fin dall’inizio. La titolarità della proprietà intellettuale deve dichiarare chiaramente che il codice, i design e la documentazione prodotti nell’ambito del contratto appartengono a voi, non che vi viene concessa una licenza per utilizzarli. Le clausole di riservatezza e gestione dei dati sono più importanti che mai quando un fornitore avrà accesso ai dati dei clienti o alla logica aziendale proprietaria.

I termini relativi a responsabilità e manleva devono riflettere il profilo di rischio effettivo del progetto. Un fornitore che realizza uno strumento interno di reporting comporta rischi diversi rispetto a uno che gestisce l’elaborazione dei pagamenti, e il linguaggio contrattuale deve adeguarsi di conseguenza. Le clausole di risoluzione devono specificare cosa accade al codice, alla documentazione e alle credenziali di accesso se una delle parti si ritira a metà progetto, perché una clausola di uscita poco chiara trasforma una scelta sbagliata del fornitore in una controversia legale.

Gli accordi sul livello di servizio devono essere inclusi nel contratto, non solo nella RFP, con tempi di risposta specifici per i diversi livelli di gravità dei difetti e un processo definito per le modifiche all’ambito una volta iniziati i lavori. La ricerca del GAO sull’acquisizione Agile osserva che i programmi basati su business case iterativi e valutazione continua gestiscono il rischio meglio dei contratti fissi e onnicomprensivi, un aspetto che vale la pena riflettere nella struttura delle milestone di pagamento e del controllo delle modifiche. La nostra guida agli acquisti pubblici include esempi di linguaggio contrattuale, se desiderate un modello di partenza anziché una pagina vuota.

Come Ridiculous Engineering può aiutarvi

Scrivere una RFP solida è un progetto. Consegnare quanto previsto è un altro, ed è quello che conta davvero. Ridiculous Engineering offre servizi per aiutare i team a redigere RFP e valutare le proposte in qualità di consulente indipendente, oppure per operare come partner di delivery, includendo ingegneri senior e competenze di sicurezza fin dall’inizio. Che vi serva un secondo parere nella valutazione dei fornitori o un team che realizzi il progetto, iniziate da Sviluppo software personalizzato oppure contattateci tramite Consulenza software e supporto alla delivery per parlare della vostra situazione.

Fonti

• Secure Software Development Framework | CSRC
• Software Acquisition Guide: per i consumatori enterprise della pubblica amministrazione | CISA
• Acquisizioni di software per la difesa: modifiche ai requisiti, alla supervisione e agli strumenti necessari per i programmi d’armamento | U.S. GAO

FAQ

Qual è la differenza tra RFP e RFQ?

Una RFP, ovvero una richiesta di proposta, invita i fornitori a proporre un approccio tecnico e una soluzione a un problema aziendale, mentre una RFQ, ovvero una richiesta di preventivo, chiede ai fornitori di indicare il prezzo di una soluzione già completamente specificata. Utilizza una RFP quando ha bisogno che i fornitori risolvano un problema in modo creativo e una RFQ quando i requisiti sono definiti e il prezzo è il fattore decisivo.

Quali sono i 7 passaggi di una RFP?

Le definizioni variano, ma una versione comune prevede: definire gli obiettivi, redigere i requisiti e l’ambito, pubblicare la RFP, organizzare le domande e risposte con i fornitori, raccogliere le proposte, valutare e assegnare un punteggio alle risposte, quindi negoziare e selezionare un fornitore. Alcune organizzazioni aggiungono un kickoff formale come ottavo passaggio dopo la firma del contratto.

Quanto costa una RFP?

Non esiste una risposta fissa, poiché il costo dipende dal tempo interno dedicato alla redazione e alla valutazione, non da un compenso versato a qualcuno. Le organizzazioni che trascurano di definire chiaramente l’ambito fin dall’inizio spesso sostengono costi indiretti dovuti agli sforamenti dei fornitori; per questo sono così importanti un intervallo di budget pubblicato e un approccio MVP per fasi.

Quali sono gli errori comuni da evitare in una RFP?

Gli errori più frequenti sono criteri di accettazione vaghi, non verificare le qualifiche del team del fornitore, considerare la sicurezza un aspetto secondario invece di una categoria valutata con un punteggio e omettere completamente le tappe di consegna. Anche specificare eccessivamente i dettagli dell’implementazione è una trappola comune, poiché può vincolare i fornitori a una soluzione tecnica peggiore di quella che proporrebbero altrimenti.

Consigliato

• Gestione degli stakeholder e costo del disallineamento
• Quanto costa sviluppare un software personalizzato nel 2026?
• Approvvigionamento di software per la pubblica amministrazione: guida pratica per i responsabili
• Stima dei progetti software: guida pratica per project manager