Porque é que desenvolver sistemas de informação no setor público é diferente - e o que raramente se discute

Há uma distinção que, na prática, decide o destino de muitos projetos públicos: digitalizar não é simplificar. Digitalizar é colocar um processo num ecrã. Simplificar é repensar o objetivo e desenhar o caminho mais eficiente para lá chegar.

E isto é especialmente sensível no setor público porque o serviço público não é “para a maioria”. É, por definição, para toda a gente - incluindo quem aparece com situações menos comuns, mais frágeis e mais difíceis de encaixar num fluxo normal.

O que raramente se discute não é que existem leis, escrutínio ou risco. Isso toda a gente sabe. O que raramente se discute é o efeito prático que isso tem na forma como desenhamos sistemas: como é que se cria um serviço simples para a maioria sem trair a universalidade, como é que se evita que o medo das excepções mate um MVP e como é que se decide com critérios quando quase nunca há métricas.

O problema de replicar o físico num ecrã

O erro mais comum é este: pegar no workflow físico e reencená-lo digitalmente, passo a passo, como se a ordem atual fosse “o processo” e não apenas uma solução histórica para um conjunto de riscos e constrangimentos que, muitas vezes, já mudaram.

O setor público está cheio de processos que existem por um motivo. Não são infundados. Foram moldados por contexto, limitações técnicas, riscos, jurisprudência, casos-limite. A experiência acumulada é valiosa. O problema começa quando tratamos essa experiência como um limite absoluto, em vez de um ponto de partida para redesenhar.

Redesenhar não é desrespeitar. É perceber porque é que o processo ficou assim e perguntar, com honestidade: este risco ainda existe? Este controlo ainda faz sentido? Esta sequência é mesmo necessária? Há formas melhores de mitigar o problema sem forçar toda a gente a passar pelo mesmo labirinto?

É aqui que a transformação, no setor público, deixa de ser um “produto” e passa a ser um projeto mais abrangente. Porque, se o objetivo for mesmo simplificar, pode implicar mudar práticas internas, redefinir responsabilidades e, em alguns casos, evoluir legislação. O que não faz sentido é a legislação entrar como desculpa para manter fluxos maus. A legislação devia focar-se no que é core e duradouro, não em detalhes de implementação que envelhecem em meses - por exemplo, cristalizar “o sítio da internet” onde algo foi disponibilizado.

O loop das excepções e o MVP que nunca nasce

Há um ponto que, para mim, separa um projeto que avança de um projeto que se arrasta: a gestão de excepções.

Em teoria, é simples dizer “temos de considerar as excepções, o serviço é para todos”. Na prática, o padrão repete-se: começamos a desenhar validações para proteger o sistema e garantir conformidade > aparece uma necessidade específica > alguém lembra-se de outra situação > a legislação “permite” que tudo seja identificável ou tratável e, de repente, o sistema deixa de ser um produto com um fluxo claro e passa a ser uma tentativa de antecipar o infinito.

O efeito é devastador para a entrega. Bloqueia libertações de código, chumba testes, impede um MVP, adia qualquer teste com utilizadores reais e impede recolher feedback sobre aquilo que, realisticamente, vai ser o caminho da maioria. O projeto fica preso na fase mais cara de todas: discutir sem dados.

E há um detalhe que torna isto ainda mais difícil no setor público: muitas destas excepções não estão escritas. Estão na cabeça de pessoas com muita experiência, que já viram casos raros e, por isso, sentem - legitimamente - que o sistema tem de estar preparado. Só que, sem números, o debate nunca acaba. É sempre possível descobrir mais uma coisa que “pode acontecer”.

Aqui nasce uma polarização perigosa. Ou hiper-simplificamos e ignoramos casos relevantes, ou ficamos hiper-focados nas excepções e o sistema nunca fica “bom o suficiente” para ser usado. O que falta no meio não é boa intenção mas um método de decisão sustentado em evidência.

O que significa decidir quando quase não há métricas

Acho que aqui está o coração do problema: no setor público, é muito difícil definir um limiar, porque a universalidade não é um slogan, é uma obrigação moral e prática. E muitas excepções pertencem precisamente a minorias que já têm limitações e/ou dificuldades. Se criarmos um fluxo que “funciona para a maioria” mas empurra os restantes para um beco sem saída, estamos a falhar o serviço público.

Ao mesmo tempo, tentar transformar todas as excepções em regras de negócio do fluxo principal é uma receita para paralisia. Um sistema nunca pode ser desenhado com foco nas excepções. Se for, transforma-se num mecanismo permissivo demais, uma “porta escancarada” onde entra tudo, com validações fracas, pouca previsibilidade e mais risco operacional.

O equilíbrio, quando existe, costuma ser construído com duas ideias simples.

