Gestione delle specifiche errate / incomplete / non chiare? [duplicare]

Se riscontri problemi durante la fase di progettazione, hai davvero un problema?

Assicurati che quelli che creano le specifiche non sentano di dover fare tutto in anticipo. Non riescono a pensare a tutto e nemmeno a noi. Devono anche sapere che non possono semplicemente fare una nottata su un documento specifico e poi essere fatti con il progetto. Questa pratica porta anche a loro aggiungere ogni piccola cosa a cui è possibile pensare perché "potrebbe" averne bisogno e se non lo chiedono ora, lo avranno mai. Devono essere disponibili per rivedere, testare e approvare i loro requisiti più e più volte.

Non provare a progettare o creare l'intera app in una sola volta. Qualsiasi progetto / app può essere suddiviso in una sorta di fasi, parti, moduli o qualsiasi altra cosa si voglia chiamare. Non devi essere agile se non è il tuo genere. Inizia con il pezzo Sicurezza utente e vai da lì.

Trova il tempo di sederti con queste persone e scoprire cosa vogliono veramente. Mi piacerebbe che qualcuno mi desse delle specifiche che mi permettessero di creare l'intero progetto tutto in una volta, ma cosa avrei fatto per il prossimo anno e mezzo?

Uso il Cono di incertezza ^{Dì in una voce che rimbomba rumorosa}

Fondamentalmente fai la stima migliore che puoi dare alle informazioni che hai.
Ma sottolinei anche che, data la vaghezza delle specifiche, c'è un'alta incertezza su queste stime (gestione dei punti nel sito in modo che possano leggere il principio).

Mentre procedi verso il target e stringi le specifiche puoi aggiornare il tuo preventivo e stringere l'incertezza.

Sì, sono generoso su stime. Non dimenticare legge di Hofstadter

Legge di Hofstadter: ci vuole sempre più tempo di quanto ci si aspetti, anche se si tiene conto della legge di Hofstadter. Da Gödel, Escher, Bach: An Eternal Golden Braid.

Il processo che stai descrivendo è in realtà abbastanza normale. Il problema è che i tipi di business tendono a pensare alle cose in termini di "fase dei requisiti", quindi "fase di progettazione", ecc. Quando un team sta creando un prodotto, è davvero necessario un approccio iterativo. Un paio di idee che ho trovato di lavoro sono:

• Definisci i principali obiettivi per le modifiche proposte / nuova app. Questi sono obiettivi correlati al business come "ridurre i costi di elaborazione dei reclami del 10%" o "condividere ricerche di mercato dai nostri uffici satelliti in modo che i prodotti soddisfino le esigenze dei nostri clienti". Aiuta a focalizzare l'attenzione sulle esigenze aperte su quali siano le reali esigenze.
• Esegui il tuo SWAG iniziale (Seriamente selvaggio-A ** Indovina) per i cattivi requisiti man mano che vengono scritti, ma documenta ciò che tu presume che l'implementazione sarà. Questo è un feedback che gli imprenditori (e il tuo cliente) devono migliorare e pensare a queste cose. Si affidano a te per loro.
• Se hai una scelta tra una stima molto lunga e una molto breve, vai sempre lunga. Probabilmente sconvolgerà chiunque ti chieda di fare un lavoro, che è una buona cosa. Vi costringerà a due a discutere di cosa stanno veramente cercando.

Ricorda che la tua prima stima non può essere accurata. Basate le vostre stime su interpretazioni ragionevoli dei requisiti che ottenete e documentate le vostre ipotesi / interpretazioni. Ci saranno più requisiti derivati a causa dei buchi che hai scoperto. Questo è normale.

Essere generosi sulle stime può sembrare bello, ma quale problema risolve? Non renderà le specifiche migliori, non renderà più semplice la pianificazione. Sta dicendo "non può essere molto peggio di X", invece di dire "potrebbe essere Y". La verità è che non lo sai. Scopri cosa puoi

