Plano de Projeto

Guia da quest

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

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

Antes de registrar pessoas

Técnicas desta quest

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

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

Base de testes

Abra este arquivo quando for responder à pergunta 4 da entrega: quem é o grupo de usuários afoitos com quem a equipe vai iniciar a operação. É a metade da Q9 que as equipes esquecem, e é a que aparece vazia no Demoday.

Modo de IA: com apoio. A IA ajuda a redigir a mensagem de convite e a organizar a lista. Ela não pode gerar os nomes, e um “público-alvo” descrito por ela não é base de testes.

Usuário afoito traduz early adopter: quem já tem a dor e adota antes de o produto estar pronto.

1. O que conta como base de testes, e o que não conta

A base de testes é a lista de pessoas concretas que vão usar o MVP durante o semestre e devolver dado. É diferente de três coisas com que ela costuma ser confundida:

O que a Q9 pede é a quarta coisa: nomes, ou grupos identificados, com forma de contato, com o que eles ganham, e com quando começam.

A regra que orienta o tamanho. Maurya é direto sobre a proporção:

Prefiro dez usuários afoitos totalmente comprometidos, a quem eu possa dar atenção integral, a cem em cima do muro, qualquer dia.

E ele explica por quê: o primeiro objetivo com o MVP é aprender. Cem usuários indiferentes produzem números que parecem melhores e aprendizado que não existe. Dez comprometidos produzem conversa.

⚠️ Isso contraria o instinto da apresentação. A equipe quer dizer “temos 200 pessoas na lista de espera” porque soa melhor diante da banca. Mas 200 inscrições sem uso é exatamente o que Ries chama de métrica de vaidade — o número que dá o quadro mais cor-de-rosa possível e não sustenta pergunta. Dez pessoas nomeadas, com o que cada uma já fez com o produto, é uma resposta que a banca não derruba.

2. Como constituir a base

Primeiro, o canal certo

Maurya coloca uma preferência antes de qualquer tática: sempre que possível, priorize achar pessoas pelo canal que você de fato vai usar para adquirir clientes no futuro. Se você não tem ainda um caminho até o cliente, isso pode não ser possível nesta fase — mas quando for, o mesmo esforço rende duas coisas: a base de testes e o teste do canal.

As técnicas, em ordem de esforço

O modelo de mensagem que Maurya usa tem uma estrutura que vale copiar: um pedido curto ao amigo, seguido de um texto pronto para encaminhar, que diz o que a equipe está construindo, quanto tempo pede, e — a frase que faz a diferença — “não estou vendendo nada, só procurando conselho”.

A parcela que fica. Quando Maurya lançou seu próprio produto de forma iterativa, cerca de metade das pessoas aceitou receber material inacabado a cada duas semanas; as outras preferiram esperar o produto terminado. Isso, por si, distinguiu usuários afoitos de clientes de estágio posterior: os afoitos se moviam pelo conteúdo e não se importavam com o empacotamento. A recusa também é dado. Registre-a.

Uma prática de campo

Prefira encontro presencial. Além de captar linguagem corporal, encontrar alguém pessoalmente cria uma proximidade que não se recria à distância — e isso é crítico para construir relação com o cliente, que é exatamente o que a base de testes é.

Ação: monte uma planilha com colunas nome · como chegamos até ele · perfil · já topou? · o que ganha · quando começa. Dez linhas preenchidas valem mais que trezentos e-mails coletados.

3. O que oferecer

Aqui há uma divergência entre as fontes, e ela é útil.

Qual usar na Q9: a de Maurya. A base de testes não é uma sessão paga; é uma relação. Se as pessoas só participam mediante pagamento, você não achou usuários afoitos — achou participantes de pesquisa.

Então o que elas ganham? A dor resolvida antes dos outros. Se a equipe não consegue dizer qual é a dor específica daquela pessoa, ela não achou o usuário afoito — achou alguém educado. A checagem prática de Maurya se aplica: se a pessoa declara um problema como indispensável mas não está fazendo nada para resolvê-lo hoje, há uma desconexão. Quem já mantém uma gambiarra para se virar tem a dor; quem não faz nada e continua se virando, não.

Os quatro princípios que fazem o convite funcionar. Maurya analisa por que um cliente concordou em pagar cinco vezes mais do que havia proposto, e nomeia quatro mecanismos. Três deles se transportam para o convite à base de testes de um projeto de disciplina, sem pagamento envolvido:

Ação: escreva o convite em três frases usando escassez explícita e número declarado. Não use “queremos o máximo de gente possível”.

4. Como manter o diálogo

Constituir a base é a parte fácil. Mantê-la viva por doze semanas é o que a Q9 está de fato pedindo.

1. Peça permissão para acompanhar — sempre, e na hora. Maurya fecha toda conversa com dois pedidos, e o primeiro é este: “Com base no que a gente conversou hoje, você toparia ver o produto quando a gente tiver alguma coisa pronta?” O objetivo declarado é estabelecer um ciclo contínuo de feedback.

