menu

Planejar pra quê???

Por

Living with paradox means planning, but not becoming wedded to that plan. It means sensing when actual events override the plan and responding with the appropriate “resolution”.
Jim Highsmith

Imagine que você tem o papel de decidir se um projeto será feito ou não. Então, chega alguém e fala para você: “olha, tenho esse projeto, é muito legal e vai fazer muito bem para a empresa.” E aí, o que você faz? Vale a pena fazer o projeto?

Você então pergunta: “Qual retorno esperado do projeto?”

A resposta é uma projeção de que o projeto, caso as premissas se confirmem, tenha um retorno de R$ 2 milhões. E agora, qual sua decisão? Fazer ou não fazer?

Hum, não é suficiente… você ainda quer saber mais e pergunta “Vocês fizeram alguma projeção dos custos do projeto?”

— Ah claro, o projeto deve custar R$ 1 milhão para ser desenvolvido. Agora você já pode decidir, certo? Afinal, já sabe que custa (R$1Mi) e quanto retorna (R$2Mi). E aí???

Mas quanto tempo demorará para ser implementado o projeto? Em quanto tempo o retorno virá, e se for daqui a 10 anos? Será que é melhor comprar algo pronto ou desenvolver? É melhor usar uma equipe interna ou contratar uma empresa terceira? Será que tem outro projeto mais promissor que esse? E como o projeto será mantido, uma vez que tenha sido concluído?

Bom, está claro que muitas perguntas precisam ser minimamente respondidas antes que uma decisão seja tomada sobre prosseguir ou não com um projeto. E mesmo depois de decidir dar andamento ao projeto, ainda precisamos planejar “Como” para que tenhamos a melhor composição entre data de entrega, funcionalidades, custo, etc.

Por que planejamos, afinal?

Entre outras coisa, planejamos para:

Auxiliar na tomada de decisões: Afinal, vale a pena iniciar o projeto? Esse projeto é o mais alinhado com a estratégia da organização? Qual a melhor alocação de funcionalidades nesse projeto? Qual a melhor forma de executá-lo? Também durante a execução do projeto, vale a pena iniciar o desenvolvimento de uma determinada funcionalidade? Ela é a mais alinhada com a visão do projeto?

Reduzir incertezas: Uma das principais incertezas que existe em um projeto é a de saber se as funcionalidades que estão sendo ou serão desenvolvidas são as que o cliente e nossos usuários realmente precisam. Nem sempre o que o cliente pede é realmente o que precisa, o que quero dizer é que muitas vezes nós, como clientes, fazemos como se fôssemos ao médico e pedíssemos um antibiótico sem que o médico, ou você mesmo, tenham diagnosticado o que realmente está errado. Tudo isso vale para antes e durante o projeto.

Reduzir riscos: O planejamento, independentemente do seu nível, traz à tona riscos que muitas vezes podem inviabilizar o início do projeto, assim como sua execução. Mesmo não sendo o caso, planejar ajudará a lidar melhor com os riscos identificados. Podemos planejar a ordem e validar hipóteses e assim reduzir riscos o quanto antes.

Alinhar expectativas: Por mais que um plano ou um processo de estimar não garanta um exato conjunto de funcionalidades em uma data e custo exatos, ajudam a alinhar as expectativas, comunicando e estabelecendo uma linha base.

Previsibilidade: A área demandante frequentemente precisa de estimativas para tomar decisões quanto a priorização e entregas. A previsibilidade também ajuda a saber quando algum recurso será necessário. Muita gente diz “vai estar pronto quando estiver pronto”, acho uma resposta injusta e com uma boa falta de empatia com quem vai pagar a conta 😉

Bom, planejamos para poder tomar decisões melhores, que claro, podem ser alteradas conforme o fluxo de novas informações for chegando no decorrer de um projeto.

“Responder a mudanças mais que seguir um plano.”
Um dos valores do Manifesto Ágil

Quando temos um projeto pela frente, com início, meio e fim, é bom ter uma ideia de quanto tempo levará, quantas pessoas serão necessárias e qual o melhor custo-benefício disso tudo, levando-se também em conta o custo de atraso e o custo de oportunidade.


Custo de atraso (Cost of Delay — COD)
O Custo de Atraso representa a receita ou a economia perdidas com a escolha de não se trabalhar em um determinado item (uma história de usuário, por exemplo). A mais alta prioridade deve ser o item com o maior custo de atraso. O custo de atraso geralmente associado ao Custo de Implementação (COI), a prazos e a outros fatores.

Custo de oportunidade
… conceito de custo de oportunidade é saber que toda vez que se escolhe trabalhar em algum item, escolhe-se também bloquear algum outro. Calcular exatamente o COD é quase sempre impossível no desenvolvimento de produtos; então geralmente será necessário seguir bons palpites. Aprender a associar um valor econômico ao trabalho desempenhado é um exercício de amadurecimento para projetos e organizações.

Jesper Boeg em Kanban em 10 passos, pág. 29


Só para fechar, existe alguma confusão em relação ao Agile, algo no sentido de que no Agile não planejamos. Não poderia ter nada mais despropositado. A maior diferença do planejamento ágil em relação ao tradicional é que damos mais ênfase ao planejamento que ao plano em si, replanejamos o tempo todo, pois o projeto é um fluxo contínuo de novas informações e nos adaptamos o tempo todo à realidade, mantendo sempre a comunicação ativa e bidirecional entre as partes interessadas.
Falaremos muito do tema Planejamento e Estimativa Ágeis em nossos próximos posts, então não fique chateado se porventura você ainda não souber como planejar de forma ágil.

Deixe nos comentários suas dificuldades com o assunto que podemos abordar em breve 😉

About the author: Leonardo Campos

Leonardo Campos trabalha na área de TI desde 2000, atuou boa parte deste tempo como desenvolvedor Java, mas também desenvolveu profissionalmente com Ruby, .NET, VB, PHP e ASP. Desde do começo de 2009 vem atuando com Agile e hoje trabalha na ThoughtWorks Brasil. É estudioso de processos e entusiasta de Lean e Agile, sendo um dos organizadores do Lean Coffee São Paulo e editor da InfoQ. Leonardo é advogado por formação (Universidade Presbiteriana Mackenzie).
LinkedIn
@leonardocampos

1 comment

  1. Pingback: Trabalhando com poucos dados | Kudoos

Leave your reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Go to top