4.1.3 Decisões por métricas e entregas contínuas

Um dos pontos levantados, tanto pela empresa, quanto pelo órgão, foi a dificuldade na implantação de entregas contínuas, ou seja, de lançamento de novas versões do portal em curtos espaços de tempo.

Aqui, os ambientes de hospedagem do SERPRO são mais burocráticos. Então quando você faz uma mudança de escopo e altera o desenvolvimento, há todo um procedimento para que aquilo vá para produção e a gente consiga testar aquela hipótese. O que a TW fez foi justamente tentar mudar essa cultura e implantar a entrega contínua. Um dos grandes ganhos do projeto foi, com a equipe de infraestrutura, tentar fazer com que esse caminho fosse automatizado, desde a alteração do código até sua efetiva implementação em produção. Acho que essa é uma das coisas mais complicadas dentro do governo para que você tenha a metodologia ágil implementada de fato.1

Esta dinâmica inviabilizou uma real entrega contínua e ágil e acabou por desmotivar práticas mais constantes e proativas de coletas e análise de estatísticas para balizar as tomadas de decisão rápidas. “Porque o legal é você ver o dado quente, fazer a mudança e já ver o resultado (…) Se a gente fosse pra produção2 uma vez por semana já dava mais calor de fazer isso. Mas a gente vai a cada mês, mês e meio. Desanima3.” Além disso, a prática de desenvolver um sistema capaz de gerar estatísticas ricas de uso gera mais trabalho de desenvolvimento do que um sistema sem essas características. Por esse detalhe metodológico não estar previsto em nenhum escopo, que normalmente só se preocupa com a descrição das funcionalidades, esse trabalho era “embutido” no desenvolvimento, e nem sempre valorizado. Logo, com o tempo, o esforço de se colher estatísticas e tomar decisões baseadas em dados empíricos foi perdendo força.

O primeiro exemplo dessa dificuldade foi percebido logo nos primeiros dias em que o novo portal estava no ar. Por meio do monitoramento dos serviços, os desenvolvedores perceberam um fluxo de pessoas muito grande acessando o portal em busca das inscrições pelo Exame Nacional do Ensino Médio (Enem). Perceberam que o portal do Ministério da Educação (MEC) estava com problemas de lentidão, possivelmente devido a sobrecarga de visitas, e muitas pessoas não conseguiam acessar seu conteúdo. Contudo, essas pessoas conseguiam ver o link para o portal de serviços na “barra Brasil”, e clicavam na esperança de encontrar o formulário de inscrição. Uma vez no portal de serviços, encontravam a página que descrevia o Enem, mas não havia nenhuma informação útil ali, nenhum link, e elas se frustravam.

A gente tinha feedback suficiente para saber que isso era um problema em quatro horas de site no ar. Se a gente soubesse que a gente podia ir pra produção com uma versão nova do conteúdo, uma coisa mais bem descrita, se a gente tivesse acesso a quem pudesse descrever o serviço do Enem melhor na hora e ir pra produção com aquilo, a gente tinha ajudado e economizado não sei quantas mil horas e deixado de frustrar não sei quantos milhares de brasileiros. Quando isso não aconteceu e a gente viu que não tinha muito bem um plano pra fazer com que isso parasse de ser um problema, aí a coisa deu uma esfriada.4

Até aqui analisamos, a partir da narrativa da área requisitante e da equipe de desenvolvimento, as principais dificuldades encontradas em se trabalhar com metodologias ágeis e com a abordagem enxuta no governo federal brasileiro. A partir desta análise conseguiremos avaliar de que maneira estes projetos conseguiram, ou não, adotar as melhores práticas identificadas (Quadro 4).

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

2“Ir para produção” e um jargão de TI que significa “colocar no ar”, “publicar uma nova versão do software no ambiente de acesso público”

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

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

ÍNDICE

Anúncios