Escolha uma Página

Nuvem de Governo ou Governo na Nuvem?

O debate que atingiu a crista do hype nos últimos meses é o debate sobre a contratação de infraestrutura na nuvem. Esse debate tomou diversos sabores ao longo dos últimos anos, e especificamente nos últimos meses se concentrou em discutir formas de reduzir custos de operação, tanto de órgãos públicos quanto de empresas públicas, por meio do modelo de contratação de Infraestrutura como Serviço (IaaS).

Considero que houveram três movimentos centrais nesse processo, que polarizaram a discussão e foram experiências concretas, disputando a audiência dos CIOs da esplanada: O OpenStack do SERPRO; a aquisição de Azure do Ministério do Planejamento; a Cloud do Ministério da Cultura.

 

OpenStack do SERPRO

 

Durante o ano de 2015, a SLTI/MP fez um movimento de organizar alguns representantes de órgãos que tinham contratos com o SERPRO, chamaram de Conselho de Clientes do SERPRO, que se reunia para debater questões de interesse dos órgãos que exigiam melhorias nos serviços e redução dos preços praticados pela empresa. Muitos deles não tinham a opção de migrar de fornecedor dada a criticidade dos serviços prestados, só podiam ser atendidos pelo SERPRO, porém não estavam satisfeitos com a forma de precificar esses serviços, e também demandavam avanços nas formas de gerenciar os serviços contratados.

Esse movimento provocou mudanças estruturais no modelo de negócios do SERPRO, algumas ainda em curso, mas basicamente colocou a disposição uma plataforma de auto serviço para gestão de infraestrutura, baseada em OpenStack com Horizon, onde os órgãos poderiam contratar uma cota de memória RAM e uma capacidade de Storage, para montar sua infra da forma que achasse necessário. Nas últimas reuniões que tive com a equipe de infra do SERPRO, eles chegaram a relatar que planejavam implementar um sistema de bilhetagem de utilização de recursos até outubro de 2016. Esse movimento de oferta de IaaS com bilhetagem de uso muda radicalmente a política de negócios do SERPRO, onde não existia muita clareza sobre a forma que os serviços eram cobrados, o que deixava os clientes suspeitosos, por terem uma grande diversidade de contratos com modelos de gestão diferentes, o que poderia significar que alguns estavam pagando mais caro que outros para obter os mesmos recursos.

Com a solução baseada em OpenStack, com auto serviço de consumo de recursos, o SERPRO passa a dar um salto na sua arquitetura de nuvem, oferecendo um serviço de melhor qualidade, mas não necessariamente mais competitivo, seus preços ainda são muito altos e não conseguem disputar espaço no mercado privado.

Acredito que a solução tende a mostrar novos caminhos gerenciais para o SERPRO, possivelmente até provoque reflexões sobre o modelo de negócios da empresa. Na última reunião que tive com um dos representantes desse produto, dei uma opinião muito objetiva e direta:

“Ofereça uma cota gratuita de utilização de infra para os Ministérios!”

A empresa precisa entender que o produto novo precisa permear o mercado, a impressão das pessoas no serviço público sobre os serviços do SERPRO não é positiva, e esse cenário precisa mudar radicalmente para qualquer estratégia emplacar. Nesse caso, por que não seguir o exemplo da AWS? Um ano de pacote básico gratuito para todos os Ministérios experimentarem os novos serviços do SERPRO, se gostarem eles expandem e passam a contratar, se não gostarem abandonam o serviço e deixam um feedback para futuras melhorias.

 

Azure no Ministério do Planejamento

 

Nesse mesmo período, a DTI do Ministério do Planejamento, Orçamento e Gestão, realizou algumas provas de conceito com o time da Microsoft Brasília, esse procedimentos não pude acompanhar de perto infelizmente, mas recebi com muita atenção os relatos da equipe da DTI/MPOG nas reuniões de coordenação do SISP. Chegamos a ter algumas interações com a equipe de compras conjuntas da STI/MPOG para discutir planilhas de custos de infraestrutura de nuvem, mas isso foi parte de um processo paralelo.

Enquanto a Diretoria de Tecnologia da Informação estudava provas de conceito com os serviços do Azure, a Secretaria de Tecnologia da Informação estudava formas de contratar serviços do mesmo tipo no mercado, por meio de compras conjuntas, onde diversos órgãos participam da mesma aquisição, gerando uma economia de escala para quem compra, e um baita negócio monopolista extremamente lucrativo para quem vende.

Nos estudos da DTI, chegaram e colocar o SEI, Sistema Eletrônico de Informações para rodar dentro da infraestrutura do Azure, o que é uma peça interessante de estudos, se levar em conta que esse sistema é o coração da burocracia por suportar todo o processo administrativo eletrônico, onde os atos administrativos são encaminhados de uma área para outra, o tempo todo o dia inteiro. Dentro dos órgãos públicos que implementaram, o SEI se tornou o principal sistema, com um grande numero de acessos diários.

