O defeito aparece antes do seu cliente
Cada mudança passa por testes automáticos que rodam sozinhos, e o sistema no ar é vigiado do lado de fora, de minuto em minuto. Quando algo cai, quem descobre somos nós — não a pessoa que estava tentando usar.
Software não falha só quando quebra. Falha quando ninguém percebe que quebrou, quando a correção some junto com quem a fez, quando o sistema não abre no celular de quem precisa dele. Este documento descreve o método que usamos para que essas três coisas não aconteçam — e é o mesmo método em todos os projetos, do primeiro dia ao sistema em produção.
Cada mudança passa por testes automáticos que rodam sozinhos, e o sistema no ar é vigiado do lado de fora, de minuto em minuto. Quando algo cai, quem descobre somos nós — não a pessoa que estava tentando usar.
As regras de trabalho não são combinado verbal: são verificadas pela própria ferramenta a cada alteração. Quem entra no projeto depois herda a regra funcionando, e não uma tradição oral.
Toda mudança fica registrada com data, motivo e efeito prático, em linguagem de quem usa — não só em linguagem de programador. É o que permite conferir o que você contratou e o que recebeu.
Da menor correção à funcionalidade nova. Não é sugestão de boas práticas: pular etapa é bloqueado pela ferramenta.
Entender o que a mudança encosta antes de escrever a primeira linha. A maior parte dos defeitos caros nasce aqui, e não na digitação.
Fazer o que foi pedido, sem carona. Funcionalidade que ninguém pediu é custo de manutenção que ninguém aprovou.
Teste automático que roda a cada alteração, e teste no navegador de verdade — porque tela quebrada com teste verde é um modo de falha real, não hipótese.
Quem vê o quê. Em sistema com vários clientes na mesma base, a separação é provada requisição a requisição, não confiada ao desenho.
Uma mudança por registro, com o motivo escrito. Seis meses depois, o motivo é a única coisa que ninguém consegue reconstituir sozinho.
A documentação acompanha a mudança no mesmo momento. Documentação que fica para depois descreve um sistema que já não existe.
Ao fim de cada bloco de trabalho fica escrito o que ficou pronto, o que está em andamento e o que falta. É o que permite retomar sem redescobrir.
Aqui fazem parte do sistema desde a primeira tela.
Termos com versão e aceite registrado, consentimento separado por finalidade e revogável, prazo de guarda escrito com descarte automático, e o direito de a pessoa levar os próprios dados embora em formato aberto.
Quando o sistema atende várias organizações, nenhuma requisição roda sem saber a qual delas pertence — e isso é verificado por teste em cada rota, não apenas na camada de banco.
Senha, chave e token de integração são gerados por nós, guardados cifrados e exibidos uma única vez. O sistema nunca aceita, de fora, um valor que vire credencial.
Ajuste de tamanho de texto, contraste em dois sentidos, espaçamento de leitura, guia de leitura, pausa de animação — mais tradução em Libras pelo widget oficial do governo brasileiro, sem custo para você.
Toda tela nasce nos dois temas, com contraste conferido por verificação automática nos dois. Não é gosto: é o que mantém a tela legível para quem enxerga pouco e para quem trabalha à noite.
O sistema se instala na tela inicial do telefone e do computador, com ícone e nome próprios, sem passar por loja de aplicativos e sem custo de publicação recorrente.
Backup automático diário, cifrado antes de sair da máquina — porque cópia de segurança carrega os mesmos dados pessoais que o sistema, e merece a mesma proteção.
Alterações relevantes ficam registradas com autor, data e valor anterior. Campos sensíveis aparecem mascarados: fica provado que mudaram, sem expor o conteúdo.
Uma distinção que muda o resultado na prática.
Um endereço pode responder “tudo certo” com o sistema morto por trás. Por isso a verificação não olha só a resposta: ela confere o conteúdo que voltou.
O alerta também é testado de propósito, provocando uma falha real para ver se o aviso chega. Monitor que nunca disparou é indistinguível de monitor quebrado — e as duas situações só se revelam no pior dia.
Uma lista do que mudou para quem usa, agrupada por tipo, escrita sem jargão. Serve para comunicar sua própria equipe.
Um para desenvolver, um para você aprovar antes de valer, e o de produção. Nada estreia direto no ambiente onde estão os dados reais.
Todo o histórico fica versionado e é entregável. Você não fica preso ao fornecedor por falta de acesso ao que já pagou.
São as perguntas cujas respostas separam um sistema que envelhece bem de um que só parece pronto na apresentação.
Como vocês descobrem que o sistema caiu?Se a resposta for “o cliente avisa”, o custo da queda é seu.
O que acontece se a pessoa que fez isto sair amanhã?A resposta está na documentação, não na confiança.
Onde está escrito por que essa decisão foi tomada?O código conta o quê; quase nunca conta o porquê.
Quais dados pessoais o sistema guarda, e por quanto tempo?Dado sem prazo é dado guardado para sempre por omissão.
Como se prova que um cliente não enxerga o dado do outro?“O sistema foi feito assim” não é prova. Teste é.
A tela funciona para quem enxerga pouco?Acessibilidade depois da entrega custa a reescrita da interface.
Se eu quiser trocar de fornecedor, o que sai comigo?Código, dados e documentação — ou dependência.