4.1 Portal de Serviços

O portal de serviços do governo federal, publicado no endereço servicos.gov.br, pretende agregar, em um só lugar, todos os serviços oferecidos por todos os órgãos da Administração Pública Federal. Foi inspirado no modelo do GDS, do governo inglês e tem o intuito de facilitar a vida do cidadão que procura algum serviço e não precisa saber, necessariamente, qual órgão é responsável por aquele serviço. Todo site de governo possui uma barra de links no topo, a chamada “barra Brasil”, com um link chamado “Serviços” que o leva para este portal.

Além de se inspirarem no modelo do site do governo britânico, que também apresenta tudo de maneira simples e transparente em um único portal para o cidadão, o MPOG também optou por experimentar o modelo de desenvolvimento do GDS e tentou, em grande medida, adotar as melhores práticas sugeridas por eles.

O primeiro desafio para tanto foi a contratação de uma empresa com experiência em metodologias lean e ágil. Maurício Formiga1, Analista de TI do Departamento de Governo Eletrônico – DGE, da SLTI, e um dos responsáveis pelo desenvolvimento do projeto, conta que os principais requisitos que eles gostariam de ver cumpridos pela empresa contratada eram experiência em trabalho com o governo e com transformação digital. Everson Lopes de Aguiar2, colega de Formiga na DGE, avalia como problemática a contratação de serviços de desenvolvimento de software dentro do escopo da Lei 8.666. “Você pode pegar qualquer coisa. Você pode pegar um ponto de função a R$400 em java, enquanto o mercado está praticando R$800. Mas você vai ter entrega disso?”3, questiona.

No entanto, este projeto foi desenvolvido dentro de algumas condições especiais. Em primeiro lugar, foi contratado com recursos do Banco Interamericano de Desenvolvimento (BID), o que não submetia a contratação as regras da Lei 8.666 e nem da IN04, que só incluiu projetos financiados por organismos internacionais no seu escopo de atuação na última revisão publicada em 2015. Isso deu ao órgão maior flexibilidade na contratação, já que as licitações praticadas pelo BID não seguem os mesmos critérios das licitações da administração direta. Além do critério de preço, foram avaliadas a qualidade da proposta e o currículo da equipe.

A vencedora da concorrência foi a ThoughtWorks (TW), empresa americana que atua em 13 países e é reconhecida mundialmente pela excelência no desenvolvimento de software com metodologias ágeis. Se apresentam com a missão de “melhorar a humanidade através do software e ajudar a gerar a criação de um ecossistema socialmente responsável e economicamente justo4”. Não por coincidência, foi a empresa contratada pelo governo britânico para liderar a implantação do portal Gov.uk e o processo de transformação digital, projeto no qual alocou 75 consultores desde 20125.

Na avaliação de Formiga6, não seria possível contratar a TW se o projeto estivesse subordinado à Lei 8.666. Isto porque a proposta apresentada pela empresa, que era superior às dos concorrentes, era também consideravelmente mais cara. Já em relação aos procedimentos da IN04, Aguiar7 avalia que eles não são necessariamente incompatíveis com o modelo de trabalho ágil, no entanto seria um processo bem mais trabalhoso: “Porque só para você fazer o planejamento da contratação, pode acontecer de a licitação toda demorar quase um ano para ser feita”8, explica. Ele lembra que a primeira versão do guia de serviços, contratado pelo SERPRO, teve seu escopo reduzido uma vez para viabilizar a entrega, que, ainda assim, demorou mais de dois anos para chegar a uma versão beta. Olívia Janequine, gerente de projetos da TW9, explica a questão do preço:

A gente é mais caro que a grande maioria dos fornecedores de software que fornecem pro governo federal. Existe um ecossistema de empresas que fornecem pro governo federal que estão adaptadas ao esquema, tanto das formas de contratação, ponto de função e outras coisas, quanto de adaptar o tipo de entrega que realizam à possibilidade de concorrer por preço dentro das licitações, e a gente não se encaixa nisso.10

Formiga11 descreve a diferença de postura da empresa em relação ao projeto como uma ruptura da reação cliente/fornecedor. A empresa não se coloca apenas como alguém que executará tarefas demandadas pelo órgão, mas trabalha junto, trazendo sua expertise e influenciando a construção do próprio produto. “Em muitos casos nós tínhamos um conhecimento maior sobre o produto e o que precisava ser feito, mas frequentemente eles traziam sugestões e contribuições que eram acatadas. É uma relação completamente diferente da que tínhamos com o antigo fornecedor”12.

Olívia exemplifica:

