Guia de Prompt
Como escrever uma proposta de projeto com o Claude
Uma proposta que é aprovada é específica. Uma proposta que é ignorada é vaga.
O Claude, da Anthropic, é bom em transformar uma ideia bruta de projeto em uma proposta estruturada com declaração do problema, escopo, cronograma, e o tipo de detalhe específico que faz um stakeholder realmente dizer sim. O que o Claude não sabe é o seu orçamento, a capacidade real da sua equipe, ou a política da sua organização, a menos que você conte a ele, por isso "escreva uma proposta de projeto para X" costuma retornar algo genérico o suficiente para pertencer a qualquer empresa. A solução é dar ao Claude as restrições reais: para quem é a proposta, o que você realmente tem disponível, e qual decisão você precisa dessa pessoa.
Para pedir ao Claude que escreva uma proposta de projeto, dê o problema que você está resolvendo, para quem é a proposta e qual decisão você precisa dela, suas restrições reais (tamanho da equipe, cronograma aproximado, faixa de orçamento), e a instrução de estruturar o rascunho como declaração do problema, abordagem proposta, escopo, cronograma e métricas de sucesso. Cole qualquer material de referência, propostas anteriores ou notas que você já tenha, e peça ao Claude para marcar qualquer coisa vaga demais para se tornar um plano concreto.
Publicado em
Aula grátis · sem precisar de contaConheça o ClaudePor Que o Claude?6 minComeçar a aula grátisPrincipais pontos
- Diga para quem é a proposta e qual decisão você precisa que ela tome. Uma proposta para sua própria equipe planejar parece diferente de uma pedindo que um executivo aprove um orçamento.
- Dê ao Claude suas restrições reais: tamanho da equipe, cronograma aproximado, faixa de orçamento. Um plano baseado em restrições inventadas precisa ser reescrito no momento em que alguém com os números reais o lê.
- Peça métricas de sucesso especificamente, não apenas uma descrição do trabalho. Uma proposta que não diz como você vai saber que funcionou é mais difícil de aprovar e mais difícil de verificar depois.
- Cole material de referência que você já tem: propostas anteriores, notas de reunião, um esboço bruto. O Claude organiza e aprimora o que você dá a ele; não pode inventar o contexto por trás do seu projeto específico.
- Leia a seção de escopo com atenção especial antes de enviar. Um escopo mais vago ou amplo do que você realmente pretende é a razão mais comum pela qual uma proposta causa problemas depois.
Copie e cole
Prompts para usar hoje mesmo
Um primeiro rascunho completo a partir de uma ideia bruta
Quero propor [descreva sua ideia de projeto em uma ou duas frases]. Isso é para [para quem é a proposta e qual decisão você precisa deles]. Isto é o que eu realmente tenho para trabalhar: equipe de [tamanho], cronograma de aproximadamente [prazo], orçamento em torno de [faixa, ou 'ainda não determinado']. Escreva um rascunho de proposta com declaração do problema, abordagem proposta, escopo (incluindo o que está explicitamente fora do escopo), um cronograma aproximado e métricas de sucesso. Marque qualquer coisa que você teve que adivinhar porque eu não dei detalhes suficientes.
Ser honesto sobre o que você ainda não sabe, como orçamento, produz um rascunho mais útil do que inventar um número para preencher a lacuna.
Transformar um brainstorm desorganizado em declaração do problema
Aqui estão minhas notas brutas e desorganizadas sobre um problema que quero resolver: [cole suas notas]. Transforme isso em uma declaração do problema curta, de duas a três frases, que explique por que isso importa e quem é afetado, sem ainda descrever a solução. Quero que o problema esteja claramente definido antes de propor a correção.
Mantenha a declaração do problema separada da solução; uma proposta que salta direto para a correção costuma perder o leitor que ainda não está convencido de que há um problema que vale a pena resolver.
Definir o escopo, incluindo o que está fora
Aqui está meu projeto proposto: [descreva-o]. Escreva uma seção de escopo que declare claramente o que este projeto vai e não vai incluir, com pelo menos três coisas específicas explicitamente fora do escopo. Quero evitar que a proposta seja lida de forma mais ampla do que pretendo.
Uma lista explícita do que está fora do escopo costuma ser a parte de uma proposta que previne mais confusão depois.
Testar uma proposta antes de enviá-la
Leia este rascunho de proposta como se você fosse o stakeholder decidindo se aprova: [cole seu rascunho]. Que perguntas você teria antes de aprovar isso? Onde o cronograma, escopo ou métrica de sucesso parecem irrealistas ou pouco claros? Seja específico sobre o que está faltando, não apenas sobre o que está errado.
Isso funciona melhor pouco antes de enviar a proposta, como uma verificação final em vez de um passo de rascunho inicial.
Adaptar o tom de uma proposta para um público diferente
Aqui está uma proposta de projeto que escrevi para minha própria equipe: [cole seu rascunho]. Reescreva-a para um público executivo que precisa aprovar o orçamento: comece com o caso de negócio e o custo, mantenha o detalhe técnico breve, e mova qualquer detalhe de implementação para uma seção de apêndice no final.
O mesmo projeto muitas vezes precisa de duas versões diferentes dependendo de quem lê e o que essa pessoa precisa decidir.
A Estrutura
As cinco partes que um prompt de proposta precisa
Essas cinco peças transformam uma ideia vaga em algo sobre o qual um stakeholder pode realmente agir.
Uma declaração do problema, antes da solução
Declare o problema e por que ele importa antes de descrever a correção. Um leitor que ainda não está convencido de que há um problema não vai levar a sério uma solução proposta para ele.
Escopo, incluindo o que está explicitamente fora
Diga o que o projeto vai fazer e, igualmente importante, o que não vai fazer. Uma proposta sem escopo definido tende a crescer na cabeça de cada um até o que eles assumiram que significava.
Restrições reais, não inventadas
Dê ao Claude o tamanho real da sua equipe, cronograma aproximado e faixa de orçamento, mesmo que parte disso ainda seja incerta. Um plano baseado em números inventados precisa ser refeito no momento em que os reais aparecem.
Métricas de sucesso, declaradas claramente
Diga como você vai saber que o projeto funcionou. Uma proposta sem métrica de sucesso é mais difícil de aprovar e, se for aprovada mesmo assim, mais difícil de acompanhar seis meses depois.
Conheça Seu Leitor
O mesmo projeto precisa de uma proposta diferente para um público diferente
Uma proposta escrita para sua própria equipe planejar e uma proposta escrita para obter aprovação de orçamento de um executivo fazem trabalhos diferentes, mesmo descrevendo o mesmo projeto. A versão da equipe pode se aprofundar em detalhes de implementação porque o leitor já se importa com isso. A versão executiva precisa começar com o caso de negócio e o custo, porque essa é a decisão real que esse leitor precisa tomar, e detalhe desnecessário só atrasa a decisão que você está pedindo.
Diga explicitamente ao Claude quem está lendo e qual decisão você precisa dessa pessoa. "Isso é para minha equipe planejar o próximo trimestre" e "isso precisa de aprovação de orçamento de uma VP que não conhece os detalhes técnicos" direcionam o Claude para dois rascunhos diferentes, mesmo para o mesmo projeto, e nomear o público antecipadamente evita que você escreva uma versão e descubra depois que ela está errada para o leitor real.
Se você realmente precisa de ambas as versões, geralmente é mais rápido escrever primeiro a versão detalhada da equipe e depois pedir ao Claude para adaptá-la para o público executivo, em vez de escrever as duas do zero. Os fatos subjacentes não mudam; só muda o que é enfatizado e o que vai para um apêndice.
Erros Comuns
O que faz uma proposta ficar parada em vez de ser aprovada
Essas são as lacunas que transformam uma ideia razoável em uma proposta que fica sem resposta.
Um escopo mais amplo do que você realmente pretende
Se você não declarar o que está fora do escopo, os leitores vão preencher a lacuna com suas próprias suposições, que costumam ser maiores do que o que você pretendia propor. Diga explicitamente o que este projeto não vai incluir.
Nenhuma decisão declarada para o leitor tomar
Uma proposta que não diz o que você está realmente pedindo, aprovação, orçamento, contratação, sinal verde para começar, deixa o leitor sem saber qual resposta você precisa dele.
Números inventados substituindo restrições reais
Um cronograma ou orçamento que o Claude adivinhou porque você não forneceu um vai parecer confiante mesmo sendo fictício, e alguém com os números reais vai notar que a proposta não corresponde à realidade.
Nenhuma forma de saber depois se funcionou
Uma proposta sem métricas de sucesso é difícil de aprovar com confiança, e se for aprovada mesmo assim, não há uma forma acordada de verificar seis meses depois se o projeto entregou.
Usando O Que Você Já Tem
Cole seu material de referência em vez de começar do zero
Se você tem uma proposta anterior para algo semelhante, notas brutas de reunião sobre o problema, ou até um esboço pela metade, cole-o em vez de descrever o projeto de memória do zero. O Claude pode organizar e aprimorar material que você já tem muito mais fielmente do que pode inventar o contexto específico, o histórico e as restrições do seu projeto real a partir de uma descrição de uma frase.
Isso importa especialmente para a declaração do problema. Se o problema surgiu em uma reunião, em uma reclamação de cliente, ou em uma tentativa anterior fracassada de algo semelhante, esse contexto pertence ao prompt. Uma declaração do problema construída apenas a partir do seu resumo atual da questão costuma perder o detalhe específico que fez o problema ser real e valer a pena resolver.
O mesmo vale para restrições. Se sua organização já tem um modelo padrão de proposta, uma faixa de orçamento típica para esse tipo de projeto, ou uma convenção de cronograma habitual, dê isso ao Claude diretamente em vez de deixá-lo recorrer a uma estrutura genérica. Uma proposta que já corresponde ao que sua organização espera ver nesse tipo de documento é lida com mais seriedade do que uma que parece um modelo de outro lugar.
Vale a pena manter uma pasta contínua com propostas que foram aprovadas na sua organização, mesmo que informalmente, e colar uma que deu certo ao lado do seu próprio rascunho quando possível. O Claude consegue identificar o padrão do que costuma funcionar, seja um certo nível de formalidade, uma preferência por parágrafos curtos em vez de longos, ou o hábito de começar pela mitigação de riscos, e aplicar esse mesmo padrão ao seu rascunho atual em vez de recorrer a uma estrutura genérica que não combina com o que realmente funciona onde você trabalha.
Antes De Enviar
O que verificar antes que a proposta chegue ao leitor
Leia a seção de escopo primeiro e pergunte-se se ela descreve exatamente o que você pretende fazer, nem mais nem menos. Essa é a seção mais propensa a causar problemas depois se for mais vaga ou ampla do que sua intenção real, porque ela se torna o ponto para onde todo mundo aponta uma vez que o projeto está em andamento.
Verifique cada número contra a realidade: o cronograma, o tamanho da equipe, o orçamento. Um plano que parece confiante mas é baseado em um número adivinhado é pior do que um honesto "cronograma ainda não finalizado", porque o primeiro é tratado como um compromisso no momento em que alguém o lê.
A estrutura aqui te dá um rascunho forte rapidamente; o julgamento sobre o que sua organização e seu leitor realmente precisam para essa proposta específica ainda é seu antes de ela ser enviada.
Uma proposta clara é lida. Uma vaga é ignorada.
A estrutura é reutilizável para toda proposta depois dessa. As lições gratuitas da Nightschool AI percorrem tarefas reais de escrita no trabalho com o Claude, incluindo os julgamentos sobre escopo e público.
Perguntas frequentes
Qual é a coisa mais importante a dizer ao Claude antes dele redigir uma proposta?
Para quem é a proposta e qual decisão você precisa que ela tome. Uma proposta para sua própria equipe planejar e uma pedindo que um executivo aprove um orçamento precisam de enquadramentos diferentes, mesmo para o mesmo projeto.
Devo dar ao Claude um número de orçamento se eu ainda não tenho um?
Não. Diga que o orçamento ainda não está finalizado em vez de deixar o Claude adivinhar um número. Um número inventado que parece confiante é tratado como um compromisso no momento em que alguém com os números reais o vê.
Por que a proposta precisa de uma seção explícita sobre o que está fora do escopo?
Sem ela, os leitores preenchem a lacuna com suas próprias suposições sobre o que o projeto inclui, que costumam ser mais amplas do que você realmente pretende. Declarar explicitamente o que está excluído previne esse desvio.
Como escrevo uma proposta que funcione tanto para minha equipe quanto para um executivo?
Escreva primeiro a versão detalhada para sua equipe, depois peça ao Claude para adaptá-la para o leitor executivo: comece com o caso de negócio e o custo, reduza o detalhe técnico, e mova especificações de implementação para um apêndice.
Posso usar notas de uma proposta anterior ou reunião em vez de começar do zero?
Sim, e você deveria. Cole o material de referência que você já tem. O Claude organiza e aprimora material real muito melhor do que pode inventar o contexto específico do seu projeto a partir do nada.
Por que a proposta precisa de métricas de sucesso?
Sem uma forma declarada de medir sucesso, a proposta é mais difícil de aprovar com confiança, e não há uma forma acordada de verificar depois se o projeto realmente entregou o que prometia.
Como devo verificar um rascunho antes de enviá-lo a um stakeholder?
Peça ao Claude para ler como o stakeholder faria e listar as perguntas que ele teria antes de aprovar. Depois verifique separadamente cada número do rascunho contra suas restrições reais antes de enviar.
E se minha organização já tem um modelo padrão de proposta?
Dê-o ao Claude diretamente em vez de deixar o rascunho recorrer a uma estrutura genérica. Uma proposta que já corresponde ao formato esperado pela sua organização é lida com mais seriedade do que uma que não corresponde.
Uma proposta aprovada começa com restrições reais
A estrutura é reutilizável a cada vez. Dar a ela números honestos em vez de suposições é a parte que vale a pena acertar.