Há um diálogo que se repete em praticamente toda organização pública, com variações de vocabulário e nenhuma variação de enredo.

A área finalística diz que a tecnologia não entrega. A tecnologia diz que a área finalística não sabe o que quer. Os dois estão parcialmente certos, o que é a pior configuração possível para resolver um problema: cada lado tem evidência suficiente para sustentar a própria versão e nenhuma das versões leva a uma solução.

Quando você abre esse diálogo, quase sempre encontra a mesma origem. A demanda chegou à TI já convertida em especificação. Alguém, em algum ponto do caminho, traduziu um problema de política pública para uma lista de funcionalidades, e a tradução se perdeu na conversão.

O custo invisível de pedir a coisa certa da forma errada

Especificar é confortável. Dá sensação de controle, cabe em documento, atravessa processo de contratação. O problema é que uma especificação carrega uma solução embutida, e a solução embutida costuma ser a primeira que ocorreu a quem escreveu.

O desperdício mais caro do setor público não é o sistema que atrasa. É o sistema que chega no prazo e ninguém usa.

Um problema bem declarado é mais desconfortável e muito mais barato. Ele diz qual resultado precisa mudar, para quem, e como saberemos que mudou. Deixa o caminho em aberto, o que permite que a solução final seja mais simples e mais barata do que a primeira ideia.

Três perguntas que mudam a conversa

  • Qual comportamento do cidadão ou do servidor precisa mudar para que a política funcione melhor? Se a resposta for uma tela, ainda não é uma resposta.
  • Como saberemos, em noventa dias, se a mudança aconteceu? Se não há indicador com linha de base, não há como avaliar entrega, só como avaliar cumprimento de prazo.
  • O que aconteceria se resolvêssemos isso sem tecnologia nova? A resposta costuma revelar o quanto do problema é de processo, de norma ou de comunicação.

Essas três perguntas não exigem conhecimento técnico. Exigem disciplina de gestão. E são justamente elas que quase nunca são feitas antes de um termo de referência ser escrito.

Por que ágil não resolveu isso

Muita organização adotou vocabulário ágil sem adotar a lógica que o sustenta. Entrega-se em ciclos curtos, mas o ciclo curto serve para acelerar produção, não para acelerar aprendizado. O sentido original de entregar rápido é receber retorno rápido e corrigir a hipótese antes que ela acumule complexidade, não produzir as mesmas funcionalidades em pacotes menores.

Quando a área finalística não participa do ciclo de aprendizado, não há retorno a ser recebido. Só há produção mais frequente da mesma coisa. É por isso que tantas organizações se declaram ágeis e continuam entregando sistemas que ninguém pediu de verdade.

Onde começar

Não apenas pela TI. Também pela formação de quem formula a demanda. Capacitar o dirigente finalístico a declarar problema, priorizar por valor e reconhecer quando precisa experimentar antes de contratar muda a qualidade de tudo o que entra na fila, e é a intervenção mais barata disponível.

A TI não precisa de mais capacidade de produção. Precisa de demanda melhor formulada. Esse é um problema de gestão, e problema de gestão se resolve com formação de gestor.