<!-- Projetão · Quest #10 — Preparação para o Demoday · 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 #10 — Preparação para o Demoday

> **Objetivo.** Organização do evento de lançamento e apresentação do projeto desenvolvido.

| | |
|---|---|
| **Modo de IA** | 🟡 com apoio no roteiro · 🟢 coprodução no material do evento — quem apresenta e defende é você |
| **Milestone** | **Pitch** |
| **Entrega** | roteiro de 8 minutos, plano de demonstração e material do evento |
| **Erro que mais custa** | começar pela equipe e pela tecnologia |

---

## O que se prepara

Planejar como apresentar, demonstrar e **provocar impacto** no público, no primeiro contato dele com a solução. O objetivo é captar interesse e, possivelmente, futuros investidores.

A banca é composta por profissionais de atuação reconhecida no mercado — pessoas que **não acompanharam o projeto** e que vão formar juízo em 8 minutos.

---

## O roteiro: siga a ordem das quests

A dica da própria disciplina, e ela é boa porque a metodologia já é um argumento:

> Quem é seu usuário/cliente? Qual o problema que o incomoda? Por que esse problema é relevante? Por que os concorrentes não o trataram adequadamente? Qual é a sua proposta única de valor? Como ela vai concretamente entregar esse valor?

Traduzido em minutos:

| Tempo | O quê | Vem da |
|---|---|---|
| 0:00–0:45 | **A pessoa e a cena.** Concreta, nomeada | Q1, Q4 |
| 0:45–1:45 | O problema e por que é relevante — **com evidência**, e a qual ODS ele responde | Q1, Q2 |
| 1:45–2:30 | Por que o que existe hoje não resolve | Q3 |
| 2:30–3:15 | A proposta única de valor, **em uma frase** | Q5 |
| 3:15–5:30 | **A demonstração** | Q6, Q8 |
| 5:30–6:30 | Que o negócio se paga: preço, custo, tração | Q7 |
| 6:30–7:15 | O que já funciona, o que não, e o que vem | Q8, Q9 |
| 7:15–8:00 | Pedido claro e fechamento | — |

A demonstração é o maior bloco. É ela que a banca lembra.

**A ordem que não funciona:** começar pela equipe e pela stack. Ninguém se importa com a sua tecnologia antes de se importar com o problema.

---

## O que faz uma boa história de projeto

Cinco atributos, e eles viram checklist dos 8 minutos:

1. **Uma necessidade satisfeita no centro** — a narrativa central é sobre como uma ideia atende a uma necessidade de forma poderosa.
2. **Cada personagem com propósito**, e a história se desenrola envolvendo cada participante na ação.
3. **Convincente sem detalhe desnecessário.**
4. **Detalhe suficiente** para ancorar numa realidade plausível.
5. **Prova de que este time consegue realizar** — a plateia não pode ficar em dúvida sobre isso.

> O designer é um contador de histórias, e sua habilidade se mede pela capacidade de construir uma narrativa convincente, consistente e crível.
>
> — Tim Brown, *Change by Design*

**Dois momentos críticos: o começo e o fim.** No começo — a narrativa deve ter sido tecida ao longo do projeto, não montada na véspera. No fim — a história ganha tração quando a plateia a adota e a leva adiante.

E um argumento útil para enquadrar "o que ainda não funciona": a narrativa de design não é um arco fechado com começo, meio e fim arrumadinhos, mas uma **narrativa aberta** que engaja as pessoas e as encoraja a escrever a própria conclusão. **Final aberto é o formato correto, não uma desculpa.**

### Estruturas narrativas que funcionam num pitch

- **Jornada do usuário** — as etapas pelas quais alguém passa, do início ao fim da experiência. No caso clássico do trem de alta velocidade, a jornada tinha dez etapas e o passageiro só sentava no trem na oitava: sete oportunidades de valor teriam sido invisíveis se o time olhasse só a poltrona. **Coloque a jornada de antes e a de depois lado a lado** — é o slide mais eficiente do pitch.
- **Storyboard** — a sequência quadro a quadro, para garantir que a história se sustenta antes do trabalho de detalhe.
- **Cenário** — situação futura descrita com palavras e imagens, com um personagem plausível. Num caso conhecido, um vídeo curto seguindo um time fictício foi **muito mais eficaz para explicar o conceito a investidores** do que um documento técnico ou um deck.

---

## As perguntas da entrega

1. **Como é o elevator pitch da solução?**
2. **Qual o nome comercial e o slogan?**
3. **Como e quanto o usuário pagará, e de que forma?**
4. **O que ainda não está implementado ou funcionando?**
5. **Como a solução será experimentada pelo público no Demoday?**
6. **O que a equipe precisará preparar para o evento?**

**A pergunta 4 parece perigosa e é o contrário.** Declarar o que não funciona é o que dá credibilidade ao que funciona. Banca experiente identifica o buraco sozinha; a diferença é se você o apresentou ou foi pego.

---

## Falar de tração sem inventar número

A banca vai perguntar se alguém usa. Duas maneiras honestas de responder.

### O teste de product-market fit

Uma pergunta, aplicada à sua base de usuários:

> **"Como você se sentiria se não pudesse mais usar [produto]?"**
> — Muito decepcionado
> — Um pouco decepcionado
> — Não decepcionado (não é tão útil assim)
> — N/A — não uso mais

**O limiar:** se mais de **40%** respondem "muito decepcionado", há boa chance de se construir crescimento sustentável em cima de um produto que é *must-have*. O número saiu da comparação de resultados entre centenas de startups: acima de 40% conseguem escalar de forma sustentável; significativamente abaixo, sempre parecem sofrer.

**Duas ressalvas honestas**, que valem dizer à banca: a redação pode precisar de ajuste em contexto corporativo; e o teste pede amostra e segmentação — ele é melhor aplicado quando já se está perto do ajuste produto-mercado. **Ele ajuda a determinar se há tração inicial; não ajuda a conquistá-la.**

### Quando não dá para rodar a pesquisa

Use **retenção**: há tração inicial quando você retém 40% dos usuários ativados, mês após mês.

E a ordem que importa: **receita é a primeira forma de validação; retenção é a forma definitiva.**

---

## Pitch de alto conceito

Destilação num *sound bite* memorável, no formato **"[referência conhecida] para/sem [torção]"**: *"Flickr para vídeo"*, *"Tubarão no espaço"*.

**Não é a PUV, e não vai na landing page** — há o risco de a referência ser desconhecida do público. Onde serve: como gancho memorável que ajuda quem ouviu a espalhar a ideia.

**A torção operacional:** ancore na ferramenta que **o interlocutor** já usa. Num Demoday, isso significa ancorar no que a banca conhece.

---

## A apresentação

Da orientação da disciplina:

- **Escolha alguém que se sinta seguro e confiante.** Não é rodízio democrático.
- **Treine a fala para caber nos 8 minutos** — cronometrada, em voz alta, mais de uma vez. Quase toda equipe estoura no primeiro ensaio.
- **Slides bonitos, claros, limpos, sem excesso de texto.**
- **Prepare-se para demonstrar** ao público presente.

E o que os pitches gravados de edições anteriores mostram com regularidade: **quem lê o slide perde a banca; quem conta a história de uma pessoa concreta prende.** O ensaio que vale é o que tem alguém de fora assistindo — de preferência alguém que não sabe nada do projeto, para dizer em que minuto se perdeu.

---

## A demonstração ao vivo

O maior risco do dia. Quatro regras:

1. **Tenha um plano B gravado.** Vídeo de 60 segundos da solução funcionando, pronto para rodar. Wi-fi de evento cai.
2. **Ensaie no ambiente**, se possível: luz, som, mesa, tomada, distância do público.
3. **Demonstre o caminho feliz.** Não é hora do caso extremo — é hora do valor sendo entregue.
4. **Defina quem faz o quê.** Uma pessoa fala, outra opera. As duas ao mesmo tempo dá errado.

E as diretrizes de demo que valem também aqui: precisa **parecer real** e usar **dados verossímeis**. Nada de *lorem ipsum* — dado plausível sustenta a narrativa.

---

## Autodiagnóstico — milestone *Pitch*

Mede a clareza e o entendimento próprio sobre o que se apresenta: a comunicação será clara para quem não passou meses no projeto? Os alunos compreendem isso? Quanto esforço para tornar compreensível no primeiro contato?

