Fatores a serem considerados no gerenciamento de riscos de software

Quais são os fatores de risco que precisamos considerar ao planejar um projeto de software.

• Sua equipe está treinada adequadamente?
• Sua equipe é grande o suficiente?
• Você tem contingência no caso de alguém deixar o projeto e como isso afetaria o cronograma?
• Sua equipe é muito grande?
• Eles têm os recursos de que precisam?
• Um concorrente pode trazer um produto ao mercado antes da conclusão do seu projeto?
• Você pode lidar com requisitos alterados?
• Você pode lidar com o projeto se tornando irrelevante?
• Você tem adesão da gerência sênior?
• Você tem alguma confiança em fornecedores ou contratados?
• Você está fazendo algo internamente em que sua equipe não é competente o suficiente?
• Você tem um orçamento grande o suficiente para atender ao custo estimado do projeto?
• Você consegue cobrir os custos imprevistos do projeto?
• E qualquer coisa que seja específica às suas circunstâncias :-)

Eu adicionaria à lista de @ Graham:

• Alguns dos requisitos estão fora de seu controle (por exemplo, as leis sobre o cálculo do imposto sobre vendas) e eles podem mudar?
• Você está usando uma ferramenta pela primeira vez e quão confiante você está de que a ferramenta funcionará para você? (Pode ser novo, por exemplo, Azure ou apenas novo para sua equipe)
• Você está confiando na aceitação geral dos usuários de outro produto (por exemplo, escrever um aplicativo para iPhone significa que você espera que seus usuários tenham iPhones, escrever um aplicativo BlackBerry significa que você espera que seus usuários tenham BlackBerries etc.)
• Você pode restaurar / recriar qualquer trabalho perdido ou alterado incorretamente (não apenas o controle de origem, mas o controle de versão de documentos, e-mails de clientes, etc.)
• Você tem ferramentas e processos que permitem entender o progresso, a falta de progresso e as regressões? O gerenciamento entende os marcos (eu tive projetos em que, em 10%, o gerenciamento viu protótipos de interface do usuário e acreditava que o trabalho estava "quase pronto" e depois pressionado a se apressar a partir de então)
• Você tem testes (automatizados ou não) para demonstrar que um conjunto específico de alterações não quebrou nenhuma outra parte do aplicativo? Sem esses testes, você poderia fazer alterações significativas, como migrar para outro idioma ou plataforma?

Eu adicionaria o seguinte:

• Você conhece as necessidades do seu cliente. Caso contrário, sua equipe de coleta de requisitos determinou adequadamente o que o cliente deseja no passado e foi responsiva o suficiente para garantir que as mudanças sejam propagadas o mais rápido possível para a equipe de desenvolvimento? Eles estão adicionando revestimento de ouro aos requisitos?
• Existe um produto existente com o qual você está competindo e você determinou antes do design exatamente como irá competir com este produto? Isso é crítico, pois os produtos existentes geralmente apresentam aspectos de "eu também quero esse recurso" que podem fazer você se desviar dos planos originais. Sua equipe / gerência / cliente-alvo pode ser rastreada por essa ocorrência e você tem planos de contingência configurados para lidar com esse problema?
• O design proposto do seu produto é relevante para o mercado? No meio do caminho, você não quer descobrir que, embora satisfaça as necessidades de seus clientes, não possui aspectos críticos para competir no "novo" mundo.

O Rapid Development de Steve McConnell contém um capítulo sobre gerenciamento de riscos, com uma longa lista útil de riscos em potencial. Eu o usei como ponto de partida mais de uma vez.

Você tem a mistura certa de pessoas? Todos os seus desenvolvedores são desenvolvedores de aplicativos em um projeto centrado em dados? Você precisa de um designer de banco de dados, um responsável pelo controle de qualidade ou um especialista em UI em vez de contratar apenas pessoas com o mesmo mix de habilidades?

Você possui hardware adequado para apoiar o projeto? Isso é especialmente verdade se você estiver criando um sistema de alto volume ou se for muito barato para comprar servidores de desenvolvimento, além de servidores de produção.

Você configurou backups de seus bancos de dados? Apenas ter o código para recriar um banco de dados não é suficiente, você precisa manter os dados também no dev.

Seus desenvolvedores estão trabalhando com um pequeno conjunto de dados em vez de um do tamanho que a produção terá? Isso quase garante problemas de desempenho de produção, porque as consultas que funcionam bem em um pequeno conjunto de dados geralmente não funcionam em um conjunto grande. Eu já vi muitas atualizações de produção com falha que tiveram que ser revertidas imediatamente devido a esse problema específico.

Você está definindo o que fazer em casos extremos e está testando-os? Por exemplo, eu vi projetos em que ninguém nunca definiu o que acontece, o que é necessário para uma aprovação e o aprovador diz que não.

Você será forçado a fazer más escolhas de design para cumprir prazos irracionais?

No seu planejamento para o projeto, você considerou que as pessoas tiram férias e dias de doença, fazem júri, tiram licença por luto, etc? Você precisa planejar não apenas as pessoas que abandonam o projeto, mas também as folgas do dia-a-dia.