TURMA 03

Bruno_Costa_Castro_T03

GERENCIAMENTO DO ESCOPO EM PROJETOS:

O gerenciamento do escopo é responsável por definir, planejar e aprovar todo o
trabalho envolvido na condução de qualquer empreendimento, observando os
requisitos e as necessidades do cliente. Nesse sentido, o gerenciamento eficaz do
escopo é fundamental para a consecução bem-sucedida de qualquer projeto, além
de fundamentar e orientar o bom desempenho das demais áreas do
gerenciamento do projeto.

Conheça as competências que você deverá desenvolver ao longo desta

disciplina:

 Utilizar conceitos, técnicas e melhores práticas com o propósito de definir, planejar,

validar e controlar o escopo de projetos;
 Identificar, adequadamente, os requisitos do projeto, considerando as necessidades e
expectativas das partes envolvidas (stakeholders);
 Aplicar ferramentas e técnicas ao planejamento do escopo de um projeto real e
 Apreender a relevância dos processos de validação e controle do escopo bem como a
necessidade de promover e manter atualizados todos os planos e documentos
decorrentes de mudanças do escopo aprovadas durante a realização do projeto.

MÓDULO 1 – CONCEITOS FUNDAMENTAIS:

Ao final deste módulo, esperamos que você seja capaz de:

 Definir o gerenciamento do escopo e localizá-lo no contexto do gerenciamento de

projetos;
 Reconhecer a terminologia e os principais conceitos envolvidos no gerenciamento do
escopo;
 Distinguir o escopo do projeto do escopo do produto e
 Identificar, em conformidade com a 6ª edição do Guia PMBOK®, os processos
relacionados ao gerenciamento do escopo do projeto e a sua relação com os grupos de
processos do gerenciamento de projetos.

A IMPORTÂNCIA DO ESCOPO:
O estabelecimento de um vocabulário e de um entendimento comuns acerca dos
conceitos e dos princípios do gerenciamento de projetos é tratado no Guia
PMBOK® como condição essencial para o desenvolvimento da disciplina e da sua
comunidade de praticantes.

APOSTILA – GERENCIAMENTO DE ESCOPO EM

PROJETOS:
(Introdução):

Segundo pesquisas atuais, as causas mais comuns de falhas em projetos em

organizações mundo afora são: problemas de comunicação, escopo mal definido e
escopo que sofre constante mudança. Ou seja, de todos os possíveis e imaginários
problemas, o assunto “escopo” aparece por duas vezes nas três primeiras
colocações, sendo que, se pararmos para avaliar um pouco mais de perto tais
resultados, um escopo mal definido possui um enorme potencial para gerar
problemas de comunicação.

Entretanto, este assunto é muitas vezes negligenciado, seja por questões

estratégicas em que prevaleça um determinado padrão, por exemplo, privilegiar o
cumprimento de um cronograma em detrimento daquilo que se está entregando,
seja até mesmo por desconhecimento técnico.

O objetivo geral desta disciplina é apresentar o conceito de escopo e as suas

peculiaridades, assim como demonstrar a área de conhecimento do
gerenciamento do escopo em projetos, oferecendo um grau de compreensão que
produza efeitos imediatos de utilização do assunto estudado em organizações,
indivíduos e grupos de pessoas, que adotem o gerenciamento profissional de
projetos.

Por sua vez, os objetivos específicos são:

 Reconhecer os principais termos e as peculiaridades que envolvam o assunto

escopo em projetos.

 Identificar todos os processos da área do escopo em projetos, segundo

modernas práticas do mercado.

 Aplicar corretamente os processos da área de escopo ao longo de um projeto

real.  Demonstrar uma visão holística, percebendo a importância da área de
escopo em relação às demais áreas de conhecimento de um projeto.

 Elaborar e analisar os principais documentos relativos à área de conhecimento

do escopo em projetos.
CONCEITO HISTÓRICO:
Com o mundo dos negócios em ebulição após um momento histórico vivido pelo
período das grandes guerras mundiais, a transformação inicia-se exatamente por
meio de uma questão muito simples, afinal de contas, precisa-se entender o que é,
efetivamente, gerir alguma coisa. Foi exatamente nesse momento em que, ainda
segundo Drucker (1954), nasceu o conceito de Administração por Objetivos (APO).

APO consiste em um método colaborativo entre líderes e liderados, com cada um

entendendo perfeitamente o seu papel dentro do contexto organizacional,
trabalhando para delimitarem juntos os objetivos que precisam ser alcançados. Há
um planejamento; objetivos e formas de monitoramento são traçados;
responsabilidades são delegadas e, constantemente, compara-se o resultado com
o planejamento previamente estabelecido, no sentido de gerar um senso de
aferição de resultados. Também há necessidade de se delimitarem objetivos de
curto (operacionais), médio (táticos) e longo (estratégicos) prazo.

Foi quando George Doran (1981), aprimorando os trabalhos de Edwin Locke

(1968), reconheceu que muitas organizações precisavam atingir metas, objetivos,
mas muitas vezes esses objetivos eram estabelecidos de maneiras difusas.
Objetivos não deveriam ser tratados como inarticulados – aqui, percebe-se uma
pitada do conceito inicial de Drucker –, ao invés disso deveriam ser tratados como
coisas mensuráveis, no intuito de alavancar o sucesso de uma organização.

