TI: Teoria e Prática

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.