ANEXO E – Entrevista com Gustavo Maultasch

Entrevista com Gustavo Maultasch, Subchefe da Divisão de Informática do Itamaraty e coordenador da Área de Desenvolvimento

PARTE 1

Quais foram as motivações pra vocês buscarem um modelo diferente de contratação?

Eu estava aqui, eu peguei o modelo anterior também, de posto de trabalho. E o modelo anterior… Aliás, o modelo anterior o pessoal chama de hora-homem. “Ah, antigamente era hora-homem.” Antigamente não era hora-homem. Hora-homem é diferente de posto de trabalho. Quer que eu já fale sobre isso agora, ou não? Ou entre nessa digressão agora?

Não, entra, entra. Que é isso. A motivação.

É o seguinte. As pessoas falam assim “ah, antigamente era hora-homem”. Cara, uma coisa é hora-homem, outra coisa é hora-cadeira ou como, você me desculpe a expressão, mas como as pessoas chamam na TI, hora-bunda. Hora-bunda é o seguinte: eu te pago tantos reais por hora pra você ficar aqui, independentemente do que você faça ou não. Isso é posto de trabalho, hora-cadeira, hora-bunda, é isso. Hora-homem não é isso. Hora-homem é uma métrica de trabalho que tem alguma objetividade. Então eu chego assim: “Vem cá, eu preciso que você pinte essa parede. Quantas horas-homem isso custa?””‘Ah, isso custa 2 hh.” Isso não quer dizer que isso vai ser feito em duas horas. Você pode ser um exímio pintor e fazer em uma. Você pode botar teu estagiário e fazer em quatro. Isso é uma métrica mais ou menos que tenta alguma objetividade. Antigamente não tinha isso. Antigamente não tinha métrica nenhuma, antigamente era posto de trabalho. Eu peguei essa época de posto de trabalho e peguei o contrato com a primeira empresa. A primeira empresa que veio aqui foi horrível. Horrível, péssima, deu tudo errado. Eles vieram aqui pra implantar, eles ganharam uma licitação, vieram implantar um modelo de fábrica remota, inclusive, que na época se aceitou. Eu já na época fui contrário a isso, mas não importa. Mas, enfim, só para você… Enfim, eu acho importante para o meu currículo pessoal eu nunca ter acreditado nisso. Mas enfim. Na época se acreditou nesse modelo de fábrica e aí o desenvolvimento foi todo remoto, então eles só teriam uma equipe de requisito aqui. Imagina isso. Não ia ter desenvolvedor nenhum aqui nem pra manutenção, nem pra sustentação de software, que, pô, software legado… Tem muito software legado por exemplo que nunca se terminou de você fazer a área administrativa dele, por exemplo. Então qualquer coisa que você precise subir, você precisa… tem coisa que tá harded coded, pô, que foi feita 10 anos atrás. Então, pô, você não ter esse cara aqui… Você acha que um cara lá de longe vai entender isso? E como é que se dá o deploy disso? O cara vai mandar um zip por email? Você tem que ter uma… Eu nem acho que fábrica remota não funcione. Eu só acho que você tenha que ter uma estrutura de comunicação e de automação tão gigantesca que é impossível fazer funcionar. Só quem faz funcionar é 37signals, sei lá… Olha, nem grandes empresas, o Yahoo, por exemplo, tinha trabalho remoto e voltou atrás. Grandes empresas aí como Netflix, por exemplo, também são 100% presenciais. Tem várias empresas que evitam trabalho remoto por causa disso, porque é difícil pra caramba. Não é porque não funciona a priori, é porque é difícil fazer funcionar. Mas enfim, fizeram isso aqui e tal. Com ponto de função também, que também deu supererrado, e com RUP. Então essa combinação de fábrica, ponto de função e RUP é a receita do fracasso.

Por quê?

Vou falar. Eu só quero fazer uma observação antes pra ficar claro. Eu, de toda maneira, eu acho que… É porque assim, aqui o nosso contrato é pequeno e tal, mas o que eu ouço falar do que rolava de outros órgãos em termos de corrupção e de desperdício de dinheiro, eu não acho que o modelo tenha sido ruim. Eu acho que ele teve o seu momento, eu acho que ele foi bom. Eu escuto histórias, por exemplo, você vai conhecer melhor que eu isso, mas eu escuto histórias, por exemplo, de gente que tinha três andares de desenvolvedor sem nenhum accountability, sem nenhuma prestação de… Sem nada, sem saber o que os caras estavam produzindo. Então assim, aí você põe gasto de dinheiro público, você põe corrupção, você põe tudo aí no meio. Então assim, se alguém me perguntasse assim: “você acha que esse modelo nunca deveria ter sido implementado?” eu diria que não, eu acho que deveria ser sim. Eu só acho que ele teve seu momento e talvez ele tenha durado um pouco demais. Mas lá em 2008, ele teve o seu momento sim. Se hoje a gente pensa muito em métrica, em resultado e tal é por causa daquele modelo. Eu só acho que ele foi uma primeira formulação que de repente foi seguido à risca demais, por tempo demais. Mas ele teve o seu valor naquele momento.

Bom, mas aí o que acontece. Por que que esse modelo não funciona? Bom, primeiro porque… Eu falei de fábrica, de RUP e de ponto de função. Bom, vamos lá, em ordem. Vou começar pelo RUP. Eu acho que assim: se você está fazendo software em que a segurança e a rastreabilidade de requisito são mais importantes do que qualquer outra coisa, inclusive do que ele funcionar, eu acho que o RUP é bom. Então, por exemplo, software que vai rodar num avião, software que vai rodar numa missão espacial. Pô, tu não quer que dê um bug lá que trave o oxigênio, sacou? Então assim, nesse tipo de software, com o qual eu nunca nem trabalhei, nem sei como fazer, eu acho que, pô, você quer rastreabilidade total. Então se você está lá no desenvolvimento e “ih! Temos que mudar uma funcionalidade aqui, vamos fazer um scrum aqui pra resolver o problema do oxigênio”, não, cara, não. Você vai propor uma mudança, com um processo formal de gerenciamento de mudança, que vai levar um mês, que a gente vai refazer algoritmo, que está numa linguagem natural qualquer, que não sei o que, que depois vai passar pelo pessoal de não sei o que, vai passar pelo algoritmo, vai passar pelo teste, vai passar pelo não sei o que, vai passar pelo… até a gente aprovar essa mudança, até você implementar. Então eu acho que todo esse controle ele é importante em algum tipo de software. No caso da maior parte da administração pública, isso aí é exagerado. Então o RUP pra mim… Ele não… o que ele tem de valor, que é essa rastreabilidade e esse controle todo, não são necessários na administração pública. Então primeiro que eu não tenho software, aqui mesmo, e em vários entes, a gente não tem software tão crítico a esse ponto, sabe, que você causa a morte de 150 pessoas se o seu software falhar. Você não tem isso, assim, não de imediato, né. Então geralmente quando tem isso você compra. Sei lá, então o software que roda no avião da presidência, foi a presidência que comprou o software junto com o avião. Então assim, não é como se a gente estivesse desenvolvido isso, a gente não tem capacidade pra isso. Então, com isso, o RUP vira um processo totalmente lento e sem valor porque você não precisa daquilo que ele tem de valor. Então o que acontecia aqui com a fábrica: a gente ficava seis meses coletando requisito. O próprio nome que se usa: coletar requisito. Pô, se você for ver uma metodologia ágil, você nem fala em “coletar requisito”, requisito não é uma coisa que dá nas árvores e você vai coletando. O requisito é uma coisa que ou você elicita ou, numa perspectiva mais ágil, você constrói o requisito. Porque o cliente está te dando um problema, a solução você que vai dar né, junto com o cara e tal. Então assim, se você começar a analisar isso, a gente tinha, assim… a gente ficava seis meses, ou mais, às vezes um ano coletando requisito. Aí eles vinham e entregavam aquele calhamaço de papel assim, “pá, tá aqui os requisitos. Agora é só homologar”. Aí você tinha que ler página por página, alguns pediam que você rubricasse cada página. Olha a loucura: você está numa área de TI rubricando página de requisito de software de uma coisa que depois vai evitar a assinatura de um outro sistema, né, pra automatizar alguma coisa. Então era um contrassenso. E aí você ficava homologando isso, e quando você fosse construir isso, se os programadores fossem bons, que também não eram, já vou falar desse problema, mas se eles fossem bons, eles implementariam um negócio que já estava totalmente ultrapassado, porque um ano depois os requisitos mudaram. O processo mudou, as necessidades mudaram. E aqui no Itamaraty tem um problema maior em relação a isso que é o seguinte: as pessoas aqui não ficam no mesmo posto de trabalho, porque as carreiras aqui exigem que você vá para outros países. Então você tem que ir pra um consulado, você tem que ir pra uma embaixada. Então qualquer projeto que demore mais de dois anos, três anos, você pega vários chefes diferentes. Então vem um chefe novo, que às vezes tinha uma visão completamente diferente do sistema. “Vai homologar isso? Mas não sei nem quem pediu esse sistema”, porque é um chefe novo. Ou pior, o cara não vê a necessidade do projeto. “Não, não precisa de sistema”. E pior, às vezes ele estava certo. Mas enfim. Então você tinha, cara, a fábrica, se não combina em lugar nenhum, combina menos num lugar que você tem rotatividade de pessoal. Então se pensar um projeto de três anos. Pô, se você tem a equipe mudando duas, três vezes ao longo de três anos…

Então o modelo do RUP não funciona, e o modelo do ágil aí, cara, você via entrar no… Eu acho que tem duas coisas que serviram de inspiração pra gente e que a gente cita no nosso TR: é o ágil e o movimento do craftsmanship, do software artesanal e tal. Aí não adianta ficar repetindo, mas toda aquela visão do software artesanal, como um processo não linear, como um processo não fordista, que você não consegue dividir em etapas tão claras assim, enfim, como um trabalho intelectual que envolve solução de problema, enfim, como um trabalho que envolve muito detalhe que você não consegue especificar previamente, não totalmente. Ou consegue até a um custo muito alto, né, que é o caso do RUP. Então assim, por causa de tudo isso a gente viu que o negócio não, enfim, que o RUP não funcionava.

Aí o livro do McGreen… Esses dois livros foram grandes inspirações minhas aqui pra isso. Esse aqui a gente usou como base no nosso TR, do Rubin, o livro do Rubin e do Scrum. No nosso TR a gente fez uma versão simplificada do Scrum, a gente pegou o Scrum e simplificou mais ainda. E o do McGreen de software craftsmanship.

Falei do RUP primeiro… Ah, o problema da fábrica. Bom, aí o lance da fábrica é que se você assume que você tem… Então o que acontece, vamos lá. Qual o problema do RUP? O RUP ele divide em fases uma coisa que não é divisível e na realidade não se divide em fases. Então assim: “ah, vamos coletar requisitos”. Se você entende que o requisito é construído e, pior, se você entende que você precisa construir a coisa muitas vezes para saber se ela funciona ou não… é isso que a engenharia faz, “pô, quero fazer um avião. eu vou fazer um avião miniatura, ou um avião dentro de um túnel de vento e vou construir e vou ver se funciona, depois eu vou ver que não funciona”. Então assim, é tão óbvio isso. E com software é a mesma coisa. Tem coisa que eu preciso construir na tela pra ver primeiro, pra ver se me atende e só depois de construído é que eu vejo. Então daí a ideia do scrum de trabalhar com ciclos. Então é claro que se você pensar dentro de uma sprint você tem um micro RUP ali, você está levantando requisito… forçando a barra eu estou falando, você tem, só que a diferença é que você faz ciclos mais rápidos e a tua perspectiva é diferente. Então assim: eu não peço, por exemplo, a gente não pede mais pro usuário assinar, homologar requisito, isso não existe, cara. Se no final do processo, isso é uma diferença muito grande também, porque se no final do processo o… Aliás, deixa eu ver, eu acho que eu anotei alguma coisa sobre isso aqui… Foi mal, mas tem que lembrar pra ver onde é que está isso, eu tinha anotado alguma coisa sobre isso. Que é o seguinte: existe uma divisão de responsabilidade, que é o seguinte (eu continuo o mesmo tema, tá, não estou fugindo do tema, que é o da fábrica), que é o seguinte, pensa só: se você é gestor e você não está tão interessado em fazer o seu trabalho, “eu estou aqui, de boa, curtindo DAS e tal”. Se você pensar nisso… O usuário vai pedir um sistema. Você só serve como proxy, de modem, modulador, demodulador. O cara da empresa vai falar: “preciso de uma reunião pra coletar requisito”. Beleza, vamos lá. O cara dá os requisitos, né, dá entre aspas. Volta pro cara. O cara entrega o requisito, aí eu redireciono de volta pro cara pra homologar. Aprova o requisito, agora eu quero o sistema. Direciono de volta. O gestor fica só de proxy, entre a área de negócio e a empresa. E aí o gestor ficando só de proxy a culpa nunca é do gestor. Se no final der tudo errado, ou a área de negócio homologou requisito que não devia ou a empresa executou uma coisa que não estava no requisito. Então a fábrica, o irônico dessa história toda é que ela nunca estoura na mão de quem está contratando. O problema da fábrica é sempre, você sempre consegue botar a culpa em alguém. No caso do que a gente está fazendo aqui agora, a gente faz uma divisão de responsabilidade, a gente assume o risco junto. Então o que acontece, se no final da sprint…

Deixa eu só te interromper, antes de entrar como é que é agora, vamos continuar ainda no… Você pulou da fábrica, do RUP, e aí de volta…

