O Steve Test: o trabalho merece existir?

No início desta semana, entreguei uma peça de trabalho em que a decisão certa era me recusar a colocá-la no ar. Um pipeline de tradução grava o conteúdo deste site no Cloudflare D1 para dez localidades. Três jobs de tradução bateram em um limite de taxa ao mesmo tempo; o mecanismo de contingência gravou silenciosamente a fonte em inglês no D1 como a “tradução” para seis dessas localidades e depois atualizou os hashes de ponto de controle para corresponder ao conteúdo em inglês. No disco, parecia sucesso. O pipeline informou “complete”. A métrica dizia que dez localidades tinham sido entregues. Toda verificação automatizada passou.

Um leitor alemão que chegasse a /de/guides/claude-code teria encontrado um parágrafo em alemão, um parágrafo em inglês, outro parágrafo em alemão e um cabeçalho de seção em inglês. Nenhum marcador explicava as transições. A página parecia deliberada e fazia o site inteiro parecer indigno de confiança: o tipo de produto que provavelmente também falharia em qualquer outra coisa para a qual existisse. O teste Jiro (o trabalho está correto?) passou em toda camada que eu havia instrumentado. E, ainda assim, a coisa não era digna. Parecia um produto e se comportava como um insulto.

A resposta certa era parar, auditar todo lote com contingência para inglês, limpar cirurgicamente os hashes de ponto de controle, executar o pipeline de tradução um job por vez, verificar localidade por localidade, fazer commit e push. Aproximadamente seis horas de tempo corrido de tradução e uma correção de proteção para impedir recorrência. O artefato no disco esteve “funcionando” o tempo todo. O artefato em produção era dano que eu tinha causado.

A forma da falha é a mesma quer o artefato seja um pipeline de tradução, um fluxo de cadastro, uma chave de recurso, uma exportação CSV ou uma página de marketing. Toda verificação automatizada passa. A coisa que chega à frente de um usuário real é dano.

A pergunta governante em produto não é Está pronto? nem Funciona? A pergunta governante é O trabalho merece existir? Todo artefato precisa respondê-la antes de ser lançado, ao lado de um teste separado de correção. Correção sem dignidade produz estoque: coisas que funcionam, são lançadas e não conquistam confiança. Dignidade sem correção produz teatro: coisas que parecem certas e quebram. Os dois testes precisam passar.

O atalho que uso é o Teste Steve. Ele fica ao lado do Teste Jiro, para rigor e evidência. São duas perguntas diferentes aplicadas pela mesma mente, e eu não lanço trabalho que falhe em qualquer uma delas.

TL;DR

O Teste Steve é o segundo teste que todo artefato precisa passar. Jiro pergunta se o trabalho está correto; Steve pergunta se o trabalho merece existir como parte do todo que você está construindo. O teste é concreto, não abstrato. Ele mede contra um usuário real em um momento real, e sua saída mais consistente é a recusa. Eu corto escopo. Eu excluo recursos. O que sobra precisa carregar meu nome. Os dois testes precisam passar. Se Jiro falha, você para e corrige. Se Steve falha, você reconstrói. Três reconstruções honestas são o limite; depois disso, o problema está acima, no enquadramento.

Por que “Está pronto?” é a pergunta errada

A maioria das equipes de produto otimiza para algo que possa ser lançado. As saídas mensuráveis são commits, implantações, gráficos de velocidade, a presença de algo em produção. O modo de falha é previsível: as equipes produzem um fluxo constante de artefatos que funcionam corretamente e gastam silenciosamente a confiança do usuário. O onboarding termina, a segunda sessão nunca acontece. Tickets de suporte se acumulam em torno de tarefas que o produto afirma resolver. A curva de abandono decai rumo a zero em vez de se estabilizar em um núcleo.

Pronto e digno são medidas diferentes. Um recurso pode estar pronto e ainda falhar em merecer sua existência. Uma página pode renderizar e insultar o leitor. Uma tradução pode estar tecnicamente presente e ser, na prática, uma mentira. O teste para saber se algo está pronto é se ele executa o comportamento especificado. O teste para saber se algo é digno é se um usuário real, em um momento real, fica melhor porque você o lançou.

