O que eu confiro antes de dizer que um software está pronto para produção
Funcionar na demonstração é só o começo. Antes de colocar gente de verdade usando, eu passo por sete perguntas, e quase nenhuma é sobre o código ser bonito.
Com IA, ficou fácil chegar a um software que funciona na demonstração. Em uma tarde dá para ter tela, banco de dados e login. A pergunta que importa vem depois: isso aguenta gente de verdade usando?
“Pronto para produção” virou uma expressão vaga, que cada um usa do seu jeito. Para mim, ela é uma lista curta de perguntas. No time que lidero, essa lista virou um padrão que todo repositório segue, com checagem automática. Mas ela serve para qualquer produto, de qualquer tamanho.
Primeiro o piso, depois o teto
Não dá para fazer tudo no primeiro dia, e nem precisa. Eu separo as perguntas em três camadas: o piso, que evita o desastre; a rotina, que deixa o time mudar o produto sem medo; e o crescimento, que prepara para quando der certo.
O piso: o que não pode faltar no primeiro dia
1. Tem alguma chave ou senha no código? É o erro mais comum e o mais caro. Chave de API esquecida no repositório, senha do banco num arquivo de configuração, token num print de tela. Se vazar, alguém usa a sua conta antes de você perceber. Segredo fica fora do código, e o repositório bloqueia quem tentar subir um.
2. Quem consegue ler os dados? Banco de dados aberto para quem souber o endereço, permissões que ninguém revisou, painel administrativo sem login. E, se o produto guarda dados de pessoas, a pergunta seguinte é: o que é guardado, quem acessa e por quê. No Brasil, a Lei Geral de Proteção de Dados (LGPD) cobra exatamente essas respostas.
3. Existe um caminho só para colocar no ar? Se cada pessoa publica de um jeito, ninguém sabe o que está rodando. O caminho tem que ser um só, automático, a partir de uma branch protegida, e precisa permitir voltar para a versão anterior em minutos.
A rotina: mudar sem medo
4. Uma mudança pode quebrar o que já funcionava sem ninguém ver? Eu não persigo uma porcentagem de cobertura de testes. Número alto se atinge com teste inútil, e quem é da área sabe disso. O que eu confiro é se os caminhos críticos estão testados (cadastro, login, pagamento, o que dá dinheiro ou dá problema) e se os testes rodam sozinhos a cada mudança.
5. Alguém fica sabendo de um erro antes de o cliente reclamar? Se o primeiro aviso de que algo quebrou é uma mensagem irritada no suporte, o produto está no escuro. Erro precisa gerar alerta, e o alerta precisa chegar a alguém que olha.
O crescimento: quando der certo
6. O que acontece com dez vezes mais usuários, e quanto isso custa? Muita coisa funciona com cem usuários e cai com mil. Às vezes não cai, mas a conta do servidor cresce mais rápido que a receita. Vale saber antes.
7. Uma pessoa nova consegue trabalhar nisso? Eu meço com uma pergunta simples: um desenvolvedor que nunca viu o projeto consegue rodá-lo na própria máquina em menos de uma hora? Se não consegue, o produto depende de quem o escreveu, e isso é risco, não detalhe.
Onde a IA entra
A IA ajuda muito nessa lista. Ela revisa código procurando segredos esquecidos, sugere testes, faz a primeira triagem de alertas de segurança. No meu time, boa parte disso já roda com ela.
O que ela não faz é decidir o que é crítico. Saber que o pagamento importa mais que a tela de configurações, ou que um dado específico não pode vazar de jeito nenhum, depende de quem conhece o negócio e o usuário. É o tipo de decisão que eu gosto de tomar olhando o produto inteiro.
Pronto não é perfeito
Pronto para produção não quer dizer sem defeito. Quer dizer saber o que pode dar errado, ficar sabendo quando deu e conseguir consertar rápido.
Se você tem um produto no ar, faça estas sete perguntas hoje. Onde a resposta for “não sei”, é por ali que eu começaria.