Best practice per il coinvolgimento del cliente in fase di sviluppo Agile? [chiuso]

Question

Abbiamo bisogno di coinvolgere i nostri partner per lo sviluppo del cliente nel nostro processo di sviluppo. Stiamo più o meno seguendo metodologie agili. Alcuni partner del cliente sono remote, altri più vicini. Abbiamo bisogno di ridurre al minimo i costi di viaggio.

I nostri clienti sono nella cura della salute e tendono ad essere occupato, costoso e difficile da programmare.

Quali pratiche e le tecnologie hanno lavorato per sostenere il coinvolgimento del cliente? Stiamo utilizzando le telefonate, conferenze telefoniche ed e-mail. Siamo curiosi di sapere sfruttando tecniche di wiki e mi piacerebbe sentire quello che ha funzionato per gli altri.

Answer 1

La mia esperienza con i metodi agili è per lo più per le applicazioni desktop. Quando i nostri clienti sono remote, abbiamo passato il tempo per ottenere un ingegnere per la sede del cliente per configurare / installare un impianto demo. L'ingegnere lavora con il cliente su una configurazione di prova e demo / piano che fornirà un ambiente che il cliente ritiene che riproduce gli aspetti importanti dell'ambiente di distribuzione, ma isola il sistema di demo da infrastrutture esistenti (in modo da poter spingere gli aggiornamenti ogni volta che abbiamo bisogno di ). L'ingegnere definisce anche sistemi di distribuzione per spostare le nostre applicazioni in produzione, in modo da poter "schierare" senza essere sul posto. Le nostre applicazioni in grado di auto-aggiornamento (sia per ogni rilascio o di ogni generazione) e abbiamo accuratamente strumento i rilasci di Login tutti gli errori e sottoponiamo tutti gli arresti come bug al nostro bug tracker. In questo modo, almeno sappiamo cosa è andato storto, anche se non sappiamo cosa sta andando a destra.

Per ogni versione / build che si presenta sul banco di prova del cliente, mettiamo a disposizione un (breve) screencast, narrato dal responsabile del progetto o sviluppatore primario, demo-ing eventuali nuove funzionalità. Le note di rilascio contengono tutti i problemi a lungo termine o domande che vogliamo il cliente a cui pensare (vale a dire che i problemi non possono essere risolti immediatamente da una telefonata o e-mail), e l'applicazione visualizza queste note per l'utente.

Infine, e forse più importante, otteniamo il cliente e / o di collegamento del cliente di un account sul il nostro calendario server e configurare il loro calendario app per fare uso di tale conto. Questo poi va in entrambe le direzioni -. Siamo in grado di programmare il tempo (in loco, telefono, e-mail, etc.) con il cliente e che possono fare lo stesso con i nostri sviluppatori

Answer 2

non importa se il cliente si trova nella stessa cabina o dall'altra parte del pianeta, ad eccezione di ritardi di comunicazione -. Il fattore critico è disponibilità

un cliente che è troppo occupato per rispondere alle vostre e-mail per diversi giorni sta per causare la vostra iterazione di essere in ritardo, o non riescono

il cliente ha due impegni fondamentali per agile:

1. a disposizione per rispondere alle domande in modo tempestivo
2. di non cambiare idea / priorità durante un'iterazione

il cliente deve impegnarsi per un accordo ragionevole livello di servizio (SLA) sulla disponibilità, per esempio tempo di 1 ora di risposta, o il tempo di risposta di 24 ore, ecc, e sarà necessario per regolare tutte le stime e gli orari per il fattore di ritardo. Se il cliente non commettere o non seguire attraverso, annullare l'iterazione e ri-piano, portando ancora una volta l'impegno del cliente alla ribalta. Fare non solo "indovinare" che cosa pensi che il cliente potrebbe desiderare.

In conclusione:. Senza un impegno verso il cliente, agile non funzionerà

Answer 3