Não tenho os números finais infelizmente, mas os relatos dizem que a infra do Azure suportou bem a demanda do SEI. Mas aí cabem outras questões que invariavelmente não eram levantadas nesses espaços de debate.

Perceba que, ao mesmo tempo que se faz necessário acelerar a adesão do governo a tecnologias mais avançadas como a computação em nuvem, e ainda que se faz necessário sim discutir os gastos de TI de governo no mercado monopolizado de datacenters e de compra de ativos de hardware, também se faz necessário nesse processo pensar os limites dessas questões, não apenas dentro do paradigma de custo/benefício, mas também sobre o paradigma de dependência/autonomia.

A prova de conceito com o SEI rodando no Azure demonstrou a viabilidade técnica e também comercial da sustentação desse sistema na nuvem, e muitos órgão podem ter adesões facilitadas por esse processo. Porém os gestores públicos de TI precisam colocar na balança também os riscos de ter seus sistemas rodando em datacenters de empresas privadas, onde por mais que seus dados estejam protegidos contratualmente, tecnicamente eles ficam completamente expostos.

Não há o que se suspeitar de empresas que oferecem infra como serviço, mas é preciso relevar que alguns dados de governo são sigilosos, e esse sigilo serve muitas vezes para proteger a vida e a integridade moral de cidadãos brasileiros, para garantir o cumprimento de Leis, e principalmente para questões de segurança nacional. Entregar os dados de governo nas mãos de uma empresa privada é um risco muito grande, pois gera uma dependência tecnológica do órgão com a instituição privada. E essa dependência tem um custo que não é monetário, mas sim histórico.

Encontrei uma coletânea de artigos interessantes sobre o tema, tratado na obra “Amazônia e Atlântico Sul: desafios e perspectivas para a defesa no Brasil” onde o Professor e pesquisador Jorge Henrique Cabral Fernandes escreve uma série de artigos junto com outros pesquisadores sobre o tema. Destaco o professor Jorge não apenas pela obra que é de extremo interesse para o tema, mas também por ser o professor gestor do Centro de Processamento de Dados da Universidade de Brasília (CPD/UnB) e membro da comissão do SISP representante das universidades públicas federais. Cito um trecho do artigo “A Perniciosa Armadilha Cibernética e uma Proposta de Mobilização Nacional”, pg. 559:

O risco militar é especialmente o da mente “consumidora”, que adquire inspirada pela beleza do design, pelo poder simbólico ligado à realização da compra, além das promessas falaciosas de que a vida cará mais simples e fácil devido à automação do controle.

 

A CLOUD DO MINISTÉRIO DA CULTURA

 

Quando comecei na gestão da CGTI do MinC em Abril de 2015, comecei com a minha equipe um projeto de revitalização do Datacenter com base em outras premissas:

  1. Automação como regra, artesanato é exceção;
  2. Infraestrutura não precisa ser solicitada, precisa ter auto serviço;
  3. Nenhum padrão tecnológico serve para tudo, cada solução tem uma arquitetura própria;
  4. DevOps não é um método ou uma ferramenta, é um exercício diário.

Nesse projeto tivemos o apoio da equipe da Hepta e da Instruct, está última uma empresa especializada em automação de infraestrutura, que trouxe uma série de conhecimentos, boas práticas e princípios importantes, por meio dos quais conseguimos criar uma nova cultura de gestão de Datacenter.

Primeiro iniciamos com a implementação do SEI, em uma nova arquitetura modular, orquestrada pelo Puppet, de forma que toda a instalação do aplicativo poderia ser desconstruída e reconstruída em menos de 10 minutos. Além da automação da instalação, o Puppet garantia a conformidade das minhas configurações, fazendo checagens periódicas em todas as máquinas e corrigindo desvios.

Quando terminamos a instalação do SEI no MinC, tínhamos uma das mais robustas e estáveis instalações da esplanada, e compartilhamos os módulos Puppet com outros órgãos, por meio dos repositórios no BitBucket.

Tínhamos ali uma primeira experiência de sucesso que nos permitia avançar. Foi quando a equipe da Hepta trouxe a arquitetura de sustentação baseada no hypervisor oVirt, uma solução extremamente robusta e muito avançada, baseada em software livre, com uma série de funcionalidades que permitiam o escalonamento de soluções e a oferta de auto serviço. Mas não para por aí.

Junto com o oVirt, implementamos os Foreman, um orquestrador livre que utiliza Puppet e Docker para automatizar diversas tarefas, e mantém painéis de indicadores da situação do seu datacenter. Com o Foreman instalado e conectado no oVirt, os scripts de instalação Puppet se tornaram um padrão interno e o repositório deles seria o nosso próprio Git. Logo conseguimos integrar com o monitoramento do Zabbix, e as soluções passaram a se relacionar de forma harmônica e inteligente, tudo por meio de APIs, sem nenhum “remendo de baixo do capô”.

Tínhamos assim criado de uma forma muito simples e sem nenhum custo de licenciamento, a MinC Cloud, uma nuvem privada rodando dentro do Datacenter do MinC, com automação, monitoramento, escalonamento e auto serviço disponível para ser consumida.