- [ ] Alguém de fora assistiu ao ensaio e entendeu, **sem eu explicar depois**?
- [ ] Cabe em 8 minutos **cronometrados**?
- [ ] A demonstração tem plano B gravado?
- [ ] Digo claramente o que **não** está pronto?
- [ ] Existe um **pedido explícito** no final?
- [ ] O primeiro minuto fala de uma pessoa, ou da equipe e da tecnologia?
- [ ] Se me perguntarem "de onde veio esse número?", eu tenho a fonte?

Nível 2 típico: slides prontos, sem ensaio cronometrado, demo dependendo de wi-fi. Nível 4: roteiro na ordem das quests, ensaiado com plateia externa, demo com plano B, limitações declaradas, pedido claro.

---

## Referências desta quest

| Arquivo | Quando |
|---|---|
| **Roteiro do pitch — Quest #10** (neste arquivo) | Ao montar. Estrutura minuto a minuto, o que vai em cada bloco, os erros de ordem |
| **Tração e números — Quest #10** (neste arquivo) | Ao falar de resultado. O teste de PMF, retenção, o que dizer quando não há número |
| **A demonstração — Quest #10** (neste arquivo) | Ao preparar a demo. Regras, plano B, ensaio, montagem do espaço |
| **Autodiagnóstico — Quest #10** (neste arquivo) | Antes do evento |

---

### Antes de registrar pessoas

| Arquivo | Quando |
|---|---|
| `../../metodo/consentimento.md` | Antes do Demoday. O que não vai para o slide, e o que fazer se você for cadastrar visitantes no evento |

---

### Técnicas desta quest

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

| Ficha | Para quê |
|---|---|
| **Jornada do Usuário** (neste arquivo) | o slide antes-e-depois |
| **Brainstorm** (neste arquivo) | gerar aberturas para o pitch |

---

## Perguntas frequentes

**"E se o projeto não estiver pronto?"**
Apresente o que está, diga com precisão o que falta e por quê, e mostre o que aprendeu. Projeto incompleto apresentado com honestidade vai melhor com a banca do que projeto incompleto apresentado como se estivesse pronto — porque a segunda opção destrói a confiança em tudo o mais que você disse.

**"Podemos usar IA para gerar os slides e o roteiro?"**
Para estruturar e criticar, sim. Mas o pitch é o milestone que mede se **você** entende o que construiu. Roteiro que você não escreveu é roteiro que você não defende na pergunta da banca — e a pergunta vem.

**"Quanto tempo de ensaio?"**
No mínimo três passagens cronometradas, sendo a última com plateia externa. E ensaie a **transição** entre quem fala e quem opera a demo — é onde as apresentações quebram.

---

## Referências de pitch da disciplina

Há dois pitches de edições anteriores usados como referência — **Blun** (Demoday CIn 2019.1) e **Potlatch** (Demoday CIn 2019.2), ambos com transcrição no material da disciplina. Assista aos dois com o roteiro acima na mão, marcando em que minuto cada bloco acontece.

---

## Bibliografia desta quest

| Obra | O que ela dá para a Q10 |
|---|---|
| **Maurya — Running Lean** | Teste de product-market fit, retenção, pitch de alto conceito, regras da demo |
| **Brown — Change by Design** | Storytelling de projeto, jornada, storyboard, cenário, os dois momentos críticos |
| **Ries — A startup enxuta** | O que reportar como progresso: aprendizado, não funcionalidades |

---

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

# Autodiagnóstico — Quest #10

Faça este exercício **antes** do evento, depois do primeiro ensaio cronometrado e antes do último. Ele é o mesmo que o mentor vai fazer depois — e boa parte dele é o que a banca vai fazer no dia.

---

## A escala

O milestone da Q10 é **Pitch**. Ele mede a clareza e o entendimento próprio sobre o que se apresenta: a comunicação será clara para quem não passou meses no projeto? Os alunos compreendem isso? Quanto esforço é preciso para tornar aquilo compreensível no primeiro contato?

| 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. 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. Ainda cabe aperfeiçoar, mas a equipe responde com segurança. |
| **5** | Perfeitamente alinhado ao conjunto. As respostas são sólidas. |

**Nível 2 típico:** slides prontos, sem ensaio cronometrado, demo dependendo do Wi-fi do evento. **Nível 4:** roteiro na ordem das quests, ensaiado com plateia externa, demo com plano B gravado, limitações declaradas, pedido claro.

O salto que trava a maioria na Q10 é o **2 → 3**, e ele quase nunca é sobre design de slide: é sobre a equipe não ter descoberto ainda que **ninguém na banca sabe do que se trata**. Entender uma solução para a qual não se tem referência prévia é mais difícil que o normal — o que parece óbvio para quem está imerso produz percepção completamente diferente em quem tem o primeiro contato.

---

## Rubrica por dimensão

### 1. Estrutura do roteiro

| | |
|---|---|
| **2** | Começa pela equipe e pela stack; a solução aparece antes do problema. |
| **3** | Ordem correta, mas os blocos não têm tempo atribuído e o roteiro não foi cronometrado por bloco. |
| **4** | Ordem das quests, com tempo por bloco, e a demonstração como maior bloco. Cada bloco tem um propósito declarado. |
| **5** | O acima, com a jornada de antes e a de depois lado a lado, e com o retorno explícito à pessoa do minuto zero no fechamento. |

### 2. A pessoa e a evidência

| | |
|---|---|
| **2** | Abertura com dado de mercado ou com adjetivo ("problema gigantesco"). |
| **3** | Há uma pessoa citada, mas genérica ("o estudante brasileiro"). |
| **4** | Pessoa concreta, com nome e cena, vinda da observação de campo; **um** dado externo com fonte, ano e link, aberto e conferido. |
| **5** | O acima, com o reconhecimento explícito de onde o dado não cobre o que a equipe observou. |

### 3. Demonstração

| | |
|---|---|
| **2** | Demo ao vivo, sem ensaio no ambiente, dependendo da rede do evento. Dados de teste na tela. |
| **3** | Demo ensaiada, mas sem plano B, ou com plano B que ninguém testou. |
| **4** | Caminho feliz, dados verossímeis, conta já povoada e logada, **plano B gravado em arquivo local**, uma pessoa fala e outra opera. |
| **5** | O acima, com uma passagem de ensaio inteira feita pelo plano B, e com o ambiente de demonstração congelado na semana do evento. |

### 4. Números

| | |
|---|---|
| **2** | Percentual sem base, ou número de cadastros apresentado como tração. |
| **3** | Números corretos, mas sem definição de "usuário ativo" nem período. |
| **4** | Todo número com base, período, definição e origem; o instrumento nomeado (teste de Sean Ellis ou retenção) e suas limitações declaradas. |
| **5** | O acima, e a equipe responde a "de onde veio esse número?" sem consultar nada. |

### 5. Honestidade sobre o que falta

| | |
|---|---|
| **2** | Nada é dito, ou o que falta aparece só quando a banca pergunta. |
| **3** | "Ainda estamos ajustando algumas coisas." |
| **4** | Bloco próprio, com o que está pronto, o que não está, **por quê**, e o que vem em seguida com data. |
| **5** | O acima, enquadrado como narrativa aberta: o que a banca ou um parceiro poderia fazer para levar aquilo adiante. |

### 6. Entrega e material do evento

| | |
|---|---|
| **2** | Nome comercial e slogan improvisados na véspera; nada preparado além dos slides. |
| **3** | Material feito, mas sem definição de quem faz o quê no dia. |
| **4** | Nome, slogan, elevator pitch, forma de cobrança e plano de como o público vai experimentar a solução, com papéis do dia distribuídos. |
| **5** | O acima, com a mesa desenhada, o que fica com o visitante definido, e **como os contatos coletados serão registrados**. |

---

## Checklist rápido