Então, uma a melhor definição para o conceito de objetivo surgiu com a utilização
do acrônimo Smart, que vem a ser: S de specific, em inglês, específico; mensurável;
atingível; relevante; e com tempo limite. Ao adotar que um objetivo precisaria
possuir todas essas cinco propriedades em conjunto, e não apenas uma ou outra,
Doran conseguiu solidificar o conceito de estabelecimento de metas para gestores
em muitas organizações.

Por exemplo, não adianta tentar definir o escopo de um projeto sem entender os
objetivos organizacionais e os benefícios estimados para a entrega do produto,
serviço ou resultado a ser gerado pelo projeto. O conceito Smart nos auxilia nesse
processo de entendimento, pois minimamente um objetivo deverá ser tratado por:
As cinco condições devem aparecer sempre em conjunto, nunca apenas uma ou
outra. Assim como em outras disciplinas, os conhecimentos relacionados ao
gerenciamento de projetos devem ser padronizados bem como globalmente
reconhecidos e aceitos pelos profissionais envolvidos, de modo a possibilitar a
evolução constante da disciplina.

Contudo, a maneira mais simples de reconhecer o objetivo de um projeto é

compreender qual é o seu escopo, que nada mais significa do que compreender o
que precisa ser feito ou entregue pelo time do projeto. Para isso, precisa-se
compreender um pouco mais a respeito de algumas nuances do termo “escopo”.

ESCOPO E CICLO DE VIDA DE UM PROJETO:

Uma abordagem errada pode desencadear uma série de falhas no trabalho do
time do projeto. Estatísticas apontam que cerca de 30% dos projetos falham ou
não atingem os objetivos planejados.

De acordo com o PMI (2017b), existem quatro tipos de ciclos de vidas de projeto.
Isso significa que um time de projeto precisa ter conhecimento a respeito dessas
variadas formas no intuito de selecionar uma abordagem condizente com as ações
demandadas pelo produto, serviço ou pela condição que será gerada.

Os tipos são:

 Ciclo de vida preditivo – trata-se de processo sequencial. Talvez a abordagem

mais tradicional de todas, com os esforços de planejamento ocorrendo em uma fase
inicial do projeto. Depois, em uma única jornada, é realizada a execução.

 Ciclo de vida iterativo – uma abordagem empírica, que permite aos poucos
retorno dos principais stakeholders engajados no projeto. Os feedbacks são
recebidos pelo time do projeto sobre trabalhos ainda não finalizados, no intuito de
melhorar o produto, o serviço ou a condição e conseguir modificá-los antes de a
versão final ser efetivamente entregue.

 Ciclo de vida incremental – uma abordagem escalonável, que, em oportunidades

pontuais ao longo do projeto, fornece versões do produto, do serviço ou da condição
não finalizados, mas com possibilidade de utilização imediata, mesmo que não na
sua total capacidade.
 Ciclo de vida ágil – junção das abordagens iterativa e incremental em um único tipo
de ciclo de vida. Ao mesmo tempo em que se permitem entregas constantes de
versões de produtos, serviços ou condições com utilização imediata, os feedbacks
também são frequentes, no intuito de aprender com a versão disponibilizada,
analisá-la e depois melhorá-la.

Nenhum ciclo de vida será perfeito para todos os tipos de projeto. Em ciclos
preditivos, existe a vantagem de se trabalhar em um ambiente com baixo grau de
incertezas e complexidade, permitindo poucas mudanças e poucas entregas
intermediárias – às vezes, nenhuma –, adotando um sequenciamento previsível de
ações.

No ciclo iterativo, há possibilidade de feedbacks sobre trabalhos parcialmente

concluídos, visando à melhoria contínua e a modificações constantes. Já no ciclo
de vida incremental, o foco encontra-se nas entregas potencialmente escalonáveis
com o cliente ou usuário final tendo a possibilidade de aproveitamento imediato
do produto, serviço ou condição, entregue em uma versão inacabada. Por fim, o
ciclo de vida ágil adota as características dos dois últimos ao mesmo tempo. Como
frequentemente entregará versões parciais e receberá feedbacks, há emprego de
conceitos de transparência de processos, confiança e engajamento entre time do
projeto e cliente, ou usuário final, adotando o foco de priorizar as funcionalidades
– veja o significado mais adiante, no item 1.4 deste mesmo material – mais
importantes e que geram mais valor às principais partes envolvidas. O grande
argumento para a utilização desse tipo de ciclo de vida é na questão estratégica,
pois a visualização do Return on Investiment (ROI) – retorno sobre o investimento –
será mais cedo do que em outros ciclos de vida, e isso facilita o processo de
tomada de decisão.

Por fim, como o gerenciamento de projetos dificilmente é tratado como uma

ciência exata, haja vista as múltiplas variáveis no momento de desenvolver um
projeto, o PMI (2017b) também determina que não há necessidade de utilização
de um único tipo de ciclo de vida durante todo o projeto. É, sim, possível a
combinação de elementos de abordagens distintas no intuito de criar o que é chamado
de abordagem híbrida.

E como o escopo se posiciona em relação a tudo isso? Para as modernas técnicas

