Saber tirar também é design

Este é o quinto e último post da série sobre os bastidores do Olha o Bichim!. Nos anteriores, eu falei da ideia, da especificação, da execução e das regras. Agora, o produto.

Até aqui, pode parecer que o projeto foi uma linha reta: documento, especificação, plano, código, publicação. Não foi. Boa parte das mudanças mais importantes veio de gente jogando e dizendo, sem rodeios, o que não funcionava.

Seis meses em uma linha

Em abril, o documento de design, o motor do jogo e a identidade visual. Maio foi o mês mais intenso, com 543 commits: o nome novo, a loja, os testes de ponta a ponta, o Firebase, o ranking e as compras. Em junho, o som, a segurança e o tutorial refeito. Em julho, a publicação no Google Play e na App Store. Agosto foi de animações, moedas, um ranking novo e a imprensa. Setembro e outubro trouxeram a Corrida Maluca, a Asa Branca, a música "Peixe Vivo" e o cupom do Dia das Crianças.

Ouvir quem joga, inclusive as crianças

A especificação do tutorial interativo começa assim: "Filhos de usuários jogaram e disseram simplesmente que 'não entenderam o jogo'." Não tem crítica mais sincera que a de uma criança.

O tutorial passou por quatro especificações em uma semana. Primeiro, virou um tabuleiro 4×4 de verdade pra praticar. Depois, ganhou uma página "Qual é o objetivo?", mostrando que a peça 2048 é a Capivara Lendária. Em seguida, a etapa livre passou a exigir chegar ao Sagui (32). E por último, o detalhe mais revelador: no tutorial, tocar numa peça trocava a imagem, o que ensinava que "o bicho muda", quando o que o jogador precisava aprender era que "duas peças se juntam". Trocamos pelo deslizar de verdade.

Isso é algo que nenhuma especificação bem escrita teria previsto. O processo do post anterior garante que o que foi pedido seja construído direito, mas só ouvir quem joga garante que o que foi pedido seja a coisa certa.

Publicar é metade do trabalho

O Google Play foi relativamente tranquilo. A Apple, nem tanto. Só em julho, depois da primeira versão na App Store, vieram:

• o layout estourando no iPad;

• a data de nascimento obrigatória, considerada coleta indevida de dados (Guideline 5.1.1), que foi trocada por um simples "Você tem mais de 13 anos? Sim/Não";

• três rejeições seguidas por causa do mesmo botão "Confirmar", que parecia travado (contei a causa no post anterior);

• o cancelamento do login com a Apple mostrando um erro cru;

• os códigos de presente, que liberavam itens pagos fora da compra dentro do app, o que a Apple não permite (Guideline 3.1.1).

Cada rejeição virou especificação, correção e regra no ios/CLAUDE.md. E, pra completar, o build do iOS é feito por SSH numa máquina virtual com macOS que não roda nem o simulador, então tudo é compilado e enviado sem eu ver o app rodando ali. Hoje, publicar uma versão significa quatro canais conferidos separadamente: GitHub Releases, Google Play, App Store e TestFlight.

Saber tirar também é design

Uma coisa que eu aprendi nesse projeto é que remover algo também é uma decisão de design, e muitas vezes a mais difícil.

O áudio é o melhor exemplo. Ele foi removido do escopo num dia e voltou no dia seguinte como um sistema 100% sintetizado em código, sem nenhum arquivo de áudio no app. A música foi tirada no outro dia, os efeitos sonoros cresceram de 8 para 25 em agosto e, em setembro, voltou uma música de fundo, a "Peixe Vivo", que é de domínio público, num estilo 16-bit, com os sons reescritos no padrão do Super Nintendo e uma voz própria pra cada um dos 14 animais. Tudo gerado em Dart, em tempo de execução.

A data de nascimento saiu por exigência da Apple. O código de presente foi escondido no iOS. E a Corrida Maluca ganhou um interruptor remoto, que permite pausar o evento sem publicar uma nova versão do app, e ele foi usado poucos dias depois. Tirar não é fracasso, é ajuste.

O que eu levo disso

Fechando a série, o que eu e a Risoleta tiramos desses seis meses:

1. Ideias nascem da observação, não da tecnologia. Foi uma criança apontando pra uma capivara.

2. Colaborar entre áreas diferentes funciona. Alguém do Direito e o outro da TI fizeram juntos um produto que nenhum dos dois faria sozinho.

3. Feche as lacunas antes de codar. Um LLM preenche o que não foi dito com a resposta mais provável, não com a sua.

4. Testes permitem ir rápido. 1.681 commits em seis meses só são sustentáveis com 1.500 testes e integração contínua.

5. IA é equipe, não mágica. Ela precisa de contexto, regras, revisão e verificação. E quem escreve não aprova.

6. Cada bug é uma regra em potencial. Os CLAUDE.md são a memória do projeto.

7. Ouça o usuário, inclusive as crianças. O tutorial foi refeito quatro vezes por causa delas.

8. Saber remover também é design.

Eu comecei este projeto querendo um desafio técnico e terminei com um jogo que professores recomendam em sala de aula e que a minha esposa joga toda semana disputando o ranking. A meu ver, não existe resultado melhor que esse.

O Olha o Bichim! está gratuito no Google Play e na App Store, e mais informações em olhaobichim.com.br. Se tiver dúvidas sobre o processo, sobre o Superpowers ou sobre como trabalhar com agentes de IA sem perder o controle do projeto, é só entrar em contato.