Obviamente foi necessário um grande esforço de migração do parque, para trazer as máquinas que rodavam na arquitetura antiga para a nova arquitetura, esses esforço acredito que continue e continuará durante algum tempo, devido ao grande número de soluções legadas do Ministério. Mas a arquitetura da solução estava montada e passamos a apresentar isso para a esplanada.

Reparem que, diferente das outras iniciativas, nossa preocupação não estava concentrada na ótica da aquisição, ou do produto a ser ofertado. Não, muito mais do que isso, no MinC nós garantimos a modernização da cultura de gestão do Datacenter, de forma a tornar o serviço muito mais ágil, e garantir maior estabilidade das soluções disponibilizadas. Isso é uma coisa que não se compra, é preciso construir.

Essa capacidade de gestão de infraestrutura ágil nos abriu uma série de possibilidades interessantes. Como tínhamos capacidade ociosa identificada no Datacanter e uma grande demanda por informatização das políticas culturais, criamos um projeto piloto com secretarias estaduais e municipais de cultura, para oferecer auto serviço de infraestrutura e também alguns softwares como serviço para serem utilizados por entes federados na realização de políticas públicas de interesse do Ministério.

Como ninguém pensou nisso antes?

Com o Datacenter automatizado, nossa equipe de sustentação pode se concentrar em tarefas mais administrativas e menos operacionais, o que abriu uma porta imensa para processos criativos. Passamos a experimentar novas tecnologias e encontrar viabilidade em ideias que antes eram impossíveis de cogitar.

Quando oferecemos a nova arquitetura do Sistema Nacional de Informações e Indicadores Culturais – SNIIC – tínhamos preparado um pacote de soluções livres que, a princípio seriam fáceis de serem implementadas, porém a realidade da TI na administração pública dos entes federados se mostrou ainda mais calamitosa que a do governo federal. Era difícil para nós imaginar que as empresas públicas de TI não conseguiriam instalar os sistemas livres baseados em PHP e Mysql, ou PHP e Postgres, por menos de 5 milhões de reais ao ano, com um cronograma de meses de implementação.

Nós fazíamos de graça, em poucos minutos. Porque não oferecer a solução pronta e instalada para eles?

Imaginem se isso vira uma política pública de fato, para todas as outras pastas, como educação, saúde, defesa, justiça, fazenda… As possibilidades são incalculáveis.

 

PRECISAMOS CRIAR UMA NUVEM DE GOVERNO!

 

Um fato elementar que aconteceu durante o período, e ainda não foi amplamente debatido e absorvido pelos dirigentes do governo federal, foi a transformação da Secretaria de Logística e Tecnologia da Informação em Secretaria de Tecnologia da Informação. A movimentação da Logística (setor de compras governamentais) para a secretaria de gestão traz a necessidade de debater amplamente o que significa pensar a Tecnologia do Governo para além dos processos de compra! Durante muitos anos, a tecnologia foi entendida na administração pública como um ativo de commodity, que você compra do mercado e entrega pro usuário, seja ele cidadão ou servidor público. Nesse paradigma, questões como autonomia, desenvolvimento científico e tecnológico, e principalmente inovação, se tornam processos completamente distorcidos. Não se refletia sobre a culturalização tecnológica, sobre os paradigmas de relação entre o Estado e o Cidadão pelo meio digital, não se aventava iniciar laboratórios de desenvolvimento científico dentro da burocracia, porque para a maioria dos gestores, só seria preciso comprar isso e pronto. Posso estar simplificando de forma injusta, mas é necessário entender o rompimento do paradigma.Quando é criada a Secretaria de Tecnologia da Informação no final de 2015, o Ministério do Planejamento manda o recado de que está se preparando para pensar Tecnologia de uma nova maneira. E isso foi um passo muito acertado.Agora é necessário avançar nessa direção. É preciso estimular mais compartilhamento de soluções, mais troca de experiências, mais laboratórios de experimentação, não apenas provas de conceitos de fornecedores, mas estimular a criatividade e a ousadia no setor público para avançar em soluções inovadoras e disruptivas.É preciso pensar a demanda de infraestrutura tecnológica com os ativos que o governo federal já possui, como podemos compartilhar recursos tecnológicos dentro dos datacenters de governo, sem gerar riscos de segurança, aliás ao contrário, fortalecendo ainda mais a arquitetura tecnológica e criando laços federativos para a implantação conjunta de políticas públicas com suporte tecnológico de ponta.Existem diversas tecnologias livres que podem dar suporte para esse tipo de solução, e já existem empresas nacionais maduras o suficiente para pensar formas de suporte para essas soluções em escala nacional.Existe mesmo, eu vi!As vezes na APF, falar que existem formas de suporte para software livre é como dizer que existe vida em outros planetas. O modelo de gestão tecnológica é tão viciado em aquisições, que simplesmente ignora a possibilidade de utilização de arquiteturas livres.Existe uma experiência interessante nos Estados Unidos, chamada Cloud.gov, que acho que pode servir de exemplo, enquanto iniciativa, para os gestores de TI do governo brasileiro. Lá eles já entenderam que precisam de uma nuvem própria de governo, com recursos compartilhados e modelos de gestão próprios, para garantir a segurança dos seus dados e dar soluções mais adequadas aos seus dispositivos normativos.Vale a pena estudar, e como tudo o que é bom, vale a pena copiar.

