RFP per lo sviluppo web: come scriverne una che funziona

Una RFP per lo sviluppo web è un documento che spiega alle agenzie cosa devi far realizzare, come valuterai le offerte e cosa deve contenere una proposta, così da poter confrontare tutto alle stesse condizioni. Scrivine una quando il progetto è abbastanza grande o rischioso da giustificare una selezione documentata e sai già più o meno cosa vuoi. Se non lo sai, definisci prima il problema e scrivi la RFP dopo. Questa guida ti dà la struttura, uno schema pronto, un metodo di valutazione e le regole svizzere da verificare.

In breve

• Usa una RFP quando budget, complessità o rischio richiedono un confronto documentato fra più agenzie e quando il risultato desiderato è ragionevolmente chiaro.
• Copri dieci parti: contesto, obiettivi, perimetro, requisiti tecnici, risultati attesi, tempi, budget, formato della proposta, criteri di valutazione e regole di consegna.
• Valuta le offerte con criteri ponderati e verifica le referenze, invece di scegliere in base al prezzo o alla presentazione più brillante.
• In Svizzera gli enti pubblici devono rispettare le soglie degli appalti. Le aziende private sono libere di definire il proprio processo, ma gli obblighi sulla protezione dei dati restano tuoi.

Cos'è una RFP per lo sviluppo web e quando ha senso

SWICO, l'associazione svizzera delle TIC, descrive la RFP come un processo in cui il committente chiede ai fornitori di sviluppare una soluzione conforme ai requisiti indicati e di quotarla. I fornitori possono anche propose first implementation ideas and possible solutions. Le stesse linee guida distinguono la RFP dal pitch: con una RFP le agenzie vengono scelte in base alle loro offerte e solo dopo elaborano il progetto nel dettaglio. Avvertono inoltre che accordi vaghi o mancanti dopo l'uno o l'altro processo possono portare a controversie e insoddisfazione.

Quest'ultimo punto è il vero motivo per scrivere una buona RFP. Il documento non è burocrazia fine a sé stessa. È la prima versione della conversazione contrattuale.

Una RFP tende a ripagare quando sono vere tre cose, secondo one practitioner guide: investimento, complessità o rischio sono abbastanza elevati da richiedere una valutazione documentata, il risultato desiderato è ragionevolmente definito e più agenzie qualificate vanno confrontate con gli stessi criteri. Un'altra guida osserva che il formato è especially useful for high-stakes, high-value projects e favorisce una selezione oggettiva e documentata.

Funziona male invece quando:

• Il progetto è piccolo, per esempio un sito vetrina di poche pagine. Un breve briefing e due o tre colloqui sono più rapidi.
• Non hai ancora chiaro quale debba essere il prodotto. Una RFP deve sostenere una decisione già definita, non sostituire il lavoro di definizione dei tuoi bisogni.
• Vuoi che l'agenzia dia forma all'idea insieme a te. In quel caso è meglio una fase di analisi a pagamento o una consulenza.

Se non sai da che parte della linea ti trovi, dedica qualche giorno a chiarire il problema e il risultato che vuoi prima di scrivere qualsiasi cosa. Una guida su how to compare agencies fa la stessa osservazione dal lato del committente: la chiarezza sui bisogni viene prima di qualsiasi lista di candidati.

Le dieci parti di una RFP per lo sviluppo web

Non esiste una formula fissa, ma le buone RFP condividono lo stesso scheletro. Ecco a cosa serve ogni parte e quanto deve essere dettagliata.

1. Presentazione dell'azienda e contesto del progetto

Due o tre paragrafi: chi sei, cosa vendi, chi sono i tuoi utenti e perché questo progetto nasce ora. Indica cosa esiste oggi (un vecchio sito, un foglio di calcolo, un processo manuale) e cosa non funziona. Le agenzie mettono a prezzo il rischio, e il contesto lo riduce.

2. Obiettivi e misure di successo

Indica il risultato aziendale, non l'elenco delle funzioni. «Dimezzare le richieste di preventivo gestite via e-mail» è un obiettivo. «Un modulo di contatto» è una funzione. L'Associazione svizzera per il project management (VZPM) consiglia di deriving project goals from the organization’s goals, tradurre i bisogni degli stakeholder in requisiti e trasformarli in criteri di accettazione con cui verificare i risultati. Scrivi due o tre obiettivi misurabili e hai già l'inizio di quei criteri.