Meu argumento em Produto Mínimo Digno é que a cultura de MVP, na prática, fundiu duas perguntas em uma: aprender rápido se degradou para lançar rápido, e lançar virou a métrica que importava.⁷ A cura é o padrão duplo. Mínimo corta escopo. Digno mantém a superfície restante em um nível que o usuário consegue sentir. O Teste Steve é a ferramenta que você usa quando está decidindo se a superfície restante passou desse nível.

A pergunta governante

O trabalho merece existir?

Eu uso a pergunta literalmente. Quando termino uma peça de trabalho e preciso decidir se vou lançá-la, faço a pergunta em voz alta. A resposta é um veredito, não uma sensação. Se a resposta é sim, o trabalho está apto a ser lançado e a próxima pergunta é se ele também passa no teste Jiro de correção. Se a resposta é não, o trabalho precisa de uma reconstrução ou de uma exclusão. Se a resposta é ainda não, mas ficará dentro de um movimento corretivo definido, continue trabalhando.

A pergunta só funciona se a resposta puder ser não. Um Teste Steve que carimba automaticamente qualquer coisa à sua frente não é um teste. O sinal de que o teste está realmente rodando é que alguns trabalhos falham nele.

O polo do usuário: dignidade nunca é abstrata

O Teste Steve falha no momento em que vira uma discussão de gosto sobre o trabalho isolado. Meça a dignidade contra um usuário específico em um momento específico. A pergunta do teste, expressa corretamente, é: O trabalho merece existir para este usuário neste momento?

Para blakecrosley.com, o usuário é um leitor que chega diretamente de uma busca, sem contexto, com uma pergunta sem resposta sobre Claude Code, Codex ou infraestrutura. O momento são os primeiros cinco segundos depois que a página carrega, antes de ela ter conquistado qualquer confiança. Uma página que carrega rápido, apresenta seu ponto de vista de forma legível e diz ao leitor algo que a busca ainda não respondeu passou do nível exigido. Uma página que o pune com um pacote lento, um banner de cookies que ele não consegue dispensar e uma parede de texto genérico moldado por SEO falhou, por melhor que pontue no eixo Jiro.

Para ResumeGeni, o usuário é alguém procurando emprego em um momento que trato como vulnerável. A maior parte da lista de espera inicial chegou depois de uma demissão ou no meio de um ciclo de entrevistas.⁶ A versão digna se recusa a tratá-los como uma métrica de conversão. O texto não se esquiva. O analisador não mente sobre o que encontrou. O conselho é concreto o bastante para que possam agir. O fluxo não os abandona no meio do processo porque o caminho ideal foi tudo que eu lancei.

O Polo do Usuário é a verificação que impede o Teste Steve de virar um esconderijo para minhas próprias preferências. Se eu não consigo nomear o usuário, nomear o momento dele e explicar como a superfície lançada o respeita e fortalece, eu não apliquei o teste. Eu apenas o afirmei.

O teste duplo: Jiro mais Steve

A doutrina completa exige dois testes, não um.¹ Eu não lanço nada que falhe em qualquer um deles.

O Teste Jiro pergunta: Isto foi feito corretamente? Ele exige evidência. Casos de borda tratados. Detalhes invisíveis concluídos. Afirmações citam prova concreta. Sem esquiva: eu acredito não é evidência. Testes passam. Sem regressões. A Barreira de Evidência é a versão do Teste Jiro que aplico a relatórios de código e saídas de agentes, e a filosofia de qualidade Jiro é o texto mais profundo.

O Teste Steve pergunta: O trabalho merece existir? Ele exige dignidade. Coerência com o todo. Um ponto de vista visível. Uma recusa ou exclusão nomeada que manteve a superfície limpa. Um mecanismo de encanto ou clareza que o leitor consegue identificar, não algo explicado de modo vago. Aptidão para carregar seu nome.

A arbitragem é simples. Se Jiro falha, pare e corrija. Trabalho incorreto não é lançado; o veto de Jiro é absoluto. Se Jiro passa e Steve falha, reconstrua. Trabalho correto, mas indigno, também não é lançado. Se ambos falham, o problema está acima, no briefing, no enquadramento ou no escopo. Só trabalho que passa nos dois está apto a ser lançado.