Tá. Só pra terminar a fábrica, que é o seguinte. Se você entender como um negócio, desenvolvimento de software como um processo artesanal, que precisa de muita comunicação, que você não consegue definir todos os detalhes de antemão, etc., você não tem como ter uma fábrica remota também. Aí mata a opção de fábrica remota, salvo naquelas casos de alta automação que a gente não tem. Então, por isso, também que a gente matou o conceito de fábrica. Inclusive o pessoal fala licitação de fábrica, a gente até evita falar de fábrica. Tô evitando usar o nome fábrica. Teve um pessoal que veio aqui outro dia, a gente comentou, “ah, vocês chamam de quê, então?” “sei lá, chama de ateliê de software, chama de qualquer coisa, mas fábrica não é, entendeu”. Não é mais fábrica assim. Porque não é… processo não é fabril, pô. O software não é um processo… Assim, você monta uma fábrica de carro, você está fazendo mil carros iguais. Uma fábrica de software não está fazendo mil softwares iguais. A parte fabril, na verdade, a única parte fabril do processo quem faz é o compilador, que é transformar código-fonte em binário, isso é fabril. Só que isso já está automatizado. Então a única parte realmente fabril do negócio é o compilador. E o resto? O resto é o papel do engenheiro que inventou o carro. Então nós somos aqui o laboratório de inovação duma fábrica, e não a fábrica em si. A fábrica em si é o compilador, e ele está fazendo seu trabalho bem.

Aí o terceiro ponto é a métrica. Então falei de fábrica, métrica e RUP. Depois eu lembro de falar o que que a gente fez ao contrário aqui. Pô, depois tu me passaria essa gravação? Que aí eu termino minhas anotações aqui. E aí é o seguinte. Não, porque o pessoal do Planejamento está querendo fazer um seminário sobre métrica, então de repente o que eu falar aqui pode me ajudar a eu mesmo falar alguma coisa lá.

Porque outra coisa que o pessoal fala assim: “ah, podemos fazer então, vamos fazer então um

um ágil e tal, só que com ponto de função?”. Tem gente fazendo, você tem visto o pessoal fazendo isso?

Tem, eles fizeram um guia e tudo…

É, ágil ponto de… Cara, o ponto de função. Qual o problema do ponto de função? Eu acho que é um outro problema. O ágil já melhora alguma coisa, né. Se você fizer uma fábrica presencial versus uma remota já melhora também. Mas o problema do ponto de função é outro. O problema que o ponto de função traz é que o ponto de função ele, como é sabido, né, ele não mede esforço. E quando você não tem uma métrica de esforço, você não tem como exigir qualidade. Ponto. Eu só tenho como exigir aquilo que a métrica mede, entendeu? Então o que acontece. Se a métrica mede a confecção de um CRUD, sei lá, um CRUD aí no… (você sabe esse nome CRUD, né? creative…) Se você tem uma.. um CRUD aí em ponto de função, vai dar o que, uns 20, 25 pontos de função mais ou menos. Aí, pô, eu descobri que no CRUD, sei lá, tem a grid lá de resultado e eu posso abrir algum na grid. Mas eu descobri o seguinte, depois que eu visualizo um item, que eu dou um read, pô, seria muito maneiro sabe o quê? Que em vez de eu ter que voltar pra grid pra ver o próximo, que naquela tela de read eu tivesse uma função de botão pro próximo, ou que eu tivesse alguma coisa assim, um item de navegação. Ou que aquele botão, melhor exemplo ainda, que aquele botão quando eu passasse o mouse em cima ele muda de cor, entendeu? Isso não é mensurável em ponto de função. Mas isso é um item que, pô, em termos de usabilidade e UX, user experience, pô, isso é fundamental, cara. Cara, UX. Isso que eu acho que eu não entendo assim, UX é 99% da qualidade de um software. Estou exagerando, botar 90. É porque assim, os outros 10% tem a ver com a qualidade da implementação e tal, mas esse é o mínimo que se espera de um programador bom. Então assim, se o cara não estiver dando uma de 171 pra cima de você, usando um banco de dados fajuto, uma modelagem tosca, apressada, se o cara tiver feito o mínimo trabalho direito, o grande diferencial do software é a experiência do usuário, pô. Então assim, né, qual a vantagem do Gmail pro Yahoo, pro não sei o quê, todos eles checam email e mandam email. Mas assim, você tem a experiência do usuário. Então, pô, você não conseguir medir isso e, pior, não conseguir remunerar a empresa por isso tá errado, cara. Pô, você tem que poder remunerar por isso. E aí o segundo fator, então são dois fatores, um é esse da qualidade, né, da métrica, de você não conseguir remunerar pela qualidade…

Da experiência de uso.

Do UX. E o outro fator é que é o seguinte: quando você não tem noção clara do que você está pagando, você não tem como melhorar sua gestão. Então por exemplo. Eu executei, sei lá, 200 pontos de função essa semana, esse mês, mais ou menos, é. Uns 400 pontos de função no mês, sei lá. Executei 400 pontos de função esse mês. Quanto que eu gastei de front-end e quanto que eu gastei de back-end? O ponto de função não te dá isso, entendeu. Então quanto que eu gastei de HTML? Quanto eu gastei de design? Quanto, pô, não dá isso. Então como é que eu sei, cara? Como é que eu sei se eu estou usando, se eu devia de repente, se eu preciso de mais gente no front-end, como é que eu sei onde está o gargalo? Como é que eu sei? Então, isso pra mim é outra, cara, eu acho, cara, é impossível você gerenciar uma coisa se você não tem visibilidade dessa coisa. E aí o que o pessoal vai dizer em relação a isso. O que o pessoal vai dizer em relação a isso. O pessoal vai dizer “Ah, não, mas você não tem que gerenciar, você está contratando o resultado, você está contratando…” Já ouviu essa? Você tem que… É, você já deve ter ouvido. Pô, não, você está contratando resultado. Que nem o pessoal fala: “não, eu não vou mais contratar TI, vou contratar o software em funcionamento”. Até hoje eu não entendi, aquelas coisas… Acho maneira como ideia, só que a realidade não funciona assim. A realidade é que a maior parte das empresas grandes, e aí entra vários projetos que, conversas paralelas, algumas das quais eu sou até parte, sobre mudar a forma de contratação do governo para permitir por exemplo startup participar de licitação, uma série de coisas, mas isso é outro assunto. É que o grande, o grande problema é que assim, a maior parte das empresas elas vão te entregar o pior possível aceitável, contratualmente aceitável. O pior possível contratualmente aceitável, entendeu. É o PPCA – Pior Possível Contratualmente Aceitável. Elas vão fazer pra isso, cara. Então o que acontece. Se você chegar e não disser “não, olha, cara, eu sei…”, é o caso lá da…

PARTE 2

Então o que acontece, o lance que a gente parou, né, falando do pior possível. Então se você não, se você, como você não consegue, é interessante isso, da mesma forma que você quando está fazendo um sistema você não consegue prever em papel tudo que você quer que o sistema faça depois, né, da mesma maneira você não consegue prever numa licitação, no papel da licitação tudo que você quer que a empresa faça depois, ao longo de cinco anos, que é mais ou menos o tempo que você espera que o contrato vai durar, né, com as renovações e tal. Então, se você colocar só o resultado, o cara vai achar uma forma de entregar uma coisa tosca, mas que atenda à letra da lei, à letra do edital. Então a única forma de você fugir disso é você se, vamos dizer, é você entrar um pouco no detalhe do contrato. É você falar um pouco de, pô, quantas pessoas mais ou menos eu preciso, que eu quero que as pessoas fiquem aqui, né, é você, pô…

Falar um pouco do processo.

Falar um pouco, exatamente, falar o tipo… Porque em tese você poderia falar assim, a gente até conversou muito isso aqui, isso foi uma conversa interessante que a gente teve. Por que eu preciso colocar metodologia de software no edital? Em tese eu não preciso, pô. Eu quero contratar uma empresa de software que me entregue software de qualidade. Por que eu preciso dizer qual metodologia eu vou usar, seja ela RUP, seja ágil, seja… Em tese eu não precisaria. Precisaria dizer alguma coisa sobre o meu cronograma de pagamento, né, mais ou menos, né, mas a metodologia de software em si eu não precisaria dizer, se eu vou trabalhar com documento de visão, se eu vou trabalhar com caso de uso ou história de usuário ou cenário ou não sei o quê. Em tese eu não precisaria dizer isso. Só que se você não diz a empresa vai tentar fazer o pior possível pra te atender e ainda assim conseguir se livrar e ganhar alguma, e vamos dizer, e conseguir levar o contrato na barriga, né. E parte desse problema também é que é muito, e aí entra um outro lado do problema, talvez fosse até um quarto item, enfim (isso que dá continuar a conversa no dia seguinte), que é o seguinte, que é muito custoso para o administrador, para o gestor no governo, punir empresa. Então assim, você dá uma advertência, agora aqui, depois quando a gente for falar aqui a gente leva isso muito a sério. Ó, por exemplo, mesmo o contrato atual, que está funcionando muito bem, cara, com todos os, eu já devo ter sei lá 7, 8 anos de TI em governo, sei lá, por aí, mais ou menos, cara, eu nunca vi um contrato funcionar tão bem quanto esse que a gente tem aqui. Está funcionando muito bem e depois eu vou te mostrar aqui os produtos pra você ver a qualidade do software. Está funcionando muito bem, mas ainda assim, cara, em seis meses eles já levaram três advertências. Porque assim, você tem que, é como aquela muretinha na estrada. Saiu um pouco você já tem que advertir. Ainda que não é saiu e caiu na ribanceira, não, é só saiu um pouquinho, mas você já adverte que aí o cara já “opa, esses caras são sérios”. Mas mesmo assim, pô, advertência você tem que parar, escrever, você perde hora. Aí às vezes você quer fazer uma coisa e você não sabe, aí você tem que ir na Jurídica e não sei o que. Pô, aí você já viu o tempo que você… E olha que aqui a gente tem uma área administrativa aqui muito boa, que ajuda a gente, os caras sabem tanto quanto a Jurídica em muitas coisas. Pô, aí se você for dar uma punição mais grave, uma multa, a mesma coisa. E aí se você for dar uma punição grave mesmo, de mandar a empresa embora, aí sim é que você tem que fazer um processo administrativo, não sei o quê. Aí você tem que fazer um emergencial, de repente você vai mandar a empresa embora e não vai ter nenhuma, aí você vai ter que… Então, cara, aí vira o caos. Então, quer ver, aí vira o caos. Então assim, a empresa, ela joga com essa leniência também do funcionário. Ela sabe que pra você é muito custoso também mandar a empresa embora. Ninguém nunca manda. Então você somando tudo isso, se você fizer uma licitação só pelo resultado os caras vão explorar demais as brechas e você não vai conseguir o que você quer. Então você tem que meio assim “tá, eu sei que em tese eu poderia só contratar o resultado, não preciso dizer quantas pessoas eu preciso pra esse resultado, porque quantas pessoas eu preciso para um determinado resultado é corolário do resultado que eu preciso, correto?” Agora, as empresas não vão ver assim, sacou. Elas vão ver assim: pô, quantos estagiários eu posso colocar aqui, quantos… vão tentar, vamos dizer, abusar o sistema ao máximo. Então acho que esse é o panorama, acho que já terminei.

Esse é o panorama das motivações. Quando vocês foram pensar essa nova licitação, como vocês procuraram encaminhar cada uma dessas coisas ou quais eram os resultados esperados?

Cara, a gente começou… A gente começou, cara, assim. Eu sempre trabalhei com ágil, né.

