ANEXO D – Entrevista com equipe do MPOG (Portal de Serviços)

Entrevista com Everson Lopes De Aguiar e Mauricio Marinho, Ministério do Planejamento, Orçamento e Gestão

Você estava falando agora sobre o modelo de desenvolvimento de software, contratação, que a maior restrição é ele estar agregado ainda à 8666, que foi uma lei pensada pra engenharia e pra compra de produtos, mais do que pra desenvolvimento, bens e serviços. E na IN 04, até onde eu sei, ela fala dos procedimentos, mas chega na hora de contratação, bom aí é a 8666. Ele deixa a parte de, ele vai até a parte de seleção do fornecedor, mas a parte de contratação…

EVERSON: Não, essa lei 8666 ela acaba que compreendendo quase que tudo, todo o ciclo. A questão é que ela é mais, ela é mais ampla, bem mais ampla, e ela também em algumas questões ela acabou ficando desatualizada, entendeu? Por exemplo, a inovação no uso do pregão pra bens e serviços foi uma grande vantagem comparativa e competitiva pro governo. E os próprios órgãos de controle remetem que os órgãos do SISP, os órgãos da administração direta têm que contratar por pregão. Então pregão a maioria é técnica e preço ou menor preço. O menor preço nesse caso aí de TIC você pode pegar qualquer coisa, você pode pegar um ponto de função a R$ 400 em Java, sendo que o mercado está praticando R$ 800. Aí você vai ter entrega disso? Isso eu estou falando desenvolvimento método tradicional, se você pega método ágil isso aí pode ser um pouco mais complexo. Não sei se pro teu estudo adianta alguma coisa, você lembra do Gustavo, Mauricio? Lá do MRE? Ele acabou de fazer um contrato com método ágil baseado… Acho que foi até um pregão, se não me engano, não tenho certeza.

Foi acho que uma licitação.

EVERSON: E ele está tentando aplicar esse modelo no contexto deles. Inicialmente o resultado estava interessante, projeto não concluiu.

É, eu conversei com ele recentemente.

MAURICIO: O que que acontece, que é interessante. Muito se fala que o governo só pode usar ponto de função, que o TCU bate forte em cima disso, só que se você for lá pro TCU eles dizem “não, você não é obrigado a contratar ponto de função, contanto que você consiga justificar bem e as entregas realmente sejam bem feitas e a cobrança ser justa em relação a isso”. O que acontece é que não existe método ainda bem elaborado e bem evoluído que substitua o ponto de função a tal ponto que possa realmente ser efetivo. Então o que que o MRE, no caso, o que que eles fizeram, eles fizeram um esquema assim, que eles contratam o tempo do homem-hora. Só que eles têm um esquema tão forte de acompanhamento, um grupo técnico tão forte, que eles conseguem validar exatamente se o cara está fazendo bem feito o trabalho e a testar a qualidade do trabalho. Então é um caso diferenciado. Então eles fizeram um modelo de contratação não baseado em ponto de função, mas assim, é um esquema… Ele não chama homem-hora, mas é uma unidade lá de técnica, de qualidade técnica que eles conseguem medir e aferir bem exatamente.

EVERSON: No caso de, por exemplo, service desk, já tem alguns órgãos que contrataram, inclusive o Planejamento, eles fizeram uma composição como se fosse um índice, e aquele índice corresponde à forma de pagamento. Eles estão querendo fazer a mesma coisa no caso pra desenvolvimento de código. Inclusive, eu não sei se alguém já fez algum comentário com você, o TCU já tem uma nota técnica específica sobre a avaliação, me parece que de 6 órgãos, ou era de 3 órgãos, que trata justamente da aplicação de métodos ágeis. Então, mas o que eu ia te falar era o seguinte, existe uma súmula do TCU que diz claramente que a gente não é obrigado a contratar por ponto de função, não. O que a gente não pode contratar, que a gente não é obrigado a contratar por homem-hora, o que a gente tem que vincular a isso é a produto e resultado mensurável. Não é que é proibido, o caso dele vai ter que estar bem claro: eu quero isso, aí eu vou gastar x homens, não sei o quê. Meu amigo, resolve, eu vou te pagar tanto, e fazer a devida homologação.

