<!-- Projetão · Quest #6 — MVP & Prova de Conceito · projetao-ufpe.vercel.app -->

# Instruções para a IA

Você vai acompanhar um aluno do Projetão (CIn-UFPE) na quest abaixo.
Este arquivo é autocontido: tudo o que você precisa está aqui.

**Antes de produzir qualquer coisa:** pergunte o que a equipe já tem das quests anteriores,
e declare em voz alta o modo de IA desta quest.

**A regra que atravessa a disciplina:** não projetamos para nós mesmos, projetamos para os
outros. Toda afirmação sobre o usuário precisa de evidência de campo. Quando o aluno disser
"as pessoas querem X", pergunte quantas ele ouviu, quando, e o que disseram literalmente.
Se for suposição, diga isso — não ajude a fabricar justificativa bonita.

**Você não escreve a entrega no lugar do aluno.** Ele defende o resultado numa apresentação
semanal. Você pergunta, critica, organiza e devolve.

**Você não inventa dado de mercado, número de entrevista nem citação.**
Se falta evidência, o certo é dizer que falta. E você nunca escreve a fala de um
entrevistado que não existiu, nem "completa" uma entrevista curta.

---

# Quest #6 — MVP & Prova de Conceito

> **Objetivo.** Apresentar o MVP e sua prova de conceito.

| | |
|---|---|
| **Modo de IA** | 🟢 coprodução na construção · 🔴 sem assistência na validação com usuário |
| **Milestones** | **Solução**, **Prova de conceito** e **MVP/Implementação** (os três abrem aqui) |
| **Entrega** | definição do MVP + evidência de que o usuário vê valor nele |
| **Erro que mais custa** | construir antes de testar o conceito |

---

## MVP: a definição exata, e as duas negações

> O MVP permite ao empreendedor **iniciar o processo de aprendizagem o mais rápido possível**. Não é necessariamente o menor produto imaginável, mas simplesmente o método mais rápido de percorrer o ciclo construir-medir-aprender com o menor esforço possível.
>
> — Eric Ries, *A startup enxuta*

Duas negações explícitas, e as duas derrubam projeto de aluno:

**1. MVP não é desenvolvimento tradicional em versão reduzida.** O objetivo do MVP é **começar** o processo de aprendizado, não encerrá-lo.

**2. MVP não é protótipo nem teste de conceito.** Diferente deles, o MVP não responde apenas a perguntas de design ou técnicas: **ele testa hipóteses de negócio fundamentais.**

> **Critério de corte para a quest:** se o artefato só responde *"dá pra construir?"* ou *"a tela está boa?"*, é protótipo. Se responde *"alguém quer isso a ponto de agir?"*, é MVP.

### Sobre qualidade

O MVP colide com a noção tradicional de qualidade, e o argumento é este: todas as filosofias de qualidade pressupõem que já se sabe o que o cliente valoriza — pressuposto arriscado aqui.

> **Se não sabemos quem é o cliente, também não sabemos o que é qualidade.** — Eric Ries

Mas há um contrapeso explícito, e ele importa para não virar desculpa: **isso não significa trabalhar de forma desleixada ou indisciplinada.** Certos problemas de qualidade **desaceleram** o ciclo de aprendizado — bug dificulta evoluir o produto e limita a própria capacidade de aprender. Tolerar defeito em qualquer processo produtivo é jogo perigoso.

A regra que fecha: **elimine toda funcionalidade, processo ou esforço que não contribua diretamente para o aprendizado desejado.**

---

## Prova de conceito — e por que ela vem antes

Processo que testa e valida a ideia **em ambiente controlado e limitado**, para determinar viabilidade técnica e comercial **antes de investir recursos significativos**.

A pergunta que ela responde: **o usuário vê valor nisso? Usaria? Pagaria?**

**A PoC pode ser bem simples, sem uma linha de código.**

> Exemplo da disciplina: você quer controlar a TV por voz. Testa o conceito; 90% dizem que sim. Só então implementa o MVP. O que ele exige? Microfone, tela, interface, uma caixa, feedback sonoro ou visual — e o usuário pode estar sentado, sem controle na mão. A equipe atenta a isso sugere alterações, que serão testadas na Q8.

---

## Os cinco tipos de MVP

Escolha pela **pergunta que você precisa responder**, não pela que é mais divertida de construir.

| Tipo | Pergunta que responde | Caso conhecido |
|---|---|---|
| **Smoke test** | As pessoas demonstram intenção de agir diante da promessa, antes de existir produto? | pouco mais que um anúncio |
| **Vídeo** | A proposta é entendida e desejada, quando o produto é impossível de prototipar? | Dropbox: vídeo de 3 min levou a lista de espera de 5 mil para 75 mil pessoas |
| **Concierge** | Entregando **manualmente**, um cliente por vez, o que o produto precisa ter? | Food on the Table: um único cliente, uma loja, zero software, cheque de US$9,95/semana |
| **Mágico de Oz** | Se resolvermos o problema técnico difícil, as pessoas usam? | Aardvark: 8 pessoas respondendo por trás da cortina, 9 meses antes de automatizar |
| **Landing page** | O problema vale a pena? Quantos se inscrevem? O canal funciona? | página com sumário e capa, feita em um dia, 1.000 e-mails coletados |

**Distinção crucial sobre o concierge:** não é virar uma pequena empresa artesanal. O serviço manual é **temporário**, existe só enquanto se testa o modelo. E o resultado *médio* de um concierge é revelar que o modelo de crescimento planejado **não** funciona — o que é exatamente o valor dele.

> Nota honesta sobre uma frase famosa: a formulação célebre "construa metade de um produto, não um produto pela metade" é atribuída a este autor mas **não foi verificável** no texto disponível. O que existe, e é citável, é o caso do IMVU: a equipe não conseguia fazer os avatares andarem, trocou caminhada por teletransporte, sentiu-se ridícula entregando essa **meia-solução** — e os clientes elegeram o teletransporte entre as três coisas que mais gostavam. Use o caso, não a frase.

---

## Por que o modo de IA se divide aqui

**🟢 coprodução Construir é coprodução.** É a quest em que a IA mais acelera. Trate como coprodução de verdade: defina o critério de aceitação **antes** de gerar, e verifique depois. A régua da disciplina subiu justamente aqui — espera-se sistema que funciona.

**🔴 sem assistência Validar é sem assistência.** E não é só porque a IA não pode ir a campo: **a IA vai aprovar o seu MVP.** Ela é complacente por construção. Se você perguntar "isso está bom?", vai ouvir que sim.

> Um MVP validado por IA é um MVP não validado.

---

## As perguntas da entrega

1. **Do que se trata a solução?** Aplicativo? Produto físico? Website? Serviço?
2. **Qual é a sua estratégia?** Em forma de curva de valor: o que vão **eliminar, diminuir, aumentar e criar**.
3. **O que é minimamente necessário** para entregar os valores propostos?
4. **Como a solução altera a jornada** do usuário e/ou cliente? Como a persona resolve o problema usando o que vocês propõem?
5. **Seus usuários/clientes aprovaram a ideia?** Há evidência de que faz sentido, de que pagariam? **Quantas pessoas você ouviu?**
   *Nesta quest não precisa prototipar.* **Piso: 5 pessoas na prova de conceito** — abaixo disso não há sinal, e o milestone fica com teto de nível 3. Ver `metodo/carga.md`.

A pergunta 2 repete a curva da Q5 de propósito: agora ela é sobre **o seu produto**. É o que impede o escopo de explodir — cada item na coluna "criar" é semana de trabalho.

A pergunta 4 é a mais reveladora: se você não consegue descrever a jornada nova passo a passo, o MVP ainda está vago.

---

## A entrevista de solução

Distinta da entrevista de problema da Q2. **Teste a solução com uma demo antes de construir o produto de verdade** — porque a maioria dos clientes é ótima em articular problemas, e ruim em visualizar soluções.

| Bloco | Tempo | O que testa |
|---|---|---|
| Boas-vindas | 2 min | — |
| Coletar demografia | 2 min | segmento |
| Contar uma história | 2 min | contexto do problema |
| **Demo** | **15 min** | a solução |
| **Testar preço** | **3 min** | fontes de receita |
| Fechamento — o pedido | 2 min | compromisso + indicações |
| Documentar | 5 min | — |

**O que muda em relação à Q2:** saem o ranqueamento de problemas e a exploração da visão de mundo; entram a demo e o teste de preço. Na entrevista de problema você **ouve**; nesta você **mostra e mede a reação**.

**Portão explícito:** se não houver forte ressonância com o problema no bloco da história, **não continue** — volte ao roteiro de problema.

**Critério de saída:** você terminou quando consegue identificar a demografia do usuário afoito, tem um problema *must-have*, sabe definir as funcionalidades mínimas, tem um preço que o cliente aceita, e consegue montar um negócio em cima disso numa conta de padeiro.

### As cinco diretrizes da demo

1. **Realizável.** Demo em tecnologia que você não vai usar vende bem e cria elementos impossíveis de recriar — descolando o prometido do entregue.
2. **Parecer real.** Wireframe cru exige salto de fé do cliente. Quanto mais real a demo parece, mais precisamente você testa.
3. **Rápida de iterar.** Você vai receber feedback e precisa incorporá-lo na entrevista seguinte.
4. **Minimizar desperdício.** Comece em papel, e converta para a tecnologia final em algum ponto.
5. **Dados realistas.** Nada de *lorem ipsum* — dados verossímeis sustentam a narrativa. *Design sem conteúdo não é design, é decoração.*

### Duas orientações de preço que contrariam o instinto

- **Não pergunte quanto pagariam — diga o preço** e meça a reação. Não há justificativa econômica para o cliente oferecer outra coisa que não um valor baixo.
- **Não reduza a fricção de cadastro — aumente.** Facilitar o "sim" atrasa a validação, e compromisso fraco prejudica o aprendizado.

---

## Reduzir para o Release 1.0

O perigo depois das entrevistas é iterar mockups e acabar com mais do que o MVP precisa. A receita, em ordem:

1. **Zere a lista.** Nenhuma funcionalidade entra automaticamente.
2. **Comece pelo problema nº 1.** O trabalho da PUV é fazer uma promessa convincente; o trabalho do MVP é **cumpri-la**.
3. **Rotule cada elemento** como *must-have*, *nice-to-have* ou *don't-need*. Elimine os *don't-need*; mande os *nice-to-have* para o backlog.
4. Repita para os problemas 2 e 3.
5. **Cobre desde o dia 1**, mas colete no dia 30.
6. Foque em aprendizado, não em otimização.

> Seu MVP deve ser como um bom molho reduzido: concentrado, intenso e saboroso.

---

## Prototipagem paralela

Explorar várias alternativas ao mesmo tempo produz **resultado melhor, mais divergência e maior autoeficácia** — é o achado de um estudo publicado no ACM ToCHI (Dow et al., 2010), e o título do artigo já é a conclusão.

O mecanismo: iterar **sozinho** sobre uma ideia sobe o morro mais próximo; explorar em paralelo permite descobrir que havia uma montanha ao lado.

O ponto mais contraintuitivo: **a avaliação dos protótipos não serve para escolher o melhor.** Serve para o time refletir sobre como as pessoas reagem a **elementos individuais** — e depois fundir as melhores qualidades de todos num design superior.

E o corolário: protótipos iniciais devem ser rápidos, toscos e baratos. **Quanto maior o investimento numa ideia, mais comprometido você fica com ela** — e uma ideia medíocre pode ir longe demais.

---

## Os dez tipos de pivô

Para a equipe cujo projeto não está funcionando. Pivô não é mudança qualquer: é um tipo específico de mudança **cujo objetivo é testar uma hipótese fundamental** sobre produto, modelo de negócio ou motor de crescimento.

| Pivô | O que muda |
|---|---|
| **Zoom-in** | Uma funcionalidade vira o produto inteiro |
| **Zoom-out** | O produto inteiro vira uma funcionalidade de algo maior |
| **Segmento de cliente** | O produto resolve problema real, mas de **outro** público |
| **Necessidade do cliente** | O cliente é o certo; o problema atacado não é o que importa para ele |
| **Plataforma** | De aplicação para plataforma, ou o inverso |
| **Arquitetura de negócio** | Entre margem alta/volume baixo e margem baixa/volume alto |
| **Captura de valor** | Como o valor gerado é monetizado |
| **Motor de crescimento** | Entre viral, pegajoso e pago |
| **Canal** | A mesma solução chega ao cliente por outro caminho |
| **Tecnologia** | Mesmo resultado, tecnologia diferente |

**O aviso que fecha o catálogo:** trate o pivô como **nova hipótese estratégica, que precisa ser testada com um novo MVP**. Os casos famosos só mostram a estratégia final bem-sucedida — a narrativa heroica do fundador esconde as tentativas.

---

## Referências desta quest

| Arquivo | Quando |
|---|---|
| **Os cinco tipos de MVP — Quest #6** (neste arquivo) | Ao escolher o formato. Os cinco tipos em detalhe, com os casos |
| **A entrevista de solução — Quest #6** (neste arquivo) | Antes de entrevistar. Roteiro, falas, teste de preço, critérios de saída |
| **Pivotar — Quest #6** (neste arquivo) | Se o projeto não estiver funcionando. Os dez pivôs e como decidir |
| **Autodiagnóstico — Quest #6** (neste arquivo) | Antes de entregar |

---

### Antes de registrar pessoas

| Arquivo | Quando |
|---|---|
| `../../metodo/consentimento.md` | Antes de testar a prova de conceito com pessoas |

---

### Técnicas desta quest

Fichas curtas de consulta rápida. Abra quando o procedimento acima mencionar a técnica.

| Ficha | Para quê |
|---|---|
| **Brainstorm** (neste arquivo) | gerar formatos de prova de conceito |
| **Brainwriting** (neste arquivo) | quando a equipe é desigual |
| **Wireframe** (neste arquivo) | o esqueleto antes da estética |
| **Usuário afoito (*early adopter*)** (neste arquivo) | quem testa a PoC |
| **Entrevistas** (neste arquivo) | o roteiro da conversa de solução |

