Este artigo foi publicado em 21/01/2015. Por ter sido considerado um dos melhores artigos de 2015, foi republicado hoje.

Salve, pessoal.

Quero abrir esta coluna agradecendo aos meus grandes mestres André Tronchini, Michel Esber e Bruno Schrappe pela experiência e principalmente pela paciência que tiveram comigo. Muito obrigado. Por conta deles e de tudo o que aprendi com eles, eu pretendo aqui cutucar a ferida de alguns, o que eu vá falar não seja nenhuma novidade! Vamos falar sobre os principais motivos de falhas nos projetos de desenvolvimento – e como podemos nos precaver de algumas armadilhas que nós mesmos construímos, além de algumas dicas de como desenvolver melhor.

Por que projetos falham?

Existem duas falhas comuns a todos os times: qualidade e tempo. Tempo? Oras, todos os seus projetos foram entregues no prazo? E mesmo se você entregou os projetos no prazo, os bugs vieram aos montes, logo após a entrega, não é mesmo?

O tempo durante o desenvolvimento tem papel importante sob vários aspectos: desde o ponto (sim, esse malvado), estimativa, prazo, datas, enfim… o que não muda é que o dia tem 24 horas para todos no projeto, desde o cliente, passando pelo desenvolvedor, pelo gerente… o tempo é igual para todos. Já a qualidade, que abordei na coluna passada, pode ser resumida em como avaliamos e controlamos o estado de algo com relação ao que é esperado dele.

Testes

Testes automatizados são provavelmente a primeira medida que tomamos quando queremos melhorar a qualidade de nossos projetos. Sejam eles unitários, de integração ou comportamento, o ideal é que os realizemos de maneira sistêmica… mas por que é um problema? Não são os testes em si, mas a maneira como os usamos, principalmente quando ainda não temos experiência com isso – aí residem nossos males.

Algumas vezes usamos testes unitários, mas a qualidade do projeto não melhora – será que eles são relevantes para o projeto? A resposta é sim, mas você deve buscar um tipo de teste que realmente agregue valor à expectativa – um teste de comportamento poderia ser uma alternativa mais relevante para o projeto? Entenda: quanto mais seu projeto estiver coberto por testes de diferentes tipos, melhor; mas não adianta fazer testes por fazer, eles devem agregar valor, ter um propósito.

E o problema principal: confesse, você começou a aprender testes unitários no projeto em que estava trabalhando, não é? Ninguém discute a eficácia dos testes, desde que você já conheça o conceito e a ferramenta, sabendo aplicá-los no projeto. Se você tenta testar sem conhecer o projeto, você não faz nada bem: nem o teste, nem o projeto. O ideal é que você aprenda em separado a testar para aí aplicar em seu projeto; você pode usar um Pet Project* para tal.

Agilismo

Falamos também de Ágil no artigo passado, mas adotar uma metodologia pode levar ao fracasso de um projeto. Como? Se você não as utilizar corretamente. Há um manifesto explicando as motivações e os objetivos do Agilismo – dentre eles não há algo como “use porque é legal”. Muitas equipes dizem estar adotando Ágil quando não o fazem na verdade, aplicando os conceitos de responsabilidade mais operacionais enquanto os princípios que envolvem níveis táticos e estratégicos são ignorados. Ágil é sobre responder a mudanças, não rapidez.

Assim como no item anterior, você deve conhecer bem a metodologia antes de aplicá-la. Tem que ser estratégico para a empresa, vir “de cima para baixo” para que todas as áreas atingidas pela metodologia, e pelo desenvolvimento, estejam preparadas. Porque Ágil dói, deixa problemas muito claros e muitos gestores não gostam dessa parte.

O que fazer para não ter problemas?

A seguir vou passar minhas recomendações pessoais, baseadas na experiência como desenvolvedor, arquiteto e gestor. O que vou dizer aqui não tem nada de bala de prata e provavelmente não será novidade para ninguém, mas talvez eu apresente algumas verdades inconvenientes. Vamos aos tópicos:

– Novidades
Esteja sempre atualizado. Use um gerenciador de feeds, saiba como obter informações atualizadas sobre a tecnologia que utiliza, faça cursos, vá a eventos e meetups para aprimorar cada vez mais seu conhecimento. Mas nunca aplique o que acabou de “aprender” no projeto que está tocando, com prazo apertado e que não tem espaço para novidades. Isso serve para testes, integração contínua, metodologias ágeis, bancos de dados e/ou linguagens novos etc.

Preferencialmente, inicie projetos com essa premissa e, se houver a real necessidade de introduzir uma novidade, que ela esteja consolidada pelo time. Lembre-se: você pode usar um Pet Project ou um projeto paralelo para conseguir proeficiência em um novo aprendizado. Isso impactará diretamente nas medidas de tempo (entrega, velocidade) do projeto, assim como potencialmente pode melhorar a qualidade.

