Programa de serviços de desenvolvimento de baixo código: um guia do comprador

Um programa de serviços de desenvolvimento de baixo código é uma maneira estruturada de adquirir a entrega de aplicativos, agrupando uma plataforma visual, serviços profissionais e suporte contínuo em aproximadamente quatro modelos de engajamento: aumento de equipe, entrega de projetos de escopo fixo, serviços de aplicativos gerenciados e parcerias de plataforma mais capacitação. O Gartner cunhou o termo “low-code” em 2014, e desde então o mercado se dividiu em categorias de serviços distintas que se comportam de maneira muito diferente em termos de custo, controle e aprisionamento.

Os programas de serviços de desenvolvimento de baixo código agrupam três coisas que geralmente são vendidas separadamente na TI tradicional: uma plataforma de desenvolvimento visual, os serviços profissionais para construir nela e o suporte contínuo para manter os aplicativos resultantes em execução. Os compradores que entendem esse pacote podem negociar cada camada de forma independente – e é aí que a maior parte do valor é ganha ou perdida.

A camada de plataforma são as ferramentas: criadores de formulários de arrastar e soltar, designers de modelos de dados, mecanismos de fluxo de trabalho, conectores de API e pipelines de implantação. Exemplos nomeados incluem Microsoft Power Apps, OutSystems, Mendix, Appian, Retool, Budibase e – para equipes já investidas no ecossistema 4D – as próprias ferramentas de formulário, método e modelo de dados 4D.

A camada de serviços é o trabalho humano: workshops de descoberta, modelagem de dados, integração, testes e transferência. A camada de suporte é o que acontece após a entrada em operação: monitoramento, solicitações de mudança, atualizações de versão e treinamento de usuários.

Um programa de serviços de desenvolvimento de baixo código difere de um projeto único em um aspecto importante: ele pressupõe entrega repetida. Em vez de comissionar um único aplicativo, o comprador estabelece uma capacidade permanente – um modelo de governança, uma biblioteca de componentes reutilizáveis ​​e uma cadência de entrega – de modo que o segundo aplicativo custa muito menos que o primeiro. Essa economia da reutilização é toda a justificativa para o enquadramento do “programa”.

Os quatro modelos de serviço, comparados

Os serviços de desenvolvimento de baixo código vêm em formatos adequados para organizações muito diferentes. A tabela abaixo é o auxílio à decisão que a maioria dos compradores precisa antes de falar com qualquer fornecedor.

Relacionado: Claris FileMaker Pro — A plataforma de banco de dados relacional de longa duração para equipes que precisam de aplicativos personalizados em desktop, web e dispositivos móveis a partir de um único arquivo..

Modelo	Comprador típico	Controle	Perfil de custos	Risco principal
Aumento de pessoal	Equipe de TI com lacunas em habilidades de plataforma	Alto – você dirige o trabalho	Taxa horária ou mensal	O conhecimento sai com o contratante
Projeto de escopo fixo	Departamento com um aplicativo definido	Baixo durante a construção	Preço fixo por aplicativo	Pedidos de alteração faturados separadamente
Serviços de aplicativos gerenciados	Equipe de operações executando aplicativos ao vivo	Baixo a médio	Retenção recorrente	Resposta lenta a novos requisitos
Parceria plataforma + capacitação	Organização construindo capacidade interna	Médio, cresce com o tempo	Combinado: plataforma, treinamento, construção	Requer tempo da equipe interna para absorver

O aumento de pessoal é adequado para equipes que já possuem um padrão de plataforma e um backlog. Projetos de escopo fixo atendem a um fluxo de trabalho único de alto valor com requisitos estáveis. Os serviços gerenciados são adequados para ambientes regulamentados onde o tempo de atividade e as trilhas de auditoria são mais importantes do que a velocidade. As parcerias de capacitação são adequadas para organizações que pretendem criar dezenas de aplicativos e desejam o recurso internamente.

