Fazer software é uma arte, mas ao contrário da pintura e da escultura é um tipo de arte que se faz em equipa. Algo mais como um concerto e menos como um solo. Fazer software sozinho é possivel, mas lento e chato.
No mundo profissional software é feito em equipa. A equipe de desenvolvimento não são apenas os programadores. São todos aqueles que participam de alguma forma no desenvolvimento. Desde do arquiteto até o testador, passando pelo programador, pelo gerente e até pelo representante do cliente.
O problema é que nem sempre a equipe é tratada com respeito. A principal razão para isso é que a equipa não exige respeito. Às vezes por falta de conhecimento do seu valor ou do seu papel no grande esquema das coisas, às vezes por modéstia e às vezes por que não estão nem ai. O problema maior acontece quando ela não exige respeito porque sua qualidade é pobre.
A qualidade da equipe de desenvolvimento é um fator a ser considerado independentemente da plataforma de desenvolvimento escolhida. Uma equipe bem treinada, afiada, com acesso a uma base de código útil que ela entenda e domine, pode ser a diferença entre o sucesso e o fracasso dos projetos. Sim, projetos , plural.
A equipe de desenvolvimento não pode ter muitos membros, pois é sabido que apenas aumentando o número de elementos em uma equipe os problemas de comunicação crescem em relação ao quadrado do numero de pessoas na equipa. Isso leva à confusão e à necessidade de longas reuniões constantes para que todos estejam no mesmo nível. O tamanho da equipe é, portanto, fundamental.
Outro fator é a rotatividade. Se os membros da equipe constantemente são substituidos a qualidade sofre porque mais tempo tem que ser passado ensinando os novos membros como as coisas funcionam. Quanto menos padronização mais dificil é essa tarefa. Um outro fator que advém de uma elevada rotatividade é a dispersão de conhecimento. Digamos que temos 4 membros na equipe que conhecem o negocio e a base de código, se sair um por mês em 4 meses todo o conhecimento que eles tinham acumulado se perdeu. Os novos integrantes da equipa não terão o mesmo insight sobre o negócio e terão que ser retreinados. Além disso não saberão quais decisões tecnicas foram tomadas e porquê foram tomadas levando à reescrita de novo codigo ou ao abandono do que já existe e à criação de um novo software.
Outro ponto fulcral é a capacitação dessa equipe. A experiência é importante, o conhecimento das tecnologias envolvidas é importante. É possivel criar um software com uma pessoa, e é possivel criá-lo com 8 juniors trabalhando 50 horas por semana, mas não é possivel fazer isso com a mesma qualidade e rapidez que com 4 sêniors trabalhando 7 horas por dia. Existe um fator de eficiencia inerente à capacitação tecnica e à própria experiencia. O sénior não vai passar 90% do seu tempo testando ideias , algoritmo ou tecnologias. Ele já fez isso antes. Ele irá passar 90% do tempo implementando features reais. Uma equipa eficiente tende a ser pequena e a ter uma razão senior/junir elevada. Claro que, como não poderia deixar de ser, isso está longe da realidade. Só é preciso ter cuidado quando você contrata a produção de um software que ela não esteja inteiramente na mão de juniors que por definição são menos preparados tecnicamente e com menos vivência no ramo. Contudo, o treinamento de pessoas é importante e a equipa também não deve apenas ser formada de sêniors. E lembre-se sempre que lá porque uma pessoa faz programas à 20 anos não significa que saiba criar aplicações hoje e muito menos que saiba gerenciar a produção delas.
Além de tudo isto, o mais importante é que todos aceitem bons valores e rejeitem maus valores e que haja concenso sobre quais valores adotar. A Extreme Programing assenta básicamente sobre valores de onde são estrapoladas práticas e é um bom exemplo de porquê valores são mais importantes que experiência. Experiencia adquire-se. Se aprende e se ensina. Valores, ou se têm, ou não se têm. É demorado e custoso incutir valores em alguém. Isso fica além do aprendizado simples e requer uma educação completa, e portanto, cara. Contratar pessoas com os valores certos, é mais importante para o custo e sucesso do que contratar pessoas com experiência. A experiencia deles pode simplesmente enganar você.
Muito já foi falado sobre os bons valores que devem ser abraçados pela equipe, mas conhecer as tentações dos maus valores e como as evitar pode ser ainda mais útil. Em outras palavras, mesmo que a equipe não faça bem, desde que não faça mal, já é um passo em frente.
Podemos enumerar sete falhas, sete anti-valores, os sete “pecados” mais comuns dos membros da equipe de desenvolvimento:
Decisões apressadas levam à degradação da qualidade do software. Isto é normalmente originado por um subjugação ao prazo irrealista do projeto que causa um stress e uma pressão sobre a equipe para entregar o software – de qualquer jeito- até ao prazo. O risco disto é imenso, pois qualquer pequeno erro feito agora causará prejuízos imensos depois. Claro, que, os causará ao cliente e não a software house, ou pior, a software house cobrará para resolver esses problemas. Assim, é lógico que, do ponto de vista do fluxo de caixa, seja preferível entregar cedo e com muitos defeitos ao invés de tarde e sem defeitos. Os clientes são os que sofrem, mas devido à lábia de alguns vendedores, os clientes nem se dão conta que estão sendo enganados. O charlatanismo ainda é um problema no mundo da produção de software, como o foi de medicina ha não muito tempo atrás.
A pressa viola o comprometimento com um prazo.O prazo tem que ser realista. Isto significa que tem que ser alcançavel mesmo quando existem imprevistos e sem periodo extra de trabalho. A pressa acontece normalmente porque alguem mentiu em informações que formaram o prazo ou o prazo foi ajustado artificialmente por alguem sem comprometimento de toda a equipa. O prazo não é uma promessa, é um tempo máximo. O software será entregue até dia X. Isto significa que pode ser entregue antes. E é isso que deve acontecer. É por isso que o prazo não deve definir o custo.
A ausência de preocupação em buscar soluções para problemas que aparecem durante o desenvolvimento, parecendo existir uma espécie de má vontade natural em solucionar os problemas, não procurando soluções que outros já utilizam ou mesmo soluções novas. Neste caso, a tendência natural é eliminar o problema fazendo algum tipo de malabarismo – mais conhecido como gambiarra – que permite que o problema simplesmente “desapareça”. Claro que como nada é mágico, essa “solução” acaba trazendo mais problemas no futuro. Devido à apatia constante, a equipe não vê relação entres esses problemas e as gambiarras que fizeram antes, criando mais gambiarras para resolver os problemas que encontraram. Isto gera um novelo de ajustes mal pensados que não resolvem problemas, ao contrário, criam outros problemas, levando a um novelo ainda maior num ciclo viciado pela não-preocupação da equipe.
A recusa em utilizar soluções já encontradas por outros e largamente utilizadas com sucesso. Estas soluções podem ser desde boas práticas de programação até a utilização de técnicas de gerenciamento, como Scrum ou algo simples, como ter muitas equipes pequenas ao invés de ter uma equipe grande. A velha “não vamos fazer isso agora porque não precisamos” é o ex libris da visão-curta.
Escolher a “solução mais fácil” repetidamente e sem analisar as consequências da decisão. Normalmente o “mais fácil” significa “o mais rápido” ao invés de “o que tem melhor razão custo-benefício”. Avaliar as soluções pelo tempo que demoram a ser implementadas é a prova de que a pessoa é preguiçosa, ela está tentando avaliar quanto tempo livre terá para ficar fazendo nada, ou invés de estar preocupada com a qualidade do software. A rapidez da implementação depende de muitos fatores e nomeadamente da experiência de quem vai implementar (um sênior provavelmente implementa em muito menos tempo que um júnior) e das ferramentas, bibliotecas e frameworks envolvidos. Se é algo que já está quase pronto da plataforma de aplicação é rápido, se é preciso criar, é lento. Um outro exemplo comum é escolher implementar uma funcionalidade no software ao invés de na plataforma de aplicação, sob a razão de que no software será mais rápido. Sempre que a palavra “rápido” é usada está em causa a preguiça de alguém. A análise e decisão entre funcionalidades não se dá pelo tempo de implementação de cada uma e sim pelo tempo de implementação de todas as funcionalidades do software. Se a funcionalidade X implementada da maneira “A” demora vinte vezes mais que a “B”, mas diminui o tempo de Y e Z por oito vezes, provavelmente será a escolhida.
Esta tem várias formas. Resistir ao compatilhamento do código com a equipe ou até achar que o código é seu e não da empresa onde trabalha é um sinal claro. Mais sútil é achar que sabe como o software tem que ser feito à margem da documentação, do cliente, e pior, dos outros membros da equipe. Porém, mais sútil ainda é escrever e organizar o código da forma que acha certa sem pensar no que são as melhores práticas, ou a prática comum do resto da equipe. Pouca abstração é um sinal disto porque a pessoa só abstrai o que é necessário para ela e não pensa que uma abstração maior poderia ser útil para outras áreas do software. Falta de comunicação e decisões baseadas em crenças pessoais são um outro sinal da avareza.
É a falha em procurar entendimento. Mantém-se as pessoas estúpidas, comentendo erros a longo prazo que voltarão potencializados para atacar e pôr em risco o software. A ignorância também se apresenta no nível gerencial e até vindo do cliente. Ao falharem em entender alguma coisa, o gerente ou o cliente não pedem explicações, mas decidem fazer as coisas de outra forma, levando a retrabalho e a um sobresforço da equipe. Isto é comum quando não se entende porque o programador passou dois dias implementando algo que não consta dos requisitos. Em vez de perguntar e tentar entender a razão técnica, o gerente automaticamente decide que a pessoa está enrolando. A Ignorância apresenta-se também pela falta de treinamento da equipe em tecnologias novas e até pela falta de abertura de que a equipe procure esse conhecimento. “Faltar um dia para assistir uma conferência ou convenção? Nem pensar!” “Ficar uma semana fazendo um curso de Java ? ‘Tá louco?”
O orgulho vem várias faces. Para a equipe é a síndrome de “não-foi-inventado-aqui” em que a equipe quer reescrever tudo o que já existe, procurando uma perfeição que não pode ser encontrada no que já existe pronto mas foi feito por outros. A recusa em utilizar frameworks e bibliotecas de mercado simplesmente porque não foram feitas aqui. Claro que nem todas podem ser usadas e nem sempre existem coisas já prontas para o que precisamos, mas a recusa a procurar por elas é a marca do orgulho. Outra forma de orgulho, mais pessoal, é a pessoa se vangloriar de alguma experiência que teve para justificar a decisão que tomou sendo mais comum o resalte dos anos de “experiência”, o famoso “Eu trabalho com isto há 30 anos”. Embora seja muito interessante para a biografia do sujeito, isto é irrelevante ao problema já que ter trabalhado com Clipper à 20 anos não o prepara para utilizar Java hoje em dia. A tecnologia evolui todos os dias, assim como as boas práticas e os paradigmas, a experiência longínqua não serve de nada agora. Isto não significa que a pessoa não possa utilizar o que sabe, o que aprendeu, apenas que ela não pode usar isso como trunfo para impor a sua decisão.
Os sete pecados são um assunto interessante e se está querendo saber mais leia Anti-Patterns – Refactoring Software, Architectures and Projects in Crisis (ISBN 0-471-19713-0) em que este tópico foi baseado. Recomendo.
Criar um software é um trabalho colaborativo tanto da equipe de desenvolvedores, como da gerência e, principalmente, do cliente. O cliente precisa saber o que pode dar errado num projeto de software e vigiar para que não aconteça. Não faz sentido que a gerencia de um projeto de software seja da software house apenas. É como colocar uma venda nos olhos do cliente. Se ele sabe vigiar problemas com todos os outros fornecedores porque não com o o fonecedor de software? Cuidado com os defeitos e a cobrança para resolver defeitos. O cliente entende muito melhor e mostra-se muito mais flexível quanto mais por dentro ele tiver do andamento do projeto. Seja honesto com o cliente. Aplique o triângulo de projeto sem medo. Ele compreende isso, pois ele usa o mesmo triângulo quando negocia com os clientes dele, no ramo dele.
Repeite o cliente, respeite a equipe e tudo dará certo.