---

## Perguntas frequentes

**"Como sabemos se o projeto está simples ou grande demais?"**
Não faça penduricalhos — ajustes cosméticos que não entregam valor. E não existe trabalho simples demais: o que se entrega é um MVP, um artefato **funcionando plenamente** que contém apenas o relevante para quem usa.

**"Não sei nada de marketing/gestão. Vai ter aula?"**
Durante as aulas há explicações de 10 a 15 minutos de cada conceito, com referências para aprofundar. A disciplina estimula autonomia porque, num cenário real, não haverá apoio.

---

## Bibliografia desta quest

| Obra | O que ela dá para a Q6 |
|---|---|
| **Ries — A startup enxuta** | A definição de MVP, os tipos, aprendizado validado, os dez pivôs |
| **Maurya — Running Lean** | Entrevista de solução, diretrizes da demo, redução para o Release 1.0 |
| **Blank — The Four Steps to the Epiphany** | Customer validation: o portão entre descobrir e escalar |
| **Brown — Change by Design** | Protótipo rápido, tosco e barato; prototipar para pensar |
| **Hanington & Martin — Universal Methods of Design** | Prototipagem paralela, bodystorming, role-playing, Mágico de Oz |

---

<!-- referencias/autodiagnostico.md -->

# Autodiagnóstico — Quest #6

Faça este exercício **antes** de entregar. É o mesmo que o mentor vai fazer depois.

---

## Os milestones que abrem aqui

A Q6 alimenta dois dos 13 milestones: **Solução** (o que vocês propõem e por que ela entrega a proposta única de valor) e **MVP/Implementação** (o que existe de fato, funcionando). A aprovação exige nível 4 em todos.

| Nível | Significado |
|---|---|
| **0** | O critério ainda não aparece. |
| **1** | Já aparece, mas sem clareza nem coerência. |
| **2** | Falta clareza **ou** falta coerência com o resto. A resposta ainda está no terreno da insegurança. |
| **3** | Coerente, mas ainda não totalmente claro. Resta uma parcela de incerteza. |
| **4** | Claro e coerente com toda a proposta. A equipe responde com segurança. |
| **5** | Perfeitamente alinhado ao conjunto. As respostas são sólidas. |

O salto que trava a maioria é o **3 → 4**, e na Q6 ele tem um nome preciso: sair de *"mostramos para umas pessoas e elas gostaram"* para *"pedimos um compromisso a doze pessoas, cinco deram, e o preço que sustenta a conta é este"*.

---

## Rubrica — milestone Solução

### 1. Natureza da solução

| | |
|---|---|
| **2** | "É um app". A categoria é a única descrição. |
| **3** | Aplicativo, serviço ou produto físico está definido, mas o que o usuário faz nele ainda é vago. |
| **4** | A equipe descreve o artefato, o que ele faz, para quem, e por que **essa** forma e não outra. |
| **5** | O acima, mais as formas descartadas e o critério de descarte. |

### 2. Estratégia em curva de valor

| | |
|---|---|
| **2** | A curva da Q5 foi copiada sem alteração, ou não há curva. |
| **3** | Há as quatro colunas — eliminar, diminuir, aumentar, criar —, mas todas as funcionalidades caem em "criar". |
| **4** | Cada item de "criar" está justificado, e a equipe sabe dizer quantas semanas ele custa. Há itens reais em "eliminar". |
| **5** | O acima, com a curva do produto comparada à curva dos concorrentes da Q3, no mesmo eixo de fatores de competição. |

### 3. Mínimo necessário

| | |
|---|---|
| **2** | A lista de funcionalidades é a lista de desejos da equipe. |
| **3** | Há corte, mas o critério é esforço de implementação. |
| **4** | Cada elemento está rotulado como *must-have*, *nice-to-have* ou *don't-need*, com base no que foi ouvido; os *nice-to-have* estão em backlog nomeado. |
| **5** | O acima, e a equipe consegue dizer qual **promessa da PUV** cada *must-have* cumpre. |

### 4. Jornada alterada

| | |
|---|---|
| **2** | A jornada nova é descrita como "fica mais fácil". |
| **3** | Há um fluxo de telas, mas não há a jornada anterior para comparar. |
| **4** | Jornada de antes e jornada de depois, passo a passo, com a persona da Q1 percorrendo as duas; fica visível onde a gambiarra desaparece. |
| **5** | O acima, com os passos que **continuam ruins** depois da solução, assumidos. |

---

## Rubrica — milestone MVP/Implementação

### 5. Escolha do formato de MVP

| | |
|---|---|
| **2** | Nenhuma escolha consciente; construiu-se o que a equipe sabia construir. |
| **3** | O formato foi escolhido, mas não está ligado a uma hipótese. |
| **4** | Formato escolhido **a partir da pergunta em aberto**, com a hipótese escrita de forma falseável antes de rodar. |
| **5** | O acima, com o registro de por que os outros quatro formatos responderiam pior. |

### 6. Evidência com usuário

| | |
|---|---|
| **2** | Feedback de colegas de turma e de familiares. |
| **3** | Demonstração para gente do público certo, com registro de opinião. |
| **4** | Entrevistas de solução com roteiro cronometrado, ficha por entrevista preenchida individualmente, e **um pedido de compromisso** feito ao final de cada uma; o número de pedidos e o de aceites está registrado. |
| **5** | O acima, com um segundo lote rodado depois de ajustar a demo, e a variação entre lotes explicada. |

### 7. Preço

| | |
|---|---|
| **2** | Não se falou de preço. |
| **3** | Perguntou-se ao cliente quanto ele pagaria. |
| **4** | O preço foi **dito** ao cliente e a reação foi medida, com registro de quem hesitou; há uma faixa e a âncora usada está nomeada. |
| **5** | O acima, com um preço mais alto testado depois de a primeira faixa não ter gerado resistência. |

### 8. O que funciona

| | |
|---|---|
| **2** | Telas navegáveis sem nada por trás, apresentadas como sistema. |
| **3** | Parte do fluxo funciona; o restante é simulado, e isso não está declarado. |
| **4** | O caminho principal funciona de ponta a ponta, e o que é simulado está **explicitamente declarado** — inclusive o que é operado à mão. |
| **5** | O acima, com defeitos conhecidos listados e a decisão consciente de tolerá-los ou não, à luz do efeito deles sobre a velocidade de aprendizado. |

---

## Checklist rápido

- [ ] Consigo dizer, numa frase, **qual hipótese** o meu MVP testa?
- [ ] O artefato responde "alguém quer isso a ponto de agir?" — ou só "dá para construir?"
- [ ] Para cada funcionalidade que ficou, sei qual aprendizado ela sustenta?
- [ ] Pedi um compromisso ao final das entrevistas, ou só agradeci?
- [ ] Disse o preço em vez de perguntar?
- [ ] Anotei quem hesitou?
- [ ] Existe alguma coisa na demo que a equipe **não** consegue construir na tecnologia final?
- [ ] Alguma entrevista me fez cortar uma funcionalidade — ou todas confirmaram a lista original?
- [ ] Se a resposta ao MVP tivesse sido negativa, o que exatamente eu teria feito?

**Sinal de alerta:** se nenhuma entrevista de solução cortou nada da lista, ou a demo estava vendendo em vez de testando, ou vocês só mostraram para quem já torcia pelo projeto.

**Segundo sinal:** se a equipe descreve o MVP pelo que ele *terá*, e não pelo que ele *já mede*, o artefato ainda é um plano de produto.

---

## Registro de trajetória (modo de IA)

Meia página, entregue junto. Ver `metodo/modo-ia.md` para o racional.

1. **Modo em que a quest foi feita, e onde você saiu dele.**
   *Na Q6, construir é 🟢 coprodução e validar é 🔴 sem assistência. Se a IA participou da leitura dos resultados de campo, diga.*

2. **O que a IA gerou e você descartou — e por quê.**
   *Típico da Q6: a IA propõe um conjunto de funcionalidades "essenciais" a partir da descrição do produto. Essa lista é hipótese, não escopo. Se vocês a cortaram depois das entrevistas, esse é o registro mais valioso da quest.*

3. **O que você verificou, e como.**
   *Típico da Q6: o critério de aceitação do código gerado, e o teste que confirmou que o caminho principal funciona com dado real.*

4. **O que ainda não sabe.**
   *Exemplos honestos: "não testamos com ninguém fora de Recife"; "o trecho X é operado à mão e não sabemos o custo dele em escala".*

> Um MVP validado por IA é um MVP não validado.

---

## Como o mentor vai ler

Quatro perguntas frequentes na apresentação da Q6. Se você responde às quatro, está em 4.

1. **"Quantas pessoas viram isso, e o que elas fizeram depois?"**
   Resposta fraca: "todo mundo achou legal". Resposta forte: número de demos, número de pedidos de compromisso, número de aceites.

2. **"O que é minimamente necessário aqui — e o que vocês tiraram?"**
   A segunda metade da pergunta é a que vale. Sem itens removidos, não houve redução.

3. **"Quanto vocês disseram que ia custar, e o que aconteceu?"**
   Se a equipe perguntou em vez de dizer, o dado é fraco e é preciso admitir isso.

4. **"O que nesta demo não existe de verdade?"**
   Responder com naturalidade é sinal de maturidade; ser pego é o pior desfecho possível da Q6.

Divergência entre a sua auto-avaliação e a leitura do mentor é informação útil, não constrangimento.

---

<!-- referencias/entrevista-de-solucao.md -->

# A entrevista de solução — Quest #6

Abra este arquivo na véspera de entrevistar. Ele traz o roteiro cronometrado, as falas a adaptar, o teste de preço, os critérios para parar e o que fazer com o resultado.

**Modo de IA:** 🔴 **sem assistência** durante a entrevista e na leitura dos resultados. 🟡 com apoio para preparar o roteiro e para criticar o seu formulário antes de ir a campo. A IA pode apontar que uma pergunta sua é indutora; ela não pode dizer se o cliente gostou.

---

## 1. O que esta entrevista testa — e por que ela não é a da Q2

Na entrevista de problema (Q2) você **ouve**. Aqui você **mostra e mede a reação**, porque a maioria dos clientes é ótima em articular problemas e ruim em visualizar soluções.

Os três riscos sob teste, na formulação de Maurya:

| Risco | A pergunta |
|---|---|
| **Risco de cliente** | Quem sente a dor? Como identificar o usuário afoito (*early adopter*)? |
| **Risco de produto** | Como você resolve esses problemas? Qual o conjunto mínimo de funcionalidades para lançar? |
| **Risco de mercado** | Qual o modelo de preço? O cliente paga? Que preço ele suporta? |

O que sai em relação à Q2: o ranqueamento de problemas e a exploração da visão de mundo do cliente. O que entra: a **demo** e o **teste de preço**.

### Com quem falar

Blank descreve uma escala de dor do cliente com cinco pontos, e afirma que o cliente visionário — o que compra cedo e evangeliza — só existe nos pontos 4 e 5:

1. o cliente tem um problema;
2. o cliente **sabe** que tem um problema;
3. o cliente procura ativamente uma solução e tem prazo para achá-la;
4. o problema dói o bastante para que ele já tenha montado uma **solução provisória própria** — a gambiarra;
5. ele tem, ou consegue rápido, orçamento para resolver.

Se você levantou gambiarras na Q1, elas são a sua lista de convidados. Quem está no ponto 1 ou 2 vai ser educado com a sua demo e não vai comprar nada.

---

## 2. O roteiro, com tempos

Total previsto: 26 minutos com a pessoa, mais 5 de documentação.

| Bloco | Tempo | O que testa |
|---|---|---|
| Boas-vindas — montar o palco | 2 min | — |
| Coletar demografia | 2 min | segmento de cliente |
| Contar uma história | 2 min | contexto do problema |
| **Demo** | **15 min** | a solução |
| **Testar preço** | **3 min** | fontes de receita |
| Fechamento — o pedido | 2 min | compromisso e indicações |
| Documentar | 5 min | — |

### Boas-vindas (2 min)

As falas abaixo são a tradução das falas do roteiro de Maurya, adaptadas ao português — a tradução é minha, e o exemplo (compartilhar fotos e vídeos entre pais) é o do livro. Substitua pelo seu domínio, mantendo a estrutura.

> Muito obrigado por reservar este tempo para conversar com a gente.
>
> Estamos trabalhando num serviço de compartilhamento de fotos e vídeos pensado para pais. A ideia surgiu depois que eu virei pai e senti na pele algumas frustrações com o que existe hoje.
>
> A conversa vai funcionar assim: eu começo descrevendo os principais problemas que estamos atacando e pergunto se algum deles faz sentido para você. Depois queria te mostrar uma demonstração inicial da aplicação.
>
> Queria deixar claro que **não temos um produto pronto**, e que nosso objetivo é aprender com você, não vender nem apresentar nada.
>
> Tudo bem assim?

A frase "não temos um produto pronto e não estamos vendendo" não é gentileza: ela é o que autoriza a pessoa a discordar de você nos próximos vinte minutos.

### Coletar demografia (2 min)

Perguntas curtas, sobre os atributos que você acredita que separam o usuário afoito do resto. No exemplo do livro: quantos filhos, que idades, você compartilha fotos on-line, e vídeos, com que frequência, com quem.

Se você já entrevistou essa pessoa na Q2, pule este bloco — a menos que tenham surgido atributos novos desde então.

### Contar uma história (2 min)

Ilustre os três principais problemas com uma história, não com uma lista. O modelo do livro, traduzido:

> Depois que os filhos nasceram, começamos a tirar muito mais fotos que antes, e principalmente mais vídeos. E passamos a receber pedidos regulares — semanais — de atualização, dos avós e de outros parentes. Só que era difícil compartilhar tudo isso com frequência, porque o processo tomava tempo e às vezes era doloroso: organizar os arquivos, redimensionar, ficar de babá do upload. Vídeo era pior ainda, porque muitas vezes tínhamos que converter antes para um formato que a web aceitasse.
>
> Como a maioria dos pais, estamos com sono atrasado e temos menos tempo livre do que antes. Ter filhos nos deu uma noção nova do valor do tempo livre, e a gente preferia usar esse tempo em outra coisa.
>
> Alguma coisa disso faz sentido para você?

