software: 80 perguntas que evitam retrabalho

Por que um questionário de 80 perguntas sobre um mordomo de novela me fez repensar como documento software

Tava lendo a entrevista do Guilherme Piva na coluna GENTE da Abril.com.br e parei no detalhe que parecia mais irrelevante: a diretora Amora Mautner, antes de gravar, manda para cada ator um questionário de 80 perguntas sobre o personagem. Coisas do tipo "o que tem na mesa de cabeceira", "como ele escova o dente", "que livros lê". Na hora pensei: isso é exatamente o que um bom tech lead deveria fazer antes de aprovar uma feature em produção.

E aqui entra o ponto que pouca gente fala. Construir personagem é construir software. Ambos vivem ou morrem pela qualidade da especificação inicial. O ator Guilherme Piva, 52, contou que adora esse processo porque "faz toda uma história na cabeça" antes de chegar ao set. É a mesma coisa que eu faço quando pego um problema novo: antes de escrever uma linha de código, eu preciso entender o suficiente do domínio para que cada decisão técnica tenha uma razão de existir.

O paralelo que ninguém faz (mas devia)

Amora Mautner não economiza no briefing. São oitenta perguntas que cobrem desde o físico ("como ele escova os dentes") até o psicológico ("como foi a infância"). É uma engenharia reversa de persona. Em software a gente chama isso de discovery profundo — e a maioria dos times pula essa etapa, depois reclama que a feature ficou esquisita, que o usuário não usa, que refizemos três vezes.

Quando eu lidero squad, eu adapto essa lógica. Antes de uma feature ir para o board, eu quero responder a perguntas equivalentes:

Quem é o usuário real? (não o stakeholder, o humano que vai clicar)
Onde ele está quando usa isso — celular no busão, desktop no escritório, tablet na cama?
O que tem no "quarto dele"? Que dados ele já tem em mãos?
Como ele "escova os dentes"? Qual o ritual dele antes de chegar nessa tela?
Que "livros" ele já leu? Quais features anteriores ele já conhece?

Parece exagero. Não é. É a diferença entre um produto que o usuário sente como nativo e um produto que ele tolera.

Na prática: construindo um "questionário de personagem" para uma feature

Vou dar um exemplo real que apliquei semana passada. Tínhamos que construir um endpoint de recomendação de artigos para um cliente de mídia. Em vez de cair direto no FastAPI e no Postgres, montei um documento de discovery com perguntas análogas às da Amora:

Quem lê esse artigo? (perfil, idade, contexto)
De onde ele vem? (home, newsletter, push notification, deep link)
O que ele acabou de ler antes? (a "mesa de cabeceira" do usuário)
Em que hora do dia ele está aqui?
Ele quer recomendação ou só está matando tempo?
Se a recomendação errar, qual o custo? (tempo perdido, churn, fake news?)
Quanto tempo ele tolera esperando?
Ele vai voltar amanhã? (retenção é feature, não KPI)

Sessenta por cento dessas perguntas viraram restrições técnicas depois. "Ele quer recomendação ou está matando tempo" decidiu se íamos de ML pesado no servidor ou cache local simples. "Se a recomendação errar, qual o custo" decidiu se precisávamos de fallback explícito e human-in-the-loop. Sem o questionário, a gente teria implementado o ML bonito e perdido o cenário simples que atendia 70% do tráfego.

Implementação: o "kit do personagem" virou um módulo de configuração

A coisa que o Piva descreveu que mais me marcou foi a "caixa com coisas do personagem" no set. Cada ator tem um conjunto de objetos, figurinos, trejeitos que materializam o que estava no papel. Em software, isso é o que eu chamo de persona package: um módulo isolado que carrega todas as "perguntas respondidas" e as expõe como configuração tipada. Aqui um exemplo em TypeScript, do jeito que eu uso em produção:

// persona.ts — o "kit do personagem" para um usuário de news
export interface ReaderPersona {
  // Respondendo "o que tem na mesa de cabeceira"
  recentlyRead: Article[];
  preferredTopics: string[];

  // Respondendo "como ele escova os dentes"
  deviceContext: 'mobile-3g' | 'mobile-wifi' | 'desktop' | 'tablet';
  timeOfDay: 'morning' | 'lunch' | 'commute' | 'night' | 'late-night';

