Skip to content

Riscos do Projeto Sentinela

Introdução

O projeto Sentinela envolve o desenvolvimento colaborativo de um software e, para garantir seu sucesso, é essencial identificar, avaliar e mitigar os riscos que possam impactar o projeto. A seguir, são descritos os principais riscos mapeados, o produto entre sua probabilidade e impacto, resultando no grau do risco, além das estratégias de monitoramento contínuo. Abaixo pode-se visualizar o Mapeamento de Riscos e Gráfico de Riscos

Lista de Riscos do Projeto Sentinela

As categorias de riscos no projeto Sentinela são divididas em cinco grupos principais: Organizacional, Técnico, Qualidade, Gerência e Externo. Os riscos organizacionais envolvem desafios relacionados ao comprometimento da equipe, comunicação e motivação, podendo gerar atrasos e conflitos internos. Os técnicos abordam dificuldades com tecnologias, arquitetura, deploy e ambientação, que podem impactar diretamente o desenvolvimento e entrega da aplicação. Já os riscos de qualidade tratam de problemas como ausência de testes, falhas de UX/UI e má prática no processo de desenvolvimento, afetando a experiência do usuário e a adequação do produto aos requisitos. Na categoria de gerência, estão os riscos relacionados à definição de escopo, gestão de tempo, cronograma e pontuação de US, que podem comprometer o andamento eficiente do projeto. Por fim, os riscos externos são imprevistos fora do controle da equipe, como suspensão de aulas, infraestrutura inadequada e afastamento de integrantes, que podem gerar interrupções no progresso do projeto.

1. Organizacional

  1. Falha de comunicação
  2. Descomprometimento da equipe
  3. Erro de priorização
  4. Desistência de membros
  5. Desavenças entre os membros
  6. Tensão de fim de semestre
  7. Falta de motivação
  8. Atraso nas entregas

2. Técnico

  1. Dificuldade em criar backlog
  2. Má escolha das tecnologias
  3. Dificuldade de ambientação
  4. Arquitetura mal definida
  5. Dificuldade de deploy da aplicação
  6. Dificuldade em hospedar a aplicação
  7. Documentação que induz ao erro
  8. Dificuldade com as tecnologias

3. Qualidade

  1. Ausência de testes
  2. Falhas e bugs
  3. Má implementação de UX
  4. Má implementação de UI
  5. Má prática do processo de desenvolvimento
  6. Aplicação não atender expectativas do usuário
  7. Não cumprimento dos requisitos elicitados
  8. Falta de validação com o stakeholder

4. Gerência

  1. Escopo mal definido
  2. Mudança arquitetural
  3. Má gestão do tempo
  4. Cronograma inviável
  5. Má pontuação das US
  6. Problema no gerenciamento da equipe
  7. Sobrecarga de tarefas
  8. Mudanças de tecnologias
  9. Horários divergentes dos integrantes

5. Externo

  1. Suspensão das aulas
  2. Baixa adesão da aplicação
  3. Imprevistos com infraestrutura (internet, energia, computador)
  4. Afastamento de integrante (enfermidade, luto, assistência familiar)
  5. Atualizações drásticas das tecnologias escolhidas

Monitoramento Contínuo dos Riscos

Gerenciar os riscos é um processo contínuo e dinâmico. Ao longo do desenvolvimento do projeto Sentinela, novos riscos podem surgir e os riscos existentes podem aumentar ou diminuir em impacto e probabilidade. É essencial que a equipe:

  • Realize revisões regulares dos riscos identificados.
  • Esteja atenta a novos riscos que possam aparecer.
  • Ajuste as estratégias de mitigação conforme necessário.
  • Documente qualquer mudança no impacto e probabilidade dos riscos.

Esse monitoramento constante permite que a equipe reaja proativamente às mudanças e mantenha o controle sobre os fatores que podem afetar o sucesso do projeto.

Planejamento de respostas aos riscos

