# Instruções para a IA Você vai acompanhar um aluno do Projetão (CIn-UFPE) na quest abaixo. Este arquivo é autocontido: tudo o que você precisa está aqui. **Antes de produzir qualquer coisa:** pergunte o que a equipe já tem das quests anteriores, e declare em voz alta o modo de IA desta quest. **A regra que atravessa a disciplina:** não projetamos para nós mesmos, projetamos para os outros. Toda afirmação sobre o usuário precisa de evidência de campo. Quando o aluno disser "as pessoas querem X", pergunte quantas ele ouviu, quando, e o que disseram literalmente. Se for suposição, diga isso — não ajude a fabricar justificativa bonita. **Você não escreve a entrega no lugar do aluno.** Ele defende o resultado numa apresentação semanal. Você pergunta, critica, organiza e devolve. **Você não inventa dado de mercado, número de entrevista nem citação.** Se falta evidência, o certo é dizer que falta. E você nunca escreve a fala de um entrevistado que não existiu, nem "completa" uma entrevista curta. --- # Quest #4 — Oportunidade Escolhida & Organização da Equipe > **Objetivo.** Apresentar a oportunidade escolhida e a organização da equipe. | | | |---|---| | **Modo de IA** | 🔴 sem assistência nas conversas de confirmação · 🟡 com apoio no resto — a decisão é da equipe | | **Milestones** | consolida **Usuário**, **Problema** e **Similares** | | **Entrega** | uma oportunidade, com evidência; papéis definidos | | **Erro que mais custa** | escolher por votação, e não por evidência | | **Natureza** | ⚠️ **checkpoint** — os professores validam aqui, conforme as evidências | --- ## Por que esta quest existe Ela foi acrescentada quando a metodologia passou de 9 para 10 quests, e o motivo é observável: as equipes escolhiam mal, cedo demais, e descobriam tarde. **Não é votação.** Escolher por maioria dentro da equipe não vale — e não porque a democracia seja ruim, mas porque a escolha da maioria não é necessariamente validada pelos professores. **Eles vão olhar as evidências.** A escolha vem do que vocês observaram dos usuários e clientes. Tem de ficar claro: 1. que o problema é **relevante** — porque impacta muita gente, ou porque impacta muito algumas pessoas; 2. que as **soluções atuais não resolvem satisfatoriamente**, e portanto há espaço. --- ## Como escolher: risco, não preferência ### Primeiro, separe incerteza de risco São coisas diferentes, e confundi-las faz a equipe paralisar diante de "tudo é incerto". - **Incerteza** — falta de certeza completa: existe mais de uma possibilidade. - **Risco** — um estado de incerteza em que **alguma das possibilidades envolve perda**, catástrofe ou outro resultado indesejável. Você pode ser incerto sobre muitas coisas que não são arriscadas. O que qualifica uma incerteza como risco é haver **perda associada**. E risco se mede combinando **probabilidade** com **perda quantificada**: "40% de chance de o poço sair seco, com perda de R$ 12 milhões" é uma medição de risco. "É arriscado" não é. Consequência prática na Q4: o risco que você deve atacar primeiro não é o que parece mais assustador — é o que combina probabilidade alta **com** perda alta. Um evento catastrófico de probabilidade ínfima pode esperar. Detalhamento e as fórmulas em **Decidir sob incerteza — Quest #4** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-04.md). ### Depois, ranqueie as oportunidades — nesta ordem Coloque as 2–3 oportunidades lado a lado. A ordem de peso, da maior para a menor: | # | Critério | Por quê | |---|---|---| | 1 | **Nível de dor do cliente** | Priorize o segmento que mais precisa. A meta é ter um dos seus três problemas como ***must-have*** — não *nice-to-have* | | 2 | **Facilidade de alcance (canais)** | Construir caminho até o cliente é das partes mais difíceis. Alcance fácil não garante problema válido nem negócio viável, mas **tira você do prédio mais rápido e acelera o aprendizado** — e num semestre isso pesa mais que numa startup | | 3 | **Preço e margem** | O que se pode cobrar é largamente determinado pelo segmento. Mais margem = menos clientes para se pagar | | 4 | **Tamanho de mercado** | Grande o bastante **dados os objetivos** do projeto | | 5 | **Viabilidade técnica** | Por último — e note que é o único critério que a maioria das equipes de computação usa primeiro | Os três tipos de risco que você está ranqueando: **risco de produto** (acertar o produto), **risco de cliente** (construir caminho até ele), **risco de mercado** (viabilizar o negócio). > A priorização incorreta de risco é um dos maiores contribuintes de desperdício. --- ## As perguntas da entrega 1. **Qual a oportunidade escolhida?** Por que ela seria a mais relevante? **Quais evidências mostram isso?** 2. **Quem é o cliente e quem é o usuário?** São a mesma pessoa? 3. **Quem é o público mais disposto a interagir com a equipe?** Quem é o **usuário afoito**? 4. **Qual a jornada do usuário?** Passo a passo de como ele resolve o problema **hoje**, sem a sua solução. 5. **Qual o mercado-alvo e o tamanho dele?** Com evidência. 6. **Por que a concorrência não resolve plenamente?** 7. **Quem são as lideranças da equipe e suas funções?** --- ## Cliente ≠ usuário > **Um cliente é alguém que paga pelo seu produto. Um usuário não.** — Ash Maurya Regras que acompanham: - **Divida segmentos amplos em menores.** Você não consegue construir, projetar e posicionar um produto para todo mundo. Até o Facebook começou com um usuário muito específico: alunos de Harvard. - **Em modelo de dois lados**, comece com um único canvas usando cor ou etiqueta por segmento, e divida só depois. - **Seus usuários gratuitos não são seus clientes** — ainda. Dois grupos são segmentos **distintos** quando: suas necessidades justificam oferta distinta; são alcançados por canais diferentes; exigem relacionamento diferente; têm rentabilidade substancialmente diferente; ou pagam por aspectos diferentes da oferta. --- ## Usuário afoito — a escala de dor O termo técnico é *early adopter*, e há uma definição operacional muito mais útil que "quem gosta de novidade". São clientes visionários que **não só espalham a notícia sobre produtos inacabados e não testados, como também os compram**. A escala de cinco degraus: 1. O cliente **tem** um problema. 2. O cliente **entende** que tem um problema. 3. O cliente está **ativamente procurando** solução, e tem prazo para achá-la. 4. O problema dói o bastante para o cliente ter **montado uma solução provisória** — a gambiarra. 5. O cliente **comprometeu, ou consegue rapidamente, orçamento** para resolver. > **O usuário afoito está nos degraus 4 e 5.** Quem está nos degraus de baixo é adotante tardio (*late adopter*), e o feedback dele não serve agora. Isso conecta direto com a Q2: **quem você viu usando a gambiarra mais elaborada é o seu candidato mais forte** — porque a gambiarra *é* o degrau 4. Duas ressalvas: usuários afoitos estão em papéis **operacionais**, não em laboratórios de pesquisa ou comitês de avaliação técnica — estes influenciam a compra mas não têm autoridade de adoção. E eles querem falar com quem constrói, não com um vendedor. Identifique **nominalmente**. "Estudantes universitários" não é usuário afoito; é demografia. --- ## Tamanho de mercado sem inventar número Duas ferramentas que substituem o chute e o "segundo o IBGE, 1 milhão de pessoas": **Decomposição de Fermi.** Quebre o número grande em fatores que você consegue estimar. Além de produzir a estimativa, a decomposição mostra **de onde vem a incerteza** — e o fator mais incerto é justamente o que vale a pena medir. **Faixa calibrada de 90%, não número único.** Em vez de "o mercado é de 1 milhão", diga "entre 400 mil e 1,6 milhão, com 90% de confiança". É mais honesto e mais defensável na banca. E a notícia boa para quem acha que precisa de 400 respostas: **você precisa de menos dados do que pensa.** As primeiras observações são as de maior retorno em redução de incerteza. Ver **Decidir sob incerteza — Quest #4** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-04.md) para a **Regra dos 5** — e o argumento de por que cinco pessoas já dizem muito. --- ## Organização da equipe Papéis que a disciplina espera ver, cada um com **nome de pessoa ao lado**: - **Gerente de projeto** — mantém o projeto andando numa direção - **Líder técnico** — implementação - **Líder de UX / experiência** — usabilidade, testes com usuário - **Líder de negócios** — modelo de receita, mercado - **Relacionamento com usuários e comunidade de testes** — pode acumular, mas precisa ter dono Três achados que ajudam a dimensionar: **Tamanho.** A formulação clássica é sete pessoas, mais ou menos duas. Acima de nove, a velocidade **cai**. Os canais de comunicação crescem por n(n−1)/2: cinco pessoas geram 10 canais; nove geram 36. Num levantamento de 491 projetos, grupos de 3 a 7 pessoas exigiram cerca de **um quarto do esforço** de grupos de 9 a 20 para o mesmo trabalho. Regra: erre para o lado pequeno — se a turma impõe equipes grandes, **subdivida em frentes com dono**. **Um único dono do "quê".** Separe quem decide **o que** deve ser feito de quem cuida de **como** o time trabalha. Duas pessoas decidindo prioridade é a origem mais comum de paralisia. **Multifuncionalidade.** O time precisa ter todas as habilidades necessárias para completar o projeto — não pode depender de alguém de fora para fechar uma entrega. --- ## Atenção **As decisões desta quest não são definitivas.** É comum que sejam revistas, e em alguns casos abandonadas em favor de outro projeto. Nenhuma escolha é irreversível. Mas isso não autoriza escolher de qualquer jeito. **Escolha errada vira aprendizado; escolha impensada, feita só para se livrar da tarefa, vira bola de neve.** --- ## Referências desta quest | Arquivo | Quando | |---|---| | **Decidir sob incerteza — Quest #4** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-04.md) | Ao comparar as oportunidades. Incerteza × risco, valor da informação, estimativa calibrada, regra dos 5, Fermi | | **Usuário afoito — Quest #4** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-04.md) | Ao definir com quem falar. A escala de dor, onde encontrar, o que perguntar | | **Organização da equipe — Quest #4** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-04.md) | Ao distribuir papéis. Tamanho, canais de comunicação, os três papéis, conflito | | **Autodiagnóstico — Quest #4** (neste arquivo) | Antes de entregar | --- ### Técnicas desta quest Fichas curtas de consulta rápida. Abra quando o procedimento acima mencionar a técnica. | Ficha | Para quê | |---|---| | **Usuário afoito (*early adopter*)** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-04.md) | como reconhecer o usuário afoito | | **Jornada do Usuário** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-04.md) | a jornada atual, sem a sua solução | | **Lean Innovation** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-04.md) | por que priorizar risco em vez de preferência | | **Brainstorm** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-04.md) | gerar alternativas de recorte | --- ## Perguntas frequentes **"Me sinto perdido na equipe — uns sobrecarregados, outros parados."** Um dos desafios da disciplina é operar em equipe grande que precisa se auto-gerenciar: ninguém gerencia de fora. Duas coisas resolvem a maior parte disso. **Papéis e responsabilidades claros.** E **colaboração ativa**: mesmo sem entender de design, você pode ajudar a construí-lo. Ninguém é especialista profundo em nada numa startup. Se algo não está sendo feito, faça — na pior hipótese, alguém melhora o que você começou. **"O ambiente está tóxico, há muito conflito, não me sinto ouvido."** Conflito e discussão não são o problema — são sinal de que o resto do mundo não pensa como você. O que resolve disputa não é convicção: é teste e evidência. Se você não está sendo ouvido, traga evidência do caminho que propõe — e esteja aberto a estar errado se ela apontar o contrário. A opinião de qualquer integrante é irrelevante frente às decisões de projeto. Se suas contribuições são opinativas, não ser ouvido é até bom sinal. Se for o oposto — você traz hipótese testada e a equipe ignora em favor de preferência pessoal —, aí talvez seja caso de mudar de grupo. --- ## Bibliografia desta quest | Obra | O que ela dá para a Q4 | |---|---| | **Hubbard — How to Measure Anything** | Incerteza × risco, valor da informação, estimativa calibrada, regra dos 5, Fermi | | **Maurya — Running Lean** | Priorização por risco, ordem de ranqueamento, cliente × usuário | | **Blank — The Four Steps to the Epiphany** | O earlyvangelist e a escala de cinco degraus | | **Osterwalder & Pigneur — Business Model Generation** | Quando dois grupos são segmentos distintos; plataforma multilateral | | **Sutherland — Scrum** | Tamanho de equipe, canais de comunicação, separação dos papéis | | **Ries — A startup enxuta** | Bibliografia oficial da quest no site | --- # 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 #4 Rode isto **dois dias antes** do checkpoint, não na véspera. A Q4 consolida três milestones — **Usuário**, **Problema** e **Similares** — e os professores validam conforme as evidências. Um dia sobrando é o que permite ir a campo tapar um buraco. Pontue cada milestone de 0 a 5. **Some no fim e leia a régua.** --- ## Rubrica — Usuário | Nota | Estado | |---|---| | 0 | O usuário é uma demografia: "estudantes", "pequenos comerciantes", "professores". | | 1 | Há um recorte, mas ninguém da equipe falou com ninguém desse recorte. | | 2 | Houve conversas, mas com quem estava à mão — colegas, parentes, quem já era conhecido. | | 3 | Cliente e usuário estão distinguidos e nomeados, e a equipe sabe dizer se são a mesma pessoa. | | 4 | Há pessoas identificadas **nominalmente** no degrau 3 da escala de dor: procuram solução ativamente, com prazo. | | 5 | Há pelo menos duas pessoas nominalmente identificadas no **degrau 4 ou 5** — com gambiarra observada, registrada com data e local — e todas estão em **papel operacional**, não em papel de avaliação ou consultoria. | --- ## Rubrica — Problema | Nota | Estado | |---|---| | 0 | O problema é a ausência da solução que a equipe queria construir. | | 1 | O problema está descrito, mas a evidência é a experiência pessoal de alguém da equipe. | | 2 | Há evidência de campo, mas ela não distingue **fato observado** de **inferência**. | | 3 | A jornada atual do usuário está mapeada passo a passo, **sem a solução de vocês**. | | 4 | A relevância está sustentada por um dos dois caminhos: impacta muita gente, **ou** impacta muito algumas pessoas — e há número, com origem declarada, para o caminho escolhido. | | 5 | O problema aparece entre os três primeiros na **ordenação feita pelos próprios usuários**, e há indício de que é *must-have* e não *nice-to-have*. O custo do problema para o usuário está quantificado — em tempo, dinheiro ou clientes perdidos. | --- ## Rubrica — Similares | Nota | Estado | |---|---| | 0 | "Não existe nada parecido." | | 1 | Há uma lista de concorrentes diretos, montada por busca na internet. | | 2 | A lista inclui **alternativas existentes** que não são produtos: planilha, caderno, grupo de mensagens, não fazer nada. | | 3 | Para cada alternativa existente está registrado **o que ela entrega** e **o que ela deixa de entregar**. | | 4 | O "não resolve plenamente" está sustentado por fala de usuário, não por avaliação técnica da equipe. | | 5 | A equipe sabe dizer **por que a alternativa sobrevive** apesar das falhas — o que ela faz bem e vocês teriam de fazer igual ou melhor. Isso é a matéria-prima da curva de valor da Q5. | --- ## Rubrica — Escolha e equipe | Nota | Estado | |---|---| | 0 | A oportunidade foi escolhida por votação ou por preferência técnica. | | 1 | Há justificativa escrita, mas ela é argumentativa e não cita evidência. | | 2 | As 2–3 oportunidades foram comparadas, mas só em viabilidade técnica. | | 3 | A comparação seguiu a ordem de peso: dor, alcance, preço e margem, tamanho, viabilidade técnica. | | 4 | Cada oportunidade tem **risco medido** — probabilidade e perda quantificada em semanas de equipe —, não apenas adjetivado. | | 5 | Está calculada a perda de oportunidade esperada de cada alternativa, e as medições cujo custo é menor que ela viraram tarefas com prazo e dono. Os papéis estão distribuídos com **nome de pessoa**, e quem decide **o quê** não é a mesma pessoa que cuida do **como**. | --- ## A régua | Soma (0–20) | Leitura | |---|---| | 0–7 | A escolha ainda é preferência disfarçada. Volte a campo antes do checkpoint. | | 8–13 | Há material, mas concentrado num milestone só. Olhe qual ficou para trás: quase sempre é **Similares**. | | 14–17 | Defensável. Prepare-se para a pergunta sobre o milestone de menor nota — ela virá. | | 18–20 | Pronta. Use o tempo que sobra para melhorar a estimativa de mercado, que é onde a banca costuma insistir. | --- ## Checklist do checkpoint **As sete perguntas da entrega, respondidas por escrito** - [ ] Qual a oportunidade escolhida, por que é a mais relevante, e **quais evidências mostram isso** - [ ] Quem é o cliente e quem é o usuário — e se são a mesma pessoa - [ ] Quem é o usuário afoito, **nominalmente**, com o degrau e a evidência do degrau - [ ] A jornada do usuário hoje, passo a passo, sem a solução de vocês - [ ] Mercado-alvo e tamanho, como **faixa de 90%** com fórmula de decomposição e origem de cada fator - [ ] Por que a concorrência não resolve plenamente, com fala de usuário - [ ] Lideranças e funções, com nome ao lado de cada papel **Higiene da evidência** - [ ] Toda afirmação sobre o usuário tem data, local e quem observou - [ ] Fato e inferência estão em colunas separadas - [ ] Nenhum número aparece sem origem declarada - [ ] Nenhum número aparece como valor único onde deveria ser faixa - [ ] Nada que a equipe não observou está escrito como se tivesse observado **Preparo da defesa** - [ ] A equipe sabe apontar **qual é o fator mais incerto** da estimativa de mercado, e como pretende medi-lo - [ ] A equipe sabe dizer o que **descartou** e por quê - [ ] Uma pessoa está designada para responder cada uma das sete perguntas --- ## Registro de trajetória As decisões desta quest **não são definitivas** — é comum revê-las, e às vezes abandonar o projeto em favor de outro. Isso só funciona se o caminho ficar registrado; senão, a equipe refaz a mesma discussão dois meses depois. Mantenha um arquivo curto, atualizado a cada decisão, com quatro campos: | Campo | O que registrar | |---|---| | **Data** | Quando a decisão foi tomada | | **O que foi decidido** | Uma frase | | **A evidência que sustentou** | Observação, contagem, conversa — com origem | | **O que faria a equipe voltar atrás** | A observação que mudaria a decisão | A quarta coluna é a que vale mais: uma decisão sem condição de reversão declarada não é decisão sob incerteza — é aposta que ninguém vai auditar. E é ela que separa as duas situações que o `SKILL.md` distingue: **escolha errada vira aprendizado; escolha impensada, feita para se livrar da tarefa, vira bola de neve.** Quando uma oportunidade for descartada, registre **por que** na mesma tabela. Duas semanas depois, alguém vai propor exatamente aquela ideia de novo. --- > Versão leve. As referências completas desta quest estão em > https://projetao-ufpe.vercel.app/baixar/colar/projetao-04.md