E além dessa questão do pregão ser preço e técnico e tal, você consegue destacar alguma outra questão concreta da 8666 que é um problema pra contratação de software e serviço?

EVERSON: Que chega a ser problema não, é só essa peculiaridade de não ser voltada pra serviço. Mas a própria IN ela contextualizou ela no sentido de aplicar bens tangíveis e intangíveis ao contexto de TI, então essa grande lacuna que existia foi suprida pela IN 04. E pelas evoluções dela.

Deixa eu te perguntar uma coisa que eu tenho dúvida, que eu também não acho muita informação concreta. Um gargalo que eu vejo também, você fala das peculiaridades, mas outro gargalo que eu vejo, comparando com esses serviços lá dos Estados Unidos e do Reino Unido, é infraestrutura. Pega os Estados Unidos, uma grande inovação que os caras estão fazendo é porque agora eles estão usando Amazon pra hospedar, e estão usando um monte de serviço, que pra eles é muito mais tranquilo porque são serviços americanos. E a gente ainda tem uma carência muito grande, todo o setor privado aqui que está inovando e desenvolvendo software ágil estão usando serviços estrangeiros e o governo fica com esse problema. Como é que é realmente a questão da contratação de infraestrutura? O Serpro ele tem prioridade, tem alguma coisa, alguma amarração legal que dá essa prioridade pro Serpro, ou isso não existe, é só uma questão de facilidade de contratação?

EVERSON: O Serpro é quem aproveitou a lei. A IN 04 ela define que serviços estratégicos poderão ser contratados pelos órgãos sem aplicação de todos os procedimentos. Pra isso, o Serpro ou a Dataprev terão que fazer um plano de capacidade. Então resumindo: na minha opinião, a gente, existe uma – como é que se chamava nos anos 80 quando tinha a indústria de informática – um protecionismo…

Reserva de mercado.

EVERSON: Uma reserva de mercado do governo. Só que assim, em tese isso deveria se aplicar só a serviços estratégicos. Só que o órgão define o que é serviço estratégico. Então muitas vezes você ainda fica empurrando algumas coisas pra Serpro e Dataprev que já poderiam estar no mercado.

Por exemplo?

EVERSON: Vou te dar um exemplo que foi antigo, que ele não está tão atual. O Serpro cobra muito caro por hospedagem e o pouco que ele usa nesse sentido de compartilhamento é a questão do ICS, no caso do Planejamento, que é uma espécie de nuvem. Só que é uma nuvem que não tem tantos níveis de serviços garantidos igual você pegaria se fosse contratar com eles próprios ou com o mercado. O exemplo que eu ia te dar era o exemplo do Portal da Transparência. Era um portal que era gerenciado… A infra ficava toda dentro do Serpro. Ou seja, tirou, colocou na Brasil Telecom na época. São dados públicos, não tem sentido isso estar guardado, não tem criticidade nenhuma. Agora se você pega um sistema estruturante do governo, aí você tem certas reservas. Um sistema de CPF, um sistema da Receita, um SIAFI, um SIGEPE. Mas mesmo assim algumas coisas ainda poderiam ser abertas. E o custo deles é muito elevado, é incomparável com o mercado.

Mas esse critério então fica a cargo do, da área finalística aqui, do…

EVERSON: Do gestor.

Do gestor do Ministério que decide “ah, isso é estratégico, isso não, isso tem que ficar no Serpro, isso não, isso pode ir pro mercado”.

MAURICIO: Exatamente.

Mas se for considerado estratégico tem que ir pro Serpro ou Dataprev.

EVERSON: Tem que ir pro Serpro.

MAURICIO: Exatamente.

Fora isso pode ser mercado normal, qualquer coisa, licitação, tudo o mais.

EVERSON: Pode ser mercado.

E existe oferta, hoje assim, de registro de preços, por exemplo, pra contratar Amazon no Brasil, pra fazer…