Uma regra prática: se o comprador não conseguir nomear quem será o proprietário do aplicativo em dezoito meses, o programa está sendo comprado pelo motivo errado. Os programas de serviços de desenvolvimento de baixo código falham na maioria das vezes, não porque a plataforma esteja errada, mas porque nenhum proprietário interno foi atribuído.

Como os serviços Low-Code e No-Code diferem na prática

Os serviços de desenvolvimento de baixo código e sem código são frequentemente comercializados como uma categoria, mas as duas metades impõem restrições diferentes ao envolvimento de serviços. As ferramentas sem código são direcionadas a usuários corporativos que configuram aplicativos sem escrever lógica; ferramentas de baixo código pressupõem que um desenvolvedor estenderá a plataforma com código quando as capacidades do construtor visual se esgotarem.

Nossa escolha: Airtable — Uma interface simples de planilha baseada em um banco de dados relacional real, com automações, visualizações e interfaces compartilháveis..

Essa distinção altera o contrato de serviços. Um envolvimento sem código envolve principalmente configuração, treinamento e governança – o trabalho do fornecedor é manter os desenvolvedores cidadãos dentro de limites seguros. Um envolvimento de baixo código adiciona engenharia de integração, componentes personalizados, ajuste de desempenho e configuração de CI/CD, porque espera-se que os aplicativos afetem os sistemas de produção e sejam dimensionados.

A maioria dos programas empresariais acaba sendo híbrida. Uma camada sem código lida com rastreadores departamentais, fluxos de aprovação e coleta de dados. Uma camada de programa de serviços de desenvolvimento de baixo código lida com qualquer coisa que grave em um sistema central, imponha regras de negócios complexas ou precise de uma trilha de auditoria. Os fornecedores que vendem apenas uma camada colocarão todos os requisitos nessa camada, o que vale a pena observar durante a definição do escopo.

Como é um envolvimento real, fase por fase

A entrega de serviços de desenvolvimento de baixo código segue um arco reconhecível, e conhecer as fases permite que o comprador identifique um fornecedor que está ignorando as fases caras.

Descoberta e modelagem de dados. O fornecedor mapeia o processo de negócios, identifica as entidades e relacionamentos e decide o que permanece na plataforma de baixo código versus o que permanece no sistema de registro. A modelagem de dados é onde se origina a maior parte do retrabalho; um formulário criado em um modelo de entidade errado é reconstruído e não corrigido.

Protótipo e validação. Um protótipo funcional será apresentado a usuários reais nas primeiras semanas. As plataformas de baixo código tornam isso econômico, e um fornecedor que não consegue criar rapidamente um protótipo clicável não está aproveitando a principal vantagem da plataforma.

Construção e integração. Telas, fluxos de trabalho, listas de valores e conexões de API são montados. A integração é geralmente o maior item em qualquer estimativa honesta, porque a autenticação, o tratamento de erros e a sincronização de dados nunca são tão simples quanto a demonstração sugere.

Relacionado: Knack — Um construtor de banco de dados sem código voltado para portais, diretórios e ferramentas internas — com preços fixos em vez de taxas por usuário..

Testes e proteção. O acesso baseado em função, a validação de entrada, o comportamento de simultaneidade e o desempenho em volumes de dados realistas são verificados. As plataformas de baixo código escondem a complexidade, o que significa que os problemas de desempenho geralmente surgem tarde.

Implantação e transferência. O aplicativo passa para a produção e, principalmente, a documentação, o treinamento administrativo e o processo de solicitação de alteração são transferidos para a equipe interna.

Operar e iterar. O programa de serviços de desenvolvimento de baixo código continua com um backlog, uma cadência de lançamento e atualizações periódicas da plataforma. Os fornecedores de plataformas lançam novas versões de acordo com sua própria programação e alguém precisa absorver essas mudanças.

Favorito do leitor: Microsoft Power Apps — Desenvolvimento de aplicativos low-code de nível empresarial conectados ao Microsoft 365, Dataverse e Power Automate..

Critérios de seleção que realmente predizem o sucesso

Avaliar fornecedores de serviços de desenvolvimento de baixo código apenas com base no reconhecimento da marca produz erros caros. Os critérios abaixo são aqueles que se correlacionam com programas de serviços de desenvolvimento de baixo código que sobrevivem ao segundo ano.