- [ ] O primeiro minuto fala de uma pessoa, ou da equipe e da tecnologia?
- [ ] A solução aparece só depois de o problema estar estabelecido?
- [ ] Cabe em 8 minutos **cronometrados**, em voz alta?
- [ ] A demonstração é o maior bloco?
- [ ] Existe um **pedido explícito** no final, e ele é específico?
- [ ] Existe plano B gravado, **em arquivo local**, e alguém já ensaiou a passagem inteira com ele?
- [ ] Os dados na tela são verossímeis, ou são "Teste 1" e *lorem ipsum*?
- [ ] A conta já está logada e povoada, ou vamos cadastrar na frente da banca?
- [ ] Uma pessoa fala e outra opera, e as duas ensaiaram juntas?
- [ ] Se me perguntarem "de onde veio esse número?", eu tenho a fonte — para **cada** número na tela?
- [ ] Todo percentual tem a base absoluta ao lado, e "usuário ativo" está definido?
- [ ] Algum número no slide é métrica de vaidade — total de cadastros, total de acessos?
- [ ] Digo claramente o que **não** está pronto, **por quê**, e o que vem depois?
- [ ] Alguém de fora assistiu e entendeu, **sem eu explicar depois** — e disse em que minuto se perdeu?
- [ ] Ensaiamos a transição entre quem fala e quem opera, e as três perguntas duras?

**Sinal de alerta:** se a equipe precisa explicar o pitch depois de apresentá-lo a alguém de fora, o pitch ainda não está pronto — a explicação posterior é o conteúdo que faltava dentro dos 8 minutos.

**Segundo sinal:** se o roteiro foi escrito na semana do evento, do zero, a narrativa não foi tecida ao longo do projeto. Ela pode ainda ser boa; mas confira se cada afirmação dela tem uma quest anterior por trás. A que não tiver é a que a banca vai perguntar.

---

## 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.
   *A Q10 é 🟡 com apoio. Para estruturar e criticar o roteiro, a IA rende. Mas o pitch é o milestone que mede se você entende o que construiu: roteiro que você não escreveu é roteiro que você não defende na pergunta da banca — e a pergunta vem.*

2. **O que a IA gerou e você descartou — e por quê.**
   *Típico da Q10: a IA devolve um roteiro com adjetivos de marketing e uma projeção de mercado. Descartar a projeção e trocar o adjetivo por um comportamento observado é o comportamento esperado.*

3. **O que você verificou, e como.**
   *Típico da Q10: o dado externo do bloco de relevância. Diga qual afirmação você foi conferir na fonte primária, e o que encontrou.*

4. **O que ainda não sabe.**

---

## Como o mentor e a banca vão ler

Cinco perguntas que aparecem com regularidade. Se você tem resposta para as cinco, está em 4:

1. **"Para quem é isso, exatamente?"** Se a resposta cresce enquanto você fala, o segmento não está fechado.
2. **"De onde veio esse número?"** Vale para o dado de relevância e para o de tração. Se a resposta for "vi numa matéria", a pergunta seguinte é qual matéria, e a seguinte é qual a fonte dela.
3. **"O que não funciona?"** Você já respondeu no bloco de 6:30 — então a resposta é "como eu disse". Se a banca precisou perguntar, o bloco não existiu ou não foi claro.
4. **"Por que a pessoa não continua fazendo do jeito que faz hoje?"** É a Q3 voltando: a alternativa existente, inclusive a gambiarra, e por que ela falha para esta pessoa.
5. **"Quem já usou?"** Nome, número e período. Ver `tracao-e-numeros.md` para o que dizer quando ainda não há.

**Uma nota sobre projeto incompleto.** Apresentar o que está pronto, dizer com precisão o que falta e por quê, e mostrar o que foi aprendido vai melhor com a banca do que apresentar um projeto incompleto como se estivesse pronto — porque a segunda opção destrói a confiança em tudo o mais que você disse.

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

---

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

# A demonstração — Quest #10

Abra este arquivo na semana anterior ao Demoday. A demonstração é o maior bloco do pitch e o maior risco do dia: é o que a banca lembra, e é a única parte que pode falhar ao vivo diante de todo mundo.

Modo de IA: 🟢 **coprodução** na preparação — gerar os dados verossímeis do ambiente de demonstração, montar o roteiro de operação, escrever o texto do vídeo de plano B. 🔴 **sem assistência** na execução: quem opera é uma pessoa da equipe, que ensaiou.

---

## 1. As quatro regras

| Regra | O que significa | O que dá errado sem ela |
|---|---|---|
| **1. Tenha um plano B gravado** | Um vídeo curto, de cerca de 60 segundos, da solução funcionando, já aberto num arquivo local, pronto para rodar | Wi-fi de evento cai, e a equipe passa dois dos oito minutos tentando reconectar |
| **2. Ensaie no ambiente** | Luz, som, mesa, tomada, distância do público, resolução do projetor | A tela fica ilegível a cinco metros, ou o áudio do vídeo não sai |
| **3. Demonstre o caminho feliz** | O fluxo em que o valor é entregue à pessoa do minuto zero do pitch | A equipe mostra o caso extremo para "provar robustez", gasta o tempo e a banca não vê o produto funcionando |
| **4. Defina quem faz o quê** | Uma pessoa fala, outra opera. As duas coisas ao mesmo tempo dá errado | A narração para toda vez que é preciso clicar, e o ritmo se perde |

**Sobre a regra 1, um argumento a favor do vídeo que vem da literatura, não do medo.** Brown registra três casos em que **o cenário em vídeo foi mais eficaz que a alternativa**: a Vocera mostrou o crachá de comunicação por voz seguindo uma equipe fictícia de suporte, num filme curto que foi muito mais eficaz para explicar o conceito a potenciais investidores do que um documento técnico ou um conjunto de slides; a Sony fez o mesmo com adolescentes em Tóquio; a Intel produziu a série "Future Vision", realizada em poucas semanas, por uma fração do custo de um anúncio convencional. **Vídeo não é o consolo de quem não conseguiu demonstrar ao vivo.** Em contextos em que o produto ainda não existe por inteiro, ele é frequentemente o formato superior.

> ⚠️ **Uma correção à ordem de preparo usual.** A maioria das equipes grava o vídeo na véspera, se sobrar tempo — e não sobra. Inverta: **grave o vídeo primeiro**, quando o produto atinge o estado apresentável, na semana da penúltima sprint. Ele passa a servir de três coisas ao mesmo tempo: plano B, material do evento, e ensaio do roteiro da demonstração. E se a demo ao vivo funcionar no dia, você tem o vídeo sobrando; o inverso não é verdade.

---

## 2. As diretrizes de demo

Maurya lista cinco diretrizes para qualquer demo — no contexto dele, uma demo de entrevista com cliente, mas as cinco valem inteiras para o Demoday.

| Diretriz | O que ela diz | Aplicação na Q10 |
|---|---|---|
| **Precisa ser realizável** | Ele conta que conhece estúdios de design com times dedicados a construir demos iniciais, muito eficazes na venda, mas apoiadas em tecnologias que **não são aquelas em que o produto final é construído** — com elementos vistosos às vezes impossíveis de recriar. O resultado é uma desconexão entre o que foi prometido e vendido e o que é entregue | Não demonstre nada que a equipe não sabe construir. A banca é de mercado e pergunta |
| **Precisa parecer real** | Ele também rejeita o extremo oposto: apoiar-se em wireframes ou esboços crus, mais rápidos de montar, mas que **exigem do cliente um salto de fé** sobre o produto final. **Quanto mais real a demo parecer, mais precisamente você consegue testar a solução** | O Demoday não é o momento do protótipo de papel. Esse momento foi a Q8 |
| **Precisa ser rápida de iterar** | Você vai receber retorno de usabilidade valioso que precisa ser incorporado e testado nas conversas seguintes. Terceirizar a demo prejudica isso, porque a sua capacidade de iterar passa a depender da agenda de outra pessoa | Quem opera a demo tem de conseguir mexer nela |
| **Precisa minimizar desperdício** | Criar uma simulação em qualquer coisa que não seja a tecnologia final gera algum desperdício. Maurya começa com esboço em papel e ferramentas de desenho, mas em algum momento converte para a tecnologia real | Na Q10, a demo deve ser o produto, ou o mais perto disso que der |
| **Precisa usar dados verossímeis** | Em vez de dados fictícios genéricos — *lorem ipsum* —, invente dados que **pareçam reais**. Eles não só ajudam a diagramar a tela como **sustentam a narrativa da sua solução** | Este é o item que mais rende por hora investida. Ver seção 3 |

E a frase que Maurya cita para fechar o argumento, de Jeffrey Zeldman: **conteúdo precede design; design na ausência de conteúdo não é design, é decoração.**