A maioria das culturas de lançamento roda silenciosamente apenas um dos dois. Culturas lideradas por engenharia costumam rodar um Jiro forte e um Steve fraco: o produto é lançado quando os testes passam, e a dignidade vira departamento de outra pessoa. Culturas lideradas por design às vezes rodam um Steve forte e um Jiro fraco: o produto é lançado quando parece certo, e a correção vira um problema operacional. Os dois modos de falha produzem artefatos reconhecíveis. Besteira bonita. Trabalho correto, mas sem alma. Você já viu. Talvez tenha lançado alguns.

Os dois testes ficam lado a lado:

Produto inteiro: você responde pela experiência total

O Teste Steve não julga artefatos isoladamente. Ele os julga como parte da experiência total que o usuário encontra.

O incidente de tradução com que abri é o exemplo recente mais limpo, e vale explicitar o mecanismo específico da falha porque ele mostra a forma da armadilha. O mecanismo de contingência do pipeline gravou a fonte em inglês no D1 quando o subprocesso do Claude bateu em um limite de taxa. O gravador do D1 aceitou esses bytes porque eram bytes. O atualizador de ponto de controle calculou o hash do conteúdo armazenado e gravou esse hash no disco. Como a “tradução” armazenada era idêntica à fonte em inglês, os hashes batiam exatamente: bytes idênticos produzindo hashes idênticos. A passagem seguinte com --update comparou o hash da fonte em inglês com o hash armazenado, viu que eram iguais e marcou o lote como inalterado. Cada componente passou no próprio teste Jiro isoladamente. O defeito vivia na composição. Um usuário viu seis localidades com prosa em idiomas misturados por horas antes de um humano abrir uma das páginas.

“Nós respondemos pelo produto inteiro” é a regra. Comportamento de produto, fluxos de UX, linguagem, verdade dos dados, sistemas de suporte, empacotamento, precisão da documentação, prompts, regras, memória, habilidades, ganchos, scripts, orquestração, estrutura de saída. Tudo isso, não apenas o artefato que você lançou por último. Nenhuma vitória local é aceitável se degrada a integridade do todo. O Teste Steve dispara quando uma superfície passa localmente e a experiência total do usuário não passa.

Exclusão: uma camada Steve que só adiciona é falsa

A coisa mais útil que o Teste Steve produz é uma exclusão.

Uma revisão que termina sem remover nada não rodou de fato. O ato de perguntar O trabalho merece existir? diante de uma superfície com complexidade real produz, quase sempre, pelo menos um pedaço de escopo, texto, recurso ou possibilidade de ação que não consegue defender sua presença. Uma revisão que encontra zero dessas peças costuma ser uma revisão conduzida como performance de revisão, não como prática de revisão.

O que o Teste Steve procura, concretamente:

• Superfícies que estão ali porque pareciam seguras de incluir, não porque conquistam seu lugar.
• Texto que se esquiva porque remover a esquiva exigiria uma afirmação real.
• Recursos trazidos de uma versão anterior que já não servem à promessa atual.
• Possibilidades de ação adicionadas para lidar com casos de borda que não ocorrem de fato no escopo atual.
• Opções de configuração que transferem uma decisão que quem fez deveria ter tomado.
• Documentação que descreve um comportamento que o produto não executa mais.
• Testes que cobrem código que deveria ser excluído.

Exclusão é o ato que distingue gosto de acúmulo. A superfície digna é menor do que a versão que você teria lançado se ninguém tivesse feito a pergunta. Nunca me arrependi de remover algo de um produto lançado. Já me arrependi muitas vezes do que deixei entrar.

Recusa como ato principal

Relacionada à exclusão, e mais forte: o Teste Steve muitas vezes dispara antes que qualquer coisa seja construída, não depois. O ato primário do gosto é a recusa: a decisão de não fazer a coisa.

A frase de Steve Jobs que importa aqui é “I’m as proud of what we don’t do as I am of what we do,” relatada em uma matéria de capa da BusinessWeek de 2006 sobre a disciplina de produto da Apple.⁵ As pessoas citam essa frase com frequência porque ela é verdadeira de um modo técnico específico. Todo produto lançado é cercado por um halo invisível de produtos que você se recusou a lançar. Esse halo é o verdadeiro ponto de vista. É a evidência de que um humano tomou a decisão, e não a lista de pendências.

