Consenti agli utenti di ottenere i requisiti da soli o guidarli insieme?

Devo ammettere che a volte scelgo l'opzione 3)

3) Listen to the clients vague ideas, blanch at the idea of spending weeks helping them figure out exactly what they want... so figure out what it is they need, build that, and refactor as required.

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

Mi capita sempre; "sicuramente potremmo fare ..." è una frase molto terrificante. Soprattutto perché le cose che vengono menzionate sono quasi sempre le campane, i fischietti e la classe di caratteristiche "belle da avere". Non lo capiscono assolutamente nell'affermazione "beh, un bug tracker ovviamente, e poi ..." la maggior parte del potenziale lavoro riposa nelle prime quattro parole.

Quindi, a volte è bello prendere una visione dei clienti, applicare una dose decente di programmatori-buonsenso 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 il # 2 è l'approccio più sano. Altrimenti c'è un'alta probabilità che in una settimana ti venga presentata una specifica meravigliosa e dettagliata ... che è completamente inutile per te come programmatore.

Molto lo stesso problema menzionato sopra (n. 3) e uno che ti lascia comunque fare il n. 2.

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

se vuoi essere uno sviluppatore , e questo è tuo client, prendi la mano del tuo cliente e guidali gentilmente attraverso la densa foresta di possibilità finché trovi il prato pieno di coniglietti felice all'incrocio tra Wants and Needs.

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

La programmazione è preliminare alla risoluzione dei problemi degli utenti. Quindi, per me, entrare in uno sforzo e in un dolore "extra" per ottenere una soluzione soddisfacente e funzionante per i nostri utenti quasi sempre vince evitando la seccatura "extra" e non offrendo nulla di utile alla fine.

(Naturalmente, ci sono utenti reali là fuori che non hanno idea di cosa vogliono, e nessuno sforzo può portarli in uno stato in cui possono prendere decisioni significative. Ma io credo che nella maggior parte dei casi hanno un vero problema, sono disposti a spendere sforzi e denaro per risolverlo, e saranno felici se potremo aiutarli a trovare una soluzione funzionante.)

Quindi la linea di fondo è, il nostro obiettivo dovrebbe risolvere i problemi degli utenti. A volte ciò 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 passare un po 'di tempo a creare semplici schizzi / prototipi / prototipi, quindi mostrare loro il risultato e chiedere "questo sembra quello che avevi in mente?" (poi buttare via il prototipo quando dicono "in realtà, stavo pensando a qualcosa di completamente diverso ..." e ricominciare da capo ...: -)

La vera abilità sta nella scelta del giusto approccio per il momento giusto.

Ultimo ma non meno importante, nella mia esperienza, le buone soluzioni richiedono quasi sempre almeno alcune conoscenze di dominio da parte dello sviluppatore. Senza questo, non hai un linguaggio comune con l'utente, quindi non c'è alcuna garanzia che ciò che tu offri sia davvero utile per loro. Gli utenti in genere non hanno molto indizio sulla tecnologia, quindi non hanno idea di cosa sia o non sia possibile e quale sia il costo di approcci / funzionalità differenti. Dal momento che non possiamo ragionevolmente aspettarci che imparino la tecnologia con dettagli sufficienti, dovremmo fare un passo in più dalla nostra estremità del ponte.

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

• mi aiuta a fornire buone soluzioni, che a lungo termine aumentano il mio valore di mercato come sviluppatore, e
• diversi domini non sono completamente distinti, quindi almeno parte di quella conoscenza del dominio sarà probabilmente riusabile in future date.

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

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

La mancata comprensione delle complessità di questa fase porta spesso a delusioni, sia con gli sviluppatori di software, sia con il cliente. Vorremmo superare questa fase sempre più velocemente o farla finita completamente. I risultati sono spesso disastrosi: dopo l'inizio accelerato, durante lo sviluppo la posta in gioco è sempre più alta e diventa sempre più difficile tornare al tavolo da disegno. Quando il sistema è finalmente finito e milioni sono stati spesi, né il cliente, né l'azienda di ingegneria sono disposti ad ammettere il suo fallimento, portando all'introduzione forzata di un sistema fallito.

Un'alternativa è lasciare che un analista aziendale faccia il lavoro per te. Questo potrebbe essere sensato 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 la riscrittura di una parte dei requisiti.

P.S. forse pensi che io stia sostenendo il metodo della cascata. Non sono un sostenitore del 'grande design in anticipo', ma credo che lo sforzo di analisi del dominio dovrebbe essere proporzionato allo sforzo di implementazione. Si possono fare più cicli (prototipo, rilasciare candidati, ecc.).

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

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

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

Non vuoi saltare all'Opzione # 2 quando riescono a esprimere a malapena 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 arrivano tu, ma nella mia esperienza questo è molto raro). Falli trovare le loro idee insieme. Invitali a scrivere qualcosa sulla carta, se possibile descrivi quello che vogliono in termini di sistemi esistenti (es. "Vogliamo un sito web come blahblah.com ma con queste differenze ... vogliamo uno strumento che faccia un compito simile al 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 puoi utilizzare per costruire il sistema.

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

Per progettare qualcosa che soddisfi i loro bisogni, devi identificare quei bisogni, e per farlo, qualcuno dovrà tenere il cliente in basso ed estrarre quei bisogni. Se nessun altro può farlo, allora devi. (Se qualcun altro pensa di poterlo, dovresti sederti con loro ed estrarre i bisogni reali più tardi ...)

Con l'opzione 2, nel corso di un certo numero di riunioni, puoi eventualmente addestrare il cliente a condividere i problemi con te piuttosto che con le soluzioni. (Anche se il cliente ha capacità tecniche - per esempio, non hanno la disponibilità a fare questo lavoro e hanno bisogno che tu lo faccia invece - potrebbero ancora concentrarsi su un'implementazione che non è l'ideale per il cliente finale.) Non importa molto quale sia il processo di sviluppo che usi, dovrai comunque andare avanti e indietro alcune volte finché non potranno rispondere alle domande in modi che definiranno le specifiche per te.

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

L'opzione 1 è un modo eccellente per evitare di lavorare. L'ho usato quando ritenevo che il lavoro non fosse necessario o che avessi cose più importanti da fare.

Innanzitutto, gli utenti non sanno cosa possono fare i computer. Molti di noi hanno passato anni a imparare a capire computer e calcoli, e ciò che è ovvio per noi potrebbe non essere facilmente comprensibile per qualcuno che ha passato quegli anni ad imparare altre cose.

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

Per dare un'analogia, quando ho comprato la mia casa attuale, un interior designer ha selezionato i colori delle pareti per le stanze del piano principale (prima negli Stati Uniti, Regno Unito). Non avrei mai scelto quei colori io stesso. Volevo una casa che fosse bella, e l'ho presa. Se il progettista mi avesse ascoltato e mi avesse dato qualsiasi cosa potessi articolare, non sarebbe uscito quasi altrettanto bene.

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