de gerenciamento de projetos, mais que desempenhar atividades distribuídas por
processos sistêmicos, o verdadeiro sentido de gerenciar um projeto está em
encontrar a solução para uma necessidade, gerar uma nova ideia ou até mesmo
aproveitar uma oportunidade. A entrega precisa ser realizada, não mais com foco
em planejamentos restritos, e, sim, com grau de adaptabilidade satisfatório para
continuamente reconhecer onde e quando entregar valor, que precisa ser
percebido pelo cliente ou usuário final. É, talvez, o maior desafio de todo o projeto.
Afinal de contas, a percepção desses stakeholders em relação ao que está sendo
gerado pode variar ao longo do projeto, principalmente com um produto, um
serviço ou uma condição ganhando forma, e novas ideias amadurecendo o
processo de concepção.

A figura 2 demonstra que, com a utilização de parâmetros de fixação de escopo, o

processo de gestão deve focar a variação dos controles de custos e de cronograma
– tempo – para que essa flutuabilidade permita entregar aquilo que foi
efetivamente solicitado, da maneira como foi solicitado, nada a mais nem a
menos. Já com a proposta de entrega de valor observada na estratégia de
condução do projeto, o foco então passa a ser outro, e isso permite que, desta vez,
o escopo flutue, deixando as restrições para as áreas de custos e de cronograma.
Dentro da proposta de uma limitação de cronograma, por exemplo, um time
poderá dizer que em dois meses entregará um determinado produto de uma
determinada maneira. O trabalho de evolução desse produto será
constantemente monitorado e controlado, significando que o escopo poderá
adaptar-se às muitas variáveis do projeto. Desenvolver bons produtos ou serviços
demanda tempo, consome dinheiro e necessita de equipes especializadas para
cada etapa da produção. Com o objetivo definido de entregar um produto final
que gere valor para o seu cliente ou usuário final, a tendência é que as principais
partes interessadas, dependentes do resultado final do projeto, fiquem satisfeitas.

É comum escutar nas organizações termos que retratam essas condições

demonstradas pelo triângulo invertido de uma maneira ligeiramente diferente.
Alguns preferem chamar de escopo fechado, quando a proposta é priorizar o
planejamento. Ao contrário, quando o escopo demonstrasse voltado para a
proposta de entrega de valor, comumente, escuta-se o termo escopo aberto.

O que não pode acontecer é tentar desenvolver um produto, um serviço ou uma

condição sem a utilização de uma metodologia aderente às necessidades de
desenvolvimento dos processos inerentes à execução do projeto e do modus
operandi do time. Afinal, qualquer método, ou framework, é melhor do que método
algum, principalmente quando falamos de algo que consome recursos, tempo,
energia e dedicação de tantas pessoas. É muito importante escolher um método
de trabalho apropriado, que faça sentido para o seu projeto e traga os resultados
esperados.

Conceitos importantes: ciclos iterativos, funcionalidades,

MVP, DoR, DoD, critérios de aceitação e critérios de
validação

TRIÂNGULO DE RESTRIÇÕES:
TRADICIONAL VERSUS INVERTIDO

O triângulo de restrições tradicional, tratado durante décadas como uma

referência nos trabalhos de escopo, custos e tempo (cronograma), começou a ser
questionado diante da possibilidade de um projeto ser executado com vieses de
ciclos de vida diferenciados. O escopo, que antes era visto apenas como algo fixo,
pode também ser gerenciado como algo variável ou até mesmo estimado.

O triângulo invertido nos dá a oportunidade de enxergar o sucesso do projeto de

uma forma diferente, resolvendo o paradoxo adaptabilidade versus conformidade.
No triângulo tradicional, um bom escopo de projeto, um cronograma bem organizado
e fatores de custo alinhados medem a qualidade de um projeto. Já no triângulo
invertido, a qualidade não deve ser a finalidade de todo o projeto, mas sim permitir
estruturas de custo flexíveis para produzir o efeito desejado, o que inclui também a
qualidade, ou seja, a qualidade é apenas mais um tópico entre tantos outros. Nesse
caso, o que importa é a proposta de entrega de valor ao cliente ou usuário final, e nada
adiantará se esse valor não for percebido.

O que mantém um time motivado com mudanças de escopo frequentes? A

resposta está na responsabilidade de priorizar as entregas e determinar quais
serão implementadas bem como quando isso ocorrerá.

Junto à sua equipe, o gerente de projeto deve buscar o equilíbrio entre as

mudanças de escopo e as restrições de tempo e orçamento. Se o objetivo do
projeto é manter-se firme nas restrições de tempo e orçamento, a equipe deve
equilibrar essas restrições. Por outro lado, se o objetivo do projeto é maximizar os
requisitos das partes interessadas e impulsionar a proposta de entrega de valor, então
a equipe é livre para adicionar funcionalidades, o que aumentará potencialmente
os custos e empurrará o cronograma.
No entanto, na imagem superior, pode-se perceber que existe uma única jornada
sequenciada por processos no ciclo de vida preditivo. Por mais que em muitas
ocasiões esses grupos de processos se sobreponham, há um encadeamento lógico
e natural começando com o grupo de iniciação e seguindo com planejamento,
execução, monitoramento e controle – aqui, há uma exceção, pois o mesmo
ocorre ao longo de todo o projeto –, finalizando com o grupo de encerramento.

Quando comparamos isso com a imagem da parte de baixo da figura 3, que

