Projeto final: sua ferramenta no ar, testada por 3 pessoas

Nesta aula

Doze aulas atrás você tinha uma ideia. Hoje coloca no ar, e deixa três pessoas tentarem quebrar.

O projeto final não é uma coisa nova: é juntar tudo o que você fez, do projeto.txt da aula 1 ao manutencao.md da aula 11, numa versão que outras pessoas conseguem usar sem você do lado. A parte que quase ninguém faz, e que separa um projeto de brinquedo de uma ferramenta de verdade, é o teste com gente de fora. Vamos fazer com método.

• Ao final, você vai ter a sua ferramenta (ou site) publicada numa versão que cumpre o briefing e passou no checklist.
• Vai saber montar um roteiro de teste para pessoas de fora e transformar o que elas disserem em correção.
• Vai sair com a versão 1.0 no ar, testada por três pessoas, e o próximo projeto escolhido.

O que é "pronto" neste curso

Pronto não é perfeito nem completo. Pronto é quatro coisas, e você já tem quase todas:

1. Cumpre o briefing. As funções da primeira versão, definidas na aula 1 e detalhadas na aula 4, funcionam. O que ficou de fora ficou de fora de propósito.
2. Passou no checklist de segurança da aula 10, com os itens de gravidade alta resolvidos e a frase de dados escrita.
3. Foi testado por gente de fora, e o que era bloqueio foi corrigido. É o que fazemos hoje.
4. Está guardado: git com histórico limpo, LEIAME.md, manutencao.md, e publicado (se for site ou ferramenta para o ar) ou instalado no aparelho certo (se for ferramenta local).

Escolha o que vai ser o seu projeto final: o site da aula 5 e 6, a ferramenta de cadastro da aula 7, ou a ferramenta com IA da aula 8. Um só. Se estiver em dúvida, escolha o que alguém do seu negócio usaria já na semana que vem. É o mesmo critério da aula 1, e ele continua certo.

Antes do teste: a passada final

Uma hora antes de mandar para as pessoas, faça a passada final. É a mesma checagem da aula 5 e da aula 7, só que completa:

• Abra do zero, como um usuário novo: no celular, pela rede móvel, se for site publicado; num navegador limpo, se for ferramenta local.
• Faça o caminho principal inteiro: de chegar até completar a ação que o briefing definiu como objetivo.
• Faça o caminho ruim: campo vazio, número negativo, texto enorme, clicar duas vezes seguidas.
• Leia cada texto. Ainda tem algum "[FALTA]" ou texto provisório? Resolva ou tire.
• Rode o pedido de revisão de segurança da aula 10 mais uma vez, porque desde então houve mudanças.
• Commit: git add . e git commit -m "candidata a versão 1.0". Publique, se for o caso.

O roteiro de teste com gente de fora

Escolha três pessoas que não participaram da construção. Idealmente, uma que representa quem vai usar (uma cliente, uma funcionária), uma que não entende nada do assunto (um parente), e uma que é exigente com detalhe. Mande o endereço (ou sente com a pessoa) e um roteiro curto. Não explique nada além do roteiro: se você explicar, o teste não vale.

A frase "não vou explicar nada de propósito" é o coração do teste. E o "não precisa ser educado" tira o filtro que faz as pessoas dizerem "ficou ótimo" para não magoar.

Transformando respostas em correções

Junte as respostas das três pessoas numa lista e classifique cada item:

• Bloqueio: a pessoa não conseguiu completar a ação principal, ou não entendeu o que a ferramenta faz. Corrige antes de chamar de pronto. Uma pessoa em três é motivo suficiente.
• Atrito: conseguiu, mas parou, ficou em dúvida ou clicou errado antes. Corrige se for rápido; se não, anota para a próxima versão.
• Preferência: "eu faria diferente", cor, ordem, palavra. Anota. Não corrige agora, a menos que duas das três pessoas tenham dito a mesma coisa.

Para cada bloqueio, o pedido de correção é o mesmo de sempre, com um ingrediente a mais: a frase da pessoa. "Uma testadora disse: 'cliquei em adicionar e achei que não tinha funcionado, porque a lista está lá embaixo'. No celular, depois de adicionar, role até o item novo ou mostre uma confirmação visível no topo. Não mude mais nada." A frase real da pessoa é o melhor briefing de correção que existe.

Depois da versão 1.0

Quando os bloqueios estiverem corrigidos e re-testados, faça o commit "versão 1.0 testada", publique, e escreva a linha no histórico do manutencao.md. Você tem uma ferramenta de verdade, feita por você, que você entende e mantém. Isso é mais do que a maioria das empresas pequenas tem.

O que vem depois, na minha experiência, segue um padrão. Quem tenta o "sistema que resolve tudo" trava e abandona. Quem faz mais um projeto pequeno, útil em uma semana, com o mesmo ciclo, em seis meses tem meia dúzia de ferramentas rodando e uma noção muito clara de quando precisa de profissional. A rotina mensal cuida do que já existe; o ciclo cuida do que vem. E os outros cursos do site (IA no trabalho, automação sem código, agentes de IA) são os próximos passos naturais, cada um com o mesmo espírito: entender antes de contratar, delegar sem perder o controle.