• Custo de saída da plataforma. Pergunte o que acontecerá com o aplicativo se o envolvimento terminar. Os dados podem ser exportados em um formato utilizável? A lógica pode ser lida por outra pessoa? A lógica visual proprietária é o maior risco de aprisionamento neste mercado.
• Histórico de integração. Solicite duas referências envolvendo a mesma classe de sistema que você precisa conectar — um ERP, um CRM, um banco de dados legado ou um diretório local.
• Equipe nomeada, não uma apresentação de capacidades. Pergunte quem realmente fará o trabalho e se essas pessoas são funcionários ou subcontratados.
• Artefatos de governança. Um programa sério produz uma estratégia de ambientes, um modelo de controle de acesso e uma convenção de nomenclatura. Os fornecedores que os tratam como opcionais estão acumulando dívidas futuras de manutenção.
• Compromisso de transferência. O contrato deve especificar documentação, treinamento administrativo e um período definido de suporte pós-lançamento.
• Transparência de preços. Existem preços por aplicativo, por usuário, por hora e retenção. O modelo importa menos do que se o fornecedor mostrará como o número foi construído.

Para due diligence em nível de plataforma, a pesquisa de analistas publicada por empresas como Gartner e Forrester é um ponto de partida razoável, e a entrada da Wikipedia sobre plataformas de desenvolvimento de baixo código fornece uma visão geral neutra do histórico e das definições da categoria. Os compradores em setores regulamentados também devem verificar a postura do fornecedor em relação à Estrutura de segurança cibernética do NIST, que muitas equipes de compras empresariais agora usam como vocabulário comum para questões de segurança.

Onde os programas de baixo código realmente compensam – e onde não.

Os programas de serviços de desenvolvimento de baixo código oferecem os maiores retornos em aplicativos numerosos, semelhantes e de curta duração. Formulários de solicitação interna, fluxos de trabalho de aprovação, listas de verificação de inspeção, rastreadores de inventário e painéis departamentais se enquadram nesse padrão: cada um é pequeno, cada um compartilha componentes com seus irmãos e, de outra forma, cada um ficaria em um backlog de TI por meses.

Os programas têm dificuldades quando o aplicativo é genuinamente complexo. Sistemas transacionais de alto volume, aplicativos com requisitos de simultaneidade complexos e qualquer coisa com computação pesada em tempo real geralmente são melhor atendidos pelo desenvolvimento convencional – ou por um híbrido onde a camada de baixo código cuida da interface e um serviço convencional cuida da lógica central.

Um segundo padrão de falha é o piloto abandonado. As organizações frequentemente realizam uma prova de conceito bem-sucedida e depois param porque ninguém financiou a camada de governança. O piloto prova que a plataforma funciona; isso não prova que o programa funciona. Orçamentar as partes chatas — gerenciamento ambiental, revisão de segurança, treinamento e suporte — é o que converte um piloto em um programa.

Um terceiro padrão é a expansão das sombras. Quando os desenvolvedores cidadãos constroem livremente sem uma biblioteca de componentes ou processo de revisão, uma organização pode acabar com centenas de aplicativos quase duplicados e nenhum inventário do que existe. Um programa de serviços deve incluir um registro de aplicativos desde o primeiro dia.

Construir versus comprar: quando um programa interno supera um externo

As organizações com capacidade de desenvolvimento existente às vezes perguntam se precisam de serviços externos de desenvolvimento de baixo código. A resposta honesta depende de três variáveis: quantas aplicações estão planejadas, quão incomuns são os requisitos de integração e se a plataforma já está padronizada.

Um programa interno faz sentido quando a organização se compromete com uma plataforma, planeja mais do que um punhado de aplicativos e pode dedicar pelo menos um desenvolvedor experiente à propriedade da plataforma. A função do fornecedor externo então se reduz à capacitação inicial e ao trabalho especializado ocasional.

