Come gestite i clienti rispetto al cambiamento dei requisiti?[Chiuso]

Question

La saggezza di Steve Yegge tuttavia, la maggior parte degli sviluppatori si trova ad affrontare requisiti raccolti da clienti non tecnici.A volte ci sono project manager che trattano con i clienti e traducono le loro esigenze, altre volte no.In ogni caso, il fatto che i requisiti cambino è inevitabile.

La maggior parte di ciò che costituisce una "buona pratica di programmazione" ha a che fare con sviluppare sistemi adattabili in modo che possano resistere alle mutevoli esigenze.Principi come YAGNI, DRY, accoppiamento lento, ecc.contribuire a questo.I processi di sviluppo iterativi come Agile tentano anche di affrontare la preoccupazione di provare a colpire un bersaglio in movimento e, naturalmente, avere un sistema sotto test rende infinitamente più fattibile apportare modifiche.

Tuttavia, sembra che per molti di noi il cambiamento delle esigenze non possa solo danneggiare la qualità del nostro software, ma può anche prosciuga la nostra motivazione e farci venire voglia di pugnalare qualcuno.

Questa domanda riguarda come farlo gestire il cliente per consentire loro di modificare le proprie esigenze nel modo di cui hanno bisogno, scoraggiando cambiamenti arbitrari o frivoli.Come si fa?

• Avete project manager per isolare gli sviluppatori dal cliente?
• Esiste un processo formale di gestione del cambiamento?Cambiare manager?
• Quanto è difficile per il cliente ottenere un cambiamento quando ne ha davvero bisogno?
• Al contrario, quanto è facile per un cliente ottenere un cambiamento quando è "frivolo"?
• Quanti dettagli fornisci al cliente quando spieghi il costo di una modifica?
• Quanto velocemente sei in grado di fornire al cliente queste informazioni dopo aver ricevuto una richiesta di modifica?
• Quali fattori possono rovinare il processo (ad es. I PM che non sanno dire di no al cliente?)
• Cosa funziona per te?

Answer 1

Se stai cercando il mondo ideale in cui il cliente non cambia mai idea o ottieni le specifiche ideali - sei nel business sbagliato . Detto questo, il meccanismo più efficace che ho trovato per gestire le aspettative dei clienti e le richieste di modifica è di istituire un sistema di misurazione accurato.

Ecco come gestisco la mia squadra:

1) Iniziamo con le storie degli utenti. Il cliente è coinvolto nella loro stesura e il team di sviluppo stima quanto tempo impiegherà ogni storia dell'utente in modo relativo.

2) Usando l'esperienza precedente prendo queste stime relative (punti della trama) e creo un programma approssimativo per quando le principali pietre miliari del progetto saranno completate.

3) All'interno di questi traguardi vengono eseguite iterazioni di 2 settimane. Il cliente è coinvolto nella definizione dei criteri di approvazione e se la storia è stata approvata o meno. Un semplice grafico di burn down mostra al cliente quanto siamo vicini al raggiungimento dell'obiettivo di lancio.

4) Spesso durante le sessioni di approvazione il cliente richiede una modifica perché la funzione non ha rivelato come si aspettava (anche se soddisfaceva i suoi criteri di approvazione originali). In questo momento generi una nuova storia con una nuova stima. Puoi anche regolare le date del tuo traguardo in modo appropriato. Questo quindi rimette la palla in campo clienti:

