Entregáveis do Projeto: Definição, Tipos e Exemplos

Peça a cinco pessoas de uma equipe de projeto que citem "os entregáveis" e você normalmente receberá cinco respostas diferentes: algumas serão tarefas, outras metas, e uma delas provavelmente será a data de um marco. Essa confusão não é um problema de vocabulário. É um problema de planejamento, porque um entregável é a única unidade de trabalho do projeto que é formalmente aceita ou rejeitada, e se a equipe não consegue concordar sobre o que conta como um, ninguém consegue concordar sobre o que significa "pronto".

Fatos principais

• A orientação do próprio PMI sobre declaração de escopo descreve os entregáveis como "itens principais, de nível resumido, cuja entrega plena e satisfatória marca a conclusão do projeto", uma definição que o PMI vem usando de forma consistente em seu material sobre escopo do projeto.
• O PMBOK Guide, Oitava Edição (PMI, novembro de 2025) é o padrão atual e nomeia o escopo, o domínio que governa o que um projeto deve entregar, como um dos sete domínios de desempenho, ao lado de governança, cronograma, finanças, partes interessadas, recursos e risco.
• A pesquisa Pulse of the Profession do PMI (2014, série "The High Cost of Low Performance") constatou que quase metade, 47%, dos projetos malsucedidos não atinge seus objetivos por causa de um gerenciamento impreciso de requisitos, a mesma lacuna que aparece depois como entregáveis que ninguém consegue concordar que foram de fato concluídos.
• O Scrum Guide define um Increment, a versão agile de um entregável, como utilizável no momento em que atende à Definition of Done da equipe: "No momento em que um item do Product Backlog atende à Definition of Done, nasce um Increment."

O que é um entregável de projeto?

Um entregável de projeto é qualquer resultado único e verificável, um produto, documento, serviço ou resultado, que um projeto deve produzir e entregar formalmente antes que aquela parte do trabalho conte como concluída. Um entregável não é uma meta e não é uma tarefa. É uma coisa: algo específico o bastante para apontar, inspecionar e aceitar ou devolver.

A orientação do próprio PMI sobre declaração de escopo enquadra os entregáveis da mesma forma: "itens principais, de nível resumido, cuja entrega plena e satisfatória marca a conclusão do projeto". Esse já é um teste útil por si só. Se você não consegue descrever algo como um item que é entregue e aceito de forma satisfatória, provavelmente não é um entregável: é uma fase, uma atividade ou uma meta usando o nome de um entregável.

Os entregáveis estão no centro de como um projeto é de fato planejado e controlado. Eles saem da declaração de escopo do projeto, são decompostos pela estrutura analítica do projeto em partes que podem ser agendadas e são aprovados com base nos critérios de aceitação. Todos os outros artefatos de planejamento de um projeto, o cronograma, o orçamento, a RACI, existem para que os entregáveis sejam produzidos e aceitos no prazo.

Entregável vs marco vs objetivo vs resultado vs tarefa vs requisito

É aqui que a maioria das páginas sobre projetos fica vaga, e é onde a maioria dos projetos realmente enfrenta problemas. Seis termos são usados quase como sinônimos em conversas casuais, e cada um responde a uma pergunta genuinamente diferente. Segue um teste de uma linha para cada um.

Ler a tabela da esquerda para a direita traça a cadeia real de trabalho na maioria dos projetos: um objetivo de negócio justifica o projeto, o projeto produz entregáveis, cada entregável deve satisfazer um conjunto de requisitos, entregá-lo exige uma série de tarefas, concluí-lo é marcado por um marco e, se o projeto der certo, tudo isso acaba aparecendo como um resultado que o negócio pode apontar. Misturar esses termos em um plano é como "construir a página inicial" (uma tarefa) acaba listada ao lado de "aumentar a conversão" (um objetivo) na mesma lista de entregáveis, sem que ninguém saiba dizer qual dos dois é formalmente aceito.

A confusão entre entregável e marco é a mais comum na prática. Um gráfico de marcos mostra datas, não volume de trabalho, e um marco frequentemente indica quando um entregável foi concluído ou aprovado. Mas o marco é o marcador, não a coisa em si. "Página inicial publicada" pode ser um marco no cronograma e se referir a um entregável aceito no mesmo dia. Estão relacionados, mas não são a mesma coisa.

Tipos de entregáveis de projeto

Depois de confirmar que algo é realmente um entregável, ainda ajuda classificá-lo. Quatro eixos aparecem em quase todo projeto, e saber em qual quadrante um entregável se encontra diz quem o revisa, com que formalidade ele é aceito e quanta visibilidade precisa ter fora da equipe de entrega.

