È responsabilità dello sviluppatore del software capire cosa intendeva il cliente con la sua richiesta?

Se è il tuo lavoro da capire, è compito tuo fare domande finché non lo fai

La persona che chiedi può essere qualcuno che non è il cliente (ho spesso parlato con un intermediario, che era in contatto con il cliente), quindi chi ti proibisce di parlare con il cliente dovrebbe invece rispondere alle domande stesse o indirizzarti a qualcuno che può.

Ma alla fine ci deve essere QUALCUN tipo di comunicazione. Se lo negano (e forniscono alcuni documenti che non si capiscono, negano efficacemente la comunicazione), dovresti fare come i tuoi predecessori: scappare, rapidamente.

Quando i tuoi clienti e superiori ti lasciano con una scia di carta disordinata, l'unica cosa che puoi fare è raccogliere il più buon senso possibile da ciò che hai e iniziare a scrivere scenari in inglese semplice nel tentativo di strutturare la conoscenza che c'è su come dovrebbe comportarsi il sistema.

Given / When / Then ti consentono di entrare nei dettagli su cosa deve accadere e perché sono scritti in un inglese semplice e sono strutturati, puoi usarli per comunicare al tuo superiore e cliente: "Ascolta, sono arrivato a questo punto e non ho idea di cosa sia il sistema fare qui ".

Se semplicemente esci quando chiedi ulteriori chiarimenti, anche se hai investito degli sforzi per documentare tutto ciò che fai e non capisci, allora i precedenti sviluppatori non hanno fallito perché non sapevano come comunicare le specifiche , ma perché è impossibile farlo.

A mio parere entrambi (cliente e sviluppatore) devono ottenere la stessa comprensione del problema e la sua soluzione.

Se non capisci la richiesta, non puoi creare la soluzione.

Quindi devi leggere le specifiche. Se le specifiche non sono abbastanza chiare (o non ci sono specifiche scritte) dovrebbe esserci qualcuno che possa dare le risposte.

Lavoro in team con una sola persona in grado di rispondere alle domande aziendali. Questo imprenditore è un membro della società di sviluppo per cui lavoro, che conosce l'attività dei clienti o un membro del team dei clienti.

Sembra che nella tua specifica ubicazione il project manager teme che il cliente sarà seccato se gli vengano poste più volte le stesse domande (necessarie a causa del turnover degli sviluppatori) e che questo rifletterà male su di lui e sulla sua azienda.

Ovviamente, se non fai queste domande, ti ci vorrà molto più tempo per completare / modificare il sistema e il risultato potrebbe non essere quello che il cliente desiderava, il che causerebbe più ritardi e ANCHE rispecchiare male il progetto manager e la sua azienda, almeno agli occhi del cliente.

Ci sono alcuni motivi per cui il project manager potrebbe scegliere di non farti fare domande:

1. Non capisce le conseguenze negative o nega loro.
2. È a conoscenza delle alternative ma sa che è più probabile che il cliente accetti ritardi e scarsa qualità rispetto alle fastidiose domande.
3. Sta giocando a giochi politici: forse sa che lascerà presto il progetto e vorrebbe mantenere nascosti i problemi fino a quel momento, o ha intenzione di incolparti per i problemi causati da questa mancanza di comunicazione.

La ragione IMO 2 è improbabile. Per eliminare la ragione 1, prova a spiegare le alternative a lui e chiedigli di fare una scelta esplicita tra di loro - suggerisci di spiegare il problema al cliente per ridurre il fastidio. Al fine di eliminare la ragione 3, farlo per iscritto in modo da poter dimostrare di essere a conoscenza dei potenziali problemi preliminari e tentare di risolverli. Ma ad essere onesti, se sospetti che ciò sia necessario, dovresti probabilmente andartene il prima possibile.

Penso che sia sempre responsabilità del fornitore di servizi assicurarsi che abbiano compreso le intenzioni dei clienti.

In qualità di esperti nel nostro settore, non è solo il nostro lavoro completare i brief, ma anche aiutare a guidare i nostri clienti attraverso il processo di utilizzo del nostro servizio, e questo implica educarli sulle possibilità che offriamo e su ciò che facciamo ora.