– Planejando
Há algumas coisas que precisam ser ditas sobre este tópico. E doem, a começar pela mais dolorosa: desenvolvedores, principalmente os experientes (ou os que se consideram assim), tendem a cair na armadilha do over engineering – quando planejamos muito além do necessário, geralmente no início do projeto. Mas isso é muito difícil de mensurar. “Como sei quando passei do ponto?”. Não há resposta para isso, mas podemos fazer um exercício para tentar não sermos pegos por essa armadilha.

Tente obter a visão do projeto – o que o requisitante quer atingir com ele. Tendo como base essa visão, e desprendendo-se do ego (inimigo nº 1 do desenvolvedor a caminho de ser um especialista), divida o projeto nas menores peças que conseguir e, então, engenhe a maneira mais simples de conseguir cada uma delas. Isso vai agregar valor mais rápido, pois exigirá menos esforço para ser produzido – em frente à grande solução que você planejaria em outra circunstância. Não tente prever o futuro. Baseie o seu planejamento com o que tem, com fatos. Com isso, você não se sobrecarregará e não afetará sua performance.

Outro problema que afeta as entregas é justamente o prazo – não o prazo em si, mas como lidamos com ele. Quem nunca, em um projeto, ficou mais sossegado no começo e virou noites quando o prazo estava estourando? E não adiantou, não é mesmo? Seja por não ter terminado no prazo ou pela qualidade ter ficado junto com a borda da pizza da última noite, você falhou. O que fazer? Se comprometer conscientemente. Se você tem 15 dias para desenvolver, comprometa-se com o que conseguir, preferencialmente com menos, e trabalhe para que esse pequeno comprometimento esteja pronto o quanto antes. Acredite, é muito melhor se comprometer com pouco e cumprir do que se comprometer com muito e falhar. Seja sincero consigo mesmo.

– Desenvolvendo

Aqui seguem algumas dicas de performance, principalmente como desenvolver melhor e mais rápido.

Use um framework: um que já esteja consolidado no time – ele vai te manter focado no código que atende ao problema, e você conta com uma comunidade muito maior que seu time para manter os pilares como persistência de dados, autenticação, roteamento etc.

Use um IDE: um ambiente de desenvolvimento no qual você tenha tudo o que precisa para desenvolver à mão.

Entenda o problema antes de desenvolver e resolva-o da maneira mais simples (e nunca simplória); aqui vale uma observação: se o problema, requisição ou tarefa chega para você de forma nebulosa, tente torná-lo melhor com a fonte, explanando como gostaria de recebê-lo.

Outro ponto: organize-se em uma rotina de trabalho. Faça sua rotina, use uma técnica de gestão do tempo (Pomodoro, por exemplo), mas estabeleça para si mesmo como vai tocar seu dia de trabalho e faça isso acontecer.

Quando virar rotina de fato, compartilhe com seu time – a ideia é que todos saibam quando contar um com o outro. Essa rotina vai melhorar muito seu foco e consequentemente sua produtividade. Você também pode tentar motivadores de produção em “jogos” como o Codeivate.

Falando em rotina, para onde você vai quando precisa fazer algo importante? Para a biblioteca, para o café, para casa? Dificilmente encontro alguém que diz “para o escritório”. Por quê? Você é constante e arbitrariamente interrompido o dia inteiro no escritório. “Mas em casa você vai se distrair com a TV” diz o gerente. Sim, se você quiser. A interrupção é uma escolha fora do escritório. Na empresa, você ainda tem que participar de reuniões agendadas do nada. O que fazer? Procurar opções de notificação em troca das interrupções. Usar um instant messenger, e-mail etc. para te notificar que alguém quer interrompê-lo – para que você não perca o foco e atenda a uma requisição quando for mais conveniente – como é muito bem explicado pelo Jason Fried, em seu TEDTalk.

Meu projeto ainda pode falhar?

Claro! Projetos são suscetíveis a falhas, assim como os humanos que os planejam e executam. Mas, se pudermos diminuir problemas comuns com atitudes simples, como as citadas, podemos melhorar nosso índice de sucesso. Em suma: ser sincero consigo mesmo, dividir os grandes marcos em tarefas menores, criar uma rotina, introduzir novidades após maturá-las e buscar a simplicidade nas soluções vão com certeza fazer a diferença. Agora expanda esse escopo para o time, o projeto, a empresa…

Um bom e saudável trabalho em equipe também sempre é bem-vindo, assim como trabalho com motivação, gestão de tempo, projetos e desenvolvimento, além de trabalhar melhor a qualidade e a criatividade durante o desenvolvimento. Mas esses são assuntos que ainda estão por vir.

Até a próxima!

*Pet Project é definido comumente como um projeto pessoal, para aprendizado, de uma linguagem ou ferramenta. A referência a “Pet” é sobre a maneira de lidar com ele – deve ser algo que nos motive a cuidar constantemente.

***

Artigo publicado na Revista iMasters. Você pode assinar a Revista e receber as edições impressas em casa, saiba mais.