Pense numa decisão real
A Conecta quer enviar mensagens automáticas. Podemos construir nosso próprio mecanismo? Contratar um serviço? Integrar algo pronto? Cada opção muda custo, prazo e dependência.
“Dá para fazer?” é uma pergunta grande demais
Vamos quebrá-la em perguntas menores:
Técnica
Temos tecnologia e conhecimento para construir e manter?
Econômica
O benefício justifica o custo?
Operacional
As pessoas realmente conseguirão usar esse novo processo?
Prazo
Conseguimos entregar no tempo necessário?
Legal
Existe alguma obrigação que precisa ser respeitada?
Organizacional
Quem ficará responsável pela solução e pelos dados?
Olhar essas dimensões é analisar a viabilidade da solução.
Construir, comprar ou integrar?
Essas três opções aparecem muito em tecnologia:
- Build — construir: fazer nós mesmos;
- Buy — comprar ou assinar: usar um produto ou serviço pronto;
- Integrate — integrar: conectar nossa solução a algo externo.
Na Conecta, podemos construir o núcleo da Ordem, contratar um serviço de mensagens e integrá-lo ao sistema.
Nenhuma opção é automaticamente melhor. Precisamos comparar custo, prazo, manutenção, dependência e adequação ao processo.
E se ainda não soubermos se uma ideia funciona?
Imagine que queremos receber confirmação de pagamento de um serviço externo. Antes de prometer isso no produto, podemos fazer um pequeno experimento para descobrir se a integração realmente funciona.
Esse pequeno experimento pode ser chamado de PoC — Proof of Concept, em português Prova de Conceito.
Ela não é o produto pronto. É apenas uma forma de responder uma dúvida técnica importante antes de apostar muito tempo nela.
Uma investigação curta com objetivo parecido também pode ser chamada de spike.
Agora pense no que pode dar errado
O serviço de mensagens pode ficar fora do ar. Um usuário pode deixar de atualizar a situação. Uma cópia de segurança pode falhar justamente quando for necessária.
Enquanto isso ainda é uma possibilidade, chamamos de risco. Quando já aconteceu, virou problema.
Risco
“O serviço de mensagens pode ficar indisponível.”
Problema
“O serviço de mensagens está indisponível agora.”
Nem todo risco merece a mesma atenção
Para decidir o que cuidar primeiro, fazemos duas perguntas: qual a chance de acontecer? e quanto prejudica se acontecer?
| ID | Risco | Chance | Impacto | O que podemos fazer |
|---|---|---|---|---|
| R01 | Serviço de mensagens indisponível | Média | Baixo/Médio | Registrar pendência e tentar depois |
| R02 | Usuários não atualizarem a situação | Média | Alto | Simplificar o fluxo, treinar e acompanhar |
| R03 | Perda de dados | Baixa | Alto | Cópia de segurança e restauração testada |
| R04 | Pagamento duplicado | Baixa | Alto | Evitar duplicação e manter auditoria |
O código R01 significa apenas “Risco 1”.
O que fazemos antes e o que fazemos se acontecer?
Mitigação
O que fazemos antes para reduzir a chance ou o impacto.
Contingência
O que faremos se o risco realmente acontecer.
Fazer e testar cópias de segurança é uma forma de mitigação. Ter um procedimento de recuperação é contingência.
Agora imagine uma mudança aparentemente pequena
O cliente pede: “Quero aprovar o orçamento diretamente pelo portal.”
Parece só um botão novo. Mas pense no que muda: quem pode aprovar? como confirmar que é realmente o cliente? como registrar a decisão? o Caso de Uso muda? o protótipo muda? os testes mudam?
Descobrir tudo que uma mudança afeta é fazer uma análise de impacto.
Como lembrar de onde cada coisa veio?
Pegue o requisito “Consultar situação”. Ele nasceu porque os clientes ligavam para perguntar o andamento. Depois virou objetivo do cliente, apareceu na tela de consulta e ganhou testes.
Essa capacidade de seguir o caminho para trás e para frente é chamada de rastreabilidade.
Ela responde duas perguntas muito úteis:
- Por que isso existe?
- Se isso mudar, o que mais pode ser afetado?
Quando existem muitas ligações, uma tabela ajuda
| Origem | Requisito | Regra | História/Caso | Tela | Teste |
|---|---|---|---|---|---|
| Cliente não sabe andamento | RF04 | — | Consultar andamento | Consulta da ordem | CT08 |
| Gerência exige aprovação | RF07 | RN01 | Registrar decisão | Orçamento | CT12 |
CT significa Caso de Teste. A tabela não existe para criar burocracia; existe para nos ajudar a encontrar origem, cobertura e impacto.
Premissa, restrição e dependência
Essas palavras ficam mais fáceis quando ligadas a perguntas:
- Premissa: o que estamos assumindo como verdadeiro?
- Restrição: o que limita nossas escolhas?
- Dependência: de que precisamos para conseguir avançar?
Depender de um fornecedor é uma dependência. Esse fornecedor ficar indisponível é um risco possível.
Faça agora
- Escolha uma decisão da Conecta e avalie se faz sentido técnica, econômica e operacionalmente.
- Explique construir, comprar e integrar usando um exemplo do projeto.
- Escolha um risco e diga chance, impacto e resposta.
- Explique a diferença entre mitigação e contingência.
- Pegue RF04 e conte a história desde o problema até o teste.
- Imagine uma mudança no portal e descubra o que mais precisaria ser revisto.
Vale a pena, o que pode dar errado e o que muda junto
Registre decisões de viabilidade, riscos importantes e as ligações entre origem, requisito, interface e teste.
Checkpoint 8 — Você consegue enxergar as consequências?
Quando uma ideia muda, você consegue dizer o que mais pode precisar de revisão e por quê?