# Risco Ação Solução
1 Falha de comunicação Mitigar Incentivar dailys, comentários em PRs e no grupo do telegram.
2 Descomprometimento da Equipe Mitigar Incentivar dailys, comentários em PRs e no grupo do telegram.
3 Erro de Priorização Prevenir Definir a prioridade e seguir a documentação
4 Desistência de Membros Aceitar Realocar tarefas para os membros restantes
5 Desavenças entre os membros Prevenir Respeitar tempo, opinião e limitações dos membros, ser empático
6 Tensão de fim de semestre Mitigar Não acumular tarefas para o fim de semestre, manter clima empático
7 Falta de motivação Prevenir Incentivar dailys, mostrar propósito e impacto das suas ações
8 Atraso nas entregas Prevenir Dar prioridade às tarefas, saber dividir o cronograma das sprints
9 Dificuldade com as tecnologias Mitigar Estudar previamente e fazer pareamentos conforme o quadro de conhecimento
10 Dificuldade em criar backlog Prevenir Definir backlog com todos os membros e clientes
11 Má escolha das tecnologias Prevenir Estudar sobre as tecnologias de acordo com a arquitetura definida
12 Dificuldade de ambientação Mitigar Estudar sobre as tecnologias utilizadas
13 Arquitetura mal definida Prevenir Estudar sobre arquitetura, validar com a professor
14 Dificuldade de deploy da aplicação Mitigar Estudar sobre as tecnologias utilizadas
15 Dificuldade em hospedar a aplicação Mitigar Estudar sobre as tecnologias utilizadas
16 Documentação que induz ao erro Prevenir Valorizar a fase de documentação e mantê-la atualizada
17 Ausência de testes Mitigar Colocar testes unitários como critério de aceitação
18 Falhas e bugs Mitigar Dedicar issues de bugs e refatoração
19 Má implementação de UX Prevenir Testar todas as fases com as clientes
20 Má implementação de UI Prevenir Estudar sobre UI e testar todas as fases com as clientes
21 Má prática do processo de desenvolvimento Prevenir Estudar boas práticas de programação
22 Aplicação não atender expectativas do usuário Prevenir Testar todas as fases com as clientes, recebendo feedbacks
23 Não cumprimento dos requisitos elicitados Prevenir Estar alinhado com a documentação
24 Falta de validação com o stakeholder Prevenir Manter contato com o stakeholder
25 Escopo mal definido Prevenir Ter as principais funcionalidades bem definidas
26 Mudança Arquitetural Prevenir Estudar sobre arquitetura, validar com a professor
27 Má gestão do tempo Prevenir Definir entregas e atividades
28 Cronograma inviável Mitigar Fazer planejamento conforme as entregas definidas
29 Má pontuação das US Prevenir Definir a pontuação com todos os membros
30 Estouro de Sprint Mitigar Planejar cada sprint, mantendo contato frequente
31 Falta de recurso humano Mitigar Estimar sprints de acordo com a capacidade da equipe
32 Dívida técnica Mitigar Dedicar issues de bugs e refatoração
33 Estimativas irreais Prevenir Fazer planejamento conforme as entregas definidas
34 Mudanças de requisitos Mitigar Manter as mudanças documentadas e atualizadas
35 Falta de autonomia da equipe Mitigar Definir tarefas claras, todos precisam contribuir
36 Clientela insatisfeita Mitigar Estar em constante contato com as clientes
37 Rotatividade do time Aceitar Realocar tarefas para os membros restantes
38 Erro de deploy Mitigar Estudar sobre as tecnologias utilizadas

Análise

  • Organizacional: Os riscos organizacionais estão ligados à interação e ao comprometimento da equipe. A falha na comunicação, desmotivação e tensões internas podem atrasar o projeto, enquanto o descomprometimento e desistência de membros impactam diretamente a capacidade de entrega.
  • Técnicos: Problemas técnicos surgem principalmente de escolhas erradas ou falta de preparação com as tecnologias e arquitetura. Aexperiencia do time de EPS se torna cricial para controlar os riscos correspondentes.
  • Qualidade: Os riscos relacionados à qualidade envolvem falhas em testes, implementação de UX/UI, e não atendimento das expectativas do cliente. A execução de testes e validação com stakeholders leva à entrega de produtos sem bugs e que atendem às necessidades elicitadas.
  • Gerência: Na categoria gerencial, a má gestão de escopo, tempo e cronograma pode inviabilizar o projeto. Para prevenir os riscos em questão durante todo o projeto escopo e tempo serão monitorados atravéz do documento AgileEVM.
  • Externo: Os riscos externos são imprevisíveis, como imprevistos com infraestrutura e afastamento de integrantes por motivos de saúde ou familiares.Portanto são riscos aos quais a equipe não possui controle.

Histórico de Versão

Alteração Data Autor
Criação do documento 22/07/24 Victor Yukio
Atualização dos riscos 08/09/24 Ingrid Carvalho
Revisão 08/09/24 Sara Campos
Adição da análise dos riscos 14/09/24 Ingrid Carvalho