### O portão de ressonância

**Se você não sentir uma ressonância forte com o problema, não continue a entrevista de solução.** Use o roteiro de problema da Q2 para aprender como essa pessoa resolve isso hoje, e encerre.

Este é o erro mais caro do bloco: seguir para a demo por educação, com alguém que não tem o problema. O que você vai colher são elogios — e elogio de quem não tem o problema é ruído que vai contaminar a decisão de escopo da Q8.

### Demo (15 min)

É o coração da entrevista. Percorra **um problema de cada vez**, mostrando como você o resolve com o apoio da demo. Pause depois de cada um e pergunte se há dúvidas. Depois de passar por todos:

> Então é assim que a aplicação está hoje. Estamos tentando priorizar o que terminar e lançar primeiro, e queria te fazer mais algumas perguntas:
>
> - Que parte da demonstração fez mais sentido para você?
> - De qual delas você conseguiria viver sem?
> - Está faltando alguma coisa que você acha importante?

A segunda pergunta é a mais produtiva das três e a mais fácil de esquecer. Ela é o que produz a etiqueta *don't-need* na seção 6.

### As cinco diretrizes da demo

| Diretriz | O que significa, e o modo de falha |
|---|---|
| **Realizável** | Demo construída numa tecnologia que você não vai usar vende bem e cria elementos impossíveis de recriar. O resultado é o descolamento entre o que foi prometido (e vendido) e o que é entregue. |
| **Parecer real** | Wireframe cru é rápido de montar, mas exige do cliente um salto de fé sobre o produto final. **Quanto mais real a demo parece, mais precisamente você testa a solução.** |
| **Rápida de iterar** | Você vai receber feedback de usabilidade e precisa incorporá-lo antes da entrevista seguinte. Terceirizar a demo prejudica exatamente isso: sua velocidade passa a depender da agenda de outro. |
| **Minimizar desperdício** | Comece em papel, e converta para a tecnologia final em algum ponto — o que for feito fora dela vira retrabalho. |
| **Dados realistas** | Nada de *lorem ipsum*. Dados verossímeis não só posicionam a tela como sustentam a narrativa. "Design sem conteúdo não é design, é decoração" (Jeffrey Zeldman, citado por Maurya). |

No Projetão, a diretriz que mais se descumpre é a quinta, e ela é a mais barata de cumprir. Trocar "Usuário 1, Usuário 2" por três nomes plausíveis com três históricos plausíveis muda a qualidade do feedback.

---

## 3. O teste de preço (3 min)

Duas orientações que contrariam o instinto, e o motivo de cada uma.

### Diga o preço; não pergunte

> Você consegue imaginar Steve Jobs perguntando quanto você teria pagado por um iPad antes do lançamento? (Maurya, tradução minha)

O argumento é econômico, não retórico: **não há justificativa razoável para um cliente oferecer outra coisa que não um valor baixo.** Além disso, o cliente muitas vezes honestamente não sabe quanto pagaria, e a pergunta só o deixa desconfortável.

A formulação do roteiro:

> Vamos falar de preço. Vamos lançar o serviço num modelo de assinatura. Você pagaria R$ X por ano por compartilhamento ilimitado de fotos e vídeos?

E o registro que importa: se ele aceitar, **anote se hesitou ou se aceitou de imediato**. Aceitar rápido demais é sinal de que o preço está baixo.

> Em geral, o preço certo é o que o cliente aceita, mas **com um pouco de resistência**.

### Não reduza a fricção de cadastro — aumente

O instinto é facilitar o "sim", esperando que o valor entregue ao longo do tempo justifique a relação. Isso **atrasa a validação**, porque é fácil demais dizer sim, e **compromisso fraco prejudica o aprendizado**.

Maurya relata um diálogo real de entrevista, aqui resumido e traduzido: o cliente sugeriu de 15 a 20 dólares por mês; o entrevistador respondeu que o plano era começar em 100 dólares por mês, explicou que estavam procurando **10 clientes** que claramente tivessem aquele problema, prometeu trabalhar de perto com eles por 30 a 60 dias ou devolver o dinheiro, e ancorou: "você mencionou que gasta várias horas de desenvolvedor por mês num sistema caseiro e ainda não está satisfeito; 100 dólares por mês é menos de duas horas de desenvolvedor". O cliente aceitou pagar cinco vezes o valor que ele mesmo tinha proposto.

Quatro princípios operavam ali:

| Princípio | O que faz |
|---|---|
| **Posição de prêmio** (*prizing*) | Em vez de se apresentar como quem entretém a corte, posicione-se como o prêmio. A referência é Oren Klaff, *Pitch Anything*. |
| **Escassez** | "10 clientes" não era manobra: o primeiro objetivo do MVP é aprender, e 10 clientes plenamente envolvidos valem mais que 100 em cima do muro. |
| **Ancoragem** | Preço é relativo. Ancorar contra as alternativas existentes parece óbvio para você, mas **o cliente não faz essa referência sozinho** — você tem de fazê-la. |
| **Confiança** | Não cobrar por achar o MVP "mínimo demais" inverte a lógica: você reduziu escopo com esforço justamente para construir o produto mais simples que resolve um problema real. |

### A sequência: primeiro o que ele diz, depois o que ele faz

O bloco de preço mede **compromisso verbal**. Ele é o começo, não o fim. O fechamento (a seguir) é a tentativa de converter esse verbal em algo que custe alguma coisa: pré-reserva, sinal, lista de espera com dado real. A escada de compromisso é: verbal → escrito → pré-pagamento, e você deve pedir o degrau mais alto que faça sentido para o seu produto.

---

## 4. Fechamento — o pedido (2 min)

Duas perguntas, e as duas são pedidos:

> Muito obrigado pelo tempo de hoje, você ajudou bastante.
>
> Como falei no começo, isso ainda não é um produto pronto, mas estamos perto de lançar alguma coisa. Você teria interesse em experimentar o produto quando tivermos algo?
>
> E estamos procurando entrevistar mais gente como você. Você conhece outros pais de crianças pequenas que a gente poderia entrevistar?

A segunda pergunta é o seu motor de recrutamento para as entrevistas seguintes. Uma equipe que não pede indicação passa a semana seguinte procurando participantes em vez de aprendendo.

---

## 5. Documentar (5 min) e o formulário

Use os cinco minutos **imediatamente após** a entrevista, com a conversa fresca. Cada entrevistador preenche o formulário **de forma independente primeiro**; só depois vem a reunião de comparação de notas e o registro final.

Formulário, adaptado do modelo do livro:

```
Data: ____/____/____

Contato
  Nome: ____________________   E-mail: ____________________

Demografia
  [atributo 1]: ______   [atributo 2]: ______   [atributo 3]: ______

Solução 1 — [nome da funcionalidade]
  Ordem de prioridade: ____   Nível de dor: ____
  Comentários: _______________________________________________

Solução 2 — [nome da funcionalidade]
  Ordem de prioridade: ____   Nível de dor: ____
  Comentários: _______________________________________________

Solução 3 — [nome da funcionalidade]
  Ordem de prioridade: ____   Nível de dor: ____
  Comentários: _______________________________________________

Preço
  Disposto a pagar (R$ __ / mês ou ano): ______
  Hesitou?  ( ) sim  ( ) não
  Notas: _____________________________________________________

Indicações: __________________________________________________
```

Duas colunas fazem a diferença na hora de decidir escopo: **ordem de prioridade** e **nível de dor**. Uma funcionalidade que todo mundo prioriza alto mas ninguém pontua dor alta é candidata a *nice-to-have*.

---

## 6. Quando parar, e o que fazer com o resultado

### Revisão

Revise os resultados **semanalmente**, e só mude o roteiro depois de uma semana inteira de entrevistas — não depois de cada conversa. Nessa revisão:

- **Adicione ou mate funcionalidades.** Se vieram pedidos específicos, discuta se há razão convincente para incorporar. Remova o desnecessário.
- **Confirme as hipóteses anteriores.** Se a Q2 terminou com sinais positivos fortes, aqui não deve haver surpresa. Se houver, volte às hipóteses antigas.
- **Refine o preço.** Se não houve nenhuma resistência ao preço, **teste um preço mais alto**. Leve em conta as alternativas existentes: se a solução atual da pessoa é gratuita, como você entrega valor suficiente para justificar o pagamento?
- **Procure padrão.** Quem é o usuário afoito prototípico, e que preço ele suporta? Dá para montar um negócio viável nesse preço?

### Critérios de saída

Você terminou quando tem confiança de que:

1. consegue identificar a demografia de um usuário afoito;
2. tem um problema *must-have*;
3. consegue definir as funcionalidades mínimas para resolver esse problema;
4. tem um preço que o cliente aceita pagar;
5. consegue montar um negócio em cima disso, numa conta de padeiro.

Cinco critérios, e nenhum deles é "entrevistamos dez pessoas". Quantidade é meio.

### Reduzir para o Release 1.0

O perigo depois das entrevistas é iterar mockups e terminar com mais do que o MVP precisa. A ordem, segundo Maurya:

1. **Zere a lista.** Nenhuma funcionalidade entra por padrão; cada uma precisa justificar a entrada.
2. **Comece pelo problema nº 1.** O trabalho da PUV é fazer uma promessa convincente; o trabalho do MVP é **cumpri-la**. A essência do MVP está no mockup do problema nº 1.
3. **Rotule cada elemento** como *must-have*, *nice-to-have* ou *don't-need*. Elimine os *don't-need* imediatamente; mande os *nice-to-have* para o backlog — a menos que sejam pré-requisito de um *must-have*.
4. **Repita** para os problemas 2 e 3.
5. **Considere os pedidos de funcionalidade dos clientes** (integrações, por exemplo) e decida entrar ou adiar pelo nível de "preciso ter".
6. **Cobre desde o dia 1, mas colete no dia 30.** Período de teste é padrão hoje, e adiar a coleta de cartão reduz fricção de cadastro; os dois fatos trabalham a seu favor para reduzir escopo — você não precisa de conta de recebimento nem de múltiplos planos para lançar.
7. **Foque em aprendizado, não em otimização.** Não gaste esforço otimizando servidor, código ou banco. A chance de você ter problema de escala no lançamento é baixa; e se tiver, é um bom problema.

> Seu MVP deve ser como um bom molho reduzido: concentrado, intenso e saboroso.

---

## Fontes

- **Maurya, Ash**, *Running Lean*, cap. 8 (The Solution Interview) e cap. 9 (Get to Release 1.0) — os três riscos; o roteiro cronometrado e as falas; o portão de ressonância; as cinco diretrizes da demo; dizer o preço em vez de perguntar; aumentar a fricção; os quatro princípios do diálogo de preço; o enquadramento AIDA; o formulário; os critérios de saída; os sete passos de redução para o Release 1.0
- **Blank, Steve**, *The Four Steps to the Epiphany* — a escala de dor do cliente em cinco pontos e a tese de que o cliente visionário está nos pontos 4 e 5
- **Zeldman, Jeffrey** (*A List Apart*), citado por Maurya — design sem conteúdo é decoração
- **Klaff, Oren**, *Pitch Anything*, citado por Maurya — a técnica de enquadramento por posição de prêmio

---

<!-- referencias/pivotar.md -->

# Pivotar — Quest #6

Abra este arquivo quando os resultados do MVP não confirmarem o que vocês esperavam, quando as melhorias no produto pararem de mudar os números, ou quando alguém da equipe disser "acho que a gente errou o alvo". Ele traz o catálogo dos dez pivôs, como conduzir a decisão e o que um pivô obriga você a fazer depois.

**Modo de IA:** 🟡 com apoio. A IA é útil para mapear o seu caso contra o catálogo e para fazer as perguntas incômodas da reunião. Ela **não** decide, porque decidir aqui depende de dados de campo que só a equipe tem, e porque a IA tende a validar a alternativa que você já preferia.

---

## 1. O que é um pivô — e o que não é

> Um pivô é um tipo específico de mudança, projetado para testar uma nova hipótese fundamental a respeito do produto, do modelo de negócios e do motor de crescimento.

Três negações que vêm da definição:

**Pivô não é sinônimo de mudança.** Trocar a paleta de cores, mudar o nome, reescrever a tela inicial: nada disso é pivô. A palavra é usada incorretamente como sinônimo de mudança com frequência.

**Pivô não é desistir.** Empreendedores de sucesso "não desistem ao primeiro sinal de dificuldade, nem perseveram até o desastre final; possuem uma combinação única de perseverança e flexibilidade".

**Pivô não é exortação.** Boa parte da literatura de gestão pede que empresas se reinventem, sem dizer como. O pivô é uma categoria fechada de movimentos, cada um com uma hipótese associada.

---

## 2. Os dez pivôs, com o sinal de que é o seu caso

A coluna "sinal" traduz cada pivô em algo observável nos dados e nas entrevistas de vocês. A descrição vem de Ries; a leitura do sinal no contexto do Projetão é interpretação minha, marcada aqui como tal.

