15 de maio de 2010

O que fazer quando o prazo é curto e a pressão é grande?

Em mais de uma década de experiência profissional, foram raras as ocasiões em que não estive envolvido num projeto com prazo curto e grande pressão. Isso pode ser familiar para você, que também desenvolve software. Muitas vezes, você talvez se sinta como eu: dividido entre manter a qualidade do seu código e atender ao prazo.

Como cumprir prazos sem abrir mão da qualidade? O que fazer quando não for possível cumprir o prazo? São pontos que pretendo abordar neste artigo.

Nota: Partirei da premissa de que a pressão é para concluir um projeto ou lançar um release. Em outro artigo abordarei a pressão para a correção de falhas críticas de software em produção.

1 - Reduza o escopo

Quando é evidente que o prazo é curto demais para determinado projeto, minha primeira proposta é a redução de escopo. Particularmente, acho maravilhoso deixar de fora funcionalidades não essenciais. Além de favorecer o cumprimento de prazos, isso geralmente torna o software mais simples de usar, evoluir e manter.

"...os melhores programadores não são os que possuem as melhores habilidades... e sim aqueles que podem determinar o que não importa." (37signals) [1]
"Inovação... é dizer NÃO para tudo exceto as funcionalidades mais cruciais." (Steve Jobs) [2]

Algumas funcionalidade que sugeri não implementar em projetos onde estive envolvido, nunca foram implementadas, mesmo depois de anos. Não por esquecimento, e sim porque se mostraram irrelevantes ou porque novas necessidades mais importantes foram identificadas.

2 - Comece pelo que é mais importante (para o cliente)

Mesmo com o escopo reduzido, ainda é necessário avaliar o que merece ser implementado primeiro. Se, ao terminar o prazo, o projeto não estiver concluído, você não desejará ter em mãos um software inutilizável porque deixou pra fazer por último as funcionalidades mais complicadas (que por acaso eram as mais importantes). Implemente primeiro as funcionalidades vitais, sem as quais seu software não faz sentido. Se algo não ficar pronto a tempo, que seja o menos importante.

3 - Faça o que tem que ser feito

"Sempre implemente as coisas quando você realmente precisar delas, nunca quando você prevê que precisará delas" (Ron Jeffries, um dos criadores do XP) [3]

Muitas vezes, o próprio programador encurta o seu prazo por querer "ir além", fazer aquilo que ele tem certeza que será necessário implementar no futuro, mas ainda não foi solicitado. Essa atitude traz consigo três implicações:

  • Exige um tempo maior para implementação, testes e ajustes;
  • Torna o software maior e mais difícil de manter;
  • O que se pensa ser necessário no presente, talvez nunca se torne necessário; ou se torne necessário, mas não como foi imaginado.

Não é por acaso que a expressão "You ain't gonna need it" (Você não vai precisar disso) ou sua abreviação YAGNY são tão populares entre os adeptos do Extreme Programming.

4 - Tenha moderação ao se preocupar com a performance

"Devemos esquecer as pequenas eficiências, digamos 97% do tempo, otimização prematura é a raiz de todos os males." (Donald Knuth) [4]

Segundo Knuth, na maioria dos casos, você não deve se preocupar com a performance do código que escreve. Isso pode soar estranho e talvez gere polêmica em torno do assunto, mas faz sentido - mesmo que você não tenha um prazo curto.

Um código otimizado para ter melhor performance, geralmente se torna menos legível e mais difícil de manter. Que percentual do código que você escreve merece se tornar menos legível em benefício da performance?

Outro ponto a considerar é quando os usuários tolerarão aguardar um pouco por uma resposta do software. Uma geração de relatório que acontece uma vez por mês tende a ter uma tolerância alta, enquanto uma pesquisa realizada dezenas ou centenas de vezes por dia tende a ter uma tolerância baixa.

Tornar um algoritmo 10 vezes mais veloz pode ser excitante para você, mas não para seus usuários se isso significar reduzir o tempo de resposta de 100 milissegundos para 10 milissegundos. Por outro lado, se você tornar um algoritmo "apenas" 2 vezes mais veloz, seus usuários ficarão felizes se isso significar uma redução de 60 segundos para 30 segundos no tempo de resposta.

Por último, mas não menos importante, quanto tempo você demorará para implementar um mecanismos que faça algo X vezes mais rápido? Seu prazo comporta esse tempo?

5 - Compartilhe decisões que diminuirão a qualidade do software

Há, infelizmente, casos em que a solução capaz de ser implementada dentro do prazo diminua a qualidade do software.

Por exemplo, você começa a codificar uma nova funcionalidade que será adicionada a um software em produção. Depois de alguns minutos, percebe que já escreveu algo parecido em outra parte do programa no passado. Como um bom programador, você logo pensa em tornar genérica a parte comum entre as duas funcionalidades e isolar os códigos específicos. Só que você talvez precise de alguns dias para concluir essa generalização, criar e testar a nova funcionalidade (além de retestar a funcionalidade antiga), enquanto precisará de apenas algumas horas se fizer o famoso "copy & paste", além de algumas alterações no código copiado. Seu gerente (que não te consultou antes de passar o prazo para o cliente) te deu apenas 1 dia para terminar esse trabalho.

Você sabe que duplicar código é algo horrível! É uma daquelas práticas que acabam com a manutenibilidade do software. Se for descoberto um bug no código original, será necessário alterar todas as cópias desse código (se você lembrar delas). Mas você está sob pressão. E então, o que você faria?

Em situações como essa, é preciso ser muito franco. Explique claramente ao seu gerente (que talvez nunca tenha sido um programador) os prós e contras de cada alternativa e deixe-o tomar a decisão junto com você (ou por você, se ele preferir). Se, compreendendo as implicações negativas, seu gerente disser quer a solução mais rápida, coloque seu chapéu de cowboy [5] [6] e atenda a vontade dele. Apenas lembre de adicionar comentários significativos no código que facilitem a manutenção no futuro.