Una possibilità: installare un proxy cliente al sito "partner del cliente" che può estrarre le informazioni di cui avete bisogno, quando i clienti sono disponibili. Hanno queste deleghe costruire le solide relazioni che consentono loro di rappresentare la vista del cliente. Il loro tempo è tutto tuo. E quando sorgono domande che non possono rispondere, hanno accesso immediato ai tuoi partner del cliente -. Anche se nella linea di caffè

Answer 4

Il punto del cliente in agile è quello di avere il discorso aperto e libero con gli sviluppatori (IE feedback immediato). Se i vostri clienti attuali non possono fornire questo, allora avete bisogno di un intermediario / proxy che può ricoprire questo ruolo. Non lo sai necessità reale i clienti, è solo bisogno di qualcuno che può rappresentare gli interessi abbastanza bene per soddisfare i vostri clienti dei clienti esigenze.

Answer 5

solo alcune idee:

Se si sceglie di utilizzare un Wiki, assicurarsi che supporta una lista "modifiche recenti" wide tutto-wiki-, e preferibilmente uno che è specifico per gli utenti. Il meno distante dalla gente di sviluppo sono, il più probabilità di avere e-mail come metafora per il loro uso del computer. Se non possono dire subito se c'è qualcosa di nuovo per loro di vedere, non potranno mai esplorarlo. È inoltre necessario preferibilmente modi per segnalare loro che è necessario il loro attenzione alle questioni, o tratteranno i cambiamenti come candidati.

Sono un grande credente nella creazione di cattura schermo il video di interazioni (narrata) e di distribuirli agli utenti. A differenza di una vera e propria demo, i clienti non si sentono come hanno bisogno di interrompere, e possono tornare indietro e ri-guardare il stessa interazione più e più volte, prestando attenzione ai piccoli dettagli.

Infine, se si fa distribuire prototipi, assicuratevi di mandare qualcuno (o almeno una sessione di condivisione dello schermo) per vedere come vengono utilizzati i prototipi. progettazione contestuale è efficace. Potete contare su persone che utilizzano il vostro prototipo modo diverso da come ci si aspetta, e si deve capire come lo usano per capire davvero dove sono i problemi, anche se non li riportano.

Answer 6

Avete considerato qualcosa di simile a LogMeIn .

Ciò consentirebbe ai clienti di entrambi i log-in per un PC in rete già in esecuzione l'applicazione, o, in alternativa permetterà di installare / aggiornare l'applicazione su uno dei loro computer.

Questo risolverebbe il problema del cliente a distanza e avrebbe anche sostenere il requisito feedback dei clienti continua in corso nel processo agile.

L'ho usato una precedente società per il supporto tecnico, ma non c'è alcuna ragione (tranne forse costo) che non avrebbe funzionato per la situazione.

E 'anche un ottimo modo per vedere in realtà come gli utenti utilizzano l'applicazione e quindi scoprire che cosa funziona e cosa no.

Answer 7

Prima di tutto, assicurarsi che si dispone di un product manager o un prodotto proprietario chiudono le sviluppatori. Questa persona sarà la gestione del rapporto con il cliente.

Quindi, il product manager in grado di dimostrare il prodotto al cliente al termine di ogni iterazione e chiedere inoltre ai clienti domanda quando lo sviluppatore ha bisogno di feedback per implementare una storia utente.

E 'sorprendente il feedback positivo si può ottenere da parte dei clienti quando li coinvolgono.

Non abbiamo usato un wiki e la maggior parte della comunicazione avviene via email, telefono, e un'applicazione di condivisione dello schermo (stiamo usando GoToMeeting, ma ci sono tonnellate di alternative là fuori).

Answer 8

Si dovrebbe probabilmente fare un kick-off una volta con tutti in un unico posto. Faccia a faccia il tempo è prezioso. Questo include tutti gli sviluppatori. Preparare alcune domande Metaplan, ma anche hanno abbastanza tempo per mescolarsi solo.

Answer 9