EVERSON: Não, porque existe uma priorização da indústria nacional também. Que existem outras legislações que tratam da questão, por exemplo, das micro e pequenas empresas e do fortalecimento da indústria nacional. Então a tendência é contratar internamente mesmo.

Não, mas a Amazon tem no Brasil.

EVERSON: Amazon tem? É porque assim, a última informação que eu tive, aí um caso prático, era que algumas agências… É porque às vezes acontece de você trabalhar, o governo, a parte de comunicação social e a parte de TI elas não são muito integradas. Então acontece, por exemplo, da agência ter autonomia e hospedar sua infraestrutura fora.

Agência de comunicação.

EVERSON: Agência de comunicação. Então… Inclusive a Secom, me parece, uma época estava querendo fazer alguma coisa… Não era a Secom, era uma agência que trabalhava pra Secom. Não era uma orientação velada, não era norma, mas a recomendação que aquilo não acontecesse. Porque teve aquele escândalo do Snowden, aquela coisa, tem um decreto de segurança da informação, que é o 8135, não sei se já teve a oportunidade de conhecer.

E ainda tem os órgãos que têm os próprios datacenters. O Planejamento tem?

EVERSON: Está montando. Montou acho que junho uma sala cofrezinha, está hospedando o SEI, o SEI está sendo interno. Mas foi uma demanda que foi pro Serpro, o Serpro não conseguiu atender, aí nossa TI resolveu o problema por montar nossa sala cofre.

MAURICIO: O que acontece também é que o Serpro está perdendo muito campo para desenvolvimento. Muito, bastante campo pra desenvolvimento, justamente por conta do valor, que é muito alto, e da qualidade também. Mas a qualidade ela é um pouco discutível, porque às vezes, muitos casos não é só a qualidade do fornecedor, é falta de planejamento do órgão, do próprio dono do negócio, então acontece muito disso.

Você diz que os órgãos estão deixando de contratar o Serpro cada vez mais e indo pro mercado, é isso?

MAURICIO: Isso. A gente é um caso desses também. Só que a gente não foi exatamente pro mercado pelo modelo IL, mas foi pelo modelo BID.

EVERSON: A gente tem dois projetos, se não me engano, que acabaram um pouco nesse sentido. Um foi o domínios, que demorou tanto a sair e quando saiu, eu estava em viés de finalização, era um sistema de registro de domínios do governo federal, o ônus para a manutenção daquilo e finalização ia ser tão grande que o projeto foi logo encerrado. E o outro foi o próprio Guia de Serviços que lá trás houve uma redução significativa do escopo pra ver se o Serpro entregava, e eles demoraram mais de dois anos pra entregar, porque o projeto era de 2009, eles entregaram em maio de 2012, aquela versão beta ainda. Sem falar que, por exemplo, a gente teve um – isso aí já divulgado na imprensa – parece que foi o TRT ou foi o TST fez um distrato de um contrato com o Serpro por falta de entrega. Então isso é bem… Assim, trabalhar com o Serpro é extremamente complexo.

MAURICIO: E outra coisa, eles não trabalham no modelo ágil. Então qualquer mudança de escopo, mudança de requisito vai gerar uma nova fatura com vários pontos de função. Então o modelo que eles trabalham meio que você tem que ter tudo definido previamente, a gente vê que não é o que acontece hoje pelo fato dos sistemas, você vai construindo e evoluindo paulatinamente.

Então vamos lá, o que vocês buscavam quando vocês começaram a pensar esse novo contrato pro Portal dos Serviços, o que vocês avaliaram que tinha, que precisava melhorar e como é que vocês pensaram essas chamadas… Não foi licitação, né, foi uma chamada de…

EVERSON: Foi uma licitação, só que uma licitação numa modalidade um pouco diferente, porque seguia as regras do BID.