3. Perimetro dei lavori

Elenca cosa è incluso e, altrettanto importante, cosa è escluso. Voci tipiche per un progetto web:

• Nuova realizzazione, riprogettazione o migrazione di un sito esistente su un'altra piattaforma
• Numero e tipo di template, più che numero di pagine
• Migrazione dei contenuti: chi scrive, chi sposta, quanto
• Integrazioni con un negozio online, CRM, ERP, sistema di pagamento o provider di identità
• Lingue: in Svizzera spesso significa tedesco, francese, italiano e inglese, il che incide su contenuti, URL e flussi di redazione
• Hosting, supporto al lancio e manutenzione successiva

4. Requisiti funzionali e tecnici

Il metodo federale di gestione progetti HERMES project-management method è qui una lista di controllo utile. Dice che i requisiti di soluzione comprendono esigenze specialistiche e tecniche, caratteristiche e funzioni attese, requisiti legali e normativi, requisiti di esercizio, supporto e sicurezza, nonché requisiti per l'ottimizzazione e la correzione dei difetti.

Per un progetto web, traducilo così:

• Funzionali: cosa devono poter fare utenti e redattori
• Tecnici: stack preferito o vincoli, luogo di hosting, supporto di browser e dispositivi, obiettivi di prestazione
• Sicurezza ed esercizio: autenticazione, backup, monitoraggio, aggiornamenti, chi interviene in caso di incidente
• Aspetti legali: protezione dei dati, accessibilità, gestione dei cookie e del consenso

Un esempio svizzero reale mostra il livello di dettaglio che funziona. Una RFP di Helvetas per il supporto al sito web specifies testing, Core Web Vitals performance, documentation, proactive maintenance, monitoring, patches, TLS and backups. Nota che copre la vita dopo il lancio, non solo la realizzazione.

Contrassegna ogni requisito come indispensabile, auspicabile o gradito. Senza questo, ogni agenzia quoterà un progetto diverso.

5. Risultati attesi

Indica i risultati che ti aspetti di ricevere: file di design, codice funzionante nel tuo repository, documentazione, formazione per gli amministratori, un rapporto di test, una sessione di consegna. Se vuoi essere proprietario del codice sorgente e poter cambiare fornitore, scrivilo qui. È molto più facile mettersi d'accordo prima del contratto che dopo.

6. Tempi

Indica la data in cui vuoi andare online, eventuali scadenze esterne fisse (una campagna, una fiera, un cambiamento normativo) e se la data è flessibile. Le indicazioni di Adobe sulle RFP elencano fra gli elementi essenziali the project timeline, including whether the deadline is flexible. Pubblica anche il calendario del processo di selezione: quando si chiudono le domande, quando scadono le offerte, quando ci sono le presentazioni, quando decidi. Nel tuo documento usa date reali e raccoglile in un'unica tabella.

7. Budget

Indica una fascia. Molti committenti nascondono il budget per «vedere cosa arriva», e il risultato sono offerte non confrontabili: un'agenzia quota una versione essenziale, un'altra una versione completa. Una fascia dichiarata permette alle agenzie di dirti onestamente cosa ci sta dentro e cosa no. La stessa guida raccomanda di indicare the project timeline, including whether the deadline is flexible. Chiedi i prezzi suddivisi per fase o per risultato atteso, e come vengono quotate le richieste di modifica.

8. Formato della proposta

Di' alle agenzie esattamente come rispondere, così da poter mettere le offerte una accanto all'altra:

• Profilo dell'azienda e del team, con i nomi delle persone che lavorerebbero al tuo progetto
• Comprensione del problema, con parole loro
• Approccio proposto e architettura
• Calendario con le tappe principali
• Dettaglio dei prezzi e piano di pagamento
• Due o tre referenze confrontabili che puoi chiamare
• Ipotesi ed esclusioni

Fissa un limite di pagine. Da quindici a venti pagine bastano per la maggior parte dei progetti web.

9. Criteri di valutazione

Pubblica i tuoi criteri e i relativi pesi nella RFP. Mantiene oneste le agenzie e coerente il tuo team. La sezione seguente spiega come.