---

## 3. Os dados da demonstração

É a parte mais barata de fazer certo, e a que mais separa uma demo que convence de uma que não.

**O princípio:** os dados na tela precisam ser os dados **da pessoa do minuto zero do pitch**. Se a abertura falou de dona Marlene, agente comunitária de saúde no bairro X, a tela não pode mostrar "Usuário 1", "Teste", "aaa" e "João Silva". Ela mostra o bairro, os nomes plausíveis, a quantidade de casos que uma agente de fato acompanha, os horários em que ela de fato trabalha.

| Faça | Não faça |
|---|---|
| Nomes, lugares e datas do domínio real do projeto | *Lorem ipsum*, "Teste 1", "asdf" |
| Volume plausível de registros (nem 3, nem 10.000) | Uma lista com um item só, ou uma lista visivelmente gerada |
| Estados variados: um item pendente, um concluído, um com problema | Tudo verde, tudo no estado feliz |
| Valores que fazem sentido junto (data, quantidade, preço coerentes entre si) | Números aleatórios que não se somam |
| Uma conta já povoada, com histórico | Cadastro do zero na frente da banca |

**A regra de tempo que decorre disso:** **nunca demonstre cadastro e configuração.** Chegue com a conta pronta, logada, na tela em que o valor acontece. Configuração consome minuto e não mostra valor. Se o cadastro é o produto — se a PUV é justamente que cadastrar é fácil —, aí sim demonstre, e só ele.

**Ação:** monte o ambiente de demonstração como um artefato próprio, com nome ("conta demo"), e congele-o. Não deixe ninguém rodar teste nele na semana do evento.

---

## 4. O ensaio

Da orientação da disciplina e da prática das edições anteriores:

- **No mínimo três passagens cronometradas**, em voz alta. Ensaio em silêncio mede outra coisa.
- **A última passagem com plateia externa**, de preferência alguém que não sabe nada do projeto. A pergunta que se faz a essa pessoa não é "gostou?" — é **"em que minuto você se perdeu?"**.
- **Ensaie a transição** entre quem fala e quem opera. É onde as apresentações quebram: a fala para, a mão procura o mouse, e três segundos de silêncio viram trinta.
- **Ensaie a falha.** Uma passagem inteira em que, no minuto 3:15, o Wi-fi "cai" e a equipe tem de partir para o vídeo. Se a transição para o plano B nunca foi ensaiada, ela vai levar um minuto no dia.
- **Ensaie as perguntas.** Peça a alguém de fora que faça três perguntas duras ao fim — de onde veio o número, o que não funciona, e por que não usar a alternativa existente da Q3.

A meta do ensaio não é decorar; é **descobrir onde o roteiro estoura**. Quase toda equipe estoura o tempo na primeira passagem, e o bloco que estoura raramente é o que a equipe imagina.

---

## 5. A montagem do espaço

Aqui vale um argumento que Brown desenvolve sobre prototipagem de experiência, porque ele muda o modo de pensar o estande ou a mesa do Demoday: **a experiência que se desenrola no tempo e envolve o participante é ela mesma um protótipo.** Ele descreve equipes que alugaram um galpão e construíram, em papelão, a réplica em tamanho real do lobby e de uma suíte de hotel — não para mostrar qualidade estética, mas para servir de **palco em que designers, clientes e "hóspedes" pudessem encenar diferentes experiências de serviço** e explorar, em espaço e tempo reais, o que parecia certo. Todos os visitantes eram convidados a colar notas adesivas no protótipo e sugerir mudanças.

A tradução para uma mesa de Demoday, se o evento tiver esse formato além do pitch:

| Elemento | Decisão a tomar antes |
|---|---|
| **O que a pessoa vê ao chegar** | Qual tela está aberta, e o que ela comunica sem ninguém falar |
| **O que a pessoa faz** | Ela opera, ou vocês operam? Se ela opera, qual é a **uma** tarefa que vocês pedem |
| **Quanto tempo dura** | Uma interação de estande dura de 60 a 120 segundos. O que cabe |
| **Quem fala com quem** | Alguém recebe, alguém demonstra, alguém anota. Rodízio combinado |
| **O que fica com a pessoa** | Cartão, QR para a página, formulário de contato — e quem digita o que foi coletado |
| **Como vocês registram** | Se dez pessoas passarem e nada for registrado, o evento não gerou dado. Uma folha com riscos já resolve |

**Ação:** desenhe a mesa numa folha antes do dia, com onde fica cada pessoa e cada objeto. Cinco minutos de desenho eliminam a maior parte da improvisação do dia.

---

## 6. Divisão de papéis no dia

| Papel | Faz | Não faz |
|---|---|---|
| **Quem apresenta** | Narra os 8 minutos. Uma pessoa, escolhida por se sentir segura e confiante, não por rodízio | Não opera o computador |
| **Quem opera** | Conduz a demonstração no ritmo da narração; dispara o plano B se preciso | Não fala, exceto se combinado |
| **Quem cuida da infraestrutura** | Cabo, tomada, adaptador, áudio, brilho, notificações desligadas, bateria; testa 30 minutos antes | Não é a mesma pessoa que apresenta |
| **Quem responde a perguntas** | Pode ser mais de uma pessoa, mas **acorde antes quem responde o quê** — técnico, negócio, usuário | Não responde três ao mesmo tempo |
| **Quem registra** | Anota as perguntas feitas pela banca e os contatos coletados | — |

**A regra que resolve a maior parte dos acidentes:** as duas primeiras funções são de **duas pessoas diferentes**, e elas ensaiaram juntas.

---

## 7. Checagem final

Coisas de custo quase zero que salvam a apresentação, e que se esquecem na semana da entrega:

- Vídeo de plano B **no disco local**, não na nuvem, e já aberto num programa que funciona sem rede.
- Notificações e mensagens desligadas em todas as telas que forem projetadas.
- Ambiente de demonstração congelado, com dados verossímeis, conta já logada.
- Adaptador de vídeo próprio, e um segundo cabo.
- Bateria carregada e carregador na tomada, porque o slot pode atrasar.
- Uma versão dos slides em PDF, num segundo dispositivo.
- Modo avião no celular de quem apresenta; celular de outra pessoa com o cronômetro.
- Alguém com a resposta pronta para "de onde veio esse número?" de cada número na tela. Ver `tracao-e-numeros.md`.

**A última:** o que **não** está pronto, dito com precisão, no bloco de 6:30 do roteiro. Declarar é o que dá credibilidade ao que funciona; banca experiente identifica o buraco sozinha, e a diferença é se você o apresentou ou foi pego.

---

## Fontes

- **Maurya, Ash**, *Running Lean*, cap. 8 — as cinco diretrizes da demo (realizável, parecer real, rápida de iterar, minimizar desperdício, dados verossímeis), a rejeição tanto da demo tecnologicamente descolada quanto do wireframe cru, e a citação de Jeffrey Zeldman sobre conteúdo preceder design
- **Brown, Tim**, *Change by Design*, cap. 4 — os cenários em vídeo da Vocera, da Sony e da Intel e a comparação com documento técnico e conjunto de slides; a encenação como protótipo, o galpão com a réplica em papelão do lobby e da suíte, e o convite ao visitante para intervir no protótipo
- **Material da disciplina** — a orientação sobre quem apresenta, o tempo de 8 minutos, a preparação para demonstrar ao público presente, e a pergunta 4 da entrega sobre o que ainda não está implementado

---

<!-- referencias/roteiro-do-pitch.md -->

# Roteiro do pitch — Quest #10

Abra este arquivo ao montar os 8 minutos, e de novo depois do primeiro ensaio cronometrado, quando for preciso cortar. Ele trata do que vai em cada bloco, dos erros de ordem, e das três estruturas narrativas que funcionam num pitch de projeto.

Modo de IA: 🟡 **com apoio**. A IA critica o roteiro, cronometra a leitura, aponta o bloco inchado e faz as perguntas que a banca faria. Ela não escreve o roteiro — o pitch é o milestone que mede se **você** entende o que construiu, e roteiro que você não escreveu é roteiro que você não defende na pergunta.

---

## 1. A estrutura, bloco a bloco