MAURICIO: Então, a ideia… Porque assim, o Portal de Serviços, na época, ele era restrito a um catálogo. Um catálogo de serviços. Então ele era muito simplista, no início. Só que houve uma demanda do Gabinete Digital da Presidência em tornar o Portal de Serviços realmente o lugar centralizado onde o cidadão pode ter ali, um lugar ali onde ele possa ter o serviço ofertado até transacionalmente. Então o modelo sairia de um catálogo pra realmente algumas prestações de serviço de fato. Então a gente precisava, nesse caso, de uma evolução que era bem maior do que a gente imaginava. Então aí, oportunamente, veio o Procis, com essa oportunidade da gente contratar uma empresa de consultoria, e aí a gente colocou alguns critérios. Aí um dos critérios mais fortes era ter alguma experiência em governo digital. Experiência com governo e, especificamente, em transformação digital. Uma das grandes demandas na época também era transformar serviços presenciais em digitais, que o Brasil ocupa hoje a 57ª posição em governo eletrônico, em grande parte porque temos poucos serviços prestados completamente pela web, transacionais. Então esse era um grande desafio. E aí a empresa que ganhou o processo de seleção ela tinha uma expertise justamente nisso por causa do período que eles passaram lá trabalhando no governo mesmo, num portal também de serviços. E oportunidades não só construíram o portal, mas fizeram a transformação digital também nos serviços. Então isso pesou muito pra processo de seleção. Outra coisa também era trabalho e a experiência com metodologia ágil. Porque a gente tinha um período de um ano pra executar um projeto que era bastante ambicioso, então a gente tinha que ter uma empresa que já tinha essa expertise, em evolução, em entrega contínua, em mudança de escopo em períodos curtos de tempo. Então, por isso que nesse caso foi bem, o processo foi bem legal, e a empresa escolhida realmente foi um sucesso que a gente teve.

Uma coisa que eles me falaram é que a chamada, a licitação chamava consultoria e não necessariamente esperava desenvolvimento de software propriamente dito, mas sim uma especificação e tal pra depois desenvolver, e eles propuseram que não, que tinha que desenvolver.

EVERSON: O objeto ele menciona claramente que seria consultoria. Mas a gente deixou bem claro no processo de seleção que teria código a ser entregue. Não é que a empresa forçou pra ter isso, a própria diretora nossa deixou bem claro quando a gente estava com quatro propostas sendo avaliadas que haveria entrega de código. E era especialidade dos fornecedores selecionados também, então veio de acordo com a nossa perspectiva e expectativa.

MAURICIO: É, em alguns produtos a gente especificava que, assim, a necessidade do produto consultoria, do trabalho intelectual, só que aquilo de alguma forma precisava ser validado. Então a validação ela era feita através de protótipos, então protótipos executáveis, na verdade. Protótipos em que a gente pudesse usar, passar para um cliente, o cliente validar. Nosso cliente, no caso, como órgão centralizador, são os outros órgãos do governo, que validam o modelo. Então daí qualquer empresa que entrasse, ela teria que, um dos pré-requisitos era justamente ter essa expertise de trabalhar também com código, então isso também favoreceu a empresa que ganhou, porque eles também já tinham esse modelo, trabalhar com consultoria barra código validando os produtos.

E foi a primeira experiência que vocês tiveram com fornecedor fazendo esse tipo de metodologia ágil ou não, vocês já tinham tido?

MAURICIO: A primeira. No nosso caso foi a primeira.

E como que foi a experiência até agora de entrar com escopo aberto, de levantar hipóteses, de validar, como é que vocês receberam…

