ANEXO B – Entrevista com equipe Thoughtworks

Entrevista com Carlos Vilela (desenvolvedor pela Thoughtworks Brasil, escritório de Porto Alegre) e Olivia Janequine (gerente de projetos da Thoughtworks Brasil, escritório de Porto Alegre)

Contratados para trabalhar no projeto do Portal dos Serviços Públicos, do Ministério do Planejamento, Orçamento e Gestão com verba do Banco Interamericano de Desenvolvimento dentro do programa Procis.

Como é o arranjo de contratação? A partir da demanda como se chegou a vocês?

OLIVIA: O Procis é um desses convênios que o governo federal tem com instituições globais de fomento, outras tipo o Banco Mundial, PNUD também tem arranjos desse tipo. No nosso ponto de vista o que tem de diferente de um arranjo desse tipo, de uma contratação convencional do governo para software, é que o critério de preço não é o único critério pra seleção do fornecedor. Então a gente competiu com as outras organizações que estavam no edital, não é um edital exatamente, que estavam na concorrência por preço e qualidade. E foi isso que fez com que fosse possível a gente conseguir o projeto. A gente tem consciência, como organização, a Thoughtworks, de que competir por preço não é uma coisa viável pra gente. A gente é caro. A gente tem um foco muito grande em qualidade, nossos consultores… Enfim, sem querer me gabar, já me gabando, a gente é foda e a gente cobra bem por isso. Entã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.

O MPOG tinha essa demanda, abriu uma concorrência a partir desse Procis com o BID e aí abriu uma licitação, uma concorrência, enfim…

OLIVIA: Uma concorrência.

E vocês ganharam essa concorrência, foram contratados e é um contrato com o BID.

OLIVIA: Não, é um contrato com o Ministério do Planejamento.

É um contrato com o Ministério do Planejamento.

OLIVIA: É. E a gente foi convidado a participar da concorrência. Avisaram a gente. O Ministério do Planejamento ativamente avisou a gente que essa concorrência existia. A gente não estava olhando.

CARLOS: Foi uma coisa bem: “a gente acha que vocês tem uma chance nesse negócio, entra na brincadeira aí”.

Mas então esse contrato ele está dentro, está regido sob…

OLIVIA: A 8666 e a IN 04.

Estão dentro do regime de TI, normal…

OLIVIA: Estamos. Normal.

Em tudo? Ou tem alguma concessão?

OLIVIA: Essas duas em tudo.

A única diferença é que não foi uma licitação comum?

OLIVIA: Eu nem sei o caminho institucional jurídico exatamente, mas eu sei que o que diferencia é que o único critério não é preço. Preço não é o único critério.

Mas tem pregão eletrônico?

OLIVIA: Não.

CARLOS: Foi avaliação subjetiva das propostas, é isso?

OLIVIA: As propostas foram entregues e tinha uma matriz de pontuação dentro dos dois critérios. Três critérios, na verdade. Um critério era preço. Isso recebia uma nota, que era matemática, objetiva. Primeiro, segundo, terceiro, quarto, quinto. O outro critério era qualidade da proposta, porque foi apresentada uma proposta técnica robusta, porque é um contrato de um estudo referencial, não é um contrato de entrega de software. E o terceiro critério era equipe. TInha lá uma série de… bem objetivo essa parte da equipe.

CARLOS: Esse era pontuado também.

OLIVIA: É, era totalmente pontuado. “Para função tal, artigo publicado vale tantos pontos, no tema X, Y, Z.” Isso era uma outra matriz. Então tinha matriz de preço, a matriz de currículos e o critério de qualidade da proposta, que foi a avaliação por parte da área demandante dentro do Ministério do Planejamento.

Mas se não é um contrato para entrega de software, ainda assim está dentro do escopo da IN 04?

OLIVIA: Tá. Porque a primeira coisa que nos apresentaram depois que a gente ganhou a concorrência foi a IN 04 e a necessidade de haver uma série de documentações lá que são específicas da IN 04, esqueci o nome do negócio, me apagou. Isso está lá no começo. Mas também é coisa lá do fiscal requisitante, fiscal técnico, fiscal administrativo, todas essas coisas com as quais eu que lido.

CARLOS: Eu esqueci agora o número da seção, mas tem uma seção na IN 04 que diz: “Essa é a estrutura que o governo tem que ter pra reger um projeto sob a IN 04”. Então tem todo um sistema de fiscalização e jurídico e tal, tudo isso aí a gente não participa ativamente, mas a gente viu isso acontecendo quando a gente começou o projeto, eles estavam se movimentando.

OLIVIA: E a gente mapeou isso pra saber com quem a gente falava e qual era o caminho de tomada de decisão, essas são as coisas que a gente fazia.

E vocês têm uma experiência grande em desenvolvimento ágil, em abordagem lean, essas coisas todas. Como que foi trazer essa visão, essa metodologia pra dentro desse projeto, tanto do ponto de vista da cultura dos gestores quanto do ponto de vista das restrições da própria IN 04, foi muito complicado?

OLIVIA: É uma batalha constante.

CARLOS: Mas a primeira alavancada que a gente deu na coisa foi ver que se a gente entregasse o que estava no contrato, que era um estudo referencial, a gente podia muito bem sentar e escrever um estudo referencial, fazer pesquisa, fazer testes, mas isso ia cumprir o contrato, a gente ia entregar o estudo referencial, mas não ia sair nada no ar no final da coisa, nem no começo. Enfim, em ponto nenhum.

OLIVIA: Ia sair um estudo referencial no qual a gente não acredita, porque ele é anti-lean. Ele seria só um levantamento infinto, enorme, num tempo excessivamente grande de hipóteses sem testar nenhuma dessas hipóteses, e a gente escolheu um outro caminho. A gente propôs um outro caminho antes de ganhar a licitação.

Antes?

CARLOS: Antes, na própria proposta.

OLIVIA Nossa proposta diz: “a gente vai construir essas hipóteses, mas a gente vai testar elas, pra construir a próxima hipótese em cima dos resultados do primeiro teste”.

CARLOS: Então os Serviços Gov.br, o projeto dos Serviços Gov.br do jeito que ele está organizado hoje, ele tem algum foco na entrega, mas pelo único motivo que a gente tem que focar na entrega porque senão os experimentos não validam. A gente não tem como saber

Se as ideias que a gente teve durante o projeto deram certo ou não. Então a gente transformou a coisa num sistema pool em vez de push, onde você bola requisito e joga numa fila pra ser produzido. A gente inverteu aquilo e falou “tá, a gente tem que saber, a gente tem que conseguir a participação de diversos órgãos pra que um portal que tem todas as cartas de serviços do governo federal de acordo com o Decreto Cidadão, a 6932 e tal”. Pra gente conseguir isso a gente precisa ter uma experiência boa na criação e edição de conteúdo, da descrição dos serviços, dos eventuais serviços digitais, integrados. Pra ter tudo isso a gente precisa saber como é que uma experiência boa seria. E pra ter uma experiência boa a gente precisa sentar com esse pessoal e dar alguma coisa pra eles, dar algum brinquedo pra ver eles quebrando. E se sentir mal porque a gente errou e tal e tentar de novo até que eventualmente a coisa saia do lugar. Então pra ter esse tempo de iterar na solução enquanto a gente achava o melhor caminho, a gente não tinha outra escolha a não ser começar logo a desenvolver software pra gente poder colocar na frente de alguém que estava responsável pelo conteúdo, ou na frente, potencialmente, de milhões de usuários, cidadãos, que vão lá consultar o portal, e aí analisar as métricas e ter estudos, enfim, pensar em cima disso. Então o pensar demora. O fazer, talvez nem tanto. Então a gente resolveu fazer primeiro pra ter mais dados pra analisar na hora de pensar e decidir qual que era o melhor caminho.