A ordem vem da própria metodologia da disciplina: quem é o usuário, qual o problema, por que ele é relevante, por que os concorrentes não o trataram, qual é a proposta única de valor, e como ela entrega esse valor concretamente. A metodologia já é um argumento — seguir a ordem das quests mostra que houve método, sem que ninguém precise dizer isso.

| Tempo | Bloco | Vem da | O que **entra** | O que **não entra** |
|---|---|---|---|---|
| 0:00–0:45 | **A pessoa e a cena** | Q1, Q4 | Uma pessoa concreta, com nome e situação. Onde ela está, o que está tentando fazer, o que dá errado. Uma frase de observação de campo | Estatística de abertura. Nome da equipe. Agradecimento |
| 0:45–1:45 | **O problema e por que é relevante** | Q2 | A dor descrita como comportamento observado, e **um** dado externo com fonte que dimensiona | Três dados. Adjetivos ("gigantesco", "alarmante") |
| 1:45–2:30 | **Por que o que existe hoje não resolve** | Q3 | As alternativas existentes, inclusive a gambiarra que as pessoas usam. Por que elas falham para **esta** pessoa | Tabela comparativa de funcionalidades com sinais de certo e errado |
| 2:30–3:15 | **A proposta única de valor** | Q5 | Uma frase. A PUV, dita e mostrada na tela | A lista de funcionalidades |
| 3:15–5:30 | **A demonstração** | Q6, Q8 | O caminho feliz, com dados verossímeis, resolvendo o problema da pessoa do minuto zero. Ver `demonstracao.md` | Configuração, login demorado, tela de administração |
| 5:30–6:30 | **Que o negócio se paga** | Q7 | Preço, como se cobra, custo principal, e o número de tração que existir. Ver `tracao-e-numeros.md` | Projeção de cinco anos. Tamanho de mercado sem caminho até ele |
| 6:30–7:15 | **O que já funciona, o que não, e o que vem** | Q8, Q9 | O que está pronto, o que não está, o que foi aprendido no teste com usuários, e a próxima etapa com data | Roadmap de doze meses |
| 7:15–8:00 | **Pedido e fechamento** | — | Um pedido explícito e específico, e o retorno à pessoa do minuto zero | "Obrigado, perguntas?" |

**A demonstração é o maior bloco.** É ela que a banca lembra. Se ao cortar o roteiro você cortar a demonstração para caber, cortou a coisa errada.

**Uma observação sobre o primeiro bloco.** Vale lembrar o que a Q8 registra: entender uma solução para a qual não se tem referência prévia é mais difícil que o normal. A banca é composta de profissionais que **não acompanharam o projeto** e vão formar juízo em 8 minutos. Os primeiros 45 segundos existem para dar a eles a âncora — uma pessoa e uma cena — a partir da qual tudo o mais faz sentido.

---

## 2. Os erros de ordem

Não são erros de conteúdo. O material está todo lá; está na sequência errada, e a sequência errada custa a atenção da banca antes do minuto três.

| Erro | O que acontece | A correção |
|---|---|---|
| **Começar pela equipe** | "Somos cinco alunos do CIn e temos paixão por tecnologia." Ninguém se importa com quem você é antes de se importar com o problema | A equipe entra no bloco de 6:30, como parte da prova de que dá para realizar |
| **Começar pela tecnologia** | A stack, a arquitetura, o modelo usado. Ninguém se importa com a sua tecnologia antes de se importar com o problema | A tecnologia entra na demonstração, implícita, ou no bloco de 6:30 se for diferencial real |
| **Solução antes do problema** | A banca vê a tela sem saber o que ela resolve, e passa os minutos seguintes tentando reconstruir a pergunta | Nunca mostre tela antes do minuto 2:30 |
| **Mercado antes da pessoa** | "O mercado de X movimenta R$ Y bilhões." Número grande sem ninguém dentro | O dado de mercado, quando entra, entra depois da cena, para dimensionar o que já foi descrito |
| **Guardar o que não funciona para o fim** | Vira confissão de última hora, sob pressão de tempo, com a banca já em modo de julgamento | Bloco próprio, em 6:30, dito com calma |
| **Deixar o pedido de fora** | O pitch termina em "obrigado" e a banca não sabe o que fazer com o que ouviu | Um pedido específico, dito em voz alta, nos últimos 45 segundos |

---

## 3. Os cinco atributos de uma boa história de projeto

Brown descreve o que está no centro de qualquer boa história, e a descrição vira checklist dos 8 minutos:

1. **Uma necessidade satisfeita, no centro.** No coração de qualquer boa história está uma narrativa central sobre **o modo como uma ideia atende a uma necessidade de forma poderosa**. Os exemplos que ele dá são todos concretos e pequenos: combinar um jantar com amigos que estão em pontas opostas da cidade; aplicar insulina discretamente durante uma reunião de trabalho; migrar de um carro a gasolina para um elétrico.
2. **Cada personagem com propósito.** Conforme a história se desenrola, ela dá a **cada personagem representado nela um senso de propósito**, e se desenrola de um modo que **envolve cada participante na ação**. Num pitch: se você citou o gestor, o operador e o usuário final, os três precisam ter função na cena — não podem ser figurantes de slide.
3. **Convincente, sem detalhe desnecessário.** Ela convence sem nos sobrecarregar com detalhe que não serve.
4. **Detalhe suficiente para ancorar.** E, ao mesmo tempo, inclui **bastante detalhe para ancorá-la numa realidade plausível**. Os dois critérios são um par, não uma contradição: corte o detalhe que não ancora; mantenha o que ancora.
5. **Prova de que este time consegue realizar.** A história **não pode deixar a plateia em dúvida** de que quem a narra tem o que é preciso para torná-la real.

O quinto atributo é o que a equipe costuma tentar cumprir no lugar errado — na abertura, apresentando currículos. Ele se cumpre melhor na demonstração que funciona, no teste com usuários que de fato aconteceu, e no plano com datas da Q9.

> O designer é um contador de histórias, e a habilidade dele se mede pela capacidade de construir uma narrativa convincente, consistente e crível.

**Um alerta de calibragem.** Brown conta o caso de uma apresentação para executivos de uma fabricante de ferramentas, em que a equipe transformou uma oficina abandonada num percurso narrativo — carros nas cores da marca na porta, sala com artefatos inspiracionais, vídeos de mecânicos reais falando da marca, e por fim uma sala escura em que se acendem as luzes sobre os protótipos. A vice-presidente de marketing chorou. E ele conclui com a ressalva que interessa: **nem sempre é necessário fazer a plateia chorar, mas uma boa história bem contada deve entregar um golpe emocional.** Num Demoday isso raramente é produção; é a pessoa do minuto zero sendo real.

---

## 4. As três estruturas narrativas

### A jornada

É a estrutura de cenário mais simples e mais útil para serviço: ela **mapeia as etapas pelas quais um cliente imaginado passa, do começo ao fim da experiência**. O ponto de partida pode ser imaginário ou vir direto de observação. O valor de descrevê-la é que ela **deixa claro onde o cliente e o serviço se encontram** — e cada um desses pontos de contato é uma oportunidade de entregar valor, ou de perder a pessoa de vez.

**O caso, com os números.** A Amtrak estudava um serviço de trem de alta velocidade na costa leste dos Estados Unidos. Quando a IDEO foi chamada para o projeto que virou o Acela, o foco já havia se estreitado aos trens e, na prática, ao **desenho das poltronas**. Depois de passar dias andando de trem com passageiros, a equipe montou uma jornada simples que descrevia o processo inteiro de viagem. Para a maioria dos clientes ela tinha **dez etapas**, incluindo chegar à estação, achar estacionamento, comprar passagem, localizar a plataforma. E o achado: **os passageiros só se sentavam no trem na etapa oito.** A maior parte da experiência de viajar de trem, portanto, não envolvia o trem.

A conclusão da equipe: cada uma das etapas anteriores era uma oportunidade de criar uma interação positiva — oportunidades que teriam passado despercebidas se o time tivesse olhado só para a poltrona. Brown reconhece que isso tornou o projeto muito mais complexo, e observa que essa é a passagem típica do design para o pensamento de design. E o fecho: **a jornada do cliente foi o primeiro protótipo do processo.**

**Como usar no pitch:** coloque **a jornada de antes e a jornada de depois lado a lado**, num slide só. É o slide mais eficiente que um pitch de projeto pode ter, porque ele mostra problema, solução e escopo ao mesmo tempo, sem texto.