MAURICIO: Então, como a gente vinha trabalhando um modelo extremamente fechado, que era o modelo do Serpro, baseado em definição de escopo previamente, fatura e contagem de ponto de função em cima daquele escopo, então a experiência foi muito boa nesse sentido. Muito boa mesmo. Porque em muitas situações a gente levantava era realmente hipóteses, a gente não tinha certeza se realmente aquilo era a melhor forma de descrever a solução negocial. Em muitos casos a gente colocava as hipóteses, pedia pra empresa desenvolver e depois a gente via de fato, isso acontecia de fato, que tinha que ser alterado por conta de métricas, que eram coletadas não só métricas passivas, vamos dizer assim, através de ferramentas que coletavam automaticamente estatísticas, com ativamente, ou seja, de cliente que a gente não tinha contactado ainda mas que vinha até nós e dizia “ó, vi isso aqui, essa parte aqui a gente está com dificuldade, etc, etc, a gente sugere a melhoria” e aquilo ali era implementado de fato. Em contrapartida… Esse foi o lado muito positivo, que a gente estava tranquilo em relação a isso, a gente sabia que se tivesse que alterar a gente ia alterar sem ter maiores problemas e burocracias em relação a isso, que é um grande empecilho que a gente tinha aqui em relação ao Serpro, o fornecedor antigo. Em contrapartida, a gente tem o seguinte. A gente tem um período definido de tempo pra entrega do projeto. Então assim, no modelo ágil, a gente sabe, ágil mesmo, puro, que é como a empresa trabalha, a gente sempre coloca uma hipótese e testa, e depois a gente vai testando e validando outras hipóteses. Então assim, no mundo ideal, a gente testaria essas hipóteses indefinidamente até chegar no modelo realmente final, sacramentado. Só que no nosso caso a gente tem um tempo mínimo definido pra isso, então a gente não tinha como esgotar todas as hipóteses, a gente ia melhorando, mas chegava num ponto que a gente tinha que definir “bom, a partir daqui a gente vai ter que parar e vocês não vão mais implementar nada pra frente”, porque tinha outros produtos, muitos outros produtos em paralelo, que a gente precisava entregar durante aquele determinado tempo. Então esse eu acredito que foi talvez uma das maiores dificuldades nesse sentido. Apesar do escopo ele ser flexível, o tempo ele não é flexível pra finalização do contrato, do projeto e os nossos compromissos pra direção, pros diretores, pros secretários, e até pro próprio ministro.

EVERSON: E o horizonte foi muito curto do contrato, né, dois meses.

MAURICIO: Exatamente.

Então vocês tinham alguns produtos macro que, dentro desse produto, o escopo era aberto e transformável, mas vocês não podiam perder a dimensão das grandes entregas.

EVERSON: Principalmente dos produtos documentais, que a gente tem que discutir mais claramente esses produtos. Porque o método é focado muito no desenvolvimento do código e onde, eu não posso falar propriamente uma discrepância entre o que é documentado no método tradicional e no método ágil. Então a gente às vezes tem que sentar, definir com a empresa as questões de entrega, o que que será entregue, os critérios de aceite, pra ficar de forma harmonizada com a expectativa nossa e com o cumprimento dos produtos e subprodutos. Nosso contrato também tem muitos subprodutos, é muito detalhado.

MAURICIO: Eu queria ressaltar um ponto que é o seguinte. O fato do código ter sido desenvolvido num modelo aberto, plataforma aberta, GitHub, então assim, a gente vai poder continuar exercitando essas hipóteses mesmo tendo terminado o contrato com a empresa. Então a cultura que é gerado nesse modelo é muito positiva nesse sentido, que a gente não fica amarrado à empresa. A gente vai ter inclusive no final do ano um processo de transferência de conhecimento, e na verdade o processo de transferência de conhecimento ele é feito contínuo ao longo do tempo, junto com todos os stakeholders do projeto, mas assim, esse é um modelo muito interessante porque a gente continua exercitando essas hipóteses adiante sem problema nenhum. E era um modelo também que a gente não tinha ainda, o modelo de disponibilizar o código do governo no GitHub, na plataforma aberta, pra que qualquer cidadão possa sugerir, não só código, mas conteúdo pro Portal. Então isso também foi um processo novo, porque a gente trabalhava também num modelo fechado, era um CMS do Serpro e tudo, então era totalmente, bem diferente nesse sentido.

EVERSON: Tem um modelo colaborativo de desenvolvimento e de evolução do projeto. A gente tem poucos projetos nessa linha, que explorem tanto a colaboração. Inclusive a gente já está divulgando isso em evento, como no FISL, pra se criar uma comunidade que existe lá o GitHub, aquela comunidade, e que a pessoa pode, o desenvolvedor pode reaproveitar aquele código, pode complementar as informações.

