Curtas

Por uma referência ao software público brasileiro

com Jarbas Lopes Cardoso Júnior* e Angela Maria Alves**

Podemos perguntar qual o propósito de um projeto desse tipo. Um projeto que visa criar um modelo de referência para o Software Público Brasileiro (SPB).

Podemos responder que é ?construir e aprimorar continuamente uma rede de produção colaborativa de conhecimento para desenvolver, em ambiente público, soluções informatizadas de TI direcionadas ao desenvolvimento sustentável (social, econômico, ambiental)?.

Também podemos perguntar aonde queremos chegar com isso. E igualmente responder que o SPB pretende se consolidar não apenas como mais um ambiente de produção colaborativa em rede, mas ir além e ser um modelo de sucesso que possa ser replicado em outras instâncias no país e no exterior, evidenciando que o modelo foi verdadeiramente apropriado pela sociedade.

O Projeto Modelo de Referência para o Software Público Brasileiro está sendo desenvolvido de forma cooperada e compartilhada para garantir a utilização de experiências anteriores bem sucedidas dos parceiros Centro de Tecnologia da Informação Renato Archer (CTI/MCT), Secretaria de Logística e Tecnologia da Informação (SLTI/MPOG), Centro de Tecnologia da Informação e Comunicação do Estado do Rio de Janeiro (PRODERJ), Secretaria de Política de Informática (SEPIN/MCT) e Associação Brasileira de Entidades Estaduais de Tecnologia da Informação e Comunicação (ABEP).

Conta com importante financiamento da Financiadora de Estudos e Projetos (FINEP/MCT).

A coordenação do projeto é feita por dois comitês: um técnico e um de gestão (gerenciamento). O Comitê Técnico é composto pelos líderes das diversas equipes transdisciplinares. O Comitê Gestor é composto pelos representantes das instituições parceiras e da Fundação de Apoio à Capacitação em TI (FacTI), uma fundação de apoio ao CTI.

Os comitês são acompanhados por dois outros comitês, um formado por representantes dos Grupos de Interesse e outro por técnicos da agência de fomento, a FINEP.

Como chegamos até aqui

O Projeto Modelo de Referência para o Software Público Brasileiro tem como objetivo ?aumentar a confiança em todos os níveis (legal, técnico, administrativo e de negócios) para os artefatos desenvolvidos, financiados ou geridos pelo governo, promovendo seu compartilhamento?. Esse objetivo difere consideravelmente do que foi pensado inicialmente, em meados de 2006.

A mudança é decorrente da maior compreensão do que é o SPB e seu potencial para subsidiar a produção de conhecimento público a partir de redes emergentes.

Essa maior compreensão vem dos constantes debates e reflexões realizados pelos os parceiros CTI, SLTI, PRODERJ, ABEP e SEPIN. Posteriormente, o debate foi sendo ampliado para os diferentes grupos de interesse, em especial as comunidades do Portal SPB.

O projeto foi originalmente idealizado com escopo mais modesto, não necessariamente menos complexo. Ele começou a ser delineado na segunda metade do ano de 2006 com ênfase no desenvolvimento de modelos abertos que viessem privilegiar o compartilhamento de software pelas instituições de governo em seus diferentes níveis e poderes.

Antes disso, é importante destacar como duas importantes iniciativas, surgidas em diferentes contextos, convergiram para conceber o Projeto Modelo de Referência para o SPB.

A primeira iniciativa é o próprio conceito do SPB, lançado pela PROCERGS, empresa de TI do governo do Estado do Rio Grande do Sul e associada da ABEP.

Posteriormente, em 2002, a DATAPREV, empresa de TI da Previdência Social, liberou o programa de inventário CACIC como software público. Em 2006, ABEP e SLTI celebraram um convênio visando aplicar o conceito de software público para facilitar o processo de compartilhamento de aplicativos de software entre os municípios, estados e a União.

A segunda iniciativa começou de forma independente em 2002. Parceiros em projetos de inovação em governo eletrônico, CTI, Governo do Estado de São Paulo e Instituto FOKUS/Fraunhofer, ABEP e outros parceiros na Europa e América Latina, propuseram e tiveram aprovado o projeto eGOIA (Electronic Government Innovation and Access) pela União Européia no âmbito no programa @LIS, Aliança para a Sociedade da Informação.

