EAR para projetos de software

Estrutura Analítica de Riscos – EAR

A EAR (Estrutura Analítica de Riscos) é uma “mão na roda” para identificação de riscos em projetos, pois serve como guia para análise do contexto, da documentação e também para questionamento das partes interessadas. Seu propósito é mostrar as principais categorias de risco para um tipo de projeto e é bom que seja bem específica mesmo, pois assim o ganho de tempo na identificação é maior. Ela tem formato hierárquico similar à EAP (Estrutura Analítica do Projeto).

Em projetos de software, por mais que haja variação entre empresas e tecnologias, existem fatores comuns a observar. Riscos técnicos, de qualidade, organizacionais, externos e de gerenciamento são os principais. Neste post vou compartilhar um pouco das lições aprendidas nesse tipo de projeto (participei de mais de 60 projetos de software até o momento).

EAR de Projetos de software

Riscos Técnicos

• Segurança da Informação -Que tipo de dados irão trafegar no sistema? São confidenciais? Quem pode ter acesso a quê? Como a segurança dos dados será garantida (acesso, backup, proteção contra hackers etc).
• Domínio tecnológico – A equipe tem domínio da tecnologia a ser utilizada? O projeto é uma inovação? Quanto menor o domínio tecnológico maior deve ser a atenção ao gerenciamento de riscos.
• Framework não existente – Existe um framework para facilitar o desenvolvimento? Ele atende às necessidades do projeto ou será alterado? O framework pode ser um risco positivo, se existir e for adequado e pode ser um risco negativo, quando não está adequado à necessidade costuma trazer consigo uma enxurrada de bugs.
• Integrações / interfaces – O sistema será integrado a algum outro? O outro sistema terá acesso de leitura ou escrita? Que tecnologia será utilizada para compartilhar os dados? Todas as views  (consultas pré-formatadas ao banco de dados) necessárias existem ou foram criadas?
• Infraestrutura – Esse é um dos pontos mais críticos do gerenciamento de riscos em projetos de software, pois geralmente nos esquecemos de providenciar com antecedência a infraestrutura onde o software será executado. É um ponto crítico de conflitos entre a área de infraestrutura, suporte e desenvolvimento. Em que servidor o sistema irá rodar? O servidor existe ou precisará ser criado? Ele já foi comprado? É nacional ou importado? Quem irá construir o servidor? Que acessos o sistema dará ao mundo externo? Quem irá acessá-lo? Quantas pessoas? Em que localidades? etc.
• Operação –Mais difícil que desenvolver é manter o sistema, pois as alterações ocorrem em velocidade mais rápida e é preciso preparar o sistema para oferecer informações ao suporte. Quem irá dar suporte? Que informações serão necessárias?

Riscos de Qualidade de software (ISO/IEC 9126)

• Funcionalidade – Contempla tudo que concerne à funcionalidade do software. Como garantir que os requisitos foram atendidos? como garantir que eles atendem à real necessidade? como garantir que o software fornecerá resultados precisos? como garantir que interagirá adequadamente com outros softwares? etc
• Confiabilidade -Neste ponto deve-se buscar a maturação do software, particularmente sou adepto das entregas parciais, que garantem a maturação ao longo do ciclo de desenvolvimento. As perguntas-chave são: como garantir a maturação do software? como garantir a tolerância a falhas (que dados não sejam perdidos caso haja falhas)? como garantir a recuperabilidade (que o software consiga se recuperar no caso de erros)?
• Usabilidade – A usabilidade engloba todos os aspectos referentes à interface com o usuário, que se sinta a vontade com o uso do sistema e que o entenda, com o minimo de treinamento, aspecto muito bem estruturado nos celulares atuais. As perguntas-chave são: É fácil de usar? é fácil de aprender? é fácil de operar (tolera erros de operação)? é atrativo?
• Eficiência – Como garantir que o software responda no tempo adequado (tempo de resposta)? como garantir que utilize recursos na quantidade adequada (memória de servidor, storage etc, mas não apenas isso, quantidade de pessoas para operá-lo também).
• Manutenibilidade -Como garantir que o software seja de fácil manutenção? existem padrões de codificação? as principais funcionalidades (que precisarão de maior manutenção) são dinâmicas, parametrizáveis? Pode-se modificar com facilidade o comportamento do software? O software é capaz de evitar efeitos colaterais após uma manutenção? é modularizado? É possível testar o software em todos os níveis (testes funcionais, testes de integração, de performance etc)?
• Portabilidade – Em que plataformas / sistemas operacionais o software irá rodar? o mesmo código é reutilizável em diferentes plataformas sem configurações complexas? se não, como será realizada a configuração? por quem? quando? O software é capaz de conviver com outros sistemas no mesmo ambiente (coexistência)? é capaz de substituir outro sistema existente sem causar impactos?

Riscos Organizacionais