• Spesso si rendono conto che la loro richiesta di modifica non è valsa la pena (dovrebbero ottenere l'approvazione del loro capo) e uccideremo la nuova funzione
• A volte è importante, quindi ritarderemo la data di scadenza per ottenere la funzione in
• E infine, c'è sempre la possibilità di uccidere un'altra caratteristica non così importante che richiederà un tempo equivalente.

La chiave non è scappare dalle richieste di modifica, ma stabilire che ogni richiesta di modifica ha conseguenze sul prodotto. Non esiste un pranzo gratuito.

Answer 2

Lavoro come sviluppatore indipendente e quindi contatto direttamente con i clienti. È normale che la maggior parte delle volte non abbiano idea di ciò che vogliono effettivamente. Quindi iniziamo lentamente e do loro presto il prototipo con cui giocare e poi le modifiche verranno fatte gradualmente. Se penso che i clienti vogliano & Quot; frivolo & Quot; cambio poi gli dico che questo cambiamento non funziona o non è necessario. Se sono 5 minuti di lavoro, potrei anche farlo comunque.

Aiuta ad aggiungere successivamente al contratto alcune clausole di manutenzione per ottenere denaro per quei piccoli cambiamenti che verranno fuori in seguito. Per modifiche più grandi, devi solo caricare a ore.

Answer 3

Gestire il cliente è difficile ed è qualcosa che molto facilmente può andare storto.

Trovo che il prima possibile sia necessario ottenere la fiducia del cliente. Per me penso che tu possa farlo tramite:

• Chiedere al cliente di nominare un product manager - che ha le idee chiare per comunicare i requisiti che desidera e cerca di stabilire un rapporto di collaborazione forte con lui / lei.
• Cerca davvero di capire la loro attività : non devi essere un esperto di dominio, ma devi sapere da dove proviene il cliente.
• Poni domande pertinenti su ciò che vogliono - non dare per scontato che ciò che chiedono (all'inizio) è ciò che vogliono veramente .
• Inizialmente benvenuto a tutte le modifiche . Non si tratta di un cliente fastidioso e volubile, ma un'opportunità per capire meglio ciò che il cliente desidera davvero. Se questo ti costa tempo / denaro, potrebbe essere necessario accettarlo come leader di perdita .
• Consegna presto un prototipo e incorpora il maggior numero possibile di feedback dei clienti.
• Offri al cliente un prodotto accattivante .

Una volta che hai fatto questo, e il cliente si fida di te, sarai in grado di iniziare a respingere le modifiche irragionevoli o chiedere pagamenti / tempo extra per cose che erano precedentemente considerate fuori campo.

Naturalmente, non sarai in grado di costruire questo tipo di relazione con ogni cliente, alcuni sono idioti (in questo caso vedi se puoi nominare un product manager diverso) ma dovresti fai sempre quanto tu per costruire un rapporto di lavoro efficace.

Answer 4

Puoi & # 8217; t puoi aspettarti che i clienti sappiano cosa vogliono all'inizio, quindi devi essere adattabile. Ma devi anche interrompere il cambiamento per motivi di modifica.

Questo è per & # 8216; interno & # 8217; clienti.

Ho scoperto che la contrattazione con il cliente è un modo efficace di procedere. Possono avere qualunque funzione desiderino se la aspettano o se sacrificano altre funzionalità (ancora da implementare). Questo li costringe a pensare al valore del cambiamento che stanno chiedendo in relazione al sistema nel suo insieme.

A volte funziona bene e si raggiunge un buon compromesso. Altre volte il cliente lancia i suoi giocattoli fuori dalla carrozzina e va per quanto in alto debba implementare la funzione e la qualità viene ridotta.

Se il cliente paga, si tratta di un gioco con la palla diverso. Devono essere informati che cambiano i costi e che i costi aumentano quando il prodotto si avvicina al completamento. Ciò significa che devi fare molte analisi iniziali su ciò che fornirai e assicurarti che le specifiche siano concordate. Quindi puoi misurare ciò che è cambiato. Questa potrebbe non essere la soluzione più efficace per entrambe le parti, ma mantiene le cose tagliate e asciutte. Quindi non sono insoddisfatti e non finisci per fare un sacco di lavoro gratis.

Answer 5

Nell'ingegneria del software, il cambiamento è solo un dato di fatto. Succederà. Per noi, tutto ha un prezzo. Faremo praticamente qualsiasi cambiamento desiderino i clienti, ma c'è sempre una stima del tempo e un costo ad esso associati. Non diciamo mai al cliente di no - non normalmente, ma a volte la richiesta di modifica ha un costo molto elevato. Tracciamo la linea alle potenziali minacce alla sicurezza ecc. Nel qual caso spieghiamo loro con calma che non possiamo soddisfare la richiesta.

Quanto spieghiamo al cliente, spieghiamo dove verranno distribuiti i soldi, così tanto per lo sviluppo, così tanto per l'analisi ecc. Non diciamo esplicitamente loro perché qualcosa costa così. Ora lo ammetto, questo varia leggermente con alcuni dei nostri clienti. Alcuni di loro ricevono fatturazione molto dettagliata su quante ore sono trascorse dove. Per ottenere il contratto abbiamo dovuto accettarlo, anche se questo è molto raro per noi.

Abbiamo addetti alle vendite che a volte non possono dire di no e ciò può causare problemi. Ci abbiamo dedicato molto tempo, ma sfortunatamente continua a crescere. Lo combattiamo spiegando quanti soldi ci costano citando qualcosa senza cercare cosa ci vorrà. La trasparenza è la chiave a tutti i livelli. Tutti devono sapere come le loro decisioni influenzano i profitti.

Facciamo cambiamenti frivoli? Sì. Quello che devi ricordare è che quando si paga ogni ora per la maggior parte del tempo viene addebitato un cambio di 5 minuti a un'ora intera, quindi è abbastanza redditizio. Spieghiamo tutto questo prima come facciamo con qualsiasi richiesta di modifica in modo che ne siano consapevoli, ma tende a scoraggiare tale comportamento a meno che non sia davvero importante. Il fatto è che trattiamo tutti i cambiamenti allo stesso modo. Non presumiamo di sapere ciò che è considerato frivolo per loro, non importa quanto assurdo pensiamo possa essere. Abbiamo un processo di cambiamento formale in cui il cliente richiede qualcosa che viene annotato e indotto a firmare che è ciò che lo valutiamo e presentiamo una stima del costo del lavoro. O concordano nel qual caso firmano formalmente un documento facendoci sapere che può iniziare, oppure annullano la richiesta. Cerchiamo di essere diligenti, ma facciamo loro sapere che ci vorranno alcuni giorni per ricevere una risposta alla loro richiesta.

Un mio collega mi ha dato il miglior consiglio che io abbia mai sentito parlare della gestione delle relazioni con i clienti. È un dare e avere. Per rendere felice il cliente, devi essere disposto ad aiutarlo quando ha bisogno di qualcosa, ma allo stesso tempo devi essere in grado di dire di no. Quando hanno a che fare con le persone vogliono che tu le aiuti, ma vogliono anche che tu abbia una spina dorsale e difendi te stesso. In questo modo diventa una situazione vantaggiosa per tutti.

Answer 6

Preferirei un termine di requisiti in evoluzione a “requisiti in cambiamento”.Professor M.M.Lehman (http://www.doc.ic.ac.uk/~mml/ E http://en.wikipedia.org/wiki/Meir_Manny_Lehman) ha dato un contributo considerevole alla ricerca sull'evoluzione del software;i suoi lavori suggeriscono inoltre che non tutti i tipi di requisiti evolvono.Ci si potrebbe considerare fortunati se si lavora su uno di questi sistemi, dove i requisiti rimangono gli stessi (ad es.librerie di matematica, ecc.).

Per il resto di noi l'esperienza suggerisce che gli sviluppatori preferiscono quante più informazioni possibili sui requisiti in anticipo, mentre i clienti o gli utenti finali apprezzano la capacità di specificare o adattare i requisiti il ​​più tardi possibile nel processo di sviluppo.I primi hanno bisogno di informazioni dettagliate per aiutare a pianificare e progettare la soluzione, i secondi possono ottenere un vantaggio strategico modificando un requisito in ritardo, perché dà al cliente un certo margine di manovra per rispondere al cambiamento dell'ambiente o alle informazioni ottenute come risultato del cambiamento. fasi iniziali/iterazioni del progetto.Un compromesso tra la capacità di avere un piano dettagliato e di cambiare le cose determina in gran parte il processo di sviluppo stesso (a cascata, agile, a spirale, ecc.).

Alcuni consigli pratici per gestire l’evoluzione dei requisiti:

• Crea uno spazio nel piano iniziale per tenere conto dell'evoluzione dei requisiti, di più punti di controllo o iterazioni.

• O inserire requisiti volatili all'inizio del progetto in modo che una sorta di prototipazione o studio di fattibilità possa chiarirli o pianificare la modifica nelle fasi successive del progetto.

• Monitorare che i requisiti siano ancora pertinenti.

• Tieni a portata di mano un elenco aggiornato e in ordine di priorità dei requisiti attuali.Nient'altro aiuta a mantenere l'evoluzione sotto controllo quanto una buona visibilità per tutte le parti interessate degli attuali "must have" compresi la loro relativa priorità e costo.

• Continuare a gestire le aspettative dei clienti su quanto tempo richiederà le cose;questo aiuta anche a mantenere la concentrazione.

• Introduci un processo formale per modificare o aggiungere requisiti, se necessario.La descrizione del processo deve specificare i ruoli dei soggetti coinvolti, la frequenza delle revisioni, ecc.Potrebbe servire come una buona salvaguardia contro alcuni requisiti politici e più opportunistici ma non essenziali.

• Compila in un po' di tempo per il refactoring anche per la prima versione.È molto probabile che abbandonerai tutta o parte della soluzione a causa dell'ulteriore acquisizione di conoscenze durante lo sviluppo.

Answer 7

Il cliente viene da te per fare qualcosa perché o non hanno il tempo di farlo o non sanno cosa fare (e vogliono pagarti per farlo per loro) . Se hai esigenze mutevoli, è a causa di quest'ultima. In altre parole, ti stanno pagando per capire i dettagli! E sanno cosa piace e non piace, ma non sanno come funziona.

Riconosci questo e qualunque cosa debba essere la soluzione va a posto.