Introdução

Nas partes 1 e 2 confirmamos como o EUC e o “God Excel” salvaram as operações no curto prazo, mas deixaram passivos para a organização no longo prazo. Neste artigo trazemos o foco para o presente e examinamos a luz e a sombra das plataformas modernas de desenvolvimento cidadão, como RPA e no-code/low-code.

Elas reencenam o God Excel e, ao mesmo tempo, carregam riscos ainda maiores em termos de escala e dependência. Para avaliar o impacto da IA generativa na próxima parte, precisamos entender corretamente sua natureza.

Série completa

Luz — por que foi abraçada

Rapidez imediata

Mesmo sem escrever código, é possível concluir rapidamente pequenas automações ou apps por meio de operações em GUI. Substituir tarefas diárias de cópia ou rotinas padronizadas em poucos dias é um ganho enorme para as equipes de linha de frente.

O poder de persuasão da visualização

Como fluxos e telas podem ser materializados de um jeito visual, até públicos sem conhecimento técnico conseguem entender. Para a alta gestão, ver um “desenho que funciona” gera grande sensação de segurança e muitas vezes se torna o fator decisivo para a adoção.

O primeiro passo pelos cidadãos

Em usos limitados, como formulários de entrada ou fluxos simples, mesmo quem não é engenheiro consegue criar algo próprio. Até aí, é possível sentir que “qualquer um consegue” e isso se torna a porta de entrada para expandir a base de desenvolvimento cidadão em toda a organização.

Sombra (1) — a “barreira profissional” que aparece na prática

À primeira vista parece que “qualquer pessoa consegue lidar”, mas ao tentar usar de verdade no dia a dia, acaba sendo exigida a mesma lógica da programação e a visão de design de um analista de sistemas.

  • Inevitabilidade das estruturas de controle Para separar o processamento conforme a condição de cada cliente, é preciso criar ramificações condicionais (If/Else). Para lidar com centenas de registros, estruturas de repetição (ForEach) são indispensáveis. Para lidar com atrasos ou erros de sistemas externos, é obrigatório prever tratamento de exceções (Try/Catch). Tudo isso está disponível em elementos de GUI, mas, na essência, continua sendo programação.

  • Compreensão da estrutura de dados Expandir JSONs ou arrays, mapear hierarquias e alinhar formatos de datas e números é inevitável nas integrações de negócios. Não basta substituir por uma tabela; sem entender a estrutura de dados, tudo desmorona.

  • Complexidade da integração entre sistemas Gerenciar a validade de tokens de API, garantir consistência ao atravessar múltiplos sistemas e evitar limites de taxa são os mesmos desafios da engenharia de software tradicional. A GUI só esconde isso — o grau de dificuldade é até maior.

  • Requisitos de operação e qualidade Sem projetar monitoramento, coleta de logs, gestão de diferenças entre ambientes de teste e produção e planos de rollback na hora da publicação, o caos chega rápido. Como não há código versionado, a observabilidade tende a cair.

Diante dessa barreira, é difícil para desenvolvedores cidadãos construírem e manterem sozinhos um sistema que aguente a prática real. No final, acabam dependendo de especialistas, mesmo que a capacidade da equipe técnica continue limitada.

Sombra (2) — vendor lock-in e dificuldade de migração

O God Excel ainda tinha algum alívio. Afinal, era um único arquivo. Os dados em formato tabular podiam ser exportados como CSV e, embora funções e macros ficassem presas ao Excel, existiam planilhas com alguma compatibilidade, e o código ou as funções eram interpretáveis. Já com RPA e no-code/low-code, os resultados ficam quase sempre aprisionados em UIs ou arquivos de configuração específicos da plataforma.

  • Migrar para produtos de outros fornecedores equivale, na prática, a “refazer tudo do zero”.
  • O encerramento de um serviço SaaS ou mudanças de especificação estão fora do controle do usuário e podem tornar irrelevante, da noite para o dia, o ativo acumulado.
  • Quando a construção é feita sobre PaaS, o ecossistema daquela nuvem prende o usuário, tornando extremamente difícil levar para outro ambiente.
  • Quando a lógica é definida via UI e não em código, localizar e investigar pontos problemáticos se torna custoso.
  • Dependendo do design da ferramenta, há casos em que é preciso dar duplo clique para ver o processamento interno, reduzindo ainda mais a legibilidade.

Comparado ao God Excel, que se encerrava em arquivos de planilha, o grau de dependência e o risco de virar passivo aumentam drasticamente.

Sombra (3) — o “viés da visualização” que confunde a gestão

Para quem é técnico, é óbvio que logo se esbarra na “barreira profissional” descrita acima. Mas executivos, ao verem fluxos e telas desenhados em GUI, tendem a pensar que “qualquer um consegue usar”.

Por quê? Porque, para a gestão, sistemas são normalmente caixas-pretas, e basta ver processos amarrados por setas ou formulários de entrada alinhados para achar que compreenderam a complexidade interna. Só que, na realidade, o que acontece por trás são as mesmas lógicas de controle e tratamentos de erro dos programas, e é indispensável conhecimento de engenharia para torná-los aptos ao uso prático.

Esse descompasso entre a “sensação de tranquilidade da gestão” e a “preocupação dos técnicos” acelera a adoção e, ao mesmo tempo, cultiva o passivo futuro.

Rumo à era do God Excel 2.0

Visto dessa forma, RPA e no-code/low-code repetem o mesmo padrão do God Excel. Salvam o dia a dia com rapidez, convencem a gestão com visualizações e, no fim, deixam um peso na organização por causa da caixa-preta e da dependência de pessoas específicas.

Mas há uma diferença decisiva: a escala do impacto. O God Excel se encerrava em arquivos isolados, enquanto o desenvolvimento cidadão moderno se integra à nuvem e aos sistemas centrais, podendo se tornar um passivo que amarra a organização inteira. Para piorar, a estrutura de lock-in é ainda mais rígida que a do Excel. Isso nos leva a uma situação que merece ser chamada de “God Excel 2.0”.

Conclusão

  • RPA e no-code/low-code foram aceitos porque oferecem rapidez e um poder de persuasão visual que agrada tanto à linha de frente quanto à gestão.
  • Contudo, para aguentar o uso prático, são indispensáveis conhecimentos de engenharia de software — estruturas de controle, estruturas de dados, integração de sistemas e design operacional — algo que desenvolvedores cidadãos sozinhos não conseguem sustentar.
  • UIs específicas de plataforma tornam a migração extremamente difícil e reforçam o vendor lock-in.
  • O “viés da visualização” da alta gestão leva a subestimar esses riscos.

No fim, o desenvolvimento cidadão moderno é tão poderoso quanto o God Excel — e ainda mais perigoso. Na próxima parte, veremos o que acontece quando a IA generativa entra nessa equação.

Próximo: Como a IA generativa afeta o desenvolvimento cidadão 4/7