Fattori da considerare per la gestione del rischio software

• Il tuo team è adeguatamente formato?
• La tua squadra è abbastanza grande?
• Hai una contingenza nel caso qualcuno lascia il progetto e come influenzerebbe il programma?
• La tua squadra è troppo grande?
• Hanno le risorse di cui hanno bisogno?
• Potrebbe un concorrente portare un prodotto a mercato prima del completamento del tuo progetto?
• Puoi affrontare cambiato? requisiti?
• Puoi occuparti di il progetto diventa irrilevante?
• Hai un buy-in da senior gestione?
• Hai qualche affidamento su fornitori o appaltatori?
• Sei tu fare qualcosa in casa che il tuo la squadra non è abbastanza competente a?
• Hai un budget abbastanza grande da soddisfare il costo stimato del progetto?
• Puoi incontrare un progetto imprevisto i costi?
• E tutto ciò che è specifico per il tuo circostanze: -)

Vorrei aggiungere alla lista di @ Graham:

• Alcuni dei requisiti sono fuori dal tuo controllo (ad esempio le leggi sul calcolo dell'imposta sulle vendite) e potrebbero cambiare?
• Stai utilizzando uno strumento per la prima volta e quanto sei sicuro che lo strumento funzionerà per te? (Potrebbe essere nuovo di zecca, ad es. Azure o solo nuovo per il tuo team)
• Stai facendo affidamento su una generale accettazione da parte degli utenti di un altro prodotto (ad esempio, scrivendo un'app per iPhone ti aspetti che i tuoi utenti abbiano gli iPhone, scrivendo un'app per BlackBerry ti aspetti che i tuoi utenti abbiano BlackBerry, ecc.)
• Puoi ripristinare / ricreare qualsiasi lavoro perso o modificato in modo errato (non solo controllo del codice sorgente ma controllo della versione per documenti, e-mail dai clienti, ecc.)
• Hai strumenti e processi che ti consentono di comprendere i progressi, la mancanza di progressi e le regressioni? La direzione comprende le pietre miliari (ho avuto progetti in cui al 10% di completamento della gestione ho visto i prototipi di UI e credevo che il lavoro fosse "quasi fatto" e poi pressato per sbrigarmi velocemente da lì in poi.)
• Hai provato (automatizzato o meno) per dimostrare che un particolare insieme di modifiche non ha danneggiato qualche altra parte dell'applicazione? Senza tali test, potresti mai apportare modifiche significative come il porting su un'altra lingua o piattaforma?

aggiungerei quanto segue:

• Conosci le esigenze dei tuoi clienti. In caso contrario, il team di raccolta dei requisiti ha determinato in modo adeguato cosa desidera in passato il cliente ed è stato sufficientemente reattivo da garantire che le modifiche vengano propagate il più rapidamente possibile al team di sviluppo? Stanno aggiungendo in placcatura in oro ai requisiti?
• Esiste un prodotto esistente con cui stai gareggiando e hai determinato prima della progettazione come competere con questo prodotto? Questo è fondamentale in quanto i prodotti esistenti spesso escono con "Voglio anche quella caratteristica" aspetti che potrebbero farti deviare dai piani originali. Il tuo team / cliente / cliente target è in grado di essere monitorato lateralmente da tale evento e disponi di piani di emergenza per gestire tale problema?
• La progettazione proposta del tuo prodotto è pertinente al mercato? A metà strada non vuoi scoprire che mentre soddisfa le esigenze dei tuoi clienti manca di aspetti critici per competere nel "nuovo" mondo.

Il Sviluppo rapido di Steve McConnell contiene un capitolo sulla gestione dei rischi, con lunga lista di potenziali rischi. L'ho usato come punto di partenza più di una volta.

Hai il giusto mix di persone? Tutti gli sviluppatori di applicazioni per sviluppatori sono in un progetto incentrato sui dati? Hai bisogno di un progettista di database, una persona di QA o uno specialista dell'interfaccia utente invece di assumere solo persone con lo stesso mix di competenze?

Hai hardware adeguato per supportare il progetto? Ciò è particolarmente vero se si sta creando un sistema ad alto volume o se si è troppo economici per acquistare server di sviluppo oltre ai server di produzione.

Hai impostato i backup dei tuoi database? Basta avere il codice per ricreare un database non è sufficiente, è necessario mantenere i dati anche su dev.

I tuoi sviluppatori lavorano con un set di dati di piccole dimensioni anziché con una dimensione di produzione? Questo quasi garantisce problemi di prestazioni di produzione perché le query che funzionano bene su un piccolo set di dati spesso non su un set di grandi dimensioni. Ho visto molti aggiornamenti di produzione falliti che dovevano essere immediatamente ripristinati a causa di questo particolare problema.

Stai definendo cosa fare nei casi limite e li stai testando? Ad esempio, ho visto progetti in cui nessuno ha mai definito che cosa succede e che l'approvazione dice no.

Sarai costretto a fare scelte progettuali sbagliate per rispettare scadenze irragionevoli?

Nella tua pianificazione per il progetto hai considerato che le persone prendevano giorni di vacanza e di malattia, prendevano il compito di giuria, prendevano un congedo dal lutto ecc.? È necessario pianificare non solo le persone che abbandonano il progetto, ma per le attività quotidiane che la gente ottiene.