4 maneiras de usar o desenvolvimento de low-code para a sua vantagem

Se ainda não adotou o desenvolvimento de low-code, aqui estão quatro formas de assegurar os seus benefícios comerciais.

As plataformas de low-code (e no-code) como Gartner prevê que representará 65% da atividade de aplicação até 2024. Como já escrevi anteriormente, uma grande parte desta popularidade deve-se à promessa de que as ferramentas de low-code permitem a um utilizador empresarial médio (também conhecido como desenvolvedor cidadão) criar aplicações sem precisar de compreender como escrever uma linha de código. O resultado é uma explosão na quantidade – embora não necessariamente na qualidade – das aplicações.

O que é frequentemente ignorado é que as ferramentas e plataformas de low-code oferecem vantagens ainda maiores para programadores profissionais e departamentos de TI. Se ainda não adoptou o desenvolvimento de low-code, aqui estão quatro formas de o fazer pagar por si:

1 – Acelerar os ciclos de desenvolvimento.
Mesmo que seja um ninja codificador, deve tirar partido de qualquer ferramenta que ajude a acelerar o trabalho de desenvolvimento. É exactamente isso que uma boa plataforma de low-code nas mãos de um profissional fará, permitindo a criação de mais aplicações mais rapidamente. Ao tornar as equipas existentes mais produtivas, o low-code pode ser uma das principais estratégias de mitigação para fazer face à escassez de talento de desenvolvimento da indústria.

Além disso, não é só o low-code que permite aos programadores tornarem-se mais produtivos; é como o faz: automatiza muitas das tarefas mais mundanas que os programadores detestam. A modelação lógica, a concepção de IU, e mesmo os esquemas de dados podem ser configurados em muito menos passos do que seria necessário para os codificar. A menos que ainda esteja a utilizar instruções SQL CREATE TABLE manuais para preparar entidades de bases de dados, já compreende isto; é provável que esteja a utilizar uma IU de concepção ou de gestão para configurar essas tabelas. Isto é tudo, mas aplicado a, bem, tudo o resto.

Isto também tem uma dimensão qualitativa; low-code significa muitas vezes menos erros. Erros de sintaxe simples acontecem com muito menos frequência, e muito manuseamento de excepções, registo, etc., podem muito bem ser incorporados na plataforma para que os construtores de aplicações individuais possam concentrar-se na lógica da aplicação, em vez de pontilhar cada “i” e cruzar cada “t”.

2 – Alinhar melhor os negócios e as TI.
Um dos desafios para muitas organizações é que as TI tendem a pensar e agir em termos de aspectos práticos e os intervenientes empresariais e os utilizadores tendem a pensar em termos de ideias. Parte de cada projecto envolve tentar destilar o que os empresários querem dizer quando pedem algo, quanto dele deve funcionar exactamente da forma como o descreveram, que coisas poderiam ser negociadas em algo que a tecnologia existente está concebida para fazer, etc.

Mesmo quando os pedidos de negócios são concretos e tangíveis, reflectem cultura e linguagem de trabalho que não é a mesma que a TI entende, pelo que a negociação e a interpretação continuam a ser muito necessárias, muito demoradas e muito frustrantes.

Se pensa que o low-code é apenas para os criadores cidadãos, não se esqueça que este problema continuará a existir, mas ao contrário; os criadores cidadãos raramente compreendem o registo, a auditoria, a criação de versões, a implementação faseada, a gestão de mudanças, os testes, a segurança, etc.

Sou um forte defensor de uma terceira abordagem, algo chamado desenvolvimento assistido pelo cidadão. O foco é a colaboração em vez da abdicação. As TI e as empresas trabalham em conjunto, em vez de ceder toda a responsabilidade a uma ou outra parte. Os cidadãos são donos do desenho, mas as opções de desenho têm barreiras de protecção, tornando o que é pedido automaticamente aplicável ao que é accionável. Além disso, a prototipagem do desenho é frequentemente feita em colaboração com as TI. A TI é proprietária da construção e entrega. Todos são donos de testes e melhorias contínuas.

Este enfoque é importante porque apenas 10% do trabalho necessário para entregar uma aplicação é dedicado ao desenvolvimento. O resto envolve todo o trabalho que acontece antes (recolha de requisitos, especificações, concepção, etc.) e depois (depuração, integração, segurança, implementação, gestão de mudanças, documentação e muito mais). A maioria das ferramentas de low-code estão focadas apenas na construção e ignoram esta realidade, mas de facto existem exceções.

3 – Alavancar os protótipos.

O protótipo de código baixo requer uma mudança subtil de pensamento: o objectivo não é que os criadores cidadãos criem aplicações a partir de um pano inteiro; é que os criadores consigam que estes utilizadores empresariais mostrem o que querem, em vez de tentarem descrevê-lo. Uma vez em mãos um protótipo viável, os programadores podem fazer perguntas informadas e começar a iterar sobre uma solução. O protótipo é a especificação.

Se é importante concentrarmo-nos na colaboração entre empresas e TI, devemos ser capazes de encontrar uma melhor forma de o conseguir do que longas e numerosas reuniões de previsão e negociação, longos documentos de especificação, e assim por diante. Introduza o protótipo.

Além disso, estes protótipos são concebidos utilizando ferramentas e métodos que reflectem o que a tecnologia disponível pode produzir. Pode ter um impacto muito real e positivo para evitar que os criadores fiquem atolados em buracos de coelho a tentarem hackear em conjunto para acomodar um desejo abstracto para a IU que a plataforma não está realmente concebida para fornecer. As ferramentas de prototipagem guiam todos para uma linguagem de design comum, o que por si só pode ajudar muito.

4 – Abraçar a melhoria contínua
É uma verdade que a perfeição é o inimigo do bem. Em desenvolvimento, isto significa frequentemente que as aplicações internas só são lançadas após meses (ou anos) de trabalho, quando são consideradas completamente prontas. Isto não só retarda os ciclos de lançamento, mas também significa que as aplicações são lançadas na natureza com testes e feedback limitados. Outra verdade: o que as pessoas realmente querem permanece incerto e abstracto até terem algo para ver, avaliar e criticar; as pessoas editam muito mais facilmente do que imaginam. Não ter visto resultados regulares que eles possam criticar e que sejam melhorados numa série rápida de iterações pode ser devastador.

Se isto soa a uma metodologia ágil, provavelmente deveria. Não é uma expressão pura de desenvolvimento ágil, mas empresta alguns princípios dessa escola de pensamento e aplica-os ao código baixo.

As organizações deveriam, em vez disso, aproveitar a velocidade do low-code para lançar rapidamente versões iniciais com um plano para iterar. Será que esta interface captura todos os elementos de dados necessários? O que é que nos falta para o fluxo de trabalho global? Estes tipos de perguntas e respostas tornam-se óbvias quando as aplicações estão em uso real. Além disso, as pessoas obtêm soluções rápidas para os seus problemas, e essas soluções melhoram rapidamente ao longo do tempo. Ambas servem para fazer dos programadores o herói.

As plataformas de low-code não são uma panaceia. Mas nas mãos adequadas – mãos de programadores – podem simultaneamente fornecer mais e melhores aplicações, ao mesmo tempo que facilitam a vida tanto para os utilizadores empresariais como para os próprios programadores. O que é que não se deve gostar?