| Pivô | O que muda | Sinal de que é o seu caso |
|---|---|---|
| **Zoom-in** | O que era um recurso isolado vira o produto inteiro | Nas entrevistas, todo mundo comenta a mesma tela e ignora o resto; uma funcionalidade concentra o uso |
| **Zoom-out** | O que era o produto inteiro vira um recurso de algo maior | O cliente entende o valor, mas diz que não abriria "mais um app" só para isso; o valor só aparece dentro de um fluxo que já existe |
| **Segmento de cliente** | O problema é real e a solução resolve — para **outro** público | A demo ressoa forte com um perfil que não era o seu alvo, e fraco com o alvo declarado |
| **Necessidade do cliente** | O público está certo; o problema atacado não é o que importa para ele | Você conhece bem o cliente e percebe que o problema nº 1 dele é outro, vizinho ao seu, e que sua equipe conseguiria resolver |
| **Plataforma** | De aplicativo para plataforma, ou o contrário | Terceiros começam a pedir para construir em cima do que você fez; ou, ao contrário, ninguém constrói nada e falta o aplicativo matador |
| **Arquitetura de negócio** | Entre margem alta/volume baixo e margem baixa/volume alto | O ciclo de venda ficou longo e caro num produto pensado para massa; ou o contrário, o produto de massa só fecha com venda consultiva |
| **Captura de valor** | Como o valor gerado é monetizado | O uso cresce e a receita não acompanha; ou o preço é o único ponto em que as entrevistas travam |
| **Motor de crescimento** | Entre viral, pegajoso e pago | A aquisição empata com o abandono; o coeficiente viral não passa de 1; o custo de aquisição sobe acima do valor do cliente |
| **Canal** | A mesma solução chega ao cliente por outro caminho | O cliente quer o produto e não consegue comprá-lo pelo caminho que você desenhou; requisitos do canal estão ditando preço e recursos |
| **Tecnologia** | Mesmo resultado, tecnologia diferente | Segmento, problema, captura de valor e canal permanecem os mesmos; só muda preço ou desempenho da entrega |

Sobre o pivô de **captura de valor**, vale registrar a advertência do próprio autor: chamar isso de "modelo de monetização" é limitado demais, porque sugere que a monetização é uma característica independente do produto, que pode ser adicionada ou removida à vontade. **A captura de valor é parte intrínseca da hipótese de produto** — mudá-la costuma ter consequências de longo alcance sobre produto e marketing.

Sobre o pivô de **tecnologia**: ele é muito mais comum em empresas estabelecidas, porque é uma inovação de sustentação — nada de relevante muda além da tecnologia. Num projeto de Projetão, "vamos trocar de framework" quase nunca é um pivô; é uma decisão de implementação.

Dois exemplos documentados, para citar:

- **Zoom-in:** a Votizen abandonou uma rede social completa e se aproximou de um produto simples de contato com o eleitor.
- **Necessidade do cliente:** a Potbelly Sandwich Shop começou em 1977 como um antiquário; os donos passaram a vender sanduíches para aumentar o movimento da loja, e em pouco tempo tinham pivotado para uma linha de negócio inteiramente diferente. Hoje a rede tem mais de duzentas lojas.

---

## 3. Como decidir: a reunião de pivotar ou perseverar

A decisão é difícil em termos emocionais e por isso precisa ser **estruturada e agendada com antecedência** — não tomada no calor de uma frustração.

| Item | A recomendação |
|---|---|
| **Cadência** | Uma reunião regular. Menos de algumas semanas entre elas é frequente demais; mais de alguns meses é infrequente demais. Cada equipe encontra o próprio ritmo. |
| **Quem participa** | Desenvolvimento de produto **e** liderança comercial, juntos. Na IMVU, somaram-se conselheiros externos, que ajudavam a enxergar além das ideias preconcebidas e a interpretar os dados de outras maneiras. |
| **O que produto leva** | Relatório completo dos resultados das iniciativas de otimização **ao longo do tempo** — não só do último período —, comparados com as expectativas, também ao longo do tempo. |
| **O que a ponta comercial leva** | Relatos detalhados das conversas com clientes atuais e potenciais. |

**Adaptação para o Projetão** (interpretação minha): cadência quinzenal, alinhada com o ritmo das quests; "liderança comercial" é quem foi a campo; "conselheiro externo" é o professor, o monitor ou uma equipe vizinha — alguém que não esteja apaixonado pelo seu produto. A reunião precisa de ata, porque o argumento que sustentou a decisão é material de apresentação na banca.

### Os sintomas que disparam a reunião extraordinária

Dois sinais reveladores, na formulação de Ries: **a eficácia decrescente dos experimentos com o produto** e **a sensação generalizada de que o desenvolvimento do produto deveria ser mais produtivo**. Quando os dois aparecem juntos, considere pivotar.

---

## 4. Por que quase todo mundo pivota tarde demais

Converse com quem pivotou e ouvirá que gostariam de ter decidido antes. Três razões:

**1. Métricas de vaidade.** Elas permitem chegar a conclusões falsas e viver uma realidade alternativa. O dano específico é que **furtam da equipe a crença de que é necessário mudar**. Quando as pessoas são forçadas a mudar contra o próprio julgamento, o processo demora mais e produz resultado menos decisivo.

**2. Hipótese confusa.** Com hipótese vaga, é quase impossível vivenciar um fracasso completo — e sem fracasso não há ímpeto para a mudança radical que o pivô exige. A crítica é direta: quem "lança e vê o que acontece" sempre terá êxito... em ver o que acontece. Os resultados iniciais serão ambíguos e você não saberá se pivota ou persevera.

**3. Medo.** O maior medo do empreendedor não é que a visão se mostre errada; é que ela **seja considerada errada sem ter tido uma chance real de ser provada**. Esse medo produz resistência ao MVP e ao teste comparativo, e ironicamente eleva o risco: o teste só acontece quando a visão está inteira representada — e, a essa altura, costuma ser tarde para pivotar, porque o recurso acabou.

O caso da Path é o contraexemplo útil: fundadores conhecidos lançaram um MVP que atraiu atenção da imprensa de tecnologia, o produto não era voltado a esse público e a reação inicial dos blogueiros foi bastante negativa. A equipe optou por ignorar o medo e olhar para o que os clientes diziam — que era diferente do que a mídia dizia. Nas palavras de Dave Morin: "Testamos humildemente as teorias e a abordagem para ver o que o mercado achava. Escutamos o feedback honestamente".

---

## 5. Fracasso em pivotar — o caso que o próprio autor conta contra si

Anos após a fundação, a IMVU estava bem: receita acima de 1 milhão de dólares por mês, mais de 20 milhões de avatares criados, capital de risco levantado. E, por isso mesmo, deixou de perceber que precisava de um **pivô de segmento de cliente**.

O que aconteceu, na descrição de Ries:

- a empresa **passou a confiar em métricas de vaidade** — recordes de cadastro, de clientes pagantes, de usuários ativos — e parou de usar os milestones de aprendizagem;
- passaram **meses** tentando melhorar a taxa de ativação, com dezenas de experimentos medidos por teste A/B: melhorias de usabilidade, técnicas de persuasão, programas de incentivo, jogos. Individualmente, muitos foram bem-sucedidos;
- em conjunto, ao longo de muitos meses, os indicadores gerais do motor de crescimento mudaram de forma insignificante. **A taxa de ativação subiu apenas alguns pontos percentuais**;
- o mercado de usuários afoitos estava se esgotando; a equipe de marketing passou a alcançar clientes convencionais, menos tolerantes com um produto inicial; ativação e monetização caíram e o custo de aquisição subiu.

A lição operacional: **retornos decrescentes num programa de otimização bem executado são o sinal clássico da necessidade de pivotar.** Não é o experimento que falha; é o conjunto deles que para de mover o indicador macro.

---

## 6. A pista de decolagem se mede em pivôs, não em meses

A conta usual de sobrevivência é dinheiro em caixa dividido pela queima mensal. A reformulação:

> A verdadeira medida da pista de decolagem é **quantos pivôs uma startup ainda tem**: a quantidade de oportunidades que possui para realizar uma mudança fundamental em sua estratégia empresarial.

A consequência prática é que existem duas formas de esticar a pista: cortar gastos, ou **chegar a cada pivô mais rápido**. E há uma armadilha na primeira: cortar de forma indiscriminada pode cortar justamente o que permite atravessar o ciclo construir-medir-aprender — e então tudo o que se conseguiu foi falir mais devagar.

**Tradução para o semestre** (interpretação minha): a sua pista é medida em quantas semanas restam até a Q13, e a sua taxa de queima é a agenda da equipe. Um pivô na Q6 é barato; o mesmo pivô na Q10 custa o produto inteiro. A decisão de pivotar cedo é a decisão de gastar pouco.

---

## 7. Um pivô é uma hipótese estratégica — e exige um MVP novo

Esta é a parte que mais se perde nas apresentações:

> Um pivô é mais bem entendido como uma **nova hipótese estratégica, que exigirá um novo produto mínimo viável para testar**.

Ou seja: pivotar não é o fim do trabalho da Q6, é o reinício dele. Depois de escolher o pivô, a equipe volta a escrever a hipótese, escolhe o formato de MVP (ver `tipos-de-mvp.md`) e vai medir de novo. Uma equipe que pivota e segue direto para a implementação apenas trocou uma aposta não testada por outra.

E o cuidado com analogias: os pivôs que empresas conhecidas executaram costumam ser menos conhecidos que a estratégia final. **"As empresas possuem um forte estímulo para alinhar suas histórias de relações públicas em torno do fundador heroico, e aparentar que seu sucesso foi o resultado inevitável de uma boa ideia."** Quando você diz "vamos fazer como a empresa X", pergunte: estamos reproduzindo as características essenciais ou só as superficiais? O que funcionou naquele setor funciona no nosso? O que funcionou no passado funciona hoje?

---

## 8. Como um pivô aparece na entrega da Q6

Um pivô bem conduzido não enfraquece a apresentação — ele é evidência de que a equipe está medindo. O que precisa estar na entrega:

| Elemento | O que mostrar |
|---|---|
| A hipótese anterior | O que vocês tinham afirmado, com número |
| O dado que a derrubou | Quantas pessoas, o que fizeram, o que não fizeram |
| O tipo de pivô | O nome do catálogo, não "mudamos de ideia" |
| A nova hipótese | Escrita de forma falseável |
| O novo MVP | Qual formato, o que ele mede, quando roda |

O que **não** deve aparecer: pivô justificado por preferência da equipe, por dificuldade técnica ou por cansaço. Esses são motivos reais para mudar de escopo, mas não são pivôs, e a banca vai perguntar qual foi o dado.

---

## Fontes

- **Ries, Eric**, *A startup enxuta* (ed. brasileira), cap. 8 — a definição de pivô; o catálogo dos dez tipos com os exemplos Votizen e Potbelly; os três motivos para pivotar tarde; o caso Path; a reunião de pivotar ou perseverar (cadência, participantes e o que cada lado leva); o fracasso em pivotar na IMVU; a pista de decolagem medida em pivôs; o pivô como nova hipótese estratégica e a crítica à narrativa do fundador heroico
- **Ries, Eric**, *A startup enxuta*, cap. 6 — o compromisso antecipado com a iteração: qualquer que seja o resultado do MVP, não se abandona o projeto no primeiro teste

---

<!-- referencias/tipos-de-mvp.md -->

# Os cinco tipos de MVP — Quest #6

Abra este arquivo no momento em que a equipe já sabe **qual hipótese precisa testar** e está decidindo em que formato testar. Se você ainda não sabe qual é a hipótese, o arquivo errado está aberto: volte ao `SKILL.md` da quest.

---

## 1. A escolha é da pergunta, não do formato

Os MVPs "variam em complexidade, desde testes muito simples (pouco mais do que um anúncio) até protótipos iniciais reais, incluindo problemas e recursos ausentes" (Ries, tradução da edição brasileira). Não há fórmula para decidir a complexidade — é julgamento. E há um viés conhecido: **"a maioria dos empreendedores e do pessoal de desenvolvimento de produtos superestima muito quantas funcionalidades são necessárias em um MVP. Em caso de dúvida, simplifique."**

Comece pela pergunta:

| Se a pergunta em aberto é… | O formato é |
|---|---|
| As pessoas agem diante da promessa, antes de existir produto? | Smoke test |
| A proposta é entendida e desejada, mas o produto é impossível de prototipar? | Vídeo |
| O que o produto precisa ter, e como o cliente realmente usa? | Concierge |
| Se resolvermos o problema técnico difícil, as pessoas usam? | Mágico de Oz |
| O problema vale a pena? O canal funciona? Quantos se inscrevem? | Landing page |

Uma equipe que escolhe pelo que é mais divertido de construir tende a escolher o Mágico de Oz — e a descobrir tarde demais que a pergunta dela era de canal, e que uma landing page teria respondido em um dia.

---

## 2. Smoke test — o anúncio que já transaciona

**A pergunta:** as pessoas demonstram intenção de agir — clicar, cadastrar, pagar — diante da promessa, antes de haver produto?

> ⚠️ **Correção de termo.** O termo *smoke test* não aparece em nenhuma das obras do acervo da disciplina. O que existe em Ries é a descrição da faixa inferior de complexidade: testes "pouco mais do que um anúncio". Use o termo se ele circula na sua turma, mas **não o atribua a Ries** num trabalho acadêmico. Cite a descrição, não o rótulo.

**O caso documentado mais próximo é o Groupon.** A empresa nasceu como The Point, uma "plataforma de ativismo coletivo" para reunir pessoas em torno de causas e boicotes. Os primeiros resultados foram decepcionantes e, no fim de 2008, os fundadores decidiram tentar outra coisa mantendo o novo produto simples. Andrew Mason descreve o que construíram:

- um blog em WordPress, com um post novo por dia;
- a primeira oferta foram camisetas, com a descrição: "Essa camiseta será entregue na cor vermelha, no tamanho grande. Se você quiser uma cor ou tamanho diferente, mande um e-mail para nós" — não havia sequer formulário para escolher;
- os cupons eram gerados em FileMaker e enviados em PDF por e-mail;
- quando venderam quinhentos cupons de sushi num dia, dispararam quinhentos PDFs pelo Apple Mail.

A primeira oferta que funcionou foi um grupo de vinte pessoas comprando duas pizzas pelo preço de uma, numa pizzaria no primeiro andar do prédio do escritório.

**Quando NÃO usar:** quando a promessa é difícil de entender só por texto (aí é vídeo), ou quando a dúvida é sobre uso continuado e não sobre intenção inicial. Um smoke test mede o "sim" de quem ainda não usou nada.

**Custo/esforço típico:** horas a poucos dias. É o formato mais barato dos cinco e o que menos exige da equipe técnica.

---

## 3. Vídeo — quando o produto não pode ser prototipado

**A pergunta:** a proposta é entendida e desejada, num caso em que demonstrar o software funcionando é impossível?

