A discussão sobre metodologias de desenvolvimento de tecnologia no setor público geralmente termina numa bifurcação improdutiva: defensores do waterfall apontam para a previsibilidade, a documentação estruturada e a compatibilidade com processos de compra governamentais; defensores do agile apontam para a capacidade de adaptação, a entrega incremental e a identificação precoce de problemas. Os dois lados têm razão. E é exatamente por isso que os governos digitais mais eficazes pararam de escolher entre eles.
O que é wagile no método governo ágil
O nome veio de um CIO de governo durante uma pesquisa sobre programas digitais públicos bem-sucedidos: “wagile”. A palavra combina waterfall e agile e descreve uma abordagem híbrida que não divide a diferença entre as duas metodologias, mas as coloca em sequência, aplicando cada uma onde ela funciona melhor.
A lógica é simples: diferentes fases de um projeto de tecnologia têm requisitos diferentes, e a metodologia deve seguir a fase, não o contrário. Nas fases iniciais de desenvolvimento, princípios ágeis fazem sentido: sprints iterativos, ciclos de feedback com stakeholders, incrementos funcionais entregues ao longo do tempo. Nas fases de operação em escala, a estrutura do waterfall oferece o que o governo precisa: documentação auditável, escopo definido, previsibilidade orçamentária.
Vale dizer que a metodologia Waterfall (ou método em cascata) é uma abordagem tradicional de gestão de projetos em que as etapas são executadas de forma linear e sequencial: cada fase só começa após a conclusão da anterior, sem sobreposição
Por que o waterfall persiste no governo
O waterfall não dominou os projetos de tecnologia governamental por inércia ou ignorância. Ele dominou porque resolve problemas reais do setor público. A documentação sequencial suporta auditorias e requisitos de conformidade. O planejamento detalhado cria entregas claras que sobrevivem à rotatividade de pessoal, uma constante em programas públicos onde a supervisão política muda a cada dois a quatro anos. A previsibilidade do waterfall é compatível com a forma como governos contratam projetos de tecnologia de grande escala: contratos de escopo fixo, com entregas definidas e prazos claros.
O problema é que o waterfall assume que uma agência pode saber, antes do início do projeto, tudo o que o sistema precisa fazer. Em transformação digital, onde tecnologias evoluem no meio do projeto, políticas mudam, necessidades dos cidadãos se transformam e ameaças de cibersegurança emergem em tempo real, essa suposição falha de forma crescente.
Por que o agile puro não resolve para um governo ágil
O modelo iterativo do agile se encaixa naturalmente na complexidade da transformação digital. Ele expõe problemas cedo, quando são menos custosos de corrigir. Mas as vantagens do agile no desenvolvimento comercial de tecnologia aparecem como passivos no contexto governamental. A redução de ênfase na documentação prévia pode conflitar com requisitos de auditoria. O escopo flexível pode criar imprevisibilidade orçamentária que não se alinha com estruturas de compra estabelecidas há décadas.
Como um CIO de governo entrevistado na pesquisa que gerou esse conceito disse: “Não podemos fazer agile como foi concebido, mas estamos fazendo o melhor possível dentro dos processos governamentais.” Essa frase captura o dilema com precisão. O problema não é o agile em si, é a tentativa de aplicá-lo de forma uniforme a um ambiente que tem requisitos de governança que o agile comercial não foi desenhado para atender.
O princípio mais importante do wagile
A metodologia wagile não é apenas um compromisso técnico entre duas abordagens. Ela reflete um princípio mais amplo que a pesquisa identificou como marca dos programas digitais governamentais mais bem-sucedidos: projetos falham quando aplicam um único framework a um programa heterogêneo.
Um projeto de transformação digital no governo não é uma coisa só. É uma sequência de fases com naturezas distintas: há a fase de descoberta e prototipagem, onde a experimentação é essencial; a fase de desenvolvimento iterativo, onde sprints e feedback funcionam bem; e a fase de implantação em escala e operação, onde documentação, auditabilidade e previsibilidade passam a dominar. Aplicar agile puro na fase de implantação em escala é tão problemático quanto aplicar waterfall puro na fase de descoberta.
Responsabilidade e adaptabilidade
O que o wagile oferece, quando implementado bem, é a possibilidade de ter as duas coisas: a adaptabilidade do agile nas fases em que ela importa e a responsabilidade do waterfall nas fases em que ela é exigida por lei, por contrato ou por boa gestão. A ideia de que governos precisam escolher entre inovar e prestar contas é um falso dilema, e o wagile é a refutação prática desse falso dilema.
Para gestores públicos brasileiros que enfrentam a pressão de modernizar sistemas legados sem abrir mão da transparência e da conformidade, o conceito oferece uma alternativa ao bloqueio típico: nem o waterfall rígido que nunca entrega, nem o agile puro que não sobrevive ao primeiro processo de auditoria. A solução está no sequenciamento inteligente, com a metodologia servindo à missão, e não o contrário.
Artigo adaptado de businessofgovernment.org
