# 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 #9 — Plano de Projeto > **Objetivo.** Apresentar o plano de implementação do MVP. | | | |---|---| | **Modo de IA** | 🟢 coprodução no cronograma · 🔴 sem assistência nas estimativas de duração e na base de testes | | **Milestone** | **Plano de projeto** | | **Entrega** | cronograma com responsáveis, caminho crítico e base de testes | | **Erro que mais custa** | estimar em horas e planejar tudo no início | --- ## Duas entregas, não uma Os preparativos e a visão panorâmica do processo de execução. É vital estimar prazos e organizar a produção para que o produto esteja pronto até o Demoday — **e** elaborar como a equipe vai estimular uma base de usuários afoitos. A segunda é a que as equipes esquecem, e é a que aparece vazia no Demoday. --- ## Por que estimar em horas falha Três argumentos encadeados: **1. O cone da incerteza.** As estimativas iniciais de trabalho variam de **400% acima** do tempo real até **25% dele** — os extremos diferem por um fator de dezesseis. Conclusão: planejar tudo no início é inútil. Refine ao longo do projeto, detalhando só o próximo incremento de valor. **2. Somos péssimos em absoluto, bons em relativo.** Humanos são terríveis em estimar valores absolutos, mas bons em **dimensionamento relativo** — comparar um tamanho a outro. **3. Quem estima tem de ser quem executa.** Uma empresa entregou a estimativa de 80 projetos multimilionários aos "melhores estimadores" e teve de abortar o experimento na metade: as estimativas eram tão erradas que se tornaram inúteis, e nada foi entregue no prazo. **Só quem faz o trabalho sabe quanto tempo e esforço ele exige.** ### Estimativa relativa O exemplo canônico usa raças de cachorro: dachshund = 1, buldogue = 3, pastor-alemão = 5, dogue alemão = 13. Ninguém sabe dizer "quantos quilos", mas todos concordam na ordem. Há uma regra operacional embutida: **se um item é grande demais, quebre-o.** O dogue alemão vira dois buldogues mais um pastor-alemão. ### Por que Fibonacci 1, 3, 5, 8, 13 — cada número é a soma dos dois anteriores. O argumento é **perceptual**: > Os números da sequência estão suficientemente distantes para que consigamos perceber a diferença. Mas a diferença entre um cinco e um seis? É sutil demais para o nosso cérebro registrar. > > — Jeff Sutherland, *Scrum* Reforço clínico: para um paciente **perceber** melhora de sintoma, ela precisa ser maior que 65%. E o fecho: Fibonacci permite estimativas que **não precisam ser 100% exatas** — o valor está em todos usarem a mesma régua e formarem consenso. --- ## Planning poker — o procedimento É o método Delphi acelerado. Delphi remove viés mas é lento demais para centenas de itens. 1. Cada pessoa tem um baralho com números de Fibonacci. 2. O item a estimar vai à mesa. 3. Todos escolhem uma carta e a põem **virada para baixo**. 4. Todos viram **ao mesmo tempo**. 5. **Se todos estão dentro de duas cartas** (ex.: um 5, dois 8 e um 13): somam, tiram a média, e passam ao próximo item. 6. **Se a distância é maior que três cartas**: quem votou o maior e quem votou o menor **explicam o raciocínio**. Só então há nova rodada. O objetivo do passo 3–4 é evitar **ancoragem** — efeito manada e efeito halo. E o valor do passo 6 é o conhecimento compartilhado: no exemplo do livro, quem votou 3 achava que havia pouca parede; quem votou 13 lembrou do tempo de fitar armários e pintar de pincel. Nova rodada: o 3 virou 8. --- ## Velocity — como prever a data **Cálculo:** rode a primeira sprint. Ao final, conte as histórias **completas**, some os pontos delas. Esse número é a velocity. **Previsão:** com a velocity, olhe quantas histórias restam e quantos pontos representam. > **Velocity × Tempo = Entrega.** — Jeff Sutherland **Consequência para a Q9:** velocity só existe **depois de ao menos uma sprint fechada**. Logo, o cronograma até o Demoday deve ser **recalculado a cada sprint** — a linha de base sem dado real é ficção. O instrumento de visualização é o gráfico de burndown: pontos levados para a sprint num eixo, dias no outro, atualizado diariamente. --- ## Caminho crítico "Atividades mais críticas" não significa "mais importantes". Significa: **as que, se atrasarem, atrasam tudo o mais.** 1. Liste as atividades e o que cada uma precisa que exista antes. 2. Estime a duração de cada uma. 3. Encontre a **sequência mais longa de dependências** até o Demoday. Essa é o caminho crítico. 4. O que está nela não tem folga. O que está fora tem — e pode ser sacrificado sem mover a data. Em projeto de semestre, o caminho crítico quase sempre passa por: a parte técnica mais arriscada, a **integração entre partes feitas por pessoas diferentes**, e a **aquisição dos primeiros usuários**. As duas últimas são subestimadas com regularidade. --- ## Tamanho de equipe e o custo da comunicação **Sete pessoas, mais ou menos duas.** Acima de nove, a velocidade **cai** — mais gente faz o time ir mais devagar. **Lei de Brooks:** acrescentar gente a um projeto atrasado o atrasa mais. Duas causas: o tempo de trazer o novato ao ritmo, e a explosão de canais de comunicação. > **Canais = n(n−1)/2.** Cinco pessoas geram 10 canais; sete geram 21; nove geram 36; dez geram 45. Dado empírico: num levantamento de 491 projetos, grupos de **3 a 7 pessoas exigiram cerca de 25% do esforço** de grupos de 9 a 20 para o mesmo trabalho. **Se a turma impõe equipe grande** — que é o caso do Projetão —, a saída não é reclamar: é **subdividir em frentes com dono**, mantendo cada frente pequena e multifuncional. Sem isso, o time se quebra socialmente em subgrupos que trabalham com propósitos cruzados, a multifuncionalidade se perde, e reuniões de minutos viram reuniões de horas. --- ## O custo real da multitarefa | Projetos simultâneos | % do tempo por projeto | Perda por troca de contexto | |---|---|---| | 1 | 100% | 0% | | 2 | 40% | **20%** | | 3 | 20% | **40%** | | 4 | 10% | **60%** | | 5 | 5% | **75%** | > A coluna de perda é desperdício puro: com cinco projetos, 75% do trabalho não vai a lugar nenhum. **O exercício que prova, e cabe em cinco minutos de aula:** escreva 1–10, I–X e A–L. Fazendo por **linhas** (trocando de contexto a cada símbolo) leva cerca de 39 segundos; fazendo por **colunas** (um bloco de cada vez), 19 — metade. E o resultado num time real: três projetos tocados ao mesmo tempo terminam no fim de julho; conduzidos **um por vez até o fim**, terminam no começo de maio. **Trabalho pela metade é igual a zero.** Se algo está pela metade no fim da sprint, você está pior do que se não tivesse começado — teria sido melhor criar algo menor que realmente funcione. --- ## O que significa "pronto" Duas definições, e elas não competem — encaixam. **A barra de engenharia.** *Pronto* é um padrão de qualidade **acordado antes**, embutido no item de trabalho, não checado no fim. Todo mundo sabe quando algo está pronto porque há critério claro. Embutir conformidade em cada item, em vez de descobrir a não-conformidade no fim, elimina boa parte do retrabalho. Exija o par **Pronto para começar** e **Pronto**: histórias verdadeiramente prontas para começar dobram a velocidade; histórias verdadeiramente prontas ao fim da sprint dobram de novo. **Só demonstre o que atende à definição de pronto.** **A barra de aprendizado.** Numa startup enxuta, **uma funcionalidade só está "pronta" quando produz aprendizado validado com clientes.** Definir assim restringe ainda mais o funil: você não trabalha em nada novo sem provar que o que acabou de sair produziu aprendizado. **Como conciliar num semestre.** Use **Pronto = padrão técnico atendido + validação qualitativa** — é o que libera o item e mantém o ritmo. A verificação quantitativa fica como estado posterior, porque leva tempo demais para caber numa sprint curta. --- ## Limite de trabalho em progresso > **Comece com um limite de trabalho em progresso igual ao número de pessoas do time.** Três pessoas, três frentes em andamento. Isso maximiza a vazão e minimiza desperdício. E conecta com a tabela da multitarefa: o limite existe para impedir a equipe de se auto-sabotar. Complementos do quadro: - **Só entram itens que entregam valor ao usuário.** O teste: *você anunciaria isso aos usuários num informe?* Se é pequeno demais para mencionar, vai para um quadro de tarefas à parte, não para o quadro principal. - **Metas no topo do quadro**, para a priorização ser óbvia a todos. - **Faixas de espera**: cada etapa se divide em "em andamento" e "concluído, aguardando ser puxado". - **Itens podem ser mortos em qualquer estágio.** --- ## Planejar num prazo que não se move A data do Demoday é fixa. Isso muda a natureza do plano: **o escopo é a variável, não o prazo.** - **Fatie por valor entregue**, não por camada técnica. "Backend pronto" não é entregável — ninguém pode usar. "O usuário consegue se cadastrar e entrar num grupo" é. - **Tenha uma versão apresentável desde cedo.** Se a partir da metade a equipe puder mostrar algo que funciona em qualquer semana, o risco de chegar ao Demoday sem nada cai muito. - **Deixe folga explícita na última semana** — não para trabalhar: para ensaiar, gravar vídeo, imprimir material e consertar o que quebrar. - **Marque o congelamento de escopo.** Uma data a partir da qual não entra funcionalidade nova. - **Integre cedo e com frequência.** Quem integra uma vez por semana descobre o erro de integração na semana; quem integra na véspera do Demoday descobre na véspera. --- ## As perguntas da entrega 1. **Quais as atividades previstas** para a implementação do MVP? 2. **Quais os prazos estimados e quais as atividades mais críticas?** 3. **Quais são as (sub)equipes e seus responsáveis?** 4. **Quem é a base de testes** — o grupo de usuários afoitos com quem a equipe vai iniciar a operação? **Dica da disciplina:** elabore um cronograma gráfico com datas e prazos por membro responsável. ### Sobre a pergunta 4 É a continuação direta do trabalho de tração da Q7, e merece o mesmo rigor: - Quem são, **nominalmente ou por grupo identificado**? - Como vocês chegam até eles? - Quantos já toparam? - O que eles ganham? (usuário afoito colabora porque tem a dor — se você não sabe qual, não achou o usuário afoito) - Quando começam a usar? "Divulgaremos nas redes sociais" não é base de testes. E há um princípio útil: **prefira 10 usuários totalmente comprometidos a 100 em cima do muro.** --- ## Onde a IA ajuda de verdade Esta é a quest mais confortavelmente 🟢 coprodução. Decomposição de atividades, detecção de dependências, geração de cronograma, checklist de riscos — a máquina é boa nisso e não há dado de usuário em jogo. **O que continua sendo seu: as estimativas de duração.** A IA não sabe quanto a sua equipe rende, quem some na semana de provas, nem que a peça de hardware demora a chegar. Estimativa gerada sem esse conhecimento parece precisa e não é — e o princípio vale aqui igual: **só quem faz o trabalho sabe quanto ele custa.** Uso que rende mais: peça à IA que **questione o seu plano** — onde ele assume que nada dá errado, o que acontece se a pessoa X sair, qual atividade não tem dono. --- ## Referências desta quest | Arquivo | Quando | |---|---| | **Estimar — Quest #9** (neste arquivo) | Ao montar o cronograma. Pontos, Fibonacci, planning poker, velocity, burndown | | **Organizar o trabalho — Quest #9** (neste arquivo) | Ao dividir. Tamanho de time, multitarefa, limite de WIP, definição de pronto | | **Base de testes — Quest #9** (neste arquivo) | Ao planejar a tração. Como constituir e manter a comunidade de usuários afoitos | | **Autodiagnóstico — Quest #9** (neste arquivo) | Antes de entregar | --- ### Antes de registrar pessoas | Arquivo | Quando | |---|---| | `../../metodo/consentimento.md` | Ao montar a base de testes. A lista de quem topou testar é uma lista de pessoas reais — o que registrar dela, e o que não | --- ### 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) | a base de testes | | **Brainstorm** (neste arquivo) | decompor o trabalho | --- ## Perguntas frequentes **"Estamos atrasados. Cortamos escopo ou estendemos?"** A data não se move — logo, corta escopo. Corte pela curva de valor da Q5: sai primeiro o que não sustenta a PUV. Cortar a PUV para caber no prazo significa entregar um produto que não é o seu; nesse caso o problema é anterior, e vale conversar com o mentor. **"Vale a pena fazer Scrum completo num semestre?"** O mínimo que costuma valer: ciclo curto, reunião regular e curta, quadro visível, limite do que cada pessoa pega ao mesmo tempo, e uma definição de pronto escrita. Cerimônia demais consome o tempo que deveria ir para o produto. --- ## Bibliografia desta quest | Obra | O que ela dá para a Q9 | |---|---| | **Sutherland — Scrum** | Estimativa relativa, Fibonacci, planning poker, velocity, tamanho de time, multitarefa, definição de pronto | | **Maurya — Running Lean** | Limite de trabalho em progresso, o que entra no quadro, pronto = aprendizado validado | | **Ries — A startup enxuta** | Lotes pequenos: por que integrar cedo revela defeito cedo | | **Bigão Silva — Gerenciamento de projetos fora da caixa** | Bibliografia oficial da quest no site | --- # Autodiagnóstico — Quest #9 Faça este exercício **antes** de entregar. Ele é o mesmo que o mentor vai fazer depois. --- ## A escala O milestone da Q9 é **Plano de projeto**. Use a escala 0–5 da disciplina: | Nível | Significado | |---|---| | **0** | O critério ainda não aparece. | | **1** | Já aparece, mas sem clareza nem coerência. | | **2** | Falta clareza **ou** falta coerência. A resposta ainda está no terreno da insegurança. | | **3** | Coerente, mas ainda não totalmente claro. Resta uma parcela de incerteza. | | **4** | Claro e coerente com toda a proposta. Ainda cabe aperfeiçoar, mas a equipe responde com segurança. | | **5** | Perfeitamente alinhado ao conjunto. As respostas são sólidas. | O salto que trava a maioria na Q9 é o **3 → 4**, e ele tem um sintoma específico: o cronograma é bonito e ninguém consegue dizer **de onde saiu cada duração**. Plano que a equipe não sustenta sob a pergunta "quem estimou isso?" está em 3. --- ## Rubrica por dimensão ### 1. Decomposição das atividades | | | |---|---| | **2** | Lista por camada técnica: "backend", "frontend", "banco". Itens grandes demais para estimar. | | **3** | Lista de atividades razoável, mas com itens de tamanhos muito díspares e sem critério de quebra. | | **4** | Atividades fatiadas por **valor entregue ao usuário**, nenhuma grande demais para caber numa sprint, cada uma com o que precisa existir antes dela. | | **5** | O acima, com os itens grandes visivelmente quebrados e o registro de como foram quebrados. | ### 2. Estimativa | | | |---|---| | **2** | Horas atribuídas por uma pessoa, ou geradas por IA e aceitas. | | **3** | Estimativa relativa em pontos, mas feita por parte da equipe, sem régua declarada. | | **4** | Pontos em escala de Fibonacci, estimados **por quem vai executar**, com o item de referência declarado e o registro dos itens em que houve divergência e do que a discussão revelou. | | **5** | O acima, com a **data de recálculo** declarada e o burndown da primeira sprint preparado. | ### 3. Prazos e caminho crítico | | | |---|---| | **2** | Cronograma com todas as semanas preenchidas no mesmo nível de detalhe até o Demoday. | | **3** | Cronograma com datas, mas "atividades críticas" listadas como sinônimo de "atividades importantes". | | **4** | Detalhe fino nas próximas semanas e blocos grossos depois; caminho crítico identificado como a **sequência mais longa de dependências**; folga explícita na última semana; data de congelamento de escopo. | | **5** | O acima, com integração cedo e frequente marcada no cronograma, e com o que sai primeiro se o prazo apertar já decidido pela curva de valor da Q5. | ### 4. Subequipes e responsáveis | | | |---|---| | **2** | "Todos fazem tudo", ou papéis genéricos sem nome. | | **3** | Frentes definidas, mas com pessoas em três frentes ao mesmo tempo. | | **4** | Frentes pequenas e multifuncionais, cada uma com **um dono nomeado**; ninguém em mais de duas frentes; limite de trabalho em progresso declarado. | | **5** | O acima, com o custo de coordenação entre frentes tratado explicitamente (quando as frentes se falam, e sobre o quê) e com quem estimou cada bloco sendo quem o executa. | ### 5. Definição de pronto e quadro | | | |---|---| | **2** | Não há definição de pronto escrita. | | **3** | Definição de pronto existe, mas é genérica ("funcionando e testado"). | | **4** | Definição escrita em uma frase, incluindo validação qualitativa com usuário; quadro montado com metas no topo e limite de trabalho em progresso visível. | | **5** | O acima, com par **pronto para começar** / **pronto**, e com a regra de que só se demonstra o que atende à definição. | ### 6. Base de testes | | | |---|---| | **2** | "Divulgaremos nas redes sociais" ou a descrição do público-alvo repetida da Q1. | | **3** | Grupo identificado, mas sem nomes, sem número de quem já topou e sem data de início. | | **4** | Pessoas ou grupos nomeados, com caminho até eles, número de confirmados, **o que ganham** (a dor específica), e a semana do cronograma em que começam a usar. | | **5** | O acima, com quem recusou e por quê, e com o canal e a frequência de contato definidos e com dono. | --- ## Checklist rápido - [ ] Cada duração do cronograma foi estimada por **quem vai executar** aquilo? - [ ] Estimamos em pontos relativos, ou em horas absolutas — e qual é o "3" de referência da equipe? - [ ] Alguma atividade continua grande demais para caber numa sprint? - [ ] O cronograma tem **data declarada de recálculo**, ou finge precisão até o fim do semestre? - [ ] O caminho crítico é a sequência mais longa de dependências, ou é só a lista do que achamos importante? - [ ] A integração entre as partes feitas por pessoas diferentes está no cronograma, com data? - [ ] Existe folga na última semana **que não é para trabalhar**, e data de congelamento de escopo? - [ ] Nenhuma frente tem mais de sete pessoas, e toda frente tem **um** dono com nome? - [ ] Alguém está em três frentes ao mesmo tempo? (Ver a tabela de troca de contexto.) - [ ] O limite de trabalho em progresso está escrito no quadro? - [ ] A definição de pronto cabe em uma frase e está colada em algum lugar visível? - [ ] A base de testes tem **nomes** e **data** no cronograma, ou tem um público-alvo? - [ ] Sabemos dizer, de cada pessoa da base, qual é a dor dela? **Sinal de alerta:** se o cronograma foi montado em uma sessão e ninguém discordou de nenhuma duração, não houve estimativa — houve transcrição. Discordância entre o maior e o menor palpite é o mecanismo pelo qual o conhecimento circula. **Segundo sinal:** se a resposta à pergunta 4 tem o mesmo texto do segmento de cliente da Q5, a equipe não constituiu base de testes. --- ## Registro de trajetória (modo de IA) Meia página, entregue junto. Ver `metodo/modo-ia.md` para o racional. 1. **Modo** em que a quest foi feita, e onde você saiu dele. *A Q9 é a quest mais confortavelmente 🟢 coprodução: decompor atividades, detectar dependências, gerar cronograma e listar riscos são tarefas em que a máquina rende, e não há dado de usuário em jogo. A fronteira é a duração: estimativa gerada por quem não executa é o erro documentado na literatura da própria disciplina.* 2. **O que a IA gerou e você descartou — e por quê.** *Típico da Q9: a IA devolve um cronograma completo com durações plausíveis. Descartar as durações e refazê-las em planning poker, mantendo a decomposição, é exatamente o comportamento esperado.* 3. **O que você verificou, e como.** *Típico da Q9: as dependências. Diga qual dependência a IA não viu, ou qual ela inventou.* 4. **O que ainda não sabe.** *Aqui cabe declarar a velocity: se ela ainda não existe, diga que ainda não existe.* **O uso que mais rende na Q9:** peça à IA que **questione o seu plano** — onde ele assume que nada dá errado, o que acontece se a pessoa X sair, qual atividade não tem dono, qual dependência não tem folga. Registre as respostas que mudaram o plano. --- ## Como o mentor vai ler Cinco perguntas que aparecem com regularidade na apresentação da Q9. Se você tem resposta para as cinco, está em 4: 1. **"Quem estimou isto?"** A resposta forte nomeia as pessoas, e elas são as mesmas que aparecem como responsáveis pela frente. 2. **"O que acontece com a data se esta atividade atrasar uma semana?"** Se qualquer atividade atrasa tudo, não há caminho crítico identificado — há uma lista. 3. **"O que vocês cortam se estiverem atrasados?"** A data não se move; logo, corta escopo. A resposta forte já sabe a ordem do corte, e ela vem da curva de valor da Q5. 4. **"Quem já está usando, ou já topou usar?"** Nome, ou número com data. "Estamos conversando com algumas pessoas" é nível 2. 5. **"O que significa 'pronto' para vocês?"** Se cada pessoa da equipe responder diferente, a definição não existe — está escrita, mas não acordada. Divergência entre a sua auto-avaliação e a leitura do mentor é informação útil, não constrangimento. --- # Base de testes — Quest #9 Abra este arquivo quando for responder à pergunta 4 da entrega: **quem é o grupo de usuários afoitos com quem a equipe vai iniciar a operação.** É a metade da Q9 que as equipes esquecem, e é a que aparece vazia no Demoday. Modo de IA: 🟡 **com apoio**. A IA ajuda a redigir a mensagem de convite e a organizar a lista. Ela não pode gerar os nomes, e um "público-alvo" descrito por ela não é base de testes. *Usuário afoito* traduz *early adopter*: quem já tem a dor e adota antes de o produto estar pronto. --- ## 1. O que conta como base de testes, e o que não conta A base de testes é a **lista de pessoas concretas que vão usar o MVP durante o semestre e devolver dado.** É diferente de três coisas com que ela costuma ser confundida: | Isto | Não é base de testes porque | |---|---| | A persona da Q1 | É um retrato, não um contato | | O segmento de cliente da Q5 | É uma categoria, não uma lista | | "Vamos divulgar nas redes" | É um canal, não um compromisso | | Os três participantes do teste da Q8 | Foram convidados para uma sessão de uma hora, não para uso continuado — a menos que você tenha pedido e eles tenham aceitado | O que a Q9 pede é a quarta coisa: nomes, ou grupos identificados, com forma de contato, com o que eles ganham, e com quando começam. **A regra que orienta o tamanho.** Maurya é direto sobre a proporção: > **Prefiro dez usuários afoitos totalmente comprometidos, a quem eu possa dar atenção integral, a cem em cima do muro, qualquer dia.** E ele explica por quê: **o primeiro objetivo com o MVP é aprender.** Cem usuários indiferentes produzem números que parecem melhores e aprendizado que não existe. Dez comprometidos produzem conversa. > ⚠️ **Isso contraria o instinto da apresentação.** A equipe quer dizer "temos 200 pessoas na lista de espera" porque soa melhor diante da banca. Mas 200 inscrições sem uso é exatamente o que Ries chama de **métrica de vaidade** — o número que dá o quadro mais cor-de-rosa possível e não sustenta pergunta. Dez pessoas nomeadas, com o que cada uma já fez com o produto, é uma resposta que a banca não derruba. --- ## 2. Como constituir a base ### Primeiro, o canal certo Maurya coloca uma preferência antes de qualquer tática: **sempre que possível, priorize achar pessoas pelo canal que você de fato vai usar para adquirir clientes no futuro.** Se você não tem ainda um caminho até o cliente, isso pode não ser possível nesta fase — mas quando for, o mesmo esforço rende duas coisas: a base de testes e o teste do canal. ### As técnicas, em ordem de esforço | Técnica | Como | Ressalva | |---|---|---| | **Contatos de primeiro grau** | Comece pelos contatos imediatos que se encaixam no perfil demográfico alvo | Há quem desconfie de feedback de contato próximo. A posição de Maurya: **falar com qualquer pessoa é melhor que não falar com ninguém** | | **Pedir apresentação** | Peça aos contatos de primeiro grau que apresentem pessoas do perfil. **Inclua um modelo de mensagem** que a pessoa possa copiar e encaminhar, para poupar o tempo dela | Duas ou três casas de distância normalmente bastam | | **Chegar até o segundo e o terceiro grau** | Use os primeiros entrevistados para chegar a outros | Serve também para praticar o roteiro e ganhar conforto | | **Contato frio** | Ligação, e-mail, redes profissionais | O segredo para conseguir que alguém, frio ou morno, aceite conversar é **acertar em cheio o problema dela**. Como isso é difícil de fazer de saída, Maurya usa as outras técnicas primeiro, roda algumas conversas, e só depois vai a frio | **O modelo de mensagem** que Maurya usa tem uma estrutura que vale copiar: um pedido curto ao amigo, seguido de um texto pronto para encaminhar, que diz o que a equipe está construindo, quanto tempo pede, e — a frase que faz a diferença — **"não estou vendendo nada, só procurando conselho"**. **A parcela que fica.** Quando Maurya lançou seu próprio produto de forma iterativa, cerca de metade das pessoas aceitou receber material inacabado a cada duas semanas; as outras preferiram esperar o produto terminado. Isso, por si, distinguiu **usuários afoitos de clientes de estágio posterior**: os afoitos se moviam pelo conteúdo e não se importavam com o empacotamento. **A recusa também é dado.** Registre-a. ### Uma prática de campo **Prefira encontro presencial.** Além de captar linguagem corporal, encontrar alguém pessoalmente cria uma proximidade que não se recria à distância — e isso é crítico para construir relação com o cliente, que é exatamente o que a base de testes é. **Ação:** monte uma planilha com colunas *nome · como chegamos até ele · perfil · já topou? · o que ganha · quando começa*. Dez linhas preenchidas valem mais que trezentos e-mails coletados. --- ## 3. O que oferecer Aqui há uma divergência entre as fontes, e ela é útil. | Fonte | Posição | Contexto | |---|---|---| | **Krug** | Pague, e um pouco acima da praxe. Torna claro que você valoriza o tempo da pessoa e melhora a chance de ela aparecer | **Teste de usabilidade**: sessão isolada de uma hora, com deslocamento | | **Maurya** | **Não pague nem ofereça outros incentivos.** "Diferentemente de teste de usabilidade, onde é aceitável oferecer incentivo, aqui o seu objetivo é achar clientes que paguem **você**, não o contrário" | **Entrevista com cliente e base de usuários**: relação continuada | **Qual usar na Q9:** a de Maurya. A base de testes não é uma sessão paga; é uma relação. Se as pessoas só participam mediante pagamento, você não achou usuários afoitos — achou participantes de pesquisa. **Então o que elas ganham?** A dor resolvida antes dos outros. Se a equipe não consegue dizer qual é a dor específica daquela pessoa, ela não achou o usuário afoito — achou alguém educado. A checagem prática de Maurya se aplica: se a pessoa declara um problema como indispensável mas **não está fazendo nada para resolvê-lo hoje**, há uma desconexão. Quem já mantém uma gambiarra para se virar tem a dor; quem não faz nada e continua se virando, não. **Os quatro princípios que fazem o convite funcionar.** Maurya analisa por que um cliente concordou em pagar cinco vezes mais do que havia proposto, e nomeia quatro mecanismos. Três deles se transportam para o convite à base de testes de um projeto de disciplina, sem pagamento envolvido: | Princípio | Como se usa no convite | |---|---| | **Escassez** | "Estamos procurando especificamente **dez** [perfil] que tenham [problema]. Vamos trabalhar de perto com essas dez pessoas para validar [PUV] em 30 a 60 dias." A escassez de Maurya **não era artifício** — era a consequência de querer dar atenção integral a cada um | | **Prêmio** (*prizing*) | Maurya cita a técnica de enquadramento de Oren Klaff, em *Pitch Anything*: na maioria das apresentações, quem apresenta faz o papel de bobo da corte entretendo a corte de clientes. Em vez de tentar impressionar, **posicione-se como o prêmio** — você está selecionando com quem vai trabalhar | | **Confiança** | A maioria reluta em cobrar, ou em convidar, porque acha o MVP "mínimo" demais e sente vergonha dele. Maurya não subscreve: **a razão de testar problemas com cuidado e reduzir escopo é construir o produto mais simples que resolve um problema real de cliente** | **Ação:** escreva o convite em três frases usando escassez explícita e número declarado. Não use "queremos o máximo de gente possível". --- ## 4. Como manter o diálogo Constituir a base é a parte fácil. Mantê-la viva por doze semanas é o que a Q9 está de fato pedindo. **1. Peça permissão para acompanhar — sempre, e na hora.** Maurya fecha toda conversa com dois pedidos, e o primeiro é este: *"Com base no que a gente conversou hoje, você toparia ver o produto quando a gente tiver alguma coisa pronta?"* O objetivo declarado é **estabelecer um ciclo contínuo de feedback**. **2. Peça indicação, na mesma hora.** O segundo pedido: *"Também estamos procurando entrevistar outras pessoas como você. Você poderia nos apresentar a outros [perfil]?"* A base cresce por dentro. **3. Deixe um gancho memorável.** Mesmo quando ainda não é hora de falar da solução em detalhe, é preciso dar um gancho que mantenha o interesse. Maurya usa o **pitch de alto conceito** para isso — a destilação em *sound bite* no formato "[referência conhecida] para/sem [torção]" —, porque ele explica a solução em alto nível **e deixa uma frase memorável que a pessoa consegue repetir para outros**. Detalhes em **Roteiro do pitch — Quest #10** (projetao-ufpe.vercel.app/baixar/colar/projetao-10.md). **4. Documente nos cinco minutos seguintes.** Reserve os cinco minutos imediatamente depois de cada conversa para registrar o resultado enquanto está fresco. Maurya recomenda um formulário curto e fixo; e, quando duas pessoas participaram, **cada uma preenche o formulário sozinha primeiro**, e só depois há uma conversa de comparação e um registro final. Isso mantém o resultado objetivo. **5. Facilite o retorno espontâneo.** Maurya observa que, ao contrário do que se teme, você não vai ser bombardeado: boa parte dos contatos que chegam são de pessoas com **dúvidas sobre o serviço**, não com problemas de suporte. Dá para reservar uma faixa de horário no dia e redirecionar as chamadas se e quando isso virar problema de escala — o que seria um problema bom de ter. **6. Vá atrás de quem desistiu.** Este é o item que quase nenhuma equipe faz e que rende muito na apresentação: **você aprende tanto ou mais com quem não ficou do que com quem ficou.** Algumas pessoas dão retorno honesto se você fizer um pedido sincero ao fim do período de teste; outras precisam de um pequeno incentivo — Maurya sugere um vale ou uma doação a uma instituição em troca de quinze minutos. **7. Tenha um ritmo fixo de revisão.** Maurya marca **um horário toda segunda-feira** para revisar os indicadores da semana com a equipe inteira e identificar onde está vazando. Numa disciplina, isso encaixa na reunião de sprint. --- ## 5. Uma coisa que a base de testes não é Ela não é fila de espera de lançamento. Maurya faz a distinção com clareza: se você já tem uma lista grande de contatos mornos vinda de esforços anteriores — página teaser, indicações de entrevistados —, **considere esgotar essa lista primeiro, na forma de mais convites de acesso antecipado, antes de um lançamento público.** A ordem, portanto, é: conversar com quem já está na lista → convidar para usar → só então pensar em divulgação ampla. Equipe que inverte essa ordem chega ao Demoday com muita divulgação e nenhum uso. E há um alerta associado: quando o produto abre, você deixa de controlar quem entra. Além dos usuários afoitos alvo, chegam robôs, curiosos e talvez outros clientes-alvo ainda não descobertos. **Olhar só o número agregado produz um efeito de média que distorce muito quando o tráfego ainda é pouco, ou não é o tráfego certo.** Por isso é preciso **segmentar** — e por isso a base nominal importa: ela é o segmento que você sabe interpretar. --- ## 6. O que reportar na entrega A pergunta 4 da Q9 pede um grupo. Responda com esta estrutura — ela é curta e cobre o que o mentor vai perguntar: | Item | O que escrever | Resposta fraca | |---|---|---| | **Quem são** | Nominalmente, ou por grupo identificado com nome próprio ("os 8 monitores do laboratório X", "o grupo de mensagens da associação Y, 40 pessoas") | "Estudantes universitários" | | **Como chegamos até eles** | O caminho concreto: quem apresentou, por qual canal | "Redes sociais" | | **Quantos já toparam** | Um número, e a data em que cada um confirmou | "Vários demonstraram interesse" | | **O que eles ganham** | A dor específica resolvida antes dos outros. Se houver outra contrapartida, declare | "Vão ajudar a melhorar o produto" | | **Quando começam a usar** | Data no cronograma, ligada a uma sprint | "Assim que estiver pronto" | | **Como vamos manter contato** | Canal, frequência, quem da equipe é responsável | — | | **O que já sabemos deles** | O que veio das conversas da Q2 e do teste da Q8, com quantas pessoas | — | | **Quem recusou, e por quê** | A recusa também é dado, e mostra que houve convite real | — | **A conexão com a Q7 e a Q10.** A base de testes é a mesma população que vai responder ao teste de ajuste produto-mercado da Q10, se houver tempo, ou fornecer o número de retenção. Se ela não existir na Q9, não existirá número honesto na Q10 — e a única resposta possível diante da banca vai ser "ainda não medimos". Ver **Tração e números — Quest #10** (projetao-ufpe.vercel.app/baixar/colar/projetao-10.md). **Ação:** entregue a planilha de dez linhas junto com o cronograma, e marque no cronograma a semana em que a base começa a usar. Base de testes sem data no cronograma é intenção, não plano. --- ## Fontes - **Maurya, Ash**, *Running Lean* — cap. 6: as técnicas para achar pessoas (contatos de primeiro grau, pedir apresentação com modelo de mensagem, contato frio e a condição de acertar o problema), a preferência pelo canal real de aquisição, a recomendação de encontro presencial, a orientação de não pagar nem incentivar prospects, a documentação em cinco minutos com preenchimento independente; cap. 7: o fechamento com pedido de permissão para acompanhar e pedido de indicação, e o uso do pitch de alto conceito como gancho; cap. 8: os quatro princípios do convite (prêmio, escassez, ancoragem, confiança) e a frase sobre dez comprometidos contra cem em cima do muro; cap. 10 e 12: esgotar a lista morna antes do lançamento público, a segmentação contra o efeito de média, o retorno espontâneo dos usuários e o incentivo para conversar com quem desistiu; cap. 2: o caso da própria publicação iterativa e a metade que preferiu esperar o produto pronto - **Krug, Steve**, *Não me faça pensar*, cap. 9 — a posição oposta sobre incentivo, no contexto de sessão isolada de teste - **Ries, Eric**, *A startup enxuta*, cap. 7 — métricas de vaidade e o "teatro do sucesso": por que número bruto de cadastros não sustenta pergunta - **Klaff, Oren**, *Pitch Anything* — a técnica de enquadramento como prêmio, conforme citada por Maurya --- # Estimar — Quest #9 Abra este arquivo no dia em que a equipe for transformar a lista de atividades em datas. Ele responde a uma pergunta só, em várias camadas: **como dizer quando algo fica pronto sem inventar.** Modo de IA: 🟢 **coprodução** na decomposição e na montagem do cronograma. 🔴 **sem assistência** no valor das estimativas — quem estima tem de ser quem executa, e a IA não executa. --- ## 1. O cone da incerteza, e o que ele proíbe Sutherland apresenta o gráfico com os números: **as estimativas iniciais de trabalho variam de 400% acima do tempo efetivamente gasto até 25% dele.** Os extremos, portanto, diferem por um **fator de dezesseis**. Conforme o projeto avança e mais coisas se assentam, as estimativas se aproximam da realidade, até que não há mais estimativa — só realidade. A conclusão que ele tira é dura e é a que interessa à Q9: **planejar tudo no início não funciona.** No caso que ele narra, uma empresa passou meses planejando o que o produto seria e quanto tempo levaria, e mesmo depois de todos esses meses a pesquisa indica que eles provavelmente errariam por um fator de quatro, para mais ou para menos. O que fazer no lugar: **refinar o plano ao longo do projeto, em vez de fazê-lo todo no início** — planejando em detalhe apenas o suficiente para entregar o próximo incremento de valor, e estimando o resto em blocos maiores. E o que sustenta esse refinamento: ao fim de cada iteração existe **algo de valor que dá para ver, tocar e mostrar** para quem vai usar. Aí você pergunta: é isso que você quer? Isso resolve pelo menos parte do seu problema? Estamos indo na direção certa? Se a resposta for não, o plano muda. > ⚠️ **Consequência para o cronograma da Q9.** A quest pede um cronograma até o Demoday, e é preciso entregar um. Mas um cronograma detalhado semana a semana até o fim do semestre, feito na semana da Q9, é exatamente o artefato que o cone da incerteza diz ser inútil. A forma defensável de entregar: **detalhe fino nas próximas duas ou três semanas, blocos grossos depois**, e uma **data declarada de recálculo** — "este cronograma será refeito ao fim de cada sprint, com a velocity medida". Declarar isso vale mais do que fingir precisão de segunda casa em maio. --- ## 2. Somos péssimos em absoluto, bons em relativo O segundo argumento encadeado: humanos são **absolutamente terríveis** em estimar valores absolutos, mas bons em **dimensionamento relativo** — comparar um tamanho a outro. Distinguir camisetas P, M e G, por exemplo. ### O exemplo das raças de cachorro Mike Cohn, tendo sido proibido pela esposa de ter cachorro, começou a perguntar às equipes de que **tamanho de cachorro** era cada pedaço do projeto. Ele listava raças — labrador, terrier, dogue alemão, poodle, dachshund, pastor-alemão, setter irlandês, buldogue — e perguntava: este problema aqui é um dachshund ou um dogue alemão? E se aquele é um dachshund, este aqui deve ser mais ou menos do tamanho de um labrador, certo? Depois vinha a conversão em número: **dachshund = 1, dogue alemão = 13.** Isso faria um **labrador = 5** e um **buldogue = 3**. Sutherland aplica ao exemplo do casamento, e o passo a passo serve de modelo para a Q9: | Item | Raciocínio | Ponto | |---|---|---| | Achar o local | Exige pesquisa, orçamento, visitar lugares. É envolvido | Pastor-alemão = **5** | | Noivos | Só precisam aparecer. Um telefonema | Dachshund = **1** | | Convites | Fazer a lista, pegar a lista da mãe dele, a da mãe dela, escolher o papel, imprimir, endereçar à mão | Dogue alemão = **13**, ou talvez dois | E aí entra a regra operacional embutida no exercício: **se um item é grande demais, quebre-o em pedaços administráveis.** Os convites viram dois projetos — juntar os nomes (buldogue, **3**) e lidar com a gráfica (buldogue, **3**) —, e endereçar vira um pastor-alemão (**5**). **Ação:** faça o exercício com a lista de atividades da Q9 antes de qualquer conversa sobre datas. Escolha **um item de referência** que todo mundo entende — algo já feito na Q6 ou Q8 — e chame de 3. Estime todo o resto em relação a ele. --- ## 3. Por que Fibonacci 1, 3, 5, 8, 13 — cada número é a soma dos dois anteriores. Sutherland dá o contexto matemático (a sequência aparece na concha do náutilo, nos galhos de árvore, na couve-flor, na curva da folha de samambaia, na forma das galáxias; é a razão áurea), mas o argumento que sustenta o uso é **perceptual**: > Os números da sequência estão suficientemente distantes para que consigamos perceber a diferença. Mas a diferença entre um cinco e um seis? É sutil demais para o nosso cérebro registrar. Se uma pessoa estima algo como cinco e outra como oito, dá para ver intuitivamente a diferença. Entre cinco e seis, não. **O reforço clínico** que ele traz: é razoavelmente conhecido em medicina que, para um paciente **relatar que percebe** melhora em um sintoma, a melhora precisa ter sido **maior que 65%**. Nossas mentes não funcionam em incrementos suaves; somos melhores em perceber saltos de um estado para outro — e saltos irregulares, não suaves. **O fecho, e é o ponto que mais se perde:** usar Fibonacci permite estimativas que **não precisam ser 100% exatas**. Nada é exatamente um cinco, um oito ou um treze. O que os números dão é uma forma de coletar opiniões sobre o tamanho de uma tarefa em que **todo mundo usa mais ou menos a mesma régua** — e é assim que se forma consenso. Estimar em grupo dessa maneira dá uma estimativa muito mais acurada do que qualquer pessoa sozinha produziria. --- ## 4. Planning poker, passo a passo ### De onde vem É o **método Delphi acelerado**. Sutherland conta a origem: nos anos 1950 a Rand Corporation foi chamada a responder perguntas da Guerra Fria. Norman Dalkey e Olaf Helmer publicaram em 1963 o método, invocando o oráculo de Delfos, com a intenção de fazer perguntas **sem que a opinião de uma pessoa afetasse a das outras**. Reuniram quatro economistas, um especialista em vulnerabilidade física, um analista de sistemas e um engenheiro elétrico, e conduziram uma série de pesquisas anônimas: ninguém sabia quem eram os outros; a cada rodada, as respostas e os dados usados voltavam ao grupo, com qualquer marca de identificação removida. Os números da convergência: na primeira rodada, a faixa ia de **50 a 5.000**. Depois de perguntarem quais fatores os especialistas haviam usado e devolverem essa informação ao grupo, a faixa caiu para **89 a 800**. Repetindo, chegou-se a **167 a 360**. **O problema do Delphi**, para o uso em projeto: é lento demais. Sutherland precisava de centenas de itens estimados em horas, não em dias ou semanas. ### Os dois vieses que ele existe para combater | Viés | O que é | Exemplo do livro | |---|---|---| | **Efeito manada** (*bandwagon*, ou cascata informacional) | Alguém propõe uma ideia, o grupo embarca, e mesmo quem discordava inicialmente vai junto. Depois, ao serem sondadas, quase todas as pessoas tinham reservas — e não as verbalizaram porque supuseram que a própria reserva era boba ou mal informada. Sutherland insiste: **isso não é falha individual, é falha humana** | Um artigo rejeitado pelo primeiro periódico tem mais chance de ser rejeitado pelo segundo, que sabe da primeira rejeição — e ainda mais pelo terceiro | | **Efeito halo** | Uma característica de algo influencia a percepção de outras características, não relacionadas | Thorndike, 1920, "A Constant Error in Psychological Ratings": oficiais militares classificaram soldados por qualidades físicas, intelectuais, de liderança e de personalidade, e as notas correlacionaram demais — quem tinha bom físico era avaliado como bom líder, inteligente e de bom caráter | ### O procedimento 1. Cada pessoa tem um baralho com os números de Fibonacci — 1, 3, 5, 8, 13, e assim por diante. 2. O item a estimar vai à mesa. 3. Cada um puxa a carta que representa o esforço que julga correto e a coloca **virada para baixo**. 4. Todos viram **ao mesmo tempo**. 5. **Se todos estão dentro de duas cartas** — por exemplo um 5, dois 8 e um 13 —, a equipe soma tudo, tira a média (nesse caso 6,6) e passa ao item seguinte. São estimativas, não cronogramas de ferro, e sobre pedaços pequenos do projeto. 6. **Se as cartas estão a mais de três de distância**, quem votou o maior e quem votou o menor **explicam o raciocínio**. Só então há nova rodada. Fora isso, a equipe simplesmente tira a média — que aproxima o que os estatísticos da Rand obtiveram. ### O exemplo que mostra o valor do passo 6 Pintar o interior de uma casa: sala, cozinha e dois quartos, com uma equipe que já pintou junta antes. - Os dois quartos: todo mundo estima **3**. Sem discordância — já fizeram, é direto. - A sala: cômodo grande mas simples. Estimativas de **5 a 13**, com média **6**. Sem necessidade de discussão. - A cozinha: um **3**, um **8**, um **13** e um **5** na mesa. Quem pôs 3 argumenta que o cômodo é pequeno e tem menos parede que os quartos. Quem pôs 13 responde que o consumo real de tempo é **fitar armários e bancadas**, e que pintar todas aquelas áreas pequenas vai ter de ser com pincel, não com rolo. Nova rodada: **o 3 vira 8**, os outros ficam. Perto o bastante — somam, tiram a média e seguem. **O que o passo 6 produz não é a estimativa: é o conhecimento compartilhado.** Todo mundo na equipe passou a saber que existe trabalho de fitar armários. **Ação:** o baralho pode ser papel cortado. O que não pode faltar é o passo 3 e 4 — todos escolhem antes de ver a escolha alheia. Sem isso, o método vira reunião de opinião, e você reintroduz exatamente os dois vieses que ele existe para remover. --- ## 5. Quem estima tem de ser quem executa Sutherland é explícito: **é crucial que quem estima seja a equipe que vai de fato fazer o trabalho, não estimadores "ideais" especialistas.** O caso que ele narra: a GSI Commerce, empresa que projetava lojas online para grandes marcas, teve a ideia — que parecia boa — de tirar a estimativa das equipes e entregá-la aos **melhores estimadores da empresa**, os que mais entendiam de projeto e tecnologia. O plano era entregar estimativas de **oitenta projetos multimilionários** aos clientes e às equipes que fariam o trabalho. O resultado: **o experimento foi interrompido pela metade, com quarenta projetos feitos.** Sutherland compara a estudos de medicamento interrompidos porque a droga está matando os pacientes. As estimativas eram tão erradas que se tornaram inúteis; nada foi entregue no prazo; os clientes ficaram insatisfeitos; as equipes, desmoralizadas. Os gestores voltaram a fazer as equipes que executam estimarem, e as estimativas voltaram a bater com a realidade. A lição que ele extrai: **só quem faz o trabalho sabe quanto tempo e esforço ele exige.** Talvez a equipe seja muito boa numa coisa e péssima em outra; talvez tenha um especialista útil numa área e ninguém que conheça outra. Equipes são individuais e únicas, cada uma com o próprio ritmo. Forçá-las em processos de molde único é receita de desastre. > ⚠️ **Onde isso morde na Q9.** Duas violações são comuns numa equipe de disciplina. A primeira: o gerente estima sozinho e distribui. A segunda: a IA gera o cronograma completo, com durações, e a equipe aceita. As duas são a mesma violação — estimador que não executa. A IA não sabe quanto a sua equipe rende, quem some na semana de provas, nem que a peça de hardware demora a chegar. **Use a IA para decompor e para questionar; não para atribuir duração.** --- ## 6. Velocity: como a data deixa de ser chute **O cálculo.** Você tem as histórias e já as estimou — esta é um oito, aquela é um três. Rode a primeira sprint. Ao fim dela, **conte as histórias completas**, some os pontos delas. Esse número é a **velocity** da equipe. **A previsão.** Com a velocity, olhe quantas histórias restam e quantos pontos elas representam — e você sabe quando vai terminar. > **Velocity × Tempo = Entrega.** **O segundo uso, que Sutherland considera o mais importante:** uma vez que você tem velocity, dá para perguntar **o que está impedindo a equipe de ir mais rápido**. É assim que se verifica se o desperdício está de fato sendo removido — e não apenas declarado removido. **O caso, com os números:** depois de três sprints medindo velocity, as equipes tinham acelerado de **20 para 60 pontos por sprint**. Com essa velocity, no começo de março, a conta dava mais dezenove sprints de duas semanas: entrega em **1º de dezembro**. A gestão recebeu então uma lista de **doze impedimentos** — de falta de autonomia para decidir a requisitos técnicos onerosos, de gente que não aparecia em reunião a coisas simples como não ter todo mundo da equipe na mesma sala. Cada impedimento com o nome de um gestor ao lado. Todos foram removidos entre a segunda e a quinta-feira. **Ao fim da sprint seguinte, a velocity subiu 50%**, e a data foi para 1º de setembro — ainda três meses atrasada, mesmo tendo a equipe acelerado de 20 para 90 pontos por sprint, mais de 400%. **As três perguntas que ele fez quando a data ainda não fechava** — e que valem para uma equipe de disciplina em apuros: 1. **Há algo que possamos fazer diferente para acelerar?** (Foi assim que descobriram que a segurança de TI havia fechado uma porta e travado equipes inteiras.) 2. **Dá para transferir itens do backlog? Há coisa que outras equipes possam fazer?** 3. **Há coisa que possamos não fazer? Dá para reduzir o escopo?** A resposta inicial foi que já haviam cortado até o osso. Passaram a tarde inteira raspando: **cada tarefa teve de lutar pela própria vida.** Ganharam mais um mês. **Consequência direta para a Q9:** velocity **só existe depois de pelo menos uma sprint fechada**. Se a Q9 acontece antes da primeira sprint, a linha de base do cronograma não tem dado real por trás. Diga isso, e marque a data do primeiro recálculo. --- ## 7. Burndown O instrumento de visualização. Num eixo, **o número de pontos que a equipe levou para a sprint**; no outro, **os dias**. Todo dia alguém soma os pontos concluídos e marca no gráfico. Idealmente, há uma **inclinação acentuada para baixo**, chegando a zero ponto restante no último dia da sprint. O valor não é o desenho: é que o desvio aparece **no dia três**, não na véspera. Uma linha que não desce nos primeiros dias é a informação de que a equipe começou muitas coisas e não terminou nenhuma — que é exatamente o diagnóstico de trabalho em progresso excessivo tratado em `organizar-o-trabalho.md`. Sutherland lista o burndown ao lado do quadro de três colunas — **A fazer, Fazendo, Feito** — como as duas formas padrão de **tornar o trabalho visível**. **Ação para a Q9:** entregue o burndown em branco, com o eixo de pontos preenchido pela estimativa da primeira sprint e os dias marcados. Um burndown planejado é entregável; um burndown inventado retroativamente não é. --- ## 8. O que a Q9 precisa mostrar sobre estimativa | Pergunta da entrega | O que a estimativa fornece | |---|---| | Quais as atividades previstas? | A lista quebrada até o ponto em que nenhum item é um dogue alemão solto | | Quais os prazos estimados? | Pontos por item, com a régua declarada (qual item é o 3 de referência) e a data de recálculo | | Quais as atividades mais críticas? | Ver caminho crítico no `SKILL.md`: a sequência mais longa de dependências. Grande ≠ crítica | | Quais as subequipes e responsáveis? | Quem estimou cada bloco é quem executa cada bloco — a coerência entre as duas listas é verificável | **Uma frase para a apresentação, se a banca ou o mentor perguntar de onde vieram as datas:** "estimamos em pontos, por comparação relativa, com quem vai executar; a data sai da velocity, e a velocity só existe depois da primeira sprint — por isso o cronograma tem data de recálculo". Isso é mais forte do que um Gantt com precisão fictícia. --- ## Fontes - **Sutherland, Jeff**, *Scrum: a arte de fazer o dobro do trabalho na metade do tempo* — cap. 6 inteiro: o cone da incerteza e os números de 400% e 25%; o refinamento incremental do plano; dimensionamento relativo e os pontos de cachorro de Mike Cohn; a sequência de Fibonacci e o argumento perceptual, incluindo o dado dos 65% de melhora percebida; o método Delphi da Rand (Dalkey & Helmer, 1963) e as faixas de convergência; efeito manada e cascata informacional; efeito halo (Thorndike, 1920); o procedimento do planning poker e o exemplo da pintura; o caso da GSI Commerce e a conclusão sobre quem estima; velocity, a fórmula, os doze impedimentos e as três perguntas; o apêndice do livro, com o burndown e o quadro de três colunas - **Cohn, Mike** — autor do exercício dos pontos de cachorro, conforme creditado por Sutherland - **Weinberg, Gerald**, *Quality Software Management* — origem da tabela de multitarefa usada em `organizar-o-trabalho.md`, do mesmo capítulo --- # Organizar o trabalho — Quest #9 Abra este arquivo quando a equipe for dividir gente por frente e decidir como o trabalho anda de semana em semana. Ele trata de quatro decisões que uma equipe grande de disciplina costuma tomar por omissão: **quantas pessoas por frente, quantas coisas ao mesmo tempo, o que significa "pronto", e o que entra no quadro.** Modo de IA: 🟢 **coprodução** — decompor, detectar dependências, montar o quadro. A IA não decide quem faz o quê, e não sabe quem some na semana de provas. --- ## 1. Tamanho de time, e por que a Q9 esbarra nisso A formulação clássica é **sete pessoas, mais ou menos duas** — Sutherland registra ter visto times de três funcionando em alto nível. O dado que interessa: **se você tem mais de nove pessoas num time, a velocity de fato cai.** Mais recurso faz o time ir mais devagar. **Lei de Brooks**, cunhada por Fred Brooks em 1975, em *The Mythical Man-Month*: **acrescentar gente a um projeto de software atrasado o atrasa mais.** Isso foi confirmado em estudo após estudo. **O dado empírico.** Lawrence Putnam dedicou a carreira a estudar quanto tempo as coisas levam para ser feitas e por quê. O trabalho dele mostrava, repetidamente, que projetos com vinte ou mais pessoas consumiam mais esforço do que projetos com cinco ou menos — não um pouco mais: **um time grande gastava cerca de cinco vezes o número de horas de um time pequeno.** Em meados dos anos 1990 ele fez um levantamento amplo para determinar o tamanho certo: **491 projetos de médio porte, em centenas de empresas diferentes**, todos exigindo produtos ou funcionalidades novas — não reaproveitamento de versões antigas. Dividindo por tamanho de time, notou de imediato que, **acima de oito pessoas, os times demoravam dramaticamente mais**. E o número que se cita: **grupos de três a sete pessoas exigiram cerca de 25% do esforço de grupos de nove a vinte para fazer a mesma quantidade de trabalho.** O resultado se repetiu ao longo de centenas e centenas de projetos. ### As duas causas Brooks encontrou duas razões para adicionar gente atrasar o projeto: 1. **O tempo de trazer a pessoa nova ao ritmo.** Como se espera, colocar alguém a par atrasa todo mundo. 2. **A explosão de canais de comunicação**, contra o limite do cérebro. **A fórmula:** número de pessoas, multiplicado por esse número menos um, dividido por dois. > **Canais = n(n−1)/2** | Pessoas | Canais | |---|---| | 5 | 10 | | 6 | 15 | | 7 | 21 | | 8 | 28 | | 9 | 36 | | 10 | 45 | **Por que isso é limite duro e não preguiça.** Sutherland traz o contexto cognitivo: o estudo clássico de George Miller, de 1956, dizia que o máximo de itens retidos na memória de curto prazo é sete. Pesquisa posterior corrigiu o número: em 2001, Nelson Cowan, da Universidade do Missouri, revisou a literatura nova sobre o tema e concluiu que **o número não é sete, é quatro**. As pessoas costumam achar que memorizam mais usando mnemônicos ou concentração, mas a evidência é razoavelmente clara: retemos cerca de quatro "blocos" de informação. O exemplo canônico é a sequência de doze letras **fbicbsibmirs** — quase ninguém retém mais que quatro letras, a menos que perceba que elas se agrupam em siglas conhecidas: FBI, CBS, IBM, IRS. Ligando ao que já está na memória de longo prazo, cabe mais. Mas a parte da mente que foca — a consciente — segura cerca de quatro itens distintos por vez. E a exigência que isso contraria: num time de Scrum, como num time de forças especiais, **todo mundo tem de saber o que todo mundo está fazendo**. Todo o trabalho em curso, os obstáculos, o progresso, tem de ser transparente para os demais. Se o time cresce demais, a capacidade de todos se comunicarem com clareza com todos, o tempo todo, se embaralha. > ⚠️ **A Q9 impõe equipe grande — e a saída não é reclamar.** A turma monta equipes acima do tamanho ótimo. A resposta operacional é **subdividir em frentes com dono**, mantendo cada frente pequena e multifuncional, e aceitando o custo de coordenação entre frentes como custo explícito, com hora marcada. O que não funciona é deixar a equipe grande operar como time único e esperar que ela se organize: sem estrutura, ela se quebra socialmente em subgrupos que trabalham com propósitos cruzados, a multifuncionalidade se perde, e reuniões de minutos viram reuniões de horas. **Ação:** na tabela de subequipes que a Q9 pede, nenhuma frente deve ter mais de sete pessoas, e cada frente deve ter **um nome de dono**. Some os canais internos de cada frente e escreva o número ao lado — é a justificativa da divisão que você escolheu. --- ## 2. O custo real da multitarefa A tabela abaixo aparece em *Quality Software Management*, de Gerald Weinberg, e é reproduzida por Sutherland: | Projetos simultâneos | % do tempo disponível por projeto | Perda por troca de contexto | |---|---|---| | 1 | 100% | 0% | | 2 | 40% | **20%** | | 3 | 20% | **40%** | | 4 | 10% | **60%** | | 5 | 5% | **75%** | **A coluna da direita é desperdício puro.** Com cinco projetos, 75% do trabalho não vai a lugar nenhum — três quartos do dia jogados fora. ### O exercício que cabe em cinco minutos Sutherland usa em treinamento, e ele funciona porque a pessoa mede o próprio tempo. A tarefa: escrever os algarismos de **1 a 10**, os algarismos romanos de **I a X**, e as letras de **A a L**. O mais rápido possível. - **Primeira rodada, por linhas.** Escreva o algarismo, o romano, a letra; depois a linha seguinte. Você troca de contexto a cada símbolo. Sutherland cronometrou: **39 segundos**. - **Segunda rodada, por colunas.** Todos os algarismos, depois todos os romanos, depois todas as letras. **19 segundos** — metade. **Por que isso não é só sobre listinhas.** A explicação vem de Harold Pashler, que no início dos anos 1990 demonstrou o que chamou de **interferência de tarefa dupla**. Um grupo fazia algo muito simples — apertar um botão quando uma luz acendia. Outro grupo fazia isso mais outra tarefa simples: apertar um botão diferente conforme a cor da luz. **Assim que a segunda tarefa era acrescentada, por mais simples que fosse, o tempo dobrava.** Pashler teorizou um gargalo de processamento: as pessoas realmente só conseguem pensar em uma coisa por vez. Há um custo em "empacotar" um processo, buscar outro na memória e rodá-lo — e esse custo se paga a cada troca. ### O resultado num time real Um time decide fazer três projetos no ano — A, B e C — e planeja o ano alternando entre eles. **Fazendo tudo ao mesmo tempo, que é a estratégia clássica, terminam no fim de julho. Levando cada projeto até o fim, um por vez, terminam no começo de maio.** O projeto não muda de tamanho nem de conteúdo; só a ordem muda. E o tempo cai para pouco mais da metade. **O custo escondido, e o que ele significa para código.** Quando você trabalha em algo complicado — escrever um relatório, montar uma apresentação, desenvolver software —, você está segurando na cabeça um objeto muito complexo: dezenas de fatores, o que já foi feito, para onde se vai, quais são os impedimentos. Se você é interrompido ou tem de trocar de projeto, mesmo por um instante, **essa arquitetura mental construída com cuidado desmorona** — e pode levar horas de trabalho só para voltar ao mesmo estado de consciência. **Ação:** blocos. Junte numa mesma janela de tempo as tarefas que exigem o mesmo tipo de concentração, e proteja o bloco. Na Q9, isso significa cronograma por **blocos de foco**, não por "um pouquinho de cada coisa toda semana". --- ## 3. Trabalho pela metade é igual a zero A ideia vem do conceito de **trabalho em processo**, ou estoque, na manufatura enxuta: é desperdício ter um monte de coisa parada que não está sendo usada para construir nada. Uma montadora que só tem carros pela metade gastou muito dinheiro e esforço e **não criou nada de valor real**. Sutherland traz o exemplo doméstico. Uma lista de tarefas da semana com dez a vinte itens: repintar o banheiro, comprar ração, pagar a conta, juntar as folhas. O maior erro é tentar fazer cinco ao mesmo tempo. Imagine cinco tarefas parcialmente feitas: **uma parede do banheiro pintada, a ração ainda no porta-malas, o cheque escrito mas não enviado, as folhas amontoadas mas não ensacadas.** Esforço gasto, valor zero. O valor chega quando a lona e as latas saem do banheiro, o cachorro come, o banco recebe e o quintal está limpo. **Fazer metade de algo é, essencialmente, não fazer nada.** Em sprint, o mesmo: **se algo está pela metade no fim da sprint, você está pior do que se não tivesse começado.** Você gastou recurso, esforço e tempo e não levou nada a um estado entregável. Você tem um carro pela metade. **Teria sido melhor criar algo menor que realmente funcione.** > ⚠️ **A tradução para o Demoday.** Cinco funcionalidades a 80% não são apresentáveis. Duas funcionalidades a 100% são. Quando a equipe estiver decidindo o que cortar na última sprint, esse é o critério — e ele é o oposto do impulso natural, que é acabar tudo um pouquinho mais. --- ## 4. O que significa "pronto" Há duas definições no acervo, e elas não competem — encaixam uma na outra. ### A barra de engenharia Sutherland conta como a definição nasceu no projeto que ele descreve: em cada nota adesiva, a equipe escrevia não só **o que precisava ser criado**, mas também **como saberiam que aquilo estava pronto**. Foi assim que requisitos de conformidade regulatória, garantia de qualidade e relatórios de processo entraram no trabalho. Para a tarefa estar pronta, ela tinha de atender àqueles critérios. O ponto é o momento em que a conformidade entra: **embutida em cada item de trabalho, e não verificada no fim.** Assim, todo mundo do time — não só o pessoal de conformidade — tinha de atingir aquele nível de qualidade antes de passar ao item seguinte. **A quantidade de retrabalho que isso remove é enorme.** A definição: *pronto* é um **padrão que precisa ser atendido**, acordado antes, de modo que todo mundo saiba quando algo está pronto ou não, porque há critérios claros para qualquer peça de trabalho. **O par que dobra a velocidade duas vezes.** Para cada história deve haver uma **definição de Pronto para começar** e uma **definição de Pronto**: | | Pergunta | Efeito medido | |---|---|---| | **Pronto para começar** | Ela atende aos critérios INVEST? Há informação suficiente para completar o item? É pequeno o bastante para estimar? Existe definição de pronto? Gera valor visível? | Quando as histórias estão de fato prontas para começar, **o time dobra a velocidade de implementação** | | **Pronto** | Que condições precisam ser atendidas, que testes precisam passar, para chamar de encerrado? | Quando as histórias estão de fato prontas ao fim da sprint, **dobra de novo** | Os critérios **INVEST** que Sutherland lista para "pronto para começar": *Independente* (dá para completar sem depender de outra), *Negociável*, *Valiosa* (entrega valor a um cliente, usuário ou interessado), *Estimável* (dá para dimensionar), *Pequena* (se for grande demais, reescreva ou quebre) e *Testável* (tem um teste que precisa passar para estar completa — escreva o teste antes de fazer a história). **A regra da demonstração:** o time só demonstra o que atende à definição de pronto — **o que está total e completamente terminado e pode ser entregue sem mais nenhum trabalho.** Pode não ser um produto completo, mas deve ser uma funcionalidade completa de um. ### A barra de aprendizado Numa startup enxuta, a barra sobe: uma história só está completa quando alcança **aprendizagem validada**. O caso que Ries narra é o da Grockit, que aplicou o princípio kanban de restrição de capacidade à priorização de produto. As histórias passaram a ser catalogadas em **quatro estados**: | Estado | Significado | |---|---| | No backlog de produto | Ainda não começou | | Em desenvolvimento | Em curso | | **Concluída** | Recurso completo **do ponto de vista tecnológico** | | **Validada** | Sabe-se se a história era uma boa ideia | Validação vinha em geral na forma de teste comparativo mostrando mudança de comportamento do cliente, mas também podia ser entrevista ou sondagem. **Cada cesto aceita poucas histórias**; quando enche, não aceita mais. E o ponto que amarra: **só quando uma história foi validada é que ela pode sair do quadro**. Se a validação fracassa e a história se revela má ideia, **o recurso é removido do produto**. O efeito sobre a equipe: as equipes que trabalham nesse sistema começam a **medir a própria produtividade por aprendizagem validada, e não por produção de novos recursos**. ### Como conciliar num semestre O problema prático: verificação quantitativa leva tempo demais para caber numa sprint curta. Maurya resolve isso com **validação em duas fases**, e é essa a formulação a adotar na Q9: **Só a validação qualitativa declara a funcionalidade "pronta".** Isso libera a trava de trabalho em progresso, permitindo que outras funcionalidades comecem **enquanto mais dados são coletados**. A verificação quantitativa continua acontecendo, como estado posterior, comparando as coortes da semana em que a funcionalidade entrou no ar com a semana anterior. Traduzindo para a definição que a Q9 deve escrever: > **Pronto = padrão técnico acordado atendido + validação qualitativa com pelo menos um usuário da base de testes. A verificação quantitativa é um estado posterior, e não trava a sprint.** **Ação:** escreva a definição de pronto em uma frase, cole no quadro, e não a mude no meio do semestre. Uma definição de pronto escrita e estável vale mais para a nota do que uma cerimônia de Scrum completa e mal feita. --- ## 5. O limite de trabalho em progresso O princípio de kanban que restringe a fila de trabalho: **estabelecer limites para quantas funcionalidades podem estar em progresso ao mesmo tempo.** Isso maximiza a vazão e minimiza o desperdício. A recomendação de Maurya é operacional: **comece com um limite de trabalho em progresso igual ao número de fundadores ou de membros da equipe, e ajuste depois se precisar.** Três pessoas, três funcionalidades em andamento. Em times maiores é comum limitar também cada subestado — protótipo, demo, código —, mas Maurya considera isso exagero em equipe pequena. **A conexão com a seção 2 é o argumento inteiro:** o limite existe para impedir a equipe de se auto-sabotar com a tabela de troca de contexto. Não é burocracia; é a implementação da tabela. --- ## 6. O que entra no quadro Nem tudo. Maurya distingue **funcionalidade mínima comercializável** (MMF, do inglês *minimum marketable feature*) de funcionalidades menores e correções de defeito. O termo foi definido por Mark Denne e Jane Cleland-Huang em *Software by Numbers*: **a menor porção de trabalho que entrega valor ao cliente.** **O teste, e ele é uma pergunta:** *Você anunciaria isso aos seus clientes num post ou num informe?* **Se é pequeno demais para mencionar, não é uma MMF.** Uma MMF é normalmente composta de itens de trabalho menores. Maurya rastreia **só MMFs no quadro principal**, e usa uma ferramenta mais leve de quadro de tarefas para funcionalidades pequenas, correções e itens de trabalho. ### Os quatro complementos do quadro | Elemento | O que é | Por que existe | |---|---|---| | **Metas no topo** | Liste os objetivos e prioridades imediatas no alto do quadro | Mantém todo mundo na mesma página ao priorizar o backlog. Com limite de trabalho em progresso finito, a fila do backlog **precisa** ser priorizada contra as metas imediatas | | **Limite de trabalho em progresso visível** | Escrito na linha de cabeçalho | O limite que ninguém vê não é limite | | **Faixas de espera** | Cada etapa se divide em duas: a parte de cima para o que está "sob trabalho", a de baixo (o *buffer*) para o que foi **concluído e aguarda ser puxado** para a etapa seguinte | Torna visível o acúmulo entre etapas — o estoque em processo da seção 3 | | **Itens podem ser mortos em qualquer estágio** | Múltiplas etapas de validação com cliente estão embutidas no ciclo de vida. Se falha a validação, o item volta à etapa anterior para retrabalho **ou é morto**. Itens marcados para morrer aparecem em vermelho | Impede que uma ideia ruim atravesse o quadro só porque já entrou | **Ação:** monte o quadro na semana da Q9, ainda que vazio, com as metas escritas no topo e o número do limite no cabeçalho. Fotografe e coloque na entrega. Quadro é evidência verificável de organização; texto sobre metodologia não é. --- ## Fontes - **Sutherland, Jeff**, *Scrum* — cap. 3: tamanho de time (sete mais ou menos dois), Lei de Brooks (Fred Brooks, *The Mythical Man-Month*, 1975), o levantamento de Lawrence Putnam com 491 projetos e o dado dos 25% de esforço, a fórmula de canais n(n−1)/2 com a tabela, Miller (1956) e a correção de Cowan (2001), a exigência de transparência total no time; cap. 5: a tabela de multitarefa de Gerald Weinberg (*Quality Software Management*), o exercício das linhas e colunas com 39 e 19 segundos, a interferência de tarefa dupla de Harold Pashler, os três projetos que terminam em maio em vez de julho, o custo de reconstruir a arquitetura mental, "trabalho pela metade é igual a zero"; cap. 6 e apêndice: a definição de pronto, os critérios INVEST, o par pronto-para-começar e pronto e o duplo ganho de velocidade, a regra de só demonstrar o que está pronto - **Maurya, Ash**, *Running Lean*, cap. 13 — o limite de trabalho em progresso igual ao número de membros da equipe, o princípio de kanban de restrição de fila, MMF e o teste do informe (definição original de Denne & Cleland-Huang, *Software by Numbers*), metas no topo do quadro, faixas de espera, itens que podem ser mortos em qualquer estágio, e a validação em duas fases que declara "pronto" pela validação qualitativa - **Ries, Eric**, *A startup enxuta*, cap. 7 — o caso da Grockit: os quatro estados da história, "validada" como condição para sair do quadro, a remoção do recurso quando a validação fracassa, e a mudança da medida de produtividade para aprendizagem validada --- # 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 --- # 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.