Eu na verdade eu fui conhecer RUP por causa da IN 4. Aí que eu fui aprender, eu sempre trabalhei, no setor privado também. Então pra mim era muito claro que isso era a forma que funcionava. E, na época do posto de trabalho aqui, eu fui gerente de projeto assim, barra PO, mais PO do que gerente de projeto na verdade, de um sistema financeiro que a gente fez aqui que deu muito certo e a gente tocou todo em Kanban. Então, a gente aqui já tinha experiência. Aí veio a IN 4, aí matou o que já gente já sabia. Isso foi muito forte também. Então a gente já tinha aqui dentro a receita de uma coisa que funcionava legal, matamos por causa do processo de fábrica, com ponto de função e tal, não sei o quê. E aí, enfim, agora estamos resgatando. Resgatar o ágil e repensar o ágil e tal pra gente não foi uma grande, não foi como se fosse uma inovação enorme, foi meio que natural. Ó, não tá funcionando, vamos redebater o ágil? Vamos. Então assim, em termos daqueles pontos que a gente conversou. Então por exemplo. Em relação à fábrica, a gente contrapôs a ideia do craftsmanship, né, do ateliê e tal. E aí, cara, isso, envolve uma série de coisas que estão refletidas no nosso edital. Uma coisa central, isso a gente conversou com muita clareza aqui na época do debate, a gente, a equipe de ATIs aqui. Pra você ter uma ideia, cara, o processo de confecção do TR a gente levou, cara, sem brincadeira, uns, talvez uns 8 meses. Mas não 8 meses porque a gente não fez nada, 8 meses trabalhando mesmo. Ó, vamos debater isso aqui e tal, vamos estudar isso, aí lê o livro do scrum e tal, não sei o quê, que que a gente pode, pô, isso aqui não está legal, vamos marcar uma reunião. Aí a gente fez reunião com TCU, fomos lá Sert, aí fizemos reunião com o MPOG, com o pessoal lá que está fazendo, tem um pessoal fazendo, que fez o guia ágil da administração. Eles vieram aqui, a gente conversou com eles. Então assim a gente fez, foi um trabalho longo aí. E muita coisa depois a gente tirou. Putz, isso aqui a gente pegou pesado aqui, vamos tirar isso aqui. Enfim, a gente, foi um trabalho muito minucioso eu diria. Então assim, à ideia de fábrica a gente contrapôs a ideia do ateliê. O que que isso envolveu no nosso TR? Quando você está trabalhando com esse modelo do craftsmanship e você sai do fordismo e tal, você entende várias coisas. Primeiro: eu preciso ter caras bons. Não dá pra ter um sênior com 15 estagiários que nem as fábricas aí. Então eu preciso de cara bom e pra ter cara bom eu preciso também ter salário bom. Então isso, e isso não só pro cara vir pra cá, mas pra eu manter o cara aqui. E além de salário bom, eu preciso ter um ambiente tecnológico bom. Né, porque o cara que gosta do assunto, ninguém quer trabalhar corrigindo bug de Java JBoss versão 0.9, nem sei qual que está. As pessoas querem, pô, trabalhar com coisa nova, empolgante e tal. Então isso foi uma coisa que a gente também repensou isso. Deixa eu começar pelo lado tecnológico, mas tem tudo a ver. Então, por exemplo. Bom, isso tem a ver um pouco com o que eu te falei de o MRE voltar a ser um centro de prospecção tecnológica e tal. Então uma coisa que a gente reparou aqui é que, pô, a gente faz, a gente desenvolve, não só aqui, o governo federal como um todo, a gente faz aplicação web como se fazia 10 anos atrás, pré-Ajax ou mais até. Ajax é de 2004. Nossas aplicações são muito velhas. Então, claro, tem umas exceções aí dos órgãos aí, o INEP, o Banco Central, que parece que são mais modernas. Mas a gente aqui estava muito defasado, cara. Então a gente falou: a gente tem que começar a se atualizar, trabalhar com front-end mais rico, né, com Angular que seja, com Falcon, com React, não sei, essas coisas novas aí. Trabalhar com uma concepção de usabilidade mais nova. Pô, as aplicações hoje, a maioria, por exemplo, celular tá indo pro material design, né, do Google, que é o que a gente está usando aqui agora, depois eu até te mostro aqui. Então, pô, a gente tem essa concepção nova de experiência do usuário que, como eu comentei ontem, é importante pra caramba. Então, pô, a gente tem que estar com isso também. E aí isso envolve também bibliotecas novas de Javascript que implementam os componentes e tal. Então a gente, pô, traçou um panorama, estamos usando NoSQL, a gente está com um projeto em Mongo aqui, um dos nossos projetos.

Como isso se refere no TR concretamente?

Cara, no TR a gente tem uma parte lá de tecnologias utilizadas. Então a gente lista tudo isso. Então isso, assim, aquele negócio, né. Tem duas teorias sobre como isso funciona. A empresa vai ler isso e vai pensar: caramba, pô, esses caras estão com uma vanguarda tecnológica maneira, a gente precisa abrir pra uns profissionais mais atualizados, mais interessados e tal. Ou até, o que seria a interpretação mais correta: cara, esses caras estão com tanta tecnologia nova que não adianta eu achar os caras que sabem, eu tenho que achar aqueles profissionais versáteis que sabem aprender sozinhos, né, que é o profissional de TI bom, né, e que vai dar conta de chegar lá e tocar qualquer coisa que rolar lá, porque é tanta coisa que eu não vou dar conta. Se você for ver a lista de tecnologia que a gente coloca lá, é um negócio gigante.

Mas vocês colocam como pré-requisito?

Colocamos. Não como pré-requisito que o cara saiba, a gente coloca isso como tecnologias utilizadas no Ministério. Tem outra teoria também, que é sempre muitos caras vão ler isso e falar “ah, tá. dane-se, vamos fazer o nosso, esquece”, ignorar. Então você nunca sabe o que a empresa vai pensar, mas pelo menos a gente tenta. Você tem que cercar por vários lados. E aí o cara folheando… Vamos dizer que os licitantes leiam página sim, página não, o teu TR inteiro, cara, você tem que cercar. Estou te falando só sobre o ateliê, as várias formas como a gente cercou isso. Então primeiro essa coisa tecnológica. Segunda forma foi o perfil profissional. A gente exigiu… Por exemplo, se você não está trabalhando no RUP e na linha fordista e você está trabalhando no ágil, você não pode ter divisão disciplinar dentro da equipe. Você não pode ter assim: ah, eu sou analista de requisito. Ah, eu só faço modelo. Eu sou só back-end. Eu sou só front-end. Eu sou só teste.” Cara, isso não vai funcionar. Então o que você tem que ter são… Nos Estados Unidos o pessoal chama isso de “full stack”, né, full stack developer, né, o cara que sabe a pilha toda. Então assim, desde… A gente já teve caso aqui de profissional, por exemplo, no passado, que falou “ah, a aplicação não está funcionando. é problema do servidor web”. Aí você dá um telnet lá na porta 80 ou o que seja, e você vê, não o servidor web parece que está no ar. Pode até ser alguma coisa com o servidor web, mas não é que o servidor web está fora. Mas o cara é “ah, eu sou desenvolvedor. Telnet pra mim, conectar no servidor”… O setor se especializou tanto, já há décadas, que é impossível alguém saber de tudo, saber de todas as tecnologias. Claro, é óbvio, existem 20 linguagens ativas aí só na Esplanada, não sei. É impossível todo mundo saber de tudo. Mas o cara tem que ter uma noção do processo inteiro, senão ele não consegue nem debugar coisa. Então no nosso edital está lá que o perfil do cara tem ser full stack. E a gente lista o perfil do cara, desde análise de negócio até passando pela modelagem de…Por exemplo, como é que um cara pode fazer um modelo de dados sem ser um cara bom de requisito e de entender negócio? Correto? É impossível. Então se o cara, aí como é que o cara pode ser bom de programar sem saber fazer modelagem? Por que de repente o cara vai programar um negócio e vê, opa, peraí, essa programação aqui está muito complexa. Sabe por que está complexa? Porque a modelagem está errada. Pô, o cara tem que ajeitar. Entendeu? Então o cara tem que ter uma visão do todo. Eu vejo assim, o que eu vejo é que tem tido uma divisão bem grande entre back-end e front-end. Tudo bem, aí eu até entendo mas é mais uma divisão de linguagem, que o back-end está mais C#, PHP e front-end é mais Javascript e tal, mas eu vejo que tem essa divisão hoje em programação web. Mas em termos de paradigma o cara entende bem, porque você tem assim, é que você tem um MVC fractal, né, você tem MVC lá no back-end e dentro do front-end você tem um mini MVC ali, mas os caras se viram. Então assim, o cara não precisa ser expert em tudo, mas o cara vai ter uma noção. E eu tenho certeza que se você pegar os nossos caras aqui, que são muito bons de back-end ainda que eles não saibam Angular, se você der duas semanas pro cara, o cara aprende. Então esse é o perfil que a gente estava buscando, isso a gente colocou lá. Pra poder garantir isso a gente colocou uma outra medida no TR que é a diligência prévia de capacidade (DPC), que é o seguinte. Todo profissional apontado pela empresa pra trabalhar aqui tem que passar por uma diligência com a gente e lá tem o formato da diligência. A diligência é: ele tem que apresentar um case profissional da vida dele. Falar problema negocial, o que que ele fez, como que ele resolveu, a programação e tal, enfim. No nosso TR a gente dividiu em dois cargos de desenvolvimento: analista e analista programador. Analista hífen programador. Por que que a gente fez isso? A gente não (parece que eu estou saindo, mas eu estou no mesmo fio aqui) Porque o seguinte. A gente ficou com receio, pra mim tudo é analista, tá? Analista de sistemas, né, é como se chamava antigamente. Analista de sistemas. Só que a gente ficou com medo do seguinte: cara, será que se a gente botar só analista vai ter empresa sem noção que vai achar que a gente só está contratando a análise e não programação? Entendeu? As pessoas: “ué, vocês só queriam análise.” Então a gente pensou isso. Então a gente pensou: então vamos botar analista programador? Aí a gente pensou: então vamos botar só programador? Não, aí se a gente botar só programador vão pensar que o cara não precisa saber análise. Então a gente fez analista e analista programador. Então tem uma pequena diferença na diligência, mas que na prática não está se dando essa diferença, que é pro analista programador obrigatoriamente na diligência ele tem que apresentar código que ele tenha escrito. Então assim, a gente faz uma diligência, quero ver o código do cara. Isso é uma coisa, foi uma coisa em relação à qual assim a gente teve muito receio de impugnação do edital e tal porque a gente ficou pensando que talvez o pessoal dissesse “ah, mas isso você está se metendo, interferindo no processo interno da empresa, questão trabalhista, entrevista de funcionário, você está entrevistando funcionário, como assim”. Cara, e a nossa interpretação aqui, e passou até pela nossa Jurídica e tal, foi o seguinte: cara, eu estou sendo diligente, pô. Assim, eu acho que errado, se você parar pra pensar, errado é eu deixar um cara que eu nunca vi na vida mexer num código-fonte que está rodando há 15 anos e custou milhões pra fazer, correto? Maluquice é você não fazer isso, pô. Eu diria que a gente era irresponsável. “Ah, ó, chegou um cara novo aqui.” “Pô, beleza?” “Beleza” “Dá manutenção lá, commita no código, faz tudo”, pô, não tem o menor cabimento. Então a gente inverteu um pouco, então essa diligência também garante tudo isso. A diligência ela nunca é pra constranger o funcionário. A diligência ela funciona bem quando a empresa, quando você avisa a empresa antes. Então o que funcionou legal também foi a contratação aos poucos. Então quando a empresa está contratando e ela já sabe “ó, vou fazer diligência no cara”, a própria empresa, que foi o que aconteceu aqui, eles próprios já usaram o formato da diligência na entrevista do cara.

Então na verdade a função da diligência não é… Eu sinto o seguinte, se a gente algum dia a gente tiver de, a gente já fez umas 15, 16, não acabamos com a equipe toda ainda. Todo mundo passou. Se algum dia a gente tiver que reprovar alguém é porque a gente errou o processo antes, entendeu? A diligência ela é pra funcionar como uma preemptive, uma ameaça preemptive.

Só uma coisa. Vocês colocaram no TR então o número de pessoas que vocês queriam, você está falando do perfil.