Para blakecrosley.com, a pilha é um registro do que podei. Considerei React e recusei. Considerei Tailwind e recusei. Um bundler ficou na mesa durante as duas primeiras semanas da reconstrução antes de eu cortá-lo. A ausência de node_modules/ em qualquer lugar do repositório não é uma escolha de design; é uma recusa que sustento ao longo do tempo contra a atração gravitacional das ferramentas padrão. Essas recusas moldam o trabalho mais do que qualquer inclusão. Elas definem o padrão que eu estava disposto a sustentar.

Para ResumeGeni, a validação veio limpa. Trezentos e quarenta cadastros de e-mail, doze contatos diretos, três ofertas espontâneas para pagar por acesso antecipado.⁶ A lista de pendências que essa demanda revelou era grande: modelos, colaboração em equipe, painéis de análise, integração com LinkedIn, integração com Indeed, histórico de versões, múltiplos formatos de exportação, um aplicativo móvel. Recusei tudo isso na primeira versão lançada. O que eu não podia recusar: análise precisa, avaliação honesta de lacunas, reescritas concretas que se encaixassem na descrição da vaga, uma exportação que abrisse corretamente no Word, um fluxo que fizesse um usuário vulnerável se sentir seguro. As coisas recusadas não desapareceram para sempre. Elas aguardam do outro lado da primeira superfície digna.

Uma superfície que não recusa nada é uma superfície sem ponto de vista. Se a equipe não recusou nada, o escopo está errado.

Chame a besteira cedo, começando por você

Recusa e exclusão só funcionam se o teste conseguir nomear falso sucesso quando ele aparece. O Teste Steve precisa chamar a besteira, e chamá-la rápido, em:

• Progresso falso. Movimento que parece progresso e não produz coisa nenhuma.
• Evidência contaminada. Um teste que passa pelo motivo errado; estatísticas que provam o que você queria provar em vez do que era verdadeiro.
• Contagem vaidosa. Contagens de commits, contagens de artefatos lançados, gráficos de velocidade: todos presentes, todos fora do ponto.
• Sistemas incoerentes que são lançados limpos em isolamento e degradam uns aos outros em combinação. O incidente de tradução acima é um desses.
• Relatórios de “está tudo dentro do previsto” que encobrem uma decisão que ninguém tomou. O Teste Steve é inimigo deles.
• Atividade de máquina de baixo valor. Trabalho que um computador faz porque consegue, não porque a saída conquista seu lugar.

A versão mais difícil e mais consistentemente útil da regra é: chame a besteira no seu próprio resultado primeiro. O incidente de tradução no início deste ensaio é exatamente isso. O pipeline relatou sucesso. Os logs estavam limpos. Toda métrica que eu tinha instrumentado passou. O trabalho era besteira, e eu precisei chamá-la em mim mesmo antes que os usuários chamassem. Combater a besteira no próprio trabalho é a disciplina que mantém o teste honesto. Polidez não é escudo contra a verdade; ocupação não substitui valor.

Gradiente de superfície: calibrando a aprovação

O Teste Steve não é uma única passagem com um único limiar. Quanto mais difícil for desfazer uma superfície, mais difícil precisa ser a aprovação.²

O teste é a mesma pergunta. O rigor da resposta exigida escala com o raio de impacto. Você pode corrigir uma resposta de chat no turno seguinte; ninguém morre. Uma implantação em produção que falha no Teste Steve queima uma confiança do usuário que levou meses para conquistar, e a correção custa mais do que a decisão original de lançar economizou.

A consequência prática é que a cadência de lançamento deve desacelerar à medida que as superfícies ficam mais difíceis de reverter, não acelerar. Equipes que lançam em velocidade uniforme através de superfícies com reversibilidades muito diferentes estão sinalizando que não acham que o teste varie. Normalmente, elas pararam de aplicá-lo.

Gosto não é temperamento

Há mais uma distinção que o Teste Steve exige, porque é a que se perde com mais frequência. Invocar Steve significa invocar seu gosto, não seu temperamento.

A doutrina proíbe explicitamente o seguinte:³

• Crueldade.
• Humilhação.
• Desprezo teatral.
• Encenação de visionário.
• Agressão como substituto de julgamento.
• Teatro de rancor.
• Drama confundido com padrões.

