Sobre o Ailton Carvalho

Sistema web sob medida

1. 1

   Diagnóstico do processo

   A conversa começa pelo trabalho que acontece hoje, não pela lista de telas que alguém imaginou. Eu procuro saber quem inicia cada tarefa, quais dados entram, quais decisões dependem de aprovação, onde a informação é copiada e onde o erro costuma aparecer. A planilha atual, os exemplos reais e as exceções valem mais do que uma descrição genérica de que a empresa precisa de um sistema completo. Também separo o que é regra obrigatória do que é preferência de interface. Se já existe ERP, CRM, loja ou serviço de pagamento, levanto quem é dono de cada informação e quais caminhos de integração estão disponíveis. Ao final, o problema deve estar descrito de forma que outra pessoa consiga entender o fluxo sem adivinhar. Se um sistema pronto resolver a necessidade com menos risco, essa também é uma conclusão possível nesta etapa.

2. 2

   Escopo da primeira versão

   Depois do diagnóstico, separo o núcleo que precisa funcionar primeiro do que pode esperar. A primeira versão deve atravessar uma tarefa real do começo ao fim, com os dados e as permissões que tornam o processo confiável. Isso pode significar cadastrar um cliente, aprovar uma solicitação, atualizar um pedido e gerar o próximo passo, em vez de entregar um painel cheio de gráficos que não muda o trabalho de ninguém. Para cada parte, escrevo o que entra, o que não entra, quais dependências existem e como saberemos que está correto. O recorte também prevê a migração inicial de dados, os perfis necessários e o caminho de retorno quando uma integração falha. Chamar isso de MVP não significa entregar algo descuidado. Significa testar a parte mais importante do negócio antes de gastar energia com expansões que ainda não provaram valor. A primeira versão pode crescer, mas deve nascer com base que não precise ser descartada quando o uso aumentar.

3. 3

   Modelagem e construção

   A construção transforma o fluxo em dados, regras, telas e integrações. O banco precisa representar as relações entre registros e recusar combinações que não fazem sentido. A aplicação precisa orientar quem executa a tarefa e mostrar uma mensagem útil quando a regra não permite continuar. As permissões são testadas por papel, inclusive para garantir que uma pessoa não consiga consultar pela URL um registro que a tela não oferece. Nas integrações, cada evento recebe identificação, estado e registro suficiente para investigar uma falha sem depender de memória. As partes são apresentadas de forma navegável em um ambiente de validação, com dados próximos do uso real e sem expor informações que não deveriam estar ali. A validação acontece enquanto o desenho ainda pode mudar. Corrigir uma regra no fluxo antes da entrega é mais simples do que explicar depois por que a equipe adotou um contorno.

4. 4

   Validação com quem opera

   Quem usa o sistema todos os dias precisa conseguir testar as tarefas que realmente executa. A validação não é apenas conferir se cada botão abre uma tela. É verificar se o fluxo impede uma transição inválida, se o relatório responde à pergunta da gestão, se o acesso de cada papel está correto e se uma falha de terceiro fica visível para alguém agir. Peço exemplos de exceção, como cancelamento, devolução, alteração depois da aprovação, reenvio de evento e usuário que muda de função. Esses casos revelam regras que normalmente ficam fora do primeiro desenho. O que for ajustado entra no escopo e no histórico do projeto, para que uma mudança de opinião não seja confundida com um defeito. A meta é chegar à produção com a equipe sabendo o que fazer e com o sistema sabendo recusar o que não deve acontecer.

5. 5

   Produção e manutenção

   Entrega é o sistema rodando com dado real, acesso correto, integração observada e procedimento para recuperar uma falha. O repositório sozinho não é entrega. Também entram a documentação mínima para subir a aplicação, as variáveis que não devem ser expostas, o processo de backup e a forma de consultar logs e auditoria. Antes da virada, combinamos como importar ou conferir os dados, quem pode aprovar a entrada e como será tratado o primeiro erro. Depois da publicação, o sistema continua exigindo cuidado: dependências mudam, APIs de terceiros mudam, permissões precisam ser revisadas e a operação descobre melhorias. Posso seguir na manutenção ou entregar o código e a documentação para quem assumirá essa responsabilidade. Em qualquer dos caminhos, o combinado precisa separar correção de defeito, melhoria de escopo e custo de serviços externos. Isso evita que a primeira falha vire dependência permanente de uma pessoa ou surpresa para a empresa.

E-commerce que aguenta operação real

1. 1

   Diagnóstico da loja

   Eu olho a loja que existe hoje: plataforma, apps, catálogo, o que está lento e o que está quebrado. Se a resposta for não mexer, eu digo isso também.

2. 2

   Construção com a loja no ar

   Tema e integrações se preparam em paralelo ao que está vendendo. Nada entra direto na loja viva sem ter sido testado antes.

3. 3

   Corte e acompanhamento

   O corte é combinado, com redirecionamento pronto e acompanhamento do que o Google e o Merchant Center enxergam depois. Queda de tráfego em migração aparece nos primeiros dias, e é aí que se corrige.