### O storyboard

A origem está no cinema. Quando o filme era pouco mais que teatro gravado, dava para ir do roteiro direto à filmagem. Conforme os diretores ficaram mais ambiciosos, com múltiplas câmeras e efeitos, **o storyboard surgiu como forma de mapear o filme antes de rodá-lo**, para garantir que todas as cenas estivessem pensadas e que o diretor não descobrisse na ilha de edição que faltava um ângulo essencial. Com a animação, ele ganhou papel ainda maior: virou **ferramenta de prototipagem que permitia aos animadores se certificarem de que a história se sustentava antes de começar o trabalho de detalhe**.

**Como usar no pitch:** desenhe os 8 minutos em oito quadros antes de abrir o editor de slides. Se a história não se sustenta em oito quadros de rabisco, ela não vai se sustentar com transições bonitas. Val Head faz a mesma recomendação para animação de interface: o storyboard é mais útil quando cobre **a frase inteira de interação**, e não trechos soltos.

### O cenário

É uma forma de narrativa em que **uma situação futura possível é descrita com palavras e imagens**. Brown descreve o método: inventar um personagem que se encaixe num conjunto de características que interessam — ele dá o exemplo de uma profissional divorciada com duas crianças pequenas — e desenvolver ao redor dela uma rotina diária crível, para "observar" como ela usaria o produto.

**Os casos, e o que eles mostram sobre plateia.** Quando a comunicação por Wi-Fi ainda engatinhava, a Vocera fez um cenário em vídeo mostrando como funcionários poderiam usar um crachá de comunicação por voz para se manterem conectados. O filme curto seguia a rotina de uma equipe fictícia de suporte de TI, e foi **muito mais eficaz para explicar o conceito a potenciais investidores do que um documento técnico ou um conjunto de slides**. A Sony usou a mesma técnica no início dos anos 1990, criando cenários sobre a vida de adolescentes em Tóquio para mostrar como eles usariam novos tipos de casa de jogos on-line. E a Intel, querendo mostrar como seria a vida num mundo de computação ultramóvel, produziu uma série de cenários em filme — o "Future Vision" — que uma equipe de design realizou em poucas semanas, por uma fração do custo de um anúncio convencional.

O terceiro valor do cenário, e é o que ele faz por você durante o preparo: **ele obriga a manter as pessoas no centro da ideia**, impedindo que a equipe se perca em detalhe mecânico ou estético.

**Como usar no pitch:** o cenário é o plano B da demonstração. Um vídeo curto seguindo uma pessoa plausível resolve o problema de mostrar o que ainda não existe, e resolve o problema do Wi-Fi do evento. Ver `demonstracao.md`.

---

## 5. Os dois momentos críticos

Brown é específico: a narrativa eficaz, como parte de um programa maior, **depende de dois momentos críticos — o começo e o fim.**

**No começo.** É essencial que a narrativa **comece cedo na vida do projeto e seja tecida em cada aspecto do esforço**. Ele observa a mudança de prática: era comum trazer quem escreve só no fim, para documentar um projeto concluído; cada vez mais as equipes incorporam essa pessoa **desde o primeiro dia**, para mover a história em tempo real.

> ⚠️ **É por isso que o pitch não se monta na véspera.** Uma equipe que registrou o que aprendeu em cada quest chega à Q10 com a narrativa quase pronta — a pessoa do minuto zero é alguém que ela observou na Q1, a evidência é a que ela levantou na Q2, o que não funciona é o que apareceu no teste da Q8. Uma equipe que não registrou vai ter de inventar, e a banca percebe. O material da Q10 não é criação: é **seleção** do que já foi produzido.

**No fim.** A história **ganha tração quando é adotada pela plateia**, que se sente motivada a levá-la adiante muito depois de a equipe ter se dispersado.

E daí decorre o argumento que resolve o problema mais delicado da Q10 — o que dizer sobre o que ainda não funciona. Brown propõe que a narrativa do design não seja pensada no sentido de um **começo, meio e fim arrumadinhos**, mas como uma **narrativa contínua e aberta, que engaja as pessoas e as encoraja a levá-la adiante e escrever a própria conclusão**. Ele cita o filme de Al Gore como exemplo: ao final, o autor apresenta a evidência e **desafia os espectadores a tornarem aquilo deles**. Brown chama de mais um exemplo de pensamento de design em ação **deixar que o cliente escreva o último capítulo da história**.

**Final aberto é o formato correto, não uma desculpa.** Mas há uma condição: final aberto exige que **você diga com precisão onde a história parou.** Ambiguidade sobre o que está pronto não é final aberto; é confusão.

---

## 6. O pitch de alto conceito

Serve como gancho memorável, não como abertura.

**O que é:** a destilação da ideia num *sound bite* memorável. Maurya registra a origem — produtores de Hollywood usam para condensar o enredo geral de um filme — e o formato **"[referência conhecida] para/sem [torção]"**. Os exemplos que ele dá: *"Flickr para vídeo"*, *"Tubarão no espaço"*, *"Friendster para cachorros"*.

**O que ele não é:** ele **não deve ser confundido com a PUV, e não se destina à página inicial do produto**. Há um risco real de os conceitos em que ele se apoia serem **desconhecidos do público**. Por isso ele é mais eficaz quando usado para passar a ideia rápido e **torná-la fácil de espalhar** — por exemplo, ao fim de uma conversa com um cliente.

**A torção operacional:** ancore na ferramenta que **o interlocutor** já usa. Maurya faz isso literalmente: no exemplo dele, a instrução é substituir o nome do serviço de referência pelo nome do serviço que aquela pessoa específica usa. Num Demoday, isso significa ancorar no que **a banca** conhece — e a banca é de mercado, não de academia.

**Onde ele cabe nos 8 minutos:** não no minuto zero. Ele cabe como a frase de fechamento do bloco da PUV, ou como a última frase antes do pedido — porque a função dele é ser o que a pessoa da banca repete para alguém depois do evento.

---

## 7. Preparar a fala

Da orientação da disciplina, com o que a prática acrescenta:

- **Escolha quem se sente seguro e confiante.** Não é rodízio democrático. A pessoa que apresenta e a que opera a demo podem ser duas — devem ser duas.
- **Cronometre em voz alta, mais de uma vez.** Quase toda equipe estoura no primeiro ensaio. Ensaio em silêncio, lendo com os olhos, mede outra coisa.
- **Slides limpos, sem excesso de texto.** Quem lê o slide perde a banca. O slide existe para mostrar o que não dá para dizer: a cena, a jornada antes e depois, o número, a tela.
- **Ensaie com alguém de fora**, de preferência quem não sabe nada do projeto, e peça que essa pessoa diga **em que minuto se perdeu**. É a única medida útil de clareza que você consegue antes do dia.
- **Ensaie a transição** entre quem fala e quem opera a demo. É onde as apresentações quebram.

**Ação:** faça o storyboard de oito quadros antes de abrir o editor de slides. Depois cronometre a leitura de cada bloco separadamente e anote o tempo real ao lado da tabela da seção 1. O bloco que estoura sempre é o mesmo, e não é a demonstração.

---

## Fontes

- **Brown, Tim**, *Change by Design* — cap. 4: cenários, o storyboard vindo do cinema e da animação, a jornada do cliente, o caso do Acela com as dez etapas e a etapa oito, os cenários em vídeo da Vocera, da Sony e da Intel, e o argumento de que o cenário mantém as pessoas no centro; cap. 7: os cinco atributos da boa história, o designer como contador de histórias, o caso da apresentação da fabricante de ferramentas e o golpe emocional, os dois momentos críticos (começo e fim), a narrativa aberta e o exemplo de Al Gore, deixar o cliente escrever o último capítulo
- **Maurya, Ash**, *Running Lean*, cap. 3 e 7 — o pitch de alto conceito: origem em Hollywood, o formato, os exemplos, a advertência de não confundir com a PUV nem usar na página inicial, e a instrução de ancorar na referência que o interlocutor usa
- **Head, Val**, *Designing Interface Animation*, cap. 10 — o storyboard cobrindo a frase inteira de interação, e não trechos soltos
- **Krug, Steve**, *Não me faça pensar* — o argumento de que entender algo sem referência prévia é mais difícil do que parece para quem está imerso
- **Material da disciplina** — a ordem das quests como estrutura do pitch, a orientação sobre quem apresenta, o tempo de 8 minutos e a composição da banca

