Na busca de tentar resolver – ou pelo
menos minimizar – a bomba-relógio que é a guerra desigual entre os recursos
cada vez mais limitados frente às demandas cada vez mais crescentes no mundo de
TI, uma das coisas que sempre me vêm à mente é a dicotomia Generalização/Especialização.
As ideias mais modernas de
governança apontam para que os recursos sejam os mais genéricos possíveis, e
alocados de acordo com a necessidade estratégica da organização. Na prática,
porém, isso é impossível. Pelo menos em sua totalidade. Mas
parcialmente, é possível. E fundamental!
A questão é: em que áreas isso
deve ser aplicado? Em construção? Requisitos? Teste? Gestão de projetos?
Infraestrutura? Talvez em todas, com percentuais diferenciados.
Aqui não estamos falando de software houses, ou de qualquer empresa
exclusivamente de TI, mas de empresas comerciais que têm uma área de TI, cuja
abordagem é bem diferente.
No geral, temos dois tipos de estruturação:
- Especialização no processo (projeto, requisito, teste, infraestrutura) ou
- Especialização no negócio (cartão, empréstimo, CRM...)
Talvez, o que dê uma melhor relação custo/benefício seja um mix, algo do tipo:
Construção: aqui não há margem para ilusões. A dependência do conhecimento do negócio é altíssima, indispensável. Então, algo como 70% de especialização no sistema e 30% de generalização (ou seja, o funcionário, aqui, é especialista “apenas” em linguagem, banco de dados, enfim, tecnologia) talvez fosse uma boa segmentação. Somente esses 30% seriam a mão-de-obra flutuante, aquela que pode ser redirecionada conforme a estratégia da organização. Na prática, é quem pode manter a produtividade ao sair de um sistema contábil para outro de auditoria, por exemplo. Ou seja, grosso modo, uma “mini-fábrica-de-software” interna;
Requisitos, testes, outros processos: 30% especialista em sistemas críticos (conhecendo também o processo relacionado) e 70% “genérico”. Aqui a flexibilidade é maior, assim como essa liberdade aumenta cada vez mais, conforme o processo. Ainda assim, o conhecimento prévio do negócio ainda é muito importante, principalmente por um aspecto: o negócio crítico é cada vez mais comprimido por restrições de tempo e abstração na sua especificação.
Isso é o que funciona. Porque, na prática, a teoria é outra.
Construção: aqui não há margem para ilusões. A dependência do conhecimento do negócio é altíssima, indispensável. Então, algo como 70% de especialização no sistema e 30% de generalização (ou seja, o funcionário, aqui, é especialista “apenas” em linguagem, banco de dados, enfim, tecnologia) talvez fosse uma boa segmentação. Somente esses 30% seriam a mão-de-obra flutuante, aquela que pode ser redirecionada conforme a estratégia da organização. Na prática, é quem pode manter a produtividade ao sair de um sistema contábil para outro de auditoria, por exemplo. Ou seja, grosso modo, uma “mini-fábrica-de-software” interna;
Isso é o que funciona. Porque, na prática, a teoria é outra.