O que a gente no TR fez foi colocar o número de USTs por ano que a gente vai contratar, que a gente quer contratar. E do número de USTs por ano a gente sugeriu uma composição da equipe, que é sugerida… Por exemplo: se eu não estou demandando o suficiente, pelo nosso TR a empresa tem um certo direito de dizer: “pô, mas esse número aqui é baseado nessa demanda, se você não está me demandando o suficiente eu não preciso botar equipe”, entendeu? Então na verdade a equipe é assim, se eu executar o máximo. Por exemplo, o nossa a gente está, se eu não me engano, em 40 mil USTs por ano, isso dá 3 mil e alguma coisa mais ou menos por mês. Pra executar isso eu preciso de 27 pessoas aqui. A gente não está executando isso ainda, a gente executou… Esse mês talvez bata 3 mil, por incrível que pareça, mas mês passado fechou acho que em 2.400, mês anterior fechou em 2.100. Então os caras estão aí com 21, 22 pessoas. Então não tem porque a gente exigir a equipe completa se a gente aqui não está conseguindo demandar, né. Porque aí tem isso também, mas vou falar depois na metodologia, que esse contrato dá muito mais trabalho de gerir do que o contrato de fábrica padrão, então a nossa capacidade de demandar a empresa diminui. Aumenta a qualidade, melhora o valor agregado, reduz o custo do órgão, economicidade e tal, tudo é bom, mas você não consegue… “Ah, tô tocando 15 projetos ao mesmo tempo porque tem 5 na fábrica de não sei aonde, 4 na Índia, 3 não sei…” Isso não dá mais, né. Mas voltando aqui ao perfil. Então a diligência e aí uma outra coisa que a gente fez que foi muito boa também foi uma pesquisa de salário no mercado. A gente contratou uma empresa de RH. Isso na verdade a gente já tinha feito antes, isso foi feito pruma outra licitação, acho que da infra, e aí o pessoal foi sagaz, viu que talvez a gente fosse fazer essa e já pediu logo… Se você vai fazer consulta de 5 profissionais, faz logo de 10, sei lá. E aí fizeram, se eu não me engano, foi pruma licitação… Agora não lembro, sinceramente, mas foi uma pesquisa de mercado de salário. Quanto está pagando na média um gerente de projeto, quanto está pagando um analista sênior, um pleno, júnior, etc. Então a gente colocou isso como indicativo. E isso é uma coisa que você não pode usar pra limar uma empresa da licitação. Mas isso permitiu à gente fazer duas coisas: primeiro você dá uma indicação do que que você espera, né. O licitante vê que você, naquela teoria de que os licitantes são agentes racionais, que não sei se é o caso, mas eles vão ver aquilo e vão ver a tua expectativa. Pô, você está falando que um analista sênior, que a gente não pegou nem a média, a gente pegou eu acho que o primeiro quartil lá em cima, o segundo quartil, eu acho, uma coisa assim. Você está me dizendo que você está na expectativa de que um sênior ganhe, sei lá, 9.500. Já está um salário alto pra caramba. Enfim, dá uma noção. Mas a segunda coisa que isso permite, que é mais prática mesmo, é que o seguinte: todo mundo que apresentou, todo mundo que apresentar um salário menor, a gente faz diligência. Então a empresa que ganhou aqui, que foi a Datainfra, apresentou um salário menor. Não muito menor, mas um salário menor. Então a gente falou na licitação, lá no pregão, aliás, está, é tudo documentado. A gente falou lá. Bom, como você apresentou um salário menor a gente vai fazer diligência. Me indica dois lugares em que você esteja executando um contrato bem e com esse salário que você diz que é possível, que a gente não acredita em você. Então o cara, essa última parte a gente não falou, mas é a lógica né, eles apresentaram o Inep e o Ministério das Comunicações. A gente visitou os dois, conversamos, batemos o salário com o pessoal lá, não com a empresa, mas com os gestores de lá, e os caras falaram: “não, olha, funciona bem sim e tal, tem um probleminha ou outro, mas funciona bem, o salário é mais ou menos esse e tal”. E então assim, isso é uma forma, a gente conseguiu aqui um salário razoavelmente, até no caso do júnior e do pleno, eu diria até bem acima do mercado. Então isso também contribui. Então você, pô, você coloca aí um escopo tecnológico maneiro, com um salário acima do mercado, você vai atrair esse perfil de full stack, cara que aprende bem sozinho, o cara, né, você começa a ter essa, enfim. Agora, deixa eu te dar um exemplo, essa retenção do pessoal e principalmente a motivação do pessoal. Eu acho que isso é uma coisa também que entra naquela história do resultado. “Ah, a motivação dos funcionários da empresa não é problema meu. Eu sou gestor, eu contrato resultado”, aquele negócio. Cara, mas é aquele negócio, a motivação é pré-requisito pro teu resultado funcionar. Então assim, você tem que estar sim preocupado com a motivação do funcionário se você quer ver o resultado funcionando. E eu acho que essa é a atenção ao detalhe que a gente tem que ter o tempo inteiro se a gente quer que o negócio funcione. E aí entra num problema que eu acho que aí, cara, é um outro debate gigante que eu não sei se vale a pena entrar agora, mas entra naquela história da visão da TI como um serviço comum, que eu acho que é a origem de todos os males. Então assim, cara, faz muita diferença se alguém que tava… Eu tenho total respeito por todas as profissões, mas tem profissões que são mais complexas e menos complexas. E não, não vou nem dizer isso não, porque eu acho que limpezas pra quem nunca fez é complicado. A pessoa boa de limpeza limpa uma casa em meia hora e você está ralando pra limpar o banheiro em duas horas. Acho que não é esse o caso não, acho que o que eu quero dizer é o seguinte. Eu acho que tem profissões que você consegue fazer menos engajado e tem profissões que você precisa estar mais engajado. Profissões que são muito intelectuais.. Cara, por exemplo, o programador está aqui. O cara briga com a namorada, o cara no dia seguinte não produz nada, e é um fato isso. E se você não entende esse fato, você não está trabalhando, você não entende de TI. Então eu imagino que outras profissões aí, sei lá, pintar parede ou limpar uma casa e tal, talvez você consiga, mesmo brigado com alguém, você consiga tocar bem porque é uma profissão mais mecânica, mais motora e menos… Então é nesse sentido. Corrigindo o que eu falei antes, acho que é questão de menos engajamento e mais engajamento. Então se você não trata isso como um serviço comum, já era, cara. Aí, por exemplo, a empresa, outro dia aconteceu um problema aqui que a empresa estava atrasando o plano de saúde do pessoal aqui. Pô, aí o pessoal começou a ficar chateado. Pô, isso não é problema meu? Aí vou fingir que não, isso… Nesse caso até é sim porque isso está na planilha de custo, então como está na planilha de custo a gente pode até interceder. Porque se a empresa diz que o preço dela que ela me cobra é baseado num custo e esse custo inclui plano de saúde e ela não paga o plano de saúde, então ela está me tungando, tungando dinheiro, bom, não a mim, né, ao órgão, está tungando dinheiro público que, em tese, né, enfim. Mas ainda que não estivesse na planilha, pode até ser um caso em que você não tenha como fazer nada. Não tem como fazer nada, não é problema meu, é problema da empresa, tudo bem, eu entendo isso. Mas ainda que você não tenha como fazer nada a respeito, não quer dizer que o problema não seja, não vá estourar em você e você não tenha que estar atento. Então você tem que pensar que isso pode atrasar o seu projeto, vai cair a qualidade, etc. Então acho que é essa a raiz, essa coisa de você ver o negócio como um serviço comum. Então, enfim. Mas aí eu acho que é isso.

Então pensando assim, a motivação do funcionário, salário, treina… Ah, tem uma coisa, tem um exemplo legal. Tudo isso do craftsmanship, pra gente ter esse modelo. Uma coisa pra te dar um exemplo de coisas que a gente queria fazer e a gente acabou tirando do edital, do termo de referência. Ou melhor, eu não sei nem se entrou, porque esse o Idec já mataram. A gente queria colocar obrigatoriedade de conferência e treinamento, inclusive no exterior. A gente queria botar o seguinte: olha a empresa tem que, todo funcionário tem que ir uma vez ao ano pra uma conferência no exterior. Umas coisas assim. Cara, assim, a gente vai aqui, né. O que você volta, de novidade do que está acontecendo, cara, boa parte – depois eu vou te mostrar nossa suíte de ALM aqui, de life cycle management, do Confluence, do JIRA, do Bamboo e tal – cara, isso é muita coisa que a gente aprendeu lá fora e trouxe pra cá. Não que aqui não tenha coisa acontecendo, tem também, mas que chega aqui cinco anos depois. Geralmente chega aqui depois que alguém já traduziu livro. Se você pode ir lá num… Enfim.

Você está falando do que vocês atacaram. Primeiro começou com coisa da fábrica X craftsmanship. Aí você falou que tinha várias coisas, uma delas era perfil da equipe, salário, etc. Isso a ver com a fábrica. Falaram alguma coisa também de trabalho presencial aqui, né.

Isso, trabalho presencial. Isso aí vem no conjunto dessa coisa do… Mas eu acho que essa coisa do trabalho presencial tem mais a ver com…

Estava no TR, o trabalho vai ser presencial?

Tá. Todos os funcionários tem que estar alocados aqui, obrigatoriamente. Se eu não me engano a gente fala aqui, o prédio da ABC que é aqui do lado e o Rio Branco, é, porque são os anexos, acho que a gente menciona. Mas é tudo aqui. A gente só coloca os outros porque de repente alguém precisa fazer alguma coisa, aí a empresa não… A gente fala que a gente tem esses anexos, mas é aqui. É dentro do MRE.

Mais alguma coisa do TR?

Isso aí eu não colocaria na questão do craftsmanship X fábrica, eu colocaria no ágil X o RUP, que é outro ponto. Bom, vamos passar pro outro então. Isso tudo é questão do craftsmanship X fábrica. Perfil do pessoal, salário, motivação e tal.

Vamos pro ponto da métrica.

Tá bom, fechado. Bom, métrica. Cara, métrica, os problemas a gente já falou ontem, então vamos falar agora da solução, o que a gente pensou. A gente pensou, cara, a gente precisa de uma métrica que meça esforço. Não dá, cara. Não dá, a gente quer exigir mais qualidade, a gente não pode ficar, a gente precisa saber o que a gente está pagando, a gente não consegue ver, você não consegue gerir um contrato assim. Não sei quanto que eu gastei de front-end, quanto eu gastei de back. E se eu quiser investir mais no front-end, e se eu quiser investir muito no design, na usabilidade, como é que eu faço isso? Como é que eu peço pra empresa botar um cara… Ah, mas aí no ponto de função você tem aquela consultoria, aquele item de consultoria lá no final, no guia de métricas, que são os itens não mensuráveis. Interessante, isso. Itens não mensuráveis, essas coisas. Pô, mas como é que meço isso? Ah, você usa os itens não mensuráveis, aí você cobra por hora ou por um deflator. Aí o que acontece, cara. Aí a gente teve um caso aqui que foi sinistro. Foi o seguinte. Por exemplo. Nós tivemos vários casos aqui que foram bizarros. Como você não paga por esforço é claro que, por exemplo, eu posso chegar assim, tá, o ponto de função não funciona com esforço, mas nessa parte dos itens não mensuráveis, eu posso funcionar com esforço. Então posso dizer assim: uma hora de consultoria sua eu vou pagar 0,25 de um ponto de função. Aí essa parte eu vou manejar assim. Você até pode fazer isso, cara, mas você mal tem condição de gerenciar uma métrica direito, que dirá, aí eu vou trabalhar com uma métrica que consome de duas formas, como é que eu vou calcular a planilha no final, aí o negócio fica meio… Então acaba que você que não vê isso tanto dessa forma, e essa parte de item mensurável acaba ficando meio solta. Então o que acontece. A gente tinha aqui, por exemplo, a gente ainda tem uma ferramenta que é usada pelos postos no exterior que é uma ferramenta de gerenciamento de conteúdo lá. Então o pessoal pede pra subir “ah, eu quero usar isso aqui”, a gente sobe uma instância pra eles. Então é um CRUD e tal, não sei o que, deve ser assim uns 20, 25 PF pra fazer do zero. Só que em 2009 ou 2010 a gente automatizou isso. O nosso desenvolvedor aqui sobe uma instância disso em uma hora, duas horas, só que no ponto de função dá quanto? Dá os mesmos 25 pontos de função. Então pra eu ajustar isso e pagar só as duas horas de esforço eu preciso mudar a métrica pra esforço. Aí às vezes “ah, mas essa parte eu posso fazer por esforço”. Até posso, só que, cara, você fica perdido naquele ponto de função você não faz, você acaba trabalhando com ponto de função. E é melhor você trabalhar com uma coerência mesmo. Então quer dizer, no que é óbvio, essa que é a questão, você está me dizendo o seguinte: que tudo que é óbvio, ah, faz um CRUD, que o ponto de função atende, tá legal, e no que não é óbvio ele não atende. Mas o problema na TI é o que não é óbvio, o problema na TI são os detalhes, são os requisitos que você não consegue medir, são os imprevistos, é você descobrir que no meio da sprint você descobre que a gente entendeu errado a demanda. Esse é que é o difícil. Então a gente teve esse caso. Um segundo caso que a gente teve, que também foi emblemático, foi o seguinte. A gente tem algumas ferramentas que, cuja configuração a gente passava pra empresa também. Então assim não é exatamente programação, mas, sei lá, configurar um WordPress, um Joomla, alguma coisa assim, isso às vezes a gente terceirizava também. Nem tudo, muita coisa a gente mesmo faz aqui, mas é muita coisa e a nossa equipe aqui é muito pequena, então a gente terceirizava isso. E isso tem um ponto lá, tem um item lá, sei lá, 0,1 ponto de função, é até bem pouco, ah, ajustar uma configuração, tá bom, e que mesmo não era porque o tempo do cara parar, entrar, mudar a tarefa que ele está fazendo, se você pensar até tem uma lógica aí com esforço. Só que teve uma vez, cara, por um problema aí de um ataque que a gente sofreu, uma história longa que não vale entrar, que eles tiveram que fazer tipo mil alterações de configuração. Só que, uma vez que você abriu a ferramenta e você está lá, você faz assim, você basicamente é clicar em mil checkboxes. Então você está ganhando aí 100 reais pra clicar em checkbox. Cada checkbox 100 reais. Cara, deu uma conta gigantesca. Deu uma conta gigantesca. E aí a gente chamou eles aqui, a gente negociou, a gente falou “cara, olha, você há de convir que…” Até a empresa, a gente fez um acordo, até a empresa aceitou. Então assim, a gente não impôs à empresa porque na verdade assim, o que a gente conversou com eles é que o item dava margem a dúvidas. E dava um pouco mesmo, mas se eles não tivessem aceitado, eles também teriam uma briga. Mas no final eles aceitaram. Então o que acontece. Você não tem visibilidade nenhuma e você acaba com essas contas assim gigantes porque às vezes o ponto de função ele… Um outro exemplo disso. Terceiro exemplo. Uma coisa que acontecia muito assim. Ah, o cara produziu mal essa semana, um determinado desenvolvedor. Cara, na semana seguinte, dependendo da demanda o cara recupera. Novamente, se vier um CRUD, 20, 25 PFs que o cara ganha e o negócio que o cara faz em um dia, um dia e meio aí com esses frameworks mais automatizados, o cara recupera a semana passada inteira que ele não trabalhou direito. Então ponto de função permite isso também. Então no fundo, cara, o ponto de função ele, aí você pensa assim: mas como é que eu consigo gerenciar assim? O cara não faz nada a semana inteira, ou trabalha mal a semana inteira. Aí na semana seguinte ele consegue faturar duas semanas. Então pera aí, então o valor do ponto de função está caro demais, não está? Se o cara trabalha uma semana e ganha por duas, eu podia reduzir o valor à metade. Então você perde, vira, sabe, lembra do Brasil inflacionário, que você não tem uma noção de valor? Essa paçoca aqui custa 20 reais, não sei nem mais se isso é caro ou é barato. 20 mil cruzeiros uma paçoca, isso é caro ou barato? Não sei, ontem tava 15, mas também tudo aumentou, então você perde a noção. Ponto de função… e a prova disso é, olha o valor, cara. Aliás, isso seria um estudo maneiro, hein, a distribuição estatística, a curva dos valores dos pontos de função praticados. Você tem ponto de função de 200 reais a 1500. Ah, mas as tecnologias são diferentes. Nem sempre, cara. Você tem em muita tecnologia repetida aí com valor… Qual a diferença de um ponto de função de 500, 800 e 1000? E 1200? Você vê que o negócio não tem base nenhuma porque realmente não mede nada. E aí você tem a medida, o ponto de função ele é excelente praquilo que ele foi criado, para você ter uma noção do escopo total. Então assim, e fora de contexto. Isso é que é maneiro do ponto de função. Ponto de função ele é maneiro por isso, ele te dá uma métrica fora de contexto, cara. Isso é muito bom. Então por exemplo, se eu vou pra um país, sei lá, estou na Ucrânia, aí eu conheço um desenvolvedor da Ucrânia. Aí o cara, “pô, estou trabalhando num projeto”. E qual o tamanho desse seu projeto? “Ah, cara, uns 500 pontos de função”. Maneiro. Se ele me dá isso em ponto estória, não significa nada, porque ponto estória é da equipe dele, é do órgão dele. Mas se ele me der em ponto de função eu consigo comensurar na minha cabeça o tamanho do projeto, isso é muito bom do ponto de função. Agora, num contexto interno de um órgão, em que eu conheço o contexto em que eu quero o contexto, não tem vantagem nenhuma usar ponto de função. Aí o que acontece. Da mesma forma que eu sou um estranho para o nosso amigo da Ucrânia, o TCU é um estranho pros órgãos. TCU não conhece o contexto dos órgãos. Então ponto de função ele facilita um pouco a fiscalização do TCU, só que ele facilita a fiscalização derrubando tua capacidade de gestão interna. Então assim, eu entendo um pouco o… eu acho que seria bacana se, um dia assim, uma fiscalização por amostragem fazendo reversa. Eu vou em órgão, seleciono projeto, faz a reversa, pega o que eu fiz aqui em UST e faz a reversa, vê, conta, não é bem reversa, é contar depois. Conta depois quantos pontos de função deu, calcula e aí você faz na Esplanada e aí você compara um órgão com outro. Aí tudo bem. Mas assim, eu já fui em conferência, tava numa conferência do ágil, Agile Alliance, esse ano. A gente teve uma sessão lá, um workshop avançado sobre métrica, só sobre métrica de software. O cara falou de tudo, de Cosmic, IFPUG, não sei o que. E uma pergunta que eu fiz pro cara foi justamente isso, eu falei: “cara, como é que você compara ponto de função de um órgão, uma métrica de um órgão usado”, eu estava até meio que defendendo ponto de função, eu falei: “pô, como é que você consegue comparar métrica de um órgão com outro, com outro, com outro, pra você ter uma noção assim de produtividade e tal?”. Ele falou “cara, pra que que você vai querer fazer isso?”. O cara não entendeu pra que eu quero fazer isso. Porque ele não tem o contexto, porque no fundo pra que que se quer fazer isso? Ah, porque eu quero fiscalizar. Mas por que você quer fiscalizar? Ah, porque tem corrupção pra cacete, porque o Brasil é uma zona, mas esse lado o cara não entende. Pra você ver o story point, por exemplo, ponto estória, ele é, eu sei que eu estou repetindo o que você sabe, ele muitas vezes é por equipe, cara. Você não consegue às vezes comparar nem uma equipe com outra dentro do mesmo contrato. Essa é a ideia do negócio, porque cada equipe tem a sua, o seu grau de dificuldade, complexidade e interpretação diferente. Fora isso, pra não entrar no fato de que ponto de função é subjetivo pra caramba também e é manipulável pra caramba. Você divide o negócio em mais, ou melhor, desnormaliza ou normaliza, ou divide coisa, por exemplo, posso dividir um campo da piora em dia, mês, ano, hora, minuto, né. E aí eu tenho mais campos na tabela, você tem um milhão de formas de inflar um negócio. Eu posso fazer várias… Por exemplo, vamos supor que eu tenha um sistema com dois perfis, perfil usuário 1, perfil usuário 2. Eu posso fazer uma visualização só com um IF ou um case que implemente lá esses dois perfis, ou eu posso fazer duas visualizações diferentes. Que que as empresas fazem? Quase sempre vão fazer duas views diferentes, que é pra ganhar mais, e aí você reconta todo o ponto de… você reconta tudo, se você tem uma nova view, você vai recontar tudo, toda entrada, toda saída, todo não sei o que. Você manja, né? Mas assim, o problema da fábrica e o problema do ponto de função são dois problemas diferentes.

