Senta que lá vem história…
O diretor da empresa precisa desenvolver o novo projeto. Ele chama o gerente de projetos, passa o escopo e o objetivo. O gerente de projetos chama a equipe e começa a planejar.
O segundo passo são as entrevistas com os usuários. Durante esse processo vão surgindo várias outras idéias. Com todas as ideias em mãos e documentadas em vários gráficos, fluxos e diagramas, a equipe começa a planejar a execução. Banco de dados, servidores, telas, funcionalidades, módulos, cadastros, automações. Tudo isso é definido e planejado o queremos surpresas.
Vamos para a execução?
Programador inocente: Nossa, vai dar trabalho pra fazer isso.
Gerente inocente: Em quanto tempo a gente entrega?
Programador inocente: Puts, não sei. Uns 6 meses?
Gerente inocente: Muita coisa, o diretor disse que precisa disso no ar em 3 meses.
Programador inocente: Nossa, é muito pouco tempo. Vamos precisar aumentar a equipe.
Gerente inocente: Tudo bem, vamos falar pro RH abrir a vaga. Enquanto isso, a gente toca o projeto com o pessoal aqui de dentro.
Sem o projeto começar eu já consigo prever alguns resultados:
A equipe vai virar a noite para entregar o (grande) escopo que foi definido. O RH não vai contratar esse novo programador. Como o tempo é curto e a equipe é pequena, a qualidade do código vai ser uma merda. Testes? O que é isso?
O mais temido acontece: o projeto atrasou. Os 3 meses viraram 6 meses.
Sem contar que o software vai atender apenas parcialmente as necessidades do cliente. O motivo? Vários: Alguns processos mudaram desde que o escopo foi definido; O que foi mapeado não reflete exatamente o que o cliente precisa; O cliente não soube explicar direito o que queria.
Temos aqui um exemplo clássico de como NÃO planejar e executar o desenvolvimento de um software.
Mas, se você trabalha com desenvolvimento de software, sabe que é assim que quase todos os projetos são feitos. Mas, por quê?
Por que planejamos?
No contexto de uma empresa, o planejamento é importante. É preciso ter um rumo para onde seguir, é preciso ter um norte. O planejamento é o responsável por isso. Além disso, ele emula o caminho que vamos percorrer com o objetivo de já identificar possíveis imprevistos e obstáculos que aparecerão no caminho.
Ok, isso é válido.
Mas é importante entender o que é mais importante. É o planejamento ou a execução? A resposta é óbvia: a execução. Não é o planejamento que trás resultados. Não é o planejamento que coloca dinheiro no bolso. Não é o planejamento que gera valor. É a execução. Ou melhor, é o resultado dessa execução.
Por que definir todos os módulos do sistema? Por que modelar todo o banco de dados? Por que desenhar todas as telas? Existe uma explicação psicológica para isso.
Basicamente, quando estamos apenas no campo das ideias nós não cometemos erros. O papel aceita tudo. No planejamento, o nosso software é perfeito. Com isso, nós acabamos nos embriagando em nosso ego e nos apaixonando por nossa solução.
A jornada é mais importante que o objetivo
No exemplo lá de cima, fica claro que TUDO foi feito de forma errada. A premissa do desenvolvimento do projeto estava errada. Todos assumiram que o projeto inteiro precisava ser entregue em 3 meses, quando, na verdade, era preciso gerar valor em três meses.
O prazo serve justamente pra nos tirar do conto de fadas e nos lembrar da realidade. Se não tiver prazo, o projeto não sai nunca. O projeto só sai quando você coloca a mão na massa, quando você gera valor mais rápido.
Um dos quatro passos para melhores códigos é planejar apenas o próximo passo. Para conseguirmos cumprir nossos prazos nós devemos planejar menos e executar mais.
Quando você executa mais, você entrega mais rápido. Ao entregar mais rápido, você tem o feedback mais rápido do seu cliente. Ao ter o feedback mais rápido, você consegue com clareza se está no caminho certo para continuar executando.
Repetindo esse ciclo várias vezes, ao final dos 3 meses você com certeza vai ter resolvido boa parte dos problemas do seu cliente. Sabe o que isso significa? Projeto entregue no