Um programa externo faz sentido quando a decisão da plataforma ainda está em aberto, quando as primeiras aplicações envolvem integrações desconhecidas ou quando o pessoal interno simplesmente não pode ser liberado dos compromissos existentes. Nesse caso, o contrato deve ser redigido com uma rampa de saída explícita – um ponto em que a equipe interna assume o controle – em vez de um retenção por tempo indeterminado.

As equipes que constroem em 4D geralmente ficam em uma posição intermediária. O modelo de dados, formulários e métodos já são familiares para o desenvolvedor interno, portanto, os serviços externos são mais valiosos para o trabalho de integração, arquitetura de implantação e modernização de estruturas binárias mais antigas. Esse é um compromisso mais restrito do que um programa completo e deve ser precificado de acordo.

Fontes e leituras adicionais

• Plataforma de desenvolvimento de baixo código - Wikipedia: Uma plataforma de desenvolvimento de baixo código (LCDP) fornece um ambiente de desenvolvimento de software - normalmente uma interface gráfica de usuário (GUI) - que envolve pouca ou nenhuma escrita…

Perguntas frequentes

O que é um programa de serviços de desenvolvimento de baixo código?

Um programa de serviços de desenvolvimento de baixo código é um acordo permanente no qual um fornecedor fornece uma plataforma de baixo código e os serviços profissionais para construir, implantar e manter aplicativos nela. Difere de um projeto único porque pressupõe entrega repetida, componentes compartilhados e um modelo de governança contínuo. Os compradores normalmente escolhem entre aumento de pessoal, projetos de escopo fixo, serviços gerenciados e parcerias de capacitação.

Quanto custam os serviços de desenvolvimento de baixo código?

Os preços variam muito para um único valor confiável, porque dependem da licença da plataforma, do modelo de engajamento e da complexidade das integrações. Os fornecedores cotam por hora, por aplicativo, por usuário ou como taxa mensal, e o licenciamento da plataforma geralmente é cobrado separadamente dos serviços. A comparação mais útil é o custo total por aplicativo entregue em um roteiro de vários aplicativos, e não a valor nominal.

O desenvolvimento de baixo código é adequado para aplicativos corporativos?

O low-code é adequado para aplicações empresariais que são numerosas, orientadas para o fluxo de trabalho e com muita integração – sistemas de aprovação, rastreadores, portais e ferramentas departamentais. É uma opção mais fraca para núcleos transacionais de alto volume, computação em tempo real e sistemas com demandas de simultaneidade incomuns. Muitas empresas executam um híbrido: low-code para a interface e camada de fluxo de trabalho, código convencional para a lógica central.

Qual é a diferença entre serviços de desenvolvimento com baixo código e sem código?

Os serviços sem código concentram-se na configuração e na governança para que os usuários empresariais possam construir com segurança sem programação. Os serviços de baixo código adicionam engenharia de integração, componentes personalizados, ajuste de desempenho e pipelines de implantação, porque espera-se que os aplicativos afetem os sistemas de produção. A maioria dos programas empresariais opera em ambos os níveis, encaminhando aplicativos simples para sem código e aplicativos complexos para baixo código.

Quanto tempo leva para entregar um aplicativo por meio de um programa de serviços de baixo código?

Muitas vezes, um protótipo pode ser mostrado nas primeiras semanas, e uma aplicação departamental simples normalmente chega à produção em questão de meses, em vez de trimestres. Os prazos aumentam quando as integrações são complexas, a revisão de segurança é pesada ou os requisitos mudam no meio da construção. A vantagem real de velocidade do programa aparece na segunda e terceira aplicações, uma vez implementados os componentes e a governança.

O que um contrato de serviços low-code deve incluir?

Um contrato deve especificar a equipe de entrega nomeada, as responsabilidades da plataforma e do licenciamento, o escopo da integração, a documentação e o treinamento de administração, um período definido de suporte pós-lançamento e os termos sob os quais o comprador pode realizar o trabalho internamente. Os direitos de exportação de dados e a legibilidade da lógica personalizada merecem linguagem explícita, porque determinam o quanto custará deixar o fornecedor posteriormente.