E aí como é que se ataca o…

O ponto de função, vamos lá. Pô, acabei falando dos problemas de novo, né. Mas a gente atacou da seguinte forma. Eu trabalhei na Mídia Lab no Rio, na MLab, que na época foi uma das maiores empresas de desenvolvimento web e tal. Eles eram do grupo Mantel. Você lembra do Prêmio iBest da internet? Melhores sites e tal? Era desse grupo que fazia e tal. E lá usava-se uma coisa parecida, que era tipo um repertório de estimativas em UST. A ideia da UST a gente pegou… (UST = unidade de serviço técnico) A gente pegou do DATASUS. Depois se quiser procurar esse TR, o DATASUS tem um edital de SOA, de arquitetura orientada a serviço, e nesse edital eles usam UST. E a gente falou: “cara, isso aqui é uma ideia que é boa pra gente”. E aí eu peguei isso e misturei com essa ideia lá que a gente fazia no setor privado de repertório de estimativas. Então como é que é. Uma UST é uma hora de serviço. É hora-homem, cara, é aquilo que falei ontem: todo mundo chama, as pessoas chamam de hora-homem um monte de coisa diferente. Então depende do que você quer dizer com hora-homem, mas o que a gente está fazendo aqui é o seguinte, a gente faz uma fiscalização estrita igual à fiscalização com ponto de função. Então, por exemplo. A gente abre a demanda. Na verdade é até melhor, porque no ponto de função depois você tem a contagem final, que pode alterar a estimada e a aprovada. Aqui não. Aqui a gente aprova antes, é tudo com aprovação prévia, então assim. A gente abre a demanda, a empresa estima em UST e a gente aprova ou não. Ou negocia, ou reclama, né, e aí aprova. E é o seguinte. Se eu abro uma demanda e a empresa começa a fazer, a gente fala, eu não vou lá amarrar o braço do cara pra ele não fazer, só que a estimativa que ele me trouxer é por conta e risco da empresa. Porque já houve caso aqui, por exemplo, de por causa da estimativa eu não querer fazer mais. Então assim, eu abro a demanda. O cara: “pô, isso aqui vai ser 50 USTs”. Eu falei “cara…”, não foi nem pelo preço, foi pela demora. Eu falei: “não, então não vai adiantar porque a demanda negocial é mais urgente”. Então assim, se o cara quer começar a fazer antes de aprovar a demanda é por conta e risco da empresa. Mas o nosso processo é esse, assim, tudo com aprovação prévia. Então a gente é muito rigoroso nisso porque é isso que diferencia isso aqui de um oba-oba de posto de trabalho. Porque se o cara faz tudo e no final do mês manda a conta: “ó, executei 1000 USTs, executei 1500”, aí vira bagunça. Então o processo todo é regulado como se fosse um ponto de função. O processo de aprovação de…

Bom, então como é que funciona a UST. A gente tem, quando a gente demanda o trabalho, o cara faz a estimativa em UST mas pra não virar bagunça a gente tem o repertório de estimativa. O que eu chamo de bagunça é o seguinte. Vamos supor, elaborar um HTML baseado em template existente. Isso aí, sei lá, são 2 USTs, não sei. Se não tiver um repertório, como a gente tem várias pessoas aqui, daqui a pouco eu estou aprovando 3, outro está aprovando 1, aí vira bagunça, aí a gente não sabe o que que cada coisa vale. Então o repertório ele é como se fosse um histórico de referência e que pra fugir do histórico, pra mudar um item ali, aí sim, isso tem que passar obrigatoriamente por mim. Então eu só, vamos dizer, na verdade todo mundo aqui tem autoridade pra mudar, mas a gente aprova comigo. Então, toda mudança de repertório passa por mim. Então com isso a gente tem um controle. Mas a gente chama de repertório e não de catálogo porque, conforme está no nosso TR, ele muda, ele é pra mudar, ele já está até, já tem 8 ou 9 versões. Eu posso te mostrar aqui no comp. Então tem lá um monte de coisa. Tem a parte de design, prototipação, tem a parte de mais de análise, que é elaborar história de usuário, elaborar o planning da sprint, por exemplo, que a gente chama de planejamento da sprint, elaborar, aí tem parte de banco, tem parte de…

Isso vocês já começaram o contrato com o repertório montado? E veio daonde?

Com o repertório montado bem pequeno. Cara, veio, a gente fez um levantamento aqui interno entre a gente, com os técnicos, com um pouca a nossa…

Mas isso foi divulgado no TR ou não?

Foi. O inicial foi. É, tinha que ser pro cara ter uma noção do que que é. Por que o que acontece, tem outros órgãos que usam unidades assim parecidas só que não têm vínculo com hora. Então você tem lá, unidade X, sei lá, ah, elaborar um caso de uso, 20x. Mas o que é 20x? Não, é uma moeda interna, como se fosse uma moeda própria, entendeu, só que pra gente não adianta, porque o que a gente quer ter é visibilidade de esforço, e a métrica dá isso hoje.

E aí esse fluxo de gestão de demandas, isso estava no TR ou não, isso já é uma coisa…?

Estava no TR. Que tudo tem que ser aprovado previamente e tal. Quando a gente até coloca aqui, ó, quando a gente abre uma demanda, no backlog do produto eles já dão uma estima. Essa estimada, a gente nem está usando muito, mas isso aqui é mais pra saber assim, pô, vamos continuar com o projeto ou não. A estimativa final deles é no backlog da sprint. Porque é na sprint que o cara… Isso também é outra coisa, né. Na sprint é que o cara tem a, levanta o, vamos dizer, faz as histórias, conhece melhor a demanda e bola a solução. E confecciona lá a solução. Então ali é que o cara promove a estimativa, eu te mostro também como é que a gente faz.

Nesse nível a estimativa é por tarefa. Por microtarefa.

Por tarefa. Microtarefa. Só que é o seguinte. A gente sempre tem um debate aqui de quão, o quão micro a gente vai. Porque a gente também não quer entrar naquele nível do desenvolvedor, ligar a máquina, começar a trabalhar, checar email, né, a gente não quer remunerar assim. Bom, a gente não remuneraria por nada disso, porque não é tarefa final, mas enfim, mas você entendeu, a gente não quer demorar em tanto detalhe. Então assim, a gente tem muito pouca coisa que dura meia UST e se tem coisa, por exemplo, que eles fazem numa tarefa e a gente não estava remunerando, a gente prefere incluir numa mesma tarefa e aumentar a UST daquela tarefa. Então, outra coisa, a gente remunera teste unitário, desenvolvimento de teste.

Que aí entra como uma demanda, fazer o teste…

Exatamente. E a estimativa, só pra você ter uma noção, por exemplo. Uma operação de banco num back-end, então o cara está programando o back-end, qualquer operação de banco que ele for fazer, né, um create, um read, um insert, um select, o que seja, isso a gente remunera 4 USTs. Então você pensa assim, o cara ganha 4 horas de trabalho pra programar uma operação de banco no back-end. Então um CRUD completo no back-end são 16 USTs. Se você contar que o cara tem que fazer as telas, os HTMLs e tal, você coloca aí mais uns 15, 20 USTs, nós estamos falando aí de 36 USTs. Isso sem fazer front-end rico com Angular, porque isso a gente remunera mais também, mas você põe aí 40 USTs. 40 USTs mais ou menos pra fazer um CRUD. A nossa UST aqui está R$ 134, então isso aí dá mais ou menos R$ 5.000. Agora, você compara R$ 5.000 com 25 pontos de função vezes o valor do ponto de função. Que isso aí vai dar, cara, um ponto de função barato aí é R$ 500, isso aí já vai dar R$ 12.500. Dá mais que o dobro. E o tempo pra fazer é o mesmo. Então o mais impressionante é isso, cara, é que assim, a gente está, os funcionários estão ganhando mais, a qualidade está mais alta e o custo está mais baixo. Aí você pensa assim “pô, mas onde é que está a mágica aí? o que que está acontecendo com a grana?” Eu acho que o que está acontecendo com a grana aqui é que no fundo, no fundo, a gente tem uma, a gente está pagando por valor agregado de verdade, então não tem mais aqueles seis meses de caso de uso que a gente conversou ontem, então por isso que a gente vê que a qualidade aumenta, e segunda coisa, a gente força aqui uma qualidade da mão de obra. Então você consegue trabalhar com menos gente. Cara, a empresa anterior aqui, a Cash, aqui tinha uns 30, mais uns 20 na fábrica, 50 pessoas trabalhando pra gente. Então assim, você reduzir a equipe e aumentar a qualidade.

Uma coisa que eu esqueci de falar, cara, que é muito importante, a gente trabalha com pirâmide invertida na equipe. Isso é parte do, isso estaria, você lendo o TR você vai ver, mas pirâmide invertida, que é o seguinte. O número de plenos não pode ser nunca maior que o número de sêniores, e o número de júniores não pode ser nunca maior que o número de plenos. Então, por exemplo, a primeira pessoa que o cara contratar, você só tem um na equipe, tem que ser sênior; o segundo, pleno; o segundo, júnior; o quarto cara que ele contratar pra manter a pirâmide tem que ser sênior de novo. Então você nunca tem a situação aqui de um sênior com cinco júniores.

Como é que funciona no TR, no contrato essa coisa de você dar a remuneração da empresa é via métrica, via UST, mas você influenciar no salário do funcionário, como é que funciona?

