Relatório de Riscos - fga-eps-mds/2017.1-Cadernos-API GitHub Wiki
Relatório de Riscos
Data | Versão | Modificação | Autor |
---|---|---|---|
30/03/2017 | 0.0.1 | Criação do documento | Eduardo Castro |
1. Objetivo
O objetivo desse artefato consiste em descrever os resultados dos processos definidos pelo Plano de Gerenciamento de Riscos de forma a levantar os riscos associados ao desenvolvimento deste projeto e o acompanhamento do mesmo.
2. Estrutura Analítica de Riscos (EAR)
3. Riscos internos
3.1 Riscos técnicos
Risco | Descrição | Causa | Ação Preventiva | Ação reativa | Impacto | Probabilidade |
---|---|---|---|---|---|---|
RT1 | Baixo domínio do stack de tecnologias do projeto | Falta de treinamento | Treinamentos períodicos | Realizar treinamentos com foco nas dificuldades do time, se necessário buscar ajuda dos coaches ou de outros alunos mais experientes | Alto | Médio |
RT2 | Dificuldade de escalabilidade e manutenção de infraestrutura | A complexidade do projeto e o tamanho dos arquivos que devem ser armazenados | Alinhamento constante de expectativas com a cliente e redução do escopo | Alinhamento imediato com o cliente | Muito alto | Muito alto |
RT3 | Projeto se mostrar mais complexo do que a capacidade de entrega do time | Alinhamento prévio fraco | Alinhamento de expectativas e avaliação de resultados constante com os clientes | Alinhamento imediado com o cliente | Muito alto | Alto |
RT4 | Time priorizar as demandas erradas | Falta de alinhamento com os clientes e mal entendimento do escopo do projeto | Alinhamentos constantes com os clientes | Alinhamento imediado com o cliente | Alto | Médio |
RT5 | Usabilidade não satisfatória | Software não é bem ulilizável para com os clientes | Aproximação de designers para o time, construção de protótipos e feedacks constantes dos clientes | Ir em busca de designers para modelar a experiência do usuário | Alto | Alto |
RT6 | Falta de domínio na padronização de documentos, códigos, etc, podendo causar atraso e problemas de qualidade, etc | Falta de treinamento e estabelecimento de padrões disponíveis de forma acessível | Treinamento e criação de documentação específica e bem detalhada | Time se junta para refatoração | Médio | Médio |
RT7 | Problemas de integração de módulos | Falta de comunicação entre o time, falta de padronização de código, falta de testes e de práticas de integração contínua e testes | Padronização, integração contínua, testes, comunicação forte entre time | Membros envolvidos se juntam para refatorar e integrar módulos conflitantes e aplicar os padrões pré-estabelecidos | Muito alto | Alto |
RT8 | Monitoramento de horas | Mal monitoramento de horas trabalhadas | Incentivo a registro de horas por parte do time | Uso de planilhas de presença, delegação de responsável por monitorar horas | Alto | Alto |
3.2 Riscos não técnicos
Risco | Descrição | Causa | Ação Preventiva | Ação reativa | Impacto | Probabilidade |
---|---|---|---|---|---|---|
RNT1 | Baixa comunicação e engajamento entre o time | Incompatibilidade de horários, falta de espaço para encontros, pouca sensação de "accomplishment" e de avanço, pouca sinergia e amizade entre o time, abandonos da disciplina | GPP sempre fomentando a comunicação no Slack, definição de um propósito comum do time, definição de local, dias e horários pré-definidos para encontros regulares, aproximação do cliente e definição de pequenos entregáveis com comemoração conjunta desses entregáveis, momentos de happy hour e integração, pessoas do time preocupados com seus "peers" de forma proativa, etc | Intervenção com reunião de grupo para reorganizar tarefas, identificar pontos de falha e definição em grupo de ações a serem realizadas. Ao identificar conflitos no time GPP deve tomar a liderança | Alto | Alto |
RNT2 | Falha no planejamento | Má definição de escopo, planejamento e cronograma | Definições minuciosa dos planos de projeto e documentos iniciais validadas por time e cliente e revisitadas/revisadas com frequência | Reconstrução imediata de artefatos com o time e cliente | Alto | Alto |
RNT3 | Estrapolar custo, sobrecarregar equipe e atrasar entregas | Mal planejamento e priorização de tarefas erradas | Reconhecimento e mensuração da capacidade de desenvolvimento do time, criação de cronogramas realistas e validados por todo o time e clientes, controle de horas de trabalho constantes por parte de GPP e ações proativas de forma a manter o ritmo ideal, questionamentos constantes com a equipe sobre satisfação dos mesmos com o projeto, sua performance, se está tudo dentro do planejado, etc | Reunião da equipe e replanejamento | Alto | Alto |
3.3 Riscos externos
Risco | Descrição | Causa | Ação Preventiva | Ação reativa | Impacto | Probabilidade |
---|---|---|---|---|---|---|
RE1 | Paralização da disciplina de MDS/GPP | Greve na universidade | Decisão conjunta da equipe quanto a continuar ou paralizar o projeto | Alto | Baixo | |
RE2 | Falha de comunicação e engajamento com o cliente | Incompatibilidade de horários e falta de interesse | Reuniões periódicas com o cliente, dar tarefas para os mesmos e fazê-los se sentir parte do processo de construção do software e entregáveis que os agradem e motivem, de forma que verão resultados | Intervenção e reunião com os clientes para reaproximação e definição de metas conjuntas, possivelmente começar a trabalhar junto com eles | Alto | Médio |
RE3 | Professores e monitores insatisfeitos | Falha de comunicação e desenvolvimento abaixo do nível esperado | Planejamento e evoluções transparentes e engajamento da equipe | Reunião do time e replanejamento | Alto | Médio |
RE4 | Clientes insatisfeitos | Entregáveis de baixa qualidade ou fora do esperado | Comunicação constante com os clientes, validação de artefatos, cronograma, escopo e entregáveis de forma conjunta, comunicação constante e entregáveis de qualidade e frequentes | Reunião da equipe para replanejamento e alinhamento com o cliente | Alto | Alto |
4 Gráfico de probabilidade x impacto
5. Responsável pelo relatório
Eduardo de Oliveira Castro.