Metodologia de desenvolvimento e métricas

A equipe do MRE, após alguns anos utilizando outras metodologias de desenvolvimento, avaliou que as metodologias ágeis eram as mais adequadas para a natureza do trabalho no órgão. Segundo sua visão, metodologias de desenvolvimento em cascata, como a RUP, possuem processos muito rígidos, desnecessários para os projetos do Ministério. A vantagem dessas metodologias, que são o alto grau de controle dos processos, a rastreabilidade das mudanças e a confiabilidade, não compensam a grande perda em outras áreas, como a agilidade das entregas e o aumento do custo para se realizar mudanças.

Por exemplo, é comum com essas metodologias um processo de meses, até um ano, apenas levantando os requisitos de um software que será desenvolvido. Com todo esse tempo de planejamento, muitas vezes se corre o risco de se desenvolver uma aplicação obsoleta, já que os processos e os dirigentes mudam regularmente. Além disso, na visão deles, requisitos não devem ser coletados, mas construídos em conjunto com os futuros usuários do sistema.

Finalmente, entendem que essas metodologias tendem a dividir o processo de desenvolvimento em etapas artificiais, que não podem ser divididas: planejamento, desenvolvimento, testes e implantação. Na visão deles, e nos defensores das metodologias ágeis, essas etapas acontecem simultaneamente.

Para enfrentar essa questão, decidiram colocar expressamente no TR qual seria a metodologia de desenvolvimento adotada. Baseados na metodologia Scrum, descreveram passo a passo os processos e os papéis dos atores envolvidos. Dessa maneira, as empresas que participassem do processo de seleção estariam cientes e de acordo com a metodologia proposta.

Em seguida veio o desafio de se escolher a métrica utilizada para mensurar as entregas do contrato. A IN04, assim como outros decretos e acórdãos do TCU, orientam que os contratos dessa natureza devem ser remunerados por resultados obtidos, sendo vedada a

contratação de postos de trabalho (alocação de um profissional, por tempo determinado, sem vínculo com entregas de valor concretas a não ser a sua mão de obra).

Normalmente nos contratos de fábrica de software, isto é feito por meio de uma métrica consagrada chamada “pontos de função”. A equipe do MRE enxergava uma série de problemas com essa metodologia. Em primeiro lugar, por entender que não é possível exigir qualidade a partir de uma métrica baseada puramente em funcionalidades. Para exemplificar este ponto, Maultasch traz a questão da preocupação cada vez mais presente com a experiência de usuário e a usabilidade dos sistemas. Com pontos de função, é simples medir quanto custará um cadastro, com telas de inserção, edição e consulta, no entanto, esta métrica não considera nenhum elemento que se preocupe com a usabilidade do sistema. “[A experiência do usuário] é o grande diferencial de um software. Não conseguir medir isso, e o que é pior, remunerar a empresa por isso, está errado”101_{, afirma.}

Maultasch avalia, também, que é impossível gerenciar algo se não é possível ter uma boa visibilidade do que está sendo feito. Na métrica do ponto de função, não é possível saber o que foi gasto de energia em diferentes etapas do processo, como design, desenvolvimento de back-end, de front-end e etc. Dessa maneira, fica difícil identificar gargalos e definir prioridades. Segundo ele, a resposta que boa parte da TI tradicional dá a essa questão é a de que não é preciso gerenciar neste nível da produção, já que o que está sendo contratando é o resultado final, e pouco importa como a empresa fará para entregá-lo.

No entanto, se a licitação foca apenas no resultado, a empresa pode encontrar uma maneira de entregar produtos de má qualidade, mas que são incontestáveis do ponto de vista contratual. Acrescente a isso o fato de a empresa saber que é muito custoso para o gestor público penalizá-la, já que advertências e multas são processos trabalhosos para uma rotina de trabalho já bastante atribulada e cancelar um contrato é algo praticamente impensável por tudo que isso implicaria, como um processo administrativo e um plano de contingência, entre outras coisas. Segundo Maultasch, esses fatores podem levar, e comumente levam, a empresa a se acomodar e entregar o "pior possível contratualmente aceitável".

Para enfrentar este problema, além de definir no Termo de Referência a metodologia de desenvolvimento que seria utilizada, o MRE também definiu uma nova métrica, a UST – Unidade de Serviço Técnico. Baseada em um contrato já realizado pelo Datasus com esta métrica, o MRE definiu que uma UST equivale a uma hora de serviço. Cada demanda aberta seria estimada pela empresa contratada e, caso aprovada, desenvolvida e faturada de acordo com a estimativa.

Na verdade é um processo bastante similar ao praticado com pontos de função, mas ao se utilizar uma medida própria, baseada em horas, o MRE teve liberdade para começar a construir o que chamaram de “repertório de estimativas”, que é um cardápio com tarefas comuns e uma referência de estimativa para cada tarefa. No TR foi apresentada uma primeira versão deste repertório, para que as empresas tivessem alguma referência dos valores que seriam praticados, e indicou-se que este repertório seria periodicamente revisto e ampliado.

Isso tem permitido que o órgão, em conjunto com a equipe de desenvolvimento, construa um acúmulo de aprendizados sobre as práticas de desenvolvimento naquele contexto. Além disso, permite que o MRE valorize e remunere aspectos que são valiosos para a organização e que são recorrentemente ignorados pelos contratos, como a já mencionada experiência de usuário e o desenvolvimento de testes automatizados.

Nesta seção vimos como o MRE atacou as deficiências que enxergava nos modelos tradicionais de metodologias de desenvolvimento de software e de métricas. De um lado, explicitando a adoção de metodologias ágeis no TR e, de outro, criando uma métrica própria que os deu flexibilidade para criar um repertório próprio de estimativas, que evolui e se enriquece com o tempo e que pode remunerar os resultados que a organização achar por bem valorizar, sem ficar presa a uma tabela pré-fixada de uma metodologia externa. As críticas aos modelos tradicionais se baseiam fundamentalmente na ideia de que, se o contrato se focar apenas nos resultados, sem se preocupar com o processo de trabalho, o gestor pode ficar refém de entregas que são incontestáveis do ponto de vista formal, mas de péssima qualidade.