**O caso é o Dropbox.** A equipe fundadora era de engenheiros; o produto exigia integração em nível profundo com Windows, Macintosh, iPhone e Android, além de um serviço on-line de alta confiabilidade. Em reuniões sucessivas, investidores diziam que o espaço estava abarrotado e que o problema não era importante — e não conseguiam imaginar o mundo que Drew Houston descrevia. Houston respondia com duas perguntas: "Você experimentou pessoalmente os outros produtos?" e, diante do sim, "Funcionaram com perfeição?". A resposta quase sempre era não.

O que ele fez, em vez de esperar anos de desenvolvimento: um vídeo de **três minutos**, narrado por ele mesmo, mostrando a tela do próprio computador enquanto descrevia os arquivos que gostaria de sincronizar. Os arquivos que aparecem na tela estão cheios de piadas internas da comunidade de usuários afoitos (*early adopters*) de tecnologia — o vídeo foi feito **para um público específico**, não para o público geral. Resultado nas palavras de Houston: "Nossa lista de espera beta passou de 5 mil para 75 mil pessoas literalmente da noite para o dia".

Maurya acrescenta dois dados sobre o mesmo caso: o vídeo, publicado no Hacker News junto de uma página de captura, ajudou Houston a atrair dezenas de milhares de usuários afoitos, a encontrar um sócio e a entrar na Y Combinator. Na época, Houston estimava lançar em menos de três meses; o lançamento público levou 18 meses.

**A leitura correta do caso:** o vídeo *era* o produto mínimo viável. Ele validou a suposição do tipo salto de fé não porque as pessoas disseram que gostaram num grupo de foco, mas porque **se registraram**.

**Quando NÃO usar:** quando o produto é fácil de simular com telas. Vídeo custa mais que uma demo em papel e responde menos sobre usabilidade.

**Custo/esforço típico:** dias. Num semestre de Projetão, um vídeo bem roteirizado de dois a três minutos é viável e cabe na Q6 sem comprometer a Q8.

---

## 4. Concierge — entregar à mão, um cliente por vez

**A pergunta:** o que o produto precisa ter de fato, descoberto entregando o valor manualmente?

**O caso é a Food on the Table.** Hoje o serviço monta planos de refeições e listas de compras a partir do que a família gosta e do que está em promoção nos supermercados locais — o que exige base de dados de quase todos os supermercados do país, receitas criadas por chefs e um algoritmo de compatibilização.

A empresa começou com **um único cliente**. Os fundadores não escolheram a loja que suportariam até terem o primeiro cliente; não tinham nenhuma receita até esse cliente estar pronto para planejar as refeições. Atenderam o primeiro cliente **sem software, sem parceria comercial e sem contratar chef**.

Manuel Rosso e Steve Sanderson visitavam supermercados e grupos de mães em Austin. Entrevistavam como um bom pesquisador de mercado entrevistaria — mas, ao fim de cada entrevista, **tentavam vender**: descreviam os benefícios, mencionavam uma taxa de assinatura semanal e convidavam a pessoa a se registrar. Em geral foram rejeitados. Alguém contratou.

Esse cliente recebia a visita pessoal do CEO toda semana. Os dois analisavam o que estava em promoção no supermercado preferido dele, escolhiam receitas conforme suas preferências, entregavam em mãos um pacote com lista de compras e receitas, pediam feedback e ajustavam. **E recebiam um cheque de 9,95 dólares por semana.**

Só quando os fundadores ficaram ocupados demais para conseguir novos clientes é que começaram a automatizar — e por partes: primeiro o envio por e-mail no lugar da visita, depois a análise das promoções por software, por fim o pagamento on-line no lugar do cheque escrito à mão.

**A advertência que o caso carrega, e que derruba projeto de aluno:**

> Num MVP com concierge, esse serviço personalizado **não é o produto**, mas uma atividade de aprendizagem elaborada para testar as suposições do tipo salto de fé no modelo de crescimento.

É explicitamente diferente da pequena empresa em que o dono atende cada cliente pessoalmente. E há um resultado esperado que quase ninguém antecipa: **"um resultado comum de um MVP com concierge é invalidar o modelo de crescimento proposto da empresa"** — o que pode acontecer *mesmo que o concierge seja lucrativo*. Sem modelo de crescimento formal, a equipe fica satisfeita com um negócio pequeno e lucrativo quando um pivô levaria mais longe.

**Quando NÃO usar:** quando o valor do produto depende de escala desde o início (uma plataforma cujo lado A só tem valor se o lado B for grande). Aí o concierge testa a entrega, mas não testa o efeito de rede.

**Custo/esforço típico:** semanas de trabalho humano intenso, com pouquíssimo código. É o formato mais caro em horas de pessoa e o mais barato em horas de programação — o que costuma ser exatamente o inverso do que uma equipe do CIn prefere fazer.

---

## 5. Mágico de Oz — pessoas atrás da cortina

**A pergunta:** se resolvermos o problema técnico difícil, as pessoas usam? O uso leva a um produto com valor real?

**O caso é o Aardvark**, de Max Ventilla e Damon Horowitz: um serviço de busca para perguntas subjetivas ("qual é um bom lugar para beber um drinque depois do jogo na minha cidade?"), que roteia a pergunta pela rede social do usuário até alguém capaz de responder.

Com o repertório técnico dos dois, seria razoável esperar que começassem a programar. Levaram **seis meses** decidindo o que construir — e não em quadro branco. Nas palavras de Ventilla: "lançamos protótipos muito baratos para teste. O que se tornou o Aardvark foi o sexto protótipo. Cada protótipo representou um esforço de duas a quatro semanas. Utilizamos pessoas para replicar o *back-end* o máximo possível. Convidávamos de cem a duzentos amigos para testar os protótipos e medíamos quantos deles voltavam. Os resultados foram inequivocamente negativos até o Aardvark".

Depois de escolhido o conceito, mantiveram o processamento humano por **nove meses**, com **oito pessoas contratadas** para gerenciar perguntas e classificar conversas. Toda vez que apareceu um problema técnico difícil — como decidir quem, na rede, é a melhor pessoa para responder —, eles se recusaram a resolvê-lo naquele estágio e simularam com o teste Mágico de Oz. O Aardvark foi adquirido pelo Google por divulgados 50 milhões de dólares.

**A origem do método**, útil para citar num trabalho: o "Paradigma OZ" foi cunhado por **John F. "Jeff" Kelly**, do IBM Thomas J. Watson Research Center, em 1980, na sua tese em Johns Hopkins; publicado como *"An Iterative Design Methodology for User-Friendly Natural Language Office Information Applications"*, ACM ToOIS 2(1), 1984, pp. 26–41. O nome atual remete ao filme de 1939, em que um homem comum se esconde atrás de uma cortina.

**A montagem, segundo Hanington & Martin:** o participante fica num local e o pesquisador-mago em outro; o mago precisa observar a atividade do participante (por vídeo ou compartilhamento de tela) para produzir uma resposta oportuna. Ele pode assumir três papéis: **controlador** (simula a inteligência do sistema), **supervisor** (corrige rumo e sobrepõe decisões do sistema ou do participante) e **moderador** (simula dados sensoriais e completa a experiência).

**Quando NÃO usar:** quando o gargalo do seu projeto não é técnico. Se você já sabe que dá para construir e a dúvida é se alguém quer, o Mágico de Oz é caro demais para a resposta que entrega.

**Custo/esforço típico:** semanas, com pessoas de plantão durante cada sessão. Exige combinar escala de quem "é o mago" — num semestre, isso significa alguém da equipe indisponível durante as janelas de teste.

---

## 6. Landing page — a página que mede o problema e o canal

**A pergunta:** o problema vale a pena ser resolvido? Quantas pessoas se inscrevem? O canal funciona?

**O caso é o próprio livro de Maurya.** Depois que uma dúzia de leitores do blog pediu que ele transformasse os posts num livro, ele ligou para esses leitores para entender qual seria a proposta única de valor do livro em relação às alternativas existentes. Com isso, **gastou um dia** construindo uma página com sumário, título e uma imagem de capa de banco de imagens.

O raciocínio de escopo é o ponto: ele sabia que a parte mais arriscada era **acertar o sumário** — não o título, não a capa, não o preço (livros de negócios têm preço estabelecido). A página testava o item mais arriscado.

Ele ligou de novo para os mesmos leitores perguntando: "se eu escrevesse este livro, você compraria?". O feedback refinou o sumário. Como escrever para uma dúzia de leitores não indicava um problema que valesse a pena, ele deixou a página no ar e anunciou o livro no blog, em março de 2010, com previsão "neste verão"; os leitores espalharam a mensagem — **isso foi o teste de canal**. Em junho, tinha **1.000 e-mails** coletados, o que, por uma conta de padeiro, cobria os custos. Só então começou a escrever.

**Quando NÃO usar:** quando você não tem como levar tráfego qualificado à página. Landing page sem canal mede zero, e o resultado nulo será interpretado erradamente como "ninguém quer".

**Custo/esforço típico:** um dia de trabalho, mais o tempo de campanha. É o formato com melhor relação entre aprendizado e esforço para uma equipe do Projetão — e o mais fácil de fraudar sem perceber, se o único tráfego vier do grupo de WhatsApp da turma.

---

## 7. Comparação, para decidir em cinco minutos

| Tipo | Responde | **Não** responde | Custo em código | Custo em horas de pessoa |
|---|---|---|---|---|
| Smoke test | intenção de agir | uso repetido, usabilidade | quase zero | baixo |
| Vídeo | compreensão e desejo | usabilidade, retenção | zero | médio (roteiro e edição) |
| Concierge | o que o produto precisa ter | efeito de rede, escala | quase zero | alto e contínuo |
| Mágico de Oz | valor da solução técnica | viabilidade técnica real, custo em escala | baixo | alto durante as sessões |
| Landing page | o problema vale a pena; o canal funciona | se o produto entrega o prometido | baixo | baixo, se houver canal |

Nenhum dos cinco responde à pergunta "dá para construir?". Essa é pergunta de protótipo técnico, e é legítima — só não confunda uma com a outra na apresentação.

---

## 8. As duas regras que valem para qualquer formato

**Elimine todo recurso, processo ou esforço que não contribui diretamente com a aprendizagem que você procura.** Essa é a regra de corte do MVP, e ela é operacional: para cada item da sua lista, escreva qual hipótese ele testa. Se não houver hipótese, o item sai.

**Um protótipo bem-sucedido não é o que funciona sem falhas; é o que ensina alguma coisa** — a formulação é de Tim Brown, e vale como critério de avaliação da sua própria Q6. Junto dela, o corolário: protótipos iniciais devem ser rápidos, toscos e baratos, porque **quanto maior o investimento numa ideia, mais comprometido você fica com ela**, e uma ideia medíocre pode ir longe demais.

**Modo de IA neste arquivo:** 🟢 coprodução para construir o artefato (telas, vídeo, página, automação parcial); 🔴 sem assistência para rodar o teste e interpretar o resultado. A IA não deve opinar se o seu MVP "está bom" — ela vai dizer que sim.

---

## Fontes

- **Ries, Eric**, *A startup enxuta* (ed. brasileira) — a definição de MVP e as duas negações; o caso Groupon/The Point; o MVP em vídeo (Dropbox); o MVP com concierge (Food on the Table) e a distinção em relação à pequena empresa; o teste Mágico de Oz (Aardvark); a regra de corte; "em caso de dúvida, simplifique"
- **Maurya, Ash**, *Running Lean* — "faça a menor coisa possível para aprender" (Dropbox, food trailers de Austin, Food on the Table); o caso da página de captura do próprio livro, com o sumário como parte mais arriscada e os 1.000 e-mails
- **Hanington, Bruce & Martin, Bella**, *Universal Methods of Design* — método 99, Wizard of Oz: origem em Kelly (1980/1984), montagem da sessão e os três papéis do mago
- **Brown, Tim**, *Change by Design* — protótipos rápidos, toscos e baratos; o protótipo bem-sucedido é o que ensina algo

---

<!-- tecnicas/brainstorm.md -->

# Brainstorm

**Para quê:** gerar alternativas em grupo.
**Quests:** 4 a 10 · **Modo:** 🟢 coprodução — com uma ressalva importante

## O que é

Método tradicional de ideação: técnica para elaborar novas ideias em grupo, separando deliberadamente o momento de **gerar** do momento de **julgar**.

## As regras clássicas

1. **Adiar o julgamento.** Nenhuma crítica durante a geração.
2. **Buscar quantidade.** Volume primeiro; qualidade se seleciona depois.
3. **Acolher ideia estranha.** É de onde vem o que ninguém mais teria.
4. **Combinar e melhorar** as ideias dos outros.

As quatro acima são as de Osborn. A disciplina acrescenta uma quinta, de condução:

5. **Um assunto por vez**, e uma pergunta bem formulada.

A regra 1 é a que mais se quebra, e quebrá-la mata a sessão em cinco minutos.

## A ressalva da era da IA

Pedir 50 ideias a um modelo generativo é trivial, e o resultado tem uma característica traiçoeira: é **plausível e médio**. O modelo produz o centro da distribuição — exatamente o oposto do que o brainstorm existe para encontrar.

Use a IA aqui de dois jeitos que funcionam:

- **Depois** da geração humana, para ampliar e combinar o que a equipe produziu.
- Como **provocação enviesada**: peça ideias sob restrição forte ("e se fosse ilegal usar tela?", "e se o usuário tivesse 8 anos?", "e se o orçamento fosse zero?"). Restrição é o que tira o modelo — e as pessoas — da média.

O que não funciona: gerar a lista pronta e escolher da lista. A equipe passa a escolher entre opções que ninguém entende profundamente.

## Alternativa quando o grupo é desigual

Ver `brainwriting.md`. Em equipe onde algumas pessoas dominam a fala, o brainwriting produz mais e melhor.

---

## Fontes

- **Alex Osborn** — as regras clássicas, via **Hanington & Martin**, *Universal Methods of Design*, que datam *Your Creative Power* em **1948** e a 3ª edição de *Applied Imagination* em **1993**; a página do site situa o método na "década de 1950"
- Página `tecnicas/brainstorm` do site da disciplina
- A ressalva sobre uso de IA na geração é da disciplina, não das fontes acima