---

<!-- referencias/tracao-e-numeros.md -->

# Tração e números — Quest #10

Abra este arquivo ao preparar o bloco de 5:30 do pitch, e antes de escrever qualquer número num slide. A banca vai perguntar se alguém usa. Há duas maneiras honestas de responder, e uma terceira para quando não há número nenhum.

Modo de IA: 🟡 **com apoio**. Peça à IA que faça as perguntas que a banca faria sobre cada número do seu slide — de onde veio, sobre qual base, em que período. 🔴 **sem assistência** na produção de números: nenhum número que a equipe não mediu entra na apresentação.

---

## 1. O teste de ajuste produto-mercado

### A origem

O termo *product/market fit* — ajuste produto-mercado — foi cunhado por Andy Rachleff, cofundador da firma de capital de risco Benchmark Capital, e popularizado por um texto de Marc Andreessen. Maurya observa que esse texto **terminou com mais perguntas do que respostas** e não ofereceu orientação sobre como alcançar ou medir o ajuste.

Quem tornou o conceito menos abstrato foi **Sean Ellis**, que dirigia a consultoria 12in6, especializada em ajudar startups na transição para crescimento. **Como condição para aceitar um cliente**, ele conduzia uma pesquisa qualitativa com uma amostra dos usuários da empresa, para determinar se o produto tinha tração inicial — o que era um bom indicador de que a empresa estava no caminho certo.

### A pergunta, exatamente como se aplica

> **"Como você se sentiria se não pudesse mais usar [produto]?"**
>
> — Muito decepcionado
> — Um pouco decepcionado
> — Não decepcionado (não é tão útil assim)
> — N/A — não uso mais

Quatro opções. Não são cinco, não há escala de 1 a 10, e a redação da pergunta é feita no negativo — pela retirada, não pela satisfação.

### O limiar

**Se mais de 40% dos usuários respondem "muito decepcionado"**, há boa chance de se construir crescimento de aquisição de clientes sustentável e escalável em cima de um produto que é *must-have* — indispensável.

**De onde vem o número:** Maurya é explícito sobre a origem, e vale citar assim se perguntarem. O parâmetro de 40% foi determinado **comparando resultados entre centenas de startups**: as que ficavam acima de 40% geralmente conseguiam escalar o negócio de forma sustentável; as que ficavam significativamente abaixo **sempre pareciam sofrer**.

---

## 2. O que o teste mede, e o que ele não mede

Maurya faz três ressalvas ao teste que ele mesmo recomenda. Todas as três valem dizer à banca — dizê-las é o que transforma um número emprestado em raciocínio próprio.

| Ressalva | O que significa | O que fazer na Q10 |
|---|---|---|
| **A redação pode precisar de ajuste** | Maurya considera que a formulação exata poderia ser levemente ajustada conforme o mercado. Em contexto corporativo, por exemplo, insinuar que se vai retirar o produto pode não cair bem com clientes iniciais que estão investindo tempo nele. Fora isso, ele considera a premissa do teste sólida | Se você ajustou a redação, **mostre a redação que usou** |
| **Pesquisa verifica, não ensina** | O desafio maior de aplicar o teste é o mesmo de qualquer pesquisa com cliente: **pesquisas são mais eficazes para verificação do que para aprendizado** | Não use o resultado para descobrir o que fazer. Use conversa para isso |
| **Ele exige amostra e segmentação** | Para o resultado ser estatisticamente significativo, é preciso amostra grande o suficiente, considerar segmentação de clientes e considerar motivação do usuário. Por isso **o teste é melhor aplicado quando já se está perto do ajuste produto-mercado** — que é também o que o próprio Sean Ellis recomenda | Se a base tem 12 pessoas, **diga que tem 12** e trate o resultado como sinal, não como medida |

E a limitação que resume as três:

**O teste ajuda a determinar se há tração inicial; ele não ajuda a conquistá-la.**

> ⚠️ **O erro mais provável na Q10.** Uma equipe roda a pergunta com os oito colegas que testaram, obtém 50%, e escreve "atingimos ajuste produto-mercado". Isso é errado por três motivos ao mesmo tempo: a amostra não sustenta, quem respondeu não é usuário real de uso continuado, e o teste é para quem **já está perto** do ajuste. A formulação defensável é: *"aplicamos o teste de Sean Ellis com as N pessoas da nossa base de testes; X responderam 'muito decepcionado'. A amostra não permite conclusão, e o teste pressupõe estar perto do ajuste — reportamos como sinal inicial."* Essa frase é mais forte diante da banca do que a afirmação, porque mostra que você sabe o que o instrumento faz.

---

## 3. A alternativa por retenção

Quando não dá para rodar a pesquisa — e numa disciplina de um semestre normalmente não dá —, Maurya oferece um caminho pelos indicadores do ciclo de vida do cliente.

**A distinção que orienta a escolha do indicador.** Alguns produtos capturam **valor de uma vez só**: fotógrafo de casamento, advogado de divórcio, livro, DVD. Outros capturam **valor recorrente por uso repetido**: software como serviço, redes sociais, restaurante, revista.

| Tipo de produto | Indicador que mede "construiu algo que as pessoas querem" |
|---|---|
| Valor de uma vez | **Ativação** — a qualidade da experiência do serviço |
| Valor recorrente | **Retenção** — a ativação continua importando, porque um bom primeiro contato ainda é necessário, mas o sucesso vem do uso repetido |

Os dois juntos formam o que Maurya chama de **indicadores de valor**.

**O argumento que permite transportar o limiar:** dá para sustentar que uso repetido de um produto por um período longo o bastante correlaciona de perto o suficiente com as respostas à pergunta do "muito decepcionado" de Sean Ellis. Isso torna possível aplicar **o mesmo limiar de 40%** à determinação de tração inicial. Maurya registra que consultou Sean Ellis sobre isso e que ele concordou.

O critério, na formulação de Maurya: **você tem tração inicial quando está retendo 40% dos seus usuários ativados, mês após mês.**

**Duas definições que precisam estar escritas antes de você medir:**

1. **O que conta como atividade.** Retenção mede atividade repetida ao longo de um período — então o primeiro passo é definir o que é atividade.
2. **O que conta como atividade *representativa*.** Uma definição mais fiel, para fins de ajuste produto-mercado, **não mede só uso, mas uso representativo**. Todo produto tem um conjunto central de ações que indicam uso contínuo real — escrever posts, no caso de uma plataforma de blog. E uma advertência que muda a conta: **a ação-chave da ativação pode não ser a mesma da retenção.**

A taxa de retenção é calculada **sobre o número de usuários ativados** — não sobre o total de cadastros.

**Ação para a Q10:** escreva as duas definições numa linha cada, antes de olhar qualquer dado. "Usuário ativado = quem completou X. Usuário retido = quem fez Y pelo menos uma vez no mês." Sem essas duas linhas, o percentual que você apresentar não significa nada, e a banca vai perguntar exatamente isso.

---

## 4. Receita e retenção não são a mesma validação

Maurya defende cobrar desde o primeiro dia e considera o preço parte do produto. Mesmo assim, ele é explícito sobre o limite da receita como prova:

**Receita é apenas a primeira forma de validação e, usada sozinha, pode ser um falso positivo como teste de ajuste produto-mercado.** Ele relata casos com os próprios produtos em que **clientes continuavam pagando por um produto que não usavam — nem esporadicamente**. Às vezes porque outra pessoa pagava (a empresa deles); às vezes porque simplesmente esqueceram de cancelar. E há a distração oposta: startups perseguindo o tipo errado de receita — acordos pontuais de licenciamento ou desenvolvimento sob medida.

A ordem, que vale como frase de apresentação:

> **Receita é a primeira forma de validação; retenção é a forma definitiva.**

E o fecho prático: se você oferece um produto de compra única, cobra o valor apropriado e tem boa ativação, **a receita se resolve sozinha**. Se você oferece assinatura, cobra desde o primeiro dia e tem boa retenção, **a receita também se resolve sozinha**.

**Como isso entra no bloco de 5:30 do pitch:** o slide de receita da Q7 não fecha o argumento de tração. Ele mostra que o modelo se sustenta. Quem fecha o argumento é o número de retenção — ou a declaração honesta de que ele ainda não existe.