Um dos principais resultados alcançados foi o desenvolvimento, em 2005, de uma arquitetura de referência orientada a serviço baseada em padrões abertos de interoperabilidade. Com esse modelo foram realizadas provas de conceito em diferentes ambientes reais de operação na disponibilização de serviços ao cidadão: pela PRODESP (empresa de TI do Estado de São Paulo) junto ao Sistema Poupatempo, em prefeituras no Estado de São Paulo e na SLTI.

Além disso, os resultados do projeto eGOIA, através da ABEP, foram disseminados para as empresas de TI dos Estados. É importante destacar o fato de o projeto ter, durante o ano de 2006, treinado mais de duas centenas de profissionais em diferentes estados.

Com a intensificação da demanda por treinamento por parte das associadas da ABEP, somada a limitação de recursos, a restrições de modelos tecnológicos e as questões políticas, estava configurado o cenário promissor para que CTI, ABEP, PRODERJ e SLTI começassem a discutir a continuidade do projeto, surgindo então a pergunta inevitável ?por que não sob a luz do SPB??.

Durante 2007, esses parceiros, coordenados pelo CTI, trabalharam intensivamente na elaboração de uma proposta de projeto para o SPB. Esse período, altamente produtivo, contribuiu para uma maior compreensão do alcance do conceito SPB.

Em 2008 juntou-se aos parceiros a SEPIN visando não apenas a negociação de recursos para o desenvolvimento do projeto dentro do contexto do PACT&I (Programa de Aceleração da Ciência, Tecnologia e Inovação) como também a produção de resultados que viessem fortalecer a indústria de software do Brasil. No final de 2008 foi aprovado o financiamento do projeto pela FINEP.

Durante o período de discussão da proposta do projeto, acompanhamos diversas iniciativas nos EUA (OpenBBR, COSI) e na Europa (Qualipso), mostrando que não só estávamos no estado-da-arte quanto à preocupação em relação à qualidade dos artefatos, processos e serviços como fomos além, com o conceito de bem público associado ao software.

Tanto que fomos convidados a participar da 1ª Conferência do Projeto Qualipso no início de 2008 e a inclusão do SPB no Roadmap de Tecnologias Abertas (2020 Free-Libre Open Source Software Roadmap) como experiência inovadora a ser observada e amplamente disseminada.

Operacionalizando o projeto

A operacionalização do projeto está em grande parte na fundação de apoio, que obedece às normas e regras da FINEP, atuando com um braço dela dentro do CTI.

Os procedimentos são rígidos, a falta de carimbo indicando a pessoa que assinou um documento pode inviabilizar uma contratação, um pagamento ao fornecedor.

As licitações são recheadas de detalhes, uma vírgula fora do lugar pode caracterizar serviço além do escopo. Um relatório de viagem sem o comprovante de embarque original implica na suspensão das próximas viagens do beneficiário até a apresentação do comprovante original ou reembolso.

Pagamento de diárias em conta bancária somente se a conta estiver no nome do beneficiário, não servindo a conta da própria empresa contratada, mesmo o beneficiário sendo o proprietário.

Toda requisição de recursos é comparada com o Plano de Trabalho e normalmente é questionada. Raras são as justificativas técnicas que são aprovadas logo na primeira emissão, gerando enorme retrabalho na confecção de documentos e demandando extensivo tempo para dialogar com os responsáveis pelos procedimentos.

Além disso, há uma série de procedimentos internos do CTI que devem ser obedecidos, como por exemplo, realizar um cadastro completo de um convidado externo do projeto para simplesmente emitir uma passagem aérea em seu nome. Se dados como o tipo sanguíneo ou a formação acadêmica não estiverem preenchidos corretamente, nosso convidado pode ficar sem viajar.

A isso devemos somar estruturas organizacionais que não dispõem de mecanismos de punição ou de premiação, como também considerar que parte de nossos parceiros são oriundos do mundo do software livre, onde o caos positivo (que produz algo útil) impera e a aversão à disciplina e aos procedimentos de controle, de administração são marcas registradas.

