Consentire agli utenti di ottenere requisiti da soli o guidarli?

Sono sicuro che tutti hanno sperimentato qualcosa del genere. Vai a un incontro con un cliente che ha un progetto. Non hanno / pochi requisiti in mente e la più vaga comprensione di ciò che vogliono / di cui hanno bisogno. A questo punto, sembrano esserci due opzioni:

1) Di 'agli utenti: "Ok, quindi non posso costruire qualcosa per te se non riesci nemmeno a descriverlo ancora. Perché non torniamo insieme in poche settimane quando sai cosa vuoi".

2) Incontra gli utenti alcune volte e aiutali a capire cosa vogliono guidandoli attraverso il buon metodo Socratic. "Devi tenere traccia di X?", "Che ne dici di Y?", "Hai bisogno della funzionalità Z?"

Con la prima opzione, non ti blocchi nel fare il lavoro di qualcun altro o nel guadagnare poteri psichici, tuttavia, gli utenti potrebbero non presentarti mai una specifica coerente, oppure potrebbero impiegare un'eternità man mano che la scadenza continua ad avvicinarsi. Con la seconda opzione, perdi un sacco di tempo a diventare un analista aziendale e devi racimolare un sacco di conoscenze commerciali nella tua testa che probabilmente non userai mai più, ma avrai molte più probabilità di uscire con una specifica che ha un senso.

Per me, questo è uno degli aspetti più difficili dello sviluppo e ho la sensazione di non essere solo in questo sentimento. Nella tua esperienza, quale di queste opzioni tende a funzionare meglio?

Devo ammettere che a volte scelgo l'opzione 3)

3) Ascolta le idee vaghe dei clienti, imbianca l'idea di passare settimane aiutandole a capire esattamente cosa vogliono ... quindi cerca di capire di cosa hanno bisogno, costruiscile e rifatti come richiesto.

Questo funziona, in particolare per i piccoli lavori, perché aiuta a evitare quelle situazioni in cui i clienti hanno in testa questa idea geniale, che non è pratica nel mondo reale.

Mi succede sempre; "sicuramente potremmo fare ..." è una frase molto spaventosa. Soprattutto perché le cose che vengono menzionate sono quasi sempre le campane, i fischi e la classe di caratteristiche "bello da avere". Non lo capiscono esattamente nell'affermazione "beh, ovviamente un tracker di bug, e poi ..." la maggior parte del lavoro potenziale si basa sulle prime quattro parole.

Quindi, a volte è bello avere una visione dei clienti , applicare una buona dose di buon senso per i programmatori e costruire qualcosa che si adatti alle loro esigenze.

