<!-- Projetão · Quest #4 — Oportunidade Escolhida & Organização da Equipe · 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 #4 — Oportunidade Escolhida & Organização da Equipe

> **Objetivo.** Apresentar a oportunidade escolhida e a organização da equipe.

| | |
|---|---|
| **Modo de IA** | 🔴 sem assistência nas conversas de confirmação · 🟡 com apoio no resto — a decisão é da equipe |
| **Milestones** | consolida **Usuário**, **Problema** e **Similares** |
| **Entrega** | uma oportunidade, com evidência; papéis definidos |
| **Erro que mais custa** | escolher por votação, e não por evidência |
| **Natureza** | ⚠️ **checkpoint** — os professores validam aqui, conforme as evidências |

---

## Por que esta quest existe

Ela foi acrescentada quando a metodologia passou de 9 para 10 quests, e o motivo é observável: as equipes escolhiam mal, cedo demais, e descobriam tarde.

**Não é votação.** Escolher por maioria dentro da equipe não vale — e não porque a democracia seja ruim, mas porque a escolha da maioria não é necessariamente validada pelos professores. **Eles vão olhar as evidências.**

A escolha vem do que vocês observaram dos usuários e clientes. Tem de ficar claro:

1. que o problema é **relevante** — porque impacta muita gente, ou porque impacta muito algumas pessoas;
2. que as **soluções atuais não resolvem satisfatoriamente**, e portanto há espaço.

---

## Como escolher: risco, não preferência

### Primeiro, separe incerteza de risco

São coisas diferentes, e confundi-las faz a equipe paralisar diante de "tudo é incerto".

- **Incerteza** — falta de certeza completa: existe mais de uma possibilidade.
- **Risco** — um estado de incerteza em que **alguma das possibilidades envolve perda**, catástrofe ou outro resultado indesejável.

Você pode ser incerto sobre muitas coisas que não são arriscadas. O que qualifica uma incerteza como risco é haver **perda associada**.

E risco se mede combinando **probabilidade** com **perda quantificada**: "40% de chance de o poço sair seco, com perda de R$ 12 milhões" é uma medição de risco. "É arriscado" não é.

Consequência prática na Q4: o risco que você deve atacar primeiro não é o que parece mais assustador — é o que combina probabilidade alta **com** perda alta. Um evento catastrófico de probabilidade ínfima pode esperar.

Detalhamento e as fórmulas em **Decidir sob incerteza — Quest #4** (neste arquivo).

### Depois, ranqueie as oportunidades — nesta ordem

Coloque as 2–3 oportunidades lado a lado. A ordem de peso, da maior para a menor:

| # | Critério | Por quê |
|---|---|---|
| 1 | **Nível de dor do cliente** | Priorize o segmento que mais precisa. A meta é ter um dos seus três problemas como ***must-have*** — não *nice-to-have* |
| 2 | **Facilidade de alcance (canais)** | Construir caminho até o cliente é das partes mais difíceis. Alcance fácil não garante problema válido nem negócio viável, mas **tira você do prédio mais rápido e acelera o aprendizado** — e num semestre isso pesa mais que numa startup |
| 3 | **Preço e margem** | O que se pode cobrar é largamente determinado pelo segmento. Mais margem = menos clientes para se pagar |
| 4 | **Tamanho de mercado** | Grande o bastante **dados os objetivos** do projeto |
| 5 | **Viabilidade técnica** | Por último — e note que é o único critério que a maioria das equipes de computação usa primeiro |

Os três tipos de risco que você está ranqueando: **risco de produto** (acertar o produto), **risco de cliente** (construir caminho até ele), **risco de mercado** (viabilizar o negócio).

> A priorização incorreta de risco é um dos maiores contribuintes de desperdício.

---

## As perguntas da entrega

1. **Qual a oportunidade escolhida?** Por que ela seria a mais relevante? **Quais evidências mostram isso?**
2. **Quem é o cliente e quem é o usuário?** São a mesma pessoa?
3. **Quem é o público mais disposto a interagir com a equipe?** Quem é o **usuário afoito**?
4. **Qual a jornada do usuário?** Passo a passo de como ele resolve o problema **hoje**, sem a sua solução.
5. **Qual o mercado-alvo e o tamanho dele?** Com evidência.
6. **Por que a concorrência não resolve plenamente?**
7. **Quem são as lideranças da equipe e suas funções?**

---

## Cliente ≠ usuário

> **Um cliente é alguém que paga pelo seu produto. Um usuário não.** — Ash Maurya

Regras que acompanham:

- **Divida segmentos amplos em menores.** Você não consegue construir, projetar e posicionar um produto para todo mundo. Até o Facebook começou com um usuário muito específico: alunos de Harvard.
- **Em modelo de dois lados**, comece com um único canvas usando cor ou etiqueta por segmento, e divida só depois.
- **Seus usuários gratuitos não são seus clientes** — ainda.

Dois grupos são segmentos **distintos** quando: suas necessidades justificam oferta distinta; são alcançados por canais diferentes; exigem relacionamento diferente; têm rentabilidade substancialmente diferente; ou pagam por aspectos diferentes da oferta.

---

## Usuário afoito — a escala de dor

O termo técnico é *early adopter*, e há uma definição operacional muito mais útil que "quem gosta de novidade". São clientes visionários que **não só espalham a notícia sobre produtos inacabados e não testados, como também os compram**.

A escala de cinco degraus:

1. O cliente **tem** um problema.
2. O cliente **entende** que tem um problema.
3. O cliente está **ativamente procurando** solução, e tem prazo para achá-la.
4. O problema dói o bastante para o cliente ter **montado uma solução provisória** — a gambiarra.
5. O cliente **comprometeu, ou consegue rapidamente, orçamento** para resolver.

> **O usuário afoito está nos degraus 4 e 5.** Quem está nos degraus de baixo é adotante tardio (*late adopter*), e o feedback dele não serve agora.

Isso conecta direto com a Q2: **quem você viu usando a gambiarra mais elaborada é o seu candidato mais forte** — porque a gambiarra *é* o degrau 4.

Duas ressalvas: usuários afoitos estão em papéis **operacionais**, não em laboratórios de pesquisa ou comitês de avaliação técnica — estes influenciam a compra mas não têm autoridade de adoção. E eles querem falar com quem constrói, não com um vendedor.

Identifique **nominalmente**. "Estudantes universitários" não é usuário afoito; é demografia.

---

## Tamanho de mercado sem inventar número

Duas ferramentas que substituem o chute e o "segundo o IBGE, 1 milhão de pessoas":

**Decomposição de Fermi.** Quebre o número grande em fatores que você consegue estimar. Além de produzir a estimativa, a decomposição mostra **de onde vem a incerteza** — e o fator mais incerto é justamente o que vale a pena medir.

**Faixa calibrada de 90%, não número único.** Em vez de "o mercado é de 1 milhão", diga "entre 400 mil e 1,6 milhão, com 90% de confiança". É mais honesto e mais defensável na banca.

E a notícia boa para quem acha que precisa de 400 respostas: **você precisa de menos dados do que pensa.** As primeiras observações são as de maior retorno em redução de incerteza. Ver **Decidir sob incerteza — Quest #4** (neste arquivo) para a **Regra dos 5** — e o argumento de por que cinco pessoas já dizem muito.

---

## Organização da equipe

Papéis que a disciplina espera ver, cada um com **nome de pessoa ao lado**:

- **Gerente de projeto** — mantém o projeto andando numa direção
- **Líder técnico** — implementação
- **Líder de UX / experiência** — usabilidade, testes com usuário
- **Líder de negócios** — modelo de receita, mercado
- **Relacionamento com usuários e comunidade de testes** — pode acumular, mas precisa ter dono

Três achados que ajudam a dimensionar:

**Tamanho.** A formulação clássica é sete pessoas, mais ou menos duas. Acima de nove, a velocidade **cai**. Os canais de comunicação crescem por n(n−1)/2: cinco pessoas geram 10 canais; nove geram 36. Num levantamento de 491 projetos, grupos de 3 a 7 pessoas exigiram cerca de **um quarto do esforço** de grupos de 9 a 20 para o mesmo trabalho. Regra: erre para o lado pequeno — se a turma impõe equipes grandes, **subdivida em frentes com dono**.

**Um único dono do "quê".** Separe quem decide **o que** deve ser feito de quem cuida de **como** o time trabalha. Duas pessoas decidindo prioridade é a origem mais comum de paralisia.

**Multifuncionalidade.** O time precisa ter todas as habilidades necessárias para completar o projeto — não pode depender de alguém de fora para fechar uma entrega.

---

## Atenção