demonstra os ciclos de vida ágeis podemos perceber que há o esforço de
iniciação, planejamento, execução, monitoramento e controle, praticamente da
mesma maneira, mas percebe-se que isso funciona para firmar a ocorrência do
primeiro ciclo de iteração. Isso significa que para a primeira “fase” do projeto há um
planejamento de 100% do que vai ocorrer dentro desse período, como também uma
execução completa para o trabalho proposto pelo planejamento e, novamente,
monitoramento e controle ocorrendo ao longo de todo o ciclo, mas não se
evidencia o trabalho de encerramento do projeto. Isso ocorre porque perto de
finalizar a execução já se pensa no próximo ciclo de iteração, e um novo
planejamento para um novo período de ações é realizado.

Segundo Cruz (2015), cada ciclo iterativo precisa terminar sendo capaz de
responder, pontualmente, às seguintes questões:

 Como podemos transformar a visão do produto em um produto real da melhor

maneira possível?
 Como podemos alcançar a satisfação do cliente e o ROI desejado?

 Quando, no pior cenário, poderemos entregar a versão X do produto, serviço ou

condição?

Um termo muito comum no momento de conduzir o trabalho do escopo ao longo de

um projeto é o de funcionalidade. Uma funcionalidade é algo passível de
execução, ou seja, algo definido como um comportamento ou até mesmo uma
ação, delimitado por uma caixa de tempo – timebox –, presumindo que exista um
momento de início para a execução dessa funcionalidade e um momento de fim,
claramente definidos.

É um trabalho que exige do time do projeto um grau de atenção redobrado, pois

um início mal estruturado poderá ser desastroso no momento em que o projeto
evoluir e as implicações de um trabalho de escopo desestruturado começar a
influenciar os trabalhos das demais áreas de conhecimento, por exemplo,
cronograma, recursos, qualidade, etc.

Outro importante conceito que auxilia na correta definição de funcionalidades é

entender o que é um MVP – ou minimum viable product (service) (MVS) –, ou,
na versão em português, mínimo produto (serviço) viável.

Um MVP, segundo Caroli (2015), ao adaptar as ideias originais de Eric Reis, “é a

versão mais simples de um produto que pode ser disponibilizado para o negócio,
focando na entrega de valor de acordo com objetivos de negócios e as
necessidades dos usuários”. O MVP serve, basicamente, para evitar desperdícios. Não
se deve gastar tempo, recursos e a paciência dos seus principais stakeholders
gerando algo que ao final pode vir a não agradar, em parte ou totalmente, ao seu
cliente. Então, testa-se gradativamente o potencial de uma entrega, antes de
enveredar muitos esforços no seu desenvolvimento. Assim, o time do projeto
possuirá condições de dosar o ritmo de trabalho e focar a proposta de entrega de
valor, pois funcionalidades que não são tão importantes ficam como últimas
prioridades.
Esse conceito foi amplamente utilizado por empresas gigantes nos seus
segmentos, por exemplo, Facebook e Apple. Garantir a maximização do ROI é a
proposta desse ciclo do MVP. A partir de uma ideia ou necessidade inicial, cria-se
uma primeira versão do produto, do serviço ou da condição.

Essa versão não é perfeita, mas consegue incluir um grau mínimo das principais
características desejadas para o produto. Por exemplo, imagine que o seu projeto
seja construir um kart. O cliente solicitou que o kart fosse seguro, bonito e
ergonômico. Em determinados casos, como o item vinculado à segurança, existem
normas legais e técnicas que permitirão o time do projeto definir o grau mínimo
de padrão de segurança exigido para um kart. A partir do momento em que esse
padrão mínimo for atingido em uma primeira versão do produto, já começa a
surgir a ideia do MVP, apesar de não podermos considerá-lo como um MVP ainda.
Explico: o kart pode ser o mais seguro desenvolvido no mundo, mas as
características de beleza e ergonomia não estiverem ainda implementadas, não
conseguimos atingir a primeira versão desse produto. Portanto, será considerado
um MVP apenas quando conseguir unificar os padrões mínimos de segurança, beleza e
ergonomia. Contudo, um padrão de beleza seria uma avaliação subjetiva, e a opinião
do cliente, de pessoas ligadas a ele ou até mesmo a opinião pública terá um peso
fundamental nessa aprovação. Para que o time defina isso com propriedade, deverá
estabelecer padrões de beleza e então descobrir qual seria o padrão mínimo.
Depois da primeira versão desenvolvida, podem-se então colher feedbacks ou
medir detalhes no intuito de juntar a maior quantidade de informação válida 18
possível para que esses dados possam ser analisados, e novas ideias possam
surgir.
Assim, um novo ciclo do MVP poderá ser gerado. Trabalhar o escopo do projeto
utilizando o conceito do MVP não só permitirá ao time do projeto um aprendizado
constante em relação ao produto ou serviço que está sendo gerado, como
também será importante para receber feedbacks intermediários, antes do produto
totalmente finalizado. Somente por meio desses feedbacks é que o time do projeto
poderá analisar detalhes pertinentes à implementação das funcionalidades requeridas
pelo escopo do produto e então decidir o rumo a ser tomado em um próximo ciclo de
iteração, obviamente, nunca perdendo de vista o objetivo de negócio com o escopo do
projeto capitaneando os processos de tomada de decisão, conforme demonstrado no
projeto donut, na figura 5.

O MVP permitirá ao criador do donut, verificar detalhes como: se o tempo de