In termini di domanda originale; Trovo che dipenda molto dal contesto. Se bloccato con il cliente (cioè è attraverso un contratto di lavoro a cui sono legato, o non c'è lavoro alternativo), allora # 2 è l'approccio più sano. Altrimenti c'è un'alta probabilità che in una settimana ti verrà presentata una specifica meravigliosa e dettagliata ... che ti è completamente inutile come programmatore.

Più o meno lo stesso problema di cui sopra (n. 3) e uno che ti lascia comunque dover fare il n. 2.

se vuoi essere solo un programmatore, allora aspetti che qualcun altro abbia capito di cosa ha bisogno il client e poi lo codifichi

se vuoi diventare uno sviluppatore , e questo è il tuo cliente, allora prendi la mano del tuo cliente e li percorri delicatamente attraverso la fitta foresta spaventosa di possibilità fino a quando non trovi insieme il felice prato pieno di coniglietti all'intersezione di Wants and Needs.

ADDENDUM: questo processo si chiama "analisi e progettazione dei sistemi", ovvero Consulenza, e non dovrebbe mai essere eseguito gratuitamente

La programmazione riguarda preliminarmente la risoluzione dei problemi degli utenti. Quindi, per me, entrare nello sforzo e nel dolore "extra" al fine di ottenere una soluzione funzionante e soddisfacente per i nostri utenti vince quasi sempre evitando la seccatura "extra" e non consegnando nulla di utile alla fine.

(Certo, ci sono utenti reali là fuori che non hanno davvero idea di cosa vogliano, e nessuno sforzo può portarli in uno stato in cui possono prendere qualsiasi decisione significativa. Ma credo che nella maggior parte dei casi abbiano un vero problema, sono disposti a spendere sforzi e denaro per risolverlo e saranno felici se possiamo aiutarli ad avvicinarsi a una soluzione funzionante.)

Quindi la linea di fondo è, il nostro obiettivo dovrebbe essere quello di risolvere i problemi degli utenti. Questo a volte può richiedere di porre alcune domande mirate e dare loro più tempo per capire le risposte. A volte richiede la creazione di grafici del dominio insieme, in stretta collaborazione. A volte è necessario dedicare un po 'di tempo alla realizzazione di semplici schizzi / prototipi / modelli, quindi mostrare loro il risultato e chiedere "sembra che ciò che avevi in ​​mente?" (poi buttando via il prototipo quando dicono "in realtà, stavo pensando a qualcosa di completamente diverso ..." e ricominciando ... :-)

La vera abilità è nella scelta dell'approccio giusto per il momento giusto.

Ultimo ma non meno importante, nella mia esperienza, le buone soluzioni richiedono quasi sempre una certa conoscenza del dominio da parte dello sviluppatore. Senza questo, non hai un vero linguaggio comune con l'utente, quindi non c'è alcuna garanzia che ciò che fornisci sarà davvero utile per loro. Gli utenti in genere non hanno molto indizio sulla tecnologia, quindi non hanno idea di ciò che è e non è possibile e quale sia il costo di diversi approcci / funzionalità. Dal momento che non possiamo ragionevolmente aspettarci che apprendano la tecnologia con sufficiente dettaglio, dovremmo fare quel passo in più dalla nostra estremità del ponte.

Questo potrebbe essere visto come uno sforzo "extra" che non ripaga - tuttavia, preferisco vederlo come un investimento, per due motivi:

• mi aiuta a fornire buone soluzioni, che a lungo andare aumenta il mio valore di mercato come sviluppatore e
• domini diversi non sono completamente distinti, quindi almeno parte della conoscenza di quel dominio sarà probabilmente riutilizzabile in concerti futuri.

Come sviluppatore di software, parte del tuo compito è acquisire una comprensione sufficiente del dominio in cui verrà utilizzato il software. Pertanto, far parte della fase nascente di un progetto è estremamente prezioso (in termini di tempo ed esperienza del cliente) . Sì, questo significa fare un'analisi approfondita dei requisiti e del dominio. È il momento perfetto per incorporare gli utenti target, intervistarli o passeggiare nel luogo in cui verrà utilizzato il software.

Ma acquisire questa abilità è quasi una forma d'arte, specialmente quando il dominio non è collegato a una disciplina ingegneristica. Le tue ovvie domande possono sembrare scoraggianti per il cliente, la tua presenza in situ potrebbe non essere desiderata, la tua mancanza di comprensione della struttura sociale del tuo pubblico di riferimento potrebbe sgretolare le connessioni ancora fragili.

Non capire la complessità di questa fase porta spesso alla delusione, sia con gli sviluppatori di software, sia con il cliente. Vorremmo superare questa fase sempre più velocemente o eliminarla completamente. I risultati sono spesso disastrosi: dopo l'inizio accelerato, durante lo sviluppo la posta in gioco sta diventando sempre più elevata e diventa sempre più difficile tornare al tavolo da disegno. Quando il sistema è finalmente finito e milioni sono stati spesi, né il cliente, né la società di ingegneria sono disposti ad ammettere il suo fallimento, portando all'introduzione forzata di un sistema guasto.

Un'alternativa è lasciare che un analista aziendale faccia il lavoro per te. Questo potrebbe essere ragionevole per alcuni prodotti e l'analista spesso è in grado di essere un intermediario, ma creerà solo più canali di comunicazione (e quindi una maggiore possibilità di errore).

In ogni caso: riscrivere un pezzo di codice non supera mai riscrivere un pezzo di requisiti.

ps forse pensi che io stia sostenendo il metodo a cascata. Non sono un sostenitore del "grande design iniziale", ma credo che lo sforzo di analisi del dominio dovrebbe essere proporzionato allo sforzo di implementazione. Si possono fare più cicli (prototipo, rilascio candidati, ecc.).

Sicuramente l'opzione 2 a meno che i tuoi utenti non siano sviluppatori (anche in questo caso potrebbe essere necessaria l'opzione 2).

