Come convincere un cliente non tecnico che le specifiche dell'applicazione devono essere semplificate?

Stimando quanti soldi / tempo costano per fare quelle centinaia di funzionalità con alta qualità. Molto, molto pochi clienti metteranno i loro soldi dove è la loro bocca.

Due parole: User Story.

Ho appreso che il modo più rapido per aiutare un cliente a ottenere un clue® è quello di loro parlarmi attraverso una trama di un utente per ogni singola funzione o pagina desiderata. Accadono diverse cose, tra cui:

1. Devono pensare su cosa diavolo dovrebbe effettivamente fare la pagina / funzione.
2. Come chiedi maggiori e più dettagli ("e poi? ... e allora? ...") iniziano a capire che l'intera cosa non sta per venire in essere avendo Magic Space Monkeys ™ volare e farlo durante il fine settimana.
3. Diventano veri partner nel processo di creazione. Il che significa che capiranno perché cambiare idea su qualcosa che è già completo all'80% causerà a) un ritardo nella programmazione eb) un aumento dei costi.

Scherzi a parte. User Story dei proprietari è uno dei migliori strumenti che conosca per portare almeno un po 'di sanità mentale al processo.

Mentre discutiamo del costo e dell'aspetto time-to-production, chiedete una classifica dei requisiti ("deve avere", "dovrebbe avere" e "bello avere") in modo che il set di prodotti minimo vitale di funzionalità che sono essenziali sono "deve avere" nella versione 1, quindi inserire il resto dei requisiti in serie di backlog che potrebbero essere eseguiti come sprint successivi alla prima versione. Speriamo che i "non-indispensabili" non essenziali andranno sul retro del pacchetto e quando arriverete a questi sprint, quelli nuovi più essenziali (dall'esperienza effettiva con il prodotto) saranno saliti in cima.

Il cliente dovrebbe apprezzare il fatto che sta prendendo in considerazione il costo della propria attività e l'importanza di ottenere rapidamente il prodotto e di non licenziare direttamente il "bello da avere" inserendoli nell'arretrato.

Modifica per rispondere alla modifica OP: Per convincere il cliente perché è una buona idea rilasciare in anticipo un prodotto minimo vitale, spiegare che finché il prodotto non viene utilizzato da utenti reali è difficile sapere se avrà successo (soprattutto in termini di usabilità). Se il cliente esita a distribuire un prodotto iniziale a tutta la sua base di utenti, consiglia di fare una "beta limitata" dove è disponibile solo per un sottoinsieme mirato dei propri clienti. Spiega loro che il rovescio della medaglia di questo approccio è un ciclo di sviluppo lungo e costoso con una determinazione tardiva che il prodotto è inutilizzabile. 37 Signals ha prodotto un paio di buoni riferimenti a questo proposito: Getting Real e Rework . Il Getting Real è disponibile gratuitamente sul web.

La causa principale della tua frustrazione per la situazione è probabilmente quella della percezione e dei termini fuorvianti / errati usati dal cliente. Di solito il cliente non viene da voi con una lista di requisiti , ma una lista di desideri di ogni singola cosa che potrebbero pensare a potrebbe essere utile a loro. Questi non sono tutti requisiti perché il cliente non ha ancora impiegato il tempo per pensare veramente se ogni funzione è veramente richiesta .

Questo non è necessariamente sempre un problema

Se il tuo cliente ha i soldi per tutte quelle funzionalità ed è disposto a separarsene, e non ti interessa davvero risolvere i problemi reali, reali che il cliente ha, allora questo potrebbe essere un progetto molto redditizio. Succede, molto, molto raramente, e per la maggior parte degli sviluppatori è un lavoro che uccide l'anima perché puoi sentire in anticipo che il progetto non avrà successo per il cliente alla fine (anche se ha successo finanziario per te come sviluppatore). È anche ad alto rischio perché è probabile che tu finisca con un progetto a costi fissi con molta incertezza, ed è davvero un problema per valutare male il rischio su progetti di grandi dimensioni.

