Qual è il modo appropriato per gestire i requisiti impliciti?

Rendere espliciti i requisiti impliciti è la risposta corretta.

Informazioni sui vincoli di follow-up:

The customer can't hear about these requirements, because I will be presenting a long list of ways in which the product can fail, instead of talking about how it will make them happy.

Immagina di essere un architetto, di progettare edifici per grandi aziende.

Big Co. Inc. ti chiede di costruire uno skyscrapper per loro sulla riva. Deve avere una piscina sul tetto e un'altra piscina al decimo piano. Deve avere un giardino a muro che copre il muro esterno dal 15 ° al 17 ° piano.

Queste sono le esigenze del cliente. Vorresti esortare ad aggiungere all'elenco dei requisiti i requisiti per far sì che l'edificio sostenga il proprio peso più due piscine piene d'acqua e un ampio giardino?

Non esiterei ad aggiungere che deve avere l'impianto idraulico, i cavi elettrici e un sistema per riempire la piscina di acqua e mantenere l'acqua pulita?

Sei l'architetto, sai cosa è necessario per un edificio, è per questo che ti pagano.

Sai che un edificio con più di tre piani avrà bisogno di un ascensore, non hai bisogno che qualcuno te lo dica.

Busy management feels that I'm wasting their time, when I talk about "obvious" features.

Quindi l'ascensore è ovvio. Per quanto ovvio, ha comunque un impatto sul costo complessivo, sulla forza lavoro complessiva richiesta, sull'ETA per il progetto e probabilmente su altri aspetti.

I will only be able to describe some of these requirements during implementation. During planning I may just have a gut feeling that a particular issue might require focused effort during development.

È qui che si interrompe l'analogia dell'architetto, principalmente a causa della natura fluida dell'IT. Il mio unico consiglio qui è che potresti beneficiare di un processo iterativo che ti consente di pianificare l'imprevisto. Agile sembra piuttosto popolare.

I'm not at the necessary height in the company totem-pole to dictate my working conditions.

La tua azienda dovrebbe avere qualcuno responsabile di assicurarsi che l'elenco dei requisiti sia completo.

• Se non lo fanno hanno un grosso problema, prova a farglieli aggiustare o iniziare a lucidare il tuo curriculum.
• Se lo fanno, ma quella persona non ha fatto bene il suo lavoro, chiamalo e intensificalo se necessario.
• Se lo fanno e quella persona sei tu, ma non ti è stata data l'autorità di svolgere il tuo lavoro, allora ti stanno chiedendo di fare qualcosa di impossibile, la tua mossa migliore non è giocare (o provare a portarli a correggilo o inizia a lucidare il tuo curriculum).

Definisci tutto. L'unico potenziale negativo nel farlo è che potresti ottenere qualcosa in cambio lamentandoti di sentirti dire che è ovvio.

Dichiara l'ovvio allora.

Questa è la chiave: Tutto ciò che non definisci può essere respinto in faccia con "non ci hai mai detto ..."

Qualsiasi cosa non definita può potenzialmente esplodere in faccia. "Meglio prevenire che curare" sono parole eccellenti per vivere.

Il termine industriale per questi requisiti che descrivi è chiamato:

Requisiti non funzionali

Dovrebbero essere identificati sotto ogni aspetto da risorse tecniche e aggiunti al piano del progetto come unità di lavoro atomiche. Se stai facendo un progetto Agile, verrebbero scritti in forma di User story e aggiunti al backlog per essere gestiti. Come risorsa tecnica devi difendere il tempo per lavorare su questi e assicurarti che abbiano una priorità appropriata durante la pianificazione dello sprint o la sessione di pianificazione del progetto con l'azienda. Inoltre, il QA deve elaborare un piano di test appropriato per queste unità di lavoro.

Come è successo, avevamo alcuni di questi requisiti impliciti che ci mordevano perché non erano definiti e quindi il QA non li testava e gli errori sono andati in produzione e non sono stati trovati per qualche tempo causando non solo il fastidio di spiegare a i clienti il problema e il motivo per cui non è stato trovato prima ma un vero problema legale per la nostra azienda. (Era un rapporto che trattava di informazioni che dovevano essere segnalate al governo.)

Se è abbastanza importante da fare, deve essere testato e quindi deve essere parte dei requisiti.

I requisiti possono provenire da qualsiasi fonte, purché siano tracciabili da dove provengono e non in conflitto tra loro. I clienti possono fornire i loro requisiti, ma i requisiti provengono anche da leggi e regolamenti, standard di settore, esigenze aziendali e anche esperienze pregresse apprese dall'erogazione di prodotti simili ad altri clienti.

Ciascuno di questi requisiti deve essere catturato con qualsiasi metodo tu usi per acquisire i requisiti in modo che non vengano dimenticati. Ciò consentirà anche di confrontarli per garantire che un requisito aggiuntivo non sia effettivamente in conflitto con un requisito del cliente o che un requisito del cliente non sia in conflitto con le normative, ad esempio.

Dovresti cogliere questi requisiti e gestirli fin dall'inizio del progetto e indirizzarli allo staff che sta progettando, implementando e testando il software. Fare ciò assicurerà che tutti comprendano appieno cosa si suppone che il software consegnato.

Tuttavia, quando si aggiunge uno di questi requisiti, è necessario verificarlo con gli stakeholder appropriati. Non puoi semplicemente aggiungere requisiti senza garantire che tu possa ancora consegnare il software entro la pianificazione e il budget previsti.

Questo succede quando c'è una squadra diversificata con persone che si specializzano in aree diverse. Richiede anche più sr. persone della squadra per guidare il resto.

Per esempio prestazioni, estensibilità futura e tracciabilità dei dati dovrebbero essere tutte cose che sono state pensate fin dall'inizio. Non sono una casella di controllo che puoi semplicemente tornare indietro e aggiungere in seguito, devono essere alla base del tuo design.

Per quanto riguarda la sicurezza, è quando avere qualcuno che ha familiarità con quest'area è nel tuo team fin dall'inizio per aiutare con il processo di progettazione.

Il design dell'interfaccia utente ha la tendenza a mordere un prodotto se non eseguito correttamente. Avere una persona UX nella squadra che fa i mock-up e i flussi di schermo per la squadra è dove questo entra in gioco. Ma, ancora, questo è qualcosa che dovrebbe essere fatto in anticipo.

I tuoi requisiti potrebbero essere un sito Web che consente agli utenti di cercare l'attuale inventario di un negozio locale. Come si progetta quel sistema è dove tali requisiti impliciti entrano in gioco.

Dal punto di vista della gestione di un progetto, ciò significa che devono essere previsti tempi di progettazione nel budget e tempi di test adeguati. Ci dovrebbero anche essere check-in con il cliente per mostrare loro ciò che è stato fatto per essere sicuri di essere sulla strada giusta.

Tutti i requisiti impliciti che finiranno per causare lavoro per il team dovrebbero essere resi espliciti.
In caso contrario, finiranno entrambi

1. ti morde più tardi quando la gente li avvicina comunque, causando eccessi di sviluppo
2. ignorato e successivamente segnalato come bug
3. essendo comunque implementato, nonostante non fosse stato programmato, causava sovraccarichi e segnalazioni di bug perché non erano implementati in quanto il cliente aveva pensato che avrebbe dovuto essere ma non menzionato mai.

Quindi, rendendo espliciti i requisiti impliciti, risparmi un sacco di mal di testa.