2. Peça indicação, na mesma hora. O segundo pedido: “Também estamos procurando entrevistar outras pessoas como você. Você poderia nos apresentar a outros [perfil]?” A base cresce por dentro.

3. Deixe um gancho memorável. Mesmo quando ainda não é hora de falar da solução em detalhe, é preciso dar um gancho que mantenha o interesse. Maurya usa o pitch de alto conceito para isso — a destilação em sound bite no formato “[referência conhecida] para/sem [torção]” —, porque ele explica a solução em alto nível e deixa uma frase memorável que a pessoa consegue repetir para outros. Detalhes em ../../q10-demoday/referencias/roteiro-do-pitch.md.

4. Documente nos cinco minutos seguintes. Reserve os cinco minutos imediatamente depois de cada conversa para registrar o resultado enquanto está fresco. Maurya recomenda um formulário curto e fixo; e, quando duas pessoas participaram, cada uma preenche o formulário sozinha primeiro, e só depois há uma conversa de comparação e um registro final. Isso mantém o resultado objetivo.

5. Facilite o retorno espontâneo. Maurya observa que, ao contrário do que se teme, você não vai ser bombardeado: boa parte dos contatos que chegam são de pessoas com dúvidas sobre o serviço, não com problemas de suporte. Dá para reservar uma faixa de horário no dia e redirecionar as chamadas se e quando isso virar problema de escala — o que seria um problema bom de ter.

6. Vá atrás de quem desistiu. Este é o item que quase nenhuma equipe faz e que rende muito na apresentação: você aprende tanto ou mais com quem não ficou do que com quem ficou. Algumas pessoas dão retorno honesto se você fizer um pedido sincero ao fim do período de teste; outras precisam de um pequeno incentivo — Maurya sugere um vale ou uma doação a uma instituição em troca de quinze minutos.

7. Tenha um ritmo fixo de revisão. Maurya marca um horário toda segunda-feira para revisar os indicadores da semana com a equipe inteira e identificar onde está vazando. Numa disciplina, isso encaixa na reunião de sprint.

5. Uma coisa que a base de testes não é

Ela não é fila de espera de lançamento. Maurya faz a distinção com clareza: se você já tem uma lista grande de contatos mornos vinda de esforços anteriores — página teaser, indicações de entrevistados —, considere esgotar essa lista primeiro, na forma de mais convites de acesso antecipado, antes de um lançamento público.

A ordem, portanto, é: conversar com quem já está na lista → convidar para usar → só então pensar em divulgação ampla. Equipe que inverte essa ordem chega ao Demoday com muita divulgação e nenhum uso.

E há um alerta associado: quando o produto abre, você deixa de controlar quem entra. Além dos usuários afoitos alvo, chegam robôs, curiosos e talvez outros clientes-alvo ainda não descobertos. Olhar só o número agregado produz um efeito de média que distorce muito quando o tráfego ainda é pouco, ou não é o tráfego certo. Por isso é preciso segmentar — e por isso a base nominal importa: ela é o segmento que você sabe interpretar.

6. O que reportar na entrega

A pergunta 4 da Q9 pede um grupo. Responda com esta estrutura — ela é curta e cobre o que o mentor vai perguntar:

A conexão com a Q7 e a Q10. A base de testes é a mesma população que vai responder ao teste de ajuste produto-mercado da Q10, se houver tempo, ou fornecer o número de retenção. Se ela não existir na Q9, não existirá número honesto na Q10 — e a única resposta possível diante da banca vai ser “ainda não medimos”. Ver ../../q10-demoday/referencias/tracao-e-numeros.md.

Ação: entregue a planilha de dez linhas junto com o cronograma, e marque no cronograma a semana em que a base começa a usar. Base de testes sem data no cronograma é intenção, não plano.

Fontes

• Maurya, Ash, Running Lean — cap. 6: as técnicas para achar pessoas (contatos de primeiro grau, pedir apresentação com modelo de mensagem, contato frio e a condição de acertar o problema), a preferência pelo canal real de aquisição, a recomendação de encontro presencial, a orientação de não pagar nem incentivar prospects, a documentação em cinco minutos com preenchimento independente; cap. 7: o fechamento com pedido de permissão para acompanhar e pedido de indicação, e o uso do pitch de alto conceito como gancho; cap. 8: os quatro princípios do convite (prêmio, escassez, ancoragem, confiança) e a frase sobre dez comprometidos contra cem em cima do muro; cap. 10 e 12: esgotar a lista morna antes do lançamento público, a segmentação contra o efeito de média, o retorno espontâneo dos usuários e o incentivo para conversar com quem desistiu; cap. 2: o caso da própria publicação iterativa e a metade que preferiu esperar o produto pronto
• Krug, Steve, Não me faça pensar, cap. 9 — a posição oposta sobre incentivo, no contexto de sessão isolada de teste
• Ries, Eric, A startup enxuta, cap. 7 — métricas de vaidade e o “teatro do sucesso”: por que número bruto de cadastros não sustenta pergunta
• Klaff, Oren, Pitch Anything — a técnica de enquadramento como prêmio, conforme citada por Maurya

Estimar

