Desenvolvimento Low-Code/No-Code em Órgãos Públicos
Gabarito: letra C. A abordagem que melhor aproveita o potencial do low-code/no-code no setor público é a de fusion teams, em que desenvolvedores e analistas de negócio colaboram em plataformas low-code, respeitando políticas de segurança, escalabilidade e interoperabilidade. Essa é a estratégia que equilibra a agilidade das plataformas com as exigências de governança e integração típicas da administração pública.
O desenvolvimento low-code/no-code representa uma mudança de paradigma na engenharia de software: em vez de escrever código linha por linha, os desenvolvedores (e, cada vez mais, usuários de negócio) constroem aplicações por meio de interfaces visuais, arrastando e soltando componentes, configurando fluxos e integrações. O objetivo central é acelerar a entrega de valor, reduzindo a barreira técnica para a criação de soluções. No contexto de um órgão público, essa agilidade é especialmente atraente, pois permite responder rapidamente a demandas internas e da sociedade. No entanto, o setor público impõe restrições severas: segurança da informação, conformidade com a LGPD, interoperabilidade entre sistemas legados e escalabilidade para atender a muitos usuários. Ignorar essas restrições em nome da velocidade seria um erro grave.
A literatura e as boas práticas de mercado convergem para o modelo de fusion teams (equipes fusionadas) como a forma mais eficaz de adotar low-code em ambientes corporativos complexos. Nesse modelo, não há uma separação rígida entre quem "entende de negócio" e quem "entende de tecnologia". Em vez disso, analistas de negócio e desenvolvedores trabalham lado a lado, cada um contribuindo com sua expertise. Os analistas de negócio, que conhecem profundamente os processos e as necessidades dos cidadãos, podem construir rapidamente protótipos e fluxos usando as ferramentas visuais. Os desenvolvedores, por sua vez, garantem que essas soluções sejam seguras, escaláveis, mantenham a integridade dos dados e se integrem corretamente aos sistemas legados. Essa colaboração é o que permite aproveitar a velocidade do low-code sem comprometer a robustez exigida no setor público.
A alternativa A, embora pareça razoável, propõe uma abordagem mais limitada: as equipes de negócio constroem fluxos com suporte técnico apenas em pontos críticos. Isso cria um risco de que as soluções desenvolvidas não sigam os padrões de arquitetura, segurança e interoperabilidade do órgão, gerando problemas de manutenção e integração no futuro. A alternativa B, por sua vez, restringe o no-code ao front-end, o que desperdiça o potencial da plataforma e cria uma separação artificial que dificulta a colaboração. A alternativa D foca em protótipos descartáveis que não se integram aos sistemas legados, o que é contrário à necessidade de soluções sustentáveis e integradas. Por fim, a alternativa E centraliza o desenvolvimento em programadores experientes, usando low-code apenas para documentação, o que não aproveita o potencial de empoderamento das equipes de negócio.
A pegadinha desta questão está em confundir "aproveitar o potencial" com "deixar os não-técnicos fazerem tudo sozinhos" ou com "usar low-code apenas para tarefas simples". A banca explora a tensão entre agilidade e governança. A resposta correta é a que integra ambos os mundos, reconhecendo que o low-code é uma ferramenta poderosa, mas que precisa ser orquestrada dentro de uma estratégia maior de TI. O critério decisivo para separar as alternativas é: a abordagem promove colaboração entre negócio e TI, respeitando as políticas de segurança, escalabilidade e interoperabilidade? A única alternativa que atende a todos esses critérios é a C.
Alternativa A — ❌ Incorreta
Embora reconheça o papel das equipes de negócio, esta alternativa limita o suporte técnico a "pontos mais críticos". Isso é insuficiente: em um órgão público, a segurança e a integração são preocupações transversais, não pontuais. Soluções construídas sem supervisão técnica adequada podem violar políticas de segurança, criar problemas de interoperabilidade e gerar dívida técnica. A abordagem correta exige colaboração contínua, não suporte esporádico.
Alternativa B — ❌ Incorreta
Restringir o no-code ao front-end e manter todas as regras de negócio no código tradicional é uma visão limitada e contraproducente. Isso não aproveita o potencial das plataformas, que são capazes de modelar processos e regras de negócio de forma visual. Além disso, cria uma separação artificial que dificulta a colaboração entre equipes de negócio e TI, exatamente o oposto do que se busca com low-code.
Alternativa C — ✅ Correta ⟵ GABARITO
Esta alternativa descreve com precisão o modelo de fusion teams: desenvolvedores e analistas de negócio colaboram usando plataformas low-code para criar soluções integradas. O texto menciona explicitamente o respeito às políticas de segurança, escalabilidade e interoperabilidade, que são os pilares para uma adoção responsável de low-code no setor público. É a abordagem que equilibra velocidade e governança, aproveitando o melhor dos dois mundos.
Alternativa D — ❌ Incorreta
Priorizar protótipos rápidos e descartáveis, mesmo que não se integrem aos sistemas legados, é uma estratégia de curto prazo que não atende às necessidades de um órgão público. Soluções descartáveis geram retrabalho, desperdício de recursos e não contribuem para a modernização dos serviços. A integração com sistemas legados é um requisito fundamental para a sustentabilidade das soluções.
Alternativa E — ❌ Incorreta
Centralizar o desenvolvimento em programadores experientes e usar low-code apenas para documentação é um desperdício do potencial da plataforma. O low-code não é uma ferramenta de documentação; é uma plataforma de desenvolvimento. Essa abordagem não empodera as equipes de negócio e não acelera a entrega de valor, que são os principais benefícios do low-code.
Gabarito: letra C