Se gli analisti aziendali devono coinvolgere prima gli sviluppatori, diglielo. Un rapporto scritto non è davvero il miglior modo di comunicare. Se puoi avere uno sviluppatore che aiuti con la raccolta dei requisiti iniziale e un analista di business che ti aiuti nello sviluppo e nel test, i risultati saranno migliori.

Ho appena letto il Cono dell'Incertezza; è roba buona, ma è facile sbagliarla. La direzione può guardare la prima immagine e dire: "ok, abbiamo i requisiti aziendali, quindi la tua stima dovrebbe essere accurata al 50% secondo il tuo cono. Dimmi'. Ciò non aiuterà.

Analogia automobilistica: qualcuno ti chiede quanto costa una macchina e ti dà un documento con le sue esigenze. Il giornale dice che dovrebbe pesare circa 1200 kg, avere quattro ruote e almeno due porte, ma forse quattro, dovrebbe ospitare quattro persone, e i buoni fari sono davvero importanti. Il colore dovrebbe essere grigio (ma è possibile anche il nero?).

Puoi dire $ 25K, e se poi si scopre che vuole una Range Rover nuova di zecca, sei fregato. Ciò non lo rende più corretto, o più utile per dire che costa $ 100K. Potrebbe semplicemente aver bisogno di un Prius usato (scusato, usato). Se non hai il tempo di scoprire quale, non lo saprai mai.

Most of the times it turns out that spec writers haven't really thought everything through, and it's usually only when we start designing and developing that we end up in trouble, as a lot of the spec seems to have holes.

L'uso di la maggior parte non è corretto.

Non è possibile per gli autori di spec. pensare tutto attraverso. Periodo. Se pensassero tutto , saprebbero quante righe di codice scrivere e quali linee di codice sono corrette.

Poiché le specifiche devono essere errate, non c'è molto che tu possa fare al riguardo.

Il finisce nei guai è il problema.

Both the business management and the IT management require estimates and deadline projections, as they should.

Forse no. Le stime e le scadenze generali non sono le cose più utili.

Di qui lo sviluppo dei metodi Agile.

Il punto è questo. Tutte le stime basate su specifiche devono contenere errori. Sono solo corretti per fortuna. La metà delle volte, la stima è molto sotto e metà del tempo in cui la stima è finita. Questa è una conseguenza logica del tentativo di prevedere il futuro con informazioni incomplete.

Dato che deve succedere, non dovresti finire nei guai quando ti sbagli. Devi essere sbagliato. E devi essere coerente e casualmente sbagliato. Altrimenti stai confondendo i numeri.

Dovresti spiegare alla direzione che con le specifiche vaghe c'è un basso grado di fiducia nella stima. Ad esempio, la stima può variare del 30% o del 40% o del 50% o qualsiasi altra cosa tu pensi. Quindi se qualcosa è stimato in 2 giorni è in realtà un intervallo da 2-3 giorni.
Quindi creare un registro dei problemi di progetto (può essere su un wiki o Jira, ecc.). Crea tutte le tue domande come problemi e fai in modo che l'azienda risponda alla tua domanda. Finché un problema rimane irrisolto, la stima rimane incerta. Se possibile, fare in modo che un analista aziendale sia condotto per facilitare questo e fare migliori requisiti. Fai in modo che il tuo team di test riveda le specifiche in quanto devono creare casi di test con le specifiche. Spesso il loro coinvolgimento può portare a scrivere specifiche migliori. Segnala giornalmente / settimanalmente alla gestione quanti problemi irrisolti hai. Più saranno risolti, migliori saranno le tue stime. Mostra sempre le metriche al management in quanto le figure le fanno pensare obiettivamente e ti mettono anche su basi solide.
Inoltre, a seconda delle dimensioni del progetto, sono necessarie da 1 a 4 settimane per la fase di progettazione della soluzione, in cui affronterai i principali problemi (sia tecnici che tecnici). Avere molti workshop con le piccole e medie imprese e cercare di capirli e, a loro volta, spiegare le proprie opinioni per giungere alla conclusione. Solo dopo che i principali casi d'uso sono stati compresi e le tue stime raggiungono circa l'80% di confidenza, dovresti procedere alla fase di costruzione.