Então, o salário é assim, a única influência que a gente teve foi na pesquisa de preço, então depois disso a gente não influencia mais, na verdade. O que acontece: quando a empresa faz o, quando ela propõe, quando ela dá a proposta dela, ela dá uma planilha.

Ela tem que dizer quanto ela vai pagar?

A gente exige. Planilha de custo.

Mas isso é comum?

Cara, é comum, mas aí eu vou te contar a história sobre isso. Isso é comum, é totalmente legal isso, se eu não me engano, em toda licitação você tem que fornecer isso, o que não é tão comum… É, eu acho que sim, eu acho que em toda licitação de serviço comum você tem que dar planilha de preço, licitação de limpeza, de não sei o que, tem que abrir a planilha. O que não é comum e que varia de Jurídica pra Júridica, de órgão pra órgão, é o quão vinculante é essa planilha. Tem órgão que interpreta isso como não sendo totalmente vinculante. Então se o cara der um salário mais baixo tudo bem, não tem problema e tal. A gente aqui é bem estrito com isso, então assim, aquela planilha é vinculante. Então se o cara colocou na planilha que vai pagar sei lá, R$ 7.500 tá o salário do sênior hoje aqui, 7.500 pro cara, é 7.500.

Ele se compromete a fazer isso.

E senão a gente já advertência pra ele. A última, a terceira advertência que ele levou é por isso, inadequação salarial. De duas pessoas. É que a gente já está avisando pra eles desde o início e eles demoraram pra ajustar, aí pediram prazo, a gente deu prazo, eles atrasaram o prazo, aí levaram advertência. Mas isso eu estou te falando assim, se eu não me engano tem 2 pessoas que não estão ajustadas duma equipe de, sei lá, 20, 25 pessoas. Então está, a gente consegue cumprir bem.

Porque é o seguinte, o que o cara pagar a menos a gente pode glosar. Então o cara, também pra ele não faz, o cara não vai levar esse dinheiro pra casa. A empresa não vai levar esse dinheiro pra casa, esse dinheiro não vai ser dele de qualquer forma. Ou vai ser do ministério, ou vai ser do funcionário.

Mas não acontece de você num mês contratar um número de USTs que não dá o valor que preenche todos os funcionários contratados certinho?

Dá, mas aí uma coisa em tese não tem nada a ver com a outra. Então se por acaso a gente não demandar nada esse mês, a obrigação trabalhista de o cara pagar o salário é dele e vai ter que pagar de qualquer forma. É claro que a gente aqui está preocupado com o faturamento da empresa também, porque é a saúde do contrato. Então hoje você tem que estar sempre calculando isso. Então por exemplo, hoje a gente sabe, a empresa vai dizer isso, a empresa diz. Olha, hoje, se eu não me engano, a empresa se paga com 2.000 USTs, mais ou menos. Então, por exemplo, levou quatro, cinco meses pra gente chegar em 2.100. Mês passado já foi 2.400. Esse vai fechar em quase 3.000. A empresa já está começando a dar lucro, isso em menos de um ano, o que também já, cara, olha, um contrato desses de cinco anos, se a empresa levar dois anos pra começar a dar lucro tá bom. Não tá ruim, né. Mas é uma preocupação, certo, o que acontece é o seguinte, o que a gente tem feito em relação a isso vai de volta naquele ponto que eu te falei da gente não pedir os funcionários completos. Lembra que eu te falei que a gente não está com a cota completa de funcionário porque a gente sabe que… Então, por exemplo, vamos supor que tem uma outra tecnologia aí que eu tenho demanda, está acontecendo isso agora, que eu tenho demanda pra um funcionário e meio, mas eu não tenho demanda pra dois funcionários. Então não vou fazer a empresa contratar um segundo. Eu prefiro aguentar o atraso, né, porque vai atrasar, se eu tenho demanda pra um funcionário e meio e só tenho um vai atrasar. Mas eu prefiro atrasar as demandas do que fazer a empresa contratar um segundo cara e ele ficar ocioso aí e daqui a pouco… É uma preocupação sim.

E voltando à questão da métrica e do planejamento, de estimativa e tal, como é que é vocês fazem sprint, é período fixo, varia, como é que é a formalização dessas… vocês têm um jeito mais ágil de formalizar as demandas e as estimativas ou tudo tem que gerar documento…

Não, não, a gente usa o JIRA, a gente tem o JIRA. A gente tem o Confluence pra documentação. Então a gente abre as demandas no JIRA. A gente evita abrir por sprint porque dividir em sprint já é um trabalho técnico um pouco posterior, então a gente costuma abrir por Epic, né, que seria uma coleção de histórias. É o Milestone, exatamente. Então a gente abre por Epic e às vezes a gente abre demanda pontual sim, corrigir um negócio e tal. Mas em geral a gente abre por Epic e aí da Epic vai saindo, vão saindo as sprints.

Qual que é o tamanho das sprints?

A gente começou tentando trabalhar com uma semana, só que não deu muito certo. Porque a gente ainda não está tão automatizado. A gente já está bem, cara, a gente já está ó, com a parte de documentação integrada, demanda, código-fonte integrado, vou te mostrar aqui. Estamos já, já estamos com coisa no… o deploy na integração contínua automatizado também. Mas está faltando a parte da infra, e esse é um projeto que a gente está começando agora também, a gente está começando aqui, pegando dois caras da empresa de infra, dois caras do desenvolvimento e a gente está montando uma equipe de DVOPS aqui.

Vocês têm infra própria aqui ou vocês contratam o Serpro?

Não, a gente tem infra própria. E aí a gente está montando essa equipe de DVOPS porque a gente, está faltando automação do lado da infra. A gente, o lado de Desenv chegou até onde pode chegar. Agora está faltando a parte de automação de TI, de conteinerização, então a gente quer testar isso. Então o pessoal vai testar aí o Kubernetes pra orquestração, com Docker, em cima de VMware, que é o que a gente tem hoje. Então, dando certo isso, aí eu acho que a gente consegue trabalhar com sprint de uma semana. Mas agora não faz sentido você trabalhar com sprint de uma semana se você leva às vezes meio dia pra subir um negócio. Aí tu já perdeu… Então hoje a gente está trabalhando de duas semanas e tem um projeto que é muito crítico, que é um projeto de segurança, de autenticação e autorização que a gente está refazendo, esse está trabalhando às vezes com sprint de três semanas, um mês, mas é porque é um projeto assim, totalmente fora do comum, uma coisa muito específica, a gente está usando uma tecnologia que a gente nunca usou aqui, que é o Oauth2, um servidor de Oauth2 aqui. Enfim, é muita novidade pra uma coisa só, então a gente nem precisaria de um ciclo de lançamento rápido agora. Mas isso não impede do pessoal ir mostrando resultado. A gente tem acompanhado. A gente tem reunião diária, né, o scrum, lá e tal, as deles, a gente tenta ir sempre quando possível. O pessoal aqui vai mais, eu vou nos projetos principais que eu toco diretamente como esse de segurança, por exemplo, eu tento ir o máximo que dá, às vezes eu consigo ir duas vezes por semana, mas enfim.

Então a gente está entrando num terceiro ponto que é a metodologia. O que vocês colocaram no TR?

Isso, vamos lá. Cara, a metodologia basicamente é a parte mais simples eu acho. A gente fez um ágil. Basicamente o scrum simplificado. Então a gente pegou o scrum, muito daquele livro do Rubin lá que você viu e pegamos o que ele fez e simplificamos. Então a gente tem assim metodologia com muita pouca documentação, muita pouca coisa. A gente criou templates, então eu tenho um template de história.

Isso está no TR, vocês colocaram no edital?

Cara, tem essas duas páginas aqui só. Olha: iniciação, então iniciação é um planejamento do produto. Isso aqui é tipo um visão, mas isso aqui é só pra eu ver o seguinte. Eu quero saber que o cara lá da empresa entendeu. Isso aqui é pro cara fazer em uma hora. Eu quero saber o seguinte: “Ó, o projeto vai ser isso, isso e isso, você entendeu?” Entendeu. “Então agora escreve só pra eu ter certeza que você entendeu.” Só isso. Depois tem a arquitetura da solução, isso já é na fase de planejamento do projeto como um todo. Arquitetura da solução ela define coisas como, pô, vamos fazer em que, vamos fazer uma camada de API por trás com Api? Vamos fazer com back-end acessando bases direto, vamos reaproveitar as APIs que já existem? A arquitetura da solução.

Tem projeto que isso aqui não significa quase nada. Tem um projeto que a gente está fazendo aí no portal que eu vou te mostrar que a arquitetura da solução tecnicamente não é nada. O projeto de autenticação segura, por exemplo, envolveu um monte de coisa, cara. Vem cá, a gente vai usar o Oauth2 ou SAML? Vamos usar qual desses dois? A gente vai usar pra autorização ACL ou vamos usar RBAC, que são paradigmas diferentes de autorização? Então quando você começa a ver tudo isso, pô, é uma arquitetura de solução que você tem que parar para pensar. A UST permite isso. Então o pessoal veio falar comigo e falou “cara, a gente precisa mudar o repertório porque a DAS remunera, sei lá, 8 USTs, não sei, e pô, isso aqui a gente vai levar…” Então o que que a gente fez, a gente abriu um estudo separado pra Oauth2 e SAML. Abrimos outro estudo pra RBAC e ACL. Abrimos um prazo muito maior pro… alteramos o repertório pra permitir mais USTs pra arquitetura da solução, porque realmente é um projeto sui generis, são poucos os casos.

Ah, uma coisa também, do nosso repertório, a gente remunera estudo de código-fonte. É mais uma das ficções do modelo atual. Como é que uma empresa que vai chegar aqui que nunca viu teu código-fonte na vida vai dar manutenção nele? Tá pedindo pra dar errado. Então a gente remunera o estudo do código-fonte. Só que a gente só remunera isso uma vez por sistema. Então assim, o segundo funcionário aí já tem que haver um repasse interno. Essa é a fase de planejamento. A arquitetura da solução e o backlog do produto, que é funcionalidade, listagem de funcionalidades assim num nível macro, como um backlog do produto. Aí vem na parte da iteração dos sprints. Aí no início da sprint, história de usuário, backlog da sprint, aí sim detalhado, com as estimativas. Era isso, só essas duas coisas. No final da sprint, revisão e retrospectiva. Tem funcionado muito bem. E no final do projeto como um todo, a gente… Ah, sugestão de atualização do repertório de estimativa, que na verdade não está rolando aqui porque a gente está fazendo ao longo do… É, o tempo todo. E documento de lições aprendidas. E a gente paga também pelas lições aprendidas.

Tudo está descrito no edital.

Tudo no edital, isso aqui é uma impressão do edital, essa tabela aqui está no edital, essas duas páginas. Então, por exemplo, lição aprendida, uma coisa, a gente paga por lição aprendida. Então você me diz quantas lições aprendidas foram e eu vou te remunerar. Aí você pensa assim: “ah, mas o cara vai inflar isso”. Cara, só que é a função do… é aquilo que você falou ontem… é apertar demais antes, depois alivia. Aqui não, a função do fiscal é apertar o tempo todo. Então assim, se o cara vier com uma lista de 15 lições, tudo de enrolação, eu não vou remunerar o cara por isso. Eu vou falar “meu amigo, você está de brincadeira comigo? E outra coisa, se eu achar que você está querendo me enganar você ainda vai levar uma advertência por isso”. Então assim, o fiscal tem todo o poder pra evitar isso, né. O que falta às vezes é tempo, mas assim, uma coisa que a gente tenta fazer aqui é essa documentação a gente rever em detalhe. O que a gente não tem tempo de rever, que é uma coisa que eu gostaria no mundo ideal, é rever com mais detalhe a implementação das coisas. Revisão de código-fonte, isso é que seria, enfim, mas aí já estou…

E essa questão de formalizar as demandas e feedbacks, esse processo todo estar em uma plataforma digital, isso foi especificado em algum momento?

Tudo na nossa ferramenta. A gente já tinha esse projeto em paralelo. O que o TR diz é que a empresa ou o MRE vai fornecer a ferramenta ou, se o MRE não fornecer, a empresa tem que fornecer.

Mas não diz qual.

Não diz qual. Mas a gente tem uma lista de requisitos. O que acontece. Quando a empresa entrou aqui a gente ainda estava implementando a ferramenta. A gente estava implementando a ferramenta, então quando a empresa chegou estava ainda em teste, não dava pra usar. Então a gente falou “cara, traz a tua provisoriamente”. Aí eles mostraram, cara, as ferramentas mais toscas assim que eu já vi, se tivesse internet no século XIX teria aquela cara. Aí a gente falou “cara, isso aqui não atende por causa disso, disso, disso, disso”. Essa foi a primeira advertência que eles levaram. Por não apresentar a ferramenta. Mas aí logo depois a gente implementou uma ferramentazinha provisória, WebIssues, que é uma ferramentazinha boa. Simplezinha, mas dá para o gosto, como de controle de demanda. Aí passou uns dois, três meses, aí implementamos a suíte da Atlassian, com o JIRA, o Confluence, Bamboo e tal, e aí é a que está no ar hoje, bom, já há vários meses. Então foi isso, a gente precificou, mas a gente já estava em andamento com essa… Que aliás, isso é uma coisa… Não sei se isso está na tua tese, mas eu acho que a gente não conseguiria fazer tudo que a gente está fazendo e com a equipe que a gente tem se não fosse também com a automação do processo.