A equipe operacional de gerenciamento do projeto acaba ficando mais focada em ?apagar incêndios? do que aplicar as boas práticas preconizadas no mundo do gerenciamento de projetos.

Aliás, em um projeto com estas características, surgem novas boas práticas e modelos de gerenciamento, de acordo com os ritos de agências de fomento, fundações de apoio e estruturas organizacionais permissivas.

Riscos

A construção de relacionamentos de confiança em projetos de cooperação não é uma tarefa fácil. Os projetos de desenvolvimento cooperado e compartilhado são fortemente baseados na confiança.

O cenário atual nos remete a uma situação de praticamente eliminar a conotação de confiança no contexto social, fundamental para o processo de inovação tecnológica.

Os projetos de pesquisa e desenvolvimento são regidos pela Portaria Interministerial 127/2008 e o Acórdão 2731/2008 do TCU (Tribunal de Contas da União) que impõem um conjunto de normas e regras que as fundações de apoio devem seguir rigorosamente sob pena de severas punições, inclusive aos pesquisadores.

Se por um lado o controle e a transparência no uso dos recursos públicos são benéficos, por outro lado, o estabelecimento de regras contratuais rígidas causa um aumento substancial do custo das transações entre os parceiros e contratados pelo projeto.

Com um complicador adicional: aquela confiança social, tão eficaz na produção de conhecimento, geradora de valiosas contribuições para o projeto, fica seriamente comprometida.

Um projeto de desenvolvimento inovador pelo que propõe e, sobretudo, inovador na forma de desenvolver a solução para o problema, sem dúvida alguma apresenta uma série de riscos, todos eles decorrentes do debate do modo de tratar o processo de inovação, ou seja, tratar coisas novas com as formas convencionais.

Podemos citar alguns riscos, entre muito outros: incompatibilidade da dinâmica do projeto com a cultura das entidades envolvidas (gestão, participação, agilidade, compartilhamento, comprometimento, inovação, ousadia); adoção de padrão de redes do tipo comando e controle para redes emergentes auto reguladas baseadas na confiança; desconsideração com as necessidades da demanda (formulação de ferramentas, que embora sofisticadas, tenham pouca aderência com a realidade); recursos financeiros insuficientes ou de difícil utilização; insucesso na criação e manutenção de comunidades; não atendimento às expectativas dos grupos de interesse, em especial das comunidades; desmotivação das equipes.

Acreditamos que esses riscos e as restrições impostas, ainda que a duras penas, serão superadas e conseguiremos não só construir o modelo de referência para o software público brasileiro plenamente aceito e apropriado pelas comunidades como também difundiremos a cultura de produção cooperativa e a confiança nos produtos e relacionamentos desse processo.

As dificuldades são intrínsecas e na medida do possível estão sendo resolvidas de forma a cumprir as exigências formais das instituições FacTI e CTI e ao mesmo tempo garantir a flexibilidade e leveza que um projeto deste tipo necessita.

Convém ressaltar que o projeto está no seu nono mês de desenvolvimento e apresenta resultados que podem ser avaliados pelos seus stakeholders.

_______
* Jarbas Lopes Cardoso Júnior é graduado (1977) e Mestre (1980) em Física pela Universidade Estadual de Campinas. Atualmente é tecnologista sênior do CTI ? Centro de Tecnologia da Informação Renato Archer, e professor titular da UNIP ? Universidade Paulista.

** Angela Maria Alves é doutoranda em Tecnologia da Informação pela USP/POLI/Produção, Mestre em Qualidade pela Universidade Estadual de Campinas/Faculdade de Engenharia Mecânica (2002), Engenheira Elétrica/Eletrônica pela Fundação Educacional de Barretos (1977), Coordenadora da pós-graduação “lato sensu” da Universidade Federal de Lavras e pesquisadora do CTI ? Centro de Tecnologia da Informação Renato Archer.

*** Artigo modificado a partir da publicação na Revista InfoBrasil, com o título ‘Um Modelo de Referência para o Software Público Brasileiro’,
junho/agosto de 2009, Ano II, nº 7, A2 Comunicação, sob a licença Creative Commons.