Software não é um produto Fabril

Nos últimos anos tivemos muitos encontros e reuniões entre os gestores de TI de governo para tratar o tema do desenvolvimento de software na esplanada.

O tema tem sido alvo de inúmeras discussões nos órgãos de controle também, a princípio, parece ser consenso entre as unidades de TI do poder executivo que o atual modelo baseado em terceirização de fábricas de software, com sua produtividade medida por contagem de pontos de função, não consegue atender com eficiência às necessidades de negócio do Estado Brasileiro.

Muito dinheiro público gasto e um grande esforço fiscalizatório é empenhado na gestão de contratos de fábricas de softwares que, no final, não entregam resultados satisfatórios, desperdiçando rios de recursos públicos em contratos milionários, comprometendo servidores públicos despreparados e impedindo o funcionamento e o crescimento de políticas públicas importantes para a nação.

Para encontrar uma solução para o tema, vou me concentrar em descrever o que é e como é pensada a gestão de uma fábrica de software, e falar sobre algumas experiências inovadoras que apresentam resultados muito mais interessantes.

O QUE É UMA FÁBRICA DE SOFTWARE?

As licitações de contratação de fábrica de software buscam em regra atender às necessidades de desenvolvimento e sustentação de software em um órgão específico. O processo de produção de software precisa se encaixar nos moldes de contratação da Lei 8.666/1993, uma lei defasada que não pensa especificamente a produção de software como um processo de aquisição específico.

As empresas que se tornam aptas a lançar propostas para um edital de fábrica de software, preparam um modelo de produção que possa retornar lucros a partir dos mecanismos dessa mesma Lei, e em obediência às demais normas infra legais em vigor. Resumindo, elas precisam construir uma forma extremamente barata de auferir lucros com base no trabalho demandado à programadores de software.

Existe porém uma importante contradição nesse momento: Todas essas empresas definem seu modelo produtivo baseados em postos de trabalho, onde ela contrata um profissional de TI para exercer uma determinada função e o remunera mensalmente, com todos os direitos previstos na CLT, de forma regular.

Mas o órgão que a contrata, contrata a entrega de software, ou seja, ele não paga de acordo com a quantidade de profissionais disponíveis, mas sim pela quantidade de software que o órgão recebe. Dessa forma, entende-se que se a empresa contratada não entregar uma quantidade “X” de software para o órgão, e não receber por ele, ela vai ficar no prejuízo. Obviamente não é assim que funciona. Uma empresa terceirizada não pode aceitar prejuízos em um contrato, ou ela ganha ou ela rompe o contrato.

Para metrificar o software entregue pode-se utilizar basicamente das seguintes métricas:

  1. Banco de horas
  2. Unidade de Serviços Técnicos
  3. Ponto de Função

AS MÉTRICAS DE SOFTWARE

Esse talvez seja o exercício central, o mais inglório de todos, como definir o valor do software entregue?

A métrica de banco de horas leva em consideração o tempo de trabalho, relacionando os custos mensais dos profissionais envolvidos no processo e calculando assim o custo do serviço prestado, em horas de trabalho. Porém, essa métrica permite uma falha muito perversa, que é a tentativa de ganhar mais, produzindo menos. Como a principal variável é o tempo, quanto mais tempo levar um profissional para produzir um software, mais remunerado ele será. E isso é muito ruim para a administração.

A UST – Unidade de Serviço Técnico – por sua vez utiliza um cálculo padrão de horas produtivas vezes um certo fator de complexidade, para chegar a uma quantidade de USTs a serem remuneradas pelo órgão. Em regra, esse tipo de métrica vem com níveis de serviço de tempo e qualidade atrelados a algum tipo de glosa automática. Mas aqui ainda a variável central é o tempo, então, vale a mesma reflexão sobre produtividade.

O Ponto de Função por sua vez tenta medir a quantidade de funções em tela, e gera diversas interpretações, regras de contagem e modelos de aferição, em um conjunto de normativas extremamente sofisticados, que tem por objetivo medir precisamente o esforço desempenhado para a produção do software, em cima das suas funcionalidades. Essa métrica foi durante muito tempo tomada como a solução para os problemas, até que se percebeu que a qualidade de um software, ou até a sua capacidade de atendimento das demandas de negócio não estão diretamente ligadas ao seu tamanho. Como a variável central aqui não é tempo, e sim quantidade de software, a perversidade explorada nessa métrica se trata basicamente de produzir muito software desnecessário, geralmente utilizando argumentos técnicos para convencer o usuário de que ele precisa dar 5 cliques para chegar onde ele precisa e não tem como chegar com um clique só.