Entregáveis internos vs externos

Os entregáveis externos carregam mais risco se os critérios de aceitação forem vagos, porque divergências podem virar disputas contratuais em vez de atrito interno. Esse é grande parte do motivo pelo qual um statement of work costuma listar os entregáveis externos de forma explícita, com os termos de aprovação anexados, enquanto os entregáveis internos muitas vezes podem ser aceitos com uma mensagem no Slack e uma caixa de seleção.

Processo, produto, tangível, intangível, intermediário e final

A maioria dos entregáveis reais fica na interseção de mais de um eixo. Um relatório de testes de UAT é um entregável de processo, tangível e geralmente intermediário. Um aplicativo móvel publicado é um entregável de produto, tangível e final. Nomear o tipo desde o início ajuda a decidir, antes de o trabalho começar, quem o revisa e quão rigorosa essa revisão precisa ser.

Do escopo ao entregável aprovado: como os entregáveis são derivados

Os entregáveis não são inventados no meio do projeto. Eles são derivados por uma cadeia específica, e pular um elo dessa cadeia é a origem da maioria das conversas do tipo "espera, quem concordou com isto?".

A declaração de escopo do projeto é onde cada entregável é nomeado pela primeira vez, como uma locução nominal (uma coisa), nunca como uma atividade (um verbo). A estrutura analítica do projeto então pega esses entregáveis nomeados e os decompõe até que cada pacote de trabalho seja pequeno o bastante para um responsável estimar e concluir com confiança. Em projetos em que o escopo completo não pode ser conhecido de antemão, as equipes usam o rolling wave planning para manter os entregáveis de curto prazo totalmente detalhados e deixar os posteriores intencionalmente grosseiros, refinando-os apenas conforme a onda deles se aproxima. Quando um pacote de trabalho é concluído, ele deve corresponder claramente a um entregável nomeado na declaração de escopo original. Se não corresponder, geralmente é expansão do escopo ou um entregável que ninguém realmente planejou.

Exemplos de entregáveis de projeto por setor

Os nomes dos entregáveis mudam completamente conforme o setor, mas a forma subjacente, uma coisa específica e aceitável, não muda. Veja como são entregáveis reais em seis domínios comuns.

Observe o padrão na coluna do aprovador. Sempre há alguém específico nomeado, nunca "a equipe" ou "os stakeholders". Um entregável sem aprovador nomeado não está de fato sendo gerenciado como entregável, é apenas trabalho parado em uma lista esperando que alguém um dia perceba que está concluído. Atribuir esse responsável é exatamente para o que serve uma RACI: todo entregável precisa de exatamente uma pessoa responsável por conseguir sua aceitação, mesmo quando várias pessoas contribuem para produzi-lo.

Como um entregável é de fato aceito

É aqui que a maioria dos projetos realmente falha, não na construção, mas na entrega. Um entregável "pronto" segundo o julgamento da própria equipe e um entregável "aceito" por quem detém a decisão são dois eventos diferentes, e tratá-los como um só é como as disputas acontecem.

Definition of done vs critérios formais de aceitação

Uma definition of done é o padrão de qualidade da própria equipe: código revisado, testado, documentado, seja o que for que a equipe sempre exige antes de dar algo por concluído. Os critérios de aceitação são específicos de um entregável e pertencem à pessoa com autoridade para dizer sim. Um entregável pode cumprir totalmente a definition of done da equipe e ainda assim falhar na aceitação formal, porque o aprovador está verificando um padrão diferente, específico do entregável. Os dois portões precisam ser passados. Nenhum substitui o outro.

Quem de fato aprova

A aceitação não é uma impressão, é uma decisão tomada por uma pessoa específica com autoridade para tomá-la. Para entregáveis internos, costuma ser um gestor ou um revisor par. Para entregáveis externos, voltados ao cliente, normalmente é nomeada no próprio statement of work, junto com o que acontece se o entregável for rejeitado: uma janela de retrabalho definida, uma data de nova revisão, às vezes um marco de pagamento vinculado à assinatura. Os projetos que deixam de nomear um aprovador antecipadamente tendem a descobrir, no pior momento possível, que três pessoas diferentes acreditam ser a que tem autoridade de aprovação, e nenhuma delas concorda.

Documentando entregáveis: o registro de entregáveis

