it-swarm.it

Trattare con specifiche errate / incomplete / poco chiare?

Sto lavorando a un progetto in cui il nostro team di sviluppo ottiene le specifiche dalla parte aziendale dell'azienda. Sia la gestione aziendale che la gestione IT richiedono stime e scadenze, come dovrebbero.

La cosa buona è che le stime sono fatte principalmente dagli sviluppatori reali che riescono a fare le funzionalità richieste. La cosa brutta è che le specifiche sono in genere troppo semplici (si scopre che ti rimangono molti punti interrogativi sulla testa perché molte informazioni sembrano mancare) o troppo complesse (fino al punto che puoi visualizzare anche dove tutto si "adatterebbe" nell'app). Più spesso, la parte commerciale delle specifiche è incompleta o ignara di ciò che può e non può essere fatto (data la logica aziendale precedentemente implementata).

Il team di sviluppo ha a disposizione circa un giorno per ogni nuova specifica per fornire una stima e cerchiamo di eliminare le incertezze, di solito incontrando chiunque abbia fatto la specifica. La maggior parte delle volte si scopre che gli autori delle specifiche non hanno davvero pensato a tutto, e di solito è solo quando iniziamo a progettare e sviluppare che finiamo nei guai, poiché molte specifiche sembrano avere buchi.

Come lo gestisci? Sei generoso con le stime in anticipo?

44
eagerMoose

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

Assicurati che coloro che creano le specifiche non si sentano come se dovessero fare tutto in anticipo. Non possono pensare a tutto e nemmeno noi. Devono anche sapere che non possono semplicemente fare una nottata su un documento di specifiche e quindi eseguire il progetto. Questa pratica li porta anche ad aggiungere ogni piccola cosa a cui possono pensare perché 'potrebbero' averne bisogno e se non lo chiedono ora, lo capiranno 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 come vogliono chiamarlo. Non devi essere agile se questa non è la tua cosa. 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 consegnasse le specifiche che mi permettessero di creare l'intero progetto in una volta, ma cosa farei per il prossimo anno e mezzo?

13
JeffO

Uso Cone of Uncertainty Dì ad alta voce in forte espansione

Fondamentalmente fai la migliore stima che puoi dare alle informazioni che hai.
Ma sottolinea anche che, data la vaghezza nelle specifiche, esiste un'elevata incertezza su queste stime (gestione dei punti sul sito in modo che possano leggere sul principio).

Man mano che avanzi verso l'obiettivo e restringi le specifiche, puoi aggiornare la stima e aumentare l'incertezza.

20
Martin York

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

Legge di Hofstadter: ci vuole sempre più tempo del previsto, anche quando si tiene conto della Legge di Hofstadter. Da Gödel, Escher, Bach: una treccia d'oro eterna.

9
Brian Carlton

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 lavoro sono:

  • Definire gli obiettivi principali per le modifiche proposte/nuova app. Si tratta di questioni commerciali obiettivi come "ridurre del 10% i costi di elaborazione dei reclami" o "condividere ricerche di mercato dai nostri uffici satellite in modo che i prodotti soddisfino meglio le esigenze dei nostri clienti". Aiuta a focalizzare i requisiti aperti su quali siano le reali esigenze.
  • Fai il tuo Swag iniziale (Seriously Wild-A ** Guess) per i cattivi requisiti mentre sono scritti, ma documenta cosa t presumerai che sarà l'implementazione. Questo è il feedback che gli uomini d'affari (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 avanti. Probabilmente scioccherà chiunque ti chieda di fare un lavoro, il che è una buona cosa. Costringerai voi due a discutere di cosa stanno veramente cercando.

Ricorda che il tuo primo preventivo non può essere accurato. Basa le tue stime su interpretazioni ragionevoli dei requisiti che ottieni e documenta le tue assunzioni/interpretazioni. Ci saranno più requisiti derivati ​​a causa dei buchi che hai scoperto. E 'normale.

6
Berin Loritsch

Essere generosi sulle stime può sembrare bello, ma quale problema risolve? Non migliorerà le specifiche, non faciliterà 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, informali. Una relazione scritta non è davvero il miglior metodo di comunicazione. Se puoi avere un aiuto dello sviluppatore nella raccolta dei requisiti iniziali e un analista aziendale che ti aiuta con lo sviluppo e i test, i tuoi risultati saranno migliori.

Ho appena letto il Cono di incertezza; è roba buona, ma è facile sbagliare. La direzione può guardare la prima immagine e dire: 'ok, abbiamo i requisiti aziendali, quindi la tua stima dovrebbe essere accurata al 50% in base al tuo cono. Dimmi'. Questo non aiuta.

Analogia automobilistica: qualcuno ti chiede quanto costa un'auto e ti fornisce un documento con le sue esigenze. Il documento afferma 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 è anche possibile il nero?).

Puoi dire $ 25K, e se si scopre più tardi vuole una Range Rover nuova di zecca sei fregato. Ciò non lo rende più corretto, né più utile dire che costa $ 100.000. Potrebbe aver solo bisogno di una Prius usata (scusate, usata). Se non hai il tempo di scoprire quale, non lo saprai mai.

3
Jaap

La maggior parte delle volte si scopre che gli autori delle specifiche non hanno davvero pensato a tutto, e di solito è solo quando iniziamo a progettare e sviluppare che finiamo nei guai, poiché molte specifiche sembrano avere buchi.

L'uso di most non è corretto.

Non è possibile per gli autori delle specifiche pensare tutto attraverso. Periodo. Se avessero pensato tutto attraverso, avrebbero saputo quante righe di codice scrivere e quali righe di codice erano corrette.

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

Il finisce nei guai è il problema.

Sia la gestione aziendale che la gestione IT richiedono stime e scadenze, come dovrebbero.

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

Da qui lo sviluppo di metodi Agili.

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

Dal momento che deve accadere, non dovresti finire nei guai quando sbagli. Devi avere torto. E devi essere in modo coerente e casuale sbagliato. Altrimenti stai sfogliando i numeri.

2
S.Lott

Dovresti spiegare al management che con vaghe specifiche c'è un basso grado di fiducia nella stima. vale a dire che la stima può variare del 30% o del 40% o del 50% o qualunque cosa tu pensi. Quindi, se si stima che qualcosa sia di 2 giorni, in realtà è un intervallo compreso tra 2-3 giorni.
Quindi crea un registro di emissione dei progetti (può essere su un wiki o su 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 il canale per facilitare questo e fare requisiti migliori. Chiedi al tuo team di test di rivedere le specifiche in quanto devono creare casi di test rispetto alle specifiche. Spesso il loro coinvolgimento può portare a scrivere specifiche migliori. Riporta quotidianamente/settimanalmente alla direzione quanti problemi irrisolti hai. Più viene risolto, migliori saranno le tue stime. Presenta sempre metriche alla direzione poiché le figure le fanno pensare in modo obiettivo e ti mettono anche su un terreno solido.
Inoltre, a seconda delle dimensioni del progetto, inserire 1-4 settimane per la fase di progettazione della soluzione in cui si risolvono i problemi principali (sia requisiti che tecnici). Organizzare numerosi seminari con le PMI delle imprese e cercare di capirle e, a loro volta, spiegare le tue opinioni per giungere alla conclusione. Solo dopo aver compreso i principali casi d'uso e le tue stime raggiungono circa l'80% di fiducia, dovresti procedere allo sviluppo della fase.

1
softveda

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. Quindi le nostre richieste di funzionalità iniziano con una descrizione del problema o dell'obiettivo che vogliono raggiungere.

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

A questo punto tocca al business sceglierne uno in base al costo e alla completezza della soluzione. Questo è anche il modo in cui potresti essere in grado di vendere loro questo metodo, che qui hanno opzioni, non solo un numero di manday, prenderlo o lasciarlo. Certo, ha anche bisogno di più risorse dalla loro parte, ma se hai problemi con le stime e le specifiche, ne vale la pena un investimento.

0
biziclop

Perché dovresti accettare una specifica dei requisiti incompleta, che contenga requisiti contrastanti o che sia impossibile? Raccomanderei che il processo includa un modo per valutare le specifiche e rispedirle per correzioni prima di accettarle e fornire stime.

0
oosterwal

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

0
FabianB

Elimina le specifiche.

Convincere le imprese a provare Agile (o almeno un processo Agile) per un progetto.

Invece di scrivere le specifiche

  • incontrare gli uomini d'affari per identificare le funzionalità
  • lavorare con loro per identificare l'insieme minimo di caratteristiche/funzioni che sarebbero utili (anche se solo per una versione interna)
  • cardare il lavoro
  • impostare una data per il lavoro (meno funzioni/lavoro è più facile dovrebbe essere per stimare con precisione una data).
  • lavorare con le aziende per stabilire le priorità del lavoro, assicurarsi che abbiano la possibilità di cambiare idea sull'ordine delle carte, dire loro come influenza la data
  • con tutte le funzionalità completate hanno un sistema di lavoro per mostrarle e farle firmare su ogni lavoro mentre viene fatto
  • pubblicazione
  • risciacquo
  • ripetere

Mostrando caratteristiche come vengono fatte. Rilasciare presto e spesso. Sii trasparente e reattivo. Ho scoperto che questo porterà all'eliminazione di scadenze inutili.

Modifica per architettura

Chiunque sia il protagonista dovrebbe avere un incontro preliminare per comunicare agli sviluppatori quale dovrebbe essere l'architettura. Il protagonista è anche davvero la persona che dovrebbe avere la dovuta diligenza per assicurarsi che tutte le esigenze siano soddisfatte.

Se hai bisogno di ulteriori passaggi nel tuo processo piuttosto che aggiungerli. È disponibile un processo per facilitare la capacità del team di svolgere il lavoro. Se qualcosa non funziona, cambiarlo. Aggiungilo, rimuovilo, modificalo per soddisfare i tuoi bisogni. Se devi essere particolarmente preoccupato per la sicurezza, aggiungi i passaggi per farlo.

0
dietbuddha

Ricorda, ogni volta che le specifiche vengono modificate per aggiungere nuove funzionalità o per chiarire le domande, è tempo di rivedere il preventivo. Non è così tanto che la nostra stima originale è negativa dato quello che ci è stato detto, ma che non facciamo un passo indietro e diciamo di no, quando abbiamo bisogno di maggiori dettagli. Se fossi un appaltatore che costruisce una casa e stimassi il costo basandomi sull'utilizzo di un piano di lavoro lamiante e un mese dopo il cliente ne vuole uno in granito, puoi scommettere che rivisiterò con lui la stima dei costi. Lasciamo che i nostri clienti vadano incontro a requisiti scadenti e quindi non respingiamo quando si scopre che ci sono molte più cose da fare di quanto inizialmente previsto.

0
HLGEM