O sinal de que a camada Steve está realmente operando é a recusa calma. “Não, o trabalho ainda não é digno”, entregue como veredito e seguida do movimento corretivo específico. Não performance. Não humilhação da pessoa que construiu a versão indigna, muitas vezes você mesmo. Não desprezo visível pela equipe. Não transmissão pública de que você tem padrões mais altos. O trabalho passa do nível exigido ou não passa. O nível exigido não é a estética da severidade.

A distinção importa porque a versão caricata de Steve Jobs se concentra no temperamento. Qualquer pessoa que já foi gerida por alguém performando Steve sabe do que estou falando. A crueldade não melhora o trabalho. Ela piora o ambiente e, por substituir julgamento por teatro, também piora o trabalho lançado.

O teste operacional para saber se você está na camada de gosto de Steve ou encenando o temperamento de Steve é se a saída do teste é um movimento técnico específico. “O trabalho não merece existir” não é uma conclusão; é a abertura de uma pergunta. A resposta precisa nomear o eixo que falhou, o movimento corretivo e o próximo teste. Se a revisão termina em “o trabalho é ruim” sem nomear o que o tornaria digno, a revisão foi performance.

O limite de reconstruções e a cláusula anti-paralisia

Um padrão alto sem regra de parada vira evitação. A disciplina que aplico a toda peça de trabalho não trivial tem um limite de três reconstruções honestas.

Uma tentativa honesta significa que você identificou o eixo que falhou, nomeou o movimento corretivo específico, mudou materialmente a abordagem e reavaliou o trabalho contra os dois testes. Três repetições da mesma passagem de polimento não contam como três tentativas. As repetições contam como uma tentativa fracassada repetida três vezes.

Depois de três reconstruções honestas que não produzem trabalho digno, o problema quase nunca é o ofício. O problema vive acima, no enquadramento, no escopo, no briefing ou na composição da equipe. Pare de reconstruir a superfície e olhe para a premissa. Às vezes a promessa era grande demais para o escopo que você consegue sustentar realisticamente com padrão. Às vezes a validação era mais fraca do que você pensava. Às vezes o problema nem é um problema de produto.

O limite de reconstruções resolve dois modos de falha opostos ao mesmo tempo. Ele se recusa a abençoar trabalho fraco e impede que refinamento vire esconderijo. Recusar-se a lançar não é inerentemente virtuoso. Reconstrução infinita em busca de perfeição é seu próprio modo de falha: ofício sem coragem. O alvo não é perfeição. O alvo é digno e lançado. Não puro e pendente para sempre.

Se você está na quarta reconstrução da mesma superfície, parou de fazer um produto e começou a usar o projeto como lugar para se esconder.

Sinais observáveis: o teste foi realmente aplicado?

O Teste Steve é fácil de alegar e difícil de aplicar de verdade. A disciplina é declarar, concretamente, o que o teste produziu.

Antes de chamar uma peça de trabalho não trivial de completa, garanto que consigo responder a todas as perguntas a seguir:⁴

1. Quem é o usuário? Não um arquétipo de persona. Uma pessoa real em uma situação real.
2. Que ponto de vista esta superfície carrega? Se você não consegue nomear um, não há ponto de vista, apenas uma lista de pendências.
3. O que você recusou ou removeu para manter isto limpo? A exclusão é a evidência de que o teste rodou.
4. Como isto serve ao produto inteiro? A peça precisa ser coerente com todas as outras peças. Vitórias locais que degradam o todo não são vitórias.
5. Que evidência prova que isto é sólido? O eixo Jiro. A verificação rodou; a afirmação é sustentada.
6. Por que isto é digno? Declarado com clareza. Se a resposta é vaga, o teste não rodou.
7. Eu assinaria meu nome nisso sem hesitar? O oráculo do gosto. Quando o julgamento é incerto, a pergunta governante na pilha.

Se eu não consigo responder a todas as sete com especificidade, afirmei a doutrina em vez de aplicá-la. Eu mando o trabalho voltar.

Exemplo prático: os sete sinais diante de uma superfície real

Aqui estão os sinais aplicados a uma superfície específica lançada depois do incidente de tradução: uma proteção contra concorrência que escrevi no pipeline de tradução. Cerca de 100 linhas de Python que se recusam a iniciar guide_bootstrap.py ou blog_translate_batch.py se outro processo de tradução já estiver rodando.

