Come convincere un cliente non tecnico a semplificare le specifiche dell'applicazione?

Spesso mi trovo di fronte alla situazione in cui un nuovo cliente viene da me con un'applicazione che ha letteralmente centinaia di funzionalità non necessarie ed è abbastanza chiaro che le cose devono essere drasticamente semplificate affinché il progetto abbia qualche possibilità di successo. Come convincere il cliente ad adottare e semplificare un approccio MVP (Minimum Viable Product) più semplice?

modificare:

Quindi l'attuale risposta principale è fornire al cliente una stima del tempo / costo per l'enorme applicazione. Non sono troppo affezionato a questa risposta perché non affronta il vero problema con questa situazione. E cioè: è una cattiva pratica speculare su una massiccia applicazione e poi provare a costruirla fin dall'inizio. Inizialmente mi sento molto più a mio agio nel costruire una base MVP piccola e semplice. E poi aggiungendo piccole funzionalità a quella base una per una. Quindi, come posso convincere il cliente ad avvicinarsi alla costruzione di software in questo modo?

Stimando quanto denaro / tempo ti costerà fare quelle centinaia di funzionalità con alta qualità. Pochissimi clienti metteranno i loro soldi in bocca.

Due parole: storie utente.

Ho imparato che il modo più veloce per aiutare un cliente Get A Clue® è di avere loro mi parlano attraverso una storia utente per ogni funzione o la pagina che vogliono. Accadono diverse cose, tra cui:

1. Devono pensare a cosa diavolo dovrebbe realmente fare la pagina / funzione.
2. Quando chiedi sempre più dettagli ("e poi? ... e poi? ...") iniziano a capire che l'intera cosa non avverrà facendo volare Magic Space Monkeys ™ e farlo nel fine settimana.
3. Diventano veri partner nel processo di creazione. Ciò significa che capiranno perché cambiare idea su qualcosa che è già completo all'80% provocherà a) ritardi di programmazione eb) aumento dei costi.

Sul serio. Le User Story dei proprietari sono uno dei migliori strumenti che conosco per portare almeno un po 'di buonsenso al processo.