**As decisões desta quest não são definitivas.** É comum que sejam revistas, e em alguns casos abandonadas em favor de outro projeto. Nenhuma escolha é irreversível.

Mas isso não autoriza escolher de qualquer jeito. **Escolha errada vira aprendizado; escolha impensada, feita só para se livrar da tarefa, vira bola de neve.**

---

## Referências desta quest

| Arquivo | Quando |
|---|---|
| **Decidir sob incerteza — Quest #4** (neste arquivo) | Ao comparar as oportunidades. Incerteza × risco, valor da informação, estimativa calibrada, regra dos 5, Fermi |
| **Usuário afoito — Quest #4** (neste arquivo) | Ao definir com quem falar. A escala de dor, onde encontrar, o que perguntar |
| **Organização da equipe — Quest #4** (neste arquivo) | Ao distribuir papéis. Tamanho, canais de comunicação, os três papéis, conflito |
| **Autodiagnóstico — Quest #4** (neste arquivo) | Antes de entregar |

---

### Técnicas desta quest

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

| Ficha | Para quê |
|---|---|
| **Usuário afoito (*early adopter*)** (neste arquivo) | como reconhecer o usuário afoito |
| **Jornada do Usuário** (neste arquivo) | a jornada atual, sem a sua solução |
| **Lean Innovation** (neste arquivo) | por que priorizar risco em vez de preferência |
| **Brainstorm** (neste arquivo) | gerar alternativas de recorte |

---

## Perguntas frequentes

**"Me sinto perdido na equipe — uns sobrecarregados, outros parados."**
Um dos desafios da disciplina é operar em equipe grande que precisa se auto-gerenciar: ninguém gerencia de fora. Duas coisas resolvem a maior parte disso. **Papéis e responsabilidades claros.** E **colaboração ativa**: mesmo sem entender de design, você pode ajudar a construí-lo. Ninguém é especialista profundo em nada numa startup. Se algo não está sendo feito, faça — na pior hipótese, alguém melhora o que você começou.

**"O ambiente está tóxico, há muito conflito, não me sinto ouvido."**
Conflito e discussão não são o problema — são sinal de que o resto do mundo não pensa como você. O que resolve disputa não é convicção: é teste e evidência. Se você não está sendo ouvido, traga evidência do caminho que propõe — e esteja aberto a estar errado se ela apontar o contrário.

A opinião de qualquer integrante é irrelevante frente às decisões de projeto. Se suas contribuições são opinativas, não ser ouvido é até bom sinal. Se for o oposto — você traz hipótese testada e a equipe ignora em favor de preferência pessoal —, aí talvez seja caso de mudar de grupo.

---

## Bibliografia desta quest

| Obra | O que ela dá para a Q4 |
|---|---|
| **Hubbard — How to Measure Anything** | Incerteza × risco, valor da informação, estimativa calibrada, regra dos 5, Fermi |
| **Maurya — Running Lean** | Priorização por risco, ordem de ranqueamento, cliente × usuário |
| **Blank — The Four Steps to the Epiphany** | O earlyvangelist e a escala de cinco degraus |
| **Osterwalder & Pigneur — Business Model Generation** | Quando dois grupos são segmentos distintos; plataforma multilateral |
| **Sutherland — Scrum** | Tamanho de equipe, canais de comunicação, separação dos papéis |
| **Ries — A startup enxuta** | Bibliografia oficial da quest no site |

---

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

# Autodiagnóstico — Quest #4

Rode isto **dois dias antes** do checkpoint, não na véspera. A Q4 consolida três milestones — **Usuário**, **Problema** e **Similares** — e os professores validam conforme as evidências. Um dia sobrando é o que permite ir a campo tapar um buraco.

Pontue cada milestone de 0 a 5. **Some no fim e leia a régua.**

---

## Rubrica — Usuário

| Nota | Estado |
|---|---|
| 0 | O usuário é uma demografia: "estudantes", "pequenos comerciantes", "professores". |
| 1 | Há um recorte, mas ninguém da equipe falou com ninguém desse recorte. |
| 2 | Houve conversas, mas com quem estava à mão — colegas, parentes, quem já era conhecido. |
| 3 | Cliente e usuário estão distinguidos e nomeados, e a equipe sabe dizer se são a mesma pessoa. |
| 4 | Há pessoas identificadas **nominalmente** no degrau 3 da escala de dor: procuram solução ativamente, com prazo. |
| 5 | Há pelo menos duas pessoas nominalmente identificadas no **degrau 4 ou 5** — com gambiarra observada, registrada com data e local — e todas estão em **papel operacional**, não em papel de avaliação ou consultoria. |

---

## Rubrica — Problema

| Nota | Estado |
|---|---|
| 0 | O problema é a ausência da solução que a equipe queria construir. |
| 1 | O problema está descrito, mas a evidência é a experiência pessoal de alguém da equipe. |
| 2 | Há evidência de campo, mas ela não distingue **fato observado** de **inferência**. |
| 3 | A jornada atual do usuário está mapeada passo a passo, **sem a solução de vocês**. |
| 4 | A relevância está sustentada por um dos dois caminhos: impacta muita gente, **ou** impacta muito algumas pessoas — e há número, com origem declarada, para o caminho escolhido. |
| 5 | O problema aparece entre os três primeiros na **ordenação feita pelos próprios usuários**, e há indício de que é *must-have* e não *nice-to-have*. O custo do problema para o usuário está quantificado — em tempo, dinheiro ou clientes perdidos. |

---

## Rubrica — Similares

| Nota | Estado |
|---|---|
| 0 | "Não existe nada parecido." |
| 1 | Há uma lista de concorrentes diretos, montada por busca na internet. |
| 2 | A lista inclui **alternativas existentes** que não são produtos: planilha, caderno, grupo de mensagens, não fazer nada. |
| 3 | Para cada alternativa existente está registrado **o que ela entrega** e **o que ela deixa de entregar**. |
| 4 | O "não resolve plenamente" está sustentado por fala de usuário, não por avaliação técnica da equipe. |
| 5 | A equipe sabe dizer **por que a alternativa sobrevive** apesar das falhas — o que ela faz bem e vocês teriam de fazer igual ou melhor. Isso é a matéria-prima da curva de valor da Q5. |

---

## Rubrica — Escolha e equipe

| Nota | Estado |
|---|---|
| 0 | A oportunidade foi escolhida por votação ou por preferência técnica. |
| 1 | Há justificativa escrita, mas ela é argumentativa e não cita evidência. |
| 2 | As 2–3 oportunidades foram comparadas, mas só em viabilidade técnica. |
| 3 | A comparação seguiu a ordem de peso: dor, alcance, preço e margem, tamanho, viabilidade técnica. |
| 4 | Cada oportunidade tem **risco medido** — probabilidade e perda quantificada em semanas de equipe —, não apenas adjetivado. |
| 5 | Está calculada a perda de oportunidade esperada de cada alternativa, e as medições cujo custo é menor que ela viraram tarefas com prazo e dono. Os papéis estão distribuídos com **nome de pessoa**, e quem decide **o quê** não é a mesma pessoa que cuida do **como**. |

---

## A régua

| Soma (0–20) | Leitura |
|---|---|
| 0–7 | A escolha ainda é preferência disfarçada. Volte a campo antes do checkpoint. |
| 8–13 | Há material, mas concentrado num milestone só. Olhe qual ficou para trás: quase sempre é **Similares**. |
| 14–17 | Defensável. Prepare-se para a pergunta sobre o milestone de menor nota — ela virá. |
| 18–20 | Pronta. Use o tempo que sobra para melhorar a estimativa de mercado, que é onde a banca costuma insistir. |

---

## Checklist do checkpoint

**As sete perguntas da entrega, respondidas por escrito**

- [ ] Qual a oportunidade escolhida, por que é a mais relevante, e **quais evidências mostram isso**
- [ ] Quem é o cliente e quem é o usuário — e se são a mesma pessoa
- [ ] Quem é o usuário afoito, **nominalmente**, com o degrau e a evidência do degrau
- [ ] A jornada do usuário hoje, passo a passo, sem a solução de vocês
- [ ] Mercado-alvo e tamanho, como **faixa de 90%** com fórmula de decomposição e origem de cada fator
- [ ] Por que a concorrência não resolve plenamente, com fala de usuário
- [ ] Lideranças e funções, com nome ao lado de cada papel

**Higiene da evidência**

- [ ] Toda afirmação sobre o usuário tem data, local e quem observou
- [ ] Fato e inferência estão em colunas separadas
- [ ] Nenhum número aparece sem origem declarada
- [ ] Nenhum número aparece como valor único onde deveria ser faixa
- [ ] Nada que a equipe não observou está escrito como se tivesse observado