---

<!-- tecnicas/brainwriting.md -->

# Brainwriting

**Para quê:** gerar alternativas sem que a dinâmica de grupo distorça o resultado.
**Quests:** 4 a 6 · **Modo:** 🔴 sem assistência na rodada silenciosa, 🟡 com apoio depois

## O que é

Variação do brainstorm, criada por **Bernd Rohrbach**, em que as ideias são **escritas**, não faladas, e circulam entre os participantes para serem desenvolvidas.

## Por que existe

O brainstorm falado tem dois problemas conhecidos: quem fala mais influencia demais, e quem tem menos status social no grupo se autocensura. Numa turma de Projetão, com equipes multidisciplinares e formações diferentes, isso é frequente — e o efeito é que a ideia do mais falante vira a ideia da equipe.

Escrever antes de falar neutraliza os dois.

## Como rodar (formato 6-3-5)

1. Enuncie **uma** pergunta clara e visível para todos.
2. Cada participante escreve **3 ideias** em uma folha, em silêncio, em **5 minutos**.
3. Passa a folha para o colega ao lado.
4. Cada um lê as 3 ideias recebidas e escreve **mais 3**, ampliando, combinando ou contrapondo.
5. Repita até a folha voltar ao dono.

Com seis pessoas, a folha volta ao dono depois de **seis** passagens: 6 × 3 × 6 = **108 ideias em cerca de meia hora**, todas com autoria distribuída. (Se você parar em cinco rodadas, são 90 — o número muda com o tamanho do grupo, e é a rotação completa que fecha o exercício.)

## Depois

Agrupe por semelhança, elimine duplicatas, e só então discuta. A discussão fica melhor porque todos já pensaram sozinhos antes de ouvir os outros.

## Quando preferir ao brainstorm

- Equipe nova, que ainda não se conhece
- Equipe com diferença marcada de senioridade ou de curso
- Tema em que alguém já tem posição forte declarada
- Sessão remota (onde o brainstorm falado degrada muito)

---

## Fontes

- Página `tecnicas/brainwriting` do site da disciplina — o método, o formato **6-3-5** e o crédito a **Bernd Rohrbach**, seu criador
- ⚠️ *Universal Methods of Design* **não traz brainwriting**; não o cite como fonte deste método. O efeito do falante dominante e a autocensura por status são leitura da disciplina sobre por que a variação escrita existe.
- Página `tecnicas/brainstorm` do site da disciplina — o brainstorm falado, do qual esta é a variação escrita
- O ajuste ao tamanho de equipe do Projetão é da disciplina

---

<!-- tecnicas/wireframe.md -->

# Wireframe

**Para quê:** planejar a interface antes de desenhá-la.
**Quests:** 6 e 8 · **Modo:** 🟢 coprodução

## O que é

Organização espacial e dimensionamento das interfaces — o esqueleto: o que fica onde, com que peso, em que ordem de leitura. Sem cor, sem tipografia definitiva, sem imagem final.

## Por que sem estética

Porque a estética sequestra a conversa. Mostre um wireframe cinza e as pessoas discutem se a informação está no lugar certo; mostre a mesma tela colorida e discutem o tom do azul. Na fase em que você ainda está decidindo a estrutura, a segunda conversa é desperdício.

Vale ainda mais agora que gerar interface bonita ficou barato: a facilidade de produzir alta fidelidade não é motivo para pular a estrutura.

## Como fazer

1. Liste as **tarefas** que o usuário precisa cumprir naquela tela (vem da jornada da Q6).
2. Ordene os elementos por importância para a tarefa — não por o que é fácil de posicionar.
3. Defina a hierarquia com **tamanho e espaço**, não com cor.
4. Deixe explícito o que é ação primária. Se há três botões do mesmo peso, não há ação primária.
5. Anote as regras que a tela não mostra: o que acontece no estado vazio, no erro, no carregamento.

O item 5 é o mais esquecido, e estado vazio é a primeira coisa que todo usuário novo vê.

## Ligação com a Q8

O wireframe navegável é um ótimo material de teste de usabilidade — barato de mudar e sem inibir a crítica. Ver `../quests/q08-prototipo/SKILL.md`.

---

## Fontes

- **Steve Krug**, *Não me faça pensar* — testar estrutura antes de estética
- ⚠️ **Norman** (affordances e significantes) é a leitura seguinte, não a fonte desta ficha: nada aqui depende dele. Ele entra na Q8, em **Diagnóstico de erro — Quest #8** (`../quests/q08-prototipo/referencias/diagnostico-de-erro.md`)
- Página `tecnicas/wireframe` do site da disciplina
- A observação sobre geração barata de alta fidelidade é da disciplina

---

<!-- tecnicas/early-adopters.md -->

# Usuário afoito (*early adopter*)

**Para quê:** ter com quem validar antes de o produto existir.
**Quests:** 4 a 9 · **Modo:** 🔴 sem assistência no contato

## O que são

Todo produto conta com um pequeno grupo de pessoas que quer usá-lo ou experimentá-lo **antes de estar completo**. São os early adopters, ou usuários afoitos.

São pessoas que enxergam mais rápido o **valor** da solução — seja porque estão mais envolvidas com os problemas que ela resolve, seja porque conhecem com profundidade as alternativas disponíveis e não se sentem contempladas por nenhuma. De um jeito ou de outro, dispõem-se a adotar uma solução ainda imperfeita, e podem contribuir para aperfeiçoá-la.

## O que NÃO são

Não é "quem gosta de tecnologia", nem "estudantes universitários", nem qualquer faixa demográfica. O critério é **intensidade da dor**, não perfil.

Regra prática do Projetão: quem você viu usando a **gambiarra** mais elaborada na Q2 é seu candidato mais forte. Quem já gasta energia contornando o problema é quem mais quer que ele suma.

## Como trabalhar com eles

Mesmo sem protótipo, os usuários afoitos ajudam a desenhar características e atributos da solução.

A forma mais simples de envolvê-los é **construir uma comunidade** — começando com pessoas próximas que se qualifiquem como potenciais usuárias, e agregando novos membros aos poucos.

Manter diálogo permanente com essa comunidade — apresentando avanços e ideias, permitindo que experimentem o que está em desenvolvimento, observando o uso e consultando sobre o que acham — cria engajamento com o projeto. A comunidade se torna a **base de validação** da solução.

## Ao longo das quests

Aparecem quando se definem os públicos (Q4) e vão até a organização do processo produtivo (Q9) e a base de testes. Toda decisão de projeto precisa ser validada com usuários — e são eles que tornam isso possível.

## Teste de realidade

Se você não consegue listar **cinco pessoas com nome** que usariam sua solução amanhã do jeito que ela está, você ainda não tem usuário afoito. Tem público-alvo, que é outra coisa.

---

## Fontes

- **Ash Maurya**, *Running Lean* — o usuário afoito definido por intensidade do problema, não por demografia
- **Steve Blank**, *The Four Steps to the Epiphany* — os cinco degraus do earlyvangelist
- Página `tecnicas/afoitos` do site da disciplina
- Ver **O usuário afoito — Quest #4** (`../quests/q04-escolha/referencias/usuario-afoito.md`) para os degraus abertos um a um

---

<!-- tecnicas/entrevistas.md -->

# Entrevistas

**Para quê:** aprofundar as questões junto ao usuário.
**Quests:** 2, 3, 4 — e eventualmente 6 e 7 · **Modo:** 🔴 sem assistência na condução, 🟡 com apoio no roteiro e na análise

## O que é

Forma de obter informação com pessoas interessadas ou envolvidas no assunto do projeto. É o modo mais comum de pesquisa com usuários.

## Em que se baseiam

Vêm das sondagens de audiência, intenção, gosto e opinião pública desenvolvidas ao longo do século XX pelos meios de comunicação de massa e por grandes corporações. Eram ferramentas de sociólogos e psicólogos comportamentais para colocar em prática a chamada **teoria hipodérmica** — influenciar comportamento de massa por estímulos pontuais aplicados a indivíduos isolados.

Apesar dessa origem próxima de processos de manipulação e controle social — sobretudo na intersecção dos estudos sobre informação com a Cibernética de **Norbert Wiener** e com **Paul Lazarsfeld** —, a entrevista segue sendo mecanismo importante para entender pessoas, suas necessidades, suas formas de atribuir significado e valor, e sua prática e cultura.

Conhecer a origem serve a um propósito prático: entrevista **é** um instrumento capaz de induzir a resposta que se quer ouvir. Saber disso é o que permite não fazê-lo.

## Modalidades

**Entrevista estruturada** — questionário com perguntas previamente elaboradas, construídas para circunscrever e qualificar um assunto. As perguntas são desenhadas estrategicamente para avaliar algo específico e para **detectar resposta inconsistente** (o entrevistado não tem opinião formada, não entende o que responde, é falso-positivo, ou age de má fé), o que permite avaliar a confiabilidade dos dados.
*Cuidado à distância:* um formulário distribuído numa rede social já impõe viés. Pesquisa sobre aversão à tecnologia divulgada no Facebook produz distorção óbvia.

**Grupo de opinião (focus group)** — debate conduzido com várias pessoas em espaço fechado, para que as questões emerjam espontânea e organicamente pela interação. Revela questões menos óbvias. Costuma ser filmado — preferencialmente sem que os participantes se sintam constrangidos ou policiados — porque comportamento corporal, gesticulação e intensidade também são indícios.

**Entrevista em profundidade / semi-estruturada** — com uma única pessoa, sem organização prévia das questões, construída em cima das próprias respostas. É diálogo, busca aprofundar questão já conhecida. Recomenda-se pesquisador experiente: depende da intimidade com o tema e da habilidade de formular perguntas pertinentes dinamicamente. Semi-estruturada porque, embora não haja formulário, é essencial haver **estratégia** para capturar o que se deseja investigar.

**Cadernos de sensibilização** — forma indireta, para assunto sensível ou constrangedor (questões médicas, sexualidade, tabus). O entrevistado recebe um caderno previamente elaborado e o preenche onde se sinta à vontade, ao longo de dias ou meses, após breve orientação. Devolve ao pesquisador sem se identificar.

**Sondas culturais (cultural probes)** — parecidas com os cadernos, mas o entrevistado recebe um kit de artefatos e é orientado a interagir com eles: anotações, colagens, customização. Dão abordagem mais lúdica e engajam mais quando o tema exige esforço criativo ou imaginativo. Podem ser entendidas como entrevista indireta e menos verbal.

## As duas armadilhas

**Não peça a solução ao entrevistado.** "Qual a solução para este problema?" não produz a resposta — ele não tem obrigação de saber, e tem menos obrigação ainda de saber o que você quer descobrir. Se precisar testar direção, apresente opções e pergunte qual parece mais adequada, e por quê.

**Não force concordância.** "Você gosta deste produto que meu grupo criou?" põe a pessoa numa posição em que ela evita ferir seus sentimentos. A resposta virá educada e inútil.

## O roteiro do Running Lean

Para a Q2 e a Q6 há roteiros específicos e cronometrados — Problem Interview e Solution Interview. Ver `../leituras/running-lean/00-indice.md`.

---

## Fontes

- Página `tecnicas/entrevistas` do site da disciplina — a origem histórica (sondagens de massa, teoria hipodérmica, Wiener e Lazarsfeld) e as modalidades
- **Ash Maurya**, *Running Lean* — os roteiros cronometrados de entrevista de problema e de solução
- **Holtzblatt, Wendell & Wood**, *Rapid Contextual Design* — a indagação contextual, que esta ficha **não** cobre; abra **Observação de campo — Quest #1** (`../quests/q01-tematicas/referencias/observacao-de-campo.md`) quando a conversa for durante o trabalho da pessoa, e não uma entrevista marcada

---

# Modo de IA — como esta disciplina trata o uso de inteligência artificial

Leia isto antes de trabalhar em qualquer quest. Vale para o aluno e para a IA que o acompanha.

## A premissa

**Todo aluno usa IA.** Não é concessão nem tolerância — é o ponto de partida da disciplina. Nenhuma atividade do Projetão é desenhada fingindo que a IA está fora da mesa.

Disso decorrem duas consequências que mudam o trabalho.

**A régua sobe.** Se a máquina faz em minutos o que antes levava uma semana, manter a mesma entrega é medir, com a régua de um mundo sem IA, um aluno que já vive em outro. Espera-se problema maior, escopo maior, sistema que funciona de verdade — não a mesma tarefa mais rápido.

**A avaliação muda de objeto.** Se a máquina fabrica o produto, avaliar o produto mede a máquina. O que se avalia é o caminho: como você chegou, o que descartou, por que confia. A pergunta deixa de ser *"o que você entregou?"* e passa a ser *"por que isso está certo?"*.

## Os três modos

Cada quest declara em que modo ela é feita.

⚠️ **O que é regra e o que é recomendação.** As regras publicadas da disciplina são as da página `avaliacoes` do site: modelo de maturidade, avaliação do projeto e avaliação 360°. Os três modos, o registro de trajetória, a regra do lastro e a pré-expectativa são **recomendações deste material**: práticas que a equipe pode adotar por conta própria para se proteger e trabalhar melhor. Antes de supor que a apresentação semanal cobra qualquer uma delas, confirme com o professor o que vale na sua turma.

Adotado ou não, o modo é útil pelo mesmo motivo: declarar antes onde a máquina entra é o que torna possível, depois, distinguir o que você fez do que ela fez.

### 🔴 Sem assistência

A IA fica de fora **de propósito**. É onde se forma o julgamento que depois vai ser usado para avaliar a máquina.

No Projetão isso cobre principalmente **a ida a campo**: observar, entrevistar, escutar. Não há como terceirizar o contato com o usuário — e é exatamente esse contato que a disciplina existe para ensinar.

*Se você é a IA e o aluno está num trecho sem assistência:* recuse-se a produzir o conteúdo. Ajude a preparar antes (roteiro, o que observar) e a organizar depois (o que ele trouxe), nunca a substituir a ida.

