Low-code para equipas de negócio: criar soluções sem depender de TI

Uma equipa de marketing pede à TI um formulário interno que ligue os pedidos de campanha ao calendário de produção. A resposta é que fica em fila. Quatro meses depois o formulário não existe e a equipa já resolveu o problema à sua maneira: uma folha de cálculo partilhada, três colunas de estado e um lembrete manual às sextas-feiras.

É neste espaço — entre o pedido que ninguém consegue atender e o remendo que ninguém assume — que o low-code para equipas de negócio faz sentido. Não como forma de dispensar a TI, mas como forma de deixar de a bloquear com pedidos que ela nunca vai priorizar.

Low-code não é "sem programadores", é "menos código"

A diferença entre low-code e no-code está no teto, não na dificuldade. Uma ferramenta no-code dá blocos prontos e acaba exactamente onde os blocos acabam. Uma ferramenta low-code dá os mesmos blocos e deixa escrever código nos pontos em que eles não chegam.

Isso traduz-se em detalhes muito concretos. No n8n existe um nó de código onde se escreve JavaScript ou Python a meio do fluxo. Na Power Platform há expressões em Power Fx dentro de campos que, à primeira vista, só aceitam cliques. Esse escape é o que decide se a solução sobrevive ao segundo pedido de alteração ou se morre nele.

Se ainda está na fase de escolher a família de ferramenta, a comparação entre no-code e low-code trata dos limites e do custo de saída de cada uma. Este artigo assume a escolha feita e trata do que vem a seguir: quem constrói, com que autonomia e até onde.

A fila da TI não anda por falta de vontade

O problema raramente é a prioridade que a TI dá ao pedido. É a aritmética de quem lá está.

Em 2023, 57,5% das empresas da UE que recrutaram ou tentaram recrutar especialistas em TIC tiveram dificuldade em preencher essas vagas, segundo os dados do Eurostat sobre vagas de difícil preenchimento. A dificuldade mais reportada nem sequer foi o salário pedido: foi a falta de candidaturas, referida por 43,24% dessas empresas.

Numa PME, isto significa uma ou duas pessoas de TI que passam o dia a manter o que já existe. O pedido do formulário de campanhas não está atrasado por ser pouco importante. Está atrasado porque está atrás do servidor de email, da migração do ERP e de um problema de backups.

A Gartner previa, em dezembro de 2022, que em 2026 pelo menos 80% dos utilizadores de ferramentas low-code estariam fora dos departamentos formais de TI, contra 60% em 2021. Estamos em 2026 e a previsão interessa menos do que a causa: não é entusiasmo pela tecnologia, é falta de alternativa.

O que uma equipa de negócio constrói mesmo bem em low-code

Um exemplo de escala pequena, que é onde isto compensa mais.

Uma equipa comercial de cinco pessoas recebe cerca de 70 pedidos de orçamento por mês, por email. Para cada um: abrir a mensagem, copiar os dados para uma folha, criar a pasta na drive, responder com um modelo e marcar o seguimento a sete dias. Cronometrado, dá cerca de 14 minutos.

São 980 minutos por mês, pouco mais de 16 horas. A um custo total de 25 € por hora — pressuposto declarado, não dado oficial; o método para calcular o valor real da sua empresa está no artigo sobre quanto custam os processos manuais — dá cerca de 400 € por mês em trabalho de copiar campos.

A versão low-code é modesta: um formulário substitui o email, o formulário escreve na folha ou no CRM, a resposta sai de um modelo e o seguimento fica agendado. Construída por alguém da equipa comercial com jeito para folhas de cálculo, em dois a três dias de trabalho repartidos por duas semanas. A TI entrou uma vez, meia hora, para autorizar a ligação ao CRM.

O padrão repete-se. Os processos que compensam a uma equipa de negócio são os que ela conhece ao pormenor e que a TI nunca vai conhecer tão bem: as excepções, quem aprova o quê, o cliente que exige o PDF com outro cabeçalho. Escrever essa especificação para outra pessoa a construir demora mais do que construí-la.