**Preparo da defesa**

- [ ] A equipe sabe apontar **qual é o fator mais incerto** da estimativa de mercado, e como pretende medi-lo
- [ ] A equipe sabe dizer o que **descartou** e por quê
- [ ] Uma pessoa está designada para responder cada uma das sete perguntas

---

## Registro de trajetória

As decisões desta quest **não são definitivas** — é comum revê-las, e às vezes abandonar o projeto em favor de outro. Isso só funciona se o caminho ficar registrado; senão, a equipe refaz a mesma discussão dois meses depois. Mantenha um arquivo curto, atualizado a cada decisão, com quatro campos:

| Campo | O que registrar |
|---|---|
| **Data** | Quando a decisão foi tomada |
| **O que foi decidido** | Uma frase |
| **A evidência que sustentou** | Observação, contagem, conversa — com origem |
| **O que faria a equipe voltar atrás** | A observação que mudaria a decisão |

A quarta coluna é a que vale mais: uma decisão sem condição de reversão declarada não é decisão sob incerteza — é aposta que ninguém vai auditar. E é ela que separa as duas situações que o `SKILL.md` distingue: **escolha errada vira aprendizado; escolha impensada, feita para se livrar da tarefa, vira bola de neve.**

Quando uma oportunidade for descartada, registre **por que** na mesma tabela. Duas semanas depois, alguém vai propor exatamente aquela ideia de novo.

---

<!-- referencias/decidir-sob-incerteza.md -->

# Decidir sob incerteza — Quest #4

Abra este arquivo quando a equipe tiver duas ou três oportunidades na mesa e precisar escolher **uma**, com argumento que sobreviva ao checkpoint; e quando precisar apresentar tamanho de mercado sem inventar número.

---

## 1. Incerteza e risco: quatro definições, não duas

Hubbard define os dois termos **e** como se mede cada um. É a segunda metade que a equipe pula, e é ela que resolve a paralisia do "tudo é incerto".

| Termo | Definição |
|---|---|
| **Incerteza** | Falta de certeza completa: existe mais de uma possibilidade. O resultado, estado ou valor verdadeiro não é conhecido. |
| **Medição da incerteza** | Um conjunto de **probabilidades** atribuído a um conjunto de possibilidades. |
| **Risco** | Um estado de incerteza em que **alguma das possibilidades envolve perda**, catástrofe ou outro resultado indesejável. |
| **Medição do risco** | Um conjunto de possibilidades, cada uma com **probabilidade quantificada e perda quantificada**. |

Os exemplos do livro: para incerteza, "há 60% de chance de este mercado mais que dobrar em cinco anos, 30% de chance de crescer a taxa menor e 10% de encolher"; para risco, "há 40% de chance de o poço proposto sair seco, com perda de US$ 12 milhões em custos de perfuração exploratória".

Repare no que essas frases têm e "é arriscado" não tem: **um número de probabilidade e um número de perda**. Enquanto a equipe não escrever a oportunidade nesse formato, não mediu risco — declarou desconforto.

E a definição de medição do livro é igualmente operacional: **uma redução de incerteza, expressa quantitativamente, baseada em uma ou mais observações.** Redução basta; eliminação não é exigida. Mas **precisa haver observação** — reunião não é medição, consenso de equipe também não.

**Acionável:** uma linha por oportunidade, três colunas — *o que pode dar errado* / *chance (%)* / *o que se perde, em semanas de equipe*. Semanas de equipe é a moeda do Projetão; use-a no lugar de reais, que vocês não têm.

---

## 2. Quanto vale medir: perda de oportunidade e valor da informação

| Sigla | Nome | Fórmula |
|---|---|---|
| **OL** | Perda de oportunidade | O custo se você escolher aquele caminho e ele se revelar errado |
| **EOL** | Perda de oportunidade esperada | chance de estar errado × custo de estar errado |
| **EVI** | Valor esperado da informação | EOL antes da medição − EOL depois |
| **EVPI** | Valor esperado da informação perfeita | o **EOL da alternativa que você escolheria** sem medir nada |

A última linha é o atalho: com informação perfeita a EOL cairia a zero, logo o valor de eliminar toda a incerteza é a EOL da sua decisão-padrão. Você calcula o teto do que vale investigar **antes** de investigar.

**O exemplo do livro.** Campanha publicitária: US$ 40 milhões de lucro se funcionar, US$ 5 milhões de perda (o custo da campanha) se falhar, com 40% de chance de fracasso segundo especialistas calibrados.

| | Aprovar | Rejeitar |
|---|---|---|
| Perda de oportunidade | US$ 5 M (custo da campanha) | US$ 40 M (ganho abandonado) |
| **EOL** | 5 × 40% = **US$ 2 M** | 40 × 60% = **US$ 24 M** |

A decisão-padrão é aprovar, por ter a menor EOL. E o valor de eliminar qualquer incerteza sobre o sucesso é **US$ 2 milhões** — não 24, não 40. Gastar US$ 3 milhões numa pesquisa para decidir isso destruiria valor.

Duas leituras do livro: a EOL **é uma expressão de risco** — a solução neutra ao risco, que multiplica chance por tamanho da perda sem ajustar para aversão; e, rodando o cálculo em dezenas de casos de negócio, apenas **uma a quatro variáveis** por caso eram incertas o bastante *e* pesavam o bastante para justificar medição. **A maioria tem valor de informação zero.**

**O mesmo em semanas de equipe.** ⚠️ Exemplo construído; os números foram inventados por mim para demonstrar o procedimento. A oportunidade A depende de integração com terceiros — 6 semanas perdidas se não for liberada, com 30% de chance: EOL = **1,8 semana**. A oportunidade B não depende de terceiros, mas o público é difícil de alcançar — 3 semanas, 50%: EOL = **1,5 semana**.

As EOLs são próximas, e isso já é um achado: **as duas são quase equivalentes em risco**, e a discussão de três horas sobre qual é "mais arriscada" não tinha do que se alimentar. Mas o EVPI de A é 1,8 semana e descobrir se a integração sai custa **um e-mail e dois dias**: custo muito abaixo do valor da informação, logo mede-se antes de decidir.

**Acionável:** escreva a EOL de cada oportunidade em semanas e, ao lado, o **custo de descobrir**, em dias. Toda linha em que descobrir custa menos que a EOL é tarefa da semana. As outras, esqueça: você já sabe o suficiente.

---

## 3. A inversão da medição

> **Em um caso de negócio, o valor econômico de medir uma variável costuma ser inversamente proporcional à atenção de medição que ela normalmente recebe.**

Hubbard chegou ao padrão aplicando o cálculo de valor da informação em projetos de TI, pesquisa e desenvolvimento, logística militar, meio ambiente, capital de risco e expansão de instalações: as variáveis de alto valor eram, repetidamente, **as que o cliente nunca media**. As duas razões que ele aponta: **as pessoas medem o que sabem medir** — é a piada do bêbado que procura o relógio na rua iluminada, embora saiba que o perdeu no beco escuro, "porque a luz é melhor aqui" — e **medem o que tende a produzir boa notícia**.

**Na Q4.** A variável que equipes de computação medem com carinho é a **viabilidade técnica** — última na ordem de ranqueamento do `SKILL.md`. As que ninguém mede: se o público atende ao telefone, se alguém já paga por algo parecido, quanto custa chegar ao primeiro usuário.

**Acionável:** liste o que a equipe já mediu nas Quests 1 a 3 e, ao lado, as três variáveis de maior EOL. Se as listas não se cruzam, você está no meio da inversão — e a segunda lista é a agenda da semana.

---

## 4. Estimativa calibrada de 90%

Uma pessoa é **calibrada** quando acerta 80% das vezes em que diz estar 80% confiante, e assim por diante. A pesquisa citada mostra que quase todo mundo é enviesado, e **a grande maioria é superconfiante**.

| Achado do teste de calibração | Número |
|---|---|
| Pessoas que acertam 5 ou menos de 10 intervalos de 90% | 56% |
| Chance de uma pessoa **realmente calibrada** ter esse desempenho | 1 em 612 |
| Acertos esperados nas questões verdadeiro/falso | 74% |
| Acertos reais | 62% |

Mais da metade erra tanto que, se fosse calibrada, seria azar de 1 em 612. Não é azar; é superconfiança sistemática.

**Por que isso importa na banca.** "O mercado é de 1,2 milhão de pessoas" afirma certeza que a equipe não tem, e a primeira pergunta a desmonta. "Entre 400 mil e 1,6 milhão, com 90% de confiança, e o fator mais incerto é X" afirma o que se sabe **e** o que não se sabe. O livro reporta que a maioria fica quase perfeitamente calibrada após **meio dia de treino**, e que a habilidade transfere de conhecimentos gerais para qualquer área de estimativa.