Claro, você começa a descrever, tem que abrir cada demanda, aprovar a estimativa. Puta merda, meu, isso deve dar um trabalho. Porque eu vejo no ministério como era a fábrica de software, isso gerava papel… OAS, cada uma era uma coisa… Era muito, muito desgastante.

É, não, te mostro assim, assim que a gente terminar aqui.

Mas vamos lá, a gente falou da métrica, da fábrica, da metodologia. Qual que era o outro ponto?

Não, cara, acho que era isso.

Tem um ponto, acho que daí a gente pode até ir pros finalmentes. Quando você falou aquele ponto de ser muito difícil penalizar a empresa, essa relação com a empresa e tal e também do PPCA e dessa relação sempre, ou seja, a gestão pública trabalha numa lógica de desconfiança mútua sempre, a gente acha que a empresa vai ferrar a gente e a empresa acha que o contratante vai ferrar a gente. Como que você vê isso, claro que antes, ao formatar o TR você estava trabalhando com o pior cenário possível, você estava trabalhando na desconfiança, mas durante a execução do contrato, como é que você vê essa questão da confiança entre o órgão e a empresa fornecedora? Você acha que é alguma coisa que é essencial, é alguma coisa que os mecanismos formais do contrato dão conta e não necessariamente precisa…

Cara, eu acho que é o seguinte. Eu entendi. Eu acho que é o seguinte, eu acho que a gente tenta ver aqui de algumas formas diferentes isso aí. Primeira coisa é uma coisa de eu acho que responsabilidade do gestor. Então assim, cara, por exemplo. Eu tenho muita confiança na equipe. Hoje.

Só pra te ajudar, você falou ontem que ia falar quando chegasse nessa hora de divisão de responsabilidades.

Acabei de anotar isso agora. Que é o seguinte. Tem vezes que eu vejo lá com o pessoal e falo assim “cara, eu tenho total confiança no que…”. Por exemplo, esse lance do projeto de autenticação e tal, o pessoal, a primeira coisa que eles propuseram foi usar o Oauth2, e eu que virei e falei, porque eu já tinha experiência com um pouco de autenticação e tal, “por que o Oauth2 e não SAML?” Eu não me meto em decisão técnica, mas eu questiono as decisões técnicas. Então isso é uma coisa que eu converso muito com o pessoal técnico sobre isso, eu falo: “cara, não estou aqui pra passar por cima, decidir, não é isso, a decisão técnica é de vocês. Mas a minha função aqui é questionar. Então assim, eu quero saber porque a gente está usando o Oauth2 e não o SAML, do contrário eu não estou tomando uma decisão responsável”. Então nesse sentido eu acho que tem uma coisa assim de, é aquela coisa do trust but verify, você confia, mas você checa e não é porque você desconfia, é porque é a tua responsabilidade institucional, você está aqui pra isso. Aí um dia vem um TCU aqui “vem cá, você aprovou isso sem ler?” “não, cara, tudo que aprovado aqui a gente lê, tudo”. A única coisa que a gente não consegue fazer ainda é fiscalizar código-fonte, mas a ferramenta vai permitir isso em breve e vamos ver como é que a gente vai implementar isso. Então nesse sentido, sim. Outra coisa que eu converso muito com o pessoal é sobre alguns possíveis problemas de falta de confiança que, por exemplo. Em fábrica ou ponto de função, o cara na fábrica não tem… Você sabe aquela história, todo mundo se penaliza por alguém que tropeçou na rua aqui, mas ninguém se penaliza por milhares que morrem num país distante todo dia, porque você está mais perto? Eu acho que o lance da fábrica também permite mais isso. Então o cara está lá longe, então o cara está lá na fábrica, de repente a função do cara é inflar mesmo. Olha, meu, constrói isso aí da maneira mais custosa possível. E o cara não tem comprometimento nenhum com o órgão. O que a gente tenta fazer aqui é um espaço de comprometimento, um espaço, pô, de motivação, de não sei o que. E a gente conversa inclusive sobre isso, eu falo isso pro pessoal. Olha, a gente já teve duas conversas gerais aqui com a equipe, tá até na hora de fazer mais uma. Mas assim, a gente fala assim, “cara, esse modelo aqui nosso é o seguinte: todo mundo que está trabalhando bem vai tá faturando aí”. Ah, outra coisa que a gente botou no nosso TR: produtividade esperada são 7 USTs por dia e não 8, porque isso é outra ficção. Ninguém trabalha 8 horas por dia, o cara vai ao banheiro, o cara vai e conversa com alguém, toma um café e tal, enfim. Então a gente falou pro pessoal, todo mundo que queira estar trabalhando todo dia tem que estar faturando 7 USTs. Se você está trabalhando direito, tem que estar faturando 7 USTs. Se você trabalhou direito.

Mas a empresa também paga pra eles por USTs ou não?

Não, não…

O que significa pra um funcionário ouvir que ele vai faturar 7 USTs? Ele vai estar gerando pra empresa 7 USTs?

Exatamente. Você levantou um ponto muito bacana que é o seguinte. Que no ponto de função você não tem como calcular isso. Na UST esse cálculo é um pouco melhor. Na UST você sabe exatamente quanto cada funcionário está produzindo. Você sabe quanto o funcionário custa em UST, você sabe quanto que ele está produzindo em UST. E você sabe o seguinte: que, por exemplo, você precisa do sênior porque o sênior é o cara que vai te dar a direção, mas ao mesmo tempo o sênior ele custa mais caro, então quem dá mais lucro pra empresa na verdade é o pleno e o júnior. Então você tem que ter bons plenos e bons júniores e você tem que trazer os caras pra cima também. Então isso gerou um ciclo virtuoso aí. O meu único receio são as demandas compartilhadas entre duas pessoas, aí entrar na conta de um e o outro funcionário não ter nada, mas aí a gente já está criando, aí eu vou te mostrar a solução técnica pra isso. A gente vai criar um outro campo aqui pra permitir dizer quanto cada funcionário fez daquela demanda. Vou te mostrar aqui, é na ferramenta. Então o que acontece. Hoje, o funcionário aqui ele sabe mais ou menos quanto que ele está gerando pra empresa e a empresa está sempre debatendo isso. E eu não acho… Assim, o júnior, se você pensa bem o júnior talvez não precise, mas um cara que é analista sênior, o cara tem que estar com essa visão global também. O cara já é sênior, o cara tem que pensar sim na empresa, tem que pensar no… o cara está pensando em… Então não acho tão, não vejo tão ruim a gente conversar sobre o faturamento também com as pessoas. Todo mundo aqui é responsável pelo… isso é parte da responsabilidade e tal. Todo mundo aqui é responsável por tudo. A gente é responsável pela empresa estar bem, a gente é responsável pelos funcionários estarem bem, pelo órgão estar bem e pelo dinheiro público estar bem também, bem usado. Então uma coisa sobre a qual eu converso com o pessoal é isso. Olha, aqui, cara, a gente, não adianta inflar, não precisa fazer isso. Outra coisa, a coisa mais importante aqui é a confiança que a gente tem, enfim, é o ambiente de trabalho que a gente tem. Então a gente tenta fazer várias coisas. Por exemplo, uma coisa que eu já falei pro pessoal, a gente tem aqui muito interesse em prospectar novas tecnologias. Então eu já falei pro pessoal “cara, qualquer coisa que vocês quiserem aprender e tiver uma conexão com novas tecnologias que a gente possa usar aqui, você me pede que eu abro uma demanda”. Por exemplo, o Mongo foi o pessoal que sugeriu de usar. O Zend também, a gente não ia usar o Zend. O Apigility também, cara, quase tudo. Se você amanhã, por exemplo, tem muita gente lá nos Estados Unidos agora saindo do Angular e indo pro React. Falei pro pessoal: “aí, cara, vamos fazer um projeto em React, eu aprovo”. É bom pra mim, porque vou conhecer nova tecnologia, o órgão, vai ter uma nova tecnologia no órgão e você vai aprender uma coisa nova pra botar no seu currículo. A gente tenta criar um ambiente aqui, é o seguinte, que o funcionário ele vai ser mais leal ao órgão que à empresa. Porque… É isso, cara. E não é diferente do desafio de qualquer empresa, qualquer organização, cara. Se o teu funcionário não está vestindo a camisa, você vai ter problemas. Então, nesse caso é isso, essa confiança tem que ser, a gente tem a confiança, mas ela tem que ser mantida todo dia, mas sem… Ficou meio confusa a frase aqui, mas sem abrir mão da responsabilidade que eu te falei antes, a responsabilidade de verificar, a responsabilidade de questionar, de perguntar é essa. Vou te dar um outro exemplo, cara. A gente tinha um sistema entregue por fábrica aqui que a gente rodava pra homologar, o negócio estourava erro na tela. Cara, isso pra mim é o cúmulo da falta de qualidade. O pessoal aqui entregou, o primeiro sistema que eles entregaram não deu um erro de funcionamento. Zero. Mas deram vários erros de qualidade. Texto desalinhado, fonte errada no nosso padrão e tal. Eu contei mais de 40 itens no sistema todo, pequenos assim, desse tipo, mas não é nenhum errão grave. Só que eu falei pra eles “cara, a entrega de vocês está excelente, mas eu não vou aprovar uma coisa que eu sei que está errada, tem que corrigir. Então vambora, vamos corrigir”. “Ah, mas isso aqui não estava definido antes.” “Ah, não tava? Então tudo bem, erro nosso. Então entra como melhoria na próxima sprint a gente paga, se a gente não definiu. Mas isso aqui já estava definido, isso aqui já estava.” “Ah, tá, então beleza.” Aí eles faziam uma lista, o que que é incidente e garantia, a gente chama incidente aqui quando é garantia, o que que é incidente, o que que é melhoria. Então é esse sentido, sabe, é uma linha tênue você misturar confiança com a tua responsabilidade de verificar. Eu acho que o importante, a forma como eu vejo que o ágil prega é comunicação constante. Uma coisa que eu falo muito, o pessoal às vezes reclama da métrica, “pô, mas essa UST não tá medindo”, eu falo “cara, eu sei que métrica de software não é o ideal. Só que, infelizmente ou felizmente, a gente tem que usar alguma métrica, que é a regra IN 4, TCU e tal, então assim…” A gente brinca aqui, se você não quiser que, me ver levando uma multa do TCU, sei lá, a gente tem que… Vamos pegar a UST e fazer ela funcionar da melhor forma possível. Infelizmente é uma coisa… Quer usar o novo banco de dados a gente aprova, quer fazer prospecção a gente… Tudo a gente aprova. Agora, bagunçar a métrica não dá. Às vezes o pessoal pede assim, “cara, Gustavo, isso aqui eu preciso fazer um estudo”. Aí o pessoal pede um estudo, tem lá no TR, tudo bem, mas tá: 20 UST. Eu falei: por que 20? Não, vou fazer isso, isso, isso e isso. Ah, então escreve uma demanda. Pra você me pedir 20, por que 20? Eu não sei, por que não 21? Por que não 18? Como é que você chegou a… Então isso é uma coisa que a gente é muito claro em relação a isso também, que essa parte da métrica é, assim, a gente não abre mão porque não é decisão nossa. Então assim, tá meio confusa a resposta, mas é isso. É uma mistura de… Eu acho que assim, deixa eu refrasear isso, me dá só mais uma chance, última chance. Eu acho que é uma mistura de responsabilidade, não é porque eu estou exigindo uma coisa que eu sou obrigado a exigir que eu estou desconfiando. Você tem que colocar essa diferença. Às vezes eu falo isso nesses termos com o pessoal lá. “Gente, olha só, a gente aqui, pô, é gestor de um órgão público, dinheiro público, eu não posso aprovar isso sem uma explicação detalhada. A responsabilidade do meu emprego é fazer isso”. Se você coloca nesses termos o cara entende. Não adianta, você não precisa pegar e simplesmente “ah, mas peraí, por que que você…” Não é isso, é nesses termos. Isso com os funcionários. Em relação à empresa aí sim eu acho que a empresa tem vários incentivos pra, eu não vou dizer pra enganar, mas ela tem vários incentivos pra retardar ao máximo qualquer coisa que gere custo pra ela. Na verdade isso é qualquer empresa. Então o seguinte cara, se você não ficar no pé, eles não vão fazer. Então, por exemplo, a primeira advertência que eles tomaram foi por causa da ferramenta, como eu comentei. A segunda foi porque eles estavam atrasando a equipe, a contratação estava atrasada. Advertência. E naquela época a contratação já estava boa, eles estavam trabalhando bem, só que você tem que dar advertência pro cara se ele começou a sair, começou a entrar na zona de conforto você dá a advertência. A empresa anterior, a Cash, cara, levou não sei, umas 10 advertências, R$ 200 mil de multa, foi um negócio também. Só que quando chega também nesse nível ruim demais já não adianta, mas eu acho que é isso, é uma mistura.

E nessa coisa de responsabilidade, como é que vocês lidam na liderança dos projetos quando é oferta e demanda pra uma área finalística que não está aqui diretamente na área de vocês, como é que vocês lidam com isso?

Aí eu esqueci de falar. Aí a questão é responsabilidade pelo sucesso do projeto. Essa responsabilidade ela tem de ser compartilhada. Ela tem que ser compartilhada. Então assim.

