Chi (cliente o fornitore) dovrebbe scrivere il documento delle specifiche

È tua responsabilità raccogliere informazioni sufficienti a rendere ragionevolmente possibile scrivere un'applicazione che soddisfi in modo sostanziale le aspettative del cliente. Di solito significa tornare al cliente, porre le domande giuste e ottenere risposte chiare.

Ci sono molte risorse che ti insegneranno come raccogliere specifiche di requisiti utili. La regola più pertinente è questa: "Ogni requisito deve essere accompagnato da un test di accettazione che, una volta eseguito, indica chiaramente e inequivocabilmente se il requisito è stato soddisfatto." Se il test di accettazione non esiste, non è un requisito: è una "caratteristica" o un "desiderio".

Lo sviluppo del software ha una lunga storia di aspettative insoddisfatte. Prima di impegnarti in un documento di design approvato e scrivere un software che il cliente dice non quello che ha chiesto (questo accade sempre), considera l'adozione di un approccio iterativo. Tu e il tuo cliente vi impegnate a sviluppare rapidamente una serie di prototipi; con il completamento di ogni prototipo, il cliente può fornire feedback sulle caratteristiche che gli piacciono e le caratteristiche che non gli piacciono, consentendo a te e al cliente di guidare lo sviluppo verso un risultato di successo.

Il processo tipico è che l'azienda di sviluppo software collabora con il cliente per definire le specifiche del software.

Quanto questo diventa coinvolto, dipende dal modello commerciale ...

Il cliente paga un prezzo fisso, per una specifica fissa, nel qual caso è necessario comprendere e documentare pienamente le specifiche e fare firmare al cliente che questo è ciò che verrà consegnato per i propri soldi.

Se il cliente paga tempo e materiali. Quindi lavorare in modo iterativo, offrendo funzionalità incrementali con revisioni periodiche con il cliente può funzionare bene, ma il cliente dovrà essere maggiormente coinvolto nella pianificazione settimanale e contribuire a risolvere le lacune nelle specifiche quando si presentano.

Nella mia esperienza, trovare clienti che sono felici di commissionare software senza una definizione fissa del prodotto finale e nessuna idea del prezzo è irrealistico, quindi alla fine si ottiene una stima complessiva del cliente. Vorrei quindi raccomandare caldamente di includere in questa stima un contingency del 30-50%, in modo che il cliente disponga di un budget per gli aggiornamenti delle specifiche, i requisiti non documentati e l'implementazione durante le esecuzioni.

Se la stima è significativamente esaurita (impiega più del doppio del tempo), il risultato finale sarà probabilmente un ex cliente molto turbato.

Buona fortuna!

Dipende completamente da ciò che il cliente sta cercando e da ciò che è stato venduto al cliente.

In un mondo ideale, il cliente avrebbe ora esattamente e in anticipo ciò di cui aveva bisogno. Ti fornirebbe una specifica perfetta con tutti i dettagli e senza alcuna ambiguità. Ma come sarebbero redatte specifiche così precise?

• Il cliente ha le capacità analitiche per fornirti un'analisi approfondita e all'avanguardia (ad esempio con i mezzi di una grande azienda)?
• Potrebbe subappaltare l'analisi a consulenti indipendenti (ad esempio a volte ciò si verifica negli appalti pubblici)? Ti avrebbe quindi fornito questo risultato (sperando che sia comprensibile e nulla fosse dimenticato)!
• O dovrebbe subappaltare questo analisi insieme al lavoro di implementazione?

Per me, le prime due alternative suonano molto simili a un modello a cascata. È certamente un'opzione possibile. Ma se fosse l'approccio migliore, il Gruppo Standish non avrebbe mai pubblicato il suo rapporto sul caos del progetto . E nessuno avrebbe inventato metodi iterativi e agili!

Il fatto che il cliente ti dia un documento relativamente breve con i suoi obiettivi e una descrizione di alto livello ha il seguente vantaggio:

• hai anche la libertà che ha scelto l'approccio migliore per perfezionare i requisiti (sia cascata che agile)
• puoi proporre soluzioni più innovative di quelle a cui il cliente può pensare (Ford diceva: "Se avessi ascoltato il mio cliente, avrei cercato cavalli più veloci" )
• il cliente evita il rischio di ping-pong tra il suo analista e il suo implementatore in caso di problemi di qualità,

Tuttavia, esiste una condizione perché funzioni correttamente: il cliente deve essere pronto a contribuire attivamente al progetto, sia per la raccolta dei requisiti sia per la sessione interattiva per convalidare i risultati del prodotto iterativo e confermare gli orientamenti.

Le responsabilità per le consegne sono generalmente indicate nelle Dichiarazioni di lavoro (SOW).

Se questo è stato lasciato indefinito, consiglio di assicurare che sia assemblato un documento dei requisiti che possa essere usato per comunicare e collaborare. Inoltre, fai attenzione che tutti i partecipanti al progetto capiscano o abbiano letto il documento.

Deve essere un processo iterativo. Chi paga mai il conto ottiene l'ultima parola, ma spesso non sanno cosa chiedere. Prepara una brutta copia e tocca settimanalmente la base con il progresso.

Vedi Sviluppo Agile