MAURICIO: O nosso projeto ele tem integração com vários órgãos de governo, inclusive com a própria CGU com a parte de Ouvidoria, então uma preocupação foi: vamos terminar o projeto, não temos mais fábrica de software, porque não tem mais recursos. Só que da forma como foi construído o projeto, que que a gente pode fazer? A gente pode entrar em contato com o órgão pra dizer: “ó, vamos fazer a integração?” “vamos” “beleza”. A gente aqui não vai ter condições, não temos fábrica pra isso, mas se o órgão quiser integrar, se quiser implementar ele pode implementar em cima da ferramenta e tudo vai funcionar”, porque está totalmente aberto, nesse sentido é outra grande… Tem várias vantagens nesse modelo, essa é uma vantagem.

E vocês disseram que vocês não estavam submetidos às regras das INs 04 e 02. Mas vocês veem que é possível, seria possível fazer a mesma coisa que vocês estão fazendo se estivessem ou não?

EVERSON: Olha, a IN tem um rótulo de burocratizar o processo, mas ao mesmo tempo tem uma vantagem porque ela facilita o gerenciamento. Então se você tem uma coisa estruturada em todo o ciclo da política pública, que vai desde planejar o que se quer e o que que vai ser necessário pra implementar aquele resultado, pelo menos em tese, e aí a gente não tem tanta experiência, mas entende de que isso vai facilitar a qualidade das entregas, a gestão dessas entregas, o resultado delas. Então acho que, meio que é indiscutível que tende a melhorar. Só que é uma grande… O próprio procedimento de contratação é uma grande queixa dos órgãos, que a IN veio burocratizar, dificultar, tanto que ela já foi alterada acho que a quarta vez.

Mas aí não ficou claro. Você acha que sim, então seria possível fazer…

EVERSON: Com ela? Eu creio que sim. Vai dar mais trabalho, porque só pra você fazer o planejamento da contratação pode acontecer da licitação toda demorar quase que um ano pra fazer.

Pois é. Uma das questões é, você tem que fazer as ordens de serviço, não sei, acho que ela não usa esse nome, mas você tem que fazer as demandas pro fornecedor com escopo, com tudo mais, e voltar, e regra de aceite e tudo o mais pra cada modulozinho. A minha pergunta é, será que isso cabe na questão de testar as hipóteses ou ficaria, teria que fazer ordens de serviço muito genéricas e difíceis de validar?

MAURICIO: Então, teve um seminário há pouco tempo atrás do SISP. Tem um grupo aqui que estuda a questão de metodologia ágil, contagem de ponto de função com a metodologia ágil. Então eles geraram um documento, que é um guia pra contagem justamente pra projetos que usam essa metodologia. Então não necessariamente você precisa ter o escopo definido, vamos dizer assim. A coisa está se flexibilizando mais. Esse guia, ele ainda não está, assim, ele não atende exatamente o ágil puro, conforme a gente está desenvolvendo aqui, ele ainda tem algumas amarras. Ele delimita, por exemplo, que você pode mudar o escopo mas pode, de determinadas funcionalidades você pode mudar, ou tantas vezes você pode mudar, então é coisa… No nosso caso, foi bem mais flexível, a gente podia mudar quantas vezes forem necessárias. Esse guia ele não está prevendo que você pode mudar quantas vezes são necessárias, então ele exige um pouco mais de estudo previamente do escopo, vamos dizer assim, mas não é tão amarrado quanto o anterior, que você tem que ter o escopo totalmente definido, e que se mudar vai ser cobrado novamente. Então a coisa está se desenhando de forma que ainda possa atender esse novo modelo.

