Nossas Visões

Os sistemas de informação do governo não falham porque a tecnologia é “muito difícil”. Eles falham porque o problema não está definido, os usuários não são compreendidos e as decisões são adiadas até que o projeto se transforme em um alvo móvel. Uma janela de planejamento de 90 dias força a disciplina: você não tem tempo para a perfeição — você precisa de escolhas claras, um escopo realista e um plano que possa ser construído.

Este artigo apresenta um roteiro mínimo viável: o menor conjunto de etapas e resultados que tornam um sistema de informação governamental financiável, comprável e implementável, sem sobrecarregar as equipes na papelada.

O que “roteiro mínimo viável” realmente significa

Um roteiro não é uma apresentação de slides com aspirações. É uma ferramenta de decisão.

Em 90 dias, seu objetivo é produzir clareza suficiente para que a liderança possa aprovar a direção, os detentores do orçamento possam ver os fatores de custo, a TI possa validar a viabilidade e a área de compras possa lançar uma licitação confiável. Se seus resultados não puderem ser usados para tomar decisões, eles não são resultados do roteiro, são documentação.

O benchmark é simples: no Dia 90, você deve ser capaz de responder, em linguagem simples, o que estamos construindo, para quem serve, como funcionará, quanto custará, como o entregaremos e como mediremos o sucesso.

A estrutura de 90 dias (sem penugem)

Pense no trabalho em quatro sprints. Cada sprint termina com resultados concretos que reduzem o risco.

Dias 1 a 10: Alinhe o propósito e a autoridade

Comece identificando o “porquê” e o “quem decide”. É aqui que muitos projetos fracassam silenciosamente: cinco agências compartilham o mesmo sistema, mas ninguém é dono das decisões.

Você quer um breve estatuto do projeto que nomeie o patrocinador, o proprietário do produto, o modelo de governança e a cadência da decisão. Combine isso com uma descrição clara do problema (o que está quebrado hoje, para quem e a que custo). Se você não consegue escrever em meia página, não está pronto para criar nada.

Dias 11 a 30: Descubra usuários, processos e restrições

Esse sprint é sobre a realidade. Você mapeia o serviço como ele existe: jornadas do usuário, etapas do processo, gargalos e pontos problemáticos dos dados. O objetivo não é documentar tudo, é identificar os poucos momentos que geram 80% dos atrasos, reclamações ou vazamentos.

Ao final desse sprint, você deve ter jornadas de usuário validadas, uma lista restrita de casos de uso prioritários e uma visão clara das restrições que moldarão a solução: obrigações legais, proteção de dados, limites de conectividade, sistemas legados e capacidade operacional.

Dias 31—60: Projete o “sistema mínimo viável”

Agora você traduz as necessidades em algo edificável. A mudança mais importante aqui é a disciplina: seu sistema deve oferecer um serviço mínimo viável, não todos os recursos que todas as partes interessadas desejam.

É aqui que você define os requisitos funcionais de uma forma que as compras e os fornecedores possam precificar, mantendo espaço para iteração. Você também decide com antecedência se vai criar, comprar ou configurar, e quais integrações não são negociáveis. Um diagrama de arquitetura simples que mostra fluxos de dados e propriedade geralmente é mais útil do que 40 páginas de texto.

Até o dia 60, você quer um esboço de plano de solução: escopo, módulos, funções, esboço do modelo de dados, necessidades de integração, abordagem de segurança e um modelo operacional realista para a instituição que o administrará.

Dias 61 a 90: Transforme o plano em algo que possa ser financiado e adquirido

É aqui que os roteiros se tornam reais. Você converte o plano em um plano de entrega: sequenciamento, recursos, custos, estratégia de aquisição e governança de implementação.

Fundamentalmente, você define o que significa “feito”. Se você não conseguir medir a adoção e a qualidade do serviço, acabará medindo apenas resultados como “número de treinamentos ministrados”. Seu pacote Day-90 deve incluir KPIs, uma abordagem de monitoramento e um plano de gerenciamento de mudanças que trate a adoção como uma característica do produto, não uma reflexão tardia.

Os resultados que mais importam (e por quê)

Um roteiro de 90 dias não precisa de centenas de páginas, mas precisa de alguns artefatos de alta utilidade:

1) Uma narrativa de serviço de uma página.
O que o sistema fará, para quem e o valor que ele desbloqueia. É isso que os altos funcionários lembram e repetem.

2) Uma lista dos “10 principais” casos de uso com critérios de aceitação.
Se o sistema não puder fornecer esses casos de uso de forma confiável, não é o sistema certo.

3) Uma nota de dados e interoperabilidade.
Quais conjuntos de dados existem, quais não existem, quem os possui e o que precisa ser integrado com o quê. Isso evita surpresas caras mais tarde.

4) Uma linha de base de segurança e privacidade.
Não é uma auditoria completa, apenas padrões mínimos claros: controle de acesso, registro, resposta a incidentes, requisitos de hospedagem e restrições de conformidade.

5) Um roteiro de entrega com custos e rota de aquisição.
Fases, suposições de pessoal, faixas de CAPEX/OPEX e o que pode ser contratado agora ou posteriormente.

Esses resultados criam viabilidade financeira porque reduzem a incerteza — o principal motivo pelo qual as compras públicas de TI atraem ofertas fracas ou preços inflacionados.

Armadilhas comuns (e como evitá-las)

Armadilha 1: Tentar digitalizar o caos.
Se o processo subjacente for interrompido, digitalizá-lo apenas agiliza a falha. Na janela de 90 dias, concentre-se na “melhoria mínima viável do processo” para os maiores pontos problemáticos.

Armadilha 2: Tratar a consulta às partes interessadas como uma construção de consenso.
Você não precisa que todos concordem — você precisa que todos sejam ouvidos e tenham uma autoridade clara para decidir. A governança é a espinha dorsal do produto.

Armadilha 3: ignorar o modelo operacional.
Um sistema sem um proprietário real, linha orçamentária, capacidade de suporte e administração de dados é um piloto que nunca se expande. Defina a casa institucional com antecedência.

Armadilha 4: requisitos de redação que nenhum fornecedor pode precificar.
Evite uma linguagem vaga como “moderna, robusta e fácil de usar”. Traduza isso em requisitos mensuráveis: tempo de resposta, tempo de atividade, padrões de acessibilidade, registros de auditoria, funções do usuário, necessidades de geração de relatórios.

Como isso acontece na prática: uma nota da experiência de Aninver

Em nossas tarefas digitais e do setor público — desde a manutenção da plataforma web CPIA do Banco Africano de Desenvolvimento até a criação de programas digitais de treinamento e capacitação no Caribe e o apoio a instituições públicas com plataformas web e ferramentas de comunicação digital — o padrão é consistente: os projetos avançam mais rapidamente quando as equipes se comprometem com um escopo mínimo viável, uma governança clara e dados utilizáveis desde o primeiro dia.

Se sua instituição está planejando um sistema de informação e quer um roteiro que possa realmente ser adquirido e implementado, explore mais o trabalho e os artigos da Aninver sobre transformação digital e entrega ao setor público, onde compartilhamos abordagens práticas, lições aprendidas e ferramentas que ajudam os projetos a passarem da intenção à execução.