Essa é uma questão com a qual me deparo frequentemente. Vou contar para vocês os cenários que tenho visto em muitas empresas, e que leva a escrever este post.
Fazer software é difícil:
- É difícil entender o que o usuário espera, o que o patrocinador do projeto espera, o que o gerente do usuário espera, e juntar tudo isso em uma solução única.
- É difícil fazer isso dar dinheiro.
- É difícil tornar isto prazeiroso para a equipe envolvida.
- É difícil conciliar todos estes interesses, muitas vezes opostos.
- É difícil encontrar uma boa arquitetura, onde exista equilíbrio na abstração, efetividade, e produtividade.
- É difícil encontrar bons profissionais, que gostam do que fazem, e são comprometidos com a empresa que trabalham, e não (só) com o salário que recebem.
- É difícil criar uma solução feita para enfrentar o teste dos anos, para o qual nenhuma técnica de testes (TDD, BDD, xDD) está preparada.
- É difícil escolher a plataforma correta para o desenvolvimento, incluindo a linguagem, a abordagem, e os princípios.
- É difícil, sobretudo, ter o envolvimento efetivo do usuário/cliente no processo de desenvolvimento.
E estas são só algumas das dificuldades. Se fosse tentar listar todas, o post seria sobre isso. Na verdade, teria que publicar um post beta para sempre, em revisão eterna.
Começo deixando isso claro, porque esse fato é reconhecido pela maioria das empresas. E reconhecendo-o, devem lidar com ele. Basendo-se nestas dificuldades, as empresas têm buscado soluções para estas dificuldades (problemas/oportunidades?). E boa parte destas soluções passam por proteger o desenvolvedor. O que significa proteger o desenvolvedor?
Proteger o desenvolvedor significa que os desenvolvedores devem ter a maioria dos problemas resolvidos para eles. Isso passa pela premissa de que eles são incapazes de resolver os problemas sozinhos. Por esse motivo, tira-se do desenvolvedor qualquer tipo de decisão, deixando a ele somente uma tarefa: codificar. Codificar o quê? O que o analista de negócios especificou. Como? Com o design do analista de sistemas. Com que técnicas e ferramentas? Com os frameworks corporativos, a (pré-definida) linguagem de programação homologada (atenção para o singular), e as abordagens (pré-definidas) pelo arquiteto.
Dessa forma, o codificador tem que tomar poucas decisões. Ele só tem que decidir o que não foi decidido para ele ainda. Neste estágio, não podemos mais chamá-lo de desenvolvedor, já que não desenvolve nada, só códifica. Todo desenvolvedor também é codificador, mas o oposto não é verdade.
Qual o problema com esta abordagem, que claramente vem de uma decisão gerencial? Enxergo de imediato dois:
O primeiro problema é assumir que o sistema de linha de montagem de uma fábrica de automóveis é plenamente compatível com o sistema de criação de um software. De que é possível alienar o trabalhador da informação, deixando para ele apenas um pedaço da montagem do software. De que é possível comunicar tudo o que é necessário com papel e diagramas. Enfim, de que é possível criar uma "fábrica de software", termo que devia ser apagado do vocabulário de qualquer pessoa que trate seu processo de desenvolvimento de software com seriedade. Estes sistemas, o de montagem de automóveis, e o de criação de um software não são compatíveis. Software é algo imaterial, que vive apenas na idéia das pessoas. Enquanto um desenho CAD é capaz de comunicar exatamente como uma caixa de câmbio deve ser produzida, um documento de especificação é incapaz de fazer o mesmo. Duas pessoas lendo o mesmo documento, ou mesmo falando com o mesmo usuário, terão idéias diferentes sobre o software a ser criado, não só no "o que", mas também, e principalmente, no "como". Entendendo isso, fica fácil perceber porque sistemas baseados em fábrica de software (seja ela interna ou externa à empresa), em linha de montagem, dão tão errado. Porque o software tem defeitos de especificação de negócios, de especificação técnica, e inúmeros bugs. Além disso tudo, nunca fazemos softwares parecidos (quem dirá iguais), enquanto que na linha de montagem de um carro, o carro é sempre o mesmo, mudam só alguns detalhes.
O segundo problema está na premissa que citei antes: os desenvolvedores são incapazes de tomar decisões sozinhos, não têm competência para isso, são incompetentes. Quando você trata o desenvolvedor como um incompetente, ele passa a se entender como um incompetente, e não se preocupa mais quando algo dá errado. Ele não busca mais a melhor solução, isso não é mais problema dele. Já que você está tratando ele como operário fabril, então ele vai se comportar como um. E já que ganha por hora, então o foco passa a ser fazer a maior quantidade de horas possível, que não vão dar em nada, já que ele sabe que nada dá em nada mesmo, porque é incompetente. A melhor maneira de acabar com o comprometimento de um desenvolvedor é tratá-lo como uma criança incapaz de tomar decisões.
Como resolver esses problemas? Atacando suas premissas. Primeiro: o desenvolvedor não é incompetente, e segundo: criar software é diferente de montar um carro. Como o assunto é proteger o desenvolvedor, vou falar da primeira. A segunda fica para outro dia.
Se você assume que seu desenvolvedor é incompetente, você tem duas opções: capacite-o para ser mais competente, ou mande ele trabalhar em outra empresa. Então vamos combinar assim: você entende que seu desenvolvedor não é incompetente. Sabendo que seu desenvolvedor possui competência para fazer um bom trabalho, você não deve tomar decisões por ele. Ele deve ser capaz de tomar as decisões corretas. Isso significa que ele deve ser capaz de falar com o usuário, decidir sobre a implementação de um requerimento, e saber usar padrões. O arquiteto pode ajudá-lo nessas tarefas, mas não deve realizá-las para ele. O arquiteto deve inspirá-lo, deve fazer coaching, mas nunca codificar para ele, porque ele é competente o suficiente para isso.
E onde ficam os frameworks corporativos, os padrões, a reusabilidade no nível da corporação? Muitas empresas fazem esse tipo de framework para ganhar tempo, diminuir a quantidade de código que escrevem, e agora? Este tipo de framework deve surgir quando necessário, e deve ter uma amplitude muito limitada. Acredito que é possível ter um framework corporativo, desde que ele emerja das necessidades reais dos projetos, ou seja, sejam abstraídos a partir de algo real que precisou ser implementado, e que pode ser reutilizado. Nesse contexto, os frameworks acabam sendo estritamente técnicos, e não de negócio, e atendem necessidades reais dos desenvolvedores. Por exemplo, não é possível ter uma entidade cliente e um repositório de clientes que possam ser reutilizados em qualquer sistema, porque em sistemas diferentes os contextos de uso do cliente são diferentes. A entidade cliente é grande demais para ser utilizada sem abstração, ela é um requisito de negócio, e cada sistema modela um processo de negócio diferente, e enxerga o cliente de forma diferente. O que faz sentido é ter componentes que resolvem problemas técnicos, como um repositório base, por exemplo, ou um framework corporativo para conexão com banco de dados seguro, ou ainda um framework de autenticação. Estes podem emergir quando necessários, e devem ser feitos seguindo boas práticas, como o open closed principle, para que não se tornem um peso no processo de desenvolvimento, mas sejam uma solução real.
Na prática, o que acontece nas empresas, é que o gerente não confia na equipe que tem, e estando acostumado a trabalhar no estilo comando/controle, diminui as variáveis que deve controlar para facilitar o próprio trabalho. É algo que pode até dar resultado em trabalhos mais repetitivos, como a montagem de um carro (e há casos onde esse tipo de coisa também não é verdade, vejam o caso da Toyota), mas certamente não funciona em software. Aplicar teoria clássica da administração na gestão de software é algo, no mínimo, anacrônico. O que deveria estar acontecendo é um movimento dos gerentes funcionais atrás de atualização, de forma a se prepararem para lidar com o trabalhador do conhecimento do século XXI, que não reconhece mais fronteiras hierárquicas, é criativo, independente, e, sobretudo, competente.
Se você é gerente, deixo aqui minha pergunta para você: que tipo de gerente você quer ser? O que entrega, tem funcionários felizes, baixo turn over, preparado para as necessidades contemporâneas? Ou o anacrônico, gerenciando conforme as técnicas ultrapassadas que pregam comando, controle, e que geram funcionários insatisfeitos, que em pouco tempo vão trabalhar em outro lugar se você não lhes der um bom calhamaço de dinheiro? E se você é empresário de TI, a pergunta é: que tipo de empresa você quer ter: a preparada para um mercado dinâmico, que demanda qualidade E custo, ou a ineficiente, que briga no mercado com centenas de concorrentes muito parecidos, depende de um nicho muito específico para viver, e que pode tomar a rasteira de uma empresa mais eficiente a qualquer momento e ir à lona? Ah, e se você é gerente, e não se entende também como empresário do seu próprio centro de custo, você está com problemas. Hoje o departamento de TI é um prestador de serviços, mesmo internamente, e você pode, se não der ROI, ser substituído tão rapidamente quanto um fornecedor. Fique atento.
Em resumo: se você está protegendo seus desenvolvedores está criando um ambiente onde a solução dos problemas não aparecem naturalmente, está restrigindo a capacidade dos desenvolvedores de dar a melhor solução para um problema, e está atrapalhando, e não ajudando o departamento que gerencia. Não proteja seus desenvolvedores, proteja o investimento que a empresa fez em você quando o colocou em uma posição gerencial, e busque produtividade encarando de frente a realidade que faz o desenvolvimento de um software nos dias de hoje. Permita aos desenvolvedores criar, e ajude-os a chegar lá, capacitando-os, e fomentando a reutilização quando ela fizer sentido, de forma a alavancar a produtividade.