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"

Postar um comentário