A responsabilidade tem que ser compartilhada, então como eu te falei ontem, antigamente, na fábrica, ah, o gestor homologava o requisito, lembra que eu falei isso? Culpa nunca era de ninguém. Agora não, a responsabilidade tem que ser compartilhada. Então não deu certo uma sprint, não saiu do jeito que o usuário final queria, cara, vamos sentar e rever nosso processo. O que que a gente errou? Você tem que olhar como uma, é uma equipe só no fundo. A gente faz a gestão, a gente tem a responsabilidade de pagar, de grana, então é uma responsabilidade grande. Pessoal que está com a mão no código tem uma responsabilidade igual ou maior, não é? Pô, o cara está escrevendo o código. Uma responsabilidade enorme também. A área fim tem uma responsabilidade também. Mas é, acho que essa é a questão, a divisão de responsabilidade. Aí vem uma mudança de cultura que inclusive alguns dos nossos desenvolvedores ainda estão passando por essa mudança, muitos vieram de fábrica. Então o pessoal chega aqui e fala “pô, ô Gustavo, mas isso aqui não estava definido”, ou melhor, não é que não estava definido, “isso aqui estava implícito demais, a história não…”. Aí eu falei “beleza, mas o que que a gente vai fazer sobre isso? Porque não vai vir mastigado”. Ou você dá uma solução pra isso, o que você me sugere? Ou você vem falar comigo, ou você implementa o que o pessoal fez aí numa última sprint, que eu achei muito bom, é uma tela que a gente precisava e que a gente tinha esquecido. Tipo uma tela de erro, essas telas que você sempre esquece de fazer. Você pensa no caminho feliz e esquece de fazer a tela. O cara fez uma tela da cabeça dele. “Ó, fiz uma tela aqui só pra preencher. É uma tela em branco escrito um texto lá.” Beleza, você fez essa tela aí, preencheu. Agora na próxima sprint vamos corrigir essa tela. O cara não precisa parar “putz, não tem requisito pra essa tela”. Não, assume a responsabilidade. É isso que eu vejo.

E o papel da área de TI do órgão quando está intermediando a fábrica ou o ateliê com…

Então, o nosso papel é de PO. E PO assim, todo o sentido completo.

Mas vocês tem que entrar no negócio pra…

A gente entra no negócio. O pessoal técnico tem que entrar no negócio. Lembra que a gente não tem analista de requisito. Então quem vai entender o negócio, vai entender requisito é o próprio analista, é o cara que vai programar.

Ou seja, largar a área fim falando direto com a…

Cara, vou te dizer, em um ou outro caso acontece isso. Por exemplo, a gente tem um projeto aqui na área financeira que a gente está fazendo isso. Só que aí, cara, é um cara…

Que manja.

Tem 15 anos de experiência, está aqui há uns 4 anos, desde outro contrato e aí é um cara que eu confio pra caramba e ele, aí a gente conversa junto, tudo é aprovado previamente por mim. Então assim, continuo aprovando, mas quem vai conversar… Ele está sendo PO do projeto. O que, aliás, eu não acho um modelo tão ruim, colocar o PO na mão da empresa. Mas é muito delicado.

Da empresa não, da área de negócios.

Não, não. O PO na empresa. Porque é o seguinte: a área de negócios é a área que vai dizer os problemas e tal. Vai dizer, enfim, o que que eles precisam e tal. O PO é o cara que faz o meio-campo e, por exemplo no livro do Rubin e tal, o PO tem umas ações que são técnicas. Por exemplo, priorizar o backlog. Cara, priorização de backlog é uma atividade técnica, porque, por exemplo, eu posso por necessidade de implementação e de migração de dados, eu posso inverter a ordem das funcionalidades. “Putz, se eu fizer essa aqui primeiro eu ganho muito…” Então o PO tem que ser técnico, cara. É muito mais fácil você pegar um técnico e ensinar o negócio do que o contrário. Pelo menos nesse ministério e no governo como um todo. Muito mais, pô, o cara entender de TI tem que por aí 5, 10 anos de experiência. Então é muito mais fácil o contrário, então por isso que a gente aqui assume os projetos mais importantes nós tocamos aqui, nós somos os POs. Ah, mas é a área fim que vai usar. Sim, a área fim é um insumo, é um stakeholder importante. Ninguém vai fazer nada para irritar os caras, mas o PO somos nós, quem prioriza somos nós. Por exemplo, a gente teve uma conversa razoável com um dos nossos caras de negócio num projeto que ele não entendia a divisão sprint. O cara não entendia o conceito. “Pô, mas vamos fazer isso junto, a gente já tá fazendo isso”, cara, eu sei, eu falei pra ele “parece contraintuitivo. Parece ruim você dividir muito assim e lançar só…” “Mas a gente vai implementar só isso nessa sprint?” Parece, mas na verdade o ganho é muito maior depois. Hoje ele está supersatisfeito porque ele viu, cara… tem um, cara, toda semana, essa a gente está conseguindo fazer uma semana porque já está no ar, são só evolutivas. Então o cara vê, caraca, toda semana eu estou testando coisa, toda semana está entrando e tal. Então você vê que um cara desses da área fim não pode ser PO. O cara não sabe nem o que é sprint. O cara, às vezes… O PO da área fim eu não entendo… Eu sei que tem uma polêmica o PO em alguns congressos eu já vi o pessoal falando que o PO é como o unicórnio. O cara tem que ser tanta coisa que ninguém nunca vai achar o PO perfeito. Mas eu ainda confio mais em um cara da TI fazendo isso. Nesse caso que eu te falei, quem tá fazendo esse papel de ir lá na área, priorizar backlog e tal é o cara da empresa, só que ele valida tudo comigo e eu confio no trabalho dele. Houve duas sprints já desse projeto e na segunda sprint aí, olha o detalhe da fiscalização que é aquilo que a gente estava conversando antes, no final do segundo sprint já era pra eles usarem o sistema, que já teria um ganho palpável. Você viu que o negócio está rápido assim, no segundo sprint já teria… Aí ele foi lá e tal, pessoal ainda não quis usar porque falou que isso sem aquela outra… Aí eu falei: “então tá bom, vamos bancar esse risco, mas essa é a última”. Terceira sprint. Se a terceira sprint eles não usarem então vou dar mais um sprint de colher de chá. Se nessa terceira sprint eles ainda não começarem a usar a ferramenta e continuarem com essa enrolação de que não atende a eles a gente cancela o projeto. Então isso é uma outra coisa também que as áreas tem que poder fazer e aí entra, putz, cara…

Tem que entender que tem que se envolver, não vai ficar esperando sentado o negócio chegar…

Que tem que se envolver, mas olha, mais importante do que a área ter que se envolver é a TI ter que aprender a dizer não. Então isso aí entra um outro debate gigante que é o trabalho do chefe aqui da Dinfor, e ele faz um trabalho excelente disso, que é comitê estratégico, é alinhar tudo, dizer não. Então aqui, cara, a gente cancela muito projeto. Esse projeto mesmo vai ser cancelado. Sabe o que vai acontecer? Quer dizer, eu espero que não seja, eu espero que essa sprint resolva. Se essa sprint não resolver, ele vai ser cancelado. Aí, vão chiar. Aí de repente vão passar por cima de mim e ligar pro chefe aqui. Aí eu vou explicar a história. Aí a gente vai sentar, vai ter uma crise, eu vou falar “tá, então quem é o responsável, porque que se falou que depois disso ia começar a usar e não está usando ainda? Tá, então vocês vão dar a chance? Tá, beleza, a gente faz um sprint quatro e aí, aí sim ou vai resolver ou vai rachar”. Então já sei mais ou menos o… É mais ou menos essa a fórmula do que acontece. Então esse é um caso excepcional em que a gente tem um cara que está tocando o projeto com uma certa autonomia, mas é porque é um cara realmente excepcional e tal. E é um projeto também mais simples, mais restrito a uma área só e tal. Enfim, aí entra, não é o ideal, tá? Mas aí, porra, a gente toca esse desenvolvimento inteiro aqui com quatro pessoas, eu e mais três.

E você, pela tua experiência de TI do governo, essa postura que vocês têm aqui da área de TI ela é comum, ela é modus operandi?

De dizer não?

Não, de se envolver tanto na área de negócio, de dizer não…

Eu acho que não, cara. Acho que não, acho que a área de TI ela ainda é muito reativa. Ela ainda é uma área… Cara, pensa só. Que que é TI numa empresa privada? É o CIO, cara. O cara está lá sentado do lado do CEO, correto? Onde você vê isso no governo federal? Ah, o cara lá, chefe da divisão… Você vê, aqui é divisão, em outros órgãos é coordenação geral, departamento, no máximo, sei lá. Isso aí já mostra a percepção do que é TI no governo está completamente errada, completamente errada. Os caras não tem noção… Cara, onde é que já se viu falar em eficiência na administração pública sem TI? Sem governo eletrônico? Já ouviu falar que TI é área meio? É uma expressão completamente equivocada. As pessoas hoje lá não estão mais pensando, pessoal não pensa TI como área meio, eles nem, assim, em termos de organização, nem acho certo você pensar em área meio e área fim, acho mais certo você pensar em áreas em termos de mais codependência e menos codependência. Acho que essa é uma forma melhor de se pensar. Cara, o quão dependente o órgão é do elevador estar funcionando? Tem uma certa dependência mas não é vital. Ou as instalações físicas, ou a TI funcionando. As pessoas falam assim “a TI é só área meio”, é, mas quando a TI para ninguém faz nada. Então, porra, é uma área meio que está no caminho crítico. Então é diferente, sabe o caminho crítico, o PMBoK, o conceito? Então você tem o caminho crítico, no caminho crítico de um projeto qualquer coisa que falhar estraga tudo. Então você tem o caminho crítico e o caminho não crítico, então TI pode até ser um meio, mas está no caminho crítico. Então melhor não pensar em meio, cara. Então essa posição da TI está muito errada. Eu acho que, por isso que eu acho que as pessoas não estão, eu não acho que por aí você vai ver isso, que a gente tenta fazer aqui é isso, uma visão de TI como estratégia de negócio do órgão. Então pra você, como é que eu posso montar uma estratégia de negócio pro órgão, como é que eu posso montar um suporte tecnológico à estratégia de negócio se eu não conheço o negócio? Não tem… Aí vira uma TI reativa. Não, eu faço o que… Que é como a infra costuma operar muito assim ainda. Essas formas aí de trabalho de i2 e não sei o que ainda são muito reativas. Não, eu faço o que você pedir, abre um chamado lá no helpdesk e eu subo a sua VM. Cara, não tô pedindo pra você subir VM, eu quero DVOPS, faz o que tiver que ser feito pra isso. A infra ainda é muito reativa e a TI como um todo ainda é muito reativa. Não, claro você me diz o sistema que você quer… Aí entra o modelo de fábrica de novo. Modelo de fábrica é o modelo de um restaurante. Você tem um restaurante e os garçons. “Aí você quer o quê?” “Ah, eu quero um sistema assim e pá”. Aí eu jogo lá na cozinha a comanda, aí vem aquela coisa, aquele monstro. Tem um cara aqui da empresa que falou outro dia uma coisa muito engraçada, ele falou “vem um monstro, vem tipo o Kyodai”. Sabe o Kyodai, aquele monstro? Então é isso, vem um monstro. Você pede uma coisa, vem aquele monstrengo feito na fábrica, aí às vezes metade de um software é feito numa fábrica, metade… Não sei se você já teve essa experiência.

Não…

Parte é feita numa fábrica, parte é feita… Cara, vinha um negócio assim… Aí o layout muda no meio do sistema. Cara, vira um negócio, assim, terrível. Mas é isso, acho que é parte… Na verdade, assim, é porque a gente está fazendo aqui uma forma de entrevista, né. Mas tudo que você tiver de experiência que contradiga o que eu estou falando eu quero saber também, porque entender o negócio dá muito trabalho. Dá muito trabalho. Olha, a gente tem uma pessoa aqui que é especialista na parte de pessoal aqui do órgão, outra pessoa especialista na parte financeira, eu vou te dizer, outra pessoa especialista na parte de comunicações, eu vou te dizer que nesses sistemas a gente entende mais do negócio do que a própria área de negócio. Não sei se isso é bom, não sei se é correto pra área de negócio, mas pra gente aqui não tem outra forma, cara. Se você vai implementar, provisionar a TI pro negócio, você tem que entender o negócio.

Fale um pouco sobre o processo licitatório. Vocês cogitaram fazer licitação antes de optar pelo Pregão eletrônico?

A gente estava achando que não conseguiria montar um edital fechadinho o suficiente para que evitasse as empresas de jogarem o preço para baixo. Então a gente pensou que iria fazer o TR com o maior cuidado mas as empresas iriam dar uma de aventureiro e jogar o preço lá embaixo. Por isso achávamos que com uma licitação técnica e preço poderíamos ter um resultado melhor. Fomos ao TCU, na SEFTI (Secretaria de Fiscalização de TI), e eles foram muito abertos a tudo, eles mesmo são críticos ao ponto de função, mas eles não se convenceram da necessidade de fazer uma licitação técnica e preço. Acabamos achando que se fizéssemos técnica e preço estaríamos chamando uma atenção desnecessária. E no fim deu certo. Na licitação você teria que especificar os quesitos técnicos, e isso você pode botar como requisito no pregão também. O que você precisa evitar é alocar profissionais incompetentes no seu contrato. Se você tem requisitos rígidos de alocação de pessoal no seu contrato ajuda nisso. A questão da pesquisa de salário foi fundamental.

Temos que trabalhar com a ilusão de que não estamos contratando pessoas. Estamos contratando serviços. Ou nem isso, estamos contratando Pontos de função, ou USTs. Mas, na verdade, quem entrega esses serviços são pessoas, que serão alocadas no projeto, que trabalharão presencialmente aqui conosco. E para garantir a qualidade desse serviço, temos que garantir que sejam contratados bons profissionais.

Anúncios