Abra este arquivo no dia em que a equipe for transformar a lista de atividades em datas. Ele responde a uma pergunta só, em várias camadas: como dizer quando algo fica pronto sem inventar.

Modo de IA: coprodução na decomposição e na montagem do cronograma. sem assistência no valor das estimativas — quem estima tem de ser quem executa, e a IA não executa.

1. O cone da incerteza, e o que ele proíbe

Sutherland apresenta o gráfico com os números: as estimativas iniciais de trabalho variam de 400% acima do tempo efetivamente gasto até 25% dele. Os extremos, portanto, diferem por um fator de dezesseis. Conforme o projeto avança e mais coisas se assentam, as estimativas se aproximam da realidade, até que não há mais estimativa — só realidade.

A conclusão que ele tira é dura e é a que interessa à Q9: planejar tudo no início não funciona. No caso que ele narra, uma empresa passou meses planejando o que o produto seria e quanto tempo levaria, e mesmo depois de todos esses meses a pesquisa indica que eles provavelmente errariam por um fator de quatro, para mais ou para menos.

O que fazer no lugar: refinar o plano ao longo do projeto, em vez de fazê-lo todo no início — planejando em detalhe apenas o suficiente para entregar o próximo incremento de valor, e estimando o resto em blocos maiores.

E o que sustenta esse refinamento: ao fim de cada iteração existe algo de valor que dá para ver, tocar e mostrar para quem vai usar. Aí você pergunta: é isso que você quer? Isso resolve pelo menos parte do seu problema? Estamos indo na direção certa? Se a resposta for não, o plano muda.

⚠️ Consequência para o cronograma da Q9. A quest pede um cronograma até o Demoday, e é preciso entregar um. Mas um cronograma detalhado semana a semana até o fim do semestre, feito na semana da Q9, é exatamente o artefato que o cone da incerteza diz ser inútil. A forma defensável de entregar: detalhe fino nas próximas duas ou três semanas, blocos grossos depois, e uma data declarada de recálculo — “este cronograma será refeito ao fim de cada sprint, com a velocity medida”. Declarar isso vale mais do que fingir precisão de segunda casa em maio.

2. Somos péssimos em absoluto, bons em relativo

O segundo argumento encadeado: humanos são absolutamente terríveis em estimar valores absolutos, mas bons em dimensionamento relativo — comparar um tamanho a outro. Distinguir camisetas P, M e G, por exemplo.

O exemplo das raças de cachorro

Mike Cohn, tendo sido proibido pela esposa de ter cachorro, começou a perguntar às equipes de que tamanho de cachorro era cada pedaço do projeto. Ele listava raças — labrador, terrier, dogue alemão, poodle, dachshund, pastor-alemão, setter irlandês, buldogue — e perguntava: este problema aqui é um dachshund ou um dogue alemão? E se aquele é um dachshund, este aqui deve ser mais ou menos do tamanho de um labrador, certo?

Depois vinha a conversão em número: dachshund = 1, dogue alemão = 13. Isso faria um labrador = 5 e um buldogue = 3.

Sutherland aplica ao exemplo do casamento, e o passo a passo serve de modelo para a Q9:

E aí entra a regra operacional embutida no exercício: se um item é grande demais, quebre-o em pedaços administráveis. Os convites viram dois projetos — juntar os nomes (buldogue, 3) e lidar com a gráfica (buldogue, 3) —, e endereçar vira um pastor-alemão (5).

Ação: faça o exercício com a lista de atividades da Q9 antes de qualquer conversa sobre datas. Escolha um item de referência que todo mundo entende — algo já feito na Q6 ou Q8 — e chame de 3. Estime todo o resto em relação a ele.

3. Por que Fibonacci

1, 3, 5, 8, 13 — cada número é a soma dos dois anteriores. Sutherland dá o contexto matemático (a sequência aparece na concha do náutilo, nos galhos de árvore, na couve-flor, na curva da folha de samambaia, na forma das galáxias; é a razão áurea), mas o argumento que sustenta o uso é perceptual:

Os números da sequência estão suficientemente distantes para que consigamos perceber a diferença. Mas a diferença entre um cinco e um seis? É sutil demais para o nosso cérebro registrar.

Se uma pessoa estima algo como cinco e outra como oito, dá para ver intuitivamente a diferença. Entre cinco e seis, não.

O reforço clínico que ele traz: é razoavelmente conhecido em medicina que, para um paciente relatar que percebe melhora em um sintoma, a melhora precisa ter sido maior que 65%. Nossas mentes não funcionam em incrementos suaves; somos melhores em perceber saltos de um estado para outro — e saltos irregulares, não suaves.

O fecho, e é o ponto que mais se perde: usar Fibonacci permite estimativas que não precisam ser 100% exatas. Nada é exatamente um cinco, um oito ou um treze. O que os números dão é uma forma de coletar opiniões sobre o tamanho de uma tarefa em que todo mundo usa mais ou menos a mesma régua — e é assim que se forma consenso. Estimar em grupo dessa maneira dá uma estimativa muito mais acurada do que qualquer pessoa sozinha produziria.

4. Planning poker, passo a passo

