È meglio spiegare cosa otterrà il cliente se si seguono i propri requisiti mentre vengono scritti e si suggerisce che i requisiti vengano riscritti per chiarire il vero intento del cliente.

Ma in generale è compito del Project Manager interpretare i requisiti in modo tale da soddisfare adeguatamente le esigenze del cliente. È inutile seguire alla cieca una serie di requisiti letteralmente quando sai che ti stai preparando per il fallimento.

Che dire del debito tecnico, per esempio? Scrivi un programma scadente, scarsamente architettato, che è irraggiungibile, ma soddisfa i requisiti del cliente o ti concedi il tempo di fare il lavoro giusto?

Sì ... è il tuo lavoro tornare indietro e ottenere chiarimenti. Noi, in qualità di sviluppatori, dobbiamo essere altrettanto coinvolti nella raccolta e nella comprensione dei requisiti di qualsiasi utente aziendale o aziendale. Se sospetti di volere qualcosa di diverso da ciò che è sulla carta, parla con loro.

Faccia a faccia se possibile - sempre meglio di e-mail o IM. POI - follow-up con una e-mail - mantieni la tua scia cartacea.

Ricevo spesso requisiti vaghi, contraddittori o che potrebbero portare a un cattivo risultato. La mia risposta standard è diventata scrivere un'e-mail che generalmente è simile a questa:

I want to double-check something with you.

What I understand is that you want me to do X, Y, and Z, you know that implementing all three of these will result in [a particular bad result], and that's what you want to happen.

If this is not correct, please tell me specifically where I've misunderstood and what you'd prefer to have done by [some date and time, like tomorrow at 1 PM]. Otherwise, I will begin implementing based on this understanding.

Ho trovato che funziona molto bene. L'ho appena fatto la scorsa notte e il mio cliente ha corretto le sue richieste prima di iniziare a lavorare stamattina.

Questo approccio non incolpa la controparte, ma mette la palla nella loro corte per capire e indicare chiaramente ciò che vogliono veramente in modo tempestivo, e fa in modo che sia loro la responsabilità di accettare le conseguenze se non lo fanno . Come consulente, stanno pagando i soldi e chiamano i colpi. Quindi immagino che se vogliono che io faccia qualcosa di stupido, li avvertirò in un linguaggio semplice, ma alla fine è una loro decisione, e finché sarò pagato, sono felice.

Dato che stai facendo una domanda sull'etica, devi specificare quale codice etico stai rispettando. Risponderò in base al Codice di etica e pratica professionale per l'ingegneria del software dell'ACM .

Le sezioni importanti sono quelle sulla relazione con il cliente e il prodotto stesso:

CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.

In particolare:

2.06. Identify, document, collect evidence and report to the client or the employer promptly if, in their opinion, a project is likely to fail, to prove too expensive, to violate intellectual property law, or otherwise to be problematic.

e

PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

In particolare:

3.06. Work to follow professional standards, when available, that are most appropriate for the task at hand, departing from these only when ethically or technically justified.

3.07. Strive to fully understand the specifications for software on which they work.

3.08. Ensure that specifications for software on which they work have been well documented, satisfy the users’ requirements and have the appropriate approvals.

Quanto sopra dovrebbe rispondere alla tua domanda sui tuoi obblighi etici. Il tuo team di sviluppo deve avvisare il tuo cliente dei problemi riscontrati dal team con i requisiti.

Suggerirei di non farlo da soli. Devi documentare ciò che vedi come problemi e discutere con il tuo project management e la tua leadership tecnica.

I progetti ben avviati dovrebbero avere un processo di gestione dei requisiti, che dovrebbe includere disposizioni per la documentazione e la risoluzione dei problemi rilevati durante lo sviluppo.

Rallenta, Cowboy!

Chiedi l'input degli utenti. E spiega perché la tua strada è migliore.

Should it be a part of our job to match the spirit of the requirements, or match ridiculous requirements with this gut feeling that the requirements will change once they see the final result?

Nessuno dei due.

Abbiamo inventato i processi Agile in modo da non avere questa scelta rigida (e ingestibile) tra due alternative abbastanza pessime.

Il punto di essere Agile è trovare un percorso utile, di valore elevato, utile tra due modalità di fallimento.

Se costruisci le tue specifiche e non ti piace il risultato, puoi dire "Ho creato le specifiche! Qual è il problema?" Quindi ci sarà la riscrittura e il perfezionamento delle specifiche e del codice. A meno che non abbiano finito i soldi per farlo. In tal caso dovrai trovare un nuovo cliente se il tuo cliente non può ottenere più denaro.

Se costruisci ciò che pensi loro vogliono e hai sbagliato , diranno "Non hai costruito ciò che vogliamo! Ri-fallo! No, non ti pagheremo questa volta! " e sarai nei guai, e forse anche senza un lavoro. Quale potrebbe succhiare.

In conclusione:

Se inizi ad avere la sensazione che ciò che vogliono non sarà buono per loro o che non gli piacerà, parlagliene con loro Ottieni chiarimenti prima inizi a scrivere quel codice.

La linea di fondo è che il cliente vuole ciò che vuole anche quando non sa quello che vuole. Prendilo? Quindi qualsiasi esercizio che non porti direttamente o indirettamente a questo obiettivo finale è un esercizio di inutilità.

Parla con il cliente e ottieni i requisiti ordinati per ciò che VERAMENTE VOGLIONO sulla carta, così in questo modo quando si passa al QA test i tester non saranno confusi su quali siano i requisiti reali.

Lo SPIRITO dei requisiti è una questione di opinione e potrebbe non coincidere con ciò che altri stakeholder, sviluppatori e tester vedono nei requisiti. Lascia il minimo spazio per l'interpretazione nel requisito scritto possibile.

@Xaade ha dato la tua risposta a @Morons (eh, strano come il suo ID si adatta così bene a questa situazione) Penso che sarebbe nel migliore interesse di tutti perseguire la tua idea di conoscere la soluzione corretta dato tutti i vincoli tecnici.

Il design iterativo è applicabile in tutte le fasi del progetto. Quindi, continua la fase dei requisiti fino a quando tutti si trovano sulla stessa pagina.