cozimento da massa foi corretamente executado, se a receita conseguiu ser
fielmente cumprida e os ingredientes agradam ao paladar dos potenciais
consumidores, se o tamanho atende às expectativas, etc.

Com o recolhimento dessas percepções, junta-se uma base de informações

suficientes para o processo de tomada de decisão e evolução natural do produto,
gerando, na sequência, novas versões que poderão produzir maior grau de
satisfação junto ao cliente ou usuário final.

Por fim, é necessário também compreender a importância dos termos: definition of

ready e definition of done. O curioso é que, ambas as palavras ready e done
possuem o mesmo significado em português: pronto.

Porém, há uma grande diferença no emprego desses dois termos quando o

trabalho do gerenciamento do escopo é exigido.

 Quando o produto, o serviço ou a condição que se vai gerar existe apenas

na imaginação de alguém ou de um grupo de pessoas, é necessário que as
suas características e condições sejam inicialmente definidas. Esse trabalho,
ou melhor, essa visão de produto, que é elaborada antes do próprio
 produto em si estar pronto, chama-se definition of ready (DoR). É como se
define o que seria considerado pronto em relação à visão desse produto.

 A partir do momento em que essa visão for gerada, servirá como ponto de
partida para o time do projeto. É como se dissessem: “Já temos condições
de compreender a ideia e estamos prontos para gerar o produto”.
Normalmente, quando se define uma característica ou condição, define-se
também o seu critério de validação.

Aqui, cabe um aparte para diferenciar critério de validação e critério de aceitação.

O primeiro trata de garantir que a condição ou característica desejada foi
efetivamente cumprida, e o segundo trata de realizar a formalização da entrega do
produto – ou parte do produto, do serviço ou da condição –, também conhecido
como handover.

O “de acordo” ou a ciência explícita do cliente em relação às entregas do projeto

são considerados critérios de aceitação. Ferramentas como relatórios de inspeção
são bem eficazes nesse momento. Os critérios de aceitação podem ser estipulados
para entregas intermediárias, mas o mais famoso de todos é, sem dúvidas, o
Termo de Encerramento do Projeto (TEP), onde ocorre a entrega final do produto,
do serviço ou da condição.

Para encerrar essa parte dos nossos ensinamentos, faltou definir o que vem a ser
o termo DoD – definition of done, que nada mais é, então, do que conferir se o
produto, o serviço ou a condição, depois da sua conclusão – em parte ou no todo –,
está de acordo com as características desejadas no momento do DoR, a situação
clássica de verificar se o realizado está de acordo com o que foi previsto. Em linhas
gerais, então, temos o pronto “de antes” (DoR), que funciona como uma visão de
futuro; e o pronto “de depois” (DoD), que confirma se o que foi desenvolvido está de
acordo com a definição inicial – ou modificada ao longo do projeto – do produto.
 FUNCIONALIDADE
Precisamos compreender corretamente o conceito de funcionalidade, que se resume a
tudo aquilo que pode ser realizado ou entregue. Sempre que for possível enquadrar
determinado comportamento ou ação dentro de um intervalo de tempo, teremos uma
proposta inicial para desenvolver uma funcionalidade.

fun·ci·o·na·li·da·de
(funcional + -idade)

substantivo feminino

1. Qualidade do que é funcional.

2. Uso especial para que algo é concebido. = FUNÇÃO, UTILIDADE
Fonte: DICIONÁRIO PRIBERAM DA LÍNGUA PORTUGUESA (2008-2013).
Disponível em: https://dicionario.priberam.org/funcionalidade. Acesso em: jan. 2020.

EXEMPLO
Quando uma equipe de projeto trabalha uma funcionalidade descrita como "gerar
relatório", por exemplo, estamos presumindo que ela terá de lidar com diferentes
informações acerca de um ou mais documentos em particular que definirão uma nova
dimensão do atributo "relatório". Segundo Jeffries et al. (2000), um produto pode ser
integralmente definido por meio das necessidades dos seus usuários. Nesse sentido,
a user story (ou, em português, história do usuário) é uma técnica que auxilia na
descrição de uma funcionalidade, definindo uma única maneira de executá-la, o que
deve ser feito, preferencialmente, no formato a seguir:
EU, COMO ____________ [quem é e o que faz a pessoa],

QUERO _______________ [fazer algo]

PARA ________________ [qual será a "recompensa"].

EXEMPLO 1

EU, COMO motociclista,

QUERO encontrar uma vaga permitida por lei

PARA evitar o recebimento de multa.

EXEMPLO 2

EU, COMO aluno de um curso EAD,

QUERO acompanhar o meu histórico de notas

PARA programar os meus estudos.

Cada uma dessas histórias de usuário poderia ter sido facilmente executada em projetos
reais, como um aplicativo de celular para ofertar vagas gratuitas em determinada região
ou uma plataforma virtual de fornecimento de cursos on-line.
Apesar de não ser essencial na maioria dos casos, algumas equipes de projeto também
trabalham com o conceito de "quando" essa funcionalidade poderá ser executada.

Para trabalhar com base em um formato associativo e na ideia de ciclos iterativos, é

recomendável apresentar na descrição todo o conjunto de pré-condições para a execução
de determinada funcionalidade, observando também as pós-condições que possam
surgir após a implementação do que foi planejado.