De onde vem

É o método Delphi acelerado. Sutherland conta a origem: nos anos 1950 a Rand Corporation foi chamada a responder perguntas da Guerra Fria. Norman Dalkey e Olaf Helmer publicaram em 1963 o método, invocando o oráculo de Delfos, com a intenção de fazer perguntas sem que a opinião de uma pessoa afetasse a das outras. Reuniram quatro economistas, um especialista em vulnerabilidade física, um analista de sistemas e um engenheiro elétrico, e conduziram uma série de pesquisas anônimas: ninguém sabia quem eram os outros; a cada rodada, as respostas e os dados usados voltavam ao grupo, com qualquer marca de identificação removida.

Os números da convergência: na primeira rodada, a faixa ia de 50 a 5.000. Depois de perguntarem quais fatores os especialistas haviam usado e devolverem essa informação ao grupo, a faixa caiu para 89 a 800. Repetindo, chegou-se a 167 a 360.

O problema do Delphi, para o uso em projeto: é lento demais. Sutherland precisava de centenas de itens estimados em horas, não em dias ou semanas.

Os dois vieses que ele existe para combater

O procedimento

1. Cada pessoa tem um baralho com os números de Fibonacci — 1, 3, 5, 8, 13, e assim por diante.
2. O item a estimar vai à mesa.
3. Cada um puxa a carta que representa o esforço que julga correto e a coloca virada para baixo.
4. Todos viram ao mesmo tempo.
5. Se todos estão dentro de duas cartas — por exemplo um 5, dois 8 e um 13 —, a equipe soma tudo, tira a média (nesse caso 6,6) e passa ao item seguinte. São estimativas, não cronogramas de ferro, e sobre pedaços pequenos do projeto.
6. Se as cartas estão a mais de três de distância, quem votou o maior e quem votou o menor explicam o raciocínio. Só então há nova rodada. Fora isso, a equipe simplesmente tira a média — que aproxima o que os estatísticos da Rand obtiveram.

O exemplo que mostra o valor do passo 6

Pintar o interior de uma casa: sala, cozinha e dois quartos, com uma equipe que já pintou junta antes.

• Os dois quartos: todo mundo estima 3. Sem discordância — já fizeram, é direto.
• A sala: cômodo grande mas simples. Estimativas de 5 a 13, com média 6. Sem necessidade de discussão.
• A cozinha: um 3, um 8, um 13 e um 5 na mesa. Quem pôs 3 argumenta que o cômodo é pequeno e tem menos parede que os quartos. Quem pôs 13 responde que o consumo real de tempo é fitar armários e bancadas, e que pintar todas aquelas áreas pequenas vai ter de ser com pincel, não com rolo. Nova rodada: o 3 vira 8, os outros ficam. Perto o bastante — somam, tiram a média e seguem.

O que o passo 6 produz não é a estimativa: é o conhecimento compartilhado. Todo mundo na equipe passou a saber que existe trabalho de fitar armários.

Ação: o baralho pode ser papel cortado. O que não pode faltar é o passo 3 e 4 — todos escolhem antes de ver a escolha alheia. Sem isso, o método vira reunião de opinião, e você reintroduz exatamente os dois vieses que ele existe para remover.

5. Quem estima tem de ser quem executa

Sutherland é explícito: é crucial que quem estima seja a equipe que vai de fato fazer o trabalho, não estimadores “ideais” especialistas.

O caso que ele narra: a GSI Commerce, empresa que projetava lojas online para grandes marcas, teve a ideia — que parecia boa — de tirar a estimativa das equipes e entregá-la aos melhores estimadores da empresa, os que mais entendiam de projeto e tecnologia. O plano era entregar estimativas de oitenta projetos multimilionários aos clientes e às equipes que fariam o trabalho.

O resultado: o experimento foi interrompido pela metade, com quarenta projetos feitos. Sutherland compara a estudos de medicamento interrompidos porque a droga está matando os pacientes. As estimativas eram tão erradas que se tornaram inúteis; nada foi entregue no prazo; os clientes ficaram insatisfeitos; as equipes, desmoralizadas. Os gestores voltaram a fazer as equipes que executam estimarem, e as estimativas voltaram a bater com a realidade.

A lição que ele extrai: só quem faz o trabalho sabe quanto tempo e esforço ele exige. Talvez a equipe seja muito boa numa coisa e péssima em outra; talvez tenha um especialista útil numa área e ninguém que conheça outra. Equipes são individuais e únicas, cada uma com o próprio ritmo. Forçá-las em processos de molde único é receita de desastre.

⚠️ Onde isso morde na Q9. Duas violações são comuns numa equipe de disciplina. A primeira: o gerente estima sozinho e distribui. A segunda: a IA gera o cronograma completo, com durações, e a equipe aceita. As duas são a mesma violação — estimador que não executa. A IA não sabe quanto a sua equipe rende, quem some na semana de provas, nem que a peça de hardware demora a chegar. Use a IA para decompor e para questionar; não para atribuir duração.

6. Velocity: como a data deixa de ser chute

