Requisiti per convincere gli uomini d'affari?

Quali metodi sembrano funzionare meglio per convincere i requisiti degli uomini d'affari non tecnologici? Sto lavorando con un team che sta cercando di mettere insieme una specifica per un progetto. Ogni volta che ci siamo incontrati e si riduce alle aspettative per il prossimo incontro, chiediamo agli uomini d'affari di riportare le loro esigenze. Di solito rispondono in questo modo: "Bene, pensi che potreste montare un prototipo in modo che possiamo vedere quello che ci piace la prossima settimana ... lo sapete, non con alcun dato o niente dato che è un prototipo, solo la funzionalità." è un progetto di oltre 6 mesi, quindi è ovviamente impossibile (dovremmo sviluppare l'intera cosa!), e non sappiamo nemmeno cosa prototipare senza una sorta di specifica. Francamente, penso come la maggior parte delle persone, hanno qualche idea di ciò che vogliono, semplicemente non ci stanno pensando nel modo mirato necessario per raccogliere i veri requisiti. In alternativa al semplice dire loro, "Dacci quello che vuoi o non possiamo / non faremo alcun lavoro" (vogliamo che siano soddisfatti dei risultati), ci sono modi per aiutarli a decidere cosa vogliono? Ad esempio, potremmo dire loro:

“Disegna alcune schermate (in Powerpoint, su un tovagliolo, qualunque cosa) che mostrano l'interfaccia utente che desideri con tutti i dati che vuoi vedere e una descrizione della funzionalità a margine. Da questo, lo perfezioneremo e costruiremo il backend in base a questo insieme di requisiti comportamentali. "

O

“Non preoccuparti di come apparirà in questo momento (il numero 1 si blocca). Forniscici un elenco di tutti i dati che desideri su ogni cosa di cui il programma tiene traccia. Quindi per "Cliente" potresti elencare: nome, indirizzo, numero di telefono, ordini, ecc. Non deve essere una struttura di database perfetta, ma possiamo capire qualcosa da ciò e avere un'idea di ciò che stai cercando "

Uno di questi approcci alternativi per focalizzare gli uomini d'affari su ciò che vogliono ha senso? Ci sono alternative che hai visto in azione?

Ho trascorso gli ultimi 3 mesi in una fase esaustiva - ed estenuante - di raccolta dei requisiti di un grande progetto e ho appreso, soprattutto, che non esiste una soluzione unica per tutti . Non esiste alcun processo, nessun segreto, che funzionerà in ogni caso. L'analisi dei requisiti è un'abilità genuina e proprio quando pensi di aver finalmente capito tutto, ti esponi a un gruppo completamente diverso di persone e devi buttare tutto ciò che conosci dalla finestra.

Diverse lezioni che ho imparato:

• Diverse parti interessate pensano a diversi livelli di astrazione.

  È facile dire "parlare a livello aziendale, non tecnico", ma non è necessariamente così facile da fare . Il sistema che stai progettando è un elefante e i tuoi stakeholder sono i ciechi che lo esaminano . Alcune persone sono così profondamente immersi nel processo e di routine che non si rendono nemmeno conto che ci sia un business. Altri possono lavorare al livello di astrazione che desideri, ma essere incline a fare affermazioni esagerate o addirittura false, o impegnarsi in un pio desiderio.

  Sfortunatamente, devi semplicemente conoscere tutti gli individui come individui e capire come pensano, imparare a interpretare le cose che dicono e persino decidere cosa ignorare.

• Dividere e conquistare

  Se non vuoi che qualcosa venga fatto, invialo a un comitato.

  Non incontrarti con i comitati. Mantenere tali riunioni il più piccolo possibile. YMMV, ma nella mia esperienza, la dimensione ideale è 3-4 persone (incluso te stesso) per sessioni aperte e 2-3 persone per sessioni chiuse (cioè quando hai bisogno di una risposta specifica alla domanda).

  Cerco di incontrare persone che hanno funzioni simili nel settore. C'è davvero molto poco da guadagnare e molto da perdere lanciando la gente di marketing nella stanza con i contatori di fagioli. Cerca le persone che sono esperte in una materia e inducile a parlarne.

• Un incontro senza preparazione è un incontro senza scopo.

  Un paio di altre risposte / commenti hanno fatto riferimento alla tecnica del pagliaccio, che è eccellente per quelle persone problematiche da cui non riesci proprio a ottenere alcuna risposta. Ma non si basano su di paglia uomini troppo tanto, o la gente altro inizierà a sentire come li stai railroading. Devi spingere delicatamente le persone nella giusta direzione e lasciare che vengano loro stessi i dettagli, in modo che si sentano come loro proprietari (e in un certo senso, li possiedono).

  Quello che devi avere è una sorta di modello mentale di come pensi che funzioni il business e come dovrebbe funzionare il sistema . Devi diventare un esperto di dominio , anche se non sei un esperto della specifica azienda in questione. Fai quante più ricerche possibili sulla tua attività, sui loro concorrenti, sui sistemi esistenti sul mercato e su qualsiasi altra cosa che potrebbe anche essere collegata in remoto.

  Una volta a quel punto, ho trovato più efficace lavorare con costrutti di alto livello, come i casi d'uso, che tendono ad essere graditi a tutti, ma è ancora fondamentale porre domande specifiche. Se inizi con "Come fatturare i tuoi clienti?" , stai per un incontro molto lungo. Poni domande che implicano un processo invece di precisare il processo al via: quali sono gli elementi pubblicitari? Come vengono calcolati? Quanto spesso cambiano? Quanti diversi tipi di vendite o contratti ci sono? Dove vengono stampati? Ti viene l'idea.

  Se ti manca un passaggio, qualcuno te lo dirà di solito. Se nessuno si lamenta, allora concediti una pacca sulla spalla, perché hai implicitamente confermato il processo.

• Rimanda le discussioni fuori tema .

  In qualità di analista dei requisiti, ricopri anche il ruolo di facilitatore e, a meno che non ti piaccia davvero passare tutto il tuo tempo alle riunioni, devi trovare un modo per tenere traccia delle cose. Ironia della sorte, questo problema diventa più pernicioso quando finalmente fai parlare le persone. Se non stai attento, può far deragliare il treno per cui hai trascorso così tanto tempo a posare i binari.

  Tuttavia - e l'ho imparato nel modo più duro molto tempo fa - non si può semplicemente dire alla gente che un problema è irrilevante . È ovviamente rilevante per loro , altrimenti non ne parlerebbero. Il tuo compito è far sì che la gente dica "sì" il più possibile e creare una barriera del genere ti faccia cadere nel territorio "no".

  Questo è un delicato equilibrio che molte persone sono in grado di mantenere con "elementi di azione" - sostanzialmente una coda generica di discussioni a cui hai promesso di tornare a volte , normalmente etichettata con i nomi di quelle parti interessate che pensavano che fosse davvero importante. Questo non è solo per il bene della diplomazia, è anche uno strumento prezioso per aiutarti a ricordare cosa è successo durante le riunioni e con chi parlare se hai bisogno di chiarimenti in seguito.

  Diversi analisti gestiscono questo in diversi modi; alcuni come la lavagna molto pubblica o il registro di lavagna a fogli mobili, altri lo inseriscono silenziosamente nei loro laptop e seguono delicatamente altri argomenti. Qualunque cosa ti senta a tuo agio.

• Hai bisogno di un ordine del giorno

  Questo è probabilmente vero per quasi ogni tipo di riunione, ma è doppiamente vero per le riunioni dei requisiti. Mentre le discussioni continuano, le menti delle persone iniziano a vagare e iniziano a chiedersi quando arriverai alle cose a cui tengono davvero. Avere un'agenda fornisce una struttura e ti aiuta anche a determinare, come menzionato sopra, quando è necessario rinviare una discussione che sta diventando fuori tema.

  Non entrare lì senza avere una chiara idea di cosa esattamente vuoi coprire e quando . Senza questo, non hai modo di valutare i tuoi progressi e gli utenti ti odieranno per sempre correndo a lungo (supponendo che non ti odino già per altri motivi).

• Deridilo

  Se usi PowerPoint o Visio come strumento di simulazione, soffrirai del problema che sembra troppo lucido . È quasi una valle misteriosa di interfacce utente; le persone si sentiranno a proprio agio con i disegni di tovaglioli (o disegni generati dal computer che assomigliano a disegni di tovaglioli, usando uno strumento come Balsamiq o Sketchflow ), perché sanno che non è la cosa reale - lo stesso motivo per cui le persone sono in grado di guardare personaggi dei cartoni animati. Ma più inizia a sembrare una vera interfaccia utente, più le persone vorranno prenderla in considerazione, e più tempo passeranno a discutere di dettagli che alla fine sono insignificanti.

  Quindi fai sicuramente dei modelli per testare la tua comprensione dei requisiti ( dopo le fasi iniziali dell'analisi) - sono un ottimo modo per ottenere feedback molto rapidi e dettagliati - ma mantienili in streaming e non affrettarti a prendere in giro fino a quando ' sei abbastanza sicuro di vedere gli occhi dei tuoi utenti.

  Tieni presente che un modello non è un risultato , è uno strumento per aiutare a capire. Proprio come non ti aspetteresti di essere tenuto prigioniero del tuo finto quando esegui il design dell'interfaccia utente, non puoi presumere che il design sia OK semplicemente perché hanno dato al tuo mock-up il pollice in su. Ho visto le beffe usate come stampella, o peggio, una scusa per eludere completamente i requisiti; assicurati di non farlo. Torna indietro e trasforma quella derisione in un vero insieme di requisiti.

• Essere pazientare.

  Questo è difficile da credere per molti programmatori, ma per la maggior parte dei progetti non banali, non puoi semplicemente sederti una volta e mettere a punto una specifica funzionale completa. Non sto solo parlando di pazienza durante un singolo incontro; l'analisi dei requisiti è iterativa allo stesso modo del codice. Il gruppo A dice qualcosa e poi il gruppo B dice qualcosa che contraddice totalmente ciò che hai sentito dal gruppo A. Quindi il gruppo A spiega l'incoerenza e risulta essere qualcosa che il gruppo C ha dimenticato di menzionare. Ripetere 500 volte e hai qualcosa di più o meno simile verità .

  A meno che tu non stia sviluppando qualche piccola app CRUD (nel qual caso perché preoccuparsi dei requisiti?), Quindi non aspettarti di ottenere tutto ciò di cui hai bisogno in una riunione, o due o cinque. Ascolterai molto, parlerai molto e ti ripeterai molto. Che non è una cosa terribile, intendiamoci; è un'opportunità per costruire un rapporto con le persone che inevitabilmente firmeranno il tuo risultato.

• Non aver paura di cambiare la tua tecnica o improvvisare.

  Diversi aspetti di un progetto possono effettivamente richiedere diverse tecniche di analisi. In alcuni casi il classico UML (Usa diagramma caso / attività) funziona alla grande. In altri casi, potresti iniziare con i KSI aziendali, o fare brainstorming con una mappa mentale o tuffarti subito nei modelli nonostante il mio avvertimento precedente.

  La linea di fondo è che devi capire tu stesso il dominio e fare i compiti prima di perdere altro tempo. Se sai che un determinato reparto o componente ha un solo caso d'uso, ma è follemente complicato, salta l'analisi del caso d'uso e inizia a parlare di flussi di lavoro o flussi di dati. Se non utilizzi lo stesso strumento per ogni parte dell'implementazione di un'app, perché dovresti usare lo stesso strumento per ogni parte dei requisiti?

• Tieni l'orecchio a terra.

  Di tutti i suggerimenti e i suggerimenti che ho letto per l'analisi dei requisiti, questo è probabilmente quello che viene trascurato più di frequente. Sinceramente penso di aver imparato di più a intercettare e occasionalmente a interrompere conversazioni più fresche di quelle che ho avuto dalle riunioni programmate.

  Se sei abituato a lavorare in isolamento, prova a trovare un punto in cui l'azione è in modo da poter ascoltare le chiacchiere. Se non ci riesci, fai solo giri frequenti, in cucina o in bagno o ovunque. Scoprirai tutti i tipi di cose interessanti su come l'azienda opera realmente ascoltando ciò di cui le persone si vantano o si lamentano durante le pause caffè e fumo.

• Infine, leggi tra le righe .

  Uno dei miei più grandi errori in passato è stato quello di essere così concentrato sul risultato finale che non mi sono preso il tempo di ascoltare veramente quello che la gente stava dicendo . A volte, per la maggior parte del tempo, potrebbe sembrare che la gente non stia blaterando per nulla o si arrabbia per qualche procedura che ti sembra del tutto inutile, ma se ti concentri davvero su ciò che stanno dicendo, ti renderai conto che c'è davvero un requisito sepolto lì dentro - o diversi.

  Per quanto banale e insipido come sembra, il Five Whys è una tecnica davvero utile qui. Ogni volta che hai quella reazione "che è stupida" (non che lo diresti mai ad alta voce), fermati e trasformalo in una domanda: perché? Perché queste informazioni vengono riscritte quattro volte, quindi stampate, fotocopiate, scansionate, stampate di nuovo, appuntate su un pannello truciolare, scattate con una fotocamera digitale e infine inviate via e-mail al responsabile delle vendite? V'è una ragione , e non può sapere di cosa si tratta, ma è il vostro lavoro per scoprirlo. Buona fortuna. ;)

Se non riesci a ricavarne qualcosa, scrivi qualcosa e fallo approvare. È molto più facile per le persone non tecniche dire "no, non mi piace" di "questo è il modo in cui dovresti farlo".

Spesso ciò che vogliono e ciò che ti dicono sono due cose molto diverse. Prenditi del tempo per scrivere una prima bozza delle specifiche con le informazioni che conosci attualmente. Chiedi alle parti interessate di leggerlo e approvarlo. Quando lo leggono, molto probabilmente vedranno cose che non gli piacciono o con cui sono d'accordo. Ottieni il loro feedback e poi rivedi.

Se c'è qualcosa su cui puoi andare in un modo o nell'altro, online entrambe le opzioni e fai decidere al decisore. Non lasciarli soli finché non lo fanno.

Per quanto riguarda i prototipi, crea modelli di schermate e spiega come funzionano le cose. Ancora una volta, vedere qualcosa li aiuta a visualizzare ciò che sta accadendo. Porta con te nuovi modelli di schermate alle riunioni e ottieni risposte.

In passato, ho effettivamente aperto FireBug e aggiunto la modifica che il cliente aveva richiesto proprio davanti a loro in modo che potessero vedere come sarebbe stato. Hanno dato il loro feedback, ho preso una schermata e poi implementato le modifiche. A loro è piaciuto molto poter vedere come sarebbe stato il cambiamento, e mi è piaciuto perché era veloce e ho avuto la mia risposta in quell'incontro ... non il prossimo.

Fagli parlare più delle loro attività e meno delle applicazioni. Scopri quali sono i veri problemi: i report di fine mese richiedono troppo tempo, errori di immissione dei dati, hanno superato la loro attuale applicazione, la crescita dell'azienda sta sfuggendo di mano.

Immagino che questi incontri siano con le persone che effettuano gli acquisti, ma non con quelle che faranno effettivamente il lavoro che coinvolge l'applicazione. Chiedi se puoi incontrare alcune di queste persone. Possono mostrarti come sono fatte veramente le cose. Assicurati di avere a che fare con clienti che hanno preventivato il proprio tempo e il costo.

Verifica se hanno rapporti che stanno attualmente utilizzando o che desiderano utilizzare. Ovviamente non puoi creare il rapporto se non raccogli i dati correttamente. Devono fare qualcosa a meno che questa non sia una linea di attività che non hanno ancora avviato.

Molti hanno queste nozioni generali che tu sei il programmatore, quindi sai come costruire tutti i programmi. I siti di e-commerce sono tutti uguali, giusto?

Inizia in piccolo. Sfortunatamente, finché non ottieni qualcosa di fronte a loro, il processo non si registra. Se non hai niente da fare, allora falla finta.

Molto di tutto ciò ha a che fare con le abilità interpersonali generiche e il modo in cui comunichi con il cliente in primo luogo. Non c'è molto che io possa dire a riguardo, oltre - assicurati di spiegare il processo come interattivo, in cui ti aspetti anche feedback e sforzi da parte dei clienti.

In particolare per lo scenario che hai descritto, ecco alcuni altri consigli: Inizia descrivendo ciò che potresti trovare utile avere e fornisci i veicoli per descrivere le informazioni in termini che non richiedono specializzazione tecnica o know-how:

• Storie di utenti / casi d'uso Chiedere descrizioni dettagliate di ciò che gli utenti si aspettano di fare, di quali informazioni hanno bisogno per farlo, e che cosa si deve e possono aspettarsi che gli utenti inseriscano se stessi. Una volta che hai queste informazioni, passaci sopra con loro e assicurati che tutto sia coperto di storie - non dovrebbe esserci nulla che andrà nell'applicazione, dove non ci sono storie che riguardano ciò che l'utente farà lì.

• Dimostrazioni convincenti Cosa è più importante per conquistare i clienti? Quali parti del programma o funzionalità devono distinguersi e devono essere completamente lucidate? Potete fornirmi una demo di modello, usando post-it note o scatole di cartone o altri stand-in, su cui vorreste lavorare?

• Informazioni sul mercato / sulla concorrenza Per ogni user story, cosa stiamo facendo che è simile ai nostri concorrenti? Diverso? Quale storia raccontano i nostri concorrenti e stiamo cercando di copiare / emulare / migliorare / innovare / essere intenzionalmente diversi?

• Domande aperte Che cosa sono i requisiti e il design delle informazioni di cui sei certo e che cos'è un esperimento? Dove cercheremo delle alternative per vedere quale funziona? Se stai cercando più alternative e ce ne hai detto solo una, quali sono le altre che stai considerando?

Quindi, disegna alcuni limiti:

• Per favore, non porre restrizioni tecniche su di me . Un uomo d'affari non dovrebbe dirti "usa Windows perché è meglio di Linux". Possono, tuttavia, fornire istruzioni sulla falsariga di "tutto il nostro mercato di destinazione utilizza Windows, la nostra applicazione dovrà funzionare su Windows per avere successo"

• Non preoccuparti del design Soprattutto se hai a che fare con persone orientate alla vendita o al marketing, tenderanno a impantanarsi con problemi di design. Ancora una volta, restringere il campo di applicazione delle informazioni a ciò in cui sono specializzati: "qui il blu è più bello" probabilmente non è appropriato. "Il nostro concorrente utilizza un tema di colore blu, ed è in circolazione dagli anni '80, per parti del nostro programma in cui non stiamo innovando, dovremmo usare uno schema blu per comunicare che non siamo nuovi", probabilmente è appropriato. "Il nome dovrebbe essere nella parte superiore dello schermo" probabilmente non è appropriato, ma "le informazioni più importanti in questa pagina sono il nome dell'utente e il saldo del conto bancario", probabilmente lo è. Assicurarsi che un designer sia coinvolto nella traduzione di questi requisiti in un'interfaccia utente.

• Annota le decisioni Preferibilmente incorporale in contratti o altri impegni assunti. Ricorda, tuttavia, che una decisione che il cliente non comprende, non vale la carta su cui è scritta. Un cliente che si disconnette su "l'applicazione verrà eseguita sulla porta 1521" non vale quanto il cliente che si disconnette su "l'applicazione verrà eseguita su una porta personalizzata, configurabile, che può richiedere una configurazione speciale per firewall e sicurezza quando viene distribuita "

Dal tuo punto di vista, al fine di incoraggiare il processo a continuare:

• Fornire feedback allo stesso livello di astrazione Questo è generale, ad esempio per le unità: se il cliente parla di un volume mensile di utenti, non rispondere in gigabit di larghezza di banda. Oppure, per i casi d'uso: descrivere la funzionalità in termini di casi d'uso funzionanti, piuttosto che moduli o correzioni di bug o funzionalità.

• Fornisci una comunicazione significativa Frase le domande che hai e le informazioni aggiuntive che hai scoperto o che stai cercando, in termini di informazioni che ti sono state fornite. "Andiamo con Linux" è probabilmente un feedback scritto male, mentre "i nostri test mostrano che l'applicazione funziona in modo più fluido quando è ospitata su macchine Linux e vi si accede con IE su Windows" potrebbe essere più appropriata.

• Iterazione rapida Per mantenere attivo il client, fornire aggiornamenti e iterazioni rapidi e significativi. Le specifiche e le informazioni che non erano disponibili o facili da ottenere all'avvio del processo possono richiedere molto impegno da parte del cliente, che probabilmente ti sta pagando, mentre non le stai pagando per nessuno dei loro lavori. Far coinvolgere e investire il cliente nel processo può aiutare quando il lavoro finisce per essere qualcosa su cui devono trascorrere tempo e fatica.

I tuoi clienti, gli uomini d'affari, potrebbero avere qualche tipo di problema, desiderare una sorta di soluzione tecnica, ma hanno una piccola idea di come potrebbe funzionare la soluzione e quindi hanno una piccola idea di come specificare qualsiasi potenziale soluzione. In tal caso, il ruolo mancante è quello di un analista di soluzioni aziendali, che può studiare il cliente, i suoi problemi, i suoi flussi di lavoro, ecc. E in che modo tutte le possibili soluzioni potrebbero adattarsi alle loro procedure aziendali, cultura, ecc., Nonché se una soluzione particolare potrebbe essere fattibile per attuare in tempo, sotto budget, ecc. Questo potrebbe essere un ruolo altamente interdisciplinare, che richiede una certa conoscenza di entrambe le pratiche commerciali (diritto, contabilità, logistica, ecc.), psicologia degli utenti, nonché tecnologia del software.

Sembra che tu voglia costringere il cliente ad essere il proprio analista di soluzioni aziendali. Questo potrebbe non essere un ruolo in cui hanno abbastanza esperienza per garantire una specifica ragionevole. E sembra che tu non voglia assumere questo ruolo. Se né tu, né il tuo cliente avete le competenze per ricoprire questo ruolo, potreste non avere tutte le persone necessarie per un progetto di successo.

A volte un gruppo di prototipi rapidi con cui il cliente può giocare potrebbe essere l'unico modo per scoprire e convergere sperimentalmente una sorta di soluzione utilizzabile per le esigenze del cliente (espresse e non espresse). Questo può o non può essere adatto a qualsiasi tipo di contratto a tempo indeterminato.

AGGIUNTO: Se si tenta di forzare un documento di requisiti ai clienti che non dispongono delle competenze necessarie, potrebbe trattarsi di un'enorme bandiera rossa che indica un disastro in arrivo.

Non richiedere requisiti di interfaccia utente o dati, richiedere requisiti di funzionalità.

Chiedi loro cosa vogliono fare l'applicazione. Invitali a capire come vorrebbero usare l'applicazione. Per iniziare, lascia fuori dettagli come l'interfaccia utente, i dati, ecc.

Ho scoperto che spesso gli utenti non sanno cosa vogliono in termini di interfaccia utente o dati, ma sanno cosa vogliono per quanto riguarda la funzionalità. Ad esempio, mi diranno "Voglio accedere e vedere tutte le informazioni sul cliente". Non entrare nell'aspetto delle schermate o dei dati che desiderano, basta ottenerne le funzionalità.

Una volta che lo hai fatto, fai un mockup veloce (mi piace Balsamiq ). Supponi solo quale sarà l'interfaccia utente / i dati e non dedicare molto tempo ad esso. Quindi riporta quel modello al Cliente. Da lì, possono dirti "non abbiamo bisogno di questi campi" o "In realtà vogliamo un elenco di numeri di telefono, non solo uno", oppure "questo dovrebbe essere un menu a discesa, non una casella di riepilogo".

Una volta che hai il punto di partenza, è molto più semplice definire dati e interfaccia utente e trovo che determinare la funzionalità sia il miglior punto di partenza.

Ti suggerisco di provare a focalizzarli innanzitutto sui processi aziendali. Fai in modo che definiscano, in un documento o in una discussione, come svolgono attualmente le attività che verranno gestite dal tuo software. Quindi concentrati sulle parti del processo che vorrebbero vedere modificate (il motivo per cui desiderano il tuo software). Usalo come punto di partenza per discutere su quali altre parti del processo potrebbero essere migliorate, o addirittura rimosse del tutto, usando il tuo software.

Se il cliente non è abituato a fornire i requisiti software, il team dovrebbe redigere i requisiti per essi. Aspettatevi di passare attraverso più revisioni, ma dovreste almeno fornire loro un documento iniziale per aiutare a comunicare ciò che state cercando.

Dopo aver avuto una buona idea dei requisiti funzionali del processo del risultato finale atteso che includerà il tuo software, puoi iniziare a redigere modelli di interfacce. Se vuoi prima lasciarli fare una pugnalata, puoi farlo, ma di solito stai meglio fornendo le idee iniziali e lasciandole modificare. Non è necessario il codice funzionale per questo. Schermate di UI in fase di sviluppo, rappresentazioni HTML dei layout utilizzando testo di riempimento statico o persino disegni (se si dispone di un artista decente nello staff) potrebbero essere utilizzate per le discussioni iniziali dell'interfaccia utente.

Dopo aver superato un paio di revisioni e tutti sono d'accordo con ciò che viene presentato, ottenere l'approvazione del cliente per iscritto! Non importa quanto resistano, questo passaggio è cruciale. Potrebbe essere necessario rassicurarli sul fatto che approvare i requisiti non significa che non possano avere ulteriori input nel progetto (a seconda della natura della relazione con il cliente), nel qual caso è necessario delineare come le revisioni ai requisiti verrà gestito (ad es. soggetto a revisione e approvazione, trasferito a una versione successiva, valutato separatamente come miglioramento, ecc.).

Vorrei dire loro che svilupperai la funzionalità del programma per funzione. Fino a un prossimo incontro, supponiamo che in 1-2 settimane lavorerai X numero di funzioni. Potrebbe essere 1, 2, 3 o più.

Supponi che inizierai sviluppando prima la funzionalità più importante. È necessario iniziare con le funzionalità principali. Diciamo che stai costruendo un bancomat (per ragioni di discussione). Diglielo, ok, il primo (o il prossimo) nell'elenco delle funzionalità più importanti è chiedere la data di nascita dell'utente come conferma quando si effettua un prelievo di grandi dimensioni (sostituire una funzionalità del tuo progetto che sai non è una delle principali funzionalità principali che sarà implementato successivamente).

Questa ingenua affermazione dovrebbe suscitare una reazione da parte del cliente. Quando chiederà loro cosa farebbero dopo? Qual è la caratteristica più importante che non è stata ancora fatta sul progetto e migliore di quella che hai menzionato.

Riutilizzando l'esempio precedente il cliente potrebbe dirti che sta convalidando la carta dell'utente o sta effettuando depositi, ecc. Quindi chiedi loro di definirlo per te. Non abbiate paura di fare molte domande, anche ingenue domande se necessario.

Dopo aver discusso di questo con il cliente, dovresti avere alcuni requisiti per questo pezzo di funzionalità. Potresti definire più di un pezzo di funzionalità ma vorrei mantenere il numero molto basso.

In 1-2 settimane si incontrano di nuovo con il cliente per presentare loro ciò che hai fatto e ottenere il loro contributo. Presentalo al cliente e ottieni il suo input se qualcosa deve essere modificato o aggiunto.

Quindi ripetere l'esercizio precedente per il prossimo gruppo di funzioni. Continua con questo processo in modo iterativo per il resto del progetto, assicurandoti di rimanere in contatto con il cliente e di incontrarti a intervalli regolari per mostrare il tuo lavoro e pianificare ciò che verrà fatto successivamente (rimanendo sempre con piccoli pezzi).

Stai parlando di ingegneria e non gliene importa nulla, nella mia esperienza; inoltre non vogliono impegnarsi a fare nulla (specialmente per iscritto) e non vogliono davvero fare alcun lavoro, anche se questo non è particolare per i tipi di attività - nessuno vuole fare un sacco di lavoro in un dominio che loro non lo so e non mi interessa saperlo. Questo è il tuo lavoro (nelle loro menti).

Quello che faccio è questo: parlare con loro di ciò che vogliono, nella loro lingua di dominio. Essi non saranno in grado o disposti a essere precisi il modo in cui avreste potuto sperare (casi d'uso, design per contratto, ecc), ma si può essere precisi nel tradurre il loro tipo di lista vaga e ventilata di desiderata in progettazione vera e propria, e , di conseguenza, un documento di progettazione. Se ti stanzeranno il tempo per farlo formalmente, tanto meglio. In caso contrario, creane uno estemporaneo, informale, su cui puoi iterare.

Questa non è una risposta super felice, lo so, ma ho trovato la vita più facile quando ho smesso di cercare di convincere i clienti (o chiunque, davvero) ad entrare nel mio universo e parlare la mia lingua. Anche se finisco per porre sempre le stesse domande quando arrivo a patti con il dominio e i requisiti (che spesso sono solo vagamente compresi dal cliente) la cosa controintuitiva è che le discussioni non sono frustranti. In effetti, le relazioni con i clienti tendono a rafforzarsi, suppongo perché alla gente piace parlare di ciò che sanno, e finisci per capire il loro POV in modo più tondo di quanto potresti se lasciato ad un approccio progettuale più rigoroso.

Senza un manager che sa qualcosa di programmazione non ho mai avuto un po 'di successo in questo. Piuttosto, l'unico approccio che ho scoperto che funziona è osservare ciò che sta realmente accadendo.

Immagino che i programmatori abbiano una migliore capacità di immaginare come sarà un programma prima che sia costruito. La prototipazione della carta può essere una tecnica efficace per ovviare a questo. I prototipi di carta sono relativamente "economici" da costruire. Guidando i tuoi clienti attraverso un semplice prototipo cartaceo, dimostri la necessità di pensare "nel modo mirato necessario per raccogliere i veri requisiti". E offre un modo specifico per concentrarsi: in realtà provare a utilizzare l'applicazione che hai in testa!

Inoltre, puoi scorrere molto rapidamente dalla tua ipotesi migliore di ciò che il client desidera sull'applicazione che il client desidera veramente, ma ha difficoltà a trasmettere. È più facile guardare un prototipo e decidere perché non corrisponde all'applicazione ideale nella tua testa piuttosto che elencare tutti i requisiti di tale applicazione.

Ho lavorato su un sito Web in cui gli altri partner erano più orientati al business. Continuavo a chiedere requisiti specifici in molti modi diversi. La loro risposta è stata sostanzialmente: "Sei il ragazzo del computer, ci aspettiamo che tu capisca queste cose. Preferiamo fare le cose di affari". Non si occupavano dei dettagli specifici ... fino a quando non fu rilasciata la prima versione! Erano molto più entusiasti dei requisiti dopo il rilascio, fornendo ogni tipo di feedback che mi avrebbe risparmiato un sacco di tempo in anticipo quando avevo chiesto inizialmente.

Quindi ho deciso che l'iterazione è la chiave: costruire la versione minima possibile e migliorarla in base al feedback. Se i requisiti sono troppo vaghi e generali, prendere decisioni sulla base di "Qual è l'implementazione più semplice e veloce?" (salvo la progettazione / architettura di sistemi fondamentali). Non pesare troppo su ipotesi basate su ciò che pensi sia "giusto". Finirà solo per perdere tempo perché è molto probabile che il tuo processo di pensiero sia diverso dai tuoi clienti.

Ad esempio: il client richiede la funzione di caricamento delle immagini; non elabora requisiti più specifici. Costruiscilo nel modo più ingenuo possibile. Anche se pensi che sia ciò che il cliente vorrà, non aggiungere funzionalità di ritaglio, ridimensionamento e anteprima automatiche. Consenti al client di vedere la versione minima realizzabile (che puoi sviluppare molto più velocemente rispetto alla versione non ingenua) e i requisiti inizieranno a fluire come "Questo è ciò che non va nella versione corrente". Registra ciascuno di questi nuovi requisiti come "bug". Puoi stabilire le priorità in base a quali sono le più facili / le più vantaggiose.

In realtà mi è successo: richiesta di modulo di iscrizione con un codice di invito speciale. L'idea era quella di creare un processo di registrazione virale in cui ogni nuovo utente riceveva alcuni inviti. Ho trascorso molto tempo a garantire che i codici fossero univoci e che potessero essere utilizzati solo una volta. Ho anche fatto molti sforzi per rendere il processo il più semplice possibile, rendendo facoltativi i campi del nome e del cognome. Alla fine, i partner hanno chiesto queste modifiche: nome e cognome obbligatori, iscrizione "codice" valida se qualcosa è stato inserito nel campo ... sigh ~