### A ordem de trabalho, se houver tempo até o Demoday

Maurya descreve a sequência de iteração rumo à tração inicial, e ela cabe nas últimas semanas do semestre:

1. **Revise os indicadores semanalmente** com a equipe inteira, num horário fixo. Identifique primeiro onde está vazando mais.
2. **Priorize as metas e o backlog** contra o que vazou.
3. **Formule hipóteses ousadas.** Nesta fase, evite experimentos de micro-otimização; formule hipóteses grandes, mas **construa a menor coisa possível** para testá-las.
4. **Acrescente ou mate funcionalidades** ao longo do ciclo de vida delas, conforme o impacto.
5. **Acompanhe as coortes de retenção.** O objetivo é ver movimento consistente para cima; do contrário, você está girando em falso.
6. **Quando a retenção se aproximar de 40%, considere rodar o teste de Sean Ellis.**

Note que o teste é o **último** passo, não o primeiro.

---

## 5. O que dizer quando não há número

É a situação mais comum na Q10, e ela tem resposta boa. A resposta não é inventar; é **mudar a unidade de progresso**.

**A unidade que substitui.** Ries propõe a **aprendizagem validada**: não é racionalização depois do fato, nem boa história elaborada para ocultar fracasso. É um método rigoroso para demonstrar progresso quando se está no terreno de extrema incerteza — o **processo de demonstrar empiricamente que uma equipe descobriu verdades valiosas sobre as perspectivas de negócio presentes e futuras**. Ele a defende como mais concreta, mais exata e mais rápida do que prognóstico de mercado ou planejamento empresarial clássico, e como o antídoto principal contra "executar com sucesso um plano que não leva a lugar nenhum".

E o modo correto de pensar produtividade numa startup, segundo ele: **não em termos de quanta coisa está sendo desenvolvida, mas de quanta aprendizagem validada se obtém a partir do esforço.**

**O que evitar, e o nome que a coisa tem.** Ries chama de **métricas de vaidade** os números tradicionais usados para julgar startups: total de usuários cadastrados, total de clientes pagantes, receita bruta. O motivo do nome: eles **dão o quadro mais cor-de-rosa possível**. Você vê um gráfico em forma de taco de hóquei e conclui que há grande progresso.

E ele nomeia também o comportamento associado: **teatro do sucesso** — o trabalho realizado para parecer bem-sucedido. Compra de anúncio de última hora, sobrecarga de canal de distribuição, **demonstrações impressionantes**, numa tentativa desesperada de fazer os números brutos parecerem melhores. A energia investida em teatro do sucesso é energia que poderia ter ajudado a desenvolver o negócio.

O teste que ele aplica para separar uma coisa da outra: um número que não permite dizer **de onde ele veio e o que o causou** é métrica de vaidade. O exemplo dele: 40 mil visitas no mês, um recorde. São 40 mil pessoas novas ou uma pessoa com um navegador muito ativo? Vieram de uma campanha ou de uma nota na imprensa? O que conta como uma visita?

> ⚠️ **A tradução direta para o Demoday.** "Tivemos 300 acessos" é métrica de vaidade. "Doze pessoas da nossa base usaram; oito voltaram na segunda semana; conseguimos falar com as quatro que não voltaram, e três disseram o mesmo motivo" é aprendizagem validada. O segundo enunciado tem números menores e sustenta muito mais pergunta.

### O roteiro de 60 segundos, quando não há tração

Quatro frases, nesta ordem:

1. **Quantos usaram, nominalmente ou por grupo, e por quanto tempo.** Número pequeno dito com precisão.
2. **O que vocês aprenderam com eles que mudou o produto.** Uma mudança concreta, com o antes e o depois.
3. **Qual é o número que vocês vão medir, e a definição dele.** "Retenção = usuário ativado que faz X pelo menos uma vez no mês."
4. **Quando vocês vão medir.** Uma data.

E a frase que enquadra tudo: *"ainda não temos volume suficiente para afirmar tração; temos aprendizado validado, e este é o instrumento com que vamos medir."* Isso é o oposto de fraqueza diante de uma banca de mercado — é a resposta que uma pessoa de mercado reconhece.

---

## 6. Regras para qualquer número no slide

| Regra | Por quê |
|---|---|
| **Todo número tem base declarada** | "40% de 12 pessoas" é honesto; "40%" sozinho não é |
| **Todo número tem período declarado** | Retenção sem janela de tempo não é retenção |
| **Todo número tem definição declarada** | Sobretudo "usuário ativo" e "usuário ativado" |
| **Todo número externo tem fonte, ano e link conferido** | E você **abriu** a fonte |
| **Nenhum número que a equipe não mediu entra** | Se a pergunta "de onde veio esse número?" não tem resposta, tire o número |
| **Percentual pequeno com base pequena vira número absoluto** | "3 de 12" comunica melhor e é mais difícil de contestar do que "25%" |

**Ação:** antes do ensaio final, passe por cada slide e escreva, num papel à parte, a resposta à pergunta *"de onde veio esse número?"* para cada número exibido. Todo número sem resposta sai do slide. É o exercício de 15 minutos que mais protege a apresentação.

---

## Fontes

- **Maurya, Ash**, *Running Lean*, cap. 14 — a origem do termo ajuste produto-mercado (Andy Rachleff; o texto de Marc Andreessen sem orientação de medida), Sean Ellis e a consultoria 12in6, a pergunta exata e as quatro alternativas, o limiar de 40% e sua derivação da comparação entre centenas de startups, as três ressalvas (redação, pesquisa como verificação e não aprendizado, exigência de amostra e segmentação), a limitação de determinar mas não conquistar tração, a distinção entre valor de uma vez e valor recorrente, a transposição do limiar de 40% para retenção com a concordância de Sean Ellis, a relação entre receita e retenção, e a sequência de iteração rumo à tração inicial; apêndice — como definir atividade e atividade representativa, e a base de cálculo da retenção sobre usuários ativados
- **Ries, Eric**, *A startup enxuta*, cap. 3 e 7 — aprendizagem validada como unidade de progresso, produtividade medida por aprendizado e não por produção, métricas de vaidade, teatro do sucesso, e o teste das 40 mil visitas

---

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

# Jornada do Usuário

**Para quê:** mapear o que acontece com o usuário ao longo de um período.
**Quests:** 1, 2, 4 (jornada atual) e 6 (jornada nova) · **Modo:** 🟡 com apoio

## O que é

Mapeamento do que acontece com o usuário ao longo de um período — as etapas, os pontos de contato, o que ele faz, sente e encontra pelo caminho.

## As duas jornadas do Projetão

A disciplina pede a mesma técnica em dois momentos, com propósitos opostos:

**Jornada atual (Q4)** — passo a passo de como ele resolve o problema **hoje**, sem a sua solução. É diagnóstico. Se ela estiver bonita demais, você não observou: jornada real tem espera, retrabalho e gambiarra.

**Jornada nova (Q6)** — como a persona resolve o problema **usando o que vocês propõem**. É projeto. E é o teste mais honesto do MVP: se você não consegue descrever passo a passo, a solução ainda está vaga.

Colocar as duas lado a lado é o slide mais eficiente do pitch da Q10.

## Como montar

1. Defina o recorte temporal — do gatilho até a resolução (ou a desistência).
2. Liste as etapas em ordem, na linguagem do usuário.
3. Para cada etapa: o que ele faz, com quem/o quê interage, quanto tempo leva, o que sente.
4. Marque os **pontos de dor** e os **momentos de decisão** (onde ele poderia desistir ou escolher outra coisa).
5. Some o tempo total. O número costuma surpreender e é ótimo material de pitch.

## Erro comum

Mapear a jornada dentro do seu produto em vez da jornada do problema. A jornada começa antes de o usuário saber que você existe, e frequentemente termina depois que ele fecha o app.

---

## Fontes

- **Stickdorn & Schneider**, *This Is Service Design Thinking* — jornada do usuário e pontos de contato
- **Hanington & Martin**, *Universal Methods of Design* — variações do método (mapa de experiência, blueprint de serviço), que esta ficha não abre
- Páginas `tecnicas/journey`, `MetQ4` e `MetQ6` do site da disciplina — o uso em dois momentos (jornada atual e jornada nova)

---

<!-- 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

---

# 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.