Seja você desenvolvedor, seja você um líder, em algum momento precisará entregar o prazo de algum projeto. Dar bons prazos é sempre um grande desafio. No texto de hoje, vou compartilhar um pouco da minha experiência e discutir como trabalho com prazos.

É impossível prever o futuro

Este é o ponto mais importante: você não sabe o que vai acontecer amanhã. Passar um prazo tentando imaginar o futuro é apenas “chutar” uma data, e isso é a pior coisa que você pode fazer enquanto está dando um prazo.

O seu “Waze” ou “Google Maps”, por exemplo, só sabem que você leva 15 minutos do ponto X ao ponto Y porque você irá passar por um caminho bastante específico. Em um projeto é a mesma coisa, você precisa construir uma rota.

Planejamento

O que é preciso ser feito no projeto? Tenho conhecimento suficiente para isso? Precisarei de alguma ajuda ou suporte? Há algum ponto de atenção durante o projeto?

São perguntas que sempre devem ser feitas antes de dar um prazo. E o planejamento começa a partir do momento que você responde essas perguntas.

Entenda o que precisa ser feito e mapeie as demandas; estude tudo que for necessário para que você desenvolva o projeto; vá atrás de alguém que te dará o suporte e já resolva todas as pendências, ou ao menos já deixe marcado; dê atenção as maiores dificuldades do projeto, e se possível até as faça primeiro.

Dê pequenos passos

Se você tem um projeto fullstack para desenvolver, você não pode pensar “10 dias para o backend, 10 dias para o frontend”. O que vai ser feito no backend? O que precisa ser desenvolvido no frontend? É mesmo tão simples a ponto de ser definido de forma tão macro?

A dica é trabalhar com pequenas tarefas: no backend, preciso construir a rota X e isso levará 2 dias, no frontend preciso construir o componente Y e isso levará 1 dia. Isso te dá uma perspectiva mais realista sobre o projeto e permite que você seja mais preciso com os prazos.

A questão por aqui é que é mais difícil dar um bom prazo para um projeto grande, do que para uma tarefa pequena.

A Lei de Murphy

Se algo tem chance de dar errado, vai dar errado. E vai mesmo. Esteja sempre preparado para algum possível problema: atraso em alguma tarefa, desenvolvimento não previsto, uma dificuldade maior do que você espera.

Por isso, volto em alguns pontos: planejamento e tarefas pequenas: com um bom planejamento você evita e se prepara para maior parte dos problemas; com pequenas tarefas você vê o erro acontecendo mais cedo e tem mais tempo hábil para solucionar.

Se um erro irá acontecer, você precisa estar preparado e ser ágil para resolver.

Experiência

O seu primeiro prazo vai ser horrível, o segundo só vai ser ruim, o terceiro foi quase lá e no quarto você finalmente acertou.

A experiência vai te permitir planejar melhor, se preparar para os problemas melhor e até descobrir novos caminhos. É o que você mais precisa para dar um bom prazo.

Ao final de um projeto, sempre tente entender onde você errou, o que poderia ter feito melhor e como fazer melhor. Desta forma, a experiência vai surgindo gradualmente.

Ainda assim você vai errar

Não importa o nível de planejamento, se demandas foram bem colocadas, se você viu um erro acontecendo e até conseguiu resolver, no fim, o seu prazo pode ir completamente errado, independente até da experiência que você tenha.

Por isso, gosto sempre de usar uma “margem de erro”. É bem simples até: Se é 10 dias, digo 15. Se é 20 dias, digo 30. Essa pequena diferença me dá mais espaço para resolver qualquer eventual problema sem quebrar a expectativa do cliente. E se tudo ocorrer bem, acabo entregando até mesmo antes da data que eu disse.

Prazos são uma negociação

Se mesmo com todas as dicas as coisas podem dar errado, o que fazer então? Bom, veja que estamos tentando trabalhar de forma exata, com algo que não é exato, e é por isso que erramos tanto.

Um bom prazo não é acertar em quantos dias você consegue entregar algo, até porque prazos não são sobre datas, são sobre expectativas, e expectativas estão bem longe do campo de exatas. Um bom prazo depende da forma em que isso é apresentado, em como é trabalhado durante toda a etapa de desenvolvimento, e principalmente em como é entregue ao final.

Tenha isso em mente, independente dos problemas, trabalhe com a expectativa do cliente.

Termino dizendo que prazo realmente não é nada tão exato quanto nós pensamos, e por isso, é um ótimo assunto a ainda ser discutido várias e várias vezes. Você já conhece o nosso canal do Discord? Estaremos por lá debatendo ainda debatendo este assunto. Participe conosco, e compartilhe como você trabalha com prazos também