Credo che dalla maggior parte delle definizioni di processi agili che hanno alta dipendenza dal coinvolgimento del cliente che hai già perso "best practice", che sarebbe per un sito on-, e preferibilmente "in squadra" cliente presente in ogni momento. Quindi suppongo che stiamo cercando un "next best-practice". :)

C'è la possibilità di introdurre un "cliente proxy" in loco. Devo ammettere di essere molto scettico circa il valore di un cliente proxy. Sono preoccupato per il rischio di introdurre una sorta di seconda classe e la funzione business analyst altrimenti necessario al mix, con l'aumento del rapporto segnale-rumore e il potenziale di messaggi distorti. Svolge anche il rischio di consentire ai clienti reali impegnati a ridurre il loro coinvolgimento nel processo, che rischia di portare a insoddisfazione. Mi chiedo se ci potrebbe essere qualcuno con buona conoscenza di dominio che si è da poco in pensione e potrebbero essere disponibili ad agire in questa capacità come consulente?

larghezza di banda di comunicazione con i clienti remoti è sorprendentemente inferiore a faccia a faccia, qualcosa che non avevo pienamente realizzati fino a quando ho iniziato a trattare con gli utenti in un altro paese. Anche con il video la perdita è significativa.

Per quanto tempo sono i tuoi iterazioni? Quanto è difficile programmare iterazioni? Potrebbe essere più facile andare per iterazioni più a lungo e ottenere di più la pianificazione fatta meno frequentemente, o ridurre l'iterazione lunghezza e andare al più piccolo, ma sessioni di pianificazione più frequenti? Sono più di un cliente involv

Hai una configurazione utilizzabile e disponibile alla fine di ogni iterazione? C'è tempo per gli utenti interessati di avere hands-on tempo prima della prossima sessione di pianificazione? Mantenere gli utenti impegnati per il trasporto di frequente sembrerebbero in superficie per essere una buona idea, che legifera forse per le piccole iterazioni frequenti (una settimana? due settimane?)

L'idea wiki potrebbe funzionare: hai guardato il FIT quadro ? Si tratta di una sorta di accettazione integrato test / wiki, che potrebbe aiutare a ottenere prove di accettazione da parte dei clienti remoti. Penso che mi piacerebbe anche cercare di fornire una sorta di "cruscotto progetto" (separato o integrato), forse spinto regolarmente per i clienti chiave e disponibili su richiesta. usarlo come un sostituto per le cose come post-it su lavagne, Grafici Grandi visibili e simili. Ci sono una serie di opzioni open-source o di basso costo che possono servire -. Scrivere il proprio semplice alternativa non deve essere troppo in termini di tempo o costoso, sia

Soprattutto, ricordate che "Agile" è una sorta-di catch-all etichetta per gli sviluppi che vengono svolte con particolare attenzione per i valori ei principi espressi nel Agile manifesto . Ciò che è considerato "migliore" in una situazione non può esserlo in un altro. Se capite i principi e regolarmente rivedere i vostri metodi con un occhio critico, allora probabilmente stai andando ad essere abbastanza vicino per la migliore applicazione pratica per la vostra situazione.

Non ho guardato per qualche tempo, ma con Beck e Fowler nella lista autore, ci dovrebbe essere qualcosa di utile in Planning Extreme Programming .

Answer 10

Nella mia posizione precedente @ drchrono.com ho aggregati richieste di dati / feedback / iterazione da 20.000 medici in tutto il paese. Il modo migliore per farlo è quello di evangelizzare un sito come uservoice.com. Ho tenuto "quotidiane dimostrazioni dal vivo web" con a volte da 50 a 100 medici (medici iscritti direttamente dal nostro sito web). In questi demo vorrei dimostrare il nostro prodotto corrente ed evangelizzare la voce all'utente di guidare il loro feedback in uno strumento utile per il nostro team di sviluppo. Tutto questo è stato fatto in remoto e ha portato ad un aumento complessivo di 1.400% in ricorrenti la crescita dei ricavi.