10. Regole di consegna

Persona di contatto, termine per le domande, termine per le offerte, formato dei file, lingua e durata di validità dell'offerta. Precisa se condividerai domande e risposte con tutti i concorrenti. Farlo è più equo e ti evita di rispondere cinque volte alla stessa domanda.

Come valutare le offerte

Una guida alle RFP per siti web raccomanda di especially useful for high-stakes, high-value projects, verificare le referenze e far valutare le risposte dagli stakeholder annotando le loro osservazioni. È una buona pratica. Una versione semplice:

Criterio	Peso esemplificativo	Cosa guardare
Comprensione del tuo problema	20%	Riformulano i tuoi obiettivi e individuano rischi che non avevi menzionato
Approccio tecnico	20%	Risponde ai requisiti, è manutenibile, senza complessità inspiegabili
Team e continuità	20%	Persone con nome e cognome, esperienza pertinente, chi resta fino alla consegna
Prezzo e condizioni commerciali	20%	Dettaglio chiaro, regole per le richieste di modifica, proprietà del codice
Referenze ed esperienza	10%	Progetti simili, clienti che puoi chiamare
Supporto dopo il lancio e consegna	10%	Modello di manutenzione, documentazione, condizioni di uscita

Adatta i pesi alla tua situazione, poi fissali prima di aprire qualsiasi offerta. Ogni valutatore assegna i punteggi da solo, poi il gruppo li confronta. Dove i punteggi divergono molto, discutetene il motivo. Di solito la differenza indica qualcosa di poco chiaro nell'offerta o nella tua RFP.

Due abitudini migliorano i risultati. Primo: chiedi chi farà davvero il lavoro. A volte le agenzie mandano i senior alla presentazione e i junior sul progetto. Secondo: considera un segnale positivo un'offerta che mette in discussione il tuo perimetro, purché il ragionamento sia solido.

Regole svizzere da verificare prima di pubblicare

Appalti pubblici

Se sei un ente pubblico o un committente ai sensi di legge, non puoi definire liberamente il processo. La Public Procurement Act federale consente l'incarico diretto per servizi sotto i CHF 150 000 e richiede una procedura aperta o selettiva a partire da CHF 230 000 per i servizi. Per i contratti a tempo indeterminato il valore si calcola moltiplicando la remunerazione mensile per 48, il che conta per i contratti di supporto e manutenzione. I bandi federali sono pubblicati su SIMAP, come indica il FDFA states for its own mandates. Cantoni e Comuni hanno regole proprie sugli appalti, quindi verifica con il tuo ufficio legale quali si applicano al tuo caso.

Protezione dei dati

Se l'agenzia ospiterà o tratterà dati personali, la responsabilità resta tua. L'Incaricato federale della protezione dei dati e della trasparenza afferma che, quando esternalizzi un trattamento, devi select the processor carefully, give appropriate instructions and monitor where necessary. Inserisci nella RFP una breve sezione in cui chiedi ai concorrenti dove saranno conservati i dati, quali subappaltatori utilizzano e come gestiscono gli incidenti.

Accessibilità

I contenuti web e le app mobili dell'Amministrazione federale devono soddisfare il livello AA delle WCAG 2.1 secondo lo eCH-0059 Accessibility Standard version 3. Le aziende private non sono vincolate a quello standard, ma chiedere lo stesso livello è un requisito ragionevole e verificabile, e si sovrappone alle buone pratiche per la ricerca. Sul legame fra le due cose, vedi questa panoramica su web accessibility and SEO.

Uno schema da copiare

Incolla questo elenco nel tuo documento e completa ogni riga. Va bene per un sito web e si adatta facilmente a un'applicazione o a una piattaforma web.

1. Introduzione: azienda, nome del progetto, persona di contatto
2. Contesto: situazione attuale, utenti, cosa non funziona
3. Obiettivi: tre risultati misurabili
4. Perimetro: incluso, escluso, fasi
5. Requisiti: funzionali, tecnici, di sicurezza, legali, di accessibilità, ciascuno classificato come indispensabile, auspicabile o gradito
6. Integrazioni: sistemi da collegare, con i rispettivi fornitori e API
7. Risultati attesi: codice, documentazione, formazione, consegna
8. Tempi: lancio previsto, tappe, date del processo di selezione
9. Budget: fascia, preferenze di pagamento, condizioni per le richieste di modifica
10. Formato della proposta: sezioni richieste, limite di pagine, referenze
11. Valutazione: criteri e pesi
12. Condizioni: validità dell'offerta, riservatezza, proprietà intellettuale, protezione dei dati