1. Quem é o usuário? Eu no início de uma rodada de tradução daqui a duas semanas, quando terei esquecido o modo exato de falha por limite de taxa que queimou seis localidades. Também qualquer agente que invoque qualquer um dos scripts em uma sessão futura.
2. Que ponto de vista a superfície carrega? Rodadas de tradução concorrentes nunca são a ferramenta certa. A proteção codifica esse veredito em código para que o próximo chamador não precise lembrá-lo.
3. O que recusei ou removi para manter isto limpo? Recusei transformar a proteção em um aviso. Recusei dar a ela uma flag de substituição curta e conveniente como --force. A única substituição é uma variável de ambiente, I18N_ALLOW_CONCURRENT=1, longa o bastante para que ninguém a digite por acidente.
4. Como ela serve ao produto inteiro? O pipeline de tradução, o gravador do D1 e o mecanismo de contingência são individualmente corretos. A proteção é a peça que impede que eles se combinem em um todo que corrompe silenciosamente.
5. Que evidência prova que ela é sólida? Verifiquei a proteção com duas checagens manuais. Uma: retorno limpo quando nenhum outro job de tradução roda. Duas: saída diferente de zero quando um subprocesso real de guide_bootstrap.py está vivo. As duas checagens rodaram contra os scripts reais, não contra simulações.
6. Por que ela é digna? A mesma corrida de execuções concorrentes que corrompeu seis localidades não consegue produzir linhas em idiomas misturados no D1 enquanto a proteção estiver ativa. Ela não previne todos os casos; ela previne o modo de falha específico que a doutrina acabou de aprender.
7. Eu assinaria meu nome nisso? Sim. Um job, semântica limpa de substituição, documentado em uma nota de memória para que uma sessão futura herde o motivo de a proteção existir.

O ponto do exemplo prático é que cada sinal tem uma resposta específica. Quando não consigo produzir uma, o teste ainda não rodou.

Compare isso com o aspecto da falha. Quando rascunhei a proteção contra concorrência, minha primeira tentativa no sinal 3 foi: “Eu me recusei a complicar demais.” A frase é o tipo de resposta que soa bem e não diz nada. Recusar complicar demais não nomeia nenhuma coisa específica que considerei e rejeitei. É uma postura, não uma recusa. Obriguei-me a escrever a resposta real: recusei transformar a proteção em um aviso; recusei um nome conveniente de flag de substituição; recusei um comportamento em que a proteção falharia aberta se não conseguisse listar processos. Essas são decisões. A primeira versão era teatro de doutrina.

Principais aprendizados

Para fundadores e construtores solo: - Nomeie o usuário real no momento real antes de chamar qualquer superfície de digna. Dignidade abstrata é inutilizável. - Toda superfície lançada deve ter pelo menos uma recusa visível. Se você não removeu nada, o escopo está errado. - Aplique o gradiente de superfície. Implantação em produção exige uma aprovação mais dura do que um rascunho; afirmações de marketing exigem a aprovação mais dura de todas.

Para líderes de produto e PMs: - Meça se o Teste Steve está realmente rodando contando recusas e exclusões por ciclo de lançamento. Zero é um sinal ruim. - Separe “funciona” de “merece existir” nas suas próprias listas de revisão. Trate-os como eixos independentes. - Proteja o orçamento de reconstrução. Três tentativas honestas, depois escale. Não deixe o perfeccionismo virar esconderijo e não deixe a pressão de prazo matar o teste.

Para líderes de engenharia: - Nomeie uma barreira Jiro e uma barreira Steve para toda superfície que sua equipe lançar. Ambas precisam passar. - Invista nos detalhes invisíveis. A diferença entre correto e digno geralmente vive nas costuras. - Recuse o temperamento. Recusa calma é o sinal. Performance de severidade é o modo de falha.

Para designers: - Ponto de vista não é decoração. É o mecanismo que torna o produto reconhecível. - Uma superfície digna recusa coisas, visivelmente. Seu trabalho inclui nomear o que você cortou. - O teste operacional na ambiguidade: você assinaria seu nome na decisão sem hesitar?

Encerramento: eu assinaria meu nome nisso?

A pergunta governante em produto é O trabalho merece existir? A pergunta governante quando o julgamento é incerto é a mais simples da pilha.

Eu assinaria meu nome nisso sem hesitar?

