Esta é a objeção que impede mais pessoas de começar, e assenta numa premissa falsa: que a sua descrição iria diretamente para código, sem possibilidade de retrocesso. Não é esse o fluxo. A sua descrição gera, em primeiro lugar, um PLANO, uma lista estruturada dos dados (com os respetivos tipos e campos), dos ecrãs e do tipo de cada ecrã, que lhe é apresentado e que pode corrigir ANTES de uma única linha de código existir: renomear uma entidade, alterar o nome de um campo, adicionar ou remover um valor de estado, ou até mudar o tipo de um ecrã. Nesta fase, enganar-se não custa nada. Após a geração, ainda é possível efetuar alterações descrevendo-as em português, mas isso reconstrói toda a aplicação e submete-a novamente à validação automática: trata-se de uma ação mais pesada, não de um simples ajuste.
O erro que se teme não é aquele que ocorre
O receio é apresentar uma descrição imprecisa e receber uma ferramenta fora do âmbito pretendido, sem possibilidade de correção. Em projetos tradicionais, esse receio é legítimo: o documento de requisitos é enviado a um prestador, o primeiro ecrã só surge semanas depois e a diferença entre o esperado e o entregue traduz-se em dias de desenvolvimento. É esse atraso, e não a dificuldade de escrever, que torna o exercício angustiante.
A literatura sobre a expressão de necessidades diz, aliás, a mesma coisa sob outro ângulo: a dificuldade não está em redigir, mas em saber o que se quer antes de ter visto algo concreto. Não adivinhamos os nossos próprios modos de trabalho; reconhecemo-los quando os vemos materializados.
O plano é mostrado antes do código e pode ser editado
Entre a sua descrição e a aplicação existe uma etapa intermédia: o plano. Ele enumera os dados que a ferramenta vai gerir (com os respetivos campos e tipos), bem como os ecrãs, especificando, para cada um, o seu tipo: tabela, calendário, painel de controlo ou mapa. Esse plano é exibido e editável.
Na prática, nesse momento pode renomear um dado e a respetiva etiqueta, corrigir os campos que ele contém, adicionar ou remover um valor de uma lista de estados («Em espera», «Aprovado», «Cancelado»), renomear um ecrã, alterar o seu ícone, e até mudar a sua natureza: uma lista que deveria ter sido um calendário é corrigida aqui, de uma só vez.
É precisamente este momento que torna a objeção irrelevante. Uma descrição aproximada não obriga a nada: gera uma proposta que pode rever e, corrigir uma palavra no plano equivale exatamente ao mesmo que tê-la escrito corretamente desde o início.
Após a geração: ainda é possível, mas já não é o mesmo gesto
Uma vez gerada a aplicação, qualquer alteração continua a ser solicitada em português, «adiciona um campo para a data de seguimento», «separa os orçamentos das faturas». A diferença está noutra parte: essa solicitação regenera o plano, reconstrói a aplicação e submete-a novamente à validação automática antes de voltar a colocá-la em serviço. É fiável, mas não é instantâneo.
Daí o único conselho prático desta página: reler o plano merece cinco minutos de atenção genuína. São os cinco minutos mais baratos do projeto.
O que é preferível saber antes de modificar uma aplicação já em funcionamento
Há dois aspetos que não são intuitivos e que vale a pena esclarecer antes de lançar uma alteração numa ferramenta que já contém os seus dados reais.
O primeiro: o que acontece aos dados já introduzidos quando a estrutura muda (um campo removido, um tipo de dado dividido em dois). Não o afirmo aqui, trata-se de uma questão que deve ser colocada explicitamente antes de modificar uma aplicação em produção, tanto aqui como com qualquer outro fornecedor.
O segundo: não existe um botão «reverter para a versão anterior». Voltar atrás é algo que se prepara, não se improvisa, daí a utilidade de exportar os seus dados antes de uma alteração estrutural, o que é possível através do ecrã Definições, em formatos CSV e JSON.