E o fato de vocês ganharem a proposta já mudando um pouco o escopo, mudando a abordagem que eles tinham pedido já mostra uma predisposição deles de experimentar isso.

CARLOS: É.

OLIVIA: Uma vontade grande, a gente sentiu lá no comecinho do projeto.

Por que é um projeto de quanto tempo?

OLIVIA: Um ano.

E vocês estão agora, em que fase?

OLIVIA: A gente está no nono mês.

E vocês, a primeira entrega executável, usável, pra eles…?

OLIVIA: Duas semanas.

Duas semanas? Mas isso não pro público, pro cidadão.

OLIVIA: Não. Deploy em produção é uma outra novela na qual a gente também escreve.

Já teve algum?

OLIVIA: Teve. Já teve cinco. Estamos indo pro sexto.

CARLOS: Antes… Claro, ir pra produção é claramente, obviamente, uma entrega de valor. Mas acho que a primeira entrega de valor foi ler o edital, não foi o edital, não sei se estou usando o termo certo.

OLIVIA: O termo de referência.

CARLOS: O termo de referência e falar “tá, vocês precisam…”

Qual termo de referência?

OLIVIA E CARLOS: Do nosso projeto.

OLIVIA: Porque depois que a gente ganhou a licitação…

CARLOS: Peraí, antes da licitação.

OLIVIA: Antes? O edital.

CARLOS: O edital. Tá, então não tava viajando. 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 de um ano de ter dado num projeto”. Então a primeira entrega de valor veio antes da gente ganhar a licitação, que foi “essa proposta só funciona se” e aí na nossa proposta a gente descreveu algumas condições pra que a coisa desse certo.

OLIVIA: Nossa visão de como fazer aquele objetivo que estava expresso ali funcionar, sendo que naqueles termos em que aquele objetivo estava desdobrado no edital a gente entendeu que não funcionaria da melhor forma possível.

Por exemplo?

OLIVIA: Por exemplo isso que eu acabei de falar anteriormente, de você fazer um monte de hipóteses sem, não testar praticamente.

CARLOS: A primeira entrega de valor foi: cara, a sua visão macro está errada de como tocar esse negócio. Porque o teu macro diz: você estuuuuda e aí lá no final você passa no vestibular fazendo o software funcionar de primeira. Não, você faz o software primeiro e aí você vai iterando em cima disso, você vai errando e achando o melhor caminho durante o desenvolvimento. E aí várias dessas hipóteses que poderiam ter sido encontradas logo no começo, você consegue não só validar as coisas, mas você consegue gerar novas. Então a gente viu, depois de algum tempo em produção, que usuários da internet em geral procuravam por determinados termos que não estavam presentes no conteúdo, não fazem parte de nenhuma categoria de coisas, que estavam previstas ou não, não fazem parte de categoria nenhuma porque ninguém tinha pensado no serviço daquela forma.

Não teve nenhum questionamento por parte de concorrentes de que a proposta de vocês mudou o escopo, o objeto?

Não houve, inclusive houve uma validação da escolha por nós, por parte do concorrente, do segundo lugar, que é um grande fornecedor do Ministério do Planejamento, que é a COPPE. A COPPE, na época, agora isso mudou um pouco, mas na época a COPPE tinha um monte de contrato com o Ministério, eles já tinham feito esse projeto… COPPETEC UFRJ. Eles já tinham feito esse projeto no ano anterior, 2014, conforme eles estavam fazendo outras coisas dentro de um outro contrato lá, eles desenvolveram umas coisas pra o então chamado Guia de Serviços. E eles entraram na concorrência, em tese era a continuidade do que eles estavam fazendo. Mas aí a gente entrou na concorrência, ganhou e recomeçou do zero. E eles não só não contestaram a escolha da gente, como o pessoal da SLTI fez questão de contar pra gente que eles tinham referendado a escolha da SLTI, falado “tá tudo certo, a gente perdeu, mas a Thoughtworks…” A gente estranhou, tipo… mas rolou. Rolou isso. A gente até teve uma reunião com eles pra falar de uma coisa que eles que desenvolvem lá, que é o Buscador de Governo.

CARLOS: Que não existe mais.

OLIVIA: Que tá lá, mas no primeiro ajuste fiscal os contratos deles, todos os contratos Procis do Ministério do Planejamento menos o nosso, agora eu vou me gabar, foram cortados em 50%. O nosso foi o único que ficou inteirinho.

Mas você estava numa linha de raciocínio… que a primeira entrega foi justamente essa mudança…

OLIVIA: Foi nossa proposta.

CARLOS: Então a primeira entrega de valor foi a proposta. A segunda, aliás, isso estava como parte da descrição do que a gente queria fazer na proposta, foi botar todo mundo na mesma sala e só sair de lá quando todo mundo tivesse a mesma frase na cabeça, ou, pelo menos, a mesma descrição do que ia ser esse negócio. Porque até então a gente escutava uma coisa diferente do escopo, que não era exatamente o que estava na TR, o Termo de Referência, e quando a gente perguntava qual que era o maior sonho de cada um dos envolvidos na coisa, era um negócio totalmente diferente. Pra alguns, o trabalho que a COPPETEC tinha feito em 2014 já era mais do que suficiente pra resolver o básico e era só usar aquilo pra daí sim falar de serviços 100% digitais. Esse era um projeto de integração de serviços e órgãos. Integração técnica mesmo, protocolos, fluxos de trabalho, enfim. Pra outros, o grande sonho era fazer com que as Ouvidorias parassem de escutar tanta chiadeira, porque tinha muita gente chegando na Ouvidoria sem saber o que tinha que fazer. Pra outros era totalmente aberto, era tipo “tá, tenho que ter TR, mas eu não sei realmente o que esperar, eu não sei muito bem o que é um serviço público, eu acho que eu vou por aqui, talvez essa seja mais ou menos a descrição do serviço”.

OLIVIA: Pra um ou outro era “queremos ser o GDS do Gov.uk”. Queremos ser tão legais quanto o Reino Unido. Não em um ano, mas algum dia.

CARLOS: Então a gente foi de expectativas que variavam entre “não sei, isso é um projeto extremamente técnico, eu não vou me meter porque eu sou da área negocial”, até… A gente nunca escutou isso palavra por palavra, mas o subtexto ficou entendido: “a gente quer fazer o GDS com um orçamento de…

OLIVIA: Um décimo.

CARLOS: Não, sessenta vezes menos por mês. Com uma equipe trezentas vezes menor. E a gente quer agora, a gente quer em um ano, a gente quer tudo. Sai fazendo.” A variação de expectativa já foi a primeira coisa que a gente teve que resolver. Na proposta tinha já um começo de projeto que era vamos juntar todo mundo sei lá, duas semanas, ou o tempo que a gente conseguir com a maior quantidade possível de pessoas que tenham alguma opinião ou alguma influência no projeto, pra discutir realmente onde é que acaba, onde é que começa, qual que é o objetivo final, quais são as prioridades e num nível um pouco mais abstrato.

