No-code: 5 lições aprendidas em um projeto real 

Recentemente, liderei as frentes de Produto e UX no desenvolvimento de uma solução SaaS de IA para SEO, com um foco estratégico na adoção de tecnologias que acelerassem a busca pelo Product-Market-Fit (PMF) e pelo Minimum Viable Product (MVP). A abordagem escolhida também visava otimizar fatores cruciais, como a redução dos custos de desenvolvimento e a diminuição da curva de aprendizagem, garantindo um processo mais eficiente e acessível. 

Por isso, decidimos utilizar a seguinte stack de soluções para o desenvolvimento do software: 

1. Figma (prototipagem); 

2. Solução no-code para front-end web; 

3. A princípio íamos utilizar backend low-code, mas pivotamos e usamos tecnologia high code. 

Uma das principais vantagens dessa stack é que a velocidade de desenvolvimento do front-end seria muito maior por conta dos facilitadores, mas mantivemos o core da solução no backend em tecnologia high code, permitindo escala com melhor eficiência em cloud e flexibilidade. 

Posso explicar melhor o racional e quais opções nós cogitamos em um próximo post, mas vamos em frente aqui (comenta aqui se você gostaria de ler sobre isso). 

5 lições aprendidas com no-code: 

1. Velocidade maior: 

É indiscutível que uma solução no-code traz mais agilidade no desenvolvimento, acredito que reduzimos o tempo de desenvolvimento do front-end na ordem de 80%. 

Chega a ser bonito ver a facilidade que é criar as interfaces e os workflows, ainda mais quando você pode simplesmente utilizar um plugin e importar as telas diretamente do Figma. 

Se você é UX ou PM, imagine validar entregas e fazer ajustes de forma ágil. Melhor ainda: você mesmo pode criar as interfaces! 

Eu mesmo fiz isso diversas vezes ao longo do projeto. Muitas vezes, gastamos tempo documentando pequenos ajustes de usabilidade para que os desenvolvedores os corrijam, mas, nessa abordagem, bastava selecionar a camada e ajustar diretamente, sem intermediários. 

Tem um ponto positivo que vale destacar: 

O software no-code que usamos tem uma estrutura de auto-layout bem parecida com o Figma, se você domina Figma, vai tirar de letra. 

2. Existirá uma curva de aprendizagem: 

Existem poucos profissionais com experiência prática na utilização de tecnologia low/no-code no país. Isso significa que você provavelmente vai ter que treinar o time a lidar com essa tecnologia, e naturalmente isso vai gerar alguns erros operacionais, bugs, e vai fritar alguns neurônios. 

A curva de aprendizagem é bem menor que uma tecnologia high-code, mas vai levar um tempinho para você construir um time maduro. 

3. Você vai ter que repensar alguns processos: 

Gestão de equipes, branches, merges, servidores de homologação, deploys… 

Você vai ter que pensar nesses processos para garantir qualidade nas entregas e mitigar erros. Imagina alguém dar um “misclick” no software no-code e subir em produção uma branch errada… 

4. Problemas novos surgem: 

Nem tudo são flores, ao utilizar uma plataforma para desenvolver um software, você pode acabar ficando dependente da empresa que fornece a plataforma (o famoso vendor lock-in), por isso é importante escolher de forma consciente qual tecnologia você vai utilizar. 

No caso do software que escolhemos, é possível exportar o projeto em código, então se no futuro você quiser tirar da plataforma, é possível, apesar que nunca fiz isso, você já exportou um projeto em produção? Conta aqui como foi. 

Além disso, você começa a se deparar com problemas diferentes, por exemplo, tinha uma tela que possuía um comportamento que com um simples “for” resolvia no código, mas no no-code foi um desafio… 

Print de uma call onde estávamos tentando resolver esse problema: 

5. Vai haver quebras de paradigmas: 

Como em qualquer mudança, algumas pessoas poderão se sentir ameaçadas, com medo, ou resistentes. Você precisa encontrar pessoas dispostas a reaprender várias coisas, e a desbravar o novo. 

Não tivemos pessoas resistentes nesse projeto mencionado, mas já presenciei em outros ambientes pessoas que ainda acreditam que essas soluções não escalam e que não funcionam. 

Conclusão 

O uso de ferramentas low-code/no-code, como o WeWeb, tem nos ajudado significativamente a acelerar experimentações e o desenvolvimento de software. No entanto, nem tudo são flores: ao longo do caminho, tivemos que repensar diversos processos de DevOps, à medida que surgiam nuances específicas de se manter um software low-code em produção. 

O verdadeiro desafio de qualquer negócio está em entender profundamente as necessidades dos clientes e encontrar maneiras eficazes de aumentar o engajamento, o valor percebido, a aquisição e a retenção. 

Além disso, todo produto de software carrega um custo muitas vezes negligenciado: o custo de oportunidade. Esse custo representa o tempo e os recursos que decidimos investir em uma determinada iniciativa (tempo que poderia estar sendo direcionado a outras apostas potencialmente mais valiosas). 

Ao acelerar o desenvolvimento com low-code/no-code, conseguimos reduzir substancialmente esse custo, permitindo que o foco da equipe esteja onde realmente importa: gerar valor para o cliente, e não apenas escrever código.