Nel discutere l'aspetto dei costi e dei tempi di produzione, chiedi una classifica dei requisiti ("deve avere", "dovrebbe avere" e "bello avere") in modo che l'insieme minimo di funzionalità praticabili del prodotto che sono essenziali siano "must have" nella versione 1, quindi inserire il resto dei requisiti in set di backlog che potrebbero essere realizzati come sprint dopo la prima versione. Si spera che quelli "essenziali da avere" non indispensabili andranno sul retro del pacchetto e quando arriverai a quegli sprint, quelli nuovi che sono più essenziali (dall'esperienza effettiva con il prodotto) saranno passati al vertice.

Il cliente dovrebbe apprezzare che stai considerando il costo della propria attività e l'importanza di ottenere rapidamente il prodotto e non stai eliminando direttamente il suo "bello avere" inserendolo nel backlog.

Modifica per rispondere alla modifica OP: per convincere il cliente del perché è una buona idea rilasciare in anticipo un prodotto minimo realizzabile, spiega che fino a quando il prodotto non viene utilizzato da utenti reali è difficile sapere se avrà successo (soprattutto in termini di usabilità). Se il cliente è riluttante a distribuire un prodotto in anticipo a tutta la sua base di utenti, consiglia di fare una "beta limitata" in cui è disponibile solo per un sottoinsieme mirato dei propri clienti. Di 'loro che il rovescio della medaglia di questo approccio è un lungo e costoso ciclo di sviluppo con una tardiva determinazione che il prodotto è inutilizzabile. 37 Signals ha prodotto un paio di buoni riferimenti a riguardo: diventare reali e rilavorare . Getting Real è disponibile gratuitamente sul Web.

La causa principale della tua frustrazione per la situazione è probabilmente quella della percezione e dei termini fuorvianti / errati utilizzati dal cliente. Il cliente di solito non viene da te con un elenco di requisiti , ma una lista dei desideri di ogni singola cosa a cui potrebbero pensare potrebbe essere utile per loro. Questi non sono tutti requisiti perché il cliente non ha ancora trascorso il tempo a pensare davvero se ogni funzionalità è 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 e reali che ha il cliente, 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 alla fine non avrà successo per il cliente (anche se è un successo finanziario per te come sviluppatore). È anche ad alto rischio perché probabilmente finirai con un progetto a costo fisso con molta incertezza, ed è davvero un problema valutare erroneamente il rischio su grandi progetti.

E se fosse un problema?

Supponiamo che non ti trovi 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 di sviluppo di un elenco così ampio di requisiti, quindi è improbabile che tu ottenga il contratto per la quantità di denaro effettivamente necessaria per farlo.
2. È improbabile che questa lista dei desideri descriva accuratamente e sinteticamente il vero problema che il cliente ha e vuole risolvere.

Nella mia esperienza, devi risolvere il problema 2 per risolvere il problema 1. Analizzare il problema reale significa che tu, lo sviluppatore, ora hai l'input necessario per fare passi da gigante nella risoluzione del problema in modi a cui il cliente stesso non ha nemmeno pensato. È probabile che queste soluzioni siano molto più economiche e veloci rispetto all'implementazione della lista dei desideri completa.

Come lo risolvi?
Come afferma Matthew Flynn nella sua risposta, iniziare dando al cliente la priorità dei requisiti. Questo non è sempre facile, ma costringerli a farlo. Se necessario, usa la frase "Se qualcuno ti tenesse una pistola alla testa, quale requisito unico manterresti?". Durante questo processo, spesso scoprirai che il cliente non ha davvero un'idea chiara del significato dei singoli requisiti. In tal caso, fai ciò che Peter Rowell suggerisce e fai lavorare il cliente attraverso User Stories. Tu e il cliente inizierete a comprendere molto meglio il problema e i requisiti, quindi potrete tornare alla definizione delle priorità. Ripeti questi passaggi tutte le volte che è necessario fino a quando non ti senti a tuo agio da conoscere abbastanza per risolvere il problema del cliente .

In che modo risponde alla domanda sullo sviluppo di una soluzione? Una volta che hai un elenco prioritario di requisiti, hai l'input necessario per suggerire un processo di sviluppo incrementale al tuo cliente. Non devi chiamarlo Agile, ma puoi suggerire di suddividere il contratto in pezzi più piccoli per ogni requisito (o serie indivisibile di requisiti) e consegnarli uno per uno con la convalida da parte del cliente. Oppure puoi fare tutto e usare le molte risorse disponibili online e offline per convincere il cliente che è nel loro interesse collaborare in uno degli stili di sviluppo Agile. In ogni caso, puoi fornire la proposta di contratto / 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 davanti al cliente,

Prima proverei a spiegare poi che i loro requisiti non sono realistici e li presenterei con una serie di contro requisiti. Spiega che ciò risolverà il loro problema in modo più semplice e rapido, quindi con meno costi e rischi. Non cercare di trasformarlo in una discussione tecnica, al cliente non interessa. 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 assumerti la responsabilità del progetto in questo modulo.

Simile a quello che gli altri hanno suggerito, ma leggermente diverso, suggerirei che tutto il cliente possa essere valido, ma devono PRIORITIZZARE. Quale oggetto deve essere fatto per primo. Quale elemento deve essere eseguito per secondo. Soprattutto, se si esaurisce il tempo, quali elementi farà meno male non avere. Dai la priorità a ciascun articolo da 1 a 732 (o qualsiasi altra cosa) e completali in quell'ordine.

Un esempio storico di un'applicazione finita nel budget e in ritardo a causa di requisiti eccessivi è il file del caso virtuale dell'FBI. Doveva sostituire diverse dozzine di applicazioni esistenti e tutte dovevano lavorare completamente, contemporaneamente, al passaggio. Alla fine il progetto è stato cancellato. Ciò che avrebbe avuto successo sarebbe stato progettare un framework e sostituire progressivamente le singole applicazioni nel nuovo sistema. Invece, la politica e le lotte informatiche portano ogni stakeholder delle applicazioni a dichiarare che la loro app era la più importante, e tutti hanno preso 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 "Devo avere tutto" in 2 casi. In uno, il grande cliente finanziario (usando la cascata di tutte le cose), aveva 40 sistemi diversi (la nostra azienda ne ha fatto uno dei 40) sostituiti e resi operativi in ​​un colpo solo. I test di integrazione e la comunicazione erano problemi enormi. La mia stima è che hanno bruciato circa $ 100.000 al giorno durante le chiamate in conferenza (quando si conteggia il tasso di fatturazione di tutti coloro che partecipano alle chiamate). In entrambi i casi, ci sono voluti forti negoziatori per stilare un elenco di ciò che sarebbe stato consegnato e poi inchiodare i piedi a terra. Non ci sono stati spostamenti di pali, nessuna rinegoziazione. Entrambi i lavori sono finiti nei tempi previsti e nelle specifiche. Uno era decisamente al di sopra del budget, l'altro era al budget. Per questo sono necessari ottimi project manager che sanno cosa possono offrire i loro team (il tipo che può dire che la funzione Q richiede 3.

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

Risposta breve: ascolterei il mio cliente e troverei l'approccio intermedio con loro.

Suggerirei di ascoltare il cliente e, a seconda del budget e dei tempi, suddividere il progetto in fasi (release, release2, ecc.).

Quindi è possibile continuare la stima di ogni fase di deliverable, budget e definizione delle priorità delle funzionalità richieste che l'applicazione dovrebbe fornire.

Pertanto, la definizione dell'ambito di lavoro e dei risultati finali è la strada da percorrere :)

Come affermano altre risposte, la definizione delle priorità è molto importante. Un modo pratico per farlo è attraverso il metodo MoSCoW . Ma potresti voler iniziare con la divisione dell'intero elenco, altrimenti l'elenco delle funzionalità stesso ti darà problemi (o il tuo cliente) di comprensione :)

Accanto a questo, hai il problema di guardare il problema nel suo insieme. Probabilmente puoi risolverlo stando seduto con il tuo cliente e procedi come segue:

• Vai a livello globale attraverso le caratteristiche e le categorie di distillazione da loro
• Dai la priorità (usando MoSCoW) alle categorie e forse definisci una gerarchia (una categoria di base con funzioni predefinite, categorie per le materie principali, categorie per variazioni specifiche delle materie principali). Ciò potrebbe alterare le categorie definite nel passaggio precedente (grazie a nuovi approfondimenti).
• Passa attraverso ciascuna funzione una per una e assegnale a una categoria
• Dai la priorità (usando MoSCoW) agli elementi nelle categorie top-x.

Ciò fornirà una vista dall'alto verso il basso piacevole e condensata delle funzionalità richieste e ti darà il manubrio per definire diverse iterazioni per iniziare con una base ed estenderla con altre funzionalità.