---

## 5. As quatro técnicas de calibração

O livro é explícito: **nenhuma isolada corrige a superconfiança**; é a combinação que funciona. Quem tentou replicar os workshops e obteve resultado pior invariavelmente deixara de fora alguma delas — em especial a primeira.

**Aposta equivalente.** Escolha entre duas formas de ganhar R$ 1.000: (A) você ganha se o valor verdadeiro estiver dentro dos limites que deu; (B) você gira uma roleta com uma fatia de 90% e outra de 10%, e ganha se cair na grande. Se prefere a roleta, acha que ela tem mais chance de pagar — logo **o intervalo que você deu não é o seu intervalo de 90%**. Para o superconfiante, a correção é **alargar** até as opções ficarem indiferentes; para o subconfiante, estreitar. O livro registra que **fingir apostar dinheiro já melhora significativamente** a avaliação de probabilidades.

**Prós e contras.** Liste um **pró** (por que a estimativa é razoável) e um **contra** (por que ela pode estar superconfiante). O exemplo: sua projeção está em linha com lançamentos de gasto publicitário parecido; mas há incerteza sobre fracassos catastróficos, sucessos descontrolados e crescimento do mercado — e a faixa se reavalia. Pesquisa acadêmica citada mostra que **este método sozinho já melhora a calibração significativamente**.

**Cada limite como binário separado.** Um intervalo de 90% tem 5% acima do teto e 5% abaixo do piso; logo você precisa estar **95% certo** de que o valor é menor que o teto. Se não estiver, suba-o; idem para o piso. Isso combate a **ancoragem** — pensar num número único e somar um "erro" produz faixas estreitas demais.

**Teste da absurdidade.** **Parta de uma faixa absurdamente larga e vá cortando.** Para o custo de uma fábrica de injeção plástica: comece em US$ 1.000 a US$ 10 bilhões; o equipamento sozinho custa US$ 12 milhões, então suba o piso; US$ 1 bilhão é mais que todas as suas outras fábricas somadas, então baixe o teto. A pergunta muda de "que valor eu acho que isso pode ter?" para **"que valores eu sei que são ridículos?"** — e onde o valor deixa de ser absurdo e vira improvável-mas-plausível está a borda do seu conhecimento. É a técnica para quem diz "não tenho como saber isso": **sempre há valores que a pessoa sabe serem absurdos**.

**Acionável:** para cada número que for ao checkpoint, rode as quatro nesta ordem — absurdidade, limites separados, prós e contras, aposta equivalente. Quem não passou pela aposta equivalente não terminou.

---

## 6. A Regra dos 5

> **Há 93,75% de chance de a mediana de uma população estar entre o menor e o maior valor de qualquer amostra aleatória de cinco dessa população.**

A demonstração tem quatro passos. **(1)** A regra estima a **mediana** — metade acima, metade abaixo —, não a média. **(2)** Por definição, a chance de um valor sorteado cair acima da mediana é 50%: é cara ou coroa. **(3)** A mediana só fica fora do intervalo se os cinco valores caírem todos acima ou todos abaixo; cinco caras seguidas é 1 em 32, ou 3,125%, e cinco coroas o mesmo. **(4)** Logo, 100% − (3,125% × 2) = **93,75%**.

A aritmética generaliza para 1 − 2 × (½)ⁿ — o caderno de exercícios de Hubbard propõe exatamente esse cálculo, a "Regra de X", para X de 2 a 10:

| n | 2 | 3 | 4 | **5** | 6 | 7 |
|---|---|---|---|---|---|---|
| Chance | 50% | 75% | 87,5% | **93,75%** | 96,88% | 98,44% |

Do 2 para o 5 ganham-se 44 pontos; do 5 para o 7, 4,7. **É a razão de a quinta conversa valer muito mais que a vigésima.** O livro diz o mesmo: a curva de valor da informação é mais íngreme no começo — as primeiras 100 amostras reduzem muito mais incerteza que as segundas 100.

**Três armadilhas.** A amostra **precisa ser aleatória**: Hubbard tapa os olhos e sorteia nomes da lista de funcionários; entrevistar os cinco colegas do laboratório não carrega os 93,75%. **Vieses continuam existindo** — uma obra temporária pode inflar o tempo de deslocamento de todos, e quem tem o trajeto mais longo pode faltar e não entrar na amostra. E **a regra não serve para escolher entre opções**: o caderno de exercícios traz o gerente que quer usá-la para decidir em qual de doze restaurantes fazer a confraternização — não funciona, porque ela estima a mediana de uma população de valores.

---

## 7. Faixa de 90% sem matemática, para amostras maiores

Com mais de cinco observações, dá para estreitar a faixa sem variância, raiz quadrada nem tabela t: basta **contar para dentro** a partir dos extremos.

| Amostra | 5 | 8 | 11 | 13 | 16 | 18 | 21 | 23 | 26 | 28 | 30 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Use o n-ésimo maior e menor | 1º | 2º | 3º | 4º | 5º | 6º | 7º | 8º | 9º | 10º | 11º |
| Confiança real | 93,8% | 93,0% | 93,5% | 90,8% | 92,3% | 90,4% | 92,2% | 90,7% | 92,4% | 91,3% | 90,1% |

Hubbard calculou a tabela por métodos não paramétricos e conferiu com simulação de Monte Carlo; ela é ligeiramente **conservadora**, porque as confianças reais ficam acima de 90%. Ele recomenda decorar os quatro primeiros tamanhos: **5, 8, 11 e 13**. Duas vantagens sobre a tabela t: **os dois limites são valores que existem nos seus dados** — no exemplo do livro sobre tempo assistindo a reality shows, a tabela t produzia um piso de *menos* 30 minutos, e a tabela sem matemática devolvia 0 a 4 horas; e **quase toda a variância está nos extremos**, já que abaixo de 12 observações ela é praticamente só o maior e o menor valor.

---

## 8. Decomposição de Fermi para tamanho de mercado

Fermi pedia aos alunos que estimassem **quantos afinadores de piano há em Chicago**. Eles diziam não ter como saber; ele então pedia estimativas mais fáceis: população da cidade (pouco mais de 3 milhões nas décadas de 1930 a 1950), pessoas por domicílio (2 ou 3), fração de domicílios com piano afinado regularmente (não mais que 1 em 10, não menos que 1 em 30), frequência de afinação (talvez 1 por ano), pianos por afinador por dia (4 ou 5) e dias trabalhados por ano (uns 250).

```
Afinadores = população ÷ pessoas por domicílio
           × fração de domicílios com piano afinado
           × afinações por ano
           ÷ (afinações por afinador por dia × dias úteis por ano)
```

Conforme os valores, sai entre 20 e 200, com cerca de 50 sendo comum — sempre mais perto do real do que os alunos teriam chutado. Duas observações do livro: **a decomposição ainda não é medição**, porque não se baseia em observação nova; e **o ganho principal não é o número, é saber de onde vem a incerteza** — a maior fonte aponta a medição que mais reduz incerteza.

O caso de mercado do livro é o de Chuck McKay avaliando abrir uma corretora de seguros em Wichita Falls, Texas, só com buscas na internet: 62.172 carros; prêmio médio anual no Texas de US$ 837,40; como o seguro é obrigatório, receita bruta local de US$ 52.062.833 por ano; comissão média de 12%, logo US$ 6.247.540 de bolo; 38 corretoras na cidade; dividindo, **US$ 164.409 por corretora ao ano** — antes do custo de escritório, e numa cidade que encolhera de 104.197 habitantes em 2000 para 99.846 em 2005. Conclusão: uma corretora nova não teria boa chance de ser lucrativa. Note a forma do argumento: **o resultado é uma recomendação de não entrar**, vinda de aritmética com números públicos.

### Um exemplo construído, no contexto brasileiro

⚠️ **Exemplo construído.** Todos os números abaixo foram inventados por mim para demonstrar o procedimento. **Nenhum é dado real, nenhum veio de fonte, e nenhum pode ser citado na entrega.** Copiem a estrutura, não os valores.

Uma equipe quer atender salões de beleza de bairro que agendam por aplicativo de mensagem e perdem receita com furo de horário. Ninguém publica esse número:

```
Salões no alvo = ruas comerciais na área atendível
               × salões por rua comercial
               × fração que agenda por mensagem e tem furo
```