Se a resposta é sim, o trabalho está apto a ser lançado. Se a resposta é “ainda não, mas ficará dentro de três reconstruções honestas”, continue trabalhando. Se a resposta é não, e continua não depois de três tentativas honestas, reconstrua o briefing, não a superfície.

Eu rodo esse teste toda vez. No código. No texto. Na mensagem de commit. Na documentação. Na superfície do produto. Neste ensaio.

Este ensaio cortou três seções que eu achava necessárias quando comecei a rascunhar: uma longa seção biográfica sobre Jobs, uma introdução à frase sobre “deixar uma marca no universo” e uma defesa de por que a doutrina usa o nome de uma pessoa real em vez de uma abstração. Nenhuma delas servia ao usuário para quem eu estava escrevendo: um construtor tentando decidir se deve lançar uma superfície sobre a qual não tem certeza. Os cortes tornaram a peça menor e mais honesta. E a falha de tradução que abre o ensaio produziu um artefato permanente além da correção: uma proteção contra concorrência no pipeline de tradução que agora se recusa a iniciar se outro job de tradução já estiver rodando. Trabalho rejeitado produziu uma mudança nas regras. A doutrina aprendeu.

Steve passa. Jiro passa. Vai para o ar.

Perguntas frequentes

O que é o Teste Steve?

O Teste Steve pergunta se uma peça de trabalho merece existir para um usuário real em um momento real. Ele fica ao lado da filosofia de qualidade Jiro: Jiro verifica correção, evidência e casos de borda; Steve verifica dignidade, coerência, recusa e gosto.

Como o Teste Steve é diferente do Teste Jiro?

Jiro pergunta se o trabalho foi feito corretamente. Steve pergunta se o trabalho correto deve ser lançado. Um recurso pode passar nos testes e ainda falhar com o usuário, com o produto ou com o ponto de vista por trás da superfície.

Quando uma equipe deve rodar o Teste Steve?

Rode-o antes de superfícies irreversíveis serem lançadas: implantações públicas, afirmações de marketing, fluxos de onboarding, páginas de preço, documentação e recursos de produto que moldarão a confiança do usuário. Trabalho leve pode usar uma aprovação mais suave, mas superfícies públicas precisam de uma aprovação estrita.

O que o teste deve produzir?

O teste deve produzir uma decisão específica: lançar, reconstruir, excluir ou recusar. Uma aprovação real nomeia o usuário, o momento, o ponto de vista, a evidência e pelo menos uma coisa que a equipe removeu para preservar o todo.

O Teste Steve pode virar perfeccionismo?

Sim. É por isso que a doutrina precisa de um limite de reconstruções. Três reconstruções honestas são suficientes; depois disso, o problema geralmente vive acima, no briefing, no escopo, na equipe ou na premissa.

O modelo de revisão

Copie isto para um rascunho, uma descrição de PR, uma página no Notion ou o topo da sua mensagem de commit. Preencha antes de declarar trabalho não trivial como concluído. Se você não consegue responder uma linha com algo específico, o teste ainda não rodou.

Teste Steve: Registro de revisão

Usuário:              [pessoa real em uma situação real, não um arquétipo de persona]
Momento:              [o momento específico em que o usuário encontra o trabalho]
Ponto de vista:       [o que esta superfície afirma; o que ela se recusa a fazer]
Recusa:               [o que considerei e cortei, ou declinei construir por completo]
Produto inteiro:      [como isto se torna coerente com cada peça adjacente do produto]
Evidência:            [eixo Jiro: a verificação rodou; prova específica de que a afirmação é sustentada]
Veredito de dignidade:[sim / não / ainda não, dentro de N reconstruções definidas]
Assinatura:           [eu assinaria meu nome nisso sem hesitar? se não, pare]

O modelo tem exatamente uma função. Forçar quem testa a produzir uma resposta específica em cada linha. Respostas vagas não passam do nível exigido. “Eu me recusei a complicar demais” não é uma recusa; “recusei uma flag de substituição conveniente e um caminho que falha aberto” é. “Serve ao usuário” não é uma resposta de produto inteiro; “fecha a lacuna composicional específica que causou o último incidente” é. Quando uma linha resiste à especificidade, o trabalho não está pronto; essa resistência é o teste dizendo para onde a reconstrução vai.

Este modelo é o artefato operacional do ensaio. Todo o restante desta página é explicação de por que as linhas existem.

Referências