Come adattarlo a un progetto software

Per un'applicazione o una piattaforma web, aggiungi quattro cose. Primo: i ruoli utente e i flussi di lavoro principali, scritti come brevi storie. Secondo: una dichiarazione esplicita su come i requisiti possono cambiare. HERMES osserva che HERMES project-management method, con le modifiche documentate tramite una richiesta di cambiamento quando si spostano obiettivi, budget o tempi. Indica ai concorrenti quale modello ti aspetti. Terzo: una sezione non funzionale: carico previsto, disponibilità, backup e monitoraggio. Quarto: un piano di uscita: documentazione, accesso al repository e un periodo di consegna se cambi fornitore.

Errori frequenti

• Elenchi di funzioni senza obiettivi. Le agenzie quotano funzioni, non risultati.
• Budget nascosto. Ricevi offerte che vanno da CHF 20 000 a CHF 300 000 e non impari nulla.
• Troppi concorrenti. Da tre a cinque agenzie scelte bene ti danno risposte migliori di quindici fatte di fretta.
• Nessun tempo per le domande. Le buone agenzie ne fanno, e le domande rivelano chi riflette davvero sul tuo problema.
• Scegliere solo in base al prezzo. L'offerta più economica spesso esclude ciò che le altre includevano.
• Ignorare la fase di manutenzione. Un sito o un'app vivono per anni dopo il lancio. Chiedi fin d'ora il modello di supporto e il suo costo.

Il ruolo di Ampersand

Siamo un piccolo studio di Zurigo: rispondiamo alle RFP e aiutiamo anche i team che non sono ancora pronti a scriverne una. Gli ingegneri senior restano coinvolti dalla prima consulenza fino alla consegna, quindi le persone che leggono la tua RFP sono le stesse che realizzano il progetto. Se i tuoi requisiti sono ancora sfumati, il nostro piano Guidance costa 799 CHF al mese e, una volta online il sito o l'app, Run & monitor costa 750 CHF al mese. Puoi vedere tutte le opzioni, dai siti web e dalle app all'automazione, alle integrazioni e alle migrazioni, sulla pagina dei prezzi di Ampersand.

Domande frequenti

Quanto deve essere lunga una RFP per lo sviluppo web?

Per la maggior parte dei progetti aziendali bastano da cinque a dieci pagine. Includi obiettivi, perimetro, requisiti, tempi, budget, formato della proposta e criteri. I documenti più lunghi tendono a nascondere i punti chiave e riducono la probabilità che le agenzie rispondano.

Devo indicare il budget nella RFP?

Sì, come fascia. Permette alle agenzie di proporre qualcosa di realistico e rende le offerte confrontabili. Se non puoi indicare una cifra, chiedi ai concorrenti di quotare due o tre varianti di dimensione diversa.

A quante agenzie conviene inviare la RFP?

Da tre a cinque è un numero pratico: abbastanza per confrontare, abbastanza poche perché tu possa leggere ogni offerta con attenzione e incontrare i finalisti. Scegliile fra chi ti è stato segnalato e chi ha già realizzato lavori simili al tuo.

Una RFP è la stessa cosa di un pitch?

No. Secondo SWICO, in una RFP le agenzie vengono selezionate in base alle loro offerte e solo dopo dettagliano il progetto, mentre il pitch è un processo diverso. In entrambi i casi SWICO consiglia di mettere poi per iscritto accordi chiari, per evitare controversie.

Fonti

• propose first implementation ideas and possible solutions
• one practitioner guide
• especially useful for high-stakes, high-value projects
• the project timeline, including whether the deadline is flexible
• HERMES project-management method
• deriving project goals from the organization’s goals
• specifies testing, Core Web Vitals performance, documentation, proactive maintenance, monitoring, patches, TLS and backups
• Public Procurement Act
• FDFA states for its own mandates
• select the processor carefully, give appropriate instructions and monitor where necessary
• eCH-0059 Accessibility Standard version 3