Ja que estamos na onda das metodologias ageis, resolvi escrever sobre os metodos mais faceis e eficientes para se chegar a causa raiz de um problema.O primeiro metodo se chama "Os 5 Porques". Este e facil. Para qualquer problema colocado na mesa faca cinco vezes a pergunta "Porque".Exemplo da aplicacao da tecnica em uma conversa entre desenvolvedor e gerente de desenvolvimento:Desenvolvedor) Sera impossivel cumprir o cronograma de desenvolvimento.Gerente de Desenvolvimento) Porque?Desenvolvedor) Porque encontramos um bug no sistema.Gerente de Desenvolvimento) Porque?Desenvolvedor) Porque existe uma incompatibilidade entre a arquitetura proposta e as funcoes da API utilizada.Gerente de Desenvolvimento) Porque?Desenvolvedor) Porque provavelmente a API nao foi analisada com criterio na hora de modelar a arquitetura.Gerente de Desenvolvimento) Porque?Desenvolvedor) Porque o arquiteto de sistemas nao dedicou tempo suficiente para modelar a arquitetura.Gerente de Desenvolvimento) Porque?Desenvolvedor) Porque ele esta alocado em outros projetos.Pronto! Chegamos a raiz do problema: Conflito na alocacao de recursos.Meu antigo chefe aplicava com frequencia esta tecnica, e impressionante como ela traz resultados rapidos. Geralmente a causa raiz aparecia no terceiro "Porque".Quem quiser maiores detalhes:http://www.mindtools.com/pages/article/newTMC_5W.htm Recentemente visitei a Ci&T em Campinas e, durante a apresentacao da metodologia de desenvolvimento baseada em SCRUM, me deparei com um abordagem voltada para analise de valor que permeava todos os processos e apoiava o entendimento e priorizacao dos requisitos funcionais junto ao cliente. Fiquei bastante entusiasmado com a abordagem, pois enderecava de forma estruturada e coerente um problema classico de priorizacao de requisitos sob a otica de quanto vale cada funcionalidade para o projeto.O discurso da Ci&T e de "entregar o maior valor possivel dentro do orcamento do projeto." Ou seja, abracar todas as mudancas (premissa de qualquer metodologia agil) e entregar de acordo com o orcamento do projeto um conjunto de funcionalidades que atendesse a expectativa do cliente em relacao ao valor de negocio gerado pelo projeto. A todo momento, a cada novo requisito, seria feita uma analise para repriorizar o backlog... fazendo com que os requisitos de baixo valor para o negocio fossem implementados posteriormente e que os requisitos realmente importantes fossem devidamente implementados dentro do orcamento negociado.Tirando qualquer cenario onirico, todos sabem que grandes projetos de software possuem complexidades e riscos ocultos. Sao projetos aonde a estimativa de esforco tende a variar, uma vez que nem todos os requisitos sao conhecidos e que haverao diversas solicitacoes de mudanca no decorrer do projeto. Sendo assim, essa metodologia cai como uma luva para justicar o uso de SCRUM junto a uma empresa tradicional (geralmente acostumada com projetos "fechados") e garantir a valorizacao do investimento.SAVE International, organizacao internacional voltada para o avanco e promocao da Metodologia de Valor (tambem conhecida por Engenharia de Valor / Analise de Valor / Gerenciamento de Valor), publica o padrao aberto chamado "Value Standard & Body of Knowledge". Esse corpo de conhecimento tem como objetivo apoiar gerentes de projeto, gerentes de programa, analistas de valor e outros profissionais na aplicacao dos conceitos e processos da Metodologia de Valor em projetos, servicos, planos de negocios, etc.A aplicacao da metodologia se da por meio de um plano de implementacao, chamado de "Job Plan" (Plano de