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

Una specie di domanda sì / no e perché?

È responsabilità dello sviluppatore del software capire cosa intendeva il cliente con la sua richiesta o è responsabilità del cliente spiegare correttamente la sua richiesta allo sviluppatore?

La situazione al lavoro è attualmente "il cliente ci ha già spiegato, cosa vuole. È tua responsabilità capire la richiesta, non fare più domande".

Mentre l'inglese non è la mia suite, tutte le richieste sono scritte in inglese oscuro con parole fuori posto e frasi difficili da capire, alcune richieste presuppongono una comprensione precedente del sistema da parte mia.

Sono il 3o o il 4o sviluppatore del sistema (gli ultimi sviluppatori hanno lasciato il lavoro) e questo potrebbe essere il motivo per cui il cliente si aspetta una certa comprensione da parte degli sviluppatori.

Il sistema stesso è piuttosto disordinato sia nell'interfaccia utente che a livello di codice sorgente. A me sembra una scimmia che mi sta codificando: codice e spero che tu ottenga la richiesta giusta, mentre in realtà non la capisci.

In realtà sto pensando di lasciare il lavoro, ma non l'ho ancora visto, dato che non sono sicuro di chi abbia ragione e chi abbia torto.

Se è il tuo lavoro capire, è il tuo lavoro fare domande fino a quando non lo fai

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

Ma alla fine ci deve essere QUALCHE tipo di comunicazione. Se lo negano (e fornire alcuni documenti che non capisci è negare efficacemente la comunicazione), dovresti fare come i tuoi predecessori: scappare, rapidamente.

Quando i tuoi clienti e superiori ti lasciano con un disordinato percorso cartaceo, l'unica cosa che puoi fare è raccogliere il maggior senso possibile da ciò che hai e iniziare a scrivere scenari in un inglese semplice nel tentativo di strutturare quale conoscenza ci sia su come il il sistema dovrebbe comportarsi.

Dato / quando / allora gli scenari ti consentono di entrare nel dettaglio di ciò che deve accadere e poiché sono scritti in un inglese semplice e sono strutturati, puoi usarli per comunicare con il tuo superiore e cliente: "Ascolta, Sono arrivato a questo punto e non ho idea di cosa dovrebbe fare il sistema qui ".

Se sei semplicemente evitato quando chiedi ulteriori chiarimenti, anche se hai investito gli sforzi per documentare tutto ciò che fai e non capisci, gli sviluppatori precedenti non sono riusciti perché non sapevano come comunicare le specifiche, ma perché è impossibile farlo.

A mio avviso, sia il cliente che lo sviluppatore devono avere la stessa comprensione del problema e della sua soluzione.

Se non capisci la richiesta non puoi creare la soluzione.

Quindi devi leggere le specifiche. Se la specifica non è abbastanza chiara (o non ci sono specifiche scritte) dovrebbe esserci qualcuno che può dare le risposte.

Lavoro in team che hanno una 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 nella tua specifica posizione, il project manager teme che il cliente sarà infastidito se gli vengono poste più volte le stesse domande (necessarie a causa del turnover degli sviluppatori) e che ciò si rifletterà male su di lui e sulla sua azienda.

Naturalmente, se non ponete queste domande, 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 rifletterà ANCHE male sul project manager e sul suo compagnia, almeno agli occhi del cliente.

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

1. Non capisce davvero le conseguenze negative o le nega.
2. Conosce le alternative ma sa che è più probabile che il cliente accetti ritardi e scarsa qualità rispetto a domande fastidiose.
3. Sta giocando a giochi politici: forse sa che lascerà presto il progetto e vuole mantenere nascosti i problemi fino ad allora, o sta pianificando di incolpare te per i problemi causati da questa mancanza di comunicazione.

Il motivo 2 dell'IMO è improbabile. Per eliminare la ragione 1, prova a spiegargli le alternative e chiedigli di fare una scelta esplicita tra 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 di potenziali problemi sin dall'inizio e aver tentato di risolverli. Ma a dire il vero, se sospetti che ciò sia necessario, dovresti probabilmente uscire il più rapidamente possibile.

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

Come esperti nel nostro settore, non è solo nostro compito completare i brief, ma anche aiutare a guidare i nostri clienti attraverso il processo di utilizzo del nostro servizio, e ciò ha comportato la loro educazione sulle possibilità che offriamo e su ciò che facciamo ora.

Credo che un approccio orientato al cliente sia assolutamente il modo di fare le cose, è un modello di business collaudato.

Il cliente e gli sviluppatori devono lavorare insieme per affinare la loro comprensione del sistema.

La società di software deve raggiungere un accordo con il cliente su ciò che è richiesto da ciascuna parte, che è l'aspetto fondamentale di un contratto. Se non esiste un "incontro di menti", in un senso molto reale, non esiste un contratto.

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

Questo si basa su alcune nuove informazioni nei commenti sulla domanda originale.

La dichiarazione che

il cliente ci ha già spiegato cosa vuole. È tua responsabilità capire la richiesta, non fare più domande

viene dal capo progetto; la logica dichiarata è

che dal momento che non sono il primo sviluppatore sul sistema non dovremmo disturbare il rappresentante del cliente con più domande, ma cercare di e, se necessario, dedicare più tempo all'interpretazione della domanda

Quindi, ciò che ti viene specificamente detto di evitare è infastidire il cliente con domande .

Chiederti di "dedicare più tempo all'interpretazione della domanda" non è necessariamente irragionevole. Dovresti fare uno sforzo ragionevole, o forse anche un po 'irragionevole, per capire quali sono i requisiti in base a ciò che il cliente ha effettivamente detto. Se non altro, è un'abilità preziosa.

Se fallisce (e sembra che lo sia 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

cosa fanno queste persone vogliono ???"

chiedi qualcosa come

Nel paragrafo 17 del documento sui requisiti, si afferma che il foobar deve sfrigolare il beccuccio; a quale di questi tre frozzi si riferisce? "

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

Direi che alla fine è responsabilità del 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 quella responsabilità. Se dimostri di aver fatto qualche sforzo da solo, e il capo progetto si rifiuta di aiutarti, allora ne ha fatto interamente la tua responsabilità. 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 davvero capire cosa desidera il cliente e avere un documento scritto in modo che entrambe le parti concordino la stessa visione.

Certo, questo non è un mondo perfetto e spesso non ci sono specifiche, e se non hai alcuna specifica scritta, beh, sarà difficile. È rimasto qualcuno nella tua azienda che lavora come delegato delle relazioni con il cliente, che potrebbe aiutarti a capire cosa desidera il cliente?

Altrimenti, nella tua posizione, proverei a ottenere informazioni dagli sviluppatori precedenti, supponendo che abbiano ovviamente compreso il compito.

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

• Dimensione della squadra
• Gli standard dell'azienda
• Il modo in cui il capo è abituato a lavorare
• Diversa competenza tra i membri del team

Quindi, se sei solo un team di un uomo, 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 con il cliente.

MODIFICA: Soprattutto, il cliente potrebbe non sapere di avere requisiti così scarsi, e il processo di raccolta dei requisiti è spesso lungo e noioso, ma è un processo importante e se ricade su di te perché nessun altro lo fa, allora dovresti fallo con loro.