Ricorda che ogni volta che la specifica viene modificata per aggiungere nuove funzionalità o per chiarire le domande, è ora di rivisitare la stima. Non è tanto che la nostra stima originale è cattiva dato ciò che ci è stato detto, ma che non ci spingiamo indietro e diciamo di no abbiamo bisogno di questo quando vengono resi disponibili maggiori dettagli. Se io fossi un appaltatore che costruisce una casa e ho stimato il costo basato sull'utilizzo di un piano di lavoro lamiante e un mese dopo il cliente vuole uno in granito, puoi scommettere che mi piacerebbe rivisitare il preventivo con lui. Lasciamo che i nostri clienti superino i requisiti scadenti e quindi non rifiutare quando si scopre che ci sono molte più cose da fare di quanto originariamente previsto.

Perché dovresti accettare una specifica dei requisiti che è incompleta, contiene requisiti in conflitto o è impossibile? Vorrei raccomandare che il tuo processo includa un modo per valutare le specifiche e inviarle per le correzioni prima di accettarle e dare delle stime.

Convinci il management / cliente che vale la pena investire in specifiche migliori. Prova a coinvolgere maggiormente le persone con conoscenza del dominio . Alla fine tutti ne trarranno profitto.

Elimina le specifiche.

Convincere le aziende a provare Agile (o almeno un processo Agile-ish) per un progetto.

Invece di scrivere le specifiche

• incontrare gli uomini d'affari per identificare le funzionalità
• lavora con loro per identificare il set minimo di funzionalità / funzioni che sarebbe utile (anche se solo per una versione interna)
• carda il lavoro
• imposta una data per il lavoro (meno funzioni / lavoro più facile dovrebbe essere per stimare con precisione una data).
• lavorare con le aziende per dare la priorità al lavoro, assicurarsi che abbiano la possibilità di cambiare idea sull'ordine della carta, dire loro come influisce sulla data
• con ogni funzione completata è disponibile un sistema funzionante per visualizzarli e farli firmare su ogni pezzo di lavoro come è stato fatto
• stampa
• risciacquo
• ripetizione

Visualizzazione delle funzioni man mano che vengono eseguite. Rilascia presto e spesso. Sii trasparente e reattivo. Ho trovato che questo porterà all'eliminazione di scadenze inutili.

Modifica per l'architettura

Chi è il protagonista dovrebbe avere un incontro iniziale per comunicare agli sviluppatori cosa dovrebbe essere l'architettura. Il protagonista è anche la persona che dovrebbe essere debellata per assicurarsi che tutti i bisogni siano soddisfatti.

Se hai bisogno di ulteriori passaggi nel tuo processo piuttosto che aggiungerli. Un processo è lì per facilitare la capacità del team di portare a termine il lavoro. Se qualcosa non funziona, cambialo. Aggiungi ad esso, rimuovi da esso, modificalo per soddisfare le esigenze . Se devi preoccuparti in particolare della sicurezza, aggiungi passaggi per questo.

La comunicazione di solito aiuta, almeno in un'organizzazione sana.

Questo non è un proiettile d'argento, ma quello che ho cercato di fare (e ha funzionato nella nostra azienda) è convincere gli uomini d'affari a spiegare il problema, piuttosto che suggerire una soluzione immediatamente. Pertanto, le nostre richieste di funzioni iniziano con una descrizione del problema o dell'obiettivo che desiderano raggiungere.

Quindi uno sviluppatore con una certa conoscenza del dominio cerca di arricchire una soluzione, mentre consulta qualcuno sul lato commerciale delle cose. Di solito questo processo produce diverse soluzioni alternative, complete di stime.

A questo punto è compito dell'azienda sceglierne uno basato sul costo e sulla completezza della soluzione. Questo è anche il modo in cui potresti essere in grado di vendere questo metodo a loro, che qui hanno opzioni, non solo un certo numero di mandays, prenderlo o lasciarlo. Certo, ha bisogno anche di più risorse dalla loro parte, ma se hai problemi con stime e specifiche, è un investimento che vale la pena.