Che cosa succede se si tratta di un problema?

Supponiamo che tu non sia in quella situazione rara. In questo caso dovrai affrontare le due principali carenze della lista dei desideri come indicato:

1. È improbabile che il cliente abbia un'idea corretta dei costi per lo sviluppo di un elenco così ampio di requisiti, quindi è improbabile che tu possa ottenere il contratto per la quantità di denaro effettivamente necessaria per farlo.
2. È improbabile che questa lista di desideri descriva in modo preciso e sintetico il vero problema che il cliente ha e vuole risolvere.

Secondo la mia esperienza, devi risolvere il problema con 2 per risolvere il problema. 1. Drillare fino al problema effettivo significa che tu, lo sviluppatore, ora hai l'input necessario per fare passi da gigante creativi nel risolvere il problema in modi che il cliente stesso non ha mai nemmeno pensato. È probabile che queste soluzioni siano molto più economiche e più veloci rispetto all'implementazione della lista dei desideri completa.

Come lo risolvi?
Come dice Matthew Flynn nella sua risposta, inizia facendo in modo che il cliente dia priorità ai requisiti. Questo non è sempre facile, ma costringili a farlo. Se necessario usa la frase "Se qualcuno ti ha puntato una pistola alla testa, quale requisito singolo vorresti mantenere?". Durante questo processo troverai spesso che il cliente non ha un'idea molto chiara di cosa significano le esigenze individuali. In tal caso, fai ciò che Peter Rowell suggerisce e invita il cliente a lavorare su User Stories. Tu e il cliente inizierete a capire molto meglio il problema e i requisiti, quindi potrete tornare alle priorità. Ripeti questi passaggi tutte le volte che è necessario finché non ti senti a tuo agio che ne sai abbastanza per risolvere il problema del cliente .

In che modo risponde alla domanda sullo sviluppo di una soluzione? Una volta che hai un elenco di requisiti prioritari, hai l'input necessario per suggerire un processo di sviluppo incrementale al tuo cliente. Non è necessario chiamarlo Agile, ma è possibile suggerire di suddividere il contratto in pezzi più piccoli per ogni esigenza (o una serie indivisibile di requisiti) e consegnarli uno per uno con la convalida da parte del cliente. Oppure puoi andare avanti e utilizzare le molte risorse disponibili online e offline per convincere il cliente che è nel loro migliore interesse collaborare in uno degli stili di sviluppo Agile. In ogni caso, è possibile fornire il proprio contratto / proposta di progetto in una forma che suggerisca chiaramente questi elementi costitutivi dei requisiti in ordine di priorità, ciascuno con i propri costi e conclusioni. Tieni quella carota di fronte al cliente e potrebbero anche pensare che fosse la loro idea decidere se continuare dopo l'incremento:).

Per prima cosa proverei a spiegare che i loro requisiti non sono realistici e li presentiamo con una serie di requisiti del contatore. Spiega che questo risolverà il problema più semplicemente e più rapidamente, quindi con minori costi e rischi. Non cercare di trasformare questo in una discussione tecnica, al cliente non importa. Il cliente si preoccupa di ottenere un buon prodotto in tempo, risolvendo il proprio business case. Se il cliente non si muove, accetta il contratto e fa il lavoro, oppure rifiuta e spiega al cliente perché non puoi assumersene la responsabilità per il progetto in questo modulo.

Simile a ciò che gli altri hanno suggerito, ma leggermente diverso, suggerirei che tutto il cliente possa essere valido, ma devono PRIORITIZZARE. Quale elemento deve essere fatto prima. Quale elemento deve essere fatto secondo. Soprattutto, se si esaurisce il tempo, quali elementi farà male il meno non avere. Assegna la priorità a ciascun elemento da 1 a 732 (o qualsiasi altra cosa) e completali in tale ordine.