• Estratégia – A projeto de software está aderente à estratégia empresarial, do cliente ou do prestador de serviço? Como lidar em caso negativo? E se houver mudança de estratégia, como garantir que o trabalho não será perdido? Existe alguma estratégia relacionada ao reuso do projeto ou à “produtização” do projeto (para comercializar em múltiplos clientes)?
• Financeiro -Existem recursos financeiros para finalizar o projeto? Há riscos de fluxo de caixa? Existem reservas de contingência para suportar os riscos do projeto? como será feito o gerenciamento? Existe alguma pendência financeira da empresa frente à fornecedores ou funcionários? como contornar?
• Estrutura – A estrutura física da empresa é adequada à necessidade do projeto? O ambiente de desenvolvimento (local onde ficam os programadores) representa algum tipo de risco? dificuldade de transporte, barulho, distrações? A estrutura organizacional suporta adequadamente a execução do projeto? Pode haver intervenções indesejadas de partes interessadas na gestão do projeto?
• Prioridade de projetos -Muitos projetos sofrem pausas e cancelamentos devido à mudanças de prioridade. Como será feito o gerenciamento de riscos desse tipo? Existem outros projetos concorrendo recursos (humanos, materiais ou financeiros)? Que prioridade eles têm na organização? (Isso se a organização tiver algum senso de prioridade)
• Processos adequados -Este ponto é o calcanhar de Aquiles do desenvolvimento de software. Existem processos para o gerenciamento de projetos de software? Existem políticas para o controle de mudanças, gestão de configuração, backup etc? Existem processos que orientam a interação com as equipes de suporte (infraestrutura e service desk)?
• Apoio da alta gestão – Muito relacionado às questões de prioridade e estratégia. A alta gestão está ciente do projeto? Ela apóia a execução do projeto? Quem é o patrocinador do projeto? Existe algum stakeholder (interno ou externo) interessado no fracasso do projeto?

Riscos Externos

• Fornecedores -Existem fornecedores qualificados para prestação de serviços? A quantidade de fornecedores disponíveis é um fator de risco? Existe algum monopolista, algum oligopólio? Os preços dos fornecedores foram coletados previamente? Existe algum risco de câmbio, juros, formas de pagamento?
• Legislação -Há alguma legislação identificada que possa impactar no desenvolvimento do produto? Alguma mudança de lei ou norma pode impactar nos requisitos? Que ações de contorno foram traçadas caso haja?
• Política – Existe algum tipo de influência política que possa impactar no projeto? O projeto é relacionado a órgãos públicos? O mercado (concorrentes ou parceiros) podem causar impacto no projeto? Pode haver algum tipo de protesto ou processo judicial que embargue o projeto?
• Economia – Deve avaliar se há riscos econômicos: câmbio, taxas, impostos, inflação etc.
• Condições ambientais – Alguns softwares podem ser impactados por condições ambientais. O software será executado em ambiente aberto? Existem riscos de chuva
• Mercado de trabalho – Como todos sabem, há carência de profissionais em TI e a rotatividade costuma ser alta entre os perfis de desenvolvimento de softwares (programação, análise, testes etc). Existe algum plano de contingência em caso de perda de profissionais?

Riscos de gerenciamento do projeto

• Mudanças no escopo – Projetos de software são campeões em mudanças de escopo, isto porque tratam de transformar uma abstração em realidade e ainda assim, é algo virtual e não físico. Para lidar com mudanças há duas formas, orçar o projeto considerando mudanças ou efetuar o controle integrado de mudanças. As regras do jogo foram combinadas previamente com o cliente? Existem riscos de mudanças serem consideradas implícitas? Leia mais em “O atendimento café com leite” e “Escopo variável, tempo e custo fixos“.
• Prazo inadequado – O prazo do projeto foi estimado pela equipe? Considerou-se tempo para testes, operação assistida e garantias? E se houver alterações de requisitos considerados implícitos, como proceder?
• Estouro de custos – Os custos forma validados pelo gerente de projetos? Foi feito um estudo de viabilidade do projeto? Como proceder se houver estouro de custos? Existem reservas de contingência e gerenciamento?
• Falta / inadequação dos recursos humanos – Os recursos humanos disponíveis para o projeto têm as competências necessárias para sua execução? As pessoas foram treinadas? Existe um sênior na equipe para orientar os demais programadores? E se houver perda de recursos? Se algum projeto tomar a prioridade?
• Partes interessadas (stakeholders) – Os stakeholders foram devidamente identificados? Além do usuário-chave (tipicamente projetos de software definem UMA pessoa como ponto focal das demandas do cliente) existem outras partes interessadas ocultas? Todos foram consultados? Existe uma parte interessada contrária ao projeto? Como lidar com objeções?
• Comunicação – O processo de comunicação foi abordado com o cliente? Qual será a periodicidade de reuniões de progresso? E de status? Serão apresentados relatórios de status? Quem será o público-avo? Que informações serão divulgadas e a quem? Onde as informações serão armazenadas e por quanto tempo?

Gerenciamento de Riscos em Projetos de Software

Softwares são voláteis e abstratos, por isso, neste tipo de projeto o gerenciamento de riscos é um ponto crítico. O índice de atrasos e principalmente de insatisfação dos clientes é alto e deve-se procurar estratégias para mitigar essa estatística.

Neste post compartilhei uma EAR (Estrutura Analítica de Riscos) baseada na minha experiência profissional nessa área e tenho consciência de que ainda há muitos outros fatores a serem discutidos. Esta EAR, no entanto, certamente cobre a grande maioria dos riscos deste tipo de projeto. Atentando a estes tópicos, tenho certeza que seus projetos serão melhor sucedidos.

Espero ter ajudado!

Eli Rodrigues

Leia também:

• Perguntas e respostas sobre Scrum
• 9 erros que o Scrum ajuda a resolver
• Como saber se a entrega está completa mesmo
• 10 erros na implantação do Scrum que você não quer cometer