A métrica do ponto de função agride diretamente as questões de usabilidade. No final, nem tudo pode ser medido por funcionalidade, de forma que em alguns modelos, a contagem de ponto de função aceita dentro da sua razão lógica o modelo de horas trabalhadas, convertendo essas variáveis por meio de formulas complexas que no final, acabam deixando uma margem muito grande para interpretações, deixando a métrica pouco precisa de fato.

PARA CONTRATAR É PRECISO DEFINIR “O QUE É SOFTWARE”

O processo de contratação depende de uma definição do que se quer contratar, se eu especifico que quero contratar tempo de desenvolvimento ou volume de desenvolvimento, eu vou receber no final o que de fato contratei, não necessariamente com qualidade, mas sim com tempo ou com volume, em quantidade necessária para cobrir os custos mensais da fábrica de software e arcar com a sua sede de lucro.

Porém, antes de definir como metrificar precisamos refletir para além da métrica, precisamos conceber o que é “software” para definir como queremos contrata-lo. Porque se parto do princípio que software é tudo igual, todo mundo tem capacidade de produzir igualmente, independente da sua experiência ou de sua capacidade de apresentar produtos interessantes, então eu estou dizendo automaticamente que software é uma coisa que se produz em larga escala, com procedimentos padrões que podem ser repetidos por qualquer pessoa em qualquer empresa, de forma satisfatória para a administração, bastando medir esse software de alguma forma para viabilizar seu pagamento.

Esse é o pensamento fabril da industria do software.

Mas quem conhece software sabe que não se trata de um produto fabril.

Softwares são mais parecidos com ideias, eles são caracterizados na verdade por um conjunto de conhecimentos que se agregam e se transformam mutuamente para encontrar maneiras rápidas para solucionar problemas da vida real, do processo produtivo e da relação em sociedade. Se trata de um produto que se consagra não pelo tamanho ou pelo tempo que leva para ser desenvolvido, mas pela quantidade de usuários que se beneficiam dele, pela capacidade de solucionar problemas complexos de forma simples.

Imaginem se tivéssemos que pagar o MS Office pela quantidade de funções que ele tem? Ou se estimássemos o preço do google baseando-se na contagem de pontos de função em tela? Não faria o menor sentido. Assim como não faz sentido continuar concebendo software como um serviço continuado, como um produto fabril onde a criatividade e a inovação são irrelevantes.

SOFTWARE É INOVAÇÃO

Quanto mais criativo e menos exaustivo for, mais chances tem esse software de atender às necessidades dos usuários, e não basta ser concebido de maneira correta, ele precisa estar preparado para aceitar mudanças, inclusive mudanças de funcionalidade que podem ser identificadas como necessárias a partir da experiência de uso do software.

Na prática, a maioria dos projetos de software dentro do Estado se tratam de melhorias de processos, formas de automatizar processos de gestão interna ou serviços públicos, por meio de ferramentas digitais.

Melhorar um processo não se trata necessariamente de ter habilidades em desenvolvimento de software, é preciso entender os objetivos de negócio e pensar como esses objetivos podem ser atingidos ao menor custo de processamento possível. Inclusive, cabe a reflexão aqui sobre o custo do processo automatizado, e se a economia com a automatização gerou algum ganho material para o órgão, mas vamos deixar essa reflexão para outro artigo.

É preciso entender que o software nada mais é do que a materialização de uma ideia inovadora, que busca melhorar um processo interno, economizar recursos e facilitar o trabalho das pessoas.

Desse ponto de vista, o software na verdade se torna um produto de inovação, que não pode ser metrificado de forma simples, não vai ser produzido de forma identica por qualquer um, e que não vai ser produzido por um processo repetitivo, não sai de uma linha de produção.

Se é um produto de inovação, se é artesanal, então talvez faça mais sentido discutir esse assunto primeiro com a academia, com universidades e centros de pesquisas.

OS LABORATÓRIOS DE SOFTWARE LIVRE DO MINC

Nós criamos um modelo de funcionamento experimental, com o apoio de 3 Universidades Públicas Federais, elaboramos os projetos dos laboratórios de software livre, por meio de um investimento direto do Ministério da Cultura nas Universidades Federais, uma relação da Administração Pública Federal com outro ente da Administração Pública Federal, para a construção de laboratórios de desenvolvimento de software, com doutores, mestres, graduandos e também com a participação de profissionais de mercado, com o objetivo de estudar as demandas de software do MinC e propor soluções inovadoras, além de realizar pesquisas sobre as tecnologias envolvidas no universo da Cultura para propor estudos e melhorias.

O objetivo desses projetos é consolidar laboratórios capazes de desenvolver soluções tecnológicas para o governo federal, e disponibilizar todas elas como software livre, possibilitando a livre utilização, distribuição e alteração dos códigos fontes dessas soluções.

Além de prover soluções abertas para o poder executivo, esses laboratórios também tem a responsabilidade de estudar os softwares culturais, as ferramentas que são mais utilizadas pelo mercado da cultura e, com base nesses estudos, propor investimentos em melhorias e novas funcionalidades.