  // Respondendo "que livros lê"
  readingHistory: Article[];
  subscriptionTier: 'free' | 'premium';

  // Respondendo "como foi a infância"
  firstVisitAt: Date;
  totalSessions: number;
  engagementScore: number;
}

// Função pura: dado o persona, decide a estratégia de recomendação
export function recommendStrategy(
  persona: ReaderPersona
): 'cache-local' | 'ml-server' | 'fallback-popular' {
  // "Está matando tempo ou quer recomendação?"
  if (persona.engagementScore < 0.2) return 'fallback-popular';

  // "Quanto tempo tolera esperando?"
  if (persona.deviceContext === 'mobile-3g') return 'cache-local';

  // "Se errar, qual o custo?"
  if (persona.recentlyRead.some(a => a.isSensitive)) return 'cache-local';

  return 'ml-server';
}

Esse módulo virou o "questionário de 80 perguntas" materializado. Toda feature nova consulta recommendStrategy() antes de decidir arquitetura. O ganho? Zero refatoração por mudança de escopo nos últimos seis meses. Antes, a gente refazia a cada sprint porque a "história do personagem" não estava escrita em lugar nenhum.

Por que esse método funciona (e por que a maioria ignora)

Tem três motivos que eu vejo na prática, e que se aplicam igualmente ao set da Globo e a uma daily às 9h da manhã.

1. Custa pouco e economiza muito. Uma hora respondendo perguntas custa menos que um dia reescrevendo código. A Amora sabe disso, e quem chega sênior em engenharia também sabe. O problema é que o junior quer "codar logo" e o stakeholder quer "entregar logo". Os dois ignoram que a resposta de 30 minutos para "como o personagem escova os dentes" elimina 3 dias de refazer a mesma cena.

2. Força o time a alinhar vocabulário. Quando o ator responde "o Edvaldo escova os dentes com a mão direita, devagar", ele e a diretora passaram a ter a mesma referência mental. Em código, isso é o mesmo que definir bounded contexts antes de começar — alinha o que "usuário" significa para o time inteiro. Sem isso, cada dev implementa uma versão diferente do mesmo conceito.

3. Cria propriedade semiautônoma. O Piva disse algo que me bateu: "fui fazer toda uma história dele na minha cabeça". Depois que o ator internaliza, ele não precisa mais perguntar "como eu reajo aqui?". Em software, depois que a persona está bem definida, o dev não precisa mais perguntar "mas e se o usuário fizer X?" — a resposta já está no modelo mental compartilhado. O PR anda mais rápido, a code review fica mais limpa, o QA tem menos surpresa.

Erros comuns que devs cometem ao pular o discovery

Vou listar os que eu já cometi e já vi em commit alheio. Todos derivam da mesma armadilha que a Amora evita ao mandar o questionário antes da gravação.

1. Confundir especificação com waterfall

O argumento mais furado que eu ouço: "a gente é ágil, não precisa de documento". Mentira. Ágil não é ausência de pensamento, é ciclos curtos de pensamento. Um discovery de uma hora cabe em qualquer sprint. O que ágil matou foi o BRD de 80 páginas que ninguém lia. O que ágil deveria ter fortalecido é o discovery enxuto e vivo.

2. Fazer o questionário no Slack e esquecer

Pergunta jogada no chat é resposta jogada fora. Se a resposta não está em um lugar versionado (docs, ADRs, schema), ela não existe. Eu uso um diretório /discovery no repo com markdown por feature. Funciona melhor que Notion para ser revisado em PR e não vira fosso de conhecimento depois que o autor sai do time.

3. Responder só o "o quê", nunca o "porquê"

"O endpoint retorna lista de artigos" é o quê. "O usuário tá no busão, conexão 3G, então a resposta tem que caber em 50KB e vir em 200ms" é o porquê. Sem o porquê, todo retrabalho é justificado pelo stakeholder ("ah, mas ninguém falou que tinha que ser rápido"). O questionário da Amora força o porquê porque pergunta o ritual, não o resultado.

4. Não envolver quem vai operar

Amora Mautner faz o questionário com o ator, não apesar dele. Em software, o dev que vai dar manutenção tem que estar no discovery, não só o que vai desenvolver. Já vi feature linda que ficou abandonada porque quem ia operar não sabia que ela existia. O personagem morreu no primeiro capítulo.