Vocês usam alguma coisa, Canvas, essas coisas assim?

CARLOS: A gente tentou uma bateria de exercícios. Nessas duas semanas a gente tentou extrair essa informação de vários jeitos diferentes. Canvas foi uma delas. Teve todo tipo de brainstorming, todo tipo de exercício que você pode imaginar.

OLIVIA: Jornada do usuário, uma série de técnicas que a gente usou. Depois se você quiser a gente pode te dar a lista das técnicas de facilitação e o tipo de exercício, cada um dos exercícios na verdade que a gente fez nessas… Foram duas semanas com uma semana de intervalo no meio que a gente processou algumas coisas.

CARLOS: Então a gente fez… A primeira semana foi “tá, vamos abrir a ideia, vamos botar ela em cima da mesa e ver até onde é que ela vai. Se precisar a gente compra mais mesa, mas vamos ver até onde essa ideia vai”. Alguns caminhos ali ficaram bem claros. Então durante essa semana que a gente voltou pra Porto Alegre pra juntar e consolidar um pouco da informação, a gente aproveitou também e pegou um pessoal mais técnico e trabalhou num protótipo marionete, assim. Vamos botar uma marionete da coisa que mal para em pé, mas aguenta um pouquinho de discutir ali, e mostrar pra essa galera pra ver se o que a gente entendeu na semana anterior realmente tá alinhado. E aí durante essa semana a gente desenvolveu isso ao mesmo tempo que a gente estava consolidando toda a saída e todo o mar de post-its que rolou nessa primeira semana. Quando a gente chegou lá, a gente chegou com uma versão um pouco resumida do que tinha sido conversado, o protótipo e a agenda pra semana seguinte. Na agenda da semana seguinte era basicamente onde é que a gente tem que bater nesse protótipo pra ele ficar realmente a coisa de verdade. Assim a discussão foi durante essa semana. Quando a gente saiu dali tava todo mundo de acordo. Quer dizer, não vou dizer 100% de acordo, mas tinha muito mais acordo sobre o que é que a gente ia fazer do que quando a gente começou. E aquele protótipo foi crescendo, a gente foi adicionando funcionalidades nele e a nossa ideia é que aquele protótipo fosse eventualmente substituir a implementação que estava rolando. Que ia ser um projeto de migração, um projeto de substituir um portal que já existia. E o portal que já existia ia continuar existindo, e quanto mais tempo ele continuasse existindo mais dano ele ia continuar causando pela própria existência. Então assim que a gente conseguisse bater um número de funcionalidades ou que a gente estivesse num ponto aceitável pra virar a chave, a gente ia se despedir do site antigo com bastante violência até, e colocar o novo no ar, e sem necessariamente fazer nenhum alarde. Mas ó: estamos com o site novo no ar, não é tão bom em algumas coisas quanto o antigo, não tem tantas coisas quanto o antigo, mas tem o suficiente pra gente não ter que se preocupar mais com o que tinha lá.

OLIVIA: E diferente do antigo, tem as coisas mínimas, que o antigo não tinha. As coisas que a gente entendeu coletivamente nesses exercícios iniciais que eram o mínimo. Que eram basicamente, que a gente definiu: permitir que o cidadão entenda o que ele precisa, encontre o que ele precisa, ele precisa procurar, precisa conseguir procurar, precisa conseguir escolher, então procurar, escolher e começar. Ele tem um problema difuso, que ele nem tem bem formulado, mas ele consegue na interação com a aplicação melhorar o entendimento dele do que é que ele precisa, chegar numa lista de possibilidades de serviços que atendam aquela necessidade dele, escolher dentro dessa lista e dar o primeiro passo. Esse era o nosso objetivo inicial. A ideia, é o nosso mínimo.

CARLOS: Esse foi o mínimo que a gente combinou ser o importante.

Esse era o MVP primeiro?

CARLOS: É, o primeiro MVP foi…

OLIVIA: O primeiro MVP era a busca corrigir cedilha, entende? Era esse o naipe do código anterior, tinha problema com cedilha. A busca não falava português.

CARLOS: Outro era que o suporte a dispositivos móveis do site antigo também era totalmente horrível.

LÍVIA: Era nulo.

CARLOS: Então só de ter colocado o sistema novo no ar a gente ganhou uma audiência potencial de metade da internet do Brasil. Então não era necessariamente o conjunto de funcionalidades de igual pra igual que dizia que a gente tinha terminado o MVP, mas foi um ponto onde a gente chegou pro Ministério do Planejamento e falou ó “Tá bom o suficiente”. “Ah, mas cadê tal funcionalidade?” “Você não precisa dela, você precisa mais é disso aqui” Então foi uma negociação um pouco mais aberta nesse sentido pra dizer “vamos pra produção”, porque quanto antes a gente for pra produção, mais a gente consegue aprender com as métricas que a gente pipocou pela aplicação toda o que a gente tem que fazer na sequência.

Isso depois de quanto tempo mais ou menos?

CARLOS: Primeira ida pra produção foi em… maio?

OLIVIA: Final de maio. Na verdade é assim, no começo de março a gente estava pronto… na metade de março a gente estava pronto pra ir pra produção. E aí a gente entrou na outra batalha que era, que foi conseguir ir pra produção. Conseguir o ambiente, entender qual das opções, difíceis todas elas, de infra a gente ia embarcar, várias conversas em relação a isso. Depois que a gente definiu ainda um processo longo de fazer com que a DTI do Ministério do Planejamento desse os passos seguintes e fizesse realmente a coisa entrar no ar. Mas a gente estava pronto com a aplicação na metade de março nesse mínimo aí que o Vilela [percebi que ela fala um apelido, mas como não entendi substituí pelo sobrenome dele] acabou de descrever. E todo o processo da gente construir isso no começo e chegar à conclusão, junto com o pessoal da SLTI, de que estávamos prontos pra produção foi um processo na verdade bem longo de convencimento e de um convencimento meio bruto no seguinte sentido, no sentido de que a gente muitas vezes fez sem perguntar e mostrou o que estava feito. Falou “ó, é isso aqui”. 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 aí teve a conversa, em vez de ter a conversa pra aí receber o ok e ir fazer alguma coisa. 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 antes deles escolherem a gente, as coisas que levaram eles a escolher. Teve essa compreensão por parte dos nossos principais interlocutores, eu acredito, que as coisas que eles gostaram no que a gente apresentou lá no começo e levaram eles a escolher a gente são grudadas, se não forem as mesmas, que assustam eles um pouco ao longo do processo de execução do projeto. Então é muito interessante, pra mim como gestora eu fico observando isso muito, tentando entender qual que é o tom geral do que a gente tá fazendo, por que tem tantos momentos mais tensos dentro do projeto e tudo mais. É isso, eles escolheram a gente pra gente fazer fricção, pra gente causar atrito no jeito como as coisas são feitas lá. De vez em quando eles falam “tá demais” e isso gera uma tensão maior. Tipo, “para, quem manda aqui é a gente”. Mas nunca ao ponto de romper e nunca por muito tempo, logo a gente volta pra experimentação pesada e pra esse esquema que eu acabei de descrever, esse cálculo que a gente faz quase que automaticamente dentro da equipe, porque nós somos uma equipe pequena então isso é mais fácil, de olhar um pro outro e falar “puta, a gente vai ter a conversa com eles antes sobre se a gente deve fazer isso ou vamos sair fazendo e aí a gente mostra pra eles o que rolou, e aí eles escolhem se eles querem ficar com isso ou não?”. E 90% das vezes a gente escolhe fazer pra mostrar pra depois ter a conversa.

