Você está começando o primeiro sistema da sua empresa ou está trabalhando pra uma startup (empresa nova) que está produzindo o seu primeiro sistema. Ele tem que sair pra ontem, você tinha pouca experiência e também tinha pouco tempo pra se preocupar em gerenciar ou controlar a maneira que as coisas estavam acontecendo. Vocês fizeram poucos testes, a documentação é praticamente inexistente e a coisa mais próxima de um histórico do projeto é o “revision” do seu controle de versão (é bom que seja Subversion…).

Cenário apocalíptico? Nem tanto.

Essa é a realidade da maior parte das startups aqui no Brasil e talvez até mesmo no mundo. A empresa é iniciada por amigos, que muitas vezes acabaram de sair da faculdade e tem uma boa idéia e bons contatos pra vender essa boa idéia, as vezes nem tudo isso, mas eles querem ir pra rua. Como acabaram de sair e não tiveram nenhuma formação especial nem experiência real em gerência de projetos (além dos livros intragáveis e da mais pura decoreba), ninguém entende muito bem de nada e, principalmente, estão sentindo a adrenalina do primeiro projeto que precisa ser entregue, a chance de satisfazer o primeiro cliente.

A equipe é genial, cada um faz o seu trabalho com afinco, se apegam ao código e começam a entender do negócio para o qual eles estão desenvolvendo a solução, afinal todos estão incrivelmente empolgados com a solução que está nascendo. Em momento nenhum eles pensam no futuro daquilo que está sendo produzido.

A primeira versão

Gerar a primeira versão é praticamente um dos atos mais importantes da vida de todos eles, é um primeiro filho que vem ao mundo depois de dias e noites de trabalho ininterrupto. Todos se regojizam com o trabalho bem feito e entregue. Mas o festejo não vai muito longe, pois rapidamente o telefone toca e ao atender, surpresa! É o cliente reclamando de um problema que ele encontrou utilizando a aplicação.

“Não se desespere”, é o que cada um pensa, bugs são normais, ninguém escreve aplicações perfeitas e o usuário provavelmente já está acostumado a esse tipo de coisas, afinal, ele já tem um computador por lá, sabe que essas coisas dão problema mesmo (olha a desculpa…). Depois desse bug, vários outros aparecem e além deles surgem os pedidos pra novas funcionalidades (que vão terminar em novos bugs).

E mesmo com os bugs, o pessoal parte em busca do mercado procurando por mais clientes, pois agora que eles tem a solução pronta podem vende-la também a outras pessoas. Eles partem então para a luta comercial e vencem algumas das batalhas, conquistando novos clientes. Rapidamente, os clientes aumentam e a quantidade de bugs e novas funcionalidades que precisam ser adicionadas também aumenta. E a coisa não pára por aí, de repente, vem aquele cliente antigo pra você e diz, “preciso de um novo sistema para resolver um novo problema”.

É nessa hora que a coisa vai começar a entortar pro seu lado.

Crescendo, crescendo, crescendo…

Aquela equipe de amigos que saíram juntos da universidade já não tem mais condições de levar tudo sozinha e eles hoje tem condições de contratar novos funcionários para ajudar a suplementar a equipe de desenvolvimento.

Lá vão eles pro mercado atrás de gente especializada pra contratar. Incrivelmente, encontrar gente capacitada torna-se cada vez mais difícil e encontrar gente capacitada que tenha conhecimento em uma área específica (como sistemas financeiros) é praticamente impossível dependendo de onde os nossos amigos estiverem, pois a maioria das empresas esquecem das universidades e na formação de trainees. Então, sem muita escolha, eles pelo menos escolhem um cara bem capacitado no serviço de desenvolvimento, mas que não entende nada do domínio das aplicações que eles desenvolvem.

Ao chegar na empresa, os veteranos estão atolados de serviços graças a manutenção e implementações de novas funcionalidades naquele primeiro sistema, sem previsão de quando eles vão poder se afastar um pouco disso e partir para as novidades. Fica para o novato, com experiência quase zero no negócio atender a nova demanda de sistemas. Ele as vezes passa por um “pequeno” treinamento sobre o que vai fazer, mas dificilmente vai poder contar com a experiência do pessoal mais antigo para resolver os seus problemas.

Ele, que não tem experiência no domínio, provavelmente vai apanhar tanto quanto os veteranos apanharam e também deve cometer vários dos mesmos erros, mas quem pode culpá-lo? Se todo o processo continua desorganizado, a tendência é que todo o ciclo se repita mais uma vez e agora nós vamos ter dois grupos de desenvolvedores que vão estar presos para sempre na manutenção das aplicações que eles desenvolveram, barrando o seu crescimento e até mesmo a construção de disseminação dos novos e velhos conhecimentos que todos adquiriram no tempo que passaram desenvolvendo as suas soluções.

Teste cedo, teste muito

Esses problemas não são comuns apenas nas startups da nossa história, eles acontecem diariamente em grandes empresas que tem anos de mercado mas que não valorizam os poderes que os testes tem sobe as soluções que eles estão escrevendo. Se aquele primeiro sistema que foi entregue tivesse sido testando junto com o seu desenvolvimento e não apenas testado quando enviado ao cliente a quantidade de defeitos seria muito menor.

O custo real de um defeito é uma multiplicação entre o tempo que ele demorou para ser descoberto e resolvido e a perda que ele causou para o cliente. O tempo que você perdeu resolvendo esse bug poderia ter sido muito mais bem gasto no desenvolvimento de uma nova funcionalidade que agregasse valor ao negócio do seu cliente. Fora isso, se você simplesmente resolveu o bug e não adicionou testes que evitem uma “regressão” (o retorno do bug por causa de uma alteração subseqüente), está dando mais um tiro no escuro e pedindo pra gastar ainda mais no futuro.

O pior de tudo, no nosso caso, é que nós temos as melhores mentes e as pessoas que mais conhecem no negócio fazendo remendos em uma cocha de retalhos com agulhas cirúrgicas, pois eles sabem que ao menor erro podem colocar todo o sistema a perder. Em vez destas mentes estarem trabalhando e desenvolvendo novas oportunidades para resolver os problemas do cliente e lhe oferecer mais valor (que é o que ele procura quando deseja automatizar o seu processo), estão perdendo tempo resolvendo defeitos que poderiam ter sido pegos por uma metodologia mais rígida de testes.

Pior, o sua equipe de desenvolvimento nunca vai ser escalável, pois sempre que surgir a necessidade de se desenvolver alguma coisa nova, você vai precisar contratar novos funcionários e começar tudo do zero outra vez, pois o pessoal antigo vai estar ocupado demais dando manutenção e fazendo correções no “legado”. Eles só vão se liberar quando você jogar o legado fora ou conseguir “migrar” pra uma plataforma “nova”.

Se você está começando, prestes a iniciar ou já caminhando em um projeto que não tem testes, prepare-se para enfrentar esse problema e muitos outros, ou então dê um passo a frente e defina uma política para os testes e durma em paz no seu travesseiro, sem ficar se preocupando com cada vez que o telefone tocar.