Muitos tem dúvidas em relação a velocidade de entrega e um de meus aprendizes me sugeriu escrever sobre esse tema. Acredito ser um tema muito útil e válido não só para os momentos de estudo, mas também para o dia a dia em empresas e, por isso, decidi compartilhar a minha experiência e visão sobre como lidar com prazos.

Entendemos que lógica é a base do desenvolvimento de software e aplicar o pensamento para resolver problemas pode ser considerada uma tarefa bastante criativa e que exige muita dedicação e concentração, seja com computação e linguagens de programação ou não. Existem diversas formas de resolver o mesmo problema, o que nos leva a considerar os pontos positivos e negativos em cada solução proposta e imaginada, favorecendo o que é mais importante naquele momento ou para o futuro, aqui temos o famoso conceito de trade-off.

“Trade-off é um termo em inglês muito utilizado na economia e que define as situações em que existem conflitos de escolha.”

Retirado deste artigo

Ou seja, as escolhas que você faz para definir soluções te levam por caminhos em que você pode resolver vários e também gerar outros problemas. Quando estamos falando de prazo, podemos levar em consideração os pilares da qualidade de software.

Para a área de desenvolvimento de software podemos citar três grandes questões quando falamos em qualidade e conseguir o melhor em ambos é considerado quase uma utopia, os elementos são: escopo, custos e tempo.

Escopo

Escopo tem relação com a definição dos limites de um projeto, considerando sempre que um projeto tem início, meio e fim. Quando você tem um projeto para desenvolver é importante entender bem qual é o objetivo e escopo do projeto, das tarefas e, se possível, o propósito e impacto delas em um futuro próximo.

Custos

Os custos tem relação com absolutamente tudo que custe dinheiro, direta ou indiretamente, para o cliente ou empresa antes, durante e depois do projeto acabar. Pensar apenas a curto prazo é um erro comum e que tende a gerar muito retrabalho, clientes insatisfeitos e, consequentemente, despesas futuras.

Tempo

Prazo tem relação com um dos três elementos, o tempo, e para aprender a negociar prazos você pode utilizar argumentos que demonstram como um prazo apertado pode impactar na qualidade e nos custos disso para uma empresa ou cliente. Geralmente, quando o prazo é muito apertado, o escopo é muito grande e/ou se pensa em redução de custos à curto prazo, pode ser para lançar um produto ou serviço novo antes da concorrência, resolver uma dor grande de um cliente e entre outras infinitas possibilidades dos negócios.

Em minha experiência, prazos quase sempre são negociáveis, desde que os argumentos sejam válidos e convincentes. No entanto, existem casos que não são negociáveis, como a entrada de uma lei em vigor a partir de determinada data ou a necessidade de cumprir a cláusula de um contrato que te dá prazo para resolução ou uma multa contratual caso não cumpra.

Vou tentar te ajudar a trabalhar com esses dois cenários, vamos lá?

Prazos negociáveis

Eu sempre vou partir do princípio que tudo é negociável até que alguém que tome a decisão ou algum documento diga o contrário. Então, em primeiro lugar, você pode se perguntar se você ou o seu time consegue atender as expectativas do seu cliente dado o prazo que você tem.

1. Se é possível atender e da melhor forma que você conhece, não tem muito o que negociar, né!? “Mão na massa!”
2. Se você consegue atender, mas não da melhor forma que você conhece e julga adequado para resolver o problema, então tente entender o contexto, questione e crie argumentos defendendo porque a sua forma de resolver vai ser melhor, estude, estime o tempo a mais que vai levar para a solução ser desenvolvida e apresente esses argumentos a quem pode tomar a decisão em relação aos prazos, depois reflita sobre o que aconteceu e aprenda com a experiência em respostas positivas e negativas.
3. Se você não consegue atender as expectativas do seu cliente no prazo, seja honesto, busque orientação e ajuda. Não adianta você assumir a bronca e trabalhar 24h por dia para resolver o problema, talvez não resolva mesmo assim e você ainda pode ter problemas físico e mental por conta disso, que além de tudo ainda pode se tornar um hábito nada saudável.