O cálculo. Você tem as histórias e já as estimou — esta é um oito, aquela é um três. Rode a primeira sprint. Ao fim dela, conte as histórias completas, some os pontos delas. Esse número é a velocity da equipe.

A previsão. Com a velocity, olhe quantas histórias restam e quantos pontos elas representam — e você sabe quando vai terminar.

Velocity × Tempo = Entrega.

O segundo uso, que Sutherland considera o mais importante: uma vez que você tem velocity, dá para perguntar o que está impedindo a equipe de ir mais rápido. É assim que se verifica se o desperdício está de fato sendo removido — e não apenas declarado removido.

O caso, com os números: depois de três sprints medindo velocity, as equipes tinham acelerado de 20 para 60 pontos por sprint. Com essa velocity, no começo de março, a conta dava mais dezenove sprints de duas semanas: entrega em 1º de dezembro. A gestão recebeu então uma lista de doze impedimentos — de falta de autonomia para decidir a requisitos técnicos onerosos, de gente que não aparecia em reunião a coisas simples como não ter todo mundo da equipe na mesma sala. Cada impedimento com o nome de um gestor ao lado. Todos foram removidos entre a segunda e a quinta-feira. Ao fim da sprint seguinte, a velocity subiu 50%, e a data foi para 1º de setembro — ainda três meses atrasada, mesmo tendo a equipe acelerado de 20 para 90 pontos por sprint, mais de 400%.

As três perguntas que ele fez quando a data ainda não fechava — e que valem para uma equipe de disciplina em apuros:

1. Há algo que possamos fazer diferente para acelerar? (Foi assim que descobriram que a segurança de TI havia fechado uma porta e travado equipes inteiras.)
2. Dá para transferir itens do backlog? Há coisa que outras equipes possam fazer?
3. Há coisa que possamos não fazer? Dá para reduzir o escopo? A resposta inicial foi que já haviam cortado até o osso. Passaram a tarde inteira raspando: cada tarefa teve de lutar pela própria vida. Ganharam mais um mês.

Consequência direta para a Q9: velocity só existe depois de pelo menos uma sprint fechada. Se a Q9 acontece antes da primeira sprint, a linha de base do cronograma não tem dado real por trás. Diga isso, e marque a data do primeiro recálculo.

7. Burndown

O instrumento de visualização. Num eixo, o número de pontos que a equipe levou para a sprint; no outro, os dias. Todo dia alguém soma os pontos concluídos e marca no gráfico. Idealmente, há uma inclinação acentuada para baixo, chegando a zero ponto restante no último dia da sprint.

O valor não é o desenho: é que o desvio aparece no dia três, não na véspera. Uma linha que não desce nos primeiros dias é a informação de que a equipe começou muitas coisas e não terminou nenhuma — que é exatamente o diagnóstico de trabalho em progresso excessivo tratado em organizar-o-trabalho.md.

Sutherland lista o burndown ao lado do quadro de três colunas — A fazer, Fazendo, Feito — como as duas formas padrão de tornar o trabalho visível.

Ação para a Q9: entregue o burndown em branco, com o eixo de pontos preenchido pela estimativa da primeira sprint e os dias marcados. Um burndown planejado é entregável; um burndown inventado retroativamente não é.

8. O que a Q9 precisa mostrar sobre estimativa

Uma frase para a apresentação, se a banca ou o mentor perguntar de onde vieram as datas: “estimamos em pontos, por comparação relativa, com quem vai executar; a data sai da velocity, e a velocity só existe depois da primeira sprint — por isso o cronograma tem data de recálculo”. Isso é mais forte do que um Gantt com precisão fictícia.

Fontes

• Sutherland, Jeff, Scrum: a arte de fazer o dobro do trabalho na metade do tempo — cap. 6 inteiro: o cone da incerteza e os números de 400% e 25%; o refinamento incremental do plano; dimensionamento relativo e os pontos de cachorro de Mike Cohn; a sequência de Fibonacci e o argumento perceptual, incluindo o dado dos 65% de melhora percebida; o método Delphi da Rand (Dalkey & Helmer, 1963) e as faixas de convergência; efeito manada e cascata informacional; efeito halo (Thorndike, 1920); o procedimento do planning poker e o exemplo da pintura; o caso da GSI Commerce e a conclusão sobre quem estima; velocity, a fórmula, os doze impedimentos e as três perguntas; o apêndice do livro, com o burndown e o quadro de três colunas
• Cohn, Mike — autor do exercício dos pontos de cachorro, conforme creditado por Sutherland
• Weinberg, Gerald, Quality Software Management — origem da tabela de multitarefa usada em organizar-o-trabalho.md, do mesmo capítulo

Organizar o trabalho

Abra este arquivo quando a equipe for dividir gente por frente e decidir como o trabalho anda de semana em semana. Ele trata de quatro decisões que uma equipe grande de disciplina costuma tomar por omissão: quantas pessoas por frente, quantas coisas ao mesmo tempo, o que significa “pronto”, e o que entra no quadro.

Modo de IA: coprodução — decompor, detectar dependências, montar o quadro. A IA não decide quem faz o quê, e não sabe quem some na semana de provas.

