Skip to main content

Matriz de Riscos

A matriz de riscos é uma ferramenta fundamental na gestão de projetos, projetada para identificar, categorizar e gerenciar riscos potenciais ao longo de todo o projeto. Com a flexibilidade para se ajustar conforme novos eventos surgem, ela ajuda a visualizar a probabilidade e o impacto de cada risco, facilitando a priorização de ações de mitigação. Além de abordar os riscos, a matriz também considera oportunidades que podem aumentar o valor do projeto, permitindo uma abordagem mais estratégica.

info

Todos os itens dispostos na matriz de risco vão estar descritos logo abaixo para melhor compreensão de onde pode-se encontrar os verdadeiros riscos/oportunidades e como mitigá-los/potencializá-los

Figura 1 - Matriz de Riscos

Matriz de Risco

Fonte: Elaborado pela equipe do Murilove

Entendendo as Ameaças e as Oportunidades da Matriz de Risco

Ameaças​

Dependências de pacotes externos: O Flutter utiliza diversos plugins e bibliotecas de terceiros (ex: mapas, câmera, geolocalização). Se esses pacotes ficarem desatualizados, apresentarem vulnerabilidades ou deixarem de ser mantidos, o aplicativo pode ter funcionalidades críticas comprometidas (ex: falha no envio de fotos de problemas no trem). Além disso, atualizações repentinas podem quebrar a compatibilidade com o código existente.

Performance em dispositivos antigos: Apesar do Flutter ser otimizado, dispositivos com hardware limitado (ex: memória RAM insuficiente ou processadores lentos) podem enfrentar lentidão, especialmente em funcionalidades que demandam alto processamento (ex: cálculo de rotas em tempo real ou exibição de mapas). Isso pode levar a uma experiência ruim para parte dos usuários da CPTM, que podem não ter smartphones top de linha.

Problemas com atualizações do Flutter: O framework Flutter passa por atualizações frequentes que, embora tragam melhorias, podem introduzir bugs ou mudanças incompatíveis com o código atual do app. Por exemplo, uma atualização pode afetar plugins essenciais (ex: integração com APIs da CPTM), exigindo refatoração não planejada e atrasando o cronograma.

Dificuldade em escalar o App: Se o aplicativo ganhar muitos usuários rapidamente (ex: após um lançamento em grande escala pela CPTM), a infraestrutura backend (ex: servidores de APIs ou banco de dados) pode não suportar a demanda, causando lentidão ou falhas no serviço. Funcionalidades como notificações de SOS ou atualização de rotas em tempo real são especialmente sensíveis a picos de acesso.

Problemas com notificação em tempo real: O sistema de alertas (ex: SOS para guardas ou avisos sobre problemas no trem) depende de notificações push confiáveis. Falhas na entrega (ex: devido a instabilidade na rede do metrô ou limitações do Firebase Cloud Messaging) podem impedir que usuários recebam assistência crítica, comprometendo a utilidade principal do app.

Não satisfazer as expectativas da CPTM: A CPTM pode ter requisitos específicos não documentados (ex: padrões de segurança adicionais ou integração com sistemas internos) que, se não atendidos, podem levar a rejeição do projeto. Além disso, mudanças nas prioridades da empresa (ex: cortes de orçamento) podem reduzir o apoio ao desenvolvimento.

Problemas de usabilidade e adesão do público: Se o aplicativo for complexo (ex: fluxo confuso para reportar problemas no trem) ou não resolver necessidades reais dos passageiros (ex: tempos de trem imprecisos), a adoção pode ser baixa. Isso prejudicaria a justificativa do investimento e a parceria com a CPTM.

Troca de tecnologia no meio do projeto: Caso a CPTM exija migrar para outra tecnologia (ex: mudança abrupta para React Native ou desenvolvimento nativo) devido a políticas internas ou limitações do Flutter, o projeto teria que ser parcial ou totalmente refeito, gerando custos extras e atrasos significativos.

Oportunidades​

Projeto ser escolhido pela empresa: O aplicativo pode ser adotado oficialmente pela CPTM como solução padrão para passageiros, integrando-se aos seus sistemas operacionais (ex: painéis de estações ou comunicação interna). Isso garantiria visibilidade em larga escala, financiamento contínuo e possibilidade de expansão para outras funcionalidades (ex: integração com bilhetagem eletrônica). Além disso, a validação da CPTM serviria como um selo de confiabilidade para atrair mais usuários.

App ser colocado em produção: A entrada em produção significaria que o app está estável e pronto para uso massivo, consolidando a parceria com a CPTM e gerando dados reais de utilização. Isso permitiria ajustes baseados em feedback dos passageiros (ex: otimização de rotas ou inclusão de novos serviços, como alertas de lotação). Além disso, abriria portas para parcerias comerciais (ex: patrocínios ou publicidade segmentada dentro do app).

