# 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** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-09.md) | Ao montar o cronograma. Pontos, Fibonacci, planning poker, velocity, burndown | | **Organizar o trabalho — Quest #9** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-09.md) | Ao dividir. Tamanho de time, multitarefa, limite de WIP, definição de pronto | | **Base de testes — Quest #9** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-09.md) | 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*)** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-09.md) | a base de testes | | **Brainstorm** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-09.md) | 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 | --- # 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 #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. --- > Versão leve. As referências completas desta quest estão em > https://projetao-ufpe.vercel.app/baixar/colar/projetao-09.md