Autor: Natália Lie Suzuki

Para solucionar um problema é necessário identificar a sua causa raiz. Como na maioria das vezes ela é desconhecida, existem várias técnicas, metodologias ou ferramentas – dependendo do problema – que podem auxiliar nesta tarefa. Uma delas é o MASP, acrônimo para Método de Análise e Solução de Problemas. Como o nome sugere, trata-se de uma metodologia que auxilia na identificação e solução de problemas.  

Assim como o PDCA (falamos do tema neste artigo), o MASP também é uma ferramenta de melhoria contínua. O método consiste em oito etapas específicas, sendo elas: identificação do problema, observação, análise, plano de ação, ação, verificação, padronização e conclusão.

Para que o entendimento de cada etapa fique claro, a seguir apresentamos um problema baseado e adaptado de um evento real, e no qual foi possível aplicar a metodologia.

Problema modelo

A imagem acima demonstra o fluxograma de como um processo de compra de licença de um software funciona. O processo é iniciado pelo solicitante e em seguida o fornecedor libera uma taxa. A ativação da licença do software pode ocorrer em três cenários:

1. O solicitante é isento de taxa;
2. O pagamento da taxa é reconhecido pelo sistema na fase “Aguardando pagamento da taxa”;
3. O solicitante declara que o pagamento já foi efetuado e tem um comprovante na fase “Declarar pagamento da taxa” antes do sistema reconhecer o pagamento. Se porventura o solicitante comprovar o pagamento da taxa com um documento falso, o sistema suspende a solicitação da compra. Desse modo, a mesma só é liberada caso o solicitante realizar o pagamento pelo banco e o sistema reconhecer este pagamento.

Aplicando a metodologia MASP

A partir do problema acima, aplicaremos a metodologia MASP nos passos descritos na introdução:

Passo 1: Identificação do problema

Ocasionalmente, existiam solicitações em que a ativação do cadastro não era realizada mesmo após a taxa ter sido paga pelo solicitante. O problema foi classificado como crítico, visto que envolvia verba e impedia o solicitante de utilizar aquilo pelo qual pagou. 

O risco que o problema apresentava era de perder a reputação do produto e da empresa, e de ser indiciado a um caso judicial.

Passo 2: Observação do problema

Após observar o problema sob vários pontos de vista utilizando as perguntas abaixo, identificamos algo em comum entre as solicitações. Em todas elas o solicitante tinha realizado a tarefa “Declarar pagamento da taxa” com um documento falso.

Seguindo o fluxo do processo de compra de licença, o sistema suspendeu a solicitação. O solicitante, então, realizou o pagamento pelo banco, que foi reconhecido pelo sistema. No entanto, a licença não foi ativada.

Perguntas que devem ser feitas neste passo:

• Os resultados variam com qual frequência?
• Os resultados são diferentes em locais diferentes?
• Os resultados variam de acordo com um determinado usuário?
• Os resultados variam como?

Passo 3: Análise do problema

Com base na observação feita no passo anterior do MASP, escolhemos as causas mais prováveis para o nosso problema. Com isso, foram reunidos os profissionais que tiveram maior participação na criação do processo de ativação da licença para auxiliar nesta etapa.

As possíveis causas que foram levantadas:

1. Inconsistência no sistema de reconhecimento do pagamento da taxa;
2. Inconsistência na forma como o processo de compra de licença foi desenvolvido;
3. Intermitência momentânea do sistema inteiro.

Passo 4: Definição dos planos de ação

Foram elaborados planos para bloquear as causas levantadas no passo anterior, para que assim a causa raiz do problema inicial fosse identificada por meio de eliminação. É importante verificar as possíveis consequências dos planos de ação e qual a eficácia, caso contrário, gerará um novo problema e isso sim será uma tremenda dor de cabeça.

Planos de ação para as possíveis causas levantadas no passo 3:

1. Monitoramento do sistema que realiza o reconhecimento do pagamento da taxa por meio de logs – dados coletados do sistema para verificar se ele está se comportando como deveria;
2. Brainstorm com os profissionais que participaram da criação do processo de compra de licença;
3. Monitoramento do sistema inteiro – sistema que engloba os vários tipos de processos, desde a solicitação de compra de licença até o de solicitação de compra de CDs, por exemplo – por meio de ferramentas como o Java Mission Control, ferramenta que permite coletar e analisar dados de aplicações desenvolvidas em linguagem JAVA. 

Passo 5: Execução das ações

Para o quinto passo do MASP, escolha os profissionais mais adequados para executarem os planos de ação e coletarem os resultados. Os monitoramentos apontados no passo anterior foram realizados diariamente – uma vez ao dia – visto que a média de tempo entre o reconhecimento do pagamento da taxa e a ativação da licença era mais de um dia, e o brainstorm foi realizado em um único dia.