Sem muito mistério, os laboratórios de software livre são pequenos motores de propulsão do desenvolvimento científico e tecnológico, que se utilizam da capacidade de compartilhamento e colaboração para acelerar o processo de informatização das políticas públicas e dos processos de área meio do Estado Brasileiro.

Como eles trabalham em sua maioria com pesquisadores e cientistas renomados, e talvez também como eles não se sujeitam a lógica da ganância pelo lucro, os projetos entregues se sustentam em outras tecnologias livres e assim conseguem mais rapidez e melhores resultados. Além é claro do suporte das comunidades ao seu redor.

Os ativos de software desenvolvidos pelos laboratórios podem ser encontrados em www.github.com/culturagovbr.

REMUNERANDO POR MICRO DEMANDAS

Outro modelo interessante em discussão é focado no fracionamento das funcionalidades de um software em diversas demandas, cada uma estimada em um valor, que pode ir a um tipo de micro leilão onde os participantes lançam o menor preço para desenvolver a funcionalidade e se comprometem a atender um grupo de critérios de qualidade para a entrega do software.

Existem duas experiências desse modelo que chamam a atenção de todos, a primeira é o www.bountysource.com, onde empresas e comunidades lançam suas necessidades de funcionalidades em projetos de softwares, todos hospedados no Github.com, e por meio da aplicação os programadores se cadastram e concorrem a trabalhos nesses projetos, onde são remunerados pelas funcionalidades entregues. Ali existe também a possibilidade de um programador se disponibilizar para realizar uma melhoria por uma certa quantia de dinheiro, então a lógica de trabalho funciona para os dois lados, o cliente que quiser uma melhoria pode demandar, e o programador que achar que pode implementar uma melhoria interessante pode chamar a atenção da comunidade.

O próprio BountySource é um software livre, que pode ser instalado e alterado de acordo com a demanda da sua organização.

Na minha opinião, o Portal do Software Público deveria ser um BountySource de governo, que remunerasse diretamente o programador pelo trabalho realizado.

Inspirados na experiência do BountySource, a 18F, agencia digital de inovação do governo Obama, lançou uma experiência no github, realizando um micro leilão direto nas issues do github, passando a demanda de desenvolvimento e os critérios de aceitação. O participante que ganhou, se ofereceu para fazer a funcionalidade por US$ 1,00, e a entrega passou nos critérios de aceitação.

Essa movimentação do governo Obama demonstra uma reflexão interessante do Estado Norte Americano no sentido de buscar formas de inovação para o desenvolvimento de softwares para a administração pública. Temos muitas possibilidades no Brasil de adaptar essa ferramenta à realidade da legislação brasileira, ou até ainda melhor, adaptar a própria legislação brasileira de acordo com essa experiência e possibilitar que desenvolvedores autônomos e comunidades de desenvolvimento de software possam se envolver em projetos do governo de forma direta e segura.

Todas essas experiencias precisam ser levadas ao governo brasileiro de forma mais contundente, apesar de conhece-las, a Secretaria de Tecnologia da Informação do Ministério do Planejamento continua apostando no modelo falido das fabricas de software com ponto de função, com uma tentativa tímida de girar o modelo de aquisição de licenças de software para o modelo de remuneração por transações em SaaS, que embora seja interessante, ainda não resolve a questão central: Como o governo vai desenvolver software livre e de qualidade para atender as demandas da sociedade moderna?

 

Gestão de Projetos de TI Simplificada

Quando alguém se pronuncia para falar de gestão de projetos acho que a primeira reação da maioria das pessoas é sentir um certo anseio por um longo e vasto monólogo sobre procedimentos burocráticos.

Criar um termo de abertura, um documento de visão, uma estrutura analítica, depois um cronograma, um plano de riscos, quem sabe uma solicitação de mudanças, e mais uma série de instrumentos estáticos que, no momento seguinte a sua criação, começam a se tornar obsoletos.

Neste artigo não posso deixar de trazer um tom de desabafo, precisamos fazer uma reflexão sobre essa ciência as vezes, e por consequência uma reflexão sobre a prática do mercado.

Não é incomum encontrar gerentes de projetos soltando bravatas do tipo “Escrevi todo o projeto e ninguém leu” (um documento de 200 páginas geralmente), ou então “Preparei todo o cronograma, se tivesse tido patrocínio teria dado certo”, ou ainda “o projeto estava ótimo, o cliente é que não conseguiu enxergar o ganho”.

É comum encontrar colegas no mercado que entendem a gestão de projetos como uma ciência exata, precisa, que planeja, executa e monitora, e tem por objetivo produzir controles minuciosos sobre os custos, riscos, equipe, recursos, cronograma, interessados e etc… Mas onde está a entrega de valor mesmo?

É importante lembrarmos que a base dessa ciência são as pessoas, seres vivos conscientes de sua existência que se relacionam em sociedade, se comunicam e sonham.

É importante entender que o sucesso de uma boa relação entre as pessoas, não está necessariamente na capacidade dos controles, mas na comunicação entre elas.

No Ministério da Cultura tive a oportunidade de reproduzir um conhecimento interessante sobre o tema, a implementação de um escritório de projetos de TI baseado no PRINCE2.

