É isso mesmo, eu não gosto de problemas, assim como eu não gosto de debugar aplicação, assim como eu nao gosto de ser acordado de madrugada porque o sistema parou de rodar o faturamento da empresa, assim como eu não gosto de ficar finais de semana corrigindo problema no sistema porque na segunda feira o pessoal da contabilidade tem que rodar o faturamento!

Não sou daqueles que acorda pela manhã e pensa:

Uau! qual será o problema do dia? Problemas de rede? Problemas com banco de dados? Problemas com a JVM?, hum……. bom mesmo se ocorresse todos eles de uma só vez!

Me lembro de algumas entrevistas, em que meus entrevistadores diziam:

Temos um ambiente desafiador, excelente para pessoas pró-ativas, determinadas a resolver os problemas, auto-motivadas…..

Bom, com o passar do tempo agente vai aprendendo ficando mais maduro quanto as promessas e passamos a interpretar algumas frases como a dita anteriormente como algo do tipo:

Temos vários sistemas cujo o pessoal que desenvolveu não está mais na empresa, os sistemas foram pouco testados por motivo de prazo e temos o caos na terra, precisamos de gente que tenha motivação suficiente para continuar levando o sistema até o fatídico dia em que já tenha ocorrido a depreciação por completo do sistema, e quem sabe se você ainda estiver na empresa quando isso acontecer, quem sabe, você possa utilizar tudo que aprendeu na manutenção deste sistema em um novo projeto.

Não sei para a maioria, mas pelo menos para mim, esta segunda frase soa menos amigável, mas muito mais sincera que a primeira.

Outra forma de “motivar” as pessoas nestas empresas são:

Fique tranquilo, com a quantidade de problemas que temos no sistema, temos emprego garantido para pelo menos 3 anos!

Acredito eu que algumas pessoas lendo este post já possa ter passado por uma situação dessas.

A triste notícia para os que não sao OP (orientados a problemas) é que pessoas que lideram os times OP tendem a investir tempo de menos em testes unitários, funcionais ou integrados e tempo demais em resolução de problemas quando o aplicativo já estiver em produção.

Dificilmente será possível se antecipar a problemas de produção, mas algumas dezenas deles já pode ser antevisto e em tempo de desenvolvimento da aplicação e mais, além de antevisto, podemos testar o comportamento da aplicação quando ( e se ) este problema ocorrer.

O recado aqui é simples:

Teste, Teste, Teste, Teste, Teste, Teste

Não se canse de testar, não se canse de criar cenários de teste para os de integração e aceitação, faça dos testes parte do desenvolvimento, algum tempo será consumido no desenvolvimento de teste, sim isto é verdade no entanto algo que é facilmente mensurável, é quanto de tempo será economizado em debugs, quanto será economizado na redução dos problemas em produção que podem acarretar em um prejuízo financeiro para empresa se isto ocorrer?

Motivação (Mais) para Testes

Faça dos testes unitários um exercício para o desenvolvimento, em um próximo post eu vou detalhar melhor os testes unitários, mas por hora, algo muito válido para ter uma boa motivação a respeito de testes unitários é que UT (unit tests) é tão interessante para o sistema quanto para você mesmo (desenvolvedor), com eles é possível modelar a estratégia de desenvolvimento da classe, serve como um exercício de barreiras para saber exatamente o escopo de onde a funcionalidade chega e onde é sua fronteira, mantendo o desenvolvimento KISS.

Faça com que a criação de testes faça parte do desenvolvimento, me lembro da frase do treinamento que tive de Scrum:

Done means…..

complete a frase com algo do tipo:

• …. não ser incomodado nos finais de semana
• …. não ter que acordar (ou não durmir) nas madrugadas para resolver problemas de sistemas

E a maneira mais simples de completar a frase é:

Teste! Teste! Teste! Teste! Teste! Teste!

English Version:

I don’t like problems! (EN)

It’s truth, I don’t like problems, I don’t like to debug application, I don’t like to wake up early (2AM or 3AM) because the billing application stops to process records. Like I don’t like to stay during all weekend solving problem becaus next mondey guys from billing will send invoice.

I’m not like that people who wake up morning and think:

Wow, what will be big problem today? Infrastructure? Database? Memory and JVM?….. that’s will be great if all those things happen together!

I remember som interviews, when the interviewers said:

We have a very motivated environment, excellent for who likes to solve problems and self-motivated….

Well, passing time we learn about this kind of “promisse”, it it automatic transformed to something like:

We have a system that the guy who created it are no longer on the company, the application was not well tested because we had a small time to develop and now we have a chaos on the earth. We need people who are self-motivated to continu to solve the problems on the application until the day that the company will says: The application is self-payed, we will invest on a new one. And maybe on this day, will could, use all your knowledge earned from mistakes on the application to develop the new one.

It is more sincere than the first phrase don’t you think?

Another way to “motivate”people is:

Stay calm, with all these bugs in the application, we have job for at least 3 years more!

The bad news for who are not PO (problem oriented) is that people who leader teams PO have tendency to inves less time on unit tests, functional tests and integrated tests and too much time in silving the problems (not the cause) when the application already be on production environment.

It’s not simple to foresee problems on production environment but, dozens of them we can foresee during development and more than that, we can test the behavior of the application if it happens in production env!

The message is simple:

Test, Test, Test, Test, Test, Test.

Don’t be tired to test, don’t be tired to create scenarios test for integration and acceptance. Some time will be consumed during development, yes this is truth but this is easy to calculate the cost, just to don’t let the application die during day, when it couldn’t stop.

Motivation (More) for Tests.

Make the creation of the unit test and exercise for development, use it for determinate the scope of the class, the development scope fof that functionality. Use it to discover if the functionality will not broken if you are the one who are changing some lines of code, and even if the functionality is following the KISS method.

I remember a training that I had with Boris Gloger about Scrum, and he said:

Done means….

complete the phrase with some like:

• …. don’t be bothered on the weekends
• …. don’t wake up dawn (or even don’t sleep) to solve problems on the application

And the best way to get it is:

Test! Test! Test! Test! Test! Test!