___________________________________________
MVP
Diante da necessidade de coletar requisitos, definir funcionalidades e entregar um
produto com a proposta de oferecer valor ao seu cliente, patrocinador ou usuário final,
chegamos a um ponto em que é fundamental a compreensão do conceito de minimum
viable product (service) (MPV) ou, na versão em português, mínimo produto (serviço)
viável ( MVS).
"Você está tentando descobrir nos primeiros dias de começar um produto: estamos
errados ou o mundo está errado?"

Patrick Collison – Fundador e CEO da empresa Stripe.

No intuito de prevenir desperdícios e entregar algo que ninguém deseje ou dê valor,

com agilidade suficiente para que a solução possa ser colocada em uso o mais rápido
possível e com o propósito de confirmar (ou não) se as teorias sobre o que está sendo
gerado encontram-se certas ou erradas aos olhos dos principais stakeholders, existe a
proposta de trabalhar com o conceito de um MVP.

No MVS, o significado do S (serviço) refere-se ao viés do intangível, mas

ainda assim apto a ser testado e servir como experiência de utilização.
 MMP significa minimum marketable product (ou, em português, produto
mínimo comercializável) e refere-se ao contexto em que o time do projeto
encontrou, finalmente, as características mínimas buscadas, iteração após
iteração, para ter, finalmente, um produto testável e digno de atender
minimamente às necessidades priorizadas das principais partes
interessadas, podendo enfim destiná-lo ao mercado.
O princípio subjacente ao conceito de produto mínimo viável é o seguinte:
aprender rapidamente, com investimento mínimo e dedicação limitada do
time do projeto.

DOR/DOD
Aprendemos que um ciclo iterativo é um período pré-determinado que
prioriza itens cujo valor possa ser valor percebido pelo cliente ou usuário
final e transforma-os no incremento de determinado produto.

No entanto, para reunir os itens a serem trabalhados em um ciclo, é

importante que as histórias de usuário (ou qualquer outra técnica cujo
objetivo seja definir as funcionalidades do produto, do serviço ou da
condição a ser gerada) estejam “prontas”.

É comum que sejam criadas histórias de usuários inacabadas ou não

refinadas, o que pode gerar muitos problemas durante o ciclo de iteração.

Para evitar esse tipo de problema, todo item determinado como "pronto"
precisa ser:

 claro – uma funcionalidade é clara se todos os membros da equipe do projeto

compartilharem a compreensão do que isso significa. Escrever de forma colaborativa e
adicionar critérios de validação ao que é de alta prioridade facilita o processo;
 viável – uma funcionalidade é viável se puder ser concluída dentro de um ciclo
iterativo, de acordo com a DoR (definition of ready). Se isso não for possível, ela
precisará ser decomposta e
 testável – uma funcionalidade é testável quando há uma maneira eficaz de determinar
se ela ocorre conforme o esperado (ou planejado). Os critérios de validação servem para
assegurar que cada funcionalidade possa ser testada e chancelada.

Essencialmente, uma DoD representa os critérios de validação compreendidos

dentro de um ciclo iterativo para provocar uma entrega parcial (também
chamada de release). Ela especifica o que a equipe do projeto deve fazer
para assegurar que o incremento do produto seja considerado "concluído".

 A DoR determina o status quo do produto, do serviço ou da condição a

ser gerada, e
 a DoD serve para chancelar se essas condições descritas no
momento do status quo foram efetivamente alcançadas.

A área de qualidade é responsável pela precisão e alcance desses requisitos do escopo

do projeto. Ela valida um determinado requisito se aprovado (ok), ou se não está (ok).
A turma do Escopo recebe essa resposta do setor de qualidade, sendo responsável por
fazer a aceitação vinda da qualidade.
O escopo, a entrega só acontece quando é feita essa formalização. O trabalho do escopo
é baseado em critérios de aceitação, transferência, delivery, amparados pela área da
qualidade. Um bom trabalho da qualidade alivia e muito o time de trabalho do escopo
de projeto.
 DIFERENÇA ENTRE ESCOPO DO PROJETO E
ESCOPO DO PRODUTO
Segundo o PMI (2017a), o termo escopo pode ser utilizado, dentro do contexto do
gerenciamento de projetos, de duas maneiras:

 Escopo do Produto – os recursos e as funções que caracterizam um produto, serviço ou

resultado. Em termos mais simples, para cumprir o escopo do produto, o time do projeto
precisa compreender o que se pede para ser desenvolvido ou gerado e precisa caracterizar
corretamente as suas propriedades no intuito de entregar uma versão final, de acordo com o
que é esperado pelo cliente do projeto ou pelo usuário final.

 Escopo do Projeto – o trabalho realizado para entregar um produto, serviço ou resultado

com os recursos e as funções especificados pelo escopo do produto. Já em relação ao escopo
do projeto, depois de o time do projeto conseguir compreender o que precisa ser gerado,
agora é o momento de definir como isso será gerado. É necessário definir as atividades de
planejamento e de gerenciamento que garantam a realização – e não mais a definição – da
entrega.

Exemplo: um projeto fictício de lançar um curso on-line de gerenciamento de projetos.

O escopo do produto seria definir as características do curso, como carga horária, conteúdo e
tipo de ambiente virtual a ser adotado, entre outras características. Já o escopo do projeto
seria definir como conseguir as licenças necessárias para registrar o curso nos órgãos
competentes, contratar mão de obra, alugar servidores de internet, etc. Ainda utilizando o
exemplo do curso on-line, apenas para corroborar alguns ensinamentos da unidade anterior,
algumas funcionalidades possíveis seriam: desenvolver conteúdo, estruturar trilha – do curso –
e definir pré-requisitos.