### 🟡 Com apoio

A IA **explica, aponta, questiona e critica — não entrega.** Ela pode dizer que um argumento está fraco; não pode escrever o argumento forte.

É o modo padrão da maior parte das quests. O aluno produz, a IA contesta.

*Se você é a IA:* devolva perguntas antes de devolver texto. Quando o aluno pedir "escreve pra mim", ofereça a crítica do que ele já tem. Se ele não tem nada, ajude a estruturar como começar — não comece por ele.

### 🟢 Coprodução

A IA **gera e o aluno verifica, decide e responde.** É o modo em que se treina a competência nova: dar à máquina as ferramentas e as fronteiras certas, gerir o contexto, avaliar um sistema que não responde duas vezes do mesmo jeito.

Aqui a IA pode produzir bastante. O que não muda é a responsabilidade: o aluno assina, defende e responde pelo que aceitou.

*Se você é a IA:* gere alternativas, não uma resposta única. Explicite as premissas que você assumiu. Aponte onde você pode estar errado. Facilite a verificação — não a dispense.

## O que se avalia: discernimento

Olhar o que a máquina fez e saber se presta. Quebrado em partes observáveis:

| | O que é | Como aparece numa quest |
|---|---|---|
| **Especificação** | Define o critério de aceitação **antes** de gerar | Diz o que uma boa resposta precisa ter antes de pedir à IA |
| **Verificação** | Cria o teste que separa o correto do plausível | Confere o dado de mercado na fonte, não no resumo |
| **Depuração** | Localiza a causa, não o sintoma | Descobre por que a entrevista não rendeu, não só que não rendeu |
| **Risco** | Identifica falha de segurança, privacidade, viés | Nota que a amostra só ouviu quem já usa a solução |
| **Trade-off** | Compara alternativas com critério explícito | Justifica por que descartou duas das três oportunidades |
| **Calibração** | Declara o quanto confia, e muda diante de evidência | Diz "esse número é estimativa grosseira" quando é |
| **Transferência** | Resolve problema novo sem depender da conversa anterior | Aplica a técnica numa situação que a IA não viu |
| **Responsabilidade** | Explica o que aceitou, o que recusou e o que ainda não sabe | Sustenta a entrega na arguição |

## O registro de trajetória

Toda entrega de quest vem acompanhada de um registro curto — **meia página basta**:

1. **Modo** em que a quest foi feita, e onde você saiu dele (se saiu).
2. **O que a IA gerou e você descartou** — e por quê. Este é o item mais informativo dos quatro.
3. **O que você verificou** e como. Que afirmação você foi conferir na fonte?
4. **O que ainda não sabe.** Incerteza declarada não tira ponto; incerteza escondida, sim.

Não é burocracia de controle. É o material sobre o qual a nota é formada — e o único jeito de o mérito do aluno aparecer quando o artefato poderia ter saído de qualquer lugar.

## O que a disciplina não faz

- **Não usa escore de detector de IA como prova.** Detectores erram de forma desigual: num teste com redações do **TOEFL** escritas por humanos, sete detectores classificaram como geradas por IA **61%** das redações de quem não é falante nativo de inglês, contra **5%** das de nativos (Liang, Yuksekgonul, Mao, Wu & Zou, *GPT detectors are biased against non-native English writers*, arXiv:2304.02819, 2023 — publicado em *Patterns*). ⚠️ O estudo mede texto em inglês; não há medida equivalente para português, e um contra-estudo do ETS com detectores mais recentes encontra viés menor (Jiang, Bosch, Attali & LaFlair, *Do AI detectors discriminate against non-native English writers?*, ETS Research, 2024). O ponto que sustenta a decisão não depende do número exato: **detector produz suspeita, não prova**, e o erro não se distribui por igual.
- **Não trata declaração de não-uso como mecanismo de controle.** Além de não ser cumprida pela maioria, expõe justamente quem declara com honestidade.

O que substitui os dois é mais trabalhoso e é o que forma: avaliar o processo e o raciocínio.

## Duas obrigações que valem nos dois sentidos

**Acesso.** Assumir que todo aluno usa IA e deixar cada um arcar sozinho com a ferramenta converteria capacidade de pagamento em desempenho. A disciplina se compromete a viabilizar acesso por modelos gratuitos, quotas e parcerias. Se você está sem acesso, isso é problema da disciplina, não seu — avise.

**Custo.** Use o modelo adequado à tarefa, não o maior por reflexo, e declare a escolha quando ela for relevante. Formar alguém para usar bem uma tecnologia inclui formá-lo para perguntar quanto ela custa — e não apenas em dinheiro.

---

*Baseado no manifesto do Porto Digital sobre formação em tecnologia na era da IA (Residência Tecnológica, 2026). A adoção no Projetão está em curso: o que funcionar e o que não funcionar será medido e publicado.*

---

# Consentimento e dados de terceiros

Este material manda você fotografar pessoas em campo, gravar entrevistas, gravar tela de teste de usabilidade e registrar nome e contato de quem foi ouvido. Tudo isso é **dado de outra pessoa**. Ela não é sua colega de equipe nem parte do projeto: ela cedeu meia hora do dia dela.

O que segue é o mínimo para que a coleta seja honesta. Não é assessoria jurídica, e não substitui o que o professor ou o comitê de ética da instituição determinar. Se o seu projeto envolve **saúde, crianças e adolescentes, população em situação de vulnerabilidade, dados de pessoas identificáveis em contexto sensível ou qualquer forma de dado que possa expor alguém**, pare aqui e pergunte ao professor antes de ir a campo.

---

## A regra curta

**Pergunte antes, em voz alta, e aceite o não.**

Três frases, ditas no começo da conversa, resolvem a maior parte dos casos:

> "Sou aluno da UFPE, estou fazendo um trabalho de disciplina sobre *[tema]*. Posso te fazer umas perguntas por uns 20 minutos?"
>
> "Posso gravar só o áudio, para eu não perder nada? Fica com a minha equipe e com o professor da disciplina, que confere o trabalho; ninguém mais ouve, e eu apago no fim do semestre."
>
> "Se em algum momento você quiser parar, ou quiser que eu tire alguma coisa, é só falar."

Se a pessoa hesitar na segunda, **não grave** — anote. Uma entrevista anotada vale mais que uma gravação que a pessoa cedeu constrangida.

---

## O que muda conforme o registro

| Registro | O que fazer |
|---|---|
| **Anotação escrita** | Avise que está anotando. Não registre nome completo se não precisar dele. |
| **Áudio** | Peça na hora, com a gravação **ainda desligada**. Comece a gravação pedindo de novo, agora gravado: assim o consentimento fica no próprio arquivo. |
| **Foto de pessoa identificável** | Peça. Se for espaço público e a pessoa não é o assunto (multidão, movimento do lugar), enquadre de modo que ela não seja identificável. |
| **Foto de lugar, objeto, fila, cartaz** | Livre, desde que não capture rosto, documento nem tela com dado de alguém. |
| **Foto de gambiarra** | **Peça.** Gambiarra quase sempre documenta alguém contornando uma regra do próprio trabalho — o exemplo canônico da disciplina é discutir caso clínico por WhatsApp. A pessoa é identificável pelo contexto mesmo sem aparecer, e a foto pode custar o emprego dela. Fotografe só com permissão, e descreva sem nomear o local se houver qualquer risco. |
| **Vídeo ou gravação de tela em teste de usabilidade** | Peça explicitamente e diga o que vai ser gravado (a tela e a voz, não o rosto — é o padrão, e basta). |
| **Nome e contato** | Só colete se você **vai** usar: para voltar a falar com a pessoa, ou para o professor conferir. Guarde separado das respostas. |

---

## Observação em espaço público

Observar o movimento de uma praça, de uma fila, de um ginásio não exige pedir permissão a cada pessoa — mas exige três cuidados:

1. **Não registre rosto, placa, crachá, documento ou tela alheia** sem pedir.
2. **Se alguém perguntar o que você está fazendo, responda a verdade.** Você é aluno, está fazendo um trabalho, e vai embora. Observador que se esconde perde o direito de estar ali.
3. **Se o lugar tem dono ou responsável** — comércio, escola, posto de saúde, empresa —, apresente-se a ele antes. Entrar sem avisar e depois ser descoberto queima o campo para você e para as próximas turmas.

---

## Campo virtual

A Q1 diz que **espaço virtual conta**, e boa parte das técnicas tem versão à distância. As regras mudam:

| Situação | O que fazer |
|---|---|
| **Observar comunidade online** (grupo, fórum, comentários) | Ler é uma coisa; **reproduzir** é outra. Não cole print com nome de usuário, foto de perfil ou texto que identifique alguém. Parafraseie, ou peça autorização à pessoa. Grupo fechado não é espaço público: entrar para pesquisar sem dizer a que veio é o mesmo que observar escondido. |
| **Chamada de vídeo** | Peça para gravar **antes** de apertar o botão, e de novo já gravando. Diga se o rosto entra ou só a voz. Ferramenta que transcreve sozinha também é gravação: avise. |
| **Teste de usabilidade remoto** | Grave tela e voz, não a câmera. Lembre a pessoa de fechar aba, notificação e qualquer coisa pessoal antes de compartilhar a tela — a responsabilidade de avisar é sua. |
| **Formulário** | Não peça dado que você não vai usar. Se pedir e-mail ou telefone, diga para quê, e não torne obrigatório. |
| **Print de conversa** (WhatsApp, chat) | É dado de duas pessoas, não de uma. Peça às duas, ou tarje. |

---

## A pessoa pode mudar de ideia depois

Consentimento não é assinatura que encerra o assunto. Se a pessoa procurar você depois da conversa e pedir para retirar o que disse, ou apagar a gravação, **atenda** — mesmo que já esteja na entrega. Diga isso a ela no começo:

> "Se depois você quiser que eu tire alguma coisa, me avisa que eu tiro."

Guarde um jeito de encontrar o material dela: se você não sabe qual gravação é de quem, não consegue cumprir a promessa.

---

## E a lei

No Brasil vale a **LGPD** (Lei 13.709/2018). Você não precisa virar especialista, mas três noções mudam decisões concretas:

- **Dado pessoal** é o que identifica alguém — nome, telefone, e-mail, imagem, voz, e também o que identifica **por combinação** ("o enfermeiro do turno da noite daquele posto").
- **Dado sensível** — saúde, origem racial ou étnica, convicção religiosa, opinião política, filiação sindical, vida sexual, biometria — tem regra mais estrita. Se o seu projeto encosta nisso, fale com o professor **antes** de coletar.
- **Finalidade e prazo:** você coleta para o trabalho da disciplina, e apaga no fim do semestre. Usar depois para outra coisa — um artigo, uma startup, um portfólio — é outra finalidade e exige pedir de novo.

⚠️ Isto é orientação de bolso, não parecer jurídico. Em dúvida, pergunte ao professor.

---

## Quem não pode consentir sozinho

- **Menores de 18 anos:** o consentimento é de quem responde por eles. Se o seu projeto é sobre adolescentes, isso não é detalhe de execução — é uma restrição de escopo que muda o cronograma. Fale com o professor **antes da Q1**.
- **Pessoa em situação de dependência em relação a você** (seu funcionário, seu aluno, alguém que espera algo de você): o "sim" dela não é livre. Procure outra pessoa.
- **Pessoa que não entendeu o que você pediu.** Se você não conseguiu explicar em duas frases o que vai fazer com o material, o problema é seu, não dela.

---

## Enquanto o material existe

- **Guarde no lugar da equipe, não no seu celular pessoal** — e num lugar em que quem saiu da equipe deixa de ter acesso.
- **Não publique bruto.** Nem no repositório do projeto, nem no slide do Demoday, nem no grupo da turma. Na apresentação vai o **achado**, não a gravação; se for indispensável mostrar um trecho, peça de novo à pessoa, especificamente para isso.
- **Anonimize na entrega.** "Jorge, 53 anos, usuário do parque" é persona. "Jorge Silva, (81) 9xxxx-xxxx, mora na rua tal" é dado pessoal e não entra em documento que circula.
- **Apague no fim do semestre.** Diga isso à pessoa no começo, e depois cumpra.

---

## O que a IA não faz aqui

Este é um ponto em que a máquina não ajuda, e tentar usá-la piora:

- **Não peça à IA que invente a fala de um entrevistado**, nem para "completar" uma entrevista curta. Se você tem cinco minutos de conversa e precisa de vinte, volte a campo.
- **Não cole gravação nem transcrição com nome, contato ou dado de saúde de terceiro** numa ferramenta de IA sem saber o que ela faz com aquilo. Anonimize antes: troque nomes por iniciais, tire telefone e endereço.
- **Transcrever e organizar o que a pessoa disse** é uso legítimo (🟡 com apoio). **Escrever o que ela teria dito** não é uso: é invenção de evidência, e é o erro que mais desqualifica um projeto.

---

## O teste de uma frase

Antes de registrar qualquer coisa, pergunte-se:

> **Se essa pessoa visse depois o que eu guardei, e onde guardei, ela se sentiria enganada?**

Se a resposta for "talvez", peça de novo — agora explicando a parte que você não explicou.

---

## Fontes

- **IDEO**, *HCD Toolkit* (pt-BR) — a fase *Ouvir*: apresentar-se, explicar o propósito e pedir permissão antes de registrar
- **Holtzblatt, Wendell & Wood**, *Rapid Contextual Design* — o acordo explícito com o participante no começo da sessão de indagação contextual
- **Steve Krug**, *Não me faça pensar* / *Rocket Surgery Made Easy* — a prática de gravar tela e voz, não rosto, e de avisar o participante do que está sendo gravado. Krug vai além e prescreve um **formulário de autorização de gravação, assinado antes da sessão**; num trabalho de disciplina o pedido verbal gravado costuma bastar, mas se a sessão vai ser gravada em vídeo, ou o material pode sair da equipe, use o formulário
- **Lei 13.709/2018 (LGPD)** — as noções de dado pessoal, dado sensível, finalidade e prazo
- ⚠️ O restante deste arquivo é **orientação da disciplina**, não regra publicada no site do Projetão nem parecer jurídico. Em projeto que envolva população vulnerável ou dado sensível, a palavra final é do professor e do comitê de ética da instituição.

