Durante 18 anos gerenciando projetos em TI, em 2004, fiz um curso de três meses sobre o PMBOK (parte do MBA em Engenharia de Software) e posso dizer que me ajudou bastante a entender as boas práticas sobre gerenciamento de custos, tempo, etc. Porém, nos últimos quatro anos estudando a filosofia lean por meio de livros, treinamentos e acompanhamentos em projetos do Lean Institute Brasil tenho uma visão muito mais realista e prática sobre o que envolve um efetivo gerenciamento de projetos.
Isso não é uma crítica sobre as boas práticas do PMBOK, mas uma maneira de dizer que gerenciar projetos não é algo tão trivial como descrito naquele livro. Quando iniciei meus estudos sobre a filosofia lean, logo passei a ver citações sobre a Toyota e como essa empresa conseguiu chegar ao patamar financeiro em que está hoje - conseguindo comprar cerca de 80% de todas as montadoras de veículos do mundo.
Após aprofundar meus estudos sobre o Sistema Toyota de Produção (STP) passei a entender que o Sistema Toyota de Desenvolvimento de Produto (STDP) era um modelo tão refinado e poderoso quanto. À medida que o STP era formado no período pós-guerra, essas práticas eram aprendidas e documentadas pelos japoneses que também as usavam para desenvolver os produtos.
Normalmente as montadoras levam de 24 a 30 meses para lançar um novo veículo no mercado. Com as práticas adotadas no STDP a Toyota chegou a lançar um automóvel em extraordinariamente 10 meses. Mas você pode estar pensando: Gerenciar o projeto de um carro é bem diferente de um software. Realmente existem muitas diferenças, mas há de concordarmos que para formar um veículo são necessárias em torno de 9000 peças montadas em fluxo contínuo por toda uma linha de produção em pouco mais de duas horas.
Desenvolver um software é algo diferente, pois as pessoas não conseguem ver exatamente o que está sendo feito e talvez isso seja o grande problema entre quem está solicitando e quem está desenvolvendo. Porém, isso não impede que possamos utilizar algumas técnicas desenvolvidas e refinadas pelos japoneses durante mais de 60 anos para gerenciar projetos de TI como de quaisquer outros tipos.
Algumas técnicas que citarei foram extraídas enquanto outras foram adaptadas do livro: Sistema Toyota de Desenvolvimento de Produtos – Integrando pessoas, processo e tecnologia escrito por James Morgan e Jeffrey Liker (2008).
- Certifique-se de que tenha entendido claramente o que o cliente deseja. Durante o processo de especificação (que deve ocorrer ao longo do desenvolvimento do projeto) utilize o método para fazer as perguntas certas e nunca tire conclusões precipitadas. Valide o que entendeu constantemente e lembre-se: qualquer erro na especificação se transformará em um enorme retrabalho posteriormente. Mas como extrair 100% das especificações corretamente? Não há uma fórmula mágica para isso, mas com o Kentou conseguiremos reduzir e muito a incidência desses erros.
- O Kentou, nesse contexto, marca o início do desenvolvimento de um software no qual a regra deve ser: Planejar com cuidado e executar com precisão. Algumas características desse conceito adaptadas a TI seriam:
- Identificar todas as áreas da empresa em que o produto passará e exigir a participação em reuniões dos sêniores responsáveis de cada área a fim de não encontrar becos sem saída no desenvolvimento de software (por exemplo: componentes que não funcionam bem na linguagem de programação escolhida anteriormente, etc), além de ajustes drásticos que impactarão no custo e no prazo.
- Exija a participação das pessoas chave no cliente. Algumas vezes quem está solicitando o software não é quem mais entende do assunto ou a pessoa diretamente responsável. Lembre-se: todas as informações que você receber de alguém para desenvolver algo, é a visão dessa pessoa, qualquer erro de conceito se transformará em retrabalhos no desenvolvimento. Isso se relaciona com o conceito de Gemba e você poderá ler mais sobre isso mais tarde clicando aqui. Em outras palavras, certifique-se de que esteja recebendo as informações certas das pessoas certas para determinado tipo de projeto.
- A fase do Kentou marca as reuniões que te darão a visão do projeto como um todo e isso permitirá que você saiba em qual ponto do desenvolvimento poderá ter problemas. Por exemplo: se for desenvolver um software que exija componentes embarcados entenda como funcionarão as conexões no software, quais seriam as empresas contratadas, os custos, quanto tempo elas estão no mercado e se necessário, estabeleça planos de contingência caso a empresa escolhida não esteja disponível quando precisar.
- Outra característica do Kentou é a Engenharia Simultânea Baseada em Alternativas – ela é formada pelo estudo detalhado de possíveis soluções (kentouzus) e podem ou não serem expressas por meio de um protótipo. Diferente do modelo iterativo pontual utilizado intuitivamente pela maioria dos gerentes de projeto, no qual se define um único caminho e vão se “ajustando” as arestas ao longo do desenvolvimento originando um produto sub-ótimo, com a Engenharia Simultânea pretende-se estudar com maior profundidade cada uma das possíveis soluções, em outras palavras, se preocupando mais com o planejamento inicial do que com a execução.