Se você for pressionado a agir como um "Programador Cowboy" por muito tempo, talvez seja bom considerar uma mudança de emprego.

6 - Se perceber que vai atrasar, avise antes que aconteça

Não tente adiar o sofrimento. Se o prazo está terminando e você percebe que não conseguirá concluir o projeto, avise com antecedência. Essa ocasião pode ser um bom momento para sugerir uma reavaliação do escopo (ou uma alteração do prazo).

Lembre-se:
"É melhor fazer meio-produto do que um produto meia-boca" (Getting Real) [1]

Foto: Escravos numa galé romana - Filme Ben-Hur, 1959

[1] ^ 37signals. "Caindo na Real"

[2] ^ Derek Sivers. "Say NO by default"

[3] ^ Ron Jeffries. "You're NOT gonna need it!"

[4] ^ Donald Knuth. "Structured Programming with go to Statements"

[5] ^ Online Etymology Dictionary. "Cowboy"

[6] ^ Tim Bowen. "Word of the week: Cowboy"

13 comentários:

Anônimo disse...

Olá, você já estudou desenvolvimento ágil e/ou coisos como scrum ou XP? Isso que vc escreveu aqui se enquadra bem na filosofia de desenvolvimento ágil e já tem muitas empresas olhando para esses carinhas.

Dirlei Dionísio disse...

Sim amigo, e minhas opiniões são fortemente influenciadas pelo que aprendi com essas metodologias. Você deve ter notado isso especialmente no item 3, que se baseia na "simplicidade", um dos quatro valores do XP. Obrigado pelo seu comentário!

Valmir disse...

Muito bom! Mas, o que fazer quanto o papel que lhe cabe é só levar a culpa? rsrs
Brincadeiras a parte, um problema sério é quando seu superior não acredita no que você diz. Ele(a) acha (e 'achismo' é uma das piores doenças) que não é nada disso e pronto.
Todo(a) gerente deveria ser *no mínimo mais* do que seus gerenciados. Ou pelo menos ter confiança neles.

Vou anotar estas sugestões.
Parabéns!

Dirlei Dionísio disse...

Concordo plenamente com você, Valmir. Obrigado pelo seu comentário!

Magno Machado Paulo disse...

Muito bom o artigo, e concordo com tudo.

Mas devemos também prestar atenção nos prazos que assumimos. É melhor dar um prazo de 20 dias e entregar o produto em 15, do que dar um prazo de 10 dias e entregar o produto em 15. Claro que imprevistos acontecem, mas devemos embutir um "tempo para imprevistos" nos nossos prazos, e o mais importante: Não ceder a pressões dos clientes

Regina Silva disse...

Oi Dirlei! Gostei muito do seu blog. Muito inteligente, como lhe é peculiar. Parabéns!
De programação 'tô por fora', mas vou te contar que umas citações e, na sua maioria, os itens, serviram até pra mim (trabalho). Como vc sabe, entendo de artesanato, e, mudando o "software" por "peça" - que é o termo que uso muito - funciona do mesmo jeito. No meu caso, meu cliente é o patrão do momento. Ao mesmo tempo, sou minha própria patroa! rsrs. É claro que a decisão na execução é minha, mas a escolha da peça é da cliente e, muitas vezes, preciso ajudá-la a ver quando lhe é adequado ou não. Viu? Algumas coisas em comum - só se vê nas entrelinhas!
Mais uma vez, parabéns!

Dirlei Dionísio disse...

Você tem razão, @Magno. É melhor dar um prazo um pouco maior e cumpri-lo do que dar um prazo curto e atrasar a entrega.

@Regina, fiquei surpreso e feliz por ter, sem querer, escrito um artigo útil também para quem não é o meu público-alvo (desenvolvedores de software). Muito obrigado pela visita e pelo comentário! : )

Unknown disse...

Nada melhor que um código "flexivel", onde por mais escabrosas que forem as alterações e implementações futuras, você consiga manter o sistema sem grandes dores de cabeça.
Gostei muito do artigo. Acho muito boa a aplicação da redução de escopo, pois quase que automaticamente ao tentarmos reduzir o escopo, conseguimos remover alguns recursos que o cliente não precisa e só pediu pela emoção da conversa no recolhimento dos requisitos e também conseguimos estabelecer a prioridade dos módulos a serem criados.
Muito bom artigo!
Grande abraço Dirlei.

Dirlei Dionísio disse...

Obrigado Alexandre! Um grande abraço pra você também.

Pierre Abreu disse...

Um problema que acontece comigo é como desenvolver bem quando não foi você que deu o prazo? A empresa cria todo aquilo discurso que "Era isso ou perderíamos o cliente" e com isso joga a responsabilidade sobre o programador. Com isso é muito trabalhoso conseguir uma diminuição de escopo ou não cometer redundancias no código. Mas enfim, acho que todo mundo passa por isso e o que temos que ter em mente, que independente da situação que estivermos, temos que ser sempre Verdadeiros (nunca mentir/ocultar) e fazermos o nosso melhor.

Dirlei Dionísio disse...

'Ser sempre verdadeiros e fazermos o nosso melhor'. Sábias palavras, xsinistro!

Dessa forma deixaremos claro que, por mais que um prazo irrealista seja cumprido, isso teve impacto na qualidade do produto final, além de ser insustentável fazer software indefinidamente com prazos assim.

Maurilio Henrique disse...

Mais uma vez, excelente. Parabéns.

Dirlei Dionísio disse...

Thanx, Maurilio!