CARLOS: Teve vários casos onde explicar dois caminhos possíveis pra alguma funcionalidade era tão complicado que fazer os dois e mostrar pra eles funcionando das duas maneiras e perguntar A ou B era mais simples. Então apesar disso não estar necessariamente na priorização, não ser uma coisa tão oficial a gente acabou nunca lidando demais com a especificação do software como uma coisa, como um documento físico que deveria existir antes do software existir. Então a gente está sempre implementando primeiro, às vezes mais de uma vez a mesma coisa, decidindo qual que é a melhor ideia daquelas, escolhendo aquilo, matando as outras e aí sim, quando alguma coisa se consolida melhor, quando a gente entende que aquilo é mesmo o caminho, aí sim a gente documenta, conta a história e enfim, cadastra nos lugares onde a gente tem que cadastrar esses documentos pra gerar os produtos do projeto.

OLIVIA: Voltando à vaca fria da sua pergunta, o que rola com a IN 04. Como é que a gente conversa com eles num processo que é tão central pra eles de gestão de contratos. E central pra gente porque se a gente não fizer a gestão do contrato a gente não recebe. É onde essa fricção fica mais explícita, porque do ponto de vista dos nossos clientes tem uma necessidade premente de gestão de risco num nível altíssimo, quase baseado em medo. Muitas vezes é baseado em medo. Que é: “não, eu preciso de tal e tal coisa porque pode ser que a fiscalização venha, o TCU”. Então tem uma sombra do acórdão do TCU pairando sobre cada uma das decisões deles relacionadas a contrato. E o nosso jeito de trabalhar é o oposto disso, é o oposto dessa coisa baseada em medo e desconfiança. É uma coisa “ó, a gente vai testar essas coisas aqui, o que der certo deu, o que não der certo a gente aprendeu”.

CARLOS: E se eventualmente não estiver bom, vamos ter uma conversa antes que fique ruim.

OLIVIA: A gente faz de novo e a gente tem uma conversa e reprioriza. O jeito como eles fazem gestão de contrato é muito rígido. Então a história da gente construir junto com eles um outro jeito de olhar pra gestão de contratos e realizar gestão de contrato em parceria, os dois lados, é muito parecido com a nossa história de tentar chegar em entrega contínua lá dentro do Ministério. Não tá concluído, ainda não é bom, gostoso pra nenhuma das partes, confortável pra nenhuma das partes. Pra gente é um pé no saco porque muitas vezes a gente tem que entregar coisas que a gente sabe que não entregam valor nenhum pro projeto como um todo, mas é uma obrigatoriedade e aquilo é um gargalo. Se eu não resolver… O único valor que várias coisas do que a gente entrega de documentação tem, é o valor de não deixar que o projeto seja interrompido por questões burocráticas. E a gente sabe disso.

A IN 04 prevê que tem a área demandante, que vai pegar, pedir, vai executar, depois vai fiscalizar, ver se foi entregue, dar o ok e liberar. Vocês estão me dizendo que vocês muitas vezes estão na frente na demanda, vocês estão propondo, não só sendo, não estão só no nível operacional estão num nível estratégico também.

CARLOS: Pra muita coisa a gente gerou a demanda.

E como isso se reflete nesse processo burocrático?

OLIVIA: O que a gente conseguiu, que é o que permite isso, não sem muita dor, é colocar uma frase na TR. Porque depois que a gente ganha a licitação você ainda negocia a TR, você ainda pode realizar mudanças no Termo de Referência do projeto. E a gente colocou uma frase lá, que foi a única frase que a gente falou que era não negociável da nossa parte, que é que o escopo de cada produto poderia ser negociado antes do início da realização daquele produto.

Então o projeto é dividido em oito produtos, cada produto tem um número variável de subprodutos, e a gente negocia os critérios de aceitação desses produtos um a um no período imediatamente anterior à realização dele. 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ão. A gente meio que falou não, eles falaram sim, e a gente foi segurando e a gente vai indo. Eles querendo acelerar umas coisas nesse sentido da definição do que é o escopo, e a gente segurando e a gente… Muitas conversas sobre porque que é importante não fechar o escopo muito antecipadamente. E ao mesmo tempo… Então essa frase garantiu isso e a gente, a partir disso, foi negociando e mostrando a nossa visão de como é que isso tinha que ser feito. Por outro lado, a gente pediu um monte de coisa em termos de processo pra suportar, pra dar condições pra que esse jeito de operar funcionasse, que é a demonstração de resultados a cada duas semanas e a priorização conjunta a cada duas semanas. Nossos ciclos de iteração são de duas semanas, cada iteração tem duas semanas, e o marco é a gente, no final das duas semanas, a gente apresenta o que aconteceu na iteração e no dia seguinte a gente faz uma priorização do que a gente vai fazer nas próximas duas semanas. O tempo inteiro num processo de tentar demonstrar executando na prática a ideia de que você só consegue prever com alguma segurança e escolher dum jeito correto num curtíssimo prazo pra software.

Mas esses ciclos de duas semanas e essas entregas de resultado são processos paralelos ao processo de entrega e documentação da entrega e aceites, são descoladas.

OLIVIA: Sim.

CARLOS: Nesse ponto são quase dois projetos paralelos.

OLIVIA: São. E esse é talvez o meu principal, não o principal mas um dos principais papéis no projeto é fazer a tradução entre um fluxo e o outro. A gente vai fazer isso aqui e isso aqui agora, e aí no mesmo dia que a gente senta pra fazer priorização do que vai ser executado pelo time,

Eu sento com o PO lá da SLTI pra mapear as coisas que a gente está fazendo em relação aos produtos que têm que ser entregues e quais são os critérios de aceite que a gente vai usar pra documentação. Já que é um estudo inicial, os nossos produtos são documento. E aí o que a gente faz, pra cada um daqueles produtos a gente vai bolando os critérios de aceitação, que é um certo conjunto de documentos e um certo conjunto de código, de funcionalidades.

Vocês vão fazendo os critérios de aceitação durante também, não antes.

OLIVIA: Não, é durante. Eles queriam fazer tudo no começo do ano.

Mas durante cada etapa.

OLIVIA: Cada mês. Os critérios de aceitação é cada mês.

