• Possibile: sì: -)

• Consigliabile: solo se non c'è davvero altro modo. Ciò comporterebbe facilmente requisiti estremamente fragili e poco compresi. E i problemi possono comparire solo in una fase successiva, durante l'implementazione o il test di accettazione.

I requisiti che si incontrano idealmente dovrebbero essere una serie di discussioni dettagliate tra cliente e sviluppatore. I clienti di solito hanno idee molto deboli di ciò che vogliono veramente, implementando così la loro prima vaga decifrazione come sarebbe quasi inevitabilmente portano a problemi. Quindi gli sviluppatori dovrebbero essere in grado di dire il prezzo di ogni idea / storia / requisito, che aiuta i clienti a dare priorità ai loro bisogni, e fornire un feedback tecnico su ciò che è possibile e fattibile. Inoltre, dovrebbero comprendere il dominio del problema nel modo più approfondito necessario, al fine di fornire la migliore soluzione tecnica al problema del cliente. Durante tutto il percorso, devono assicurarsi di aver compreso correttamente il cliente, il che significa chiedere spesso chiarimenti e ripetere ciò che hanno capito con le proprie parole durante le sessioni di comunicazione (e spesso fornendo prototipi UI / prototipi di idee dei clienti). Il mezzo migliore per questo è la comunicazione orale - se non è possibile faccia a faccia, un video o una conferenza telefonica è la prossima opzione migliore.

Avere una persona non tecnica come canale di comunicazione tra clienti e sviluppatori limita strongmente l'efficienza della comunicazione. Anche l'invio di documenti avanti e indietro via e-mail sarebbe meglio, dove non c'è almeno un intermediario , quindi c'è una possibilità in meno di incomprensione.

Anche se sono d'accordo con Péter Török che una via di mezzo potrebbe limitare l'efficienza, avere un colloquio di non sviluppatore con gli utenti finali potrebbe aumentare l'efficacia della comunicazione.

Ho scoperto che spesso gli sviluppatori e gli utenti finali possono parlare insieme ma continuano a capirsi male perché provengono da "mondi diversi". Mentre parlano le stesse parole possono capirli per significare cose completamente diverse ... Un intermediario che comprende sia la mentalità / linguaggio dell'utente finale che degli sviluppatori, può valere il loro peso in oro, migliorando la comprensione reciproca di ciò che è necessario / cosa sarà sviluppato.

Detto questo, chiedere ad un manager, che si tratti di un account manager o di un altro tipo di manager, non è la strada da percorrere. Colmare il divario tra lo sviluppatore e il mondo degli utenti finali è un'abilità e non qualcosa che fai "da parte".

In breve, questo modo di lavorare è pieno di pericoli ed è stato uno dei motivi per cui è nato Agile Manifesto .

{cattivo tentativo di umorismo} Inizia, prendi in prestito, combatti, imbroglia, ruba, affascina, porta al pub, fai tutto ciò che puoi per essere realmente coinvolto con l'utente finale {/ cattivo tentativo di umorismo}

Ma seriamente, se non riesci ad accedere, assicurati almeno che ci sia un ciclo di feedback rapido. Quindi sì, è possibile porre domande tramite il gestore account (se è possibile accedere direttamente al client, anche se in remoto tramite e-mail che è ancora migliore), ma chiedere loro ogni giorno e fornire un prototipo il più spesso possibile per il client da provare.

Altrimenti rischi di consegnare qualcosa che il cliente finale non vuole realmente.

Lavoro in un'organizzazione di dimensioni medio-grandi e abbiamo un team di soluzioni aziendali con molti analisti di business. Svolgono un lavoro importante in quanto comprendono perfettamente il processo aziendale e traducono ciò che l'azienda desidera a ciò che lo sviluppatore comprende. Funziona anche in altro modo. Se rilevo un problema di progettazione e / o architettura o propongo un modo alternativo per risolvere il problema, parlo con loro e loro a loro volta verso il business.

In una grande azienda ci sono molte cose da considerare oltre alle cose tecniche quando si fa un requisito. Come i problemi di formazione del personale, come non incidere su un cliente con una modifica, come un processo di compensazione esistente per rendere la tua domanda un non-problema, o "John" è marketing usa questa funzione e non puoi cambiarla ecc.

Per rispondere alla tua domanda se hai una struttura in atto, allora usala. Fornisci loro l'elenco di domande da seguire con i gestori degli account aziendali.

Stai giocando ai requisiti che raccolgono la versione del gioco del telefono. Nella migliore delle ipotesi, ciò causerà molta inefficienza nella comunicazione. Nel peggiore dei casi, causerà requisiti non correttamente raccolti. L'importanza di questo ciclo di feedback e la sua efficienza sono uno dei motivi principali per cui il rappresentante del cliente è uno dei ruoli più preziosi (e più difficili da scalare) in un team Agile.

NO

Prendendo la tua domanda alla lettera, la risposta non può essere altro che un clamoroso "NO! NO! A MILLE E VENTIQUATTRO VOLTE NO!" a meno che il "Gestore account" sia anche un consulente esperto, analista e sviluppatore

Se nel processo deve esserci un intermediario non addestrato, è meglio inviare i sondaggi degli utenti via e-mail e semplicemente fare il check-in del gestore dell'account. Lui / Lei non può aggiungere valore al processo, ma può certamente ingannare le comunicazioni.

Il ruolo appropriato per l'Account Manager in questo processo è quello di partecipare alla conversazione come stakeholder , non giocare middleware o analista dilettante.