As causas de falhas em projetos são inúmeras. e você não sabe ao certo o que
deve entregar e quais são os limites do projeto, a probabilidade de atingir os seus
objetivos é muito pequena.

A seguir, vamos examinar as principais causas de falhas em projetos diretamente

relacionadas ao planejamento e ao controle inadequados do escopo, com a
indicação de boas práticas para evitá-las.

 PRESSÃO PARA INICIAR O PROJETO: As pressões para iniciar a execução do

projeto antes de a definição do escopo estar completa são inúmeras.

 LEVANTAMENTO IMPRECISO DE REQUISITOS: Em alguns casos, não são

empenhados esforços para levantar, com clareza e precisão, os requisitos
relevantes durante o planejamento do projeto.
  FALTA DE COMUNICAÇÃO: A falta de comunicação da equipe do projeto com
os clientes ou usuários, e mesmo entre diferentes departamentos da
empresa, costuma causar divergências quanto ao escopo esperado na
conclusão do empreendimento.

 MUDANÇA NA OPINIÃO DO CLIENTE: Sabe-se que é comum o cliente mudar

constantemente de opinião sobre como o produto final deveria ser. Muitas
vezes, o cliente não compreende as dificuldades técnicas de mudança do
escopo, especialmente no caso de empreendimentos grandes e complexos.

 INFLUÊNCIA DE FATORES EXTERNOS: A estabilidade e manutenção do escopo de

um projeto também sofre influência de fatores externos, como mudanças
políticas, econômicas e inovações tecnológicas demandadas pelo mercado.

De acordo com o relatório PM SURVEY.ORG, de 2017, a definição inadequada

e as mudanças constantes do escopo estão entre as quatro principais causas
de falhas em projetos.

O gerente e a equipe do projeto devem implementar políticas de controle eficazes,

que incorporem um exame mais detalhado sobre a necessidade da mudança
proposta, os impactos técnicos e os efeitos sobre cronograma, orçamento e
exposição ao risco.

Uma das práticas disponíveis para obter o controle sobre as mudanças do escopo
recomenda a educação dos stakeholders quanto aos perigos inerentes à
realização de modificações não planejadas no escopo. O envolvimento contínuo e
a comunicação, desde o início do projeto, com todas as partes interessadas e com
o patrocinador, bem como com clientes e usuários, é outra recomendação
importante para reduzir problemas na definição e no gerenciamento do escopo.

ENTREGAS OU “DELIVERABLES”:
 TERMO DE ABERTURA DO PROJETO (TAP):
Antes mesmo de a área de escopo iniciar propriamente os trabalhos, o time do
projeto já arregaçou as mangas e providencia detalhes que serão importantes
para o futuro do trabalho. De acordo com o PMI (2017a), todo projeto inicia
formalmente os seus trabalhos após a aprovação de um Termo de Abertura do
Projeto (TAP).

 Os projetos são iniciados por uma entidade externa ao projeto, tais como um
patrocinador, programa, escritório de gerenciamento de projetos (EGP) ou dirigente do
órgão diretivo do portfólio ou o seu representante autorizado. O responsável pela
iniciação do projeto ou patrocinador do projeto deve estar em um nível apropriado
para captar o financiamento e dedicar recursos para o projeto (PMI, 2017a, p. 113).

 Existe vida antes do projeto. Esforços já foram cometidos no sentido de avaliar

cenários, pesquisar mercados, realizar estudos de viabilidade e o que mais for
necessário para minimizar surpresas após a formal implementação do projeto. Tudo o
que é realizado antes do projeto e que se relacione com o escopo que será gerado
transforma-se em informação para auxiliar no início dos trabalhos do projeto. Na
maioria das vezes, o TAP vem recheado de anexos contendo valiosos documentos pré-
projeto (veja as “entradas” descritas na figura 7).

 Dependendo do grau de importância e de investimento do projeto, é comum, por

exemplo, a realização de pré-projetos ou projetos-base para investigar melhor
possíveis condições futuras. O processo que visa à elaboração de um TAP é veiculado à
 área de conhecimento de integração e encontra-se descrito no processo 4.1 –
Desenvolver o Termo de Abertura do Projeto, constante do grupo de processos de
iniciação, ou seja, antes do planejamento, no Guia PMBOK® (PMI, 2017a).

É de bom tom que o TAP seja aprovado pelo patrocinador do projeto e, mesmo que não exista
um formato ou template específico para confeccioná-lo, deve haver muita atenção no
momento de gerar essa importante etapa do projeto.

Segundo Massari (2016), da mesma maneira que um TAP serve para definir a visão de um
produto e formalizar o início dos trabalhos com foco em um planejamento mais detalhado,
muitas outras técnicas podem ser utilizadas, por exemplo: inception enxuta, tweet charter,
vision box, project model canvas, press release, elevator statement ou exploração 360º.
Depois do advento do TAP, os esforços serão voltados ao Plano de Gerenciamento
do Projeto (PGP), e um dos componentes principais desse documento é o Plano de
Gerenciamento do Escopo (PGE), que será a base para o gerenciamento do escopo
do projeto, definindo todas as regras inerentes ao trabalho do escopo para o time
do projeto. Segundo o PMI (2017a), o gerenciamento do escopo do projeto
encontra-se presente apenas em dois grupos de processos: planejamento, com
quatro processos; e o de monitoramento e controle, com outros dois processos,
conforme pode ser verificado no quadro a seguir.