Un esempio storico di un'applicazione che è finito oltre budget e in ritardo a causa di requisiti eccessivi è il file virtuale del FBI. Doveva sostituire diverse dozzine di applicazioni esistenti, e tutte dovevano lavorare completamente, subito, al passaggio. Il progetto è stato infine cancellato. Quello che avrebbe avuto successo era di progettare un framework e sostituire progressivamente le singole applicazioni nel nuovo sistema. Invece, la politica e le lotte intestine portano a tutti gli stakeholder delle applicazioni che declamano che la loro app è stata la più importante, e tutti hanno sfruttato le loro specifiche con "must have" da tutte le funzionalità che volevano aggiungere all'app esistente. Alla fine, il volume delle richieste di modifica scritte ogni giorno superava la quantità di codice effettivamente scritto ogni giorno.

Ho visto che "Devo avere tutto" funziona in 2 casi. In uno, il grande cliente finanziario (che utilizzava cascata di tutte le cose), aveva 40 sistemi diversi (la nostra azienda ne faceva uno dei 40) per essere sostituito e reso operativo in un colpo solo. Test di integrazione e comunicazione erano enormi problemi. La mia stima è che hanno bruciato circa $ 100.000 al giorno in conference call (quando si conta il tasso di fatturazione di tutti i partecipanti alle chiamate). In entrambi i casi, ci sono voluti forti negoziatori per stilare un elenco di ciò che sarebbe stato consegnato e poi inchiodare tutti i piedi a terra. Non c'è stato alcun movimento dei pali, nessuna rinegoziazione. Entrambi i lavori sono finiti in orario e su specifica. Uno era troppo costoso, l'altro era in bilancio. Per questo avete bisogno di project manager molto bravi che sappiano cosa possono offrire i loro team (il tipo che può dire che Q richiede 3,5 settimane per fare e testare - e sono almeno del 90% accurati nelle promesse di consegna).

Mancando i PM, i negoziatori e le metriche eccellenti, consiglierei di spingere il cliente verso le consegne incrementali. Se vogliono ancora l'intero mattone d'oro in una volta, potrebbero essere meglio serviti aiutandoli a trovare qualche altra consulenza. A volte la risposta migliore è "non possiamo aiutarti".

Risposta breve: vorrei ascoltare il mio cliente e trovare l'approccio di mezzo con loro.

Suggerirei di ascoltare il cliente e, in base al budget e ai tempi, dividere il progetto in fasi (release, release2, ecc.).

Quindi è possibile continuare a stimare ogni fase di deliverable, budget e prioritizzazione delle funzionalità richieste che l'applicazione dovrebbe fornire.

Quindi, definire la portata del lavoro e dei risultati è la strada da percorrere:)

Come indicano altre risposte, la prioritizzazione è molto importante. Un modo pratico per farlo è attraverso il metodo MoSCoW . Ma potresti voler iniziare dividendo l'intera lista, altrimenti l'elenco delle caratteristiche stesso ti darà (o il tuo cliente) dei problemi di comprensione:)

Accanto a questo, hai il problema di considerare il problema nel suo complesso. Probabilmente puoi risolvere questo problema sedendo con il tuo cliente e procedi nel seguente modo:

• Vai a livello globale attraverso le funzioni e distilla le categorie da loro
• Assegna la priorità (usando MoSCoW) alle categorie e magari definisci una gerarchia (una categoria base con caratteristiche predefinite, categorie per le materie principali, categorie per variazioni specifiche dei soggetti principali). Ciò potrebbe alterare le categorie definite nel passaggio precedente (grazie a nuovi approfondimenti).
• Analizza ciascuna funzione una alla volta e assegnale a una categoria
• Assegna la priorità (usando MoSCoW) agli elementi nelle categorie top-x.

Ciò fornirà una vista top-down piacevole e condensata delle funzionalità richieste e fornirà manubri per definire iterazioni diverse per iniziare con una base ed estenderla con altre funzionalità.