O PRINCE2 (Projetos em Ambientes Controlados) tem uma vasta literatura na internet, trata-se de uma metodologia de gestão (não apenas um conjunto de conhecimentos) que busca orientar a gestão de projetos com as seguintes abordagens:

  • foco na garantia da justificativa de negócio, ou seja, busca garantir que o projeto tenha uma razão de existir na organização, com vistas a agregar valor ao seu negócio;
  • Planejamento baseado em entregas de produtos;
  • Ênfase na divisão do projeto em fases ou cenários controláveis, com entregas claras para os clientes;
  • Flexibilidade para ser adaptada para a necessidade do projeto, e não ao contrário.

Esses fatores nos levaram a preparar uma metodologia de gestão de projetos de TI (MGP-TI) capaz de dialogar com as necessidades da organização de forma comunicativa, com processos de tomada de decisão organizados, e com pontos de controle que permitiam o acompanhamento e o alinhamento dos objetivos de negócio de cada projeto.

mgpti

Essa metodologia foi introduzida pela CGTI do Ministério das Comunicações (2012 – 2015), na gestão de Luiz Felipe Monteiro da qual tive o prazer de participar, e foi implantada pela gestão da CGTI do Ministério da Cultura (2015), na minha gestão, com algumas pequenas adaptações.

Nessa metodologia nos concentramos em garantir em um processo de gestão comunicativo, transparente, com atribuições claras e responsabilidades definidas, de forma que o projeto possa ser monitorado pela área de TI e pela área de negócio solicitante, podendo ser realinhado sempre que necessário para garantir os objetivos da área.

Algumas sacadas importantes:

  1. O projeto não tem um gerente, autônomo e capaz de tomar decisões sozinho, ele tem um líder, que comunica os objetivos, que busca garantir o cumprimento das metas e traz inspiração ao projeto;
  2. As decisões gerenciais são colegiadas, o comitê gestor do projeto é o organismo dirigente capaz de tomar decisões sobre andamento, mudança de escopo, alocação de recursos e desvio de escopo;
  3. Mais foco na comunicação do que no formalismo, muito melhor que um documento de 200 páginas assinado pelo diretor, passamos a um evento de decisão, uma apresentação de 30 minutos;
  4. Flexibilidade gerencial ajuda a traduzir os diversos processos técnicos de TI de forma unificada, garantindo assim a gestão centralizada do portfólio de projetos de TI.

No repositório https://github.com/culturagovbr/mgp_ti é possível encontrar todos os modelos de artefatos e a norma operacional que estabelece a MGP-TI no âmbito do órgão. Muitas melhorias podem ser feitas a essa norma, utilize, distribua e contribua livremente.

Hoje fazemos algumas reflexões sobre a metodologia, pensamos a introdução de alguns princípios ágeis para acelerar o processo de comunicação e de tomada de decisão.

Temos experimentado um pouco de Lean e project model canvas, que trazem mais algumas provocações importantes.

Mas o mais empolgante é perceber o fenômeno que ocorre na organização, quando as áreas de negócio passam a enxergar e entender a área de TI com clareza. A desconfiança se transforma em empatia, a disputa se transforma em cooperação, as ameaças se transformam em criticas construtivas.

É importante ter clareza de que um escritório de projetos saudável, transforma os processos organizacionais também, não apenas dentro da TI.

GitHub.com, GitLab ou Portal do Software Público?

Quando iniciamos o debate sobre libertação do software produzido pelos órgãos públicos, a primeira questão que veio a tona foi:

“Onde vamos hospedar nossos repositórios?”.

Quando falamos de software produzido pela administração pública, é importante lembrar que nós falamos de software não licenciado.

Por força dos dispositivos legais que regem a questão da propriedade intelectual, todo software desenvolvido por um órgão público se torna propriedade privada do órgão, e não da União.

Se outra agência pública quiser utilizar o software desenvolvido, terá que pedir a cessão do direito de uso para o órgão que o desenvolveu, podendo o órgão negar esse direito, ou até mesmo cobrar por ele.

Se isto lhe parece estranho, é porque realmente é. Afinal, todo software desenvolvido por órgãos da administração pública são desenvolvidos com recursos públicos, originários dos impostos dos cidadãos brasileiros. Além disso, em regra os órgãos públicos não tem por objetivo lucrar com a oferta de software, a não ser que seja uma empresa pública de TI, o que ainda assim pode ser criticado.

Penso que faria sentido se todo ativo de software desenvolvido com dinheiro público fosse livre. Licenciado de forma a garantir a liberdade de uso, de reprodução e de alteração por qualquer cidadão do mundo. Imagine que riquíssima contribuição a administração pública poderia dar ao mundo se ela compartilhasse seus softwares de gestão por exemplo.

Quando assumi a CGTI do Ministério da Cultura, tomamos a decisão de abrir os códigos-fontes:

Não importa se ele está pronto!

Não importa se está bem feito!

Não gera nenhuma falha de segurança!