Quadro 2 – Processos do gerenciamento do escopo (Adaptado de PMI (2017a).

A integração da área de escopo com as demais áreas de conhecimento

preconizadas pelo Guia PMBOK® é essencial, pois a partir do momento em que as
quatro etapas de planejamento do escopo começam a gerar informações para o
time do projeto, as ações passam a girar em função do fiel cumprimento do que
estiver estipulado para ser entregue.

Por sua vez, as informações do processo 5.2 também serão importantes para os
trabalhos do 5.3 e do 5.4, que trabalharão artefatos como a declaração do escopo
do projeto e a linha de base de entregas, também conhecida como Estrutura
Analítica do Projeto (EAP). O curioso é que, depois da conclusão de uma primeira
versão aplicável da EAP, as informações retornam aos pontos de origem, ou seja,
uma linha de base pronta no processo 5.4 retorna informações para o 5.3, para o
5.2 e para o 5.1.

Então, o ciclo se fecha, pois todo o fluxo de ida e de volta foi realizado por meio de
mútuas ações do time do projeto, visando ao planejamento do escopo. Com o
planejamento do escopo do projeto pronto, outras áreas também vão reforçar os
seus respectivos planos complementares no intuito de gerar um único e grande
documento: o PGP.

Quando uma entrega encontra-se pronta para validação, há uma sincronia da área
de escopo com a área de qualidade. Somente após o “ok” do time de qualidade é
que o escopo, ou parte dele, poderá ser validado – processo 5.5. Entretanto,
sempre que houver algum tipo de problema ou desconformidade em relação
àquilo que foi planejado nos processos iniciais – 5.1 a 5.4 –, há a possibilidade de
controlar o escopo – processo 5.6 – acionando o controle integrado de mudanças
do projeto, processo vinculado à área de integração.

O Termo de Abertura do Projeto é um dos documentos a que devemos mais

importância no início das atividades de um projeto. Por meio desse documento,
entre outros artefatos que podem ter sido produzidos até mesmo na fase pré-
projeto, consegue-se informar ao time de planejamento (não só o time do escopo
mas também os times das demais áreas de conhecimento) as principais
referências que precisam ser levadas em consideração para o trabalho de
confecção de um correto plano de gerenciamento do escopo.
 MÓDULO 2 – PLANEJAR O GERENCIAMENTO DO ESCOPO:

A importância é caracterizar o planejamento. São as primeiras ações de como se

define o escopo do projeto, porem, ele não saíra definido totalmente. O que ficará
definido são as normas e regras, principais temas, como vai ser a estrutura
analítica do projeto, etc.

Normalmente, ao iniciarmos um projeto, é comum ficarmos ansiosos para saber

qual será exatamente o trabalho a ser realizado. No entanto, em um
planejamento, além de definirmos o que precisa ser realizado, precisamos
determinar como isso será realizado e controlado. Esse é exatamente o foco do
processo planejar o gerenciamento do escopo.
Você já conheceu o principal resultado desse processo, que são os principais
componentes inclusos no plano de gerenciamento do escopo, e entendeu as
razões que justificam a sua execução. No entanto, é importante ter em mente que
os benefícios de produção de um plano de gerenciamento do escopo devem
superar os seus esforços.

A ponderação entre os benefícios e os esforços associados ao planejamento do

escopo é fundamental para a concepção de um bom plano, com um nível de
detalhamento que seja adequado às especificidades do projeto, ao contexto
organizacional e aos ambientes interno e externo.
“O projeto não falha quando termina; falha no começo.”
 FLUXO DE DADOS E DETALHAMENTO DO
PROCESSO

Já conhecemos o plano de gerenciamento do escopo e o plano do gerenciamento

de requisitos, com ênfase nas principais entradas utilizadas pelo processo de
planejamento do gerenciamento do escopo. Você deve ter observado como os
fatores ambientais e os ativos organizacionais não só influenciam o planejamento
do escopo, mas também são por ele influenciados.

Do mesmo modo, o registro e a disseminação de lições aprendidas e a construção

de guias e templates (modelos) dos documentos do projeto e dos demais planos
de gerenciamento (incluindo os do gerenciamento do escopo) são boas práticas
que você deve conhecer a fim de evitar erros e desperdícios tanto de tempo
quanto de recursos.
A adoção e a aplicação de tais práticas costumam acelerar os benefícios e superar
os esforços de planejamento do projeto.
PROCESSO "PLANEJAR O GERENCIAMENTO DO
ESCOPO": SAÍDAS
CONCLUSÃO
Neste módulo, analisamos o primeiro processo do gerenciamento do escopo: planejar o
gerenciamento do escopo.

Entendemos a importância de realizar o planejamento adequado do escopo para o

projeto e descrevemos as entradas utilizadas na execução desse processo, dando
destaque especial ao Termo de Abertura do Projeto, explicando como se dá o início, a
seleção e a aprovação formal de um projeto nas organizações.

Para finalizar, apresentamos o Plano de Gerenciamento do Escopo, principal resultado

desse processo, e descrevemos os os seus componentes, como o Plano de
Gerenciamento de Requisitos.