| Fator | Faixa de 90% | De onde veio | Teto ÷ piso |
|---|---|---|---|
| Ruas comerciais na área | 400 a 900 | contagem no mapa, com absurdidade | 2,3 |
| Salões por rua comercial | 0,5 a 2 | **nada ainda** | 4,0 |
| Fração com agendamento por mensagem e furo | 0,3 a 0,7 | impressão das Quests 1–2 | 2,3 |
| Mensalidade suportável (R$) | 30 a 120 | **nada ainda** | 4,0 |

Multiplicando pisos e tetos: **60 a 1.260 salões no alvo**, e receita anual potencial entre R$ 21,6 mil e R$ 1,81 milhão. A faixa é enorme de propósito — ela é honesta. E a coluna da direita diz onde medir: **"salões por rua" e "mensalidade suportável" são os mais incertos**, com fator 4 entre teto e piso. O primeiro custa uma tarde — sorteiem cinco ruas, contem, apliquem a Regra dos 5. O segundo custa cinco conversas.

⚠️ **Sobre multiplicar extremos.** Multiplicar pisos entre si e tetos entre si produz uma faixa **mais larga** que a de 90% verdadeira do produto, porque é improvável que todos os fatores estejam simultaneamente no piso. A agregação correta, no livro, é por **simulação de Monte Carlo**. Para a Q4 multiplicar extremos serve — o erro é para o lado conservador, e vocês devem dizer isso ao apresentar, em vez de deixar a banca descobrir.

**Acionável:** a resposta à pergunta 5 da quest tem três peças: a **fórmula da decomposição**, a **tabela de fatores com faixas e origem de cada uma**, e **qual fator vocês vão medir em seguida, e como**. Um número solto não passa.

---

## Fontes

- **Hubbard, Douglas W.**, *How to Measure Anything* — incerteza, risco e suas medições; definição de medição; OL, EOL, EVI e EVPI com o exemplo da campanha; a inversão da medição; teste de calibração e seus percentuais; aposta equivalente, prós e contras, limites binários e teste da absurdidade; Regra dos 5 e sua demonstração; tabela de 90% sem matemática; decomposição de Fermi, os afinadores de Chicago e a corretora de Wichita Falls; Monte Carlo para agregar faixas.
- **Hubbard, Douglas W.**, *How to Measure Anything Workbook* — o exercício da "Regra de X"; a limitação da Regra dos 5 em problemas de seleção.
- Os dois exemplos marcados como **construídos** são meus, escritos para demonstrar procedimento. Não são dados.

---

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

# Organização da equipe — Quest #4

Abra este arquivo ao responder a pergunta 7 da entrega — "quem são as lideranças da equipe e suas funções?" — e sempre que a equipe travar por disputa de prioridade, por gente parada ou por reunião que não acaba.

O `SKILL.md` dá os papéis que a disciplina espera. Aqui está de onde vêm os números, o que separa quem decide **o quê** de quem cuida do **como**, o que caracteriza um time excelente na pesquisa, e o que fazer quando o tamanho da equipe é imposto de fora.

---

## 1. Tamanho: por que sete, mais ou menos dois

A formulação clássica é **sete pessoas, mais ou menos duas**. Sutherland relata ter visto times de três funcionando em alto nível, e registra o achado contraintuitivo: **acima de nove pessoas, a velocidade do time cai**. Mais gente faz o time andar mais devagar.

### As duas evidências

**A lei de Brooks.** Formulada por Fred Brooks em 1975, em *The Mythical Man-Month*: **"acrescentar mão de obra a um projeto de software atrasado o atrasa ainda mais."**

**O levantamento de Putnam.** Lawrence Putnam dedicou a carreira a estudar quanto tempo as coisas levam para ser feitas e por quê. Seus dados mostravam repetidamente que projetos com vinte ou mais pessoas usavam mais esforço que os de cinco ou menos — e não um pouco mais: **um time grande usava cerca de cinco vezes o número de horas de um time pequeno.** Em meados dos anos 1990, ele estudou **491 projetos de porte médio** em centenas de empresas diferentes, todos exigindo criação de produto ou funcionalidade nova (não reaproveitamento de versão anterior). Separando por tamanho de time, o padrão apareceu na hora: passando de oito pessoas, os times demoravam dramaticamente mais. **Grupos de 3 a 7 pessoas exigiram cerca de 25% do esforço de grupos de 9 a 20 para produzir o mesmo trabalho.**

### As duas causas

Brooks identificou duas razões para o efeito. A primeira é o tempo de colocar gente nova a par — que atrasa todo mundo enquanto acontece. A segunda tem a ver com o limite físico do que o cérebro consegue processar.

**Os canais de comunicação crescem por n(n−1)/2.**

| Pessoas | Canais |
|---|---|
| 5 | 10 |
| 6 | 15 |
| 7 | 21 |
| 8 | 28 |
| 9 | 36 |
| 10 | 45 |

E há um limite duro do outro lado. Sutherland registra que o clássico estudo de George Miller, de 1956, dizia que a memória de curto prazo retém sete itens — mas que pesquisa posterior o refutou. Em 2001, **Nelson Cowan**, da Universidade do Missouri, revisou a literatura e concluiu que o número é **quatro**. O exemplo do livro: dê a alguém a sequência de doze letras `fbicbsibmirs`; a pessoa lembra de umas quatro — a menos que perceba que dá para agrupá-las em siglas conhecidas (FBI, CBS, IBM, IRS). Amarrar em memória de longo prazo aumenta a capacidade; a parte consciente, que foca, segura cerca de quatro itens distintos.

### O que acontece quando o time passa do ponto

Sutherland descreve o desenrolar, e ele é reconhecível em turma de Projetão:

- todo mundo deixa de saber o que todo mundo está fazendo;
- o time **se quebra social e funcionalmente em subgrupos que passam a trabalhar com propósitos cruzados**;
- **a multifuncionalidade se perde**;
- **reuniões que levavam minutos passam a levar horas**.

**Acionável:** conte os canais da sua equipe antes de discutir processo. Uma equipe de nove tem 36 canais; nenhuma ferramenta de gestão consegue compensar isso. A resposta não é uma reunião a mais — é reduzir o número de pessoas que precisam se sincronizar entre si.

---

## 2. Quem decide o quê, e quem cuida do como

Este é o ponto que resolve mais paralisia por linha escrita.

O Scrum tem **três papéis**: quem faz o trabalho (o time), quem ajuda o time a descobrir como trabalhar melhor (o Scrum Master), e quem decide **qual** trabalho deve ser feito (o Product Owner). O dono do produto é dono da lista de trabalho — do que está nela e, **mais importante, da ordem em que está**.

A origem da separação é reveladora. Sutherland se inspirou no **Engenheiro-Chefe da Toyota**, responsável por uma linha inteira de produto (o Corolla, o Camry), que precisa mobilizar grupos especializados sem ter autoridade para mandar: tem de persuadir, convencer e demonstrar que o seu caminho é o melhor. Sutherland observa que **esse papel costuma exigir alguém com trinta anos de experiência** — e que pouquíssimas pessoas têm essa combinação. Por isso ele **dividiu o papel em dois: o Scrum Master ficou com o "como" e o Product Owner com o "quê"**.

### As quatro exigências do dono do "quê"

| # | Exigência | O que significa na prática |
|---|---|---|
| 1 | **Conhecer o domínio** | Entender o processo que o time executa bem o bastante para saber o que dá e o que **não** dá para fazer; e conhecer o mercado bem o bastante para saber o que faz diferença. |
| 2 | **Ter poder de decidir** | Assim como a gerência não deve interferir no time, o dono do produto precisa de margem para decidir a visão e o caminho, e para **se manter firme** sob pressão de vários interessados. Responde pelos resultados, mas deixa o time decidir como. |
| 3 | **Estar disponível** | Precisa ser confiável, consistente e acessível. Sem acesso a ele, o time não sabe o que fazer nem em que ordem. **É por isso que Sutherland raramente recomenda que um alto executivo seja o dono do produto: falta tempo.** |
| 4 | **Responder por valor** | O que é "valor" varia — receita, número de sucessos, atendimento a um público. O essencial é **decidir qual é a medida de valor** e cobrar dele mais dela. |

Sutherland acrescenta que o primeiro dono de produto que ele nomeou não veio da engenharia, e sim do marketing de produto: alguém que conhecia o produto **do ponto de vista de quem o usa**, e não do ponto de vista técnico.

⚠️ **A tradução para o Projetão.** A exigência 3 é a que mais derruba equipes: elege-se dono do produto a pessoa mais ocupada, que também é a líder técnica, que também faz estágio. O papel exige disponibilidade, não prestígio. E a exigência 2 tem um corolário que o `SKILL.md` enuncia: **duas pessoas decidindo prioridade é a origem mais comum de paralisia.** O que decide não é quem tem razão — é que só uma pessoa pode ordenar a lista.

