[ Desenvolvimento ]

A equipe tem que ser boa

02 de abril de 2002, 00:00

Por Handerson Ferreira Gomes

O homem constrói casas há séculos. Com certeza você já deve ter visto em algum documentário da TV as pinturas feitas pelos homens das cavernas milhares de anos atrás.

Já a arte de desenvolver software infelizmente, ou felizmente, tem algumas dezenas de anos apenas. Ainda estamos aprendendo e reaprendendo a desenvolver software, a gerenciar os recursos, a reconhecer as variáveis envolvidas neste complexo ambiente e lidar com situações novas e muitas vezes adversas.

Todos aqueles que já tiveram a oportunidade de participar de projetos de software devem ter passado também por algum tipo de sofrimento. Noites mal dormidas por causa do prazo apertado, custos aumentando com programadores e licenças de software que não ajudaram muito, problemas de relacionamento entre os membros da equipe e assim vai. Quem nunca trabalhou num feriado prolongado para terminar um projeto que estava planejado para alguns meses antes? Melhor parar com a tortura, chega de lembranças ruins…

Edward Engler é desenvolvedor de software com mais de 15 anos de experiência em projetos que deram certo e também em projetos que não deram certo. Ao longo deste tempo ele pode perceber quais são os pontos mais importantes em um projeto de software. Em seu paper Get It Right the First Time, ele expõe as lições que aprendeu em mais de uma década trabalhando em projetos de desenvolvimento de software.

Neste artigo, e em próximos, vamos discutir estas lições e adicionar um pouco do tempero brasileiro às dicas de Engler, pois algumas coisas são diferentes no mercado brasileiro e no americano.

Os três primeiros tópicos abordam a equipe de desenvolvimento. Montar um equipe boa pode ser a diferença entre o sucesso e fracasso do projeto.

1. Encontre desenvolvedores 10x

Todo mundo que já trabalhou em desenvolvimento de software sabe que alguns desenvolvedores são mais produtivos que outros. Mas estudos têm mostrado que o tempo para desenvolver um mesmo código pode variar em até 10 vezes entre um desenvolvedor e outro. Nós costumamos chamar os desenvolvedores que possuem uma grande produtividade de programação de 10x developers.

Um desenvolvedor 10x não deve ser apenas um expert em alguma tecnologia de programação, ele deve também atuar como um membro eficaz da equipe, motivando e ajudando os outros membros. Deve ter a capacidade de escrever um código limpo e bem estruturado, evitando defeitos, e também escrever programas de fácil manutenção.

A experiência também é outro fator de suma importância em um desenvolvedor 10x. Saber quais arquiteturas são funcionais, saber quando abortar uma abordagem de desenvolvimento que parecia correta mas será inadequada daqui a algumas semanas, conhecer pacotes e soluções que podem economizar esforços reinventando a roda.

Além de ser mais produtivo, um desenvolvedor 10x é mais econômico. Vamos fazer algumas contas. O valor hora pago pelo mercado em São Paulo para um programador Java iniciante está em torno de R$ 15,00 a R$ 25,00 a hora. Dificilmente um desenvolvedor sênior em Java ganhará mais de R$ 200,00 por hora de trabalho. É claro que estes valores podem variar de acordo com o mercado, mas resumindo: um desenvolvedor com produtividade 10x não é 10x mais caro.

Se foi fácil fazer as contas, encontrar um desenvolvedor 10x não é tão simples assim. É necessário certificar que o candidato realmente atuará como um membro da equipe e trará vantagens mensuráveis. Nesta hora é importante investir tempo e dinheiro no processo de seleção, pesquisar sobre as experiências reais dos candidatos, principalmente através de entrevistas técnicas com outros membros da sua equipe.

Formar um desenvolvedor em casa pode ser uma solução viável, mas o garoto ou a garota deve levar jeito pra coisa. Eu tento jogar futebol desde os cinco anos de idade e até hoje não aprendi.

Contratar consultorias que tenham um staff sênior e comprovada experiência em desenvolvimento de software na tecnologia necessária também pode ser uma ótima opção, principalmente se o contratante não deseja manter um vínculo empregatício com o desenvolvedor. É o caso de projetos de curta duração ou quando não há tempo para ir ao mercado procurar por desenvolvedores com o perfil citado acima.

E finalmente, não meça um desenvolvedor 10x pelo número de linhas programadas, mas sim pelo número de resultados apresentados.

Mantenha os seus times pequenos

A produtividade de um time diminui à medida que o tamanho da equipe aumenta, isto é um fato.

Grandes equipes aumentam o tempo gasto com comunicação, delegação de tarefas e coordenação de atividades que diminuem a performance dos desenvolvedores.

Uma boa solução é quebrar grandes projetos em pequenos componentes, com pontos bem definidos de comunicação entre os componentes, e alocar pequenas equipes para estas atividades.

Se você tem uma equipe com bons programadores, então será fácil manter pequena a equipe do projeto. Você vai aproveitar os benefícios da produtividade de um time 10x e também o ganho de produtividade com um pequeno grupo de desenvolvedores.

Não só mantenha seus times pequenos como tente mantê–los com o nível técnico mais equilibrado possível. Numa corrida de aventura, um time é formado na maioria das vezes por quatro ou seis elementos. Durante toda a prova a equipe deve se manter unida; a vencedora será a equipe que chegar primeiro e ainda com todos os membros. Ou seja, a velocidade da equipe é nivelada pelo seu elemento mais fraco.

Com a equipe de desenvolvimento acontece algo semelhante. Um desenvolvedor 10x depende dos outros membros da equipe, ele pode manter o ritmo, ajudar em problemas que atrasariam todo o projeto, mas não pode levar todo os desenvolvedores consigo.

Cuidado com o desenvolvedor enrolado

Um bom desenvolvedor pode ser dez vezes mais produtivo do que os outros membros de uma equipe. Da mesma forma, um desenvolvedor problemático pode diminuir bastante a produtividade de todos.

As principais características de um desenvolvedor encrenca são:

• não seguir as regras de arquitetura e codificação definidas pela equipe;
• ser tímido ou inseguro para pedir ajuda e conselho aos outros membros do time ou
• pedir ajuda demais atrapalhando a produtividade da equipe.
• ser mal humorado demais, ou brincalhão demais;
• e principalmente: incompetente, irresponsável e desorganizado.

Além destes problemas, um programador pouco profissional pode desencorajar os outros membros da equipe a continuar o código dele, o que pode atrasar a detecção de defeitos no código. Uma das máximas da engenharia de software é: quanto mais tempo você demorar a achar um defeito num código, mais caro será corrigi–lo.

Desenvolvedores problema são pouco produtivos individualmente e baixam a moral da equipe. Freqüentemente tomam tempo precioso de outros desenvolvedores em tarefas de correção de código.

Lembra o exemplo da corrida de aventura? Um desenvolvedor problema será um peso para todos e o resultado quase sempre é uma equipe mais tensa e possivelmente com o prazo atrasado. Quando encontrar um assim, tente rapidamente retirar esta pessoa de sua equipe, se você quer ter uma equipe campeã. [Webinsider}