A gente muitas vezes fez sem perguntar e mostrou o que estava feito. Fez sem perguntar, com o mínimo custo possível, entendendo que em muitas coisas que a gente fez ao longo de todo esse ano, o custo de convencer antes de realizar era maior do que o custo de realizar e eventualmente jogar fora. Então várias vezes a gente realizou coisas dentro do projeto e mostrou e, só depois, teve a conversa. Algumas vezes a gente assustou o pessoal da SLTI com essa abordagem. Mas ao mesmo tempo eles entenderam muito rápido no começo do projeto que era assim que a gente fazia, e que isso estava embutido no que eles tinham gostado da nossa proposta e dos diálogos que tivemos antes deles escolherem a gente.13

Carlos Villela, líder técnico do projeto pela TW, avalia que a primeira entrega de valor que fizeram ao projeto foi ainda durante o processo seletivo, quando avaliaram o edital e apresentaram uma proposta com um modelo de trabalho.

Quando a gente leu o edital a gente falou ‘tá, a gente pode até ganhar isso aqui, mas se a gente ganhar esse edital e tocar esse projeto exatamente nesses termos, a gente não vai entregar nada ou a gente vai entregar muito menos valor do que a gente esperaria’. Então a primeira entrega de valor veio antes da gente ganhar a licitação, que foi ‘essa proposta só funciona se:’ e, então, na nossa proposta a gente descreveu algumas condições pra que a coisa desse certo.14

Basicamente, a chamada de trabalho foi para estudos referenciais, que entregassem protótipos executáveis ao final do processo, no entanto a proposta da TW deixava claro que eles desenvolveriam software desde o início do projeto. Segunda Villela, eles se posicionaram claramente contra a visão de que primeiro se faz um grande estudo para, depois, se implementar o software e “acertar de primeira”. Portanto, propuseram o inverso: “você faz o software primeiro e aí você vai iterando em cima disso, você vai errando e achando o melhor caminho durante o desenvolvimento15.”

Após a seleção da TW, veio a negociação do Termo de Referência. Neste momento Janequine narra que teve um ponto no qual foram inflexíveis. O projeto, que é dividido em oito produtos e vários subprodutos, previa que fossem estabelecidos os critérios de aceitação de cada um no início do contrato. A TW pediu para que os critérios de aceitação de cada um dos produtos fossem definidos no período imediatamente anterior à realização deles. “No início eles queriam que a gente combinasse esses critérios de aceite para todos os produtos nas primeiras três semanas do projeto. A gente falou não16”, comenta Janequine.

Formiga avalia como positiva a flexibilidade de se alterar o escopo, já que o produto podia evoluir a medida que as experiências eram coletadas. No entanto, chama atenção para os limites que tinham no contrato.

Estávamos tranquilos em relação a isso, sabíamos que se tivéssemos que alterar [o escopo], iríamos alterar sem ter maiores problemas e burocracias em relação a isso – que é o grande empecilho que tínhamos em relação ao SERPRO, o antigo fornecedor. Em contrapartida a gente tinha um período definido de tempo para a entrega do projeto. A gente sabe que no modelo ágil, a gente sempre coloca uma hipótese e testa, e depois vai testando e validando outras hipóteses. No mundo ideal, a gente testaria essas hipóteses indefinidamente até chegar a um modelo final. Mas no nosso caso, nós temos um tempo definido para isso. Então a gente não tinha como esgotar todas as hipóteses. A gente ia melhorando, mas chegava no ponto em que dizíamos, a partir daqui a gente vai ter que parar e vocês não vão implementar nada mais pra frente porque haviam muitos outros produtos em paralelo que a gente precisava entregar. Apesar de o escopo ser flexível, o tempo não era flexível para finalização do contrato, do projeto e dos nossos compromissos para a direção.17

Feita esta introdução ao projeto, passaremos agora a analisar mais especificamente algumas etapas chave do desenvolvimento, que nos permitirão fazer uma comparação das práticas adotadas com as melhores práticas propostas neste trabalho.

1Entrevista com integrantes do Ministério do Planejamento Orçamento e Gestão disponível no ANEXO D.

2Ibdem

3Ibdem

4About us. Disponível em <https://www.thoughtworks.com/about-us>. Acessado em 18/10/2015.

5 Como Transformar O Desenvolvimento De Software Para Entregar Valor. Disponível em <http://pt.slideshare.net/ThoughtWorks/tw-renasic-agilidadeentregavalorfev2014&gt;. Acessado em 18/10/2015.

6Entrevista com integrantes do Ministério do Planejamento Orçamento e Gestão disponível no ANEXO D.

7Ibdem.

8Ibdem

9Entrevista com integrantes da ThoughtWorks disponível no ANEXO B.

10Ibdem

11Entrevista com integrantes do Ministério do Planejamento Orçamento e Gestão disponível no ANEXO D.

12Ibdem

13Entrevista com integrantes da ThoughtWorks disponível no ANEXO B.

14Ibdem

15Ibdem

16Ibdem

17Entrevista com integrantes do Ministério do Planejamento Orçamento e Gestão disponível no ANEXO D.

ÍNDICE