**Acionável:** na entrega, escreva quem é o dono do "quê" e quem é o dono do "como", com nome. Se a mesma pessoa aparecer nos dois, a equipe não fez a separação.

---

## 3. O que caracteriza um time excelente

### Os três atributos da pesquisa original

Takeuchi e Nonaka, no artigo que deu origem ao Scrum, descreveram as características dos times que observaram nas melhores empresas do mundo — entre elas Honda, Fuji-Xerox, 3M e Hewlett-Packard:

| Atributo | O que significa |
|---|---|
| **Transcendente** | Têm um senso de propósito além do ordinário. A própria decisão de não ser mediano, e sim excelente, muda como se veem e o que se julgam capazes de fazer. |
| **Autônomo** | São auto-organizados e autogeridos: têm o poder de decidir como fazem o trabalho, e poder para que essas decisões valham. |
| **Multifuncional** | Têm **todas as habilidades necessárias para completar o projeto** — planejamento, projeto, produção, venda, distribuição —, e essas habilidades se alimentam mutuamente. |

Sutherland resume os três em uma linha do sumário do capítulo: **times excelentes são multifuncionais, autônomos e empoderados, com um propósito transcendente.**

A multifuncionalidade é o atributo mais operacional dos três para a Q4: se a equipe precisa de alguém de fora para fechar uma entrega, ela não é multifuncional, e cada entrega vai depender da agenda de terceiros.

### Interdisciplinar não é o mesmo que multidisciplinar

Brown faz uma distinção que muda o comportamento em reunião:

- Num time **multidisciplinar**, cada pessoa vira **advogada da própria especialidade técnica**, e o projeto vira uma negociação prolongada entre elas — que provavelmente termina num **compromisso cinzento**.
- Num time **interdisciplinar**, **as ideias têm propriedade coletiva** e todo mundo assume responsabilidade por elas.

O que permite a segunda forma é o que Brown chama de pessoa em **"T"** — termo popularizado pela McKinsey. O traço vertical é a profundidade numa habilidade que permita contribuir de forma tangível para o resultado. O traço horizontal é a **capacidade e a disposição** de colaborar através das disciplinas. Brown observa que juntar diversidade de formações exige paciência, porque é preciso encontrar pessoas **seguras o bastante da própria especialidade para irem além dela**.

⚠️ **É esta a leitura correta da pergunta frequente do `SKILL.md`** — "mesmo sem entender de design, você pode ajudar a construí-lo". Não é apelo à boa vontade: é o traço horizontal do T. Um time em que cada pessoa só faz o que está no seu rótulo produz o compromisso cinzento.

### As três competências mínimas

Maurya define o time de problema/solução por competências, não por cargos, e diz que o time ideal nessa fase tem **duas ou três pessoas**:

| Competência | O que abrange |
|---|---|
| **Desenvolvimento** | Capacidade de construir, com experiência prévia de ter construído coisas e domínio da tecnologia escolhida. |
| **Design** | Estética **e** usabilidade. Um produto não é uma coleção de funcionalidades, e sim uma coleção de fluxos de uso. |
| **Marketing** | "Todo o resto." Escrita, comunicação, e entendimento de métricas, preço e posicionamento. |

Ele acrescenta duas advertências. A primeira: **desconfie de terceirizar qualquer uma das três** — um protótipo inicial até dá, mas ficar refém da agenda de outra pessoa limita a capacidade de iterar e aprender. A segunda é categórica:

> **A única coisa que você nunca deve terceirizar é aprender sobre os clientes.**

---

## 4. Quando a turma impõe equipe grande

O Projetão trabalha com equipes maiores que sete. Isso não invalida os números da seção 1 — significa que a equipe tem de administrar as consequências deles conscientemente.

A saída que aparece nas duas fontes é a mesma: **times pequenos dentro de um time grande, com dono declarado em cada frente.**

Brown descreve o padrão: acaba-se com um time grande em favor de **vários pequenos**. É comum ver times criativos grandes, mas **quase sempre na fase de implementação**; a fase de inspiração pede um grupo pequeno e focado, cujo trabalho é estabelecer o enquadramento geral. O exemplo dele: quando o projetista-chefe Tom Matano apresentou o conceito do Mazda Miata à direção, em agosto de 1984, estava acompanhado de **dois outros projetistas, um planejador de produto e dois engenheiros** — seis pessoas. Quando o projeto se aproximou da conclusão, o time tinha **trinta ou quarenta**. O mesmo vale, ele observa, para qualquer grande projeto de arquitetura, software ou entretenimento: um núcleo pequeno define o conceito, e "os exércitos" chegam depois.

Sutherland, do lado oposto, dá a regra de bolso: **erre para o lado pequeno.**

**Como aplicar na Q4:**

1. Defina **frentes**, não cargos decorativos. Cada frente tem no máximo três ou quatro pessoas e **um nome de dono**.
2. **Uma única pessoa ordena a lista de trabalho** do projeto inteiro, atravessando as frentes (seção 2).
3. Não replique a decisão de prioridade dentro de cada frente. Frente decide **como**; a ordem do **quê** vem de fora.
4. Meça o efeito pelo sintoma certo: se as reuniões gerais voltaram a durar horas, os canais venceram a estrutura, e é preciso reduzir o que precisa ser sincronizado — não aumentar a frequência das reuniões.

---

## 5. Conflito: como resolver sem culpar pessoa

Sutherland dedica um trecho longo ao **erro fundamental de atribuição**: a tendência de explicar o comportamento dos outros pelo caráter deles e o nosso pela situação. Quando somos nós, enxergamos bem os fatores situacionais que nos levaram até ali — e, diz ele, quando falamos de nós mesmos, estamos absolutamente certos. O erro é usar o outro critério para os outros.

O exemplo mais direto que ele traz é um experimento feito num seminário teológico no início dos anos 1970 (o livro não nomeia os autores). Os participantes foram informados de que tinham de dar um sermão do outro lado do campus. A alguns disseram que precisavam se apressar, porque já estavam atrasados e havia gente esperando; a outros, não. No caminho, cada um passou por alguém gemendo por socorro numa porta. **Entre os que foram apressados, 10% pararam para ajudar.** Seminaristas.

A conclusão que o livro tira, e que serve como protocolo de conflito de equipe:

> **Culpa é burrice. Não procure gente ruim; procure sistemas ruins — os que incentivam mau comportamento e recompensam mau desempenho.**

Em vez de procurar um culpado, o Scrum examina o sistema que produziu a falha e o conserta. Em outra passagem, Sutherland enuncia a mesma regra de outro jeito: **quando você estiver cercado de gente insuportável, não procure pessoas ruins; procure sistemas ruins que as recompensam por agir assim.**

### O protocolo, para a Q4

| Sintoma | Pergunta errada | Pergunta certa |
|---|---|---|
| Alguém não entregou | "Por que fulano não fez?" | Que parte do nosso jeito de trabalhar tornou fácil não fazer? |
| Uns sobrecarregados, outros parados | "Quem está de corpo mole?" | Onde falta dono declarado de frente? Onde a fila de trabalho não é visível para todos? |
| A mesma discussão volta toda semana | "Quem está certo?" | Que evidência decidiria isso, e quanto custa consegui-la? |

A última linha é a regra da disciplina, e ela vem direto da lógica das quests: **o que resolve disputa não é convicção, é teste e evidência.** Se você não está sendo ouvido, traga evidência do caminho que propõe — e esteja aberto a estar errado se ela apontar o contrário. Vale notar o corolário desconfortável: se as suas contribuições são opinativas, não ser ouvido é sinal de que a equipe está funcionando.

**Modo de IA.** 🟡 com apoio. A IA pode reformular um conflito de pessoa em conflito de sistema, listar que evidência decidiria a disputa e apontar onde falta dono — não pode arbitrar a disputa nem decidir a prioridade. Essa decisão é de uma pessoa nomeada.

---

## Fontes