Onde o low-code trava

Quatro travões reais, que aparecem quase sempre pela mesma ordem.

O licenciamento escala por pessoa, não por uso. A página oficial de preços do Power Apps lista hoje o plano Premium a 22 USD por utilizador e por mês, pago anualmente, e 14 USD acima de 2000 lugares. O detalhe que apanha as equipas é outro: a tabela pública já só mostra planos por utilizador. Uma solução para seis pessoas é barata; a mesma solução alargada a 120 passa a ser uma decisão de orçamento, não uma decisão de equipa.

Há dados que estão do lado de dentro. Um ERP instalado em servidor próprio, uma base de dados sem API, um ficheiro que só existe na rede local. Aqui não há caminho sem TI — e é bom que não haja.

Volume e falhas mudam o problema. Um fluxo que corre 40 vezes por dia tolera que alguém repita a mão quando falha. A 40 000, é preciso pensar em repetições automáticas, duplicados e alertas. Isso já é engenharia.

A dívida técnica tem nome próprio. Um estudo publicado na MIS Quarterly Executive em 2024, baseado em 30 entrevistas com citizen developers e especialistas de plataformas low-code, resume o risco sem rodeios: entregar desenvolvimento a não-programadores traz qualidade abaixo do padrão, shadow IT e dívida técnica. E conclui algo mais útil — governar desenvolvimento cidadão não é igual a governar software tradicional, precisa de mecanismos próprios.

O acordo com a TI que faz o low-code funcionar

Não depender da TI para construir não é o mesmo que construir sem a TI. O que separa uma coisa da outra são quatro regras que cabem numa página.

• Um ambiente por equipa, nunca o ambiente por omissão. É aí que se aplicam limites de partilha, políticas de dados e verificação de soluções. A documentação de ambientes geridos da Power Platform descreve exactamente estes controlos, e o equivalente existe nas outras plataformas.
• Uma pessoa com nome como dona de cada solução. O pior cenário não é um fluxo mal feito: é um fluxo crítico que corre na conta pessoal de alguém que saiu da empresa.
• Uma lista curta de dados proibidos. Dados de saúde, dados de cartões, ficheiros de salários. Se o processo toca nisso, vai para a TI, sem discussão.
• Uma revisão trimestral de 30 minutos. Que fluxos existem, quantas vezes correram, quais já ninguém usa. Desligar o que morreu vale mais do que auditar o que vive.

Estas regras não travam a equipa. Travam a conversa de dois anos depois, quando alguém pergunta quem é que autorizou aquilo.

Um mês, um processo

A forma mais rápida de perceber se o low-code funciona na sua empresa é fazê-lo uma vez, pequeno.

1. Semana 1 — escolher um processo com dono claro, volume conhecido e nenhum dado sensível. Cronometrá-lo, sem estimativas de cabeça.
2. Semana 2 — construir a versão feia. Sem interface bonita, sem casos raros, só o caminho principal.
3. Semana 3 — correr em paralelo com o processo antigo. É desconfortável e é onde aparecem as excepções que ninguém mencionou.
4. Semana 4 — decidir: adoptar, corrigir ou deitar fora. Deitar fora ao fim de um mês é um bom resultado; arrastar durante seis meses não é.

O ponto crítico está na semana 3, e é de adopção, não de tecnologia. O artigo sobre desenhar um workflow que a equipa realmente adota trata das razões pelas quais soluções tecnicamente correctas são abandonadas ao fim de três meses.

A pergunta a levar à próxima reunião

Não é "podemos usar low-code?". Essa já tem resposta e a resposta é sim, com limites.

A pergunta é mais desconfortável: qual é o pedido que está na fila da TI há mais de três meses, quem na equipa o conhece melhor do que qualquer programador o conheceria, e o que é que impede essa pessoa de o construir esta semana — com um limite escrito de até onde pode ir sozinha?