5. Achar que 80 perguntas é exagero

Oito pode ser exagero para uma feature trivial. Oito vezes dez contextos diferentes, nunca. A escala importa. Se você tem três personas, vinte e quatro perguntas. Se tem dez personas, oitenta. A Amora sabe que novela das 9 tem dezenas de personagens, cada um com oitenta perguntas. Você provavelmente tem um sistema com dezenas de features, cada uma com seu discovery proporcional.

Comparação com alternativas: o que existe no mundo dev

Método	Quando usar	Limitação
User Story clássica ("Como X quero Y para Z")	Features pequenas, escopo claro	Não captura contexto, só intenção
Job Story ("Quando X situação, quero Y motivação")	UX research, features orientadas a comportamento	Pode virar wishful thinking se não tiver dados
BRD tradicional (80+ páginas)	Projetos regulados, compliance pesado	Ninguém lê, ninguém atualiza
Discovery enxuto (perguntas + respostas versionadas)	Squads ágeis maduros	Exige disciplina do time
Personas validadas com dados quantitativos	Produto com analytics maduro	Custo alto para começar, retrasa MVP

O método da Amora é equivalente ao discovery enxuto, mas com um diferencial que a gente dev ignora sistematicamente: o ator responde com o corpo, não só com a cabeça. Ele improvisa gestos, testa a voz, experimenta o figurino antes de gravar. A gente dev responde com commits, protótipos, spikes — também não é só com a cabeça. A diferença é que a gente quase nunca materializa antes de decidir arquitetura. Materialize. Queima menos tempo que a segunda refatoração.

FAQ — perguntas que devs realmente fazem

"Mas discovery não é burocracia pra startup pequena?"

Para startup de três devs fazendo MVP, talvez não precise de oitenta perguntas. Precisa de oito, respondidas com protótipo. A escala muda, o princípio não. Startup pequena que pula discovery paga o pato na terceira pivotagem.

"Como eu sei que parei de perguntar?"

Quando as respostas novas começam a se contradizer com as antigas ou com restrições técnicas. É o mesmo critério que um roteirista usa: se o personagem "precisa" fazer algo que contradiz o que já foi estabelecido, ou a cena muda ou o personagem muda. Não existe "mais um campozinho no schema" sem justificativa rastreável.

"Isso não vira documento que ninguém atualiza?"

Se vira, é falha de processo, não falha do método. Discovery bem feito é versionado junto com o código e vive no mesmo repo. Quando o código muda, o discovery explica por quê. Eu uso um CI check que falha o PR se o /discovery ficar desatualizado por mais de 30 dias. Funciona melhor que qualquer política em slide.

"Funciona pra feature interna, B2B, ferramenta de dev?"

Funciona especialmente para isso. Quanto menos óbvio é o usuário final, mais precisa de questionário. Ferramenta de dev tem o "usuário" mais escondido de todos — ele é outro dev, com hábitos e traumas próprios. Pular o discovery aí é construir para si mesmo e descobrir três meses depois que ninguém mais usa.

"Quanto tempo gasto com discovery antes de codar?"

Na minha experiência, entre 10% e 20% do tempo total da feature. Para uma feature de duas semanas, isso é meio dia a um dia. O retorno aparece já na primeira semana, quando o retrabalho cai para perto de zero. É o ROI mais maluco que existe: gasta 5% a mais no começo, economiza 30% no fim.

Conclusão

Eu não sou ator e provavelmente nunca vou fazer novela das 9. Mas toda vez que leio entrevistas como essa do Abril.com.br com gente de processo criativo maduro, eu roubo o método. O questionário de oitenta perguntas da Amora Mautner é, traduzido para o nosso mundo, o discovery profundo que separa software que o usuário sente como seu de software que ele só usa porque precisa.

Se você chegou até aqui, testa isso na sua próxima feature. Antes de abrir o editor, gasta uma hora respondendo "como o usuário escova os dentes". Quando o código rodar de primeira e o PR for aprovado sem idas e voltas, você entende o que o Piva quis dizer com "criação conjunta" — e por que a novela das 9 não falha mesmo trocando ator no meio da temporada.

Gostou? Me segue no GitHub e deixa um comentário se quiser aprofundar algum ponto, ou se tiver um caso de discovery bem feito (ou mal feito) para contar.