- **Sutherland, Jeff**, *Scrum: The Art of Doing Twice the Work in Half the Time* — sete mais ou menos dois e a queda de velocidade acima de nove; a lei de Brooks (1975); o levantamento de Putnam com 491 projetos e a proporção de 25% de esforço entre grupos de 3–7 e de 9–20; a fórmula n(n−1)/2 e a tabela de canais; Miller (1956) refutado por Cowan (2001) e o limite de quatro itens; a degradação de times grandes; os três papéis e a divisão "Scrum Master fica com o como, Product Owner com o quê", inspirada no Engenheiro-Chefe da Toyota; as quatro exigências do dono do produto; os três atributos de Takeuchi e Nonaka; o erro fundamental de atribuição, o experimento do seminário teológico e a regra de procurar sistemas ruins, não pessoas ruins.
- **Brown, Tim**, *Change by Design* — a distinção entre time multidisciplinar e interdisciplinar; a pessoa em "T", termo popularizado pela McKinsey; o padrão de vários times pequenos no lugar de um grande, e o exemplo do Mazda Miata (seis pessoas na concepção, trinta ou quarenta na conclusão).
- **Maurya, Ash**, *Running Lean* — o time de problema/solução de duas ou três pessoas; as três competências mínimas (desenvolvimento, design, marketing); as advertências sobre terceirização e sobre nunca terceirizar o aprendizado sobre clientes.
- As traduções para o contexto da disciplina marcadas com ⚠️ e o protocolo de conflito da seção 5 são leituras minhas sobre as fontes citadas.

---

<!-- referencias/usuario-afoito.md -->

# Usuário afoito — Quest #4

Abra este arquivo ao responder a pergunta 3 da entrega — "quem é o público mais disposto a interagir com a equipe?" — e antes de marcar a primeira rodada de conversas depois do checkpoint.

O `SKILL.md` dá a escala de cinco degraus. Aqui está o que caracteriza cada degrau na fala da pessoa, onde encontrar quem está nos degraus de cima, o que perguntar quando encontrar, e por que a gambiarra que vocês viram na Q2 é o atalho.

---

## 1. De onde vem o termo, e por que ele não é "quem gosta de novidade"

Blank precisou de uma palavra nova. Entusiastas que espalham a boa notícia sobre um produto já se chamavam evangelistas; faltava nome para o cliente visionário que **não só espalha a notícia sobre produtos inacabados e não testados como também os compra**. Daí *earlyvangelist* — em português, **usuário afoito**.

A razão de existir da categoria é econômica, e vale trazer para o Projetão sem adaptação: **nenhuma equipe consegue construir, no primeiro ciclo, um produto com todas as funcionalidades que um cliente de mercado de massa precisa.** O produto ficaria pronto tarde demais e já obsoleto. A saída é construir de forma incremental para um grupo pequeno de clientes iniciais que compraram a visão, e usar o retorno deles para definir o que vem depois.

Num semestre de 14 semanas, isso deixa de ser conselho e vira restrição.

---

## 2. Os cinco degraus, na fala da pessoa

Blank constrói a escala com um exemplo único: um banco cuja fila dá a volta no quarteirão às sextas-feiras, e uma equipe cujo produto reduziria a espera para 10 minutos. Cada degrau é uma resposta diferente do presidente do banco.

| Degrau | O que caracteriza | Como soa na conversa | O que fazer |
|---|---|---|---|
| **1. Tem o problema** | O problema existe, mas a pessoa não o reconhece. **Necessidade latente.** | *"Que problema?"* | Não é cliente nos dois primeiros anos de vida do produto, e **o retorno dele sobre necessidade de produto é inútil**. Agradeça e siga. |
| **2. Entende que tem o problema** | Reconhece, se incomoda, mas nunca se moveu além de disfarçar o sintoma. **Ainda necessidade latente** — em Blank, latente cobre "tem o problema" *e* "tem o problema e sabe que tem". | *"Sim, é um problema terrível. Me sinto mal, distribuo copos d'água para quem está na fila nos dias mais quentes."* | Dá bom retorno **sobre o tipo de problema**. Não estará na primeira fila para comprar. Provavelmente vende-se para ele depois, com produto de mercado. |
| **3. Procura ativamente, com prazo** | Procura solução de verdade, e já **visualizou** o que quer: com que integra, quanto pode custar, quando precisa. **Necessidade ativa.** | *"Estamos perdendo mais de US$ 500 mil por ano. Procuro software que corte 70% do tempo de processamento, tem de integrar com o Oracle, custar menos de US$ 150 mil e chegar em seis meses."* | Está esquentando. Ainda não é o alvo. |
| **4. Montou uma gambiarra** | A dor foi grande o bastante para a pessoa construir uma solução provisória com o que tinha à mão. | *"Não achei um único pacote que resolvesse, então pedi ao meu setor de TI para fazer. Eles emendaram uma solução, mas ela vive travando na mão dos caixas."* | **Alvo.** |
| **5. Tem, ou consegue rápido, orçamento** | Além da gambiarra, há dinheiro reservado ou mobilizável. | *"Se aparecesse um fornecedor que resolvesse isso, eu gastaria com ele os US$ 500 mil que tenho orçados."* | **Alvo.** |

Os três estágios de Blank — latente, ativa, visão — mapeiam assim: **latente** nos degraus 1 e 2, **ativa** no 3, **visão** no 4 e no 5. É a mesma escala descrita em **Quem entrevistar — Quest #2** (**Quem entrevistar — Quest #2** (projetao-ufpe.vercel.app/baixar/colar/projetao-02.md)), vista pelo lado do comportamento em vez do lado do reconhecimento.

> **O usuário afoito está nos degraus 4 e 5.** Nos degraus de baixo está o *late adopter* — o adotante tardio —, e o retorno dele não serve agora.

Blank é explícito sobre o degrau 4 valer tanto em contexto corporativo quanto de consumo: pode ser um setor de TI que emendou um sistema, ou alguém que em casa **prendeu com fita um garfo, uma lâmpada e um aspirador de pó**. A escala é a mesma; só mudam os zeros.

**A conexão com a Q2 é direta e é o atalho da quest.** O degrau 4 *é* a gambiarra. Quem vocês viram, nas Quests 1 e 2, mantendo a planilha paralela, o caderno ao lado do sistema, o grupo de mensagens que substitui o processo oficial — essa pessoa já está no degrau 4 por definição. **Não é preciso procurar usuário afoito do zero: é preciso voltar à lista de gambiarras e ordenar por elaboração.** Quanto mais trabalho a pessoa teve para montar a gambiarra, mais alto o degrau.

---

## 3. Por que eles estão em papéis operacionais

Esta é a ressalva que Blank marca como importante, e é a que mais custa a equipes de computação.

Muitos fundadores acham que o usuário afoito está no laboratório de pesquisa e desenvolvimento, no grupo de avaliação técnica do cliente, ou — em produto de consumo — no laboratório de testes de produtos novos, onde o trabalho da pessoa é justamente avaliar coisas novas.

**Não são esses.** Blank diz que às vezes eles são influenciadores críticos numa compra, mas **não têm papel operacional no dia a dia e não têm autoridade para garantir adoção e implantação**. O usuário afoito é quem está em papel operacional, tem o problema, procurou solução, tentou resolver e tem orçamento.

**A tradução para o Projetão.** O professor da área, o coordenador do laboratório, o colega que "manja do assunto" e o especialista que a equipe conhece são todos influenciadores. Eles opinam bem e não adotam nada. O usuário afoito é a pessoa que **executa a tarefa hoje** e cuja semana melhora ou piora conforme o problema seja resolvido.

Segunda ressalva do livro, igualmente prática: usuários afoitos **não querem falar com vendedor**. Querem ver e ouvir os fundadores e a equipe técnica. Numa equipe de Projetão isso é uma vantagem — vocês são exatamente quem eles topam receber. Vá quem constrói.

---

## 4. Onde encontrar

Blank descreve um procedimento numérico, e o número tem função: ele existe para a equipe não se contentar com as três pessoas fáceis.

**Monte uma lista de 50 nomes.** Fontes que ele cita: redes sociais, amigos, investidores, fundadores, advogados, recrutadores, revistas do setor, livros de referência de negócios, contadores. Nessa fase, **cargo e nível hierárquico são irrelevantes**; e em produto de consumo, se a pessoa tem hoje algum interesse no produto também é irrelevante. O que importa é quem lhe dará algum tempo e se encaixa, mesmo folgadamente, no perfil que vocês hipotetizaram.

**Monte em paralelo uma lista de inovadores.** São empresas, setores ou pessoas do campo que são inteligentes, respeitadas e costumam estar à frente do assunto. Em produto de consumo, pode ser o "fanático por novidade" a quem todo mundo pede conselho. Serve para duas coisas: encontrar quem "entende" ideias novas, e formar lista de conselheiros e influenciadores.

**Os números do contato.** Blank prescreve **10 telefonemas por dia**, até a agenda ter três visitas por dia. Como regra prática, **50 ligações rendem de 5 a 10 visitas marcadas**. Habitue-se a ouvir não — e sempre pergunte: *"se você está sem tempo, com quem eu deveria falar?"*