Ultrapassar as expectativas do cliente: Se o aplicativo entregar funcionalidades além do planejado (ex: integração com serviços urbanos como ônibus ou bike-sharing, ou uso de IA para prever atrasos), a CPTM poderá ampliar seu escopo de atuação (ex: transformá-lo em um "app multimodal"). Isso fortaleceria a imagem da empresa como inovadora em mobilidade urbana, atraindo investimentos e potencializando o impacto social (ex: redução de tempo de deslocamento para PCDs).

Poder competitivo com os outros App's: O app pode se destacar ao oferecer dados oficiais da CPTM e funcionalidades exclusivas como:

  • SOS integrado com a equipe das estações

  • Rotas acessíveis para PCDs com status de elevadores

  • Alertas em tempo real sobre problemas operacionais

Esses diferenciais, somados ao selo de app recomendado pela CPTM, criariam vantagens competitivas contra soluções genéricas como Google Maps e Moovit. A integração direta com os sistemas da operadora permitiria informações mais precisas e atualizadas, enquanto features como gamificação (ex: pontos por uso frequente) aumentariam o engajamento.

Planos de Prevenção e Ataque

  Além da criação da Matriz de Risco, também é desenvolvido um plano de prevenção para evitar que os riscos se concretizem, bem como um plano de ação para lidar com os riscos caso eles se tornem realidade.

1. Dependências de pacotes externos​

Prevenção:

  • Validar a reputação e manutenção dos pacotes antes da integração (ex: GitHub Stars, última atualização).
  • Fixar versões específicas no pubspec.yaml para evitar atualizações inesperadas.

Ataque:

  • Criar wrappers próprios para funções críticas (ex: envio de fotos), reduzindo dependência direta de plugins.
  • Monitorar vulnerabilidades com ferramentas como Dependabot e ter um plano de substituição rápida.

2. Performance em dispositivos antigos​

Prevenção:

  • Testar o app em dispositivos low-end (ex: Android 8+, 2GB RAM) durante o desenvolvimento.
  • Otimizar assets (imagens compressas) e evitar animações complexas em telas essenciais.

Ataque:

  • Implementar um "modo light" opcional (ex: desativar mapas 3D) para dispositivos limitados.
  • Usar flutter_devtools para identificar e corrigir gargalos de performance.

3. Problemas com atualizações do Flutter​

Prevenção:

  • Manter o projeto em um canal estável do Flutter (ex: stable, não beta).
  • Documentar todas as versões de dependências no pubspec.lock.

Ataque:

  • Isolar módulos críticos em packages separados para facilitar migrações.
  • Ter um ambiente de teste dedicado para validar atualizações antes de aplicar ao projeto principal.

4. Dificuldade em escalar o App​

Prevenção:

  • Projetar a arquitetura para escalabilidade desde o início (ex: Firebase + Cloud Functions).
  • Implementar cache offline para dados essenciais (ex: horários de trens).

Ataque:

  • Usar balanceamento de carga (load balancing) em APIs críticas (ex: SOS).
  • Monitorar métricas em tempo real (ex: Firebase Performance) para ajustar recursos sob demanda.

5. Problemas com notificação em tempo real​

Prevenção:

  • Usar serviços confiáveis como Firebase Cloud Messaging (FCM) com fallback para SMS.
  • Testar notificações em cenários de baixa conectividade (ex: túneis de metrô).

Ataque:

  • Implementar confirmação de recebimento (ex: callback do usuário ao abrir o alerta).
  • Criar filas de retentativa para mensagens não entregues.

6. Não satisfazer as expectativas da CPTM​

Prevenção:

  • Alinhar requisitos com a CPTM em documentos formais (ex: Termo de Abertura de Projeto).
  • Entregar protótipos funcionais para validação contínua.

Ataque:

  • Criar um roadmap flexível para incorporar feedbacks rápidos.
  • Designar um "embaixador do projeto" na CPTM para facilitar comunicação.

7. Problemas de usabilidade e adesão do público​

Prevenção:

  • Realizar testes de usabilidade com passageiros reais antes do lançamento.
  • Priorizar acessibilidade (ex: leitor de tela, contrastes altos).

Ataque:

  • Lançar campanhas educativas nas estações (ex: tutoriais em vídeo).
  • Implementar analytics (ex: Hotjar) para identificar pontos de abandono no app.

8. Troca de tecnologia no meio do projeto​

Prevenção:

  • Documentar toda a arquitetura e decisões técnicas para facilitar migrações.
  • Manter a modularização alta (ex: separar lógica de negócios da UI).

Ataque:

  • Ter um plano de migração gradual (ex: manter versões paralelas durante a transição).
  • Treinar a equipe em tecnologias alternativas (ex: React Native) como contingência.

Monitoramento Contínuo​

  • Checkpoints/Entrega de Sprints: Revisões a cada duas semanas com a CPTM e features que estejam condizente com o que eles estão esperando em relação ao App.

Referências

[1] REDACAO PAPOCA. O que é matriz de risco? Aprenda como montar + exemplo. Esfera Energia. Disponível em: https://blog.esferaenergia.com.br/gestao-empresarial/matriz-de-risco. Acesso em: 08 agosto. 2024.