Então diretor de TI, o seu sistema corporativo é gratuito, porque foi trazido de uma empresa-irmã, que o considera o software livre (Via de regra não é [1]). Assim, a cada versão do sistema original, sua corporação atualiza também o sistema instalado, se conseguir ir tão rápido. Mas alguns problemas indicam que o sistema é lilliputiano, o que pode sair caro. Como resolver isso ?
O QUE SÃO SISTEMAS LILLIPUTIANOS ?
Sistemas lilliputianos são aqueles que não podem funcionar sem a intervenção de uma forte equipe de controle de danos. Lilliput é uma ilha fictícia do romance As Viagens de Gulliver, de Jonathan Swift. Nela, habitariam seres pequeninos, muito organizados e trabalhadores. Justamente o tipo de seres necessários para fazer funcionar um sistema incongruente com a realidade da empresa. Tais sistemas precisam de correções constantes no código, no ambiente de operação e, principalmente no banco de dados - o que é uma má prática, afinal. São sistemas caros e com o tempo desgastam a equipe de manutenção, condenando-a a um sem-fim de atividades chatas e trabalhosas. É a equipe que sempre apanha de todos os lados e a quem cabe a culpa pelos defeitos.
PROBLEMAS EM LILLIPUT
O que se observa frequentemente nesses sistemas é:
- As bases de dados são alteradas pelos scripts de atualização de versão, levando a conflitos inesperados e causando paradas indesejáveis para correção.
- Na operação "normal" acontecem problemas que precisam ser corrigidos no banco.
- Alterações em versões novas às vezes diminuem a produtividade do usuário.
- Alterações em versões locais são "atropeladas" por versões maiores do produtor, o que traz a volta de problemas que já haviam sido solucionados.
COMO RESOLVER A CRISE DOS SISTEMAS LILLIPUTIANOS ?
- Livre-se da relação com organização principal. Você tem o código, tem pessoal especializado no banco de dados e no negócio, tem o feedback dos usuários. Livre-se do versionamento e passe ao seu próprio fork, lançando versões que realmente atendam às necessidades de seu público.
- Crie equipes de revisão de código, com o objetivo de extrair o que não interessa e simplificar os fontes e a tecnologia usada. Lembre-se: Menos, é menos suporte !
- Cria com urgência uma comissão de usuários, que determine o que é importante realmente implementar. Será que aquela feature de IA é mesmo essencial, ou é melhor que o requisitórios de pequeno valor funcionem bem ?
- Crie um projeto de liberdade. Determine que, a partir de agora, você não vai mais depender da fornecedora original. Mas cuidado, diretor ! Você pode perder o emprego no processo, se não se cuidar. Você precisa (1) De um patrono poderoso para a ideia (2) De uma campanha interna e externa de propaganda (3) De uma equipe descansada e renovada (4) De muitos estagiários de nível superior (5) De um defensor da ideia e líder de projeto. Essa pessoa ganha bem e deve estar pronta para ser incendiada a qualquer momento. E não pode ser você. Você deve ter um consultor experiente atuando por trás de sua imagem.
- Premie sua equipe, se não quiser perdê-la por exaustão.
- Treine o pessoal e estimule o desenvolvimento de pequenas soluções com o novo framework do sistema. Por exemplo: É difícil fazer CRUD com as rotinas do tal sistema lilliputianos ? E se, a partir de agora, só esse framework for usado ? Assim ele seria testado ao máximo.
- Simplifique as tecnologias usadas. Pare de misturar coisas complexas e de dividir o esforço de treinamento da equipe. Por exemplo: Java e só Java.
- Treine equipes em qualidade de software. Provavelmente você não tem nem metrias.
- Faça estatísticas dos problemas ocorridos a cada versão e compare os prós ou contras. Use o sistema de helpdesk para isso. Aliás, qualquer pedido de alteração de sistema deve estar no helpdesk, não se admitindo outro canal. Não se pode alterar aquilo que não se pode medir.
- Obrigue a equipe a documentar tudo numa base da conhecimento única (KB - KnowledgeBase). Hoje certamente o conhecimento deve estar espalhado. Provavelmente você tem zero de documentação das tabela do banco, difusa documentação da consolidação das normas da organização, queries ocultas que os especialistas desenvolveram para soluções, nos apertados registros no OneNote. Enfim, você precisa de uma KB integrada e com capacidade de acesso discricionário - O Plone se presta bem a isso, desde que você use Single Sign On (SSO).
- Elabore as estatísticas de melhoria a partir do início de atividade do seu projeto de liberdade.
- Implemente as alterações aos poucos e quase em processo de guerrilha. Mas pegue para si a tarefa de evitar por enquanto novas versões, baseadas em novos requisitos. Esse grande passo político precisa ter o apoio da alta gerência e deve ser indiscutível - lavrado e assinado após os devidos "considerandos" alimentados por suas estatísticas.
- Implemente o Single Sign On ! Isso pode ser uma evolução dolorosa em sua empresa e pode durar tanto quanto uma década ! Mas comece ... nem que seja pela unificação do servidores AD !
- Negocie a alteração do acorso de cooperação com a entidade-irmã, de modo que os resultados ainda possam ser compartilhados. Não deve ser uma ruptura dolorosa, mas sim natural e consensual.
QUANDO TERÁ DADO CERTO ?
Simples. Quando ninguém mais precisar mexer em banco de dados tentando solucionar problemas !
RESUMO RÁPIDO
- Implantar base de conhecimento única na organização (KB).
- Promover a migração do conhecimento para a KB.
- Garantir que qualquer pedido ou ocorrência em relação ao sistema em análise seja registrado corretamente no sistema de helpdesk. Solicitar apoio da equipe de atendimento.
- Obter estatísticas sobre os efeitos das migrações e elaborar relatório.
- Incentivar a criação de um grupo de usuários, que possa ser de apoio político ao projeto. Manter contato constante com o novo grupo.
- Analisar continuamente o ambiente político propício para o novo projeto.
- Preparar a campanha marketing necessária.
- [ SENSÍVEL ] Entregar relatório à alta direção com recomendações.
- [ SENSÍVEL ] Criar o projeto de liberdade, escolher a liderança e a assessoria de projeto.
- Executar a campanha de marketing.
- [ SENSÍVEL ] Negociar com a organização fornecedora a transição.
- [ SENSÍVEL ] Abandonar a paridade de versões com o fornecedor e partir para um fork próprio.
- Promover a documentação interna da base de dados.
- Estimular o uso do framework do próprio sistema para aplicação novas e alteração das antigas, onde for possível.
- Avaliar continuamente as modificações necessárias e medir a produtividade.
- Proibir o acesso ao banco, dando preferência a ferramentas feitas com o framework e que documentem os logs.
- Integração com o projeto de Single Sign On.
- Implantar logs integrados com outros sistemas.
Converse com um etnógrafo de tecnologia. É um profissional ainda novo no mercado, mas vai te dar uma visão fantástica.
[1] Por exemplo, um software livre sem um instalador simples não é necessariamente livre, pois amarra a instalação ao fabricante.