**Suba a cadeia alimentar da expertise.** A pergunta que Blank repete em todo contato é: **"quem é a pessoa mais inteligente que você conhece?"** O objetivo do primeiro surto de ligações não é só falar com quem está na lista; é usar cada contato para chegar ao seguinte.

⚠️ **Ajuste de escala para o semestre.** 50 nomes e 10 ligações por dia é o ritmo de uma startup em tempo integral. Numa equipe de Projetão com cinco a nove pessoas, **50 nomes divididos entre os integrantes é uma tarde de trabalho**, e mantém a proporção do método. O que não se deve ajustar é a **taxa de conversão**: se a equipe montou uma lista de 8 nomes, deve esperar 1 visita — e isso não é evidência de nada.

---

## 5. O que perguntar

### A apresentação do problema

Blank chama de *problem presentation*, e a diferença em relação a uma apresentação de produto é o objetivo: ela **não foi feita para convencer o cliente; foi feita para extrair informação dele**.

Em contexto corporativo, cabe em **um slide de três colunas**. Em conversa com consumidor, onde slide seria estranho, um papel serve.

| Coluna 1 | Coluna 2 | Coluna 3 |
|---|---|---|
| Os problemas, como vocês os entendem | Como se resolve isso hoje | A solução de vocês — a ideia grande, **não a lista de funcionalidades** |

O procedimento é uma sequência de **pausas**:

1. Mostre a coluna 1. **Pare.** Pergunte o que a pessoa acha que são os problemas, o que está faltando na lista, e como ela **ordenaria** os problemas.
2. Se ela concordar, peça que explique **por que** acha importante resolver. E pergunte, casualmente: *"quanto esse problema custa para você hoje — em receita perdida, clientes perdidos, tempo, irritação?"*
3. Mostre a coluna 2. **Pare.** Pergunte quais são as soluções atuais, se falta alguma, e como ela ordenaria a viabilidade delas.
4. Ainda na coluna 2, pergunte: **"quem mais tem esse problema?"** Outras unidades? Outras pessoas na mesma empresa? Outros no setor? Outros com o mesmo cargo?
5. Mostre a coluna 3. **Pare e observe a reação.** A pessoa entende as palavras? Diz "ah, se vocês fizerem isso, meu problema acaba"? Ou diz "como assim?" e continua sem entender depois de vinte minutos de explicação?

A pergunta 4 tem peso desproporcional: Blank escreve que **um conjunto de pessoas com problemas em comum equivale a uma proposta de valor em comum**. É literalmente a matéria-prima da Q5.

> **Não tente convencer o cliente de que ele tem os problemas que você descreve. Ele é quem tem o talão de cheques — você quer que ele convença você.**

E se o cliente disser que as questões que vocês achavam importantes não são: Blank insiste que isso é **um dado ótimo**, não um fracasso. Pode não ser o que se queria ouvir, mas é excelente saber disso cedo.

### O entendimento em profundidade

Depois da apresentação do problema, o objetivo muda: entender como a vida ou o trabalho da pessoa realmente funciona. As perguntas que Blank lista:

- Como o fluxo de trabalho acontece de fato? A tarefa é feita isoladamente? Se não, com quais outras áreas ou pessoas ela interage?
- Que outros produtos a pessoa usa?
- O problema é só dela, ou outros na organização compartilham? Dá para quantificar o impacto — em dinheiro, tempo, custo — na organização inteira?
- O que faria a pessoa **mudar o jeito atual de fazer**? Preço? Funcionalidade? Um novo padrão?
- *"Se você tivesse um produto assim [descrito em termos conceituais], que porcentagem do seu tempo você passaria usando? Quão crítico ele seria? Resolveria a dor que você mencionou? Quais seriam as barreiras para adotar?"*
- Como a pessoa **fica sabendo de produtos novos**? Quem ela lê e respeita?
- Essa pessoa pode ajudar de novo? Numa próxima rodada? Como conselheira? Indicando outros?

### A regra das três coisas

Depois de algumas conversas, as respostas embaralham. Blank recomenda levar as hipóteses escritas e, **antes de cada conversa, reduzir a lista a "quais são as três coisas que preciso aprender antes de sair daqui?"**. Garanta essas três. Conforme forem se confirmando, troque as perguntas.

**Modo de IA.** 🔴 sem assistência na conversa: quem fala com a pessoa é a equipe, e a IA não escreve resposta de usuário. 🟡 com apoio antes e depois: use a IA para criticar o roteiro de três colunas, apontar perguntas que induzem resposta, e organizar as notas depois — não para gerar as conclusões.

---

## 6. Identifique nominalmente

O critério de aprovação da pergunta 3 da entrega é simples: **"estudantes universitários" não é usuário afoito; é demografia.** Uma resposta aceitável tem nome, papel operacional, o degrau em que a pessoa está e a evidência do degrau.

Formato sugerido:

| Nome | Papel operacional | Degrau | Evidência do degrau | Contato conseguido por |
|---|---|---|---|---|
| | | 4 ou 5 | a gambiarra observada, com data e local | |

Se nenhuma linha da tabela chega ao degrau 4, a equipe ainda não encontrou usuário afoito — e essa é a tarefa da semana, não um detalhe da entrega.

---

## Fontes

- **Blank, Steve**, *The Four Steps to the Epiphany* — origem do termo *earlyvangelist*; a escala de cinco degraus de dor e o exemplo do banco em todos os degraus; necessidade latente, necessidade ativa e solução visualizada; a ressalva sobre laboratórios de pesquisa e grupos de avaliação técnica; a preferência por falar com quem constrói; a lista de 50 nomes, a lista de inovadores, os números de ligações e visitas, a pergunta pela pessoa mais inteligente; a apresentação do problema em três colunas e o protocolo de pausas; "quem mais tem esse problema" e a proposta de valor em comum; as perguntas de entendimento em profundidade; a regra das três coisas por conversa; a instrução de não convencer o cliente.
- A ligação com a gambiarra da Q2 e o ajuste de escala do número de contatos para o semestre são leituras minhas, marcadas no texto.

---

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

# Usuário afoito (*early adopter*)

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

## O que são

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

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

## O que NÃO são

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

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

## Como trabalhar com eles

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

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

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

## Ao longo das quests

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

## Teste de realidade

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

---

## Fontes

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

---

<!-- tecnicas/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/lean-innovation.md -->

# Lean Innovation

**Para quê:** desenvolver inovação de forma enxuta.
**Quests:** transversal, com peso em 4, 5 e 6 · **Modo:** 🟡 com apoio

## A ideia

Filosofia que alia um negócio altamente focado às vantagens mercadológicas da inovação: em vez de planejar longamente e construir de uma vez, **documenta-se a hipótese, identifica-se o que é mais arriscado, e testa-se sistematicamente** — corrigindo o rumo com evidência.

O princípio que organiza tudo: **desperdício é qualquer atividade que consome recurso e não cria valor.** Construir o que ninguém quer é a forma mais cara de desperdício num projeto de inovação.

## Os três passos

1. **Documente seu plano A.** Escrever a visão inicial e compartilhá-la com pelo menos outra pessoa. Hipótese que só existe na cabeça de quem a teve serve para reforçar a própria convicção.
2. **Identifique as partes mais arriscadas.** Priorização errada de risco é das maiores fontes de desperdício.
3. **Teste sistematicamente.** Converta hipótese em algo falseável, teste, e corrija.

## Por que isso importa no Projetão

A metodologia das quests é uma implementação disso: a Q1 e a Q2 documentam o terreno, a Q3 e a Q4 identificam onde está o risco e escolhem por onde começar, e as quests seguintes testam — conceito na Q6, preço na Q7, usabilidade na Q8.

O que a disciplina acrescenta e o lean puro não enfatiza: o campo vem **antes** da hipótese. Você não começa com o seu plano A; começa observando.

## Materiais

Aula *Inovação*, de Geber Ramalho. Ver também `../leituras/running-lean/00-indice.md`, que é a versão operacional detalhada desta filosofia, e a bibliografia oficial (*A startup enxuta*, de Eric Ries).

---

## Fontes

- **Ash Maurya**, *Running Lean* — os três passos (documentar o plano A, identificar as partes mais arriscadas, testar sistematicamente)
- **Eric Ries**, *A startup enxuta* — o ciclo construir-medir-aprender, que sustenta a filosofia descrita aqui mas não é detalhado nesta ficha; ver **Running Lean — nota de leitura operacional** (`../leituras/running-lean/00-indice.md`)
- **Womack & Jones**, *Lean Thinking* — a definição de desperdício, citada por Maurya
- Página `tecnicas/lean` do site da disciplina

---

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