Virar o problema do avesso

Há alguns anos atrás, participei num projecto de desenvolvimento de um sistema de informação para a minha escola. O sistema que se encontrava a funcionar na altura tinha sido desenvolvido nos anos 80 e já não suportava com facilidade alterações. O sistema foi a inovador para a época em que tinha sido desenvolvido. Contudo, a tecnologia utilizada tinha-se tornado obsoleta, e estava-se a atingir a situação crítica em que o conhecimento acerca do sistema estava em uma ou duas pessoas. 

Quando procurámos perceber como se tinha chegado a esta situação foram-nos apontadas diversas razões. O projecto foi um sucesso, tendo contado com o apoio da gestão que se tinha envolvido directamente nele, mas o seu envolvimento foi progressivamente diminuindo. Os utilizadores faziam constantes pedidos de alterações dado não haver custos associados, tendo-se tornado um projecto com uma significativa vertente de manutenção. Haver poucas pessoas no mercado de trabalho que dominassem as tecnologias usadas. A incapacidade da escola concorrer com as empresas de software para a contratação dos melhores recursos humanos, quer em termos salariais quer em termos de perspectiva de carreira.

Estávamos portanto perante uma situação típica dos problemas resultantes do desenvolvimento de um sistema in-house. As receitas para este problema são conhecidas: comprar feito (off-the-shelf) ou mandar fazer (outsource). 

O sistema de informação iria focar sobre o core business da escola, a gestão dos planos curriculares, a gestão dos semestres, etc. Por exemplo, pretendia-se vir a ter a capacidade de adaptar facilmente os planos curriculares, curso a curso e ao longo dos anos. Esta situação tornava a solução de comprar feito menos interessante pois o sistema a adquirir seria idêntico ao usados por outras escolas que adquirissem o mesmo sistema, reduzindo a capacidade de o sistema de informação ser um instrumento da estratégia de diferenciação da escola relativamente às restantes. A solução de mandar fazer resolve o problema do suporte informático à diferenciação estratégia dado que sistema será feito à medida. Contudo, requer uma maior competência da escola em termos de informática. É necessário ter profissionais que trabalhem no levantamento de requisitos e que tenham as competências necessárias para gerir o contrato com a empresa de software durante um longo período de tempo. Ou seja, no caso de mandar fazer, a escola terá que ter recursos humanos com conhecimentos na área da informática, enquanto que na opção de comprar feito essa capacidade não será tão relevante.

Em ambas as situações, comprar feito e mandar fazer, embora os custos iniciais sejam menores eles tendem a aumentar com a manutenção que pode durar muitos anos. Uma outra situação que se verifica é que as organizações que seguem estas estratégias ficam dependentes das empresas de software. Relativamente ao desenvolvimento in-house, passa-se da dependência de uma equipa interna para a dependência de uma organização externa.

Este era o problema que tínhamos entre mãos e, dado que já tínhamos identificado as vantagens e desvantagens de cada uma das possíveis soluções, agora era altura de decidir. Este problema é de facto ubíquo a todas as organizações que necessitam de sistemas de informação para o seu funcionamento, espero futuramente voltar a esta questão.

A solução que na altura parecia mais indicada, um pouco influenciada pelo resultado do desenvolvimento in-house, seria de procurar ter o desenvolvimento fora. Contudo nós resolvemos olhar de novo para o problema e reformulá-lo da seguinte forma:

• O problema tem a ver com o facto das actividades associadas ao desenvolvimento do sistema de informação não contribuírem para a missão da escola, embora o sistema de informação dê suporte ao core business da escola.

Tendo reformulado o problema, procurámos perceber qual era a missão da escola e como é que o desenvolvimento do sistema de informação poderia ser colocado nesse contexto:

• Transmissão de conhecimento - dado que uma das missões da escola é o ensino porque não usar o sistema de informação e o seu processo de desenvolvimento como material pedagógico.
• Criação de conhecimento - dado que uma outra missão da escola é a investigação porque não fazer investigação sobre problemas identificados no projecto e aplicar os resultados da investigação no sistema.
• Transferência de tecnologia - dado que a escola tem a responsabilidade de transferir para a sociedade os resultados do seu trabalho porque não fazer o desenvolvimento open-source e motivar outras escolas a usar o sistema e empresas a fazer a sua distribuição e adaptação.

Seguindo esta estratégia, o sistema passa a ter um valor próprio para a missão da escola deixando de ser secundário, embora necessário. Para além disso permitiu-nos resolver alguns dos problemas que identificámos, ou foram pelo menos colocados numa nova perspectiva que permite outras soluções:

• Dado que o sistema é usado no ensino, o número de recursos humanos que conhecem o sistema é maior, evitando que o conhecimento fique reduzido a um reduzido grupo de pessoas. Por outro lado, o custo dos recursos humanos será menor dada a oferta.
• O facto de haver investigação sobre o sistema evita que a tecnologia que usa se torne obsoleta, sendo motivante para as pessoas que nele trabalham, pois sentem que estão a trabalhar com tecnologia de ponta. Por outro lado, os trabalhos de investigação evitarão que o desenvolvimento seja apenas de manutenção.
• A partilha do desenvolvimento e do conhecimento seguindo o modelo open-source permite resistir às flutuações do envolvimento da gestão, o projecto é independente das decisões da gestão de uma particular escola, e de financiamento, as escolas que tiverem mais recursos num determinado momento serão aquelas que "puxarão" o projecto. Adicionalmente, o conhecimento sobre os sistema deixa de ficar limitado a uma única organização.

Apresentei este caso durante um painel da SINFO sobre Sistemas de Informação na Administração Pública pois acredito que muitos dos problemas são iguais àqueles que tivemos que enfrentar. Contudo, não creio que a solução possa ser a mesma pois nestas coisas a "cópia" não funciona. Ainda assim, o espectro das variações sobre as 3 alternativas standard está sempre lá - in-house, off-the-shelf e outsource - a não ser que se vire o problema do avesso.