Prazos não negociáveis

Esses casos geralmente são a exceção, mas eles também costumam te dar um tempo hábil para se adequar. As leis que impactam os sistemas, por exemplo, costumam ter um período razoável para entrar em vigor e assim permitir a adequação das empresas, como mudanças fiscais e LGPD por exemplo.

Nestes casos, o que você consegue flexibilizar são os custos, pois prazo e escopo não costumam ser negociáveis, então a sugestão é que siga as orientações 1 e 3 acima para esses cenários. Caso a opção seja a segunda e você não consiga fazer da melhor forma que conhece, se planeje para uma revisão e possível refatoração depois da entrega. Considere como um MVP que você precisa entregar, mas depois pode melhorar e deixar mais robusto.

(Legal Gabriel… Você tem um exemplo mais prático?)

Vou usar o caso do meu aprendiz. Ele está estudando diversas disciplinas de desenvolvimento de software e tem desafios práticos para entregar e mostrar o que aprendeu. Eu comentei com ele sobre uma frase que me faz refletir sobre essas situações sempre:

“Se eu tivesse apenas uma hora para cortar uma árvore, eu usaria os primeiros quarenta e cinco minutos afiando meu machado.”

Abraham Lincoln

Neste caso, ele tem algumas semanas ou dias para estudar uma disciplina e depois tem uma semana para resolver um desafio prático que engloba os principais conceitos e aplicações do que ele estudou. Então, ele pode se questionar o motivo de ele não conseguir resolver os desafios dentro do tempo, pode tentar negociar o prazo do desafio argumentando os porquês usando as técnicas que descrevi (ou outras que ele julgar mais adequadas) ou considerar que o prazo não é negociável por conta própria, dar o seu melhor e entregar, depois voltar a estudar o assunto, revisar e aprender o conteúdo.

Eu diria que aprender o conteúdo é mais importante do que entregar, mas a verdade é que existe um conflito aqui. Geralmente, para as empresas o mais importante é que você entregue e elas não se importam se você aprendeu a fazer ou não, desde que entregue. Contudo, se você não aprender vai levar quase sempre o mesmo tempo para resolver problemas similares nas próximas vezes em que surgirem porque vai precisar pesquisar de novo e voltar a estaca zero todas as vezes em que aparecer um problema similar, mas diferente, até que, depois de apanhar várias vezes daquele assunto, a experiência tenha te moldado e você finalmente tenha aprendido, mas sem profundidade e talvez de um jeito que se aplica apenas a aquela determinada situação.

(Mas… O que eu faço então?)

Como chegar a um ponto de equilíbrio entre entrega e aprendizado?

Dado que cada entrega é única e é o que se espera de você como desenvolvedor, mas o aprendizado é contínuo e é isso que vai fazer você evoluir como pessoa e profissional, eu sugiro que você faça a entrega da melhor forma que conseguir, mesmo que precise pedir ajuda para isso e não consiga resolver sozinho (você pode aprender com outras pessoas também, sabia?), e durante ou depois disso estabeleça uma rotina de estudos para te ajudar a evoluir fora do horário de trabalho, seja em questões técnicas (hard skills) ou mais abstratas (soft skills).

“Hoje melhor do que ontem, amanhã melhor do que hoje”

Filosofia Kaizen

Ninguém é melhor do que você para saber aonde está doendo, mas pode ser bom ouvir conselhos de pessoas que querem o nosso bem e nos ajudam. Trabalhe nisso, evolua e seja uma pessoa e um profissional melhor a cada dia.

E ai, gostou? Foi útil? Concorda ou discorda de algum ponto? Comenta ai e vamos aprender mais juntos.

Espero ter te ajudado 😉