Escopo do produto e escopo do projeto: qual a diferença
A diferença entre escopo do projeto e escopo do produto parece detalhe de prova de certificação, até o dia em que o cliente recusa a entrega. O sistema faz tudo o que estava na especificação, mas ninguém treinou os usuários, os dados antigos não foram migrados e o manual nunca foi escrito. O produto estava completo; o projeto, não. Ou o contrário: a equipe cumpriu cada atividade do cronograma, e o aplicativo entregue não resolve o problema de quem vai usá-lo.
Os dois escopos respondem a perguntas diferentes. O escopo do produto diz o que será entregue e como esse resultado deve se comportar. O escopo do projeto diz que trabalho precisa ser feito para chegar lá. Separar as duas coisas evita discussões no aceite, melhora as estimativas e deixa claro quem responde por cada decisão.
Formação relacionada
Gestão de Produto: CPM-F e CPM-E
Noventa videoaulas sobre descoberta, métricas, ciclo de vida e priorização. Os dois exames da PMCert inclusos.
O que é escopo do produto
Escopo do produto é o conjunto de características e funções que definem o produto, serviço ou resultado. É a resposta à pergunta "o que essa coisa precisa ser e fazer?". Quem costuma responder por ele é o gerente de produto, como mostra o artigo sobre o que faz um gerente de produto. Num aplicativo, são as funcionalidades, as regras de negócio, os requisitos de desempenho e segurança. Numa casa, é a planta, o número de cômodos, o padrão de acabamento. Num evento, é o formato, a programação, o número de participantes e a experiência esperada.
O escopo do produto é descrito por requisitos: histórias de usuário, especificações funcionais, critérios de aceite, protótipos, memorial descritivo. Ele é verificado contra esses requisitos. A pergunta de verificação é: o produto faz o que deveria fazer?
O que é escopo do projeto
Escopo do projeto é o trabalho que precisa ser realizado para entregar o produto com as características e funções especificadas. Inclui o trabalho de construir o produto e também tudo o que cerca a entrega: planejamento, testes, homologação, treinamento, migração de dados, documentação, comunicação com as partes interessadas e encerramento.
O escopo do projeto é descrito na declaração de escopo e decomposto na Estrutura Analítica do Projeto (EAP). Ele é verificado contra o plano do projeto. A pergunta de verificação é: o trabalho combinado foi feito?
Essas definições seguem o glossário do Guia PMBOK, do Project Management Institute (PMI), que trata escopo do produto como as características e funções do resultado e escopo do projeto como o trabalho executado para entregá-lo. Para o escopo do projeto em detalhe, com o que colocar na declaração e o que deixar de fora, veja o artigo sobre o que é escopo do projeto.
Escopo do projeto e escopo do produto lado a lado
| Aspecto | Escopo do produto | Escopo do projeto |
|---|---|---|
| Pergunta | O que vamos entregar? | Que trabalho faremos para entregar? |
| Descrito em | Requisitos, histórias, especificação, protótipo | Declaração de escopo, EAP, plano do projeto |
| Verificado contra | Requisitos e critérios de aceite | Plano do projeto (escopo, prazo, custo) |
| Quem costuma decidir | Gerente de produto, Product Owner, cliente | Gerente de projetos, com a equipe e o patrocinador |
| Tempo de vida | Enquanto o produto existir | Do início ao encerramento do projeto |
| Exemplo em software | Login por biometria, relatório de vendas por região | Testes de carga, treinamento de 40 usuários, migração da base |
Repare na linha "tempo de vida". O produto continua existindo e mudando depois que o projeto termina; o projeto acaba. Essa é a razão pela qual empresas de produto digital falam tanto em backlog contínuo e menos em escopo fechado.
Exemplos em três tipos de projeto
Implantação de um sistema de agendamento numa rede de clínicas. Escopo do produto: agendamento online, confirmação por mensagem, integração com a agenda dos médicos, relatório de faltas. Escopo do projeto: levantamento com as recepcionistas, configuração em cada unidade, carga das agendas existentes, treinamento das equipes, operação assistida no primeiro mês, encerramento formal.
Construção de uma casa. Escopo do produto: três quartos, área de 120 metros quadrados, acabamento conforme memorial descritivo, aquecimento solar. Escopo do projeto: aprovação na prefeitura, contratação de fornecedores, execução das etapas da obra, fiscalização, vistoria e entrega das chaves.
Convenção anual de vendas. Escopo do produto: dois dias de programação, 300 participantes, palestras, premiação e jantar. Escopo do projeto: escolha e contratação do local, logística de viagens, credenciamento, ensaio, pesquisa de satisfação e prestação de contas.
Os exemplos são ilustrativos. Em todos, o escopo do projeto contém o escopo do produto, porque construir o produto faz parte do trabalho, mas vai além dele.
Como os dois escopos se conectam
O escopo do produto alimenta o escopo do projeto. Cada requisito do produto gera trabalho: desenvolver, testar, documentar, treinar. Por isso uma mudança no produto sempre mexe no projeto, mesmo quando parece pequena. "Só mais um campo no relatório" pode significar ajuste no banco de dados, novos testes e atualização do material de treinamento.
O caminho inverso também existe. Restrições do projeto limitam o produto: se o prazo é fixo por causa de uma data legal ou de uma campanha, o escopo do produto precisa caber nele. A forma de decompor esse trabalho num projeto de software, com entregas de produto e de gestão na mesma estrutura, está no exemplo de EAP de projeto de software.
O que muda em projetos ágeis
Em abordagens ágeis, a relação se inverte com frequência. Prazo e equipe ficam fixos (Sprints de duração definida, time estável) e o escopo do produto varia: o backlog é reordenado a cada ciclo conforme o que se aprende com os usuários. O escopo do projeto, nesse caso, é definido mais pelo objetivo e pela janela de tempo do que por uma lista fechada de funcionalidades.
Isso não elimina a diferença entre os dois. Mesmo num time ágil, existe trabalho que não é funcionalidade: preparar ambientes, migrar dados, treinar o atendimento, comunicar o lançamento. Quando esse trabalho fica fora do backlog, ele aparece de surpresa no fim. Técnicas para controlar o escopo nesse ambiente estão em gestão de escopo em produtos digitais.
Erros que nascem da confusão
- Declaração de escopo que só lista funcionalidades. O cronograma esquece treinamento, migração e operação assistida, e o projeto estoura no fim.
- Aceite sem critério de produto. O projeto é encerrado porque as atividades foram cumpridas, mas ninguém verificou se o produto atende aos requisitos.
- Mudança de produto tratada como detalhe. Uma funcionalidade nova entra "por fora", sem avaliar o impacto no trabalho, no prazo e no custo. É o caminho mais curto para o aumento descontrolado de escopo.
- Gerente de projetos decidindo o produto, ou o contrário. Quando os papéis se misturam, ninguém responde pela qualidade da decisão. A divisão de responsabilidades entre as duas funções está em gerente de produto ou gerente de projeto.
Perguntas para separar os dois na reunião de início
Na reunião de abertura, cinco perguntas costumam bastar para que cada escopo fique no seu lugar:
- Qual problema o produto resolve e como vamos saber que resolveu?
- Quais características são obrigatórias no primeiro lançamento e quais podem vir depois?
- Que trabalho, além de construir, precisa acontecer para o produto ser usado: treinamento, migração, comunicação, suporte?
- Quem aprova mudanças no produto e quem aprova mudanças no prazo e no custo?
- O que marca o fim do projeto, e quem passa a cuidar do produto depois disso?
A quinta pergunta é a que mais falta. Sem ela, o projeto nunca termina de verdade, porque cada melhoria do produto vira "mais uma entrega" do mesmo projeto, e o time de operação recebe um sistema sem saber que agora ele é seu.
Como aplicar no seu próximo projeto
Antes de fechar o planejamento, faça duas listas numa folha: à esquerda, o que o produto precisa ter e fazer; à direita, todo o trabalho necessário para que ele chegue funcionando às mãos de quem vai usar. Confira se cada item da esquerda gera pelo menos uma entrega na direita e se a direita tem o que não aparece no produto. Depois, defina quem aprova mudanças em cada lista.
Se você atua na fronteira entre produto e projeto e quer dominar o lado do produto, com descoberta, requisitos e priorização, o curso de gestão de produto da Projeto Diário organiza esse conhecimento com exemplos de produtos digitais.