Todos os softwares desenvolvidos com dinheiro público devem ser livres!

Muitos gestores de TI buscam diversos argumentos para não tomar essa decisão, a maioria possivelmente não consegue vislumbrar a possibilidade de compartilhar projetos, de reaproveitar sistemas que já existem, de trabalhar em conjunto para resolver problemas comuns. A verdade é que a maioria de nós está sofrendo o “mito da caverna”, o medo de atravessar e de caminhar ao desconhecido é tão grande, que leva os órgãos públicos a padecerem da atual situação.

Para nossa gestão essa questão era simples, se o software foi desenvolvido com recurso público, então ele não pertence ao órgão, pertence aos cidadãos, e deve ser licenciado como software livre.

O Portal do Software Público Brasileiro é um dos projetos de sucesso da Secretaria de Tecnologia da Informação que vem para reverter esse cenário.

Um catálogo de softwares licenciados em GPLv2, licença de software livre da GNU, com uma série de procedimentos para aceitar a entrada de projetos de software, normalizados na IN 01 do Ministério do Planejamento. Embora não seja ágil e simples como um serviço de hospedagem de repositórios, esse espaço vem sendo reformulado em uma perspectiva interessante. Hoje o SPB não se propõem mais a ser apenas um catálogo de software, mas também um repositório GIT de código compartilhado, combinado com diversas ferramentas de gestão de comunidades.

O SPB era uma opção de lugar para hospedar nossos repositórios.

Outra opção era usar o Gitlab.com, um repositório livre de código-fonte aberto que permite tanto a hospedagem on-line quanto o download para instalação de uma instância no seu próprio ambiente. Uma opção bem atrativa pra quem quer ter uma ferramenta poderosa de versionamento e ainda assim manter o controle do código em seu ambiente interno!

Autonomia, facilidade, usabilidade e sustentação internacional por uma grande empresa… Mas e as comunidades? Nenhuma das opções anteriores detém grandes comunidades de desenvolvedores autônomos, buscando projetos para contribuir.

Hoje o maior repositório de projetos de software do mundo é o github.com. Com mais de 30 milhões de repositórios hospedados, o github hoje conta com a maior rede de programadores, hospeda os importantes projetos internacionais de software livre e mantém um conjunto de ferramentas interessantes de comunicação e produtividade. Mas não disponibiliza ele mesmo como software livre, não dispõem de instalação no seu ambiente interno.

No Github, se você quiser criar um repositório de software livre público, para todos verem, você pode fazer isso de graça. Porém, se quiser ter um repositório privado, você precisa pagar um plano mensal. De uma forma ou de outra, você não vai poder ter uma instância do Github rodando no seu ambiente interno. E talvez você não precise.

Depois de meses nessa discussão, chegamos a um veredicto: Não é importante manter tudo hospedado em um lugar só, o importante é disponibilizar a tecnologia certa para o meu projeto, dependendo das características dele.

Se tenho um projeto que só serve para a administração pública, faz mais sentido hospedar no SPB, pois ali está a atenção dos órgãos públicos, para lá apontam os normativos, nele se baseiam os órgãos de controle. As áreas de TI da administração pública toda conhecem o SPB, embora ainda não o utilizem em sua completa capacidade.

Se tenho um projeto de interesse da sociedade civil, faz mais sentido compartilha-lo onde tenho o maior número de desenvolvedores e comunidades de software disponíveis, no Github.com.

E se tenho um projeto muito estratégico, de missão crítica, que não pode ser exposto a qualquer momento e que precisa estar dentro do meu ambiente controlado, faço uma instalação própria do GitLab e hospedo nela, podendo compartilhar versões específicas do meu código-fonte, mas não todas as branchs de desenvolvimento.

Agora a questão mais importante de todas, é que na verdade, independente de onde esteja, se seu código está em um repositório Git, ele pode ser Clonado a qualquer momento. Veja, clonar um repositório é diferente de baixar uma versão do repositório. A função clone do git permite que o repositório exista inteiro em outro ambiente. E se necessário, é possível espelhar um repositório no outro. Sim, dois repositórios idênticos podem coexistir em servidores diferentes de forma sincronizada!

Git é mais que um repositório, é um estilo de vida. Precisamos pensar mais em compartilhamento, mais em libertação do código-fonte dos softwares desenvolvidos com dinheiro público. A administração pública precisa exercitar seus princípios e garantir a troca de conhecimentos consigo mesma. Isso é o mais importante.

Conheça os repositórios do Ministério da Cultura e contribua:

  • https://github.com/culturagovbr
  • http://git.cultura.gov.br/
  • https://softwarepublico.gov.br/gitlab/simec/simec/

De A a Zimbra! Como migrar do Exchange

forma que isso possa diminuir traumas e dores causadas na Muitas pessoas me perguntaram por que tomamos a decisão de migrar o servidor de e-mail para a solução corporativa da Zimbra, ao invés de permanecer no conforto do Exchange. Algumas delas me pediram insistentemente que escreve-se um artigo detalhando o processo as decisões que tomamos.

(mais…)