CARLOS: Antes de começar cada produto ou subproduto ou subsubproduto, a gente fala dos critérios de aceite. No começo a coisa engargalou muito porque o time deles é pequeno, o nosso time é pequeno e se a gente fosse parar pra entender todos os critérios de aceite de tudo, a gente estava no momento onde as duas equipes eram mais ignorantes possível sobre o que tinha que ser feito. A gente conseguiu meio que deixar essa mensagem um pouco mais clara, de que tinha muitas coisas que a gente não sabia que a gente não sabia ainda, e tinha muita coisa que a gente sabia que a gente não sabia, que a gente tinha uma ideia de como resolver. E no primeiro dia de projeto a gente estava, se você imaginar o quadrante das coisas, o número de itens que a gente sabia que a gente sabia, que a gente tinha totalmente resolvido, era o menor possível. Então a gente mostrou isso pra eles e falou: “galera, o número de coisas que a gente não sabe, que a gente sabe que a gente não sabe, é grande. O que a gente sabe que sabe resolver, que a gente tem completa certeza de como fazer, é o menor possível. Esses números vão só mudar durante o projeto, durante a execução a gente vai passar a entender melhor um monte de coisa, a gente vai mapear partes que a gente não tinha visto antes e trazer aquilo pro escopo do projeto porque elas são importantes. Só que se a gente parar pra fazer isso agora, a gente está se impedindo de aprender mais antes de tomar uma decisão. Então por que que a gente não faz com que o fluxo da coisa seja primeiro você aprende o máximo possível sobre as decisões que você tem que tomar antes de tomá-las? Então antes de você necessariamente fechar uma opção entre A e B só no palpite, você consegue dados, você estuda, você traz mais gente pra conversa, enfim, faz o que você puder fazer nesse caso. E se a gente fizer isso no primeiro dia de projeto, na primeira semana de projeto, no primeiro mês de projeto, a gente está tomando todas as decisões erradas possíveis de uma vez só.

Mas não chegaram nenhum caso aonde a evolução do projeto mudou completamente o produto ou o subproduto e aí…

OLIVIA: Pegamos. A gente mudou de prioridade geral radicalmente em junho.

CARLOS: Produto não sei, mas subproduto eu acho que não teve nenhum que terminou do jeito que começou. Em janeiro e agora assim não tem nenhum subproduto que está igual ainda.

OLIVIA: Não, não tem. Ao ponto do seguinte, Leo: lá na TR que tem coisas descritas pressupondo que a solução que a gente ia estudar, que na verdade a gente está realizando, tem um banco de dados. A gente não tem banco de dados. A gente lida com dados, mas o nosso, entre muitas aspas, banco de dados é um repositório do GitHub. É um repositório Git, que não precisa ser no GitHub, mas é um repositório Git que faz controle de versão das unidades mínimas de conteúdo que são os serviços, cada um dos serviços. Então a gente teve que dar um jeito no jeito de lidar com a TR junto com eles, de gerar produtos que explicitassem essas mudanças e ficassem ao mesmo tempo sólidos, do ponto de vista de atender o que estava escrito na TR e fizessem sentido pra o que estava acontecendo de fato no projeto. Então a gente faz esse exercício com cada uma das coisas.

Então sempre antes de começar um produto ou subproduto, até talvez seja o caso de já saber de antemão “não, esse produto mudou, não é mais o que estava previsto”.

OLIVIA: A casa não acontece tão fluida assim porque o timing de entender as coisas que tem que ser feitas e o que que vai entregar mais valor não é exatamente o timing de… E não é um pra um. Não é o mesmo ritmo que o entendimento da TR e o entendimento das coisas que estão acontecendo com o código acontecem, são ritmos diferentes. O código tem ciclos rapidíssimos, curtos e o entendimento da visão de produto que está expressa na TR é um ciclo bem mais lento. Ao mesmo tempo isso gera o quê? O aprendizado no código, então às vezes as coisas mudam três, quatro vezes na frente de desenvolvimento de código até gerar uma mudança na frente de desenvolvimento da documentação oficial do projeto, da documentação que gera pagamento. E o principal impacto disso é que a gente tem um descompasso entre esforço e faturamento. E  a gente só conseguiu descrever esse problema que eu consigo te descrever agora desse jeito tão sintético, tão bonitinho, no terceiro, quarto mês de projeto, conforme os atritos e os embates entre essas duas visões, a nossa e a do cliente, foram gerando um entendimento e um conhecimento nas duas partes. Então a gente identificou o problema lá pelo terceiro, quarto mês de projeto e a gente só conseguiu reverter esse problema e fazer esforço e faturamento caminharem juntos mês que vem. Ó, tá aqui. Essa é a curva.

CARLOS: Onde a linha cruza.

OLIVIA: É assim que eu acompanho o que está acontecendo.

Pessoal que está assistindo em casa, eu tô vendo um gráfico agora.

OLIVIA: O que estava previsto na TR pro nosso recebimento é essa linha pontilhada, ela é mais… Se você fizer uma linha de tendência aqui ela fica bonitinha, não tem grandes pontos de disparidade da mediana, do que deveria ser. Aqui é o esforço. A gente já realizou uma parte muito maior do esforço do projeto do que o tempo de projeto. Não corresponde. Por quê? Porque o grosso de código tá antes e a gente vai ter um tanto no final que é só faxina final, organizar as caixas e tudo mais. Que não gera tanto valor.

A métrica sua é homem-hora ou mulher-hora?

Não, é geração de valor, entrega de valor.

Mas isso é a métrica que vocês usam na Thoughtworks.

OLIVIA: Não, é a métrica que a gente usa neste projeto, que é produto. Que na Thoughtworks a grande maioria dos projetos é pessoa-hora. Pessoa-hora é a melhor solução pra esse dilema. E aqui é como vai a finança. Tá vendo? Vai aos soluços. A gente só recebeu pela primeira vez em maio.

CARLOS: E isso vai junto também com algumas entregas pra produção. Tem alguns soluços que aparecem aí que coincidem com visitas a Brasília onde a gente conseguiu às vezes resolver no mesmo dia uma entrega pra produção, entregar diversos produtos, receber o aceite daqueles critérios de aceitação que a gente tinha combinado e sei lá, ainda ganhou um boa noite mais educado no final. Tem algumas coisas que aconteceram de maneira cíclica no projeto todo que foram bem interessantes assim. Esse lance de só conseguir ir pra produção depois de muita briga, a gente não fez essa conta, mas dá pra descobrir de forma científica quanto foi que a gente perdeu de escopo possível porque a gente não conseguia experimentar em produção.

OLIVIA: Não dava pra tomar decisão.

CARLOS: Não tinha decisões.

OLIVIA: Aumentou o custo de algumas coisas porque a gente demorou muito tempo, investiu muito tempo em coisas que depois precisaram ser refeitas. O editor é um grande exemplo disso.

CARLOS: É. E não poder ir pra produção com frequência aumenta toda aquela carga de medo.  Então se um texto não estiver necessariamente… Se você não está 100% confiante com um determinado texto no site, pode ser uma coisa besta, pode ser um texto num botãozinho.

OLIVIA: Que só vai corrigir um mês depois.

CARLOS: Mas se você não está feliz com aquilo, você sabe que se você mudar de ideia assim que você ver aquilo no ar e você vai poder corrigir aquilo só um mês ou dois meses depois, você vai ficar muito mais na retranca de tomar essa decisão. Se você puder tomar essa decisão agora, estar em produção daqui 15 minutos, e se daqui a meia hora você achou que mudou de ideia e você está em produção de novo com a correção 15 minutos depois daquilo, você toma uma, você acaba tendo uma atitude totalmente diferente sobre como conduzir o projeto. Então a gente viu… Aliás, essa curva também mostra. No começo a gente trouxe muito mais escopo pra dentro do projeto, a gente implementou muito mais código. Uma parte desse código foi aquela bateção de cabeça pra tentar achar o melhor caminho, mas muito daí também teve de perfumaria. De “não gostei, isso aqui não tá 100% do jeito que eu queria, e eu não vou autorizar enquanto não estiver 100%. Eu não vou aceitar 90%, nem 99.9%, quero 100, quero 100% do escopo que eu tinha pensado meses atrás, ignorando tudo que eu aprendi nesse meio-tempo, porque eu sei que ir pra produção é uma batalha, então se eu não puder ir pra produção com frequência, eu vou pra retranca”.