1. Tamanho de time, e por que a Q9 esbarra nisso

A formulação clássica é sete pessoas, mais ou menos duas — Sutherland registra ter visto times de três funcionando em alto nível. O dado que interessa: se você tem mais de nove pessoas num time, a velocity de fato cai. Mais recurso faz o time ir mais devagar.

Lei de Brooks, cunhada por Fred Brooks em 1975, em The Mythical Man-Month: acrescentar gente a um projeto de software atrasado o atrasa mais. Isso foi confirmado em estudo após estudo.

O dado empírico. Lawrence Putnam dedicou a carreira a estudar quanto tempo as coisas levam para ser feitas e por quê. O trabalho dele mostrava, repetidamente, que projetos com vinte ou mais pessoas consumiam mais esforço do que projetos com cinco ou menos — não um pouco mais: um time grande gastava cerca de cinco vezes o número de horas de um time pequeno. Em meados dos anos 1990 ele fez um levantamento amplo para determinar o tamanho certo: 491 projetos de médio porte, em centenas de empresas diferentes, todos exigindo produtos ou funcionalidades novas — não reaproveitamento de versões antigas. Dividindo por tamanho de time, notou de imediato que, acima de oito pessoas, os times demoravam dramaticamente mais. E o número que se cita: grupos de três a sete pessoas exigiram cerca de 25% do esforço de grupos de nove a vinte para fazer a mesma quantidade de trabalho.

O resultado se repetiu ao longo de centenas e centenas de projetos.

As duas causas

Brooks encontrou duas razões para adicionar gente atrasar o projeto:

1. O tempo de trazer a pessoa nova ao ritmo. Como se espera, colocar alguém a par atrasa todo mundo.
2. A explosão de canais de comunicação, contra o limite do cérebro.

A fórmula: número de pessoas, multiplicado por esse número menos um, dividido por dois.

Canais = n(n−1)/2

Por que isso é limite duro e não preguiça. Sutherland traz o contexto cognitivo: o estudo clássico de George Miller, de 1956, dizia que o máximo de itens retidos na memória de curto prazo é sete. Pesquisa posterior corrigiu o número: em 2001, Nelson Cowan, da Universidade do Missouri, revisou a literatura nova sobre o tema e concluiu que o número não é sete, é quatro. As pessoas costumam achar que memorizam mais usando mnemônicos ou concentração, mas a evidência é razoavelmente clara: retemos cerca de quatro “blocos” de informação. O exemplo canônico é a sequência de doze letras fbicbsibmirs — quase ninguém retém mais que quatro letras, a menos que perceba que elas se agrupam em siglas conhecidas: FBI, CBS, IBM, IRS. Ligando ao que já está na memória de longo prazo, cabe mais. Mas a parte da mente que foca — a consciente — segura cerca de quatro itens distintos por vez.

E a exigência que isso contraria: num time de Scrum, como num time de forças especiais, todo mundo tem de saber o que todo mundo está fazendo. Todo o trabalho em curso, os obstáculos, o progresso, tem de ser transparente para os demais. Se o time cresce demais, a capacidade de todos se comunicarem com clareza com todos, o tempo todo, se embaralha.

⚠️ A Q9 impõe equipe grande — e a saída não é reclamar. A turma monta equipes acima do tamanho ótimo. A resposta operacional é subdividir em frentes com dono, mantendo cada frente pequena e multifuncional, e aceitando o custo de coordenação entre frentes como custo explícito, com hora marcada. O que não funciona é deixar a equipe grande operar como time único e esperar que ela se organize: sem estrutura, ela se quebra socialmente em subgrupos que trabalham com propósitos cruzados, a multifuncionalidade se perde, e reuniões de minutos viram reuniões de horas.

Ação: na tabela de subequipes que a Q9 pede, nenhuma frente deve ter mais de sete pessoas, e cada frente deve ter um nome de dono. Some os canais internos de cada frente e escreva o número ao lado — é a justificativa da divisão que você escolheu.

2. O custo real da multitarefa

A tabela abaixo aparece em Quality Software Management, de Gerald Weinberg, e é reproduzida por Sutherland:

A coluna da direita é desperdício puro. Com cinco projetos, 75% do trabalho não vai a lugar nenhum — três quartos do dia jogados fora.

O exercício que cabe em cinco minutos

Sutherland usa em treinamento, e ele funciona porque a pessoa mede o próprio tempo. A tarefa: escrever os algarismos de 1 a 10, os algarismos romanos de I a X, e as letras de A a L. O mais rápido possível.

• Primeira rodada, por linhas. Escreva o algarismo, o romano, a letra; depois a linha seguinte. Você troca de contexto a cada símbolo. Sutherland cronometrou: 39 segundos.
• Segunda rodada, por colunas. Todos os algarismos, depois todos os romanos, depois todas as letras. 19 segundos — metade.