EVERSON: Uma coisa que a gente pensou no começo que faz, pelo menos em princípio parece facilitar esse processo de gestão com projetos ágeis, é a questão da qualificação da equipe com relação à metodologia. A gente no começo sentiu um pouco de dificuldade porque os órgãos não têm pessoal e não estão preparados pra… Porque assim, você não tem uma equipe de desenvolvimento nos órgãos. Às vezes você tem um cara que foi desenvolvedor um dia e que agora é um gestor, não necessariamente um coordenador-geral de TI ou um gerente de projeto, ele pode ser um DAS, alguma coisa assim, e está envolvido com o projeto. No caso do Itamaraty, que a gente citou, eles tinham equipe forte, que conhecia e que acompanhava, então isso é diferencial. Pelo menos assim, o que eu vi com bons olhos nesse sentido foi isso, porque pra eu colocar uma pessoa ou até duas pra acompanhar um projeto de médio porte, que tenha um prazo estritamente definido, e que não tenha muita flexibilidade, embora tenha com o objeto, pelo fato de ter escolhido o método ágil, mas não tenha com relação à entrega que deve ser feita, isso pode comprometer a qualidade da entrega e complicar até na questão de emissão de fatura, porque a empresa ela também precisa ser remunerada ao longo do tempo. E o processo ágil, você vai fazer as entregas e essas entregas podem não estar plenamente redondas.

MAURICIO: Eu queria ressaltar uma coisa que é o seguinte. No caso do método ágil, sempre aquela premissa de que você vai testar as suas hipóteses. Só que testar hipóteses num ambiente, vamos dizer assim, privado você tem abertura total. Aqui você tem os ambientes de hospedagem que são mais burocráticos, que são do Serpro. Então o que que acontece. Você faz uma mudança de escopo, você altera o desenvolvimento, mas daqui que aquilo vai pra produção, você tem todo um procedimento pra poder chegar realmente em produção e a gente conseguir testar aquela hipótese e alterar, depois de voltar, e você tem um tempo de ciclo mais curto possível. Então a gente sempre trava em algum momento. O que a empresa que ganhou esse processo fez foi justamente tentar mudar essa cultura aqui, tentar implantar a entrega contínua, que a TW fez, um dos grandes ganhos, foi, juntamente com a equipe de infraestrutura, tentar fazer com que esse caminho seja automatizado, desde a alteração do código até a sua efetiva implementação em produção, que eu acho que é uma das coisas mais complicadas dentro de governo pra você realmente ter a metodologia ágil implementada de fato, da forma mais pura possível e rendendo os resultados que ela prevê, que gera a curto prazo, a curto e médio prazo.

E um ponto negativo, algo que não deu certo, algo que gerou ruído, algum problema, teve alguma coisa, vocês conseguem?

EVERSON: A gente está descobrindo agora porque está no trimestre final do projeto. Eu acho que a questão da documentação, não propriamente um ruído, mas eu acho que teve que haver um maior diálogo com relação à expectativa.

MAURICIO: Eu acho que uma das grandes dificuldades do projeto foi que a gente, que participa da equipe que executa o projeto, juntamente com o fornecedor, a gente não participou da construção do Termo de Referência que estabelecia todas as regras e todos os produtos que iam ser entregues.

Quem que fez isso? Foi outra equipe aqui do Planejamento?

MAURICIO: Outra equipe, com uma participação de um dos membros aqui. Mas assim, um dos membros de nossa equipe, uma participação. Mas a gente não teve completo controle sobre isso, não teve completa participação sobre isso. Então a gente teve um pouco de dificuldade no entendimento de alguns produtos que estavam no TR pra adaptar à necessidade real do projeto. Esse acredito que foi uma das maiores dificuldades.

Você acha que em alguns casos a documentação gerada acaba sendo uma documentação pró-forma pra cumprir contrato e menos útil?

MAURICIO: O que a gente faz é tentar gerar uma interpretação pra o produto que está escrito, gerar interpretação que realmente seja mais adequada pra necessidade do projeto. Então é mais nesse sentido. Alguns casos a descrição estava um pouco abrangente, aí a gente consegue especificar. Em outros casos não, ela é mais direta, mas não reflete algumas necessidades reais. Aí é mais difícil da gente conseguir colocar uma interpretação, porque não está tão subjetiva.