Gran parte dei cicli di vita dello sviluppo software si concentrano sulla raccolta dei requisiti. Non solo la maggior parte degli utenti non sa cosa vuole, ma non sa anche cosa sia possibile, quindi lavorare con l'utente per capire di cosa ha bisogno è un compito fondamentale per lo sviluppo del software.

Penso che tu debba andare con entrambe le opzioni. Lasciali andare e decidi cosa vogliono. Quindi, quando c'è un'idea concreta da utilizzare come punto di partenza, guidali per affinare i requisiti in qualcosa di utile.

Non vuoi saltare all'opzione n. 2 quando riescono a malapena a articolare ciò che vogliono in quanto renderà l'intero processo più lento e frustrante (a meno che non abbiano già un'idea molto chiara di ciò che vogliono quando vengono da te, ma nella mia esperienza questo è molto raro). Falli mettere insieme le loro idee. Invitali a scrivere qualcosa sulla carta, fai descrivere ciò che vogliono in termini di sistemi esistenti, se possibile (es. "Vogliamo un sito web come blahblah.com ma con queste differenze ... vogliamo uno strumento che faccia Task A come Prodotto X , ma l'interfaccia utente deve anche eseguire l'attività B ... "). Quindi è un buon momento per iniziare a perfezionare ciò che vogliono in requisiti molto specifici che è possibile utilizzare per costruire il sistema.

In generale, i clienti verranno da te sapendo esattamente di cosa pensano di aver bisogno. Sfortunatamente, questo è ciò che ti diranno, invece di descrivere i problemi che portano alla soluzione che pensano che fornirai.

Per progettare qualcosa che soddisfi le loro esigenze, è necessario identificare tali esigenze e, per farlo, qualcuno dovrà tenere premuto il cliente ed estrarre tali esigenze. Se nessun altro può farlo, allora devi farlo. (Se qualcun altro pensa di poterlo fare, potresti doverti sedere con loro ed estrarre i bisogni reali in seguito ...)

Con l'opzione 2, durante un certo numero di riunioni, si spera che si possa formare il cliente a condividere problemi con te piuttosto che con soluzioni. (Anche se il cliente ha capacità tecniche - ad esempio, non ha disponibilità a fare questo lavoro e ha invece bisogno che tu lo faccia - potrebbe comunque concentrarsi su un'implementazione che non è l'ideale per il cliente finale.) importa molto quale processo di sviluppo utilizzi, dovrai comunque andare avanti e indietro alcune volte fino a quando non potranno rispondere alle domande in modo da definire le specifiche per te.

Ricorda che vuoi rilevare i difetti il ​​più presto possibile nel ciclo di sviluppo. Se riesci a catturarli durante i requisiti piuttosto che durante la codifica o i test, ti risparmierai molto tempo.

L'opzione 1 è un modo eccellente per evitare di lavorare. L'ho usato quando credevo che il lavoro fosse inutile o avevo cose più importanti da fare.

Innanzitutto, gli utenti non sanno cosa possono fare i computer. La maggior parte di noi ha trascorso anni a imparare a comprendere i computer e il calcolo, e ciò che è ovvio per noi potrebbe non essere facilmente comprensibile per qualcuno che ha trascorso quegli anni a imparare altre cose.

In secondo luogo, gli utenti non sanno necessariamente di cosa hanno bisogno e di solito non sanno quello che vogliono, in alcun senso attuabile.

Per fare un'analogia, quando ho comprato la mia attuale casa, un designer d'interni ha selezionato i colori delle pareti per le stanze del piano principale (primo piano negli Stati Uniti, Regno Unito). Non avrei mai scelto quei colori da solo. Volevo una casa che stesse bene e l'ho presa. Se il designer mi avesse ascoltato e mi avesse dato tutto ciò che potevo articolare, non sarebbe uscito altrettanto bene.

L'unico modo per dare agli utenti qualcosa che fa ciò di cui hanno bisogno nel modo che preferiscono è lavorare con loro da soli.