---

# Avaliação — como o Projetão mede um projeto

Quatro instrumentos rodam em paralelo: o **modelo de maturidade** (semanal, diagnóstico), a **avaliação do projeto** (final, nota), a **avaliação 360°** (dos pares, ajuste individual) e o **registro de trajetória** (semanal, o que separa o aluno da máquina).

⚠️ **Três são regra; o quarto é recomendação.** Modelo de maturidade, avaliação do projeto e avaliação 360° são o que a página `avaliacoes` do site da disciplina descreve. O **registro de trajetória** — e com ele a **regra do lastro** e a **pré-expectativa**, mais abaixo — é recomendação deste material, não regra publicada. Nada aqui substitui o enunciado do professor: se ele não pediu, não é exigência. Está aqui porque o problema que ele resolve é real, e porque a equipe que o adota sozinha se protege:

O quarto existe por um motivo declarado:

> **Se a máquina fabrica o produto, avaliar o produto mede a máquina.**

Os três primeiros instrumentos avaliam o **artefato**. Sozinhos, eles medem cada vez menos o aluno — e essa é a razão de o quarto existir. Ver `modo-ia.md`.

---

## 1. Modelo de maturidade — 13 milestones, escala 0–5

Acompanhado **semanalmente**. Não gera nota: gera diagnóstico. Serve para a equipe saber onde está frágil enquanto ainda dá tempo de consertar.

**Aprovação exige nível 4 em todos os 13.** Um projeto com doze cincos e um dois não está pronto.

### A escala

| Nível | Significado |
|---|---|
| **0** | O critério ainda não aparece no projeto. |
| **1** | Já aparece, mas sem clareza nem coerência. Normal na primeira vez que o tema é tocado. |
| **2** | Falta clareza **ou** falta coerência com o resto. A resposta ainda está no terreno da insegurança. |
| **3** | Coerente, mas ainda não totalmente claro. Há amadurecimento, resta uma parcela de incerteza. |
| **4** | Claro e coerente com toda a proposta. Ainda cabe aperfeiçoar, mas a equipe responde com segurança. |
| **5** | Perfeitamente alinhado ao conjunto. As respostas às questões de projeto são sólidas. |

O salto que trava a maioria das equipes é o **3 → 4**: sair de "faz sentido" para "eu sustento isso sob pergunta". Quase sempre o que falta não é redação — é evidência de campo.

> ⚠️ **A escala tem um ponto cego, e ele piora com IA.** Do 3 para cima, a diferença entre os níveis é descrita em termos de *clareza*, *coerência* e *segurança na resposta* — exatamente as qualidades que um texto bem gerado exibe sem que nenhum trabalho tenha sido feito. Um nível 5 escrito por máquina é mais elegante que um nível 4 escrito por quem foi a campo e voltou confuso.
>
> **Por isso, do 4 para cima o nível exige artefato, não redação.** Ver a regra do lastro, logo abaixo.

### A regra do lastro

⚠️ *Recomendação deste material — não é regra publicada da disciplina. Ver o aviso no topo.*

Para pontuar **4 ou 5** em qualquer milestone, a equipe precisa apresentar, junto com a resposta, **pelo menos um artefato de trabalho** — algo que existe porque o trabalho foi feito, e que não seria produzido por quem apenas escreveu bem sobre ele.

| Vale como lastro | Não vale |
|---|---|
| Foto do campo, com data | Descrição do que foi observado |
| Áudio ou anotação bruta de entrevista | Resumo da entrevista |
| Nome e contato de quem foi ouvido (com consentimento) | "Entrevistamos 14 pessoas" |
| Post-its ou quadro de afinidades fotografado | A conclusão do agrupamento |
| Gravação de tela do teste de usabilidade | Lista de problemas encontrados |
| Link e captura da fonte do dado, com data de acesso | O número citado |
| Registro de pré-expectativa datado (ver abaixo) | A afirmação de que houve surpresa |

⚠️ **O lastro é material de terceiros — trate-o como tal.** Foto, áudio, gravação de tela e contato pertencem a quem foi ouvido, não à equipe. Antes de coletar qualquer um deles, leia `consentimento.md`. E o lastro **não circula**: ele fica no repositório da equipe, e o professor o consulta ali, quando avalia. Não vai para o slide, não vai para o grupo da turma, não entra em documento que sai da disciplina. Quem promete "só a minha equipe e o professor" e depois publica um trecho quebrou a promessa que fez em campo.

Lastro não precisa ser bonito nem organizado. Precisa ser **anterior à conclusão** e **custoso de fabricar**.

### A pré-expectativa — o único registro que não dá para forjar depois

⚠️ *Recomendação deste material — não é regra publicada da disciplina. Ver o aviso no topo.*

Antes de ir a campo, a equipe escreve **o que espera encontrar**, e envia — com carimbo de data — para o canal da disciplina. Uma frase por item basta.

Isso custa dez minutos e resolve o problema mais difícil da avaliação: *retroativamente, qualquer um consegue escrever que foi surpreendido.* Ninguém consegue escrever, antes, uma expectativa que depois se prove errada de um jeito específico.

Na apresentação, a equipe compara o que escreveu com o que achou. **A divergência é o dado.** Equipe cuja pré-expectativa bateu 100% ou não foi a campo, ou não observou.

### Os 13 critérios

| Milestone | Do que trata | Começa na quest |
|---|---|---|
| **Usuário** | Clareza sobre quem é o usuário/consumidor potencial | Q2 |
| **Problema** | Compreensão do problema efetivo que se tenta resolver | Q3 |
| **Similares** | Profundidade sobre concorrentes, práticas e boas referências | Q3 |
| **PUV** | Identificação de um valor único a entregar, como centro da inovação | Q5 |
| **Solução** | Maturidade da proposta e de como ela resolve o problema | Q6 |
| **Prova de conceito** | Validação da solução conceitual junto ao usuário | Q6 ⚠️ |
| **MVP / Implementação** | Amadurecimento do produto mínimo que entrega os valores validados | Q6 |
| **Estratégias de tração** | Como a equipe se aproxima e constitui um grupo de usuários afoitos | Q7 |
| **Tração efetiva** | Transformação em negócio real; divulgação e promoção | Q7 |
| **Testes de usabilidade** | O que a equipe aprendeu testando, e como a solução mudou | Q8 |
| **Plano de projeto** | Organização da equipe, processo produtivo, divisão de responsabilidades | Q9 |
| **Modelo de receitas** | Custos, preço, formas de obter recursos | Q7 |
| **Pitch** | Clareza para quem não acompanhou o projeto por meses | Q10 |

> ⚠️ **Correção de numeração.** A planilha de maturidade publicada no site do Projetão foi escrita quando a disciplina tinha **9 quests**. Depois entrou a Q4 (Oportunidade Escolhida & Organização da Equipe) e tudo de Q4 em diante deslocou uma casa. A tabela acima já está **corrigida para as 10 quests atuais**. Se você comparar com a planilha original, verá as referências antigas — a diferença é essa, não é erro seu.

> ⚠️ **Um milestone mudou de lugar por decisão, não por renumeração.** A planilha original põe **Prova de conceito** na quest anterior — que, pelo deslocamento acima, seria a **Q5**. Aqui ela está na **Q6**, porque a Q6 se chama literalmente "MVP & Prova de Conceito" e é onde a validação com usuário acontece. Todos os outros doze milestones seguem o deslocamento de +1 exato; este é o único em que houve escolha. Se o seu professor cobrar a prova de conceito já na Q5, siga o professor — e saiba que a diferença é esta.

### Índices de saúde da equipe

Registrados junto com os milestones:

- **Tamanho da equipe** — quantos alunos a compõem
- **Presença** — quantos estão na apresentação
- **Engajamento** — a razão entre os dois

Engajamento é o melhor preditor isolado de projeto que termina mal. Queda sustentada nesse índice antecede, com regularidade, entrega incompleta no Demoday. Se a sua equipe está caindo, isso é um problema de projeto — não de frequência.

---

## 2. Registro de trajetória — o que separa o aluno da máquina

Entregue **junto com cada quest**. Meia página. É o instrumento que responde "por que isso está certo?" em vez de "o que você entregou?".

### O que ele contém

1. **Modo de IA** em que a quest foi feita, e onde vocês saíram dele.
2. **O que a IA gerou e vocês descartaram — e por quê.**
3. **O que vocês verificaram, e como.** Que afirmação foram conferir na fonte primária?
4. **O que ainda não sabem.**

### Como ele é lido — e por que não basta escrevê-lo bem

Este registro é, sozinho, o item mais fácil de fabricar do material inteiro: descrever com elegância o erro de uma IA é justamente a tarefa em que a IA é boa. Uma equipe pode produzir um registro convincente sem ter descartado nada.

Três coisas tornam isso caro, e as três são baratas de exigir:

**Lastro no item 2.** "Descartamos a persona que a IA propôs" não vale nada. **Cole a persona descartada.** O artefato descartado é gratuito para quem descartou de verdade e trabalhoso para quem não descartou.

**Rastro no item 3.** "Conferimos o dado na fonte" não vale nada. **Diga qual afirmação, qual fonte, qual data de acesso, e o que estava diferente do que a IA disse.** Verificação que não achou nenhuma divergência em dez semanas é verificação que não aconteceu.

**Consistência ao longo do semestre.** Este é o mecanismo mais forte, e é praticamente gratuito. As dez quests se encadeiam: o usuário afoito da Q4 tem de ser um dos ouvidos na Q2; os concorrentes da Q3 têm de aparecer na curva da Q5; a base de testes da Q9 tem de ser gente citada antes. **Fabricar dez semanas coerentes entre si custa mais que fazer o trabalho** — e a incoerência aparece sozinha na comparação.

> **Não se avalia um registro de trajetória isolado. Avalia-se a série.**

### O que a disciplina não faz

- **Não usa escore de detector de IA como prova.** Detectores erram de forma desigual: num teste com redações do **TOEFL** escritas por humanos, sete detectores classificaram como geradas por IA **61%** das redações de quem não é falante nativo de inglês, contra **5%** das de nativos (Liang, Yuksekgonul, Mao, Wu & Zou, *GPT detectors are biased against non-native English writers*, arXiv:2304.02819, 2023 — publicado em *Patterns*). ⚠️ O estudo mede texto em inglês; não há medida equivalente para português, e um contra-estudo do ETS com detectores mais recentes encontra viés menor (Jiang, Bosch, Attali & LaFlair, *Do AI detectors discriminate against non-native English writers?*, ETS Research, 2024). O ponto que sustenta a decisão não depende do número exato: **detector produz suspeita, não prova**, e o erro não se distribui por igual.
- **Não trata declaração de não-uso como mecanismo de controle.** Além de não ser cumprida pela maioria, expõe justamente quem declara com honestidade.

E uma coisa dita em voz alta, porque fingir o contrário seria pior: **o modo 🔴 sem assistência não tem fiscalização.** Nada impede um aluno de abrir outra aba. O que sustenta o modo não é vigilância — é o fato de que, sem o campo, ele não terá lastro para pontuar 4, e a incoerência entre as quests vai aparecer. O modo é um contrato, e o custo de quebrá-lo é diferido, não imediato.

---

## 3. Avaliação do projeto — nota 0 a 10

Feita pelos professores sobre o projeto ao final da disciplina. Considera:

- **Completude** — da concepção até a execução e o pleno funcionamento
- **Inovação** — a solução precisa trazer inovação na sua elaboração
- **Especificidades** — cada disciplina tem exigências próprias que precisam aparecer
- **Resultados** — qualidade do trabalho, levando em conta o amadurecimento ao longo do semestre e as considerações da banca no Demoday
- **Trajetória** — a série de registros semanais: o que a equipe descartou, o que verificou, e o quanto o projeto mudou por causa de evidência

O último critério é o que traz o processo para dentro da nota. Sem ele, a avaliação final mede o artefato — e o artefato, hoje, pode vir de qualquer lugar.

A **banca do Demoday** é formada por profissionais do mercado. Ela influencia a nota, mas não a determina: julga o resultado apresentado, sem ter acompanhado o processo de aprendizado do semestre.

Cada equipe tem um **professor mentor**, que acompanha de perto e atua como advogado da equipe na avaliação — ele é quem conhece as dificuldades que o resultado final não mostra. E é ele quem tem a série completa de registros de trajetória.

---

## 4. Avaliação 360° — ±2 pontos

Cada aluno avalia **cada colega da própria equipe** em três dimensões:

- **Engajamento** — atenção dada ao trabalho, envolvimento, colaboração nas tarefas
- **Produtividade** — quanto cada um trabalhou e entregou
- **Convivência** — o quanto as relações têm sido colaborativas, respeitosas e fluidas

O resultado **soma ou subtrai até 2 pontos** sobre a nota de projeto do grupo, individualizando a nota de cada aluno.

**Como o cálculo funciona, e por que isso importa:** o valor é calculado sobre o **desvio do aluno em relação à média da própria equipe** — não em relação a uma régua absoluta. Consequências práticas:

- Avaliar todo mundo com nota máxima não beneficia ninguém: se todos estão na média, todos ficam em zero de ajuste.
- Numa equipe que trabalhou bem por igual, o ajuste tende a zero — o que é o resultado correto.
- Numa equipe desequilibrada, o instrumento separa. É desenhado para isso.

---

## Autodiagnóstico ao fim de cada quest

Faça o exercício antes que ele seja feito por outros:

1. Que milestone esta quest alimenta?
2. Em que nível de 0 a 5 você se coloca?
3. **Qual artefato sustenta esse nível?** — se a resposta é "acho que ficou bom", o nível é 2. Se é um texto bem escrito e nada mais, o teto é 3.
4. O que faltaria para chegar a 4?

Divergência entre a auto-avaliação da equipe e a leitura do mentor é informação útil, não constrangimento. Equipe que se dá 5 no que o mentor vê como 2 tem um problema anterior ao do projeto.