Se vocês fossem fazer, participar da abertura do TR, quais são as documentações que vocês consideram essenciais, por exemplo, a IN 04 prevê uma série de documentação lá antes de requisitos, de riscos e de coisas… como é que chama aquela de…

EVERSON: Termos de aceite, recebimento definitivo provisório?

Não, tem um que é de internalização, como que o cara vai…

EVERSON: Documento de oficialização de demanda?

Não, tem um que é especificamente sobre como que esse software vai ser internalizado pela equipe do órgão contratante, que fala sobre… Esqueci o nome agora… Enfim, mas comparando com isso, comparando com o que está no TR, quais que vocês consideram que são as documentações realmente necessárias?

EVERSON: É porque assim, uma coisa é o que exige a legislação, outra coisa é a documentação necessária pro projeto. Eu não consigo separar, o que é da legislação eu não consigo retirar.

Não, eu sei, mas se vocês fossem fazer a legislação, se ela estivesse na sua mão, poder de legislação, é uma pergunta assim, do ponto de vista de gestores de projetos, o que que vocês consideram prum contrato de desenvolvimento de software que tem que ter documentação, qual que é a documentação realmente…

MAURICIO: Então, eu nunca participei assim de um projeto em que eu tive que passar por todas aquelas etapas da IN 04, gerar toda aquela documentação. Então assim, eu não poderia comparar na prática se fez alguma diferença ou não. O que eu acho é que pra esse projeto tudo que foi necessário, vamos dizer assim, dava pra descrever lá e da forma que a gente, tudo que a gente precisava. Então assim, em tese, a gente não precisou de nada da IN 04. Agora, a gente com certeza teve alguns documentos, algumas coisas da IN 04, planejamento de risco, transferência de conhecimento…

EVERSON: Plano de inserção.

Plano de inserção. Esse que eu tava falando.

MAURICIO: Plano de inserção não está na IN 04.

EVERSON: Está. É porque a gente… O que o que que aconteceu, a gente queria incluir pra fazer alterações não do objeto, mas pra melhorar, esclarecer o objeto e por conta do timing a gente acabou não fazendo o plano de inserção pro projeto.

E você acha que é um que é importante?

EVERSON: Eu acho que é importante porque contextualiza até a empresa com relação às entregas e expectativas e algum eventual ajuste necessário.

MAURICIO: Apesar de não estar descrito no Termo de Referência que a gente fez, a empresa ela fez. Ela fez uma semana aqui de imersão, vamos dizer assim. De entendimento do escopo, de quais são todos os objetivos macro do projeto e tal. Isso, apesar de não estar descrito no TR, a empresa ela mesma já fez isso.

EVERSON: Por conta da aplicação do próprio ágil. Ela teve duas semanas de inserção.

Mas isso foi no começo do projeto, né?

EVERSON: No começo do projeto. Que é na fase que vai aplicar técnica de persona, que levantou requisito, expectativa dos clientes, stakeholders, essa coisa toda.

MAURICIO: Assim, a gente não teve nenhuma dificuldade em tese por não ter seguido a IN 04, a gente não teve… O modelo ágil ele é bem interessante pra ajudar justamente nisso, porque a gente muda tanto o escopo, então a coisa não é amarrada. Então facilita bastante em relação a esse ponto.

EVERSON: Teve um evento do SISP que acho que foi até transmitido que o Mauricio mencionou que eles lançaram o roteiro de métricas pra métodos ágeis, eu acho que ele está disponível na intranet, na intranet não, no site do Serpro. Se você conseguisse, porque tem outras iniciativas além do Itamaraty, eu não se se é Ipham… Tem mais dois órgãos que apresentaram cases aqui… Banco Central foi um… Talvez fosse interessante você dar uma analisada.

MAURICIO: Eu acho que o modelo também de contratação do BID também, você tem esse modelo? Conhece as regras? Se você quiser a gente pode disponibilizar também.

ÍNDICE