# Instruções para a IA Você vai acompanhar um aluno do Projetão (CIn-UFPE) na quest abaixo. Este arquivo é autocontido: tudo o que você precisa está aqui. **Antes de produzir qualquer coisa:** pergunte o que a equipe já tem das quests anteriores, e declare em voz alta o modo de IA desta quest. **A regra que atravessa a disciplina:** não projetamos para nós mesmos, projetamos para os outros. Toda afirmação sobre o usuário precisa de evidência de campo. Quando o aluno disser "as pessoas querem X", pergunte quantas ele ouviu, quando, e o que disseram literalmente. Se for suposição, diga isso — não ajude a fabricar justificativa bonita. **Você não escreve a entrega no lugar do aluno.** Ele defende o resultado numa apresentação semanal. Você pergunta, critica, organiza e devolve. **Você não inventa dado de mercado, número de entrevista nem citação.** Se falta evidência, o certo é dizer que falta. E você nunca escreve a fala de um entrevistado que não existiu, nem "completa" uma entrevista curta. --- # Quest #6 — MVP & Prova de Conceito > **Objetivo.** Apresentar o MVP e sua prova de conceito. | | | |---|---| | **Modo de IA** | 🟢 coprodução na construção · 🔴 sem assistência na validação com usuário | | **Milestones** | **Solução**, **Prova de conceito** e **MVP/Implementação** (os três abrem aqui) | | **Entrega** | definição do MVP + evidência de que o usuário vê valor nele | | **Erro que mais custa** | construir antes de testar o conceito | --- ## MVP: a definição exata, e as duas negações > O MVP permite ao empreendedor **iniciar o processo de aprendizagem o mais rápido possível**. Não é necessariamente o menor produto imaginável, mas simplesmente o método mais rápido de percorrer o ciclo construir-medir-aprender com o menor esforço possível. > > — Eric Ries, *A startup enxuta* Duas negações explícitas, e as duas derrubam projeto de aluno: **1. MVP não é desenvolvimento tradicional em versão reduzida.** O objetivo do MVP é **começar** o processo de aprendizado, não encerrá-lo. **2. MVP não é protótipo nem teste de conceito.** Diferente deles, o MVP não responde apenas a perguntas de design ou técnicas: **ele testa hipóteses de negócio fundamentais.** > **Critério de corte para a quest:** se o artefato só responde *"dá pra construir?"* ou *"a tela está boa?"*, é protótipo. Se responde *"alguém quer isso a ponto de agir?"*, é MVP. ### Sobre qualidade O MVP colide com a noção tradicional de qualidade, e o argumento é este: todas as filosofias de qualidade pressupõem que já se sabe o que o cliente valoriza — pressuposto arriscado aqui. > **Se não sabemos quem é o cliente, também não sabemos o que é qualidade.** — Eric Ries Mas há um contrapeso explícito, e ele importa para não virar desculpa: **isso não significa trabalhar de forma desleixada ou indisciplinada.** Certos problemas de qualidade **desaceleram** o ciclo de aprendizado — bug dificulta evoluir o produto e limita a própria capacidade de aprender. Tolerar defeito em qualquer processo produtivo é jogo perigoso. A regra que fecha: **elimine toda funcionalidade, processo ou esforço que não contribua diretamente para o aprendizado desejado.** --- ## Prova de conceito — e por que ela vem antes Processo que testa e valida a ideia **em ambiente controlado e limitado**, para determinar viabilidade técnica e comercial **antes de investir recursos significativos**. A pergunta que ela responde: **o usuário vê valor nisso? Usaria? Pagaria?** **A PoC pode ser bem simples, sem uma linha de código.** > Exemplo da disciplina: você quer controlar a TV por voz. Testa o conceito; 90% dizem que sim. Só então implementa o MVP. O que ele exige? Microfone, tela, interface, uma caixa, feedback sonoro ou visual — e o usuário pode estar sentado, sem controle na mão. A equipe atenta a isso sugere alterações, que serão testadas na Q8. --- ## Os cinco tipos de MVP Escolha pela **pergunta que você precisa responder**, não pela que é mais divertida de construir. | Tipo | Pergunta que responde | Caso conhecido | |---|---|---| | **Smoke test** | As pessoas demonstram intenção de agir diante da promessa, antes de existir produto? | pouco mais que um anúncio | | **Vídeo** | A proposta é entendida e desejada, quando o produto é impossível de prototipar? | Dropbox: vídeo de 3 min levou a lista de espera de 5 mil para 75 mil pessoas | | **Concierge** | Entregando **manualmente**, um cliente por vez, o que o produto precisa ter? | Food on the Table: um único cliente, uma loja, zero software, cheque de US$9,95/semana | | **Mágico de Oz** | Se resolvermos o problema técnico difícil, as pessoas usam? | Aardvark: 8 pessoas respondendo por trás da cortina, 9 meses antes de automatizar | | **Landing page** | O problema vale a pena? Quantos se inscrevem? O canal funciona? | página com sumário e capa, feita em um dia, 1.000 e-mails coletados | **Distinção crucial sobre o concierge:** não é virar uma pequena empresa artesanal. O serviço manual é **temporário**, existe só enquanto se testa o modelo. E o resultado *médio* de um concierge é revelar que o modelo de crescimento planejado **não** funciona — o que é exatamente o valor dele. > Nota honesta sobre uma frase famosa: a formulação célebre "construa metade de um produto, não um produto pela metade" é atribuída a este autor mas **não foi verificável** no texto disponível. O que existe, e é citável, é o caso do IMVU: a equipe não conseguia fazer os avatares andarem, trocou caminhada por teletransporte, sentiu-se ridícula entregando essa **meia-solução** — e os clientes elegeram o teletransporte entre as três coisas que mais gostavam. Use o caso, não a frase. --- ## Por que o modo de IA se divide aqui **🟢 coprodução Construir é coprodução.** É a quest em que a IA mais acelera. Trate como coprodução de verdade: defina o critério de aceitação **antes** de gerar, e verifique depois. A régua da disciplina subiu justamente aqui — espera-se sistema que funciona. **🔴 sem assistência Validar é sem assistência.** E não é só porque a IA não pode ir a campo: **a IA vai aprovar o seu MVP.** Ela é complacente por construção. Se você perguntar "isso está bom?", vai ouvir que sim. > Um MVP validado por IA é um MVP não validado. --- ## As perguntas da entrega 1. **Do que se trata a solução?** Aplicativo? Produto físico? Website? Serviço? 2. **Qual é a sua estratégia?** Em forma de curva de valor: o que vão **eliminar, diminuir, aumentar e criar**. 3. **O que é minimamente necessário** para entregar os valores propostos? 4. **Como a solução altera a jornada** do usuário e/ou cliente? Como a persona resolve o problema usando o que vocês propõem? 5. **Seus usuários/clientes aprovaram a ideia?** Há evidência de que faz sentido, de que pagariam? **Quantas pessoas você ouviu?** *Nesta quest não precisa prototipar.* **Piso: 5 pessoas na prova de conceito** — abaixo disso não há sinal, e o milestone fica com teto de nível 3. Ver `metodo/carga.md`. A pergunta 2 repete a curva da Q5 de propósito: agora ela é sobre **o seu produto**. É o que impede o escopo de explodir — cada item na coluna "criar" é semana de trabalho. A pergunta 4 é a mais reveladora: se você não consegue descrever a jornada nova passo a passo, o MVP ainda está vago. --- ## A entrevista de solução Distinta da entrevista de problema da Q2. **Teste a solução com uma demo antes de construir o produto de verdade** — porque a maioria dos clientes é ótima em articular problemas, e ruim em visualizar soluções. | Bloco | Tempo | O que testa | |---|---|---| | Boas-vindas | 2 min | — | | Coletar demografia | 2 min | segmento | | Contar uma história | 2 min | contexto do problema | | **Demo** | **15 min** | a solução | | **Testar preço** | **3 min** | fontes de receita | | Fechamento — o pedido | 2 min | compromisso + indicações | | Documentar | 5 min | — | **O que muda em relação à Q2:** saem o ranqueamento de problemas e a exploração da visão de mundo; entram a demo e o teste de preço. Na entrevista de problema você **ouve**; nesta você **mostra e mede a reação**. **Portão explícito:** se não houver forte ressonância com o problema no bloco da história, **não continue** — volte ao roteiro de problema. **Critério de saída:** você terminou quando consegue identificar a demografia do usuário afoito, tem um problema *must-have*, sabe definir as funcionalidades mínimas, tem um preço que o cliente aceita, e consegue montar um negócio em cima disso numa conta de padeiro. ### As cinco diretrizes da demo 1. **Realizável.** Demo em tecnologia que você não vai usar vende bem e cria elementos impossíveis de recriar — descolando o prometido do entregue. 2. **Parecer real.** Wireframe cru exige salto de fé do cliente. Quanto mais real a demo parece, mais precisamente você testa. 3. **Rápida de iterar.** Você vai receber feedback e precisa incorporá-lo na entrevista seguinte. 4. **Minimizar desperdício.** Comece em papel, e converta para a tecnologia final em algum ponto. 5. **Dados realistas.** Nada de *lorem ipsum* — dados verossímeis sustentam a narrativa. *Design sem conteúdo não é design, é decoração.* ### Duas orientações de preço que contrariam o instinto - **Não pergunte quanto pagariam — diga o preço** e meça a reação. Não há justificativa econômica para o cliente oferecer outra coisa que não um valor baixo. - **Não reduza a fricção de cadastro — aumente.** Facilitar o "sim" atrasa a validação, e compromisso fraco prejudica o aprendizado. --- ## Reduzir para o Release 1.0 O perigo depois das entrevistas é iterar mockups e acabar com mais do que o MVP precisa. A receita, em ordem: 1. **Zere a lista.** Nenhuma funcionalidade entra automaticamente. 2. **Comece pelo problema nº 1.** O trabalho da PUV é fazer uma promessa convincente; o trabalho do MVP é **cumpri-la**. 3. **Rotule cada elemento** como *must-have*, *nice-to-have* ou *don't-need*. Elimine os *don't-need*; mande os *nice-to-have* para o backlog. 4. Repita para os problemas 2 e 3. 5. **Cobre desde o dia 1**, mas colete no dia 30. 6. Foque em aprendizado, não em otimização. > Seu MVP deve ser como um bom molho reduzido: concentrado, intenso e saboroso. --- ## Prototipagem paralela Explorar várias alternativas ao mesmo tempo produz **resultado melhor, mais divergência e maior autoeficácia** — é o achado de um estudo publicado no ACM ToCHI (Dow et al., 2010), e o título do artigo já é a conclusão. O mecanismo: iterar **sozinho** sobre uma ideia sobe o morro mais próximo; explorar em paralelo permite descobrir que havia uma montanha ao lado. O ponto mais contraintuitivo: **a avaliação dos protótipos não serve para escolher o melhor.** Serve para o time refletir sobre como as pessoas reagem a **elementos individuais** — e depois fundir as melhores qualidades de todos num design superior. E o corolário: protótipos iniciais devem ser rápidos, toscos e baratos. **Quanto maior o investimento numa ideia, mais comprometido você fica com ela** — e uma ideia medíocre pode ir longe demais. --- ## Os dez tipos de pivô Para a equipe cujo projeto não está funcionando. Pivô não é mudança qualquer: é um tipo específico de mudança **cujo objetivo é testar uma hipótese fundamental** sobre produto, modelo de negócio ou motor de crescimento. | Pivô | O que muda | |---|---| | **Zoom-in** | Uma funcionalidade vira o produto inteiro | | **Zoom-out** | O produto inteiro vira uma funcionalidade de algo maior | | **Segmento de cliente** | O produto resolve problema real, mas de **outro** público | | **Necessidade do cliente** | O cliente é o certo; o problema atacado não é o que importa para ele | | **Plataforma** | De aplicação para plataforma, ou o inverso | | **Arquitetura de negócio** | Entre margem alta/volume baixo e margem baixa/volume alto | | **Captura de valor** | Como o valor gerado é monetizado | | **Motor de crescimento** | Entre viral, pegajoso e pago | | **Canal** | A mesma solução chega ao cliente por outro caminho | | **Tecnologia** | Mesmo resultado, tecnologia diferente | **O aviso que fecha o catálogo:** trate o pivô como **nova hipótese estratégica, que precisa ser testada com um novo MVP**. Os casos famosos só mostram a estratégia final bem-sucedida — a narrativa heroica do fundador esconde as tentativas. --- ## Referências desta quest | Arquivo | Quando | |---|---| | **Os cinco tipos de MVP — Quest #6** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-06.md) | Ao escolher o formato. Os cinco tipos em detalhe, com os casos | | **A entrevista de solução — Quest #6** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-06.md) | Antes de entrevistar. Roteiro, falas, teste de preço, critérios de saída | | **Pivotar — Quest #6** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-06.md) | Se o projeto não estiver funcionando. Os dez pivôs e como decidir | | **Autodiagnóstico — Quest #6** (neste arquivo) | Antes de entregar | --- ### Antes de registrar pessoas | Arquivo | Quando | |---|---| | `../../metodo/consentimento.md` | Antes de testar a prova de conceito com pessoas | --- ### Técnicas desta quest Fichas curtas de consulta rápida. Abra quando o procedimento acima mencionar a técnica. | Ficha | Para quê | |---|---| | **Brainstorm** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-06.md) | gerar formatos de prova de conceito | | **Brainwriting** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-06.md) | quando a equipe é desigual | | **Wireframe** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-06.md) | o esqueleto antes da estética | | **Usuário afoito (*early adopter*)** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-06.md) | quem testa a PoC | | **Entrevistas** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-06.md) | o roteiro da conversa de solução | --- ## Perguntas frequentes **"Como sabemos se o projeto está simples ou grande demais?"** Não faça penduricalhos — ajustes cosméticos que não entregam valor. E não existe trabalho simples demais: o que se entrega é um MVP, um artefato **funcionando plenamente** que contém apenas o relevante para quem usa. **"Não sei nada de marketing/gestão. Vai ter aula?"** Durante as aulas há explicações de 10 a 15 minutos de cada conceito, com referências para aprofundar. A disciplina estimula autonomia porque, num cenário real, não haverá apoio. --- ## Bibliografia desta quest | Obra | O que ela dá para a Q6 | |---|---| | **Ries — A startup enxuta** | A definição de MVP, os tipos, aprendizado validado, os dez pivôs | | **Maurya — Running Lean** | Entrevista de solução, diretrizes da demo, redução para o Release 1.0 | | **Blank — The Four Steps to the Epiphany** | Customer validation: o portão entre descobrir e escalar | | **Brown — Change by Design** | Protótipo rápido, tosco e barato; prototipar para pensar | | **Hanington & Martin — Universal Methods of Design** | Prototipagem paralela, bodystorming, role-playing, Mágico de Oz | --- # 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. --- # Autodiagnóstico — Quest #6 Faça este exercício **antes** de entregar. É o mesmo que o mentor vai fazer depois. --- ## Os milestones que abrem aqui A Q6 alimenta dois dos 13 milestones: **Solução** (o que vocês propõem e por que ela entrega a proposta única de valor) e **MVP/Implementação** (o que existe de fato, funcionando). A aprovação exige nível 4 em todos. | Nível | Significado | |---|---| | **0** | O critério ainda não aparece. | | **1** | Já aparece, mas sem clareza nem coerência. | | **2** | Falta clareza **ou** falta coerência com o resto. A resposta ainda está no terreno da insegurança. | | **3** | Coerente, mas ainda não totalmente claro. Resta uma parcela de incerteza. | | **4** | Claro e coerente com toda a proposta. A equipe responde com segurança. | | **5** | Perfeitamente alinhado ao conjunto. As respostas são sólidas. | O salto que trava a maioria é o **3 → 4**, e na Q6 ele tem um nome preciso: sair de *"mostramos para umas pessoas e elas gostaram"* para *"pedimos um compromisso a doze pessoas, cinco deram, e o preço que sustenta a conta é este"*. --- ## Rubrica — milestone Solução ### 1. Natureza da solução | | | |---|---| | **2** | "É um app". A categoria é a única descrição. | | **3** | Aplicativo, serviço ou produto físico está definido, mas o que o usuário faz nele ainda é vago. | | **4** | A equipe descreve o artefato, o que ele faz, para quem, e por que **essa** forma e não outra. | | **5** | O acima, mais as formas descartadas e o critério de descarte. | ### 2. Estratégia em curva de valor | | | |---|---| | **2** | A curva da Q5 foi copiada sem alteração, ou não há curva. | | **3** | Há as quatro colunas — eliminar, diminuir, aumentar, criar —, mas todas as funcionalidades caem em "criar". | | **4** | Cada item de "criar" está justificado, e a equipe sabe dizer quantas semanas ele custa. Há itens reais em "eliminar". | | **5** | O acima, com a curva do produto comparada à curva dos concorrentes da Q3, no mesmo eixo de fatores de competição. | ### 3. Mínimo necessário | | | |---|---| | **2** | A lista de funcionalidades é a lista de desejos da equipe. | | **3** | Há corte, mas o critério é esforço de implementação. | | **4** | Cada elemento está rotulado como *must-have*, *nice-to-have* ou *don't-need*, com base no que foi ouvido; os *nice-to-have* estão em backlog nomeado. | | **5** | O acima, e a equipe consegue dizer qual **promessa da PUV** cada *must-have* cumpre. | ### 4. Jornada alterada | | | |---|---| | **2** | A jornada nova é descrita como "fica mais fácil". | | **3** | Há um fluxo de telas, mas não há a jornada anterior para comparar. | | **4** | Jornada de antes e jornada de depois, passo a passo, com a persona da Q1 percorrendo as duas; fica visível onde a gambiarra desaparece. | | **5** | O acima, com os passos que **continuam ruins** depois da solução, assumidos. | --- ## Rubrica — milestone MVP/Implementação ### 5. Escolha do formato de MVP | | | |---|---| | **2** | Nenhuma escolha consciente; construiu-se o que a equipe sabia construir. | | **3** | O formato foi escolhido, mas não está ligado a uma hipótese. | | **4** | Formato escolhido **a partir da pergunta em aberto**, com a hipótese escrita de forma falseável antes de rodar. | | **5** | O acima, com o registro de por que os outros quatro formatos responderiam pior. | ### 6. Evidência com usuário | | | |---|---| | **2** | Feedback de colegas de turma e de familiares. | | **3** | Demonstração para gente do público certo, com registro de opinião. | | **4** | Entrevistas de solução com roteiro cronometrado, ficha por entrevista preenchida individualmente, e **um pedido de compromisso** feito ao final de cada uma; o número de pedidos e o de aceites está registrado. | | **5** | O acima, com um segundo lote rodado depois de ajustar a demo, e a variação entre lotes explicada. | ### 7. Preço | | | |---|---| | **2** | Não se falou de preço. | | **3** | Perguntou-se ao cliente quanto ele pagaria. | | **4** | O preço foi **dito** ao cliente e a reação foi medida, com registro de quem hesitou; há uma faixa e a âncora usada está nomeada. | | **5** | O acima, com um preço mais alto testado depois de a primeira faixa não ter gerado resistência. | ### 8. O que funciona | | | |---|---| | **2** | Telas navegáveis sem nada por trás, apresentadas como sistema. | | **3** | Parte do fluxo funciona; o restante é simulado, e isso não está declarado. | | **4** | O caminho principal funciona de ponta a ponta, e o que é simulado está **explicitamente declarado** — inclusive o que é operado à mão. | | **5** | O acima, com defeitos conhecidos listados e a decisão consciente de tolerá-los ou não, à luz do efeito deles sobre a velocidade de aprendizado. | --- ## Checklist rápido - [ ] Consigo dizer, numa frase, **qual hipótese** o meu MVP testa? - [ ] O artefato responde "alguém quer isso a ponto de agir?" — ou só "dá para construir?" - [ ] Para cada funcionalidade que ficou, sei qual aprendizado ela sustenta? - [ ] Pedi um compromisso ao final das entrevistas, ou só agradeci? - [ ] Disse o preço em vez de perguntar? - [ ] Anotei quem hesitou? - [ ] Existe alguma coisa na demo que a equipe **não** consegue construir na tecnologia final? - [ ] Alguma entrevista me fez cortar uma funcionalidade — ou todas confirmaram a lista original? - [ ] Se a resposta ao MVP tivesse sido negativa, o que exatamente eu teria feito? **Sinal de alerta:** se nenhuma entrevista de solução cortou nada da lista, ou a demo estava vendendo em vez de testando, ou vocês só mostraram para quem já torcia pelo projeto. **Segundo sinal:** se a equipe descreve o MVP pelo que ele *terá*, e não pelo que ele *já mede*, o artefato ainda é um plano de produto. --- ## Registro de trajetória (modo de IA) Meia página, entregue junto. Ver `metodo/modo-ia.md` para o racional. 1. **Modo em que a quest foi feita, e onde você saiu dele.** *Na Q6, construir é 🟢 coprodução e validar é 🔴 sem assistência. Se a IA participou da leitura dos resultados de campo, diga.* 2. **O que a IA gerou e você descartou — e por quê.** *Típico da Q6: a IA propõe um conjunto de funcionalidades "essenciais" a partir da descrição do produto. Essa lista é hipótese, não escopo. Se vocês a cortaram depois das entrevistas, esse é o registro mais valioso da quest.* 3. **O que você verificou, e como.** *Típico da Q6: o critério de aceitação do código gerado, e o teste que confirmou que o caminho principal funciona com dado real.* 4. **O que ainda não sabe.** *Exemplos honestos: "não testamos com ninguém fora de Recife"; "o trecho X é operado à mão e não sabemos o custo dele em escala".* > Um MVP validado por IA é um MVP não validado. --- ## Como o mentor vai ler Quatro perguntas frequentes na apresentação da Q6. Se você responde às quatro, está em 4. 1. **"Quantas pessoas viram isso, e o que elas fizeram depois?"** Resposta fraca: "todo mundo achou legal". Resposta forte: número de demos, número de pedidos de compromisso, número de aceites. 2. **"O que é minimamente necessário aqui — e o que vocês tiraram?"** A segunda metade da pergunta é a que vale. Sem itens removidos, não houve redução. 3. **"Quanto vocês disseram que ia custar, e o que aconteceu?"** Se a equipe perguntou em vez de dizer, o dado é fraco e é preciso admitir isso. 4. **"O que nesta demo não existe de verdade?"** Responder com naturalidade é sinal de maturidade; ser pego é o pior desfecho possível da Q6. Divergência entre a sua auto-avaliação e a leitura do mentor é informação útil, não constrangimento. --- > Versão leve. As referências completas desta quest estão em > https://projetao-ufpe.vercel.app/baixar/colar/projetao-06.md