Passo 6: Verificação dos resultados

Com os resultados coletados no passo anterior, compare se o problema foi solucionado, liste se houve efeitos positivos ou negativos. Caso tenha ocorrido efeitos negativos, então é necessário retornar ao passo três, pois significa que a solução proposta tem possíveis falhas.

No problema modelo, após executar as ações foi identificado que o problema se encontrava na forma como o processo de compra de licença foi desenvolvido. Foi um cenário não previsto pelo sistema e com isso o processo de compra de licença foi alterado. 

Resumindo, adaptou-se o processo para atender os casos em que o sistema suspendeu a solicitação e depois reconheceu o pagamento da taxa. Veja a figura a seguir e compare-a com a figura mais acima.

Passo 7: Padronização do procedimento

Se o problema foi solucionado, padronize tudo o que foi levantado até este momento, pois isso irá prevenir o reaparecimento do problema.

Passo 8: Conclusão

Avalie todos os passos que foram realizados até aqui, pois podem existir padrões ou soluções que podem ser aplicados em eventos futuros.

Conclusão

Um problema é definido como um exercício que exige grande esforço e determinação para ser solucionado. Problemas existem em qualquer âmbito de nossa realidade, e na área profissional é crucial que eles sejam solucionados com exatidão e eficiência, pois mais indesejado do que lidar com um problema é lidar com o mesmo problema mais de uma vez.

Gostou do artigo? Compartilhe-o com seus colegas. Aproveite e visite também o blog da Neomind. Ainda não conhece o Fusion Platform? Teste gratuitamente durante 15 dias.

Você está habituado com uma versão de um software, mas precisa fazer uma atualização. Sabemos o quanto isso pode não ser fácil, afinal, muitas vezes é preciso passar por um processo de adaptação (e na rotina corrida não temos tempo para perder, não é mesmo?). Como entendemos que existe um certo receio quando falamos de atualização de software, neste artigo mostraremos a você que abrir mão da versão antiga vale – e muito – a pena (e você ou sua empresa só terão a ganhar).

O que é a versão do software?

Primeiramente, você precisa entender que a versão do software nada mais é do que um número ou um nome para identificar seu nível de desenvolvimento ou atualização. Por exemplo, quando falamos de carros 1.0, sabemos que eles são menos potentes que os 2.0. Ou ainda, quando falamos do celular Y9, sabemos que ele é melhor que o Y8 .Tudo isso são exemplos de versões e o entendimento é o mesmo quando se trata de software.

Por exemplo, o Fusion está na versão 3.6.3 atualmente. Ou seja, existem muitas funcionalidades novas que não existiam na 3.2.0, como é o caso do novo modelador de e-mail, que permite, dentre outras funções, montar o layout do seu e-mail pela própria ferramenta, sem precisar programar.

Entendi, mas eu não preciso do novo modelador de e-mail. Então por que atualizar?

Na nova versão do software, não são apenas novas funcionalidades que estão presentes. Também são realizados tratamentos para inconsistências, que nada mais são do que comportamentos não previstos pelo desenvolvedor.

Você pode se perguntar: “mas então não daria para fazer as melhorias na mesma versão?” A pergunta faz sentido, pois essa é uma maneira de não precisar atualizar o software. A resposta é simples: é possível, porém não é o recomendado. Ao fazermos isso obrigamos os usuários a se adaptarem com algo que não estão preparados. Justamente por respeitarem as escolhas de cada um é que desenvolvedores oferecem a opção de atualizar ou não quando desejar. Tudo depende do tempo que cada empresa precisa para se preparar.

E se ocorrer algum imprevisto e a ferramenta ficar indisponível por mais tempo do que o planejado?

Para que isso não aconteça, deve ser feito um processo de validação. A atualização da versão de seu ambiente pode ser aplicado em uma cópia para um ambiente de testes. Assim, os imprevistos poderão ser calculados e possíveis soluções podem ser estudadas antes da atualização do software ser aplicada no ambiente oficial.

Lembre-se que você deve pensar em longo prazo. Pode ser que seu processo para a atualização leve meses para seus usuários se ajustarem, porém valerá a pena o esforço que será investido neste processo. Quanto mais tempo você leva para atualizar a versão do software, mais tempo você deixará de usufruir dos novos benefícios.

Concluindo

Atualização de versão pode tomar boa parte do tempo de quem irá realizar esta tarefa, pois o software ficará inacessível neste período. Após a finalização, o processo de adaptação pode variar, sendo agradável ou não. Porém, se comparados os benefícios em longo prazo, você verá que valerá o esforço para desfrutar das funcionalidades da nova versão. Fique por dentro das atualizações do Fusion Platform em nossa Central de Ajuda.