Um registro de entregáveis (às vezes chamado de tracker ou log de entregáveis) é a única fonte de verdade para todos os entregáveis de um projeto: o que é, quem é o responsável, quando vence, o que significa "aceito" e em que ponto está agora. Sem um, o status dos entregáveis vive em e-mails dispersos e em quem lembrar de perguntar.

Mantenha o registro atualizado na mesma cadência do seu relatório de status do projeto, para que o status dos entregáveis nunca esteja desatualizado quando os stakeholders perguntarem. Quando os critérios de aceitação ficam no registro e não na caixa de entrada de alguém, uma entrega contestada vira uma consulta de dois minutos em vez de um concurso de memória. Para entregáveis vinculados a requisitos específicos de produto ou contratuais, cruze o registro com uma matriz de rastreabilidade de requisitos, de modo que todo requisito possa ser rastreado até o entregável que deve satisfazê-lo, e todo entregável possa ser rastreado até o requisito que justificou sua construção.

Problemas comuns com entregáveis

A maioria das disputas sobre entregáveis remonta a um pequeno número de reincidentes. Nomeá-los facilita pegá-los antes que custem a alguém uma semana de retrabalho.

A expansão do escopo merece destaque próprio aqui, porque raramente chega como um novo entregável óbvio. Quase sempre chega disfarçada de uma pequena adição a um existente, um "campo extra rápido" no formulário, mais um slide na apresentação, uma página que ninguém previu originalmente. Cada uma dessas adições muda o que o entregável de fato é, o que significa que também muda o que "aceito" deveria significar.

Entregáveis no agile: incrementos e definition of done

As equipes agile normalmente não usam a palavra "entregável" no dia a dia, mas o conceito não desaparece, só é renomeado e entregue com mais frequência. No Scrum, a unidade equivalente é o Increment: uma parte do produto que é utilizável e potencialmente liberável no momento em que atende à definition of done da equipe.

O Scrum Guide é explícito ao dizer que esse padrão não é opcional: "O trabalho não pode ser considerado parte de um Increment a menos que atenda à Definition of Done", e, uma vez que atende, "no momento em que um item do Product Backlog atende à Definition of Done, nasce um Increment". É uma versão mais rigorosa e contínua da mesma lógica de entrega que governa um entregável tradicional. A diferença não está em se a aceitação acontece, mas em com que frequência e quem verifica. Um projeto preditivo pode aceitar formalmente cinco entregáveis ao longo de um ano. Uma equipe Scrum faz a mesma pergunta de aceitação a cada sprint, às vezes todos os dias, só que em uma escala muito menor a cada vez.

Melhores práticas

• Nomeie os entregáveis como coisas, nunca como atividades. Se o nome começa com um verbo, ele pertence à EAP ou à lista de tarefas, não à lista de entregáveis.
• Escreva os critérios de aceitação antes de o trabalho começar, não depois. Critérios escritos retroativamente descrevem o que foi construído, não o que era realmente necessário.
• Atribua exatamente um responsável por entregável. A responsabilidade compartilhada é como os entregáveis emperram silenciosamente sem que ninguém se sinta pessoalmente responsável.
• Separe explicitamente "pronto" de "aceito". O padrão de qualidade da própria equipe e a aprovação formal de um stakeholder são duas verificações diferentes, e as duas precisam ser passadas.
• Mantenha um registro de entregáveis vivo, não a memória. Status, responsável, data de entrega e critérios de aceitação devem estar todos em um só lugar que todos possam consultar.
• Trate toda "pequena adição" como uma questão de escopo. A forma mais rápida de a expansão do escopo entrar em um projeto é por mudanças em um entregável existente que nunca passam pelo controle de mudanças.
• Ajuste a formalidade da aceitação ao tipo de entregável. Um entregável final voltado ao cliente merece uma revisão mais rigorosa do que um rascunho interno intermediário; reserve o processo mais pesado para onde o risco realmente está.
• Rastreie os entregáveis até os requisitos, não apenas adiante até as tarefas. Uma matriz de rastreabilidade de requisitos pega os entregáveis que existem sem motivo documentado e os requisitos para os quais ninguém nunca construiu um entregável.

Entregável é a única palavra de um plano de projeto que nunca deveria ser ambígua, porque é aquilo que todos são, em última análise, pagos para produzir, e aquilo que outra pessoa precisa concordar que de fato está concluído. Nomeie os entregáveis como coisas, escreva seus critérios de aceitação antes de qualquer um começar a construir e dê a cada um exatamente um responsável e um aprovador. Acertando isso, a maioria das conversas do tipo "espera, isto está mesmo pronto?" que consomem as últimas semanas de um projeto simplesmente deixa de acontecer.