Por que isso não é só sobre listinhas. A explicação vem de Harold Pashler, que no início dos anos 1990 demonstrou o que chamou de interferência de tarefa dupla. Um grupo fazia algo muito simples — apertar um botão quando uma luz acendia. Outro grupo fazia isso mais outra tarefa simples: apertar um botão diferente conforme a cor da luz. Assim que a segunda tarefa era acrescentada, por mais simples que fosse, o tempo dobrava. Pashler teorizou um gargalo de processamento: as pessoas realmente só conseguem pensar em uma coisa por vez. Há um custo em “empacotar” um processo, buscar outro na memória e rodá-lo — e esse custo se paga a cada troca.

O resultado num time real

Um time decide fazer três projetos no ano — A, B e C — e planeja o ano alternando entre eles. Fazendo tudo ao mesmo tempo, que é a estratégia clássica, terminam no fim de julho. Levando cada projeto até o fim, um por vez, terminam no começo de maio. O projeto não muda de tamanho nem de conteúdo; só a ordem muda. E o tempo cai para pouco mais da metade.

O custo escondido, e o que ele significa para código. Quando você trabalha em algo complicado — escrever um relatório, montar uma apresentação, desenvolver software —, você está segurando na cabeça um objeto muito complexo: dezenas de fatores, o que já foi feito, para onde se vai, quais são os impedimentos. Se você é interrompido ou tem de trocar de projeto, mesmo por um instante, essa arquitetura mental construída com cuidado desmorona — e pode levar horas de trabalho só para voltar ao mesmo estado de consciência.

Ação: blocos. Junte numa mesma janela de tempo as tarefas que exigem o mesmo tipo de concentração, e proteja o bloco. Na Q9, isso significa cronograma por blocos de foco, não por “um pouquinho de cada coisa toda semana”.

3. Trabalho pela metade é igual a zero

A ideia vem do conceito de trabalho em processo, ou estoque, na manufatura enxuta: é desperdício ter um monte de coisa parada que não está sendo usada para construir nada. Uma montadora que só tem carros pela metade gastou muito dinheiro e esforço e não criou nada de valor real.

Sutherland traz o exemplo doméstico. Uma lista de tarefas da semana com dez a vinte itens: repintar o banheiro, comprar ração, pagar a conta, juntar as folhas. O maior erro é tentar fazer cinco ao mesmo tempo. Imagine cinco tarefas parcialmente feitas: uma parede do banheiro pintada, a ração ainda no porta-malas, o cheque escrito mas não enviado, as folhas amontoadas mas não ensacadas. Esforço gasto, valor zero. O valor chega quando a lona e as latas saem do banheiro, o cachorro come, o banco recebe e o quintal está limpo. Fazer metade de algo é, essencialmente, não fazer nada.

Em sprint, o mesmo: se algo está pela metade no fim da sprint, você está pior do que se não tivesse começado. Você gastou recurso, esforço e tempo e não levou nada a um estado entregável. Você tem um carro pela metade. Teria sido melhor criar algo menor que realmente funcione.

⚠️ A tradução para o Demoday. Cinco funcionalidades a 80% não são apresentáveis. Duas funcionalidades a 100% são. Quando a equipe estiver decidindo o que cortar na última sprint, esse é o critério — e ele é o oposto do impulso natural, que é acabar tudo um pouquinho mais.

4. O que significa “pronto”

Há duas definições no acervo, e elas não competem — encaixam uma na outra.

A barra de engenharia

Sutherland conta como a definição nasceu no projeto que ele descreve: em cada nota adesiva, a equipe escrevia não só o que precisava ser criado, mas também como saberiam que aquilo estava pronto. Foi assim que requisitos de conformidade regulatória, garantia de qualidade e relatórios de processo entraram no trabalho. Para a tarefa estar pronta, ela tinha de atender àqueles critérios.

O ponto é o momento em que a conformidade entra: embutida em cada item de trabalho, e não verificada no fim. Assim, todo mundo do time — não só o pessoal de conformidade — tinha de atingir aquele nível de qualidade antes de passar ao item seguinte. A quantidade de retrabalho que isso remove é enorme.

A definição: pronto é um padrão que precisa ser atendido, acordado antes, de modo que todo mundo saiba quando algo está pronto ou não, porque há critérios claros para qualquer peça de trabalho.

O par que dobra a velocidade duas vezes. Para cada história deve haver uma definição de Pronto para começar e uma definição de Pronto:

Os critérios INVEST que Sutherland lista para “pronto para começar”: Independente (dá para completar sem depender de outra), Negociável, Valiosa (entrega valor a um cliente, usuário ou interessado), Estimável (dá para dimensionar), Pequena (se for grande demais, reescreva ou quebre) e Testável (tem um teste que precisa passar para estar completa — escreva o teste antes de fazer a história).

A regra da demonstração: o time só demonstra o que atende à definição de pronto — o que está total e completamente terminado e pode ser entregue sem mais nenhum trabalho. Pode não ser um produto completo, mas deve ser uma funcionalidade completa de um.

A barra de aprendizado

Numa startup enxuta, a barra sobe: uma história só está completa quando alcança aprendizagem validada.

O caso que Ries narra é o da Grockit, que aplicou o princípio kanban de restrição de capacidade à priorização de produto. As histórias passaram a ser catalogadas em quatro estados:

Validação vinha em geral na forma de teste comparativo mostrando mudança de comportamento do cliente, mas também podia ser entrevista ou sondagem. Cada cesto aceita poucas histórias; quando enche, não aceita mais. E o ponto que amarra: só quando uma história foi validada é que ela pode sair do quadro. Se a validação fracassa e a história se revela má ideia, o recurso é removido do produto.

O efeito sobre a equipe: as equipes que trabalham nesse sistema começam a medir a própria produtividade por aprendizagem validada, e não por produção de novos recursos.

Como conciliar num semestre

O problema prático: verificação quantitativa leva tempo demais para caber numa sprint curta. Maurya resolve isso com validação em duas fases, e é essa a formulação a adotar na Q9:

Só a validação qualitativa declara a funcionalidade “pronta”. Isso libera a trava de trabalho em progresso, permitindo que outras funcionalidades comecem enquanto mais dados são coletados. A verificação quantitativa continua acontecendo, como estado posterior, comparando as coortes da semana em que a funcionalidade entrou no ar com a semana anterior.

Traduzindo para a definição que a Q9 deve escrever:

Pronto = padrão técnico acordado atendido + validação qualitativa com pelo menos um usuário da base de testes. A verificação quantitativa é um estado posterior, e não trava a sprint.

Ação: escreva a definição de pronto em uma frase, cole no quadro, e não a mude no meio do semestre. Uma definição de pronto escrita e estável vale mais para a nota do que uma cerimônia de Scrum completa e mal feita.

5. O limite de trabalho em progresso

O princípio de kanban que restringe a fila de trabalho: estabelecer limites para quantas funcionalidades podem estar em progresso ao mesmo tempo. Isso maximiza a vazão e minimiza o desperdício.

A recomendação de Maurya é operacional: comece com um limite de trabalho em progresso igual ao número de fundadores ou de membros da equipe, e ajuste depois se precisar. Três pessoas, três funcionalidades em andamento.

Em times maiores é comum limitar também cada subestado — protótipo, demo, código —, mas Maurya considera isso exagero em equipe pequena.

A conexão com a seção 2 é o argumento inteiro: o limite existe para impedir a equipe de se auto-sabotar com a tabela de troca de contexto. Não é burocracia; é a implementação da tabela.

6. O que entra no quadro

Nem tudo. Maurya distingue funcionalidade mínima comercializável (MMF, do inglês minimum marketable feature) de funcionalidades menores e correções de defeito. O termo foi definido por Mark Denne e Jane Cleland-Huang em Software by Numbers: a menor porção de trabalho que entrega valor ao cliente.

O teste, e ele é uma pergunta:

Você anunciaria isso aos seus clientes num post ou num informe? Se é pequeno demais para mencionar, não é uma MMF.

Uma MMF é normalmente composta de itens de trabalho menores. Maurya rastreia só MMFs no quadro principal, e usa uma ferramenta mais leve de quadro de tarefas para funcionalidades pequenas, correções e itens de trabalho.

Os quatro complementos do quadro

Ação: monte o quadro na semana da Q9, ainda que vazio, com as metas escritas no topo e o número do limite no cabeçalho. Fotografe e coloque na entrega. Quadro é evidência verificável de organização; texto sobre metodologia não é.

Fontes

• Sutherland, Jeff, Scrum — cap. 3: tamanho de time (sete mais ou menos dois), Lei de Brooks (Fred Brooks, The Mythical Man-Month, 1975), o levantamento de Lawrence Putnam com 491 projetos e o dado dos 25% de esforço, a fórmula de canais n(n−1)/2 com a tabela, Miller (1956) e a correção de Cowan (2001), a exigência de transparência total no time; cap. 5: a tabela de multitarefa de Gerald Weinberg (Quality Software Management), o exercício das linhas e colunas com 39 e 19 segundos, a interferência de tarefa dupla de Harold Pashler, os três projetos que terminam em maio em vez de julho, o custo de reconstruir a arquitetura mental, “trabalho pela metade é igual a zero”; cap. 6 e apêndice: a definição de pronto, os critérios INVEST, o par pronto-para-começar e pronto e o duplo ganho de velocidade, a regra de só demonstrar o que está pronto
• Maurya, Ash, Running Lean, cap. 13 — o limite de trabalho em progresso igual ao número de membros da equipe, o princípio de kanban de restrição de fila, MMF e o teste do informe (definição original de Denne & Cleland-Huang, Software by Numbers), metas no topo do quadro, faixas de espera, itens que podem ser mortos em qualquer estágio, e a validação em duas fases que declara “pronto” pela validação qualitativa
• Ries, Eric, A startup enxuta, cap. 7 — o caso da Grockit: os quatro estados da história, “validada” como condição para sair do quadro, a remoção do recurso quando a validação fracassa, e a mudança da medida de produtividade para aprendizagem validada

Autodiagnóstico

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:

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

3. Prazos e caminho crítico

4. Subequipes e responsáveis

5. Definição de pronto e quadro

6. Base de testes

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.