O exemplo 2 de uso do MASP (Método de Análise e Solução de Problemas), com IA (Inteligência Artificial) em TI (Tecnologia da Informação), apresenta uma situação de especificação incompleta que causou uma falha num aplicativo.
Exemplo de Prompt estruturado com MASP
1CONTEXTO
1.1 Correção de bug no app VoteNet.
1.1.1 Descrição do bug: No ambiente de Homologação, a URL está inválida. Em vez de aparecer https://homologacao.votenet.net/signup/, apareceu https://votenet.com.br/invite/.
1.1.2 Frontend:
1.1.2.1 ReactJS v15.6.1
1.1.2.2 Node v6.17.1
1.1.2.3 NPM v3.10.10
1.1.3 Axios v.0.26.0: comunicação via API, chamando funções do arquivo ajax_utils.js.
1.1.4 Backend: Django v4.2.3
1.1.4.1 Aplicação: N/a
1.1.4.2 model: N/a
1.1.4.3 views: N/a
1.1.5 Infraestrutura: AWS
2IDENTIFICAÇÃO DO PROBLEMA
Um problema é caracterizado pela diferença entre o que é e o que deveria ser. As perguntas abaixo (5W1H) ajudarão a caracterizar o problema, com detalhes do cenário.
[What?] O que está acontecendo?
Está acontecendo um bug no aplicativo VoteNet.
[Who?] Quem está envolvido?
Quem está envolvido é o usuário responsável pela homologação.
[When?] Quando ocorreu?
Ocorreu quando o usuário clicou no botão “Copiar link de convite”, localizado na rede à direita da foto do convidado, e o link foi gravado na Área de Transferência.
[Where?] Onde aconteceu?
Aconteceu no componente SectionInvites.jsx.
[Why?] Por que isso é um problema?
Porque no link de convite, em vez de aparecer https://homologacao.votenet.net/signup/, apareceu https://votenet.com.br/invite/.
[How?] Como surgiu?
Surgiu após o clique no botão “Copiar link de convite”, que formatou o link de convite com a URL diferente daquela onde está sendo executado o aplicativo.
3Observação:
Investigue características específicas do problema usando o Diagrama de Ishikawa (Causa e Efeito). Registre “SIM”, “NÃO” ou “NÃO SEI”, para fatores como:
3.1. Método (A Lógica)
Regras de Negócio: O algoritmo está aplicando a regra correta? NÃO
Fluxo do Processo: Existe algum "nó" na sequência da automação (ex: um passo que tenta rodar antes do anterior terminar)? NÃO SEI
Tratamento de Erros: O código sabe o que fazer quando recebe uma resposta inesperada? NÃO SEI
3.2. Máquina (Infraestrutura/Software)
Ambiente: O erro ocorre em produção, mas não em homologação? NÃO
Recursos: Há falta de memória, timeout de servidor ou falha na conexão com o banco de dados? NÃO SEI
Versões: Bibliotecas ou frameworks desatualizados estão gerando conflitos? NÃO SEI, mas esta é uma hipótese a ser analisada.
3.3. Mão de Obra (Intervenção Humana)
Desenvolvimento: Houve falha na escrita do código ou falta de revisão (code review)? SIM (falha na formatação do link de convite)
Testes: O cenário que gerou o bug foi previsto no plano de testes? NÃO
Operação: Alguém alterou uma configuração manualmente que quebrou a automação? NÃO SEI
3.4. Medida (Dados e Monitoramento)
Input de Dados: O bug é causado por um caractere especial ou campo vazio que a automação não esperava? SIM (é causado por um texto diferente do esperado)
Logs: O sistema está gerando registros suficientes para rastrear onde o erro começa? SIM
Métricas: O erro acontece após um número X de execuções (vazamento de memória)? NÃO
3.5. Material (Integrações/APIs)
Dependências Externas: Uma API de terceiros mudou o formato do JSON ou está fora do ar? NÃO SEI
Qualidade dos Dados: A base de dados que alimenta a automação contém informações corrompidas? NÃO SEI
3.6. Meio Ambiente (Contexto de Execução)
Conectividade: Instabilidade na rede afetou a troca de pacotes? NÃO SEI
Simultaneidade: Outro processo automatizado está tentando acessar o mesmo recurso ao mesmo tempo? NÃO SEI
4Análise:
Para cada fator identificado na etapa anterior, utilize os “5 Porquês” para encontrar a causa raiz.
4.1 Método (A Lógica)
Por quê? Porque não foi especificada uma regra de formação da URL.
Por quê? Porque quem especificou não sabia qual a regra de formação.
Por quê? Porque quem especificou imaginou que quem ia codificar sabia a regra de formação.
Por quê? Porque quem ia codificar era uma ferramenta de IA.
Por quê? Porque quem especificou (eu mesmo) escolheu a IA por conhecer pouco do aplicativo e da linguagem de programação do Frontend, sendo, portanto, incapaz de garantir a integridade das informações fornecidas nas especificações.
4.2 Máquina (Infraestrutura/Software)
Por quê? NÃO SEI
4.3 Mão de Obra (Intervenção Humana)
Por quê? NÃO SEI
4.4 Medida (Dados e Monitoramento)
Por quê? NÃO SEI
4.5 Material (Integrações/APIs)
Por quê? NÃO SEI
4.6 Meio Ambiente (Contexto de Execução)
Por quê? NÃO SEI
5. Comando:
Atue como um Especialista em Qualidade de Software e Metodologia MASP (Método de Análise e Solução de Problemas).
Estou analisando um bug em um processo automatizado dentro do aplicativo VoteNet, implementado no componente SectionInvites.jsx, em anexo.
Com base nas 3 primeiras etapas do MASP especificadas acima, elabore a etapa 4 de "Plano de Ação" (formato 5W2H) focando no bloqueio e correção definitiva das causas.
Resultado do Prompt estruturado com MASP
Olá, Gustavo. A sua análise de causa raiz usando os 5 Porquês no método MASP foi cirúrgica. Ao identificar que o erro "nasceu" da especificação de uma URL fixa (hardcoded) no momento em que o código foi gerado, você isolou perfeitamente o ponto de falha no método (A Lógica).
Abaixo, elaboro o Plano de Ação estruturado e, em seguida, forneço o código corrigido, mantendo total compatibilidade com a arquitetura baseada em classes do seu ambiente React 15.6.1.
4. Plano de Ação (5W2H)
What? (O que será feito): Substituição da URL estática (https://votenet.com.br/invite/) por uma construção dinâmica que capture o domínio real do ambiente em execução e aponte para a rota de cadastro correta.
Why? (Por que será feito): Para garantir que o link copiado para a área de transferência espelhe o ambiente atual (Desenvolvimento, Homologação ou Produção), corrigindo o desvio onde o ambiente de homologação estava gerando um link de produção com uma rota diferente da esperada.
Who? (Quem fará): O desenvolvedor responsável pela manutenção do Frontend do VoteNet.
Where? (Onde será feito): No arquivo SectionInvites.jsx, especificamente dentro da função _copyInviteLink(uuid).
When? (Quando será feito): Imediatamente, dentro da atual iteração de testes e correções de homologação.
How? (Como será feito): Alterando a declaração da variável inviteUrl. Será utilizada a propriedade nativa do navegador window.location.origin para extrair a raiz do domínio em tempo real, concatenando-a de forma padronizada com o caminho /signup/${uuid}.
How Much? (Quanto custará): Sem custo financeiro. Exigirá apenas o tempo de refatoração pontual e um novo deploy no ambiente AWS.
Correção no Código-Fonte
Localize o método _copyInviteLink no seu arquivo SectionInvites.jsx e substitua-o integralmente pelo bloco abaixo:
JavaScript
_copyInviteLink(uuid) {
// Constrói a URL dinamicamente baseada no ambiente atual (origin) e aponta para a rota de signup
const inviteUrl = `${window.location.origin}/signup/${uuid}`;
if (navigator.clipboard && navigator.clipboard.writeText) {
navigator.clipboard.writeText(inviteUrl).then(() => {
Materialize.toast("Link copiado para a área de transferência!", 4000);
}).catch(err => {
console.error('Erro ao copiar link: ', err);
alert("Erro ao copiar link.");
});
} else {
// Fallback para navegadores sem suporte a clipboard API
alert("Link: " + inviteUrl);
}
}
Resumo técnico do bloqueio da causa:
Removemos o engessamento causado pela string https://votenet.com.br/invite/${uuid}. Ao utilizar ${window.location.origin}/signup/${uuid}, o componente herda a inteligência de saber onde está rodando. Se o acesso vier de https://homologacao.votenet.net, o sistema irá gerar e copiar automaticamente https://homologacao.votenet.net/signup/[UUID], respeitando perfeitamente o ambiente de testes.
Do Problema à Solução - Áudio
Do Problema à Solução - Vídeo
Guia Prático MASP: Transformando Falhas em Soluções (Case VoteNet)
Bem-vindo ao seu guia sobre o MASP (Método de Análise e Solução de Problemas) . Como especialista em engenharia de qualidade e mentor, meu objetivo é demonstrar que resolver um bug vai muito além de "trocar uma linha de código". O MASP é um roteiro sistemático que nos ajuda a entender por que um erro aconteceu e como garantir que ele nunca mais volte, protegendo a integridade do produto.Neste guia, utilizaremos o caso real do aplicativo VoteNet para ilustrar como transformar um erro de execução em uma solução robusta.
1. Introdução ao MASP e Contexto do Problema
O MASP é um processo racional e estruturado para a resolução de problemas e melhoria de processos. Na engenharia de software, ele é vital para evitar o "ciclo de correções paliativas", onde um erro é corrigido superficialmente apenas para ressurgir depois.
O Cenário: Aplicativo VoteNet
O VoteNet é uma aplicação moderna que utiliza uma stack robusta, mas que apresentou uma falha crítica durante a fase de homologação (testes finais).Stack Tecnológica:
Frontend: ReactJS v15.6.1, Node v6.17.1, NPM v3.10.10.
Comunicação: Axios v.0.26.0 (ajax_utils.js).
Backend: Django v4.2.3.
Infraestrutura: AWS (Amazon Web Services).O Bug de Homologação
URL Esperada: https://homologacao.votenet.net/signup/
URL Obtida: https://votenet.com.br/invite/Impacto Técnico: O link de convite gerado aponta para o domínio de produção com uma rota inexistente, impedindo novos cadastros no ambiente de testes.Antes de qualquer tentativa de correção, como mentores de qualidade, precisamos diagnosticar o problema com precisão antes de tentar corrigi-lo.
2. Etapa 1: Identificação (O Diagnóstico 5W1H)
Na metodologia MASP, definimos um problema como a diferença entre o que é e o que deveria ser . Para caracterizar essa lacuna no VoteNet, utilizamos a técnica 5W1H para garantir que todos os envolvidos compreendam a extensão do desvio.
Identificado o sintoma e o local exato do erro, precisamos observar os fatores que o cercam para não sermos enganados por impressões superficiais.
3. Etapa 2: Observação (Causa e Efeito com Ishikawa)
Utilizamos o Diagrama de Ishikawa (Espinha de Peixe) para investigar as características do problema sob seis perspectivas fundamentais, rastreando onde a qualidade foi comprometida.
Método (A Lógica)
Regras de Negócio: O algoritmo aplica a regra correta? NÃO .
Fluxo do Processo: Existe um "nó" na automação? NÃO SEI .
Tratamento de Erros: O código sabe lidar com respostas inesperadas? NÃO SEI .
Máquina (Infraestrutura/Software)
Ambiente: O erro ocorre apenas em produção? NÃO .
Recursos: Há falta de memória ou falha de conexão? NÃO SEI .
Versões: Bibliotecas desatualizadas geram conflito? NÃO SEI (Hipótese em análise: verificar se versões de Node/NPM impactam o build).
Mão de Obra (Intervenção Humana)
⚠️ Desenvolvimento: Houve falha na escrita do código ou falta de revisão? SIM .
Impacto: Falha direta no funil de aquisição; novos usuários não conseguem se cadastrar durante a fase de testes, bloqueando o cronograma.
Testes: O cenário foi previsto no plano de testes? NÃO .
Medida (Dados e Monitoramento)
⚠️ Input de Dados: O bug é causado por um texto inesperado? SIM .
Impacto: Inconsistência de dados que impede a criação de contas válidas e gera erros 404 no ambiente de homologação.
Logs: O sistema gera registros suficientes? SIM .
Material (Integrações/APIs)
Dependências Externas: API de terceiros mudou? NÃO SEI .
Meio Ambiente (Contexto de Execução)
Conectividade ou Simultaneidade: Problemas de rede ou acesso concorrente? NÃO SEI .Após observar esses fatores, percebemos que o foco deve estar no Método e na Mão de Obra. Agora, é preciso mergulhar na causa raiz de cada um.
4. Etapa 3: Análise (A Técnica dos 5 Porquês)
Como mentores, sabemos que o "5º Porquê" geralmente revela uma falha de processo ou de julgamento humano, não apenas técnica. Focaremos no fator crítico: Método (A Lógica) .
Por que a URL estava inválida? Porque não foi especificada uma regra de formação da URL.
Por que não foi especificada? Porque quem especificou não sabia qual era a regra de formação correta.
Por que não sabia? Porque imaginou que quem iria codificar já conhecia a regra.
Por que houve esse pressuposto? Porque quem ia codificar era uma ferramenta de IA.
Por que a IA falhou? Porque quem especificou conhecia pouco do aplicativo e da linguagem Frontend, sendo incapaz de garantir a integridade das instruções passadas para a IA.Causa Raiz: O uso de Inteligência Artificial para codificação baseado em especificações incompletas (URL Hardcoded ) e o desconhecimento técnico sobre a necessidade de paridade de ambiente e regras de formação dinâmica.A descoberta da causa raiz é o gatilho para a criação de um plano de ação eficaz.
5. Etapa 4: Plano de Ação (A Estratégia 5W2H)
Não basta saber o que está errado; precisamos de uma estratégia de bloqueio definitiva para garantir a Environment Parity .
A estratégia agora ganha forma através da sua implementação técnica direta.
6. Implementação e Bloqueio da Causa Raiz
A solução técnica abandona o erro de deixar URLs fixas e passa a usar a inteligência do navegador. Ao utilizar window.location.origin, o software se torna agnóstico ao ambiente.
Código Corrigido
_copyInviteLink(uuid) {
// Solução MASP: Tornando a URL dinâmica para garantir paridade entre ambientes
const inviteUrl = `${window.location.origin}/signup/${uuid}`;
if (navigator.clipboard && navigator.clipboard.writeText) {
navigator.clipboard.writeText(inviteUrl).then(() => {
Materialize.toast("Link copiado para a área de transferência!", 4000);
}).catch(err => {
console.error('Erro ao copiar link: ', err);
alert("Erro ao copiar link.");
});
} else {
// Fallback para navegadores sem suporte a clipboard API
alert("Link: " + inviteUrl);
}
}
Benefícios da Correção (Bloqueio da Causa Raiz):
Herança de Inteligência: O componente identifica o domínio atual sem intervenção humana.
Environment Parity (Paridade de Ambiente): O mesmo código funciona perfeitamente em Localhost, Homologação e Produção.
Escalabilidade: Elimina a necessidade de manutenção manual caso o domínio do projeto mude no futuro.Tão importante quanto a correção técnica é o registro do aprendizado para evitar que falhas semelhantes se repitam.
7. Conclusão e Lições para o Estudante
O uso do MASP nos permitiu sair do nível superficial do "conserto" para o nível da engenharia. Identificamos que a falha não foi da IA, mas da supervisão técnica sobre ela.Principais Insights:
A importância da especificação: O código é o resultado direto da qualidade da instrução. Uma especificação incompleta gera uma Root Cause de falha lógica.
O risco de IA sem supervisão: Ferramentas de IA são aceleradores, mas jamais substituem o Code Review e o pensamento crítico do engenheiro.
Priorize a automação dinâmica: Evitar valores Hardcoded é uma regra de ouro para garantir que o software seja resiliente a diferentes contextos de infraestrutura.Dominar o MASP é o que diferencia um programador que apenas escreve linhas de código de um verdadeiro Engenheiro de Qualidade . Aplique este método no seu próximo desafio e observe a qualidade das suas soluções subir de nível.
Quando a IA Alucina o Código: O que um Link Quebrado no VoteNet nos Ensina sobre Especificação
1. Introdução: O Mistério do Link Fantasma
Imagine o cenário: estamos na reta final de uma bateria de testes em um ambiente de homologação robusto na AWS. O sistema VoteNet parece impecável, a interface React 15.6.1 responde bem e o backend em Django está estável. No entanto, um detalhe crítico surge durante a validação manual: ao clicar no botão "Copiar link de convite", o sistema gera https://votenet.com.br/invite/ em vez da URL esperada para aquele estágio, que seria https://homologacao.votenet.net/signup/.Este não é apenas um erro de interface. É um aviso de falha no deployment pipeline . Se esse comportamento não tivesse sido capturado em homologação, o bug teria chegado à produção, comprometendo a entrada de novos usuários e expondo uma quebra severa na paridade de ambientes. O que parecia um erro "básico" revelou uma falha profunda na forma como estamos delegando lógica de negócio a ferramentas de IA.
2. O Perigo do "Hardcoded" em um Mundo Ágil
O diagnóstico técnico imediato revelou um erro clássico: o link estava "chumbado" (hardcoded) no componente SectionInvites.jsx. Em uma arquitetura moderna que transita entre múltiplos estágios (Dev, Homologação e Produção), o uso de strings fixas é uma dívida técnica que ignora a dinâmica da infraestrutura.Ao inserir uma URL estática, o desenvolvedor (ou a ferramenta de IA) remove a capacidade do código de ser context-aware (consciente do contexto). Em ecossistemas AWS, onde cada ambiente possui seu próprio subdomínio, essa rigidez impede a portabilidade do software. A conveniência momentânea de uma string fixa gera um risco operacional alto, transformando um recurso simples em um ponto de falha que invalida o processo de teste automatizado.
3. A Armadilha da Confiança Cega na IA
A análise de causa raiz através dos "5 Porquês" revelou algo inquietante. O bug não foi um mero descuido de digitação, mas uma alucinação lógica da IA aceita sem questionamento. O especificador, possuindo pouco domínio técnico sobre o Frontend e as minúcias do app, utilizou a IA para preencher lacunas de conhecimento.O resultado foi uma ironia amarga: a ferramenta utilizada para diminuir o gap de conhecimento técnico acabou ampliando o gap de qualidade. A IA não apenas errou o domínio, mas "alucinou" o próprio caminho (path) da rota, trocando o correto /signup/ por um inexistente /invite/. Ela tentou adivinhar a lógica de negócio sem ter o contexto necessário."O erro nasceu porque quem especificou imaginou que a ferramenta de IA já conhecia as regras de formação da URL."
4. MASP: O Método por Trás da Solução
Para evitar correções superficiais, aplicamos o MASP (Método de Análise e Solução de Problemas) . Essa disciplina foi essencial para isolar a causa raiz e entender que o problema não era a infraestrutura, mas o processo humano e metodológico. Utilizamos as seguintes ferramentas:
5W1H : Para delimitar o desvio entre o comportamento esperado e o real.
Diagrama de Ishikawa : Identificamos falhas em "Método" (lógica de formação da URL) e, crucialmente, em "Mão de Obra".
5 Porquês : Para chegar à falha na especificação assistida por IA.
5W2H : Para estruturar o plano de ação corretivo.A análise pelo Ishikawa destacou um ponto vital: o cenário que gerou o bug sequer estava previsto no plano de testes original. Houve uma falha dupla — tanto na escrita do código quanto na revisão (code review), provando que ferramentas de IA sem supervisão técnica rigorosa são um risco à integridade do produto.
5. A Elegância da Solução Dinâmica
A solução definitiva não custou "zero reais" apenas por ser uma refatoração simples, mas porque devolveu ao código a inteligência que ele nunca deveria ter perdido. Substituímos a string estática pela propriedade nativa do navegador window.location.origin.A lógica corrigida no método _copyInviteLink passou a ser: const inviteUrl = ${window.location.origin}/signup/$ {uuid};Com essa mudança, o aplicativo passa a "herdar" a identidade do ambiente onde está rodando. Se o código é executado em homologação, ele gera links de homologação; se está em produção, gera links de produção. Resolvemos o problema de paridade de ambientes e eliminamos a necessidade de intervenções manuais em cada deploy, garantindo escalabilidade técnica.
6. Conclusão: O Futuro da Programação Assistida
O caso do VoteNet é um alerta para todo Tech Lead. A IA é um acelerador poderoso, mas ela não possui a consciência do contexto de negócio ou da arquitetura de deploy. Ela é capaz de gerar código sintaticamente correto, mas logicamente alucinado.A supervisão humana e o rigor metodológico são as únicas barreiras entre uma entrega ágil e um desastre em produção. Devemos nos perguntar: "Até que ponto estamos delegando a lógica central de nossos produtos a ferramentas que não entendem o contexto do nosso negócio?" A eficiência nunca deve atropelar a precisão técnica.
Nenhum comentário:
Postar um comentário