Métodos Ágeis Para Solução de Problemas II

Continuando a série de posts sobre os métodos mais fáceis e eficientes para se chegar a causa raiz de um problema, hoje irei tratar de Mind Map.

Para quem nunca ouviu falar, Mind Map (e suas variações) é uma técnica milenar utilizada na educação, brainstorm, visual thinking, solução de problemas entre outros. A técnica foi refinada por Allan M. Collins e M. Ross Quillian em 1960 com a publicação da tese sobre redes semânticas - uma teoria que explica o processo humano de aprendizagem por meio de mind maps.

Um mind map é criado à partir de uma palavra colocada no centro, aonde idéias associadas, palavras e conceitos são agregados. Segue abaixo um guideline sobre mind map criado em forma de mind map:O uso de mind maps na resolução de problemas pode ser feito à partir de um brainstorm, reunindo as pessoas responsáveis pela resolução e guiando o brainstorm por meio do mind map. Eu costumo usar mind maps até mesmo para planejamento pessoal (viajem, trabalho, etc), neste caso eu faço um brainstorm comigo mesmo (!) e gero um mind map que será a minha guia na execução.

Existe um excelente projeto open source chamado FreeMind , que consiste em uma interface para criação de mind maps. Rápido, simples e extremamente funcional. Quem se interessar pode fazer download em:

http://freemind.sourceforge.net/wiki/index.php/Main_Page

Métodos Ágeis Para Solução de Problemas I

Já que estamos na onda das metodologias ágeis, resolvi escrever sobre os métodos mais fáceis e eficientes para se chegar a causa raiz de um problema.

O primeiro método se chama "Os 5 Porquês". Este é fácil. Para qualquer problema colocado na mesa faça cinco vezes a pergunta "Porquê".

Exemplo da aplicação da técnica em uma conversa entre desenvolvedor e gerente de desenvolvimento:

Desenvolvedor) Será impossível cumprir o cronograma de desenvolvimento.

Gerente de Desenvolvimento) Porquê?

Desenvolvedor) Porque encontramos um bug no sistema.

Gerente de Desenvolvimento) Porquê?

Desenvolvedor) Porque existe uma incompatibilidade entre a arquitetura proposta e as funções da API utilizada.

Gerente de Desenvolvimento) Porquê?

Desenvolvedor) Porque provavelmente a API não foi analisada com critério na hora de modelar a arquitetura.

Gerente de Desenvolvimento) Porquê?

Desenvolvedor) Porque o arquiteto de sistemas não dedicou tempo suficiente para modelar a arquitetura.

Gerente de Desenvolvimento) Porquê?

Desenvolvedor) Porque ele está alocado em outros projetos.

Pronto! Chegamos a raiz do problema: Conflito na alocação de recursos.

Meu antigo chefe aplicava com freqüência esta técnica, é impressionante como ela traz resultados rápidos. Geralmente a causa raiz aparecia no terceiro "Porquê".

Quem quiser maiores detalhes:

http://www.mindtools.com/pages/article/newTMC_5W.htm