Veja neste artigo uma breve discussão sobre pessoa que é responsável por gerar um atraso físico no processo de software. Esse profissional "delay tier" também é carinhosamente conhecido como "tio da senha".
A divisão do software em camadas, atualmente, é certamente uma das formas mais eficientes de se estar organizando a sua aplicação. Facilitando a manutenção, reaproveitamento de código, etc. Vale salientar que camada no inglês tem duas palavras: Tier, a camada física e Layer, camada lógica. No entanto, criar um grande número de camadas além de desnecessário acaba deteriorando a desempenho do seu software. Assim surgiram as chamadas delay layer, camadas lógicas que apenas servem para passar à informação a diante, gerando atraso na reposta e consumo desnecessário na memória. Esses atrasos em alguns casos acontecem fora da parte lógica da aplicação. Acontecem no processo de desenvolvimento (fora do código), pessoas ou profissionais que acabam gerando um atraso na resposta, delay tier, conhecido carinhosamente como os "tios da senha".
Figura 1: O tempo de resposta das aplicações hoje é um fator fundamental
Exemplificando como eles funcionam, podemos citar funcionário que aperta o botão no elevador, vale ressaltar que não estamos desmerecendo nenhuma profissão. O elevador possui uma interface bastante simples e basta se pressionar o botão com o andar desejado. Você precisa informar o andar desejado ao funcionário e ele por sua vez apertará o botão. Essa chamada gerará um atraso natural até você informar o andar desejado e esse profissional executar sua ação, quando entrarem dez pessoas simultaneamente essa demora será "gritante".
As empresas não o contratam diretamente, alguns preferem chamar de Arquitetos, gestores de aplicação ou DBAs, são profissionais que centralizam alguns até mesmo todos os processos de software de uma empresa. Essa ação gera um pseudo controle para a empresa, porém, acaba gerando atraso tanto nas escolhas de tecnologias quanto na execução de um script, alteração no banco de dados etc. e esses atrasos impactam diretamente a entrega desse projeto.
Caso os detentores das senhas, se desmotivarem e parem de se atualizar profissionalmente. O parque tecnológico da empresa em pouco tempo virará artefato de museu.
Centralizar decisões técnicas para todos os projetos é um grande erro! Ninguém melhor que um membro da equipe para decidir qual ferramenta é a mais interessante para um requisito específico. Sem falar que pode gerar uma padronização equivocada, ou seja, para todos os problemas a mesma solução. Dizer que para todos os problemas precisamos de um martelo é dizer que os parafusos também são pregos.
Figura 2: Centralizar decisões técnicas não é uma boa escolha
O aumento demasiado do ego, isso mesmo, um técnico com um ego muito grande faz com que toda a empresa use tecnologias do seu "mundinho" para que assim ele seja o maioral.
Mau aproveitamento de um profissional, se queremos executar um simples script ou renomear um campo de uma tabela, para que precisamos de um DBA para uma atividade tão trivial? Seria mais interessante que ele estivesse ajudando em atividades como: trabalhar para dar maior desempenho e diminuir o tempo de resposta no banco, definir índices, ajudar na escalabilidade do banco, uma mudança de estratégia para um banco NOSQL ou NewSQL, bigdata, ajudar na criação de queries com mais desempenho ou talvez criação de views, etc.
Ou o que eles precisam fazer?
Em relação das ações, o que eles precisam fazer é o processo totalmente inverso, ou seja, o de não centralizar informação e facilitar o acesso ao conhecimento. Descentralizar é fazer com que as informações circulem de maneira mais "livre" e que as soluções partem de qualquer parte da empresa. Estimular atividades como codingdojos, participação de eventos, wiki na empresa, etc. Uma equipe autogerenciável deve ser o sonho de qualquer gestor de TI que esteja em 2012.
Remover os atrasos do processo software é crucial para manter um ciclo saudável no desenvolvimento. Conhecer a filosofia "toyotismo", que se tornou base para as metodologias ágeis, e dizer adeus ao "Taylorismo", filosofia de Taylor que visa centralizar as decisões, é um pequeno passo para isso. Desconcentrar processos e decisões de software é muito mais do que apenas remover uma camada física desnecessária, delay tier, também é criar uma equipe auto-gerenciável, impedir que a empresa vire um museu, permitir que existam opções para solucionar um problema e que a mais adequada seja utilizada, deixar fluir a informação e fazer com que os profissionais se atualizem e utilizem tal conhecimento. Sobre tudo demonstrar que gosta do que faz e passar esse prazer para os outros membros da equipe, estimular para que eles também façam o mesmo.