Credo che un approccio incentrato sul cliente sia assolutamente il modo di fare le cose, è un modello di business provato e testato.

Il cliente e gli sviluppatori devono collaborare per perfezionare la loro comprensione del sistema.

L'azienda di software deve raggiungere un accordo con il cliente su ciò che è richiesto a ciascuna parte, che è l'aspetto fondamentale di un contratto. Se non c'è un "incontro di menti" allora, in un senso molto reale, non c'è un contratto.

Supponendo che tu sia un programmatore competente, se le specifiche non sono chiare, semplicemente ti viene detto "È tua responsabilità capire la richiesta, non fare più domande" è piuttosto sciocco.

Questo è basato su alcune nuove informazioni nei commenti alla domanda originale.

La dichiarazione che

the customer already explained us, what he wants. It's your responsibility to understand the request, not ask more questions

viene dal leader del progetto; la logica dichiarata è

that since I'm not the first developer on the system we shouldn't bother the client's representitive with more questions, but try to and if necessary, spend extra time interpreting the question

Quindi ciò che ti viene detto di evitare è disturbare il cliente con domande .

Chiedere di "dedicare più tempo a interpretare la domanda" non è necessariamente irragionevole. Dovresti compiere uno sforzo ragionevole, o forse anche uno sforzo leggermente irragionevole, per capire quali sono i requisiti basati su ciò che il cliente ha effettivamente detto. Se non altro, è un'abilità preziosa.

Se ciò non riesce (e sembra che lo abbia già, per vari motivi), chiedi aiuto al tuo capo progetto. Cerca di essere il più specifico possibile nelle tue domande, dimostrando che hai fatto i compiti. Ad esempio, piuttosto che

what do these people want???"

chiedi qualcosa del tipo,

In paragraph 17 of the requirements document, it says that the foobar must frizzle the frozzle; which of these three frozzles does that refer to?"

Oppure, se i requisiti sono scritti così male che non puoi decifrarli, diglielo.

Direi che in ultima analisi spetta al responsabile del progetto assicurarsi che i requisiti siano compresi correttamente (è certamente nel suo interesse per il successo del progetto). Ma come membro del team, condividi parte di questa responsabilità. Se mostri di aver fatto uno sforzo da solo, e il capo del progetto si rifiuta di aiutarti, allora ha fatto interamente a tuo carico. Se arriva a quel punto, assicurati che lo sappia.

In un mondo perfetto, ci dovrebbe essere un elenco di caratteristiche e specifiche da qualche parte, qualcosa scritto su un contratto che lega la tua azienda e il tuo cliente.

Per rispondere alla tua domanda, lo sviluppatore dovrebbe effettivamente capire cosa vuole il cliente e avere un documento scritto in modo che entrambe le parti concordino sulla stessa visione.

Naturalmente, questo non è un mondo perfetto e spesso non ci sono specifiche, e se non si hanno specifiche scritte, beh, questo sarà difficile. C'è qualcuno rimasto nella tua azienda che lavora come delegato di relazioni con il cliente, chi potrebbe aiutarti a capire cosa vuole il cliente?

In caso contrario, nella tua posizione, proverei a ottenere informazioni dagli sviluppatori precedenti, supponendo che abbiano compreso il compito, naturalmente.

Penso che il ruolo effettivo che specifica chi si prende cura dei requisiti di comprensione varia a seconda di alcune di queste variabili

• Dimensioni del team
• Standard aziendali
• Il modo in cui il boss è abituato a lavorare
• Competenze diverse tra i membri del team

Quindi, se sei un team composto da un solo membro, dovresti fare ogni sforzo per arrivare al fondo delle richieste. se sei nuovo in un progetto in corso, dovresti fare uno sforzo per ripassare le richieste di nuovo con il cliente.

Modifica La cosa più importante è che il cliente potrebbe non sapere di aver fatto tali esigenze e il processo di raccolta dei requisiti è spesso lungo e noioso, ma è un processo importante, e se cade su di te perché nessun altro lo fa, allora dovresti farlo con loro.