A primeira é tornar os casos mais comuns o mais automáticos e simples possível. Não para “fugir” à complexidade, mas para libertar capacidade humana para o que é realmente complexo. A “espuma dos dias” deve ser tratada com fluidez, consistência e automatização. Os recursos humanos, que são cada vez mais escassos, devem estar concentrados nos casos de excepção, nos casos complexos e nos casos que exigem interpretação e responsabilidade.

A segunda é reconhecer que “serviço para todos” não significa “o mesmo caminho para todos”. Significa garantir que ninguém fica sem resposta. E isso pode implicar um canal de excepção bem desenhado, com triagem, rastreabilidade e critérios claros, em vez de tentar meter tudo no mesmo funil.

Isto não resolve o problema das métricas mas muda a conversa. Em vez de “vamos prever tudo”, passa a ser “vamos garantir que a maioria tem um percurso simples e que a minoria tem um percurso digno, seguro e operável”.

Responsabilidade: menos slogans, mais princípios aplicáveis

Quando se fala em “desenhar com responsabilidade” é fácil cair em frases bonitas. Eu prefiro olhar para referências concretas, precisamente porque nos obrigam a sair do discurso vago.

Em Portugal, o Mosaico (mosaico.gov.pt) tenta criar um modelo comum para desenho e desenvolvimento de serviços públicos digitais, com princípios orientadores e guias por perfil. A ideia, no fundo, é evitar que cada equipa invente o seu “Estado” e que os serviços fiquem inconsistentes entre si.

No Reino Unido, o GOV.UK Service Standard é citado por um motivo: não é um manifesto abstrato, é um conjunto de pontos que obriga equipas a pensar em utilizadores, acessibilidade, segurança, operação e melhoria contínua e até em publicar dados de desempenho.

A parte menos consensual é como estes standards são aplicados. Quando viram checklist para “cumprir”, criam burocracia nova e pouca melhoria real. Quando funcionam como linguagem comum e como ferramenta de decisão, ajudam a cortar ruído e a dar autonomia.

E isto liga diretamente ao tema das excepções. Um serviço pode ser simples e, ainda assim, responsável. Ser simples não é reduzir tudo ao mínimo, é remover fricção onde ela não protege ninguém e manter fricção onde ela é necessária para garantir justiça, segurança e confiança. Uma boa parte do trabalho está em decidir onde a fricção é intencional e onde é apenas herança.

No setor público, digitalizar sem simplificar é o caminho mais curto para informatizar o problema. Um sistema público não pode ser só um workflow físico com ecrãs. Tem de nascer do objetivo: o que é que queremos que aconteça para o cidadão, para a empresa, para a comunidade? A partir daí é que se reconstrói o processo, se avaliam riscos, se desenham excepções com dignidade e se cria espaço para testar com pessoas reais, em vez de tentar antecipar o infinito numa sala.

Às vezes parece que a solução é “simples”: levantar dados, medir, perceber as excepções e decidir. Em teoria, sim. Na prática, é aqui que o setor público nos puxa o tapete.

Muitos sistemas foram desenhados numa lógica em que existiam pessoas para absorver variabilidade. Se entrava um caso estranho, alguém avaliava. Se havia uma dúvida, resolvia-se com experiência. O serviço era universal porque o “sistema” não precisava de fechar tudo à entrada, havia capacidade humana para tratar o que escapava às regras. Só que isso tem um custo escondido: quando a triagem é humana e a decisão é distribuída, a estrutura do dado perde-se. As excepções existem, mas ficam diluídas em registos pouco normalizados, em notas, em decisões pontuais, em conhecimento tácito.

E chegamos à realidade atual: menos recursos, mais pressão, equipas a encolher, pessoas experientes a sair mais depressa do que entram outras, e uma expectativa crescente de que o sistema seja mais automático, mais consistente e mais justo. Começamos a querer fechar o funil - validar regras, impedir incoerências, não deixar “tudo entrar”. Faz sentido. Mas tropeçamos no mesmo ponto de partida: as regras que precisamos de automatizar nem sempre estão formalizadas nos sistemas atuais e os dados que nos permitiriam definir limiares com confiança não estão tão disponíveis quanto gostaríamos.

No fundo, voltamos ao início. Como é que se decide o que fica no fluxo principal e o que fica num canal de excepção quando o passado não está devidamente medido - precisamente porque, durante anos, a universalidade foi garantida por pessoas e não por regras? Não tenho uma resposta perfeita para isto. Se tivesse, provavelmente cometia menos erros. O que sei é que ignorar esta realidade só nos empurra para dois extremos: ou continuamos a desenhar portas escancaradas porque “o serviço público é para todos” ou tentamos fechar tudo por princípio e acabamos por excluir quem mais precisa.

Digitalizar sem simplificar é só pôr um problema antigo num ecrã novo.