Cosa inserire in una RFP di sviluppo software (e le 5 clausole che ti tutelano)

Una richiesta di proposta di sviluppo software (RFP) è il documento che indica ai fornitori cosa è necessario realizzare, perché e come verranno giudicate le loro offerte. Uno valido contiene cinque cose: il problema e gli obiettivi aziendali (non una lista dei desideri), i vincoli noti (intervallo di budget, scadenze, sistemi esistenti, conformità), un ambito chiaro con ciò che è in entrata e in uscita, i criteri di valutazione rispetto ai quali otterrai effettivamente un punteggio e i termini contrattuali che governeranno il lavoro. L'ultima parte conta di più ed è quella che la maggior parte delle RFP lascia sottile. Cinque clausole ti proteggono: proprietà della proprietà intellettuale, criteri di accettazione, consegna e documentazione, controllo delle modifiche e supporto post-lancio. Inseriscili nella RFP stessa, non nel contratto che negozi dopo aver già scelto, e manterrai aperte le tue opzioni mentre le hai ancora.

Cosa contiene una buona RFP di sviluppo software?

La struttura è semplice. La disciplina consiste nel mantenersi sui risultati, non sulle soluzioni.

1. Il problema e l'obiettivo. Descrivi cosa è rotto o mancante e come si presenta il successo in termini semplici. Un buon venditore propone la build; descrivi il risultato. Se specifichi la soluzione in dettaglio, scopri solo se possono seguire le istruzioni.
2. Vincoli e contesto. Range di budget, tempistica, sistemi con cui deve integrarsi, dati con cui entrerà in contatto ed eventuali obblighi normativi. Nascondere il budget fa perdere tempo a tutti e produce offerte che non è possibile confrontare.
3. Ambito, esplicito da entrambe le parti. Elenca cosa è dentro e, cosa altrettanto importante, cosa è fuori. La maggior parte delle controversie iniziano nel divario tra ciò che una parte presume fosse incluso e l’altra no.
4. Criteri di valutazione. Indica come assegnerai un punteggio alle proposte: esperienza pertinente, approccio tecnico, team, prezzo e i termini seguenti. I venditori scrivono ciò che misuri.
5. Le clausole protettive. Le cinque seguenti. Inserirli nella RFP, e non nel contratto successivo, è l'elemento più importante che separa un acquirente che mantiene il controllo da uno che non lo fa.

Questo è anche il documento in cui dovrebbe già essere definita la decisione costruisci o acquista software. Una RFP è per una build. Se stai ancora pesando, risolvi prima questo.

Quali 5 clausole ti proteggono in una RFP software?

Questi sono i termini che decidono chi detiene il potere una volta terminato il progetto. Richiedili in anticipo, mentre diversi venditori vogliono ancora il lavoro.

Clausola	Cosa garantisce	Cosa va storto senza
Proprietà intellettuale	Possiedi il codice sorgente, le risorse e il diritto di modificarli	Il fornitore possiede il codice e tu ottieni in licenza il tuo sistema da loro
Criteri di accettazione	Un test oggettivo per "fatto" prima del pagamento finale	Discussione infinita sul fatto che l'opera soddisfi le specifiche
Consegna e documentazione	Codice, credenziali e documenti che consentono a un altro team di assumere il controllo	Sei bloccato perché solo loro capiscono come funziona
Cambia controllo	Un processo e una tariffa concordati per le modifiche all'ambito	Fatture a sorpresa o rifiuto di adeguarsi man mano che impari
Assistenza e manutenzione	Tempi e costi di risposta definiti dopo il lancio	Un sistema live senza che nessuno sia obbligato a ripararlo

Perché la proprietà della proprietà intellettuale rientra nella RFP e non nel contratto?

Perché l’equilibrio del potere cambia nel momento in cui scegli un fornitore. Prima di firmare hai diverse parti interessate e un confronto pulito. Dopo aver firmato, hai un fornitore e un sistema costruito a metà che non puoi spostare facilmente. Una clausola che non costa nulla da concordare nella prima settimana può costare una rinegoziazione, o una ricostruzione, nel sesto mese.

La proprietà della proprietà intellettuale è l’esempio più chiaro. Dichiara chiaramente che tutto il codice sorgente, le risorse di progettazione e i materiali correlati diventano di tua proprietà a pagamento, senza alcuna licenza residua richiesta per eseguirli o modificarli. Le aziende rispettabili lo accettano senza attriti. Un venditore che resiste, perché vuole mantenere il tuo codice, ti sta dicendo qualcosa di utile prima che tu abbia speso qualcosa.

L’accettazione è la seconda clausola che le persone rimpiangono di aver saltato. Definire cosa significa "finito" come test che il sistema supera o fallisce, concordato in anticipo. Senza di esso, l’ultimo dieci per cento di un progetto diventa una negoziazione piuttosto che una consegna, e il pagamento finale è l’unica leva rimasta per forzarne il completamento.

In che modo il passaggio di consegne, il controllo del cambio e il supporto ti mantengono sotto controllo?

Questi tre decidono se possiedi un sistema o semplicemente affitti l'accesso alle persone che lo hanno costruito.

La consegna è la proprietà resa reale. Il contratto dovrebbe richiedere codice sorgente funzionante in un repository che controlli, istruzioni di distribuzione, configurazione dell'ambiente, credenziali e documentazione abbastanza buona da consentire a un team competente che non ha mai visto il progetto di eseguirlo ed estenderlo. Richiedilo come un risultato finale con una propria fase di accettazione, non come una cortesia alla fine. Se la consegna è vaga, sei bloccato indipendentemente da ciò che dice la clausola IP, perché in pratica nessun altro può toccare il sistema.

Il controllo delle modifiche protegge entrambe le parti. Le tue esigenze cambieranno durante la costruzione; questo è normale. Quello che vuoi è un modo concordato per gestirlo: come viene richiesta una modifica, come viene fissata il prezzo e a quale tasso. Lo scopo non è impedire il cambiamento ma toglierne la sorpresa, in modo che una nuova esigenza diventi una piccola conversazione prevedibile anziché una disputa.

Supporto e manutenzione sono la clausola per il giorno successivo al lancio, ovvero il momento in cui il software inizia effettivamente la sua vita. Definisci cosa succede quando qualcosa si rompe: tempi di risposta, chi è responsabile, quanto costa e per quanto tempo. Un sistema attivo senza obbligo di manutenzione è una responsabilità in attesa del suo primo incidente. È qui che emerge anche la differenza tra un consiglio d'acquisto e l'acquisto di un risultato. Un partner che rimane responsabile una volta che il sistema è in produzione è una proposta diversa da uno che scompare al momento della consegna.

Il pratico asporto

Tratta la RFP come il luogo in cui imposti i termini, non solo il luogo in cui descrivi il lavoro. Le cinque clausole (proprietà della proprietà intellettuale, accettazione, trasferimento, controllo delle modifiche, supporto) non costano quasi nulla da concordare mentre i fornitori sono ancora in competizione e molto da aggiungere una volta scelta. Scrivili in anticipo, valuta le proposte contro di loro e mantieni il controllo del sistema che stai pagando per costruire. Se vuoi dare un'occhiata più da vicino a un brief prima che venga pubblicato, raccontaci cosa stai costruendo; è esattamente il tipo di definizione dell'ambito da cui parte comunque il nostro lavoro di software personalizzato.