Aí a gente já entra numa questão de infraestrutura ágil também, não é só uma questão política ali, de querer, uma questão gerencial, uma cultura de gestão, é mais uma questão tecnológica, um gargalo tecnológico ou não?

OLIVIA: É uma questão política, mais do que tecnológica, que a gente encontrou os indivíduos.

CARLOS: É uma questão política motivada pela questão tecnológica. Então porque a organização não tinha estrutura técnica pra fazer idas pra produção com frequência, a ida pra produção com frequência virou uma coisa impossível ou rara.

OLIVIA: Mas isso é o dilema do ovo e da galinha, aquilo que eu discordo de você. O que eu acho é o seguinte: existe possibilidade técnica, material, que a estrutura pode ser, que existe, pode ser trabalhada pra viabilizar a entrega contínua. Existem os indivíduos capazes de fazer isso, ou muito próximos de serem capazes de fazer isso. Mas o modo como a estrutura política se organiza inibe que isso vire o próximo passo.

Eu ia dar minha opinião, mas não sou eu que estou sendo entrevistado.

OLIVIA: E isso dá pra dar nome aos bois. Eu não sei se o que existe hoje materialmente em termos de infraestrutura técnica permitiria um jeito ágil de lidar com infraestrutura em grande escala. Eu não acho que o jeito que está hoje seja escalável. Mas a gente não quer escalar ainda, porque essa porra nem começou. Você só vai pensar em escalar o negócio depois que você já tiver começado. Mas o modo como o esquema político acontece, a relação entre pedacinhos do Ministério uns com os outros, DTI com SLTI, Ministério com Serpro, que é onde estão as máquinas, o modo como essas coisas, essas relações se dão, inibe que sequer comece, que sequer se tenha um projeto piloto que a coisa acontece. A gente ainda tem esperança de até o fim desse ano conseguir emplacar um grau de autonomia suficiente pra entrega que a gente possa chamar de entrega contínua.

CARLOS: Estamos bem perto disso faz um tempinho já eu acho.

OLIVIA: A gente está bem perto disso desde junho. E o nosso aprendizado sobre isso continua muito bom, tanto político quanto técnico, mas é foda.

Você comentou no começo do projeto de ninguém saber, de ter muito mais dúvidas do que certezas. Agora, os gestores pensavam assim também ou eles acreditavam que sabiam exatamente o que queriam, e isso foi uma desconstrução?

CARLOS: Foi desconstrução em alguns, em muitos casos. Foi legal ver que o pessoal do MPOG, a esmagadora maioria, dava um baita voto de confiança na gente, porque eles trouxeram a gente pra causar atrito, pra questionar, fundamentais.

Mas eram as pessoas que estavam no dia a dia do projeto?

OLIVIA: Não só.

CARLOS: Não só. É, também

OLIVIA: Tem gente no dia a dia do projeto que faz isso, tem gente que faz o contrário, e tem gente que faz isso fora do dia a dia do projeto. Que torce pra gente, que fala “não, vai aí, tá mó legal”. Que visita. Mesmo em outros ministérios, sabe.

Você consegue me lembrar alguma… Bom, você já falou dessa questão da gestão da documentação, ter que ser quase uma gestão dum projeto paralelo, descolado da realidade muitas vezes pra dar conta das entregas formais e do cumprimento da legislação e deixar o pessoal tranquilo em relação aos órgãos de controle. Tem alguma outra coisa que você viu nas práticas previstas pela IN 04 que eram contraditórias com as práticas de trabalho de vocês, especificamente?

OLIVIA: Teve uma coisa lá que era responsabilidade deles, que eles simplesmente desistiram de fazer. Eu esqueci o nome disso. Eu tenho aqui, peraí só um minuto, já te digo.

CARLOS: Enquanto isso eu falo do meu favorito ali. A IN 04 prevê que é acabar com a amizade se a contratada se colocar numa posição de superioridade à contratante. Eu não lembro exatamente qual que é o fraseado certinho ali. Mas tinha um lance que você não pode, por exemplo, ter… no nosso caso a gente não teve isso, mas vamos supor que a gente tivesse desenvolvedores mesmo dentro do ministério. Não foi o caso, mas era uma coisa que eu tinha um pouco de receio até no começo, porque na IN 04 tem um dispositivo, tem um pedaço lá que diz que a empresa contratada não pode de repente aparecer numa situação onde ela gerencia a contratante. Então eu fiquei com medo disso até. Porque se o Ministério do Planejamento tivesse desenvolvedores mesmo, e a gente estivesse trabalhando mesmo que juntos, em pares ali, eu na posição de líder técnico do projeto ainda ia poder, ainda poderia aparecer como alguém que mandou essa pessoa fazer alguma coisa. Esse pedaço da IN 04 me pareceu superesquisito.

Isso foi um receio pessoal seu ou isso apareceu na mesa em algum momento?

CARLOS: Receio pessoal, e eu tô até surpreso que nunca apareceu. Porque teve muitas situações onde a gente queria, por exemplo, saber se determinada solução técnica estava boa o suficiente pra alguém que não conhece a parte técnica a fundo fazer alguma operação. Então um exemplo mais claro, vai, isso aconteceu semana retrasada. A gente descobriu que faltou migrar um determinado campo de uma determinada carta de serviço lá da biblioteca da SPI, que era o único registro no banco de dados inteiro que tinha aquele campo preenchido. E veio a demanda: “ó, precisamos migrar esses dados”. E eu devolvi com uma resposta, até meio torta, do tipo: “tá, a gente tem um editor de serviços justamente pra que esses casos de exceção assim possam ser resolvidos. Você topa testar lá e fazer o negócio funcionar?” “Beleza, fiz”. Só que essa interação entre contratada e contratante, pela IN 04, seria ruim, eu não sei se seria ilegal, ou se seria motivo pra advertência, aviso, sei lá, mas seria uma coisa estranha, no mínimo. E eu achei que isso ia aparecer com mais frequência porque a gente fez bastante esse tipo de bate-boca, de bate-bola, de vamos tentar fazer um negócio, não funcionou, tenta você e eu vou ficar olhando pra ver que a gente pode melhorar na tua experiência de como lidar com isso. Isso poderia ser muito bem-visto como “você está tentando mandar na gente, não, parou”. Eu entendo porque que a IN 04 tem isso, porque deve ter relações muito mais tóxicas entre contratada e contratante por aí pelo governo e a IN 04 foi feita pra pensar em tudo.

Acho que é meio que pros dois lados. Tem que entender também que a contratante não pode ter uma posição hierárquica, é uma contratante de serviços, não é que você pode colocar pessoas pra trabalhar aqui que vão ser funcionários.

OLIVIA: Tem um tema geral por trás disso, eu lembrei, eu achei o negócio aqui. A IN 04 prevê, uma das coisas que ela prevê de artefato é que você tem que ter um plano de inserção e isso é responsabilidade do fiscal requisitante, se não me engano, ou do fiscal técnico. E eles pediram a nossa contribuição pra construir esse documento e tal. A gente trabalhou uns dois meses nisso, dando pitaco e falando e tal. Até que chegou um belo momento que era tão conflitante a ideia de fazer um plano de inserção que definia um monte de coisa escrita em pedra, porque depois que você protocola aquele negócio aquilo é meio que uma bíblia sagrada do projeto. Era tão conflitante isso com o jeito como as coisas estavam acontecendo e as coisas nas quais eles estavam confiando, em termos da forma de trabalhar e da entrega que tava acontecendo, que eles desistiram de fazer um plano de inserção.

Eles não entregaram?

OLIVIA: Não entregaram. Até o que eu sei, não entregaram.

Tem também um relatório de riscos, né?

OLIVIA: Existe um relatório de riscos que foi um produto nosso, que basicamente o jeito como a gente entregou ele foi uma proposta de monitoramento contínuo de riscos, o jeito de fazer esse monitoramento, e um primeiro levantamento, válido praquele momento

Mas fala a coisa que você tinha mandado aí.

OLIVIA: Tem um tema geral por trás dessa conversa sobre a IN 04 e a forma como a gente trabalha que é um grande conflito de perspectivas do que é uma relação entre contratante e contratada, entre fornecedor e cliente, que é se você vai basear essa relação em confiança ou desconfiança. A IN 04 é claramente um dispositivo baseado em desconfiança.

CARLOS: Desconfiança mútua de ambas as partes.

OLIVIA: O teu contratado quer te enganar até que se prove o contrário e vice-versa. Você quer explorar o teu contratado, você como contratante, no caso o governo como contratante, quer explorar o seu contratado até que se prove o contrário, então precisamos de um dispositivo legal que arrefeça esse impulso natural hobbesiano. E o jeito como a gente trabalha é o oposto. A gente busca construir nossas relações com os nossos clientes com base na confiança. É mais fácil dizer isso do que construir isso de fato, porque a gente vive num mundo de medo. As pessoas individualmente, não só como organizações, é cada vez mais difícil ceder a um clima geral de desconfiança e de medo. Mas a gente faz, a gente se esforça, a gente bota muita energia nisso. É uma coisa muito central na organização onde a gente trabalha, não só no que tá ali, nas conversas sobre como é que a gente se comporta com o cliente, mas dentro da própria organização, a relação entre as pessoas dentro da organização, a forma como a gente traz as pessoas pra dentro da organização no processo de contratação, tudo, a forma como a gente elabora conflito e resolve conflito. Então eu acho que isso é um grande tema das relações adultas, eu ousaria dizer, no mundo contemporâneo, assim, no Brasil, vamos dizer. É diferente em outros lugares, tem nuances, mas no Brasil isso é um grande tema, as pessoas desconfiam, por padrão. Nada feito, em condições normais de temperatura e pressão tá todo mundo querendo foder todo mundo. Então a gente precisa fazer coisas pra evitar isso. E isso muda tudo. Muda tudo. Se você olha por um lado ou por outro desses dois que eu descrevi muda tudo. E a IN 04 é uma excrecência desse mundo da desconfiança. Não que ele não seja justificado, porque há traumas concretos que levaram à construção disso, mas quando você consolida num instrumento como a IN 04 você perpetua a merda em vez de resolver a origem do problema. E eu acho que isso é um problema recorrente do Estado no Brasil, mas isso é uma outra conversa.

Queria trazer o tema do envolvimento do usuário final do serviço. No fim das contas é o cidadão. Como que era a percepção deles, como que é a de vocês, isso teve algum papel diferenciado?

OLIVIA: A gente queria muito mais do que eles toparam e conseguiram viabilizar.

CARLOS: Quando a gente tava com aquele protótipo pronto, lá nas duas primeiras semanas de visão e criação e tal, a gente queria sair com o notebook com aquele protótipo rodando pelo corredor, parando quem fosse que olhasse por mais de meio segundo pra gente pra “senta aí, a gente te paga uma coca-cola, agora testa esse negócio e fala pra gente o que você achou”. No geral a gente teve, pra generalizar um pouco a coisa mas até sendo meio malvado, a gente  normalmente durante o projeto todo teve uma atitude muito mais corajosa em dar a cara a tapa e ver que deu errado, e tentar resolver os problemas que a gente identificava ou que identificavam pra gente do que o governo, que foi supercuidadoso em convidar órgãos, usuários finais, enfim, pra dar feedback. Então uma coisa que não foi pedida pra gente mas a gente simplesmente fez porque tinha oportunidade foi fazer um teste com um usuário cego. A gente queria saber se as tags que a gente tinha colocado no site eram suficientes pra quem usa um leitor de tela navegar de uma forma boa no site. Apareceu essa oportunidade porque teve um outro negócio que tava rolando lá na TW em Porto Alegre e tinha um usuário desses que tava por lá, a gente entrou em contato e tal. E se a gente fosse pedir toda aquela autorização e fosse passar por toda aquela cadeia de priorização e tal não teria acontecido. A gente viu que isso ia rolar, foi lá, fez e se isso virasse um problema depois a gente pediria desculpa, mas isso apareceu primeiro e foi mega produtivo, deu supercerto. Hoje, se você usar um leitor de tela no Serviços Gov.br ele é um site que de longe se comporta melhor em todos os sites do governo que a gente testou até hoje. Então pra gente é uma coisa supernatural querer feedback.

OLIVIA: E vale uma observação nesse processo, sem querer te interromper já te interrompendo, quando a gente fez o laboratório a gente tinha passado por todos os testes automatizados desse tipo, a gente tinha validado com vários parâmetros e testadores.

De acessibilidade?

OLIVIA: É. E tinha passado. Só que a hora que a gente fez o teste com o usuário a gente descobriu 500 outras coisas.

CARLOS: Foi um caos.

OLIVIA: O cara não conseguiu fazer nada e a partir daí a gente…

CARLOS: E ele sentou com a gente até ele conseguir fazer tudo.

OLIVIA: Virou gente grande.

CARLOS: A gente foi trabalhando junto. Então assim, do nosso lado, claro, a gente sabe que tem muita coisa que dá pra automatizar e validar automaticamente, que tem um mundão de ferramentas boas aí pra garantir que o teu software funciona bem. Mas a gente não… A gente partiu da ideia de que se tem um potencial risco em fazer alguma coisa, se tem um… Nesse caso, por exemplo, se tem um risco de alguém com problemas visuais de não conseguir usar o teu sistema é melhor você ficar sabendo disso três meses antes ou nos primeiros dois meses de projeto do que deixar isso acontecer no final ou até possível a gente não dar bola pra isso. E o que eu vi muito do governo foi uma atitude onde isso só entrava, preocupações desse tipo entravam na pilha de preocupações. E aí aquilo aumentava o medo, aumentava a insegurança, e dificultava ainda mais o caminho de iterar em produção, e experimentar, e dar a cara a tapa, efetivamente, com soluções que não necessariamente teriam muito risco em ser iteradas em público. Claro, você não vai tentar uma estratégia dessas com o Imposto de Renda ou com alguma coisa que é vai ou não vai. Mas tem sistemas e tem sistemas. A gente tá num sistema onde a definição do que é um bom serviço pro cidadão é totalmente subjetiva dependendo do serviço, dependendo do cidadão, dependendo do órgão, dependendo do contexto.

OLIVIA: Dependendo do que é bom.

CARLOS: É, enfim. Tudo ali é subjetivo. O Imposto de Renda pode melhorar se ele for pago antes e se ele for mais fácil de preencher. Mas no nosso caso ali tem muita variável diferente, então a gente não estava lidando só com uma coisa binária, assim, de é bom ou não é, melhorou ou não melhorou.

E aí entra a questão dos feedbacks de estatísticas de uso em produção. Por isso acho que é a importância de entrar em produção tão cedo. Isso tava previsto no TR, imagino que não…

OLIVIA: A gente está fazendo que “não” com a cabeça.

CARLOS: Pro pessoal de casa.

Mas isso demanda um esforço de desenvolvimento, enfim, impacta de alguma maneira no escopo. Como é que foi na hora em que em algum momento vocês tinham que negociar a priorização de alguma coisa nesse sentido ou isso nunca entrou na discussão com eles, isso era só uma entrega a mais?

OLIVIA: A gente embutiu.

CARLOS: A gente embutiu.

OLIVIA: A gente nunca discutiu “ah, a gente não pode priorizar isso agora porque a gente está usando o esforço pra tornar nossas métricas mais corretas. Não. Ficou embutido.

Mas as métricas eles viam e isso ajudava na priorização?

OLIVIA: A gente apresenta.

CARLOS: A gente apresenta, se eles veem é outra história.

OLIVIA: Isso é um ponto. E a outra coisa é, como não é um tema estabelecido, não é uma coisa que eles cobram da gente, é uma coisa que a gente faz, é uma das coisas que entra nesse movimento da gente fazer pra mostrar, pra continuar, é uma das coisas que eu sinto que podia ter sido bem melhor. Mas duas coisas desanimaram a gente de por mais esforço nisso. Uma é a gente escolheu nossas batalhas. Se a gente entrasse em mais essa, pra priorizar isso que não tava previsto lá, que não é uma coisa clara pra eles como uma prioridade, a gente teria perdido a energia pra outras que foram consideradas mais prioritárias contextualmente né, em cada momento desses de negociação. E a outra é que isso é tanto mais legal quanto mais próximo de entrega contínua você tá. Porque o lance é você ver o dado quente ali e no quente você põe a mudança e já vê o resultado em uma semana, duas de ir pra deploy. Se a gente fosse pra produção uma vez por semana já dava mais calor de fazer isso. Mas a gente vai a cada mês, mês e meio. Desanima.

CARLOS: A primeira coisa que pegou quando a gente tava falando disso, foi logo depois da primeira ida pra produção coincidiu mais ou menos com a época da inscrição do Enem. A gente estava coletando métricas, a gente viu que a explosão de acessos e tudo que estava acontecendo ali era muito por causa das inscrições do Enem, a aplicação das inscrições do Enem estava dando problemas, tinha problemas técnicos, e pra muitos usuários estava demorando demais pra carregar. Mas uma das coisas que carregava era o link para o portal de serviços. Era bem comum isso, acontecia milhares de vezes ao dia. Alguém estava esperando carregar, achava que era aquilo mesmo, não ia carregar mais nada, clicava no botão “Serviços” porque achou que a inscrição do Enem estava ali, ia, de alguma maneira, até a inscrição do Enem no portal, achava lá o serviço descrito. A descrição do serviço estava horrível, era tipo duas, três linhas, não tinha links, não tinha ajuda, não tinha…

OLIVIA: Ou duas, três linhas, ou mil e quinhentas linhas, que é o outro lado do horrível.

CARLOS: É o 8 ou 80 que a gente lida hoje. Mas o do Enem era bem curtinho, era pouco informativo e enfim, não ajudava. E assim, a gente viu essa métrica acontecendo no primeiro dia de produção, no primeiro dia que o portal foi pro ar a gente lançou avisos falando: “galera, o Enem está com algum problema porque tem muito acesso, tem muito feedback vindo, tem muita gente fazendo voltas na navegação”. Então a pessoa clicava no portal do Enem, clicava no Serviços, navegava até o Enem dentro do portal, clicava de novo, ia pro portal de Serviços.

OLIVIA: Buscava “Inscrição Enem”.

CARLOS: A pessoa ficava nesse loop, não conseguia resolver o problema e não parava de clicar até ela achar ou desistir. A maioria desistia.

OLIVIA: Ou desistir, ou achar ou colocar uma mensagem mal-educada ali na caixinha de feedback.

CARLOS: É. Se a gente tivesse… A gente tinha feedback suficiente pra saber que isso era um problema em quatro horas de site no ar. Se a gente soubesse que a gente podia ir pra produção com uma versão nova do conteúdo, uma coisa mais bem descrita, se a gente tivesse acesso a quem pudesse descrever o serviço do Enem melhor na hora e ir pra produção com aquilo, a gente tinha ajudado e economizado não sei quantas mil horas e frustrado não sei quantos milhares de brasileiros, deixado de frustrar não sei quantos milhares de brasileiros. Quando isso não aconteceu e a gente viu que não tinha muito bem um plano pra fazer com que isso parasse de ser um problema, aí a coisa deu uma esfriada. Então do nosso lado também a gente perdeu um pouco do pique e foi buscar outras brigas. Mas especialmente nesse lance… mas eu vejo isso como uma coisa mais pessoal. Quando eu vi que eu tava de mãos atadas, que eu não podia ajudar a galera que tava deixando feedback pra gente, super mal-educado às vezes, ou então às vezes suplicando pra conseguir botar o filho no diacho do Enem de tudo quanto é jeito. Então tinha coisas assim “já estou tentando faz dois dias”. E você sabe que os pais não estão tentando faz dois dias naquela coisa meio de vez em quando tentava, eles estavam tentando dois dias…

OLIVIA: Ou os próprios estudantes, estamos falando de estudantes de 18 anos.

CARLOS: É, os pais e/ou todo mundo que tava tentando entrar.

Como os gestores receberam esse feedback?

OLIVIA: É culpa do MEC.

CARLOS: Receberam com os ombros.

OLIVIA: É, tipo, estamos aqui no Ministério do Planejamento. O pessoal do MEC já sabe que está rolando. É isso. E o pessoal do MEC estava sabendo que estava rolando e estava dando os pulos lá pra tentar resolver o que estava rolando. É isso.

CARLOS: Só que eles estavam tentando resolver o que estava rolando no site da própria inscrição do Enem. Isso não tirou, não ajudou em nada a descrição do serviço no Portal dos Serviços que estava ruim.

OLIVIA: Mas a principal causa das pessoas chegarem na página do Portal do Enem era porque direto no site de inscrição não estava funcionando. Então a partir do momento que ela se frustrava lá ela tentava achar algum jeito e parava lá na descrição pífia que tinha no Portal e fazia esse loop que o Vilela descreveu, angustiante.

CARLOS: A gente viu usuário em cima de usuário depois de usuário depois de usuário durante muito tempo que começava numa experiência frustrante e em cada passo que a pessoa tomava ela se frustrava mais até o ponto onde era quase certeza que ela ia deixar um feedback ali. E o nosso formulário de opinião no começo era super, é ainda, totalmente aberto. É “O que você achou deste site”, na verdade. Só que ninguém lê essa parte, eles viram uma caixa de texto onde eles podiam descarregar toda a raiva de não conseguir fazer o que eles estavam fazendo.

ÍNDICE

Anúncios