INTRODUÇÃO

Em certo momento da minha vida profissional, deparei-me com

um jovem engenheiro recém-formado que estava no primeiro emprego,
na verdade, um estágio. Um dia, depois de muitos esforços em prol de
um detalhe simples que demandou muitas horas de atenção por parte da
equipe do projeto, escutei o rapaz questionar que a vida de um
profissional de gerenciamento de projetos era muito inconstante e sujeita
a muitas variáveis.
No primeiro momento, acreditei tratar-se da expressão do
óbvio; afinal, se alguém havia escondido dele tal detalhe, caberia a
mim demonstrar que isso era uma condição de muitas vidas
profissionais: a instabilidade. Tamanha foi a minha surpresa quando
esse mesmo indivíduo desejou que a vida profissional dele fosse mais
estável. Aquilo martelou muito tempo na minha cabeça. Afinal de
contas, quem possui uma vida estável no trabalho? Sem mencionar
que uma vida estável pode consideravelmente levar à zona de conforto,
ao sedentarismo, à desmotivação ou até mesmo à substituição de
determinados cargos por máquinas.
Se praticamente tudo o que a estabilidade traz é prejudicial,
comecei a demonstrar para aquele estagiário exatamente o contrário, ou
seja, o quão bom é um ambiente instável, pois o que importa é manter
uma postura de busca por uma identidade cultural acerca da
adaptabilidade à mudança e estar sempre disposto a abraçar desafios. O
fato de viver em um ambiente em constante mudança pode ser
extremamente gratificante, basta aprender a lidar com diferentes tipos de
situações. Mais ainda, é possível que tenhamos de agradecer todos os dias
pelo tipo de trabalho realizado, pois do contrário, muito provavelmente,
já não seremos peças necessárias.
O gerenciamento de projetos não é uma descoberta nem mesmo um
modismo. Trata-se de um tema que muito se explora há décadas, cujas
benesses da correta aplicação dos conceitos muitas organizações públicas,
privadas ou do terceiro setor apenas recentemente começaram a perceber.
 Sempre que o assunto é visto de maneira ordenada e integrada, muitas são as possibilidades de
desenvolver melhores produtos e serviços inerentes a um negócio, alinhando padrões internacionais
de gestão com o fortalecimento de uma instituição, seja por demonstrar melhor cuidado com os
processos ou por transparecer, por meio dos valores tangíveis e intangíveis, diferenciais competitivos.
Exatamente por isso, muito se discute sobre como melhorar processos, estipular métricas,
capacitar profissionais e otimizar entregas, entre outros detalhes que poderão trazer retornos
rápidos, ou mesmo de longo prazo, para organizações que adotam tais práticas. O gerenciamento
do escopo é somente a ponta desse iceberg, pois ele e os demais temas pertinentes ao projeto têm o
dom de provocar uma verdadeira revolução na maneira como as organizações veem e são vistas, com
influência imediata nas pessoas, que são a base de toda e qualquer estrutura. De nada serviria o
trabalho do escopo, se não estivesse corretamente alinhado com o da qualidade, por exemplo. São
irmãos separados no nascimento. Um depende, essencialmente, do outro. É por meio do
gerenciamento da qualidade que busca-se agregar valor àquilo que está sendo gerado pelo time do
projeto e melhorar a percepção de satisfação das principais partes interessadas, assim como vincular
o resultado do projeto com os objetivos traçados por diretrizes estratégicas organizacionais.
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
esses resultados, um escopo mal definido possui um enorme potencial para gerar problemas de
comunicação. Em face dessa observação, surge uma questão sobre as respostas dos entrevistados:
não estavam elas mais atentas às consequências dos problemas do que, talvez, às causas deles? Se
essa teoria pudesse ser confirmada, potencialmente teríamos o escopo como gerador de dois dos
principais problemas de falhas em projetos, apenas para nos atermos ao top 3. Curiosamente, a
qualidade só é lembrada após menções de muitos outros tipos de problemas, como disputas de
recursos, estimativas sem fundamento, riscos mal avaliados, atrasos de cronograma, entre outros. É
verdade que nem toda organização possui algum tipo de mentalidade ou até mesmo um setor (quiçá
profissionais específicos) voltados para processos de qualidade. Muitas acreditam que está tudo muito
bem, obrigado e utilizam a máxima de que em time que está ganhando não se mexe. Exatamente por
isso, é muito comum verem-se práticas de qualidade serem realizadas (quando realizadas) por
profissionais que acumulam funções não originais de qualidade.
A resposta para melhorar esses problemas – ou até solucioná-los, de uma vez por todas – está
em uma correta atenção ao gerenciamento do escopo e da qualidade em projetos. Entretanto, esse
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 ou falta de
estrutura/cultura organizacional.
 Este material é um compêndio para que profissionais da área de gerenciamento de projetos
percebam cada vez mais a importância do gerenciamento do escopo e da qualidade em projetos, assim
como as correlações destes com o trabalho dos demais temas que permeiam o gerenciamento de projetos.
Dessa forma, o objetivo geral desta disciplina é apresentar os conceitos de escopo e de
qualidade, tratando algumas peculiaridades, ferramentas, dicas, modelos e práticas, entre tudo o
que mais possa ser útil para a melhor compreensão desses dois importantes tópicos. Além disso,
demonstrar como ambos, escopo e qualidade em projetos, portam-se, oferecendo um grau de
compreensão que produza efeitos imediatos de utilização do assunto estudado em organizações, em
capacitação/motivação de indivíduos e grupos de pessoas, que adotem ou visem a adotar o
gerenciamento profissional de projetos.
Por sua vez, os objetivos específicos são:
 reconhecer os principais termos e as peculiaridades que envolvem o assunto escopo e
qualidade em projetos;
 identificar todas as etapas do escopo e da qualidade em projetos, segundo modernas
práticas internacionais reconhecidas pelo mercado;
 aplicar corretamente os processos do escopo e da qualidade ao longo de um projeto real,
independentemente de porte ou segmento de mercado;
 demonstrar uma visão holística, percebendo a importância dos trabalhos do escopo e da
qualidade em relação às demais temáticas de um projeto e
 elaborar, reconhecer e analisar, com visão crítica, os principais documentos relativos ao
escopo e à qualidade em projetos.

Visto isto, este material está organizado de tal forma que o módulo I, Introdução e conceitos
fundamentais do escopo, apresenta o escopo como um dos assuntos mais nervais em um projeto, pois
possui o dom de influenciar direta e indiretamente todo o trabalho da equipe do projeto.
Exatamente por isso, é necessário conhecer os principais termos e peculiaridades demandados na
condução de um bom trabalho de gerenciamento do escopo em projetos. O módulo se propõe a
demonstrar, em um primeiro momento, como o termo escopo surgiu e amadureceu, passando a ser
utilizado como fator crítico de sucesso em um modelo de gestão estratégica, de preferência
vinculado aos objetivos de negócio de qualquer organização. Apresenta também todos os principais
conceitos necessários à correta compreensão e à assimilação de um bom trabalho de gerenciamento
do escopo em projetos. Na sequência, faz a conexão com os primeiros momentos do projeto, por
meio do Termo de Abertura do Projeto, demonstrando como será o percurso a ser percorrido para
o início dos trabalhos, visando aos esforços de um bom planejamento.
Por sua vez, o módulo II, Introdução e conceitos fundamentais da qualidade, aborda a qualidade
como um tema de suma importância em todos os setores e, para o gerenciamento profissional de
projetos, não poderia ser diferente. O tema relaciona-se diretamente com todas as demais temáticas
de um projeto e possui o poder de provocar potenciais impactos em muitos dos processos de tomada
de decisão ao longo do ciclo de vida do projeto. Em função de melhorarmos a compreensão acerca
do tema, serão apresentados os principais conceitos, iniciando por um breve relato histórico de
como a sociedade moderna descobriu os benefícios da implementação da qualidade em produtos e
serviços. Na sequência, trataremos de técnicas, métodos, ferramentas e outras opções, como rituais
da qualidade, que possam ser rapidamente compreendidos – ou aperfeiçoados, caso o aluno já os
conheça –, e implementados na prática com o mínimo de esforço, representando um benefício
imediato de absorção dos ensinamentos do módulo, sempre com foco num trabalho cada vez
melhor do gerenciamento da qualidade.
Para começar a trabalhar o escopo, o módulo III, Planejamento do escopo: parte I, incorpora
os conceitos primordiais de valor e o que isso representa para o desempenho dos trabalhos da equipe
de um projeto. Em face dessa proposta, é importante que o time do escopo de um projeto domine
esse conhecimento para que construa a documentação necessária que influenciará todo o
planejamento e, consequentemente, todo o trabalho do projeto. As ações do planejamento de um
projeto não se iniciam necessariamente com a definição do escopo, mas, a partir do momento em
que passa a existir essa definição, todo o trabalho da equipe do projeto passa a ter outro significado.
O planejamento do escopo, independentemente da abordagem selecionada para executar o projeto,
é primordial para o encadeamento do restante dos esforços. No módulo, serão identificadas as regras
para se trabalhar com um bom planejamento do escopo assim como dos requisitos de um projeto,
pois buscaremos compreender como funcionam os trabalhos de elicitação (coleta), análise,
organização, documentação e as respectivas importâncias para a saúde de um projeto.
No módulo IV, Planejamento do escopo: parte II, com as regras do escopo já definidas, assim
como as normas para o trabalho com os requisitos do projeto, o planejamento do escopo torna-se
necessário em muitos níveis de atuação, desde os mais estratégicos até os com necessidade de ajustes
mais prementes, com intervalos diários. Com a proposta de dar subsídios à equipe do projeto no
intuito de que não existam dúvidas do que será realizado e de como será realizado para que seja feita
a entrega do produto, serviço ou resultado desejado ao cliente ou usuário final, a documentação do
planejamento será complementada e atualizada com importantes informações sobre o escopo. A
equipe do projeto passa a ter, então, conhecimento explícito e detalhado do escopo do
projeto/produto, representado por uma linha de base do escopo. Faz-se mister definir como as
entregas serão subdivididas em componentes gerenciáveis, os quais, pela sua vez, poderão ser melhor
estimados, mensurados, monitorados e, caso necessitem, controlados.
Todo bom trabalho começa com um planejamento bem feito. Com a qualidade não poderia ser
diferente. No módulo V, Planejamento da qualidade, veremos como as informações provenientes do
planejamento do escopo, mesmo que ainda incompleto, habilitam os primeiros trabalhos de
planejamento da qualidade. É necessário reunir um conjunto de informações que guiam o trabalho da
qualidade ao longo de todo o projeto, com o foco principal na definição de todos os parâmetros para
acompanhar as condições (físicas, técnicas e estratégicas) do produto, serviço ou resultado que estará
sendo gerado pela equipe do projeto, de maneira objetiva, ou seja, passível de verificação e controle. O
planejamento da qualidade é fundamental para explicitar políticas, diretrizes, modelos e objetivos da
qualidade, desenvolver métricas e estabelecer padrões. Planejar a qualidade é uma ação que, dependendo
do tipo de abordagem destinada ao projeto, pode ser realizada em um único momento ou em momentos
pré-estabelecidos. Veremos as melhores opções para cada tipo de abordagem.
Em seguida, o módulo VI, Acompanhamento, validação dos requisitos, aceitação das entregas e
controle do escopo, mostra como, a priori, o objetivo de um bom planejamento do escopo é conseguir
que as entregas sejam todas aceitas no formato originalmente previsto. Esta é a meta máxima de toda
a equipe do escopo: conseguir que todos os requisitos tenham as suas precisões confirmadas e as
entregas possam ser realizadas tranquilamente. Trata-se de um trabalho realizado não somente pelas
equipes do escopo mas também com valiosas contribuições dos times da qualidade. Quando o time
do escopo consegue formalizar uma entrega aceita, isso significa um trabalho a menos para a equipe
do projeto e também sinaliza que a direção para a concretização do resultado esperado é cada vez mais
curta. Obviamente, todo projeto é um carrossel de emoções e sofre a influência de um turbilhão de
variáveis, internas e externas, sem mencionar constantes interferências de algumas partes interessadas.
Exatamente em função disso, é necessário um trabalho atento de gerenciamento de possíveis alterações
na linha de base do escopo. Caso ocorra uma solicitação de mudança, há que se realizar um trabalho
de controle integrado de ações, minimizando problemas e conduzindo o resultado do projeto sempre
alinhado com os objetivos estratégicos organizacionais e as necessidades do negócio.
E, por fim, no módulo VII, Gerenciamento e controle da qualidade, veremos que gerenciar a
qualidade é colocar em prática tudo o que foi discriminado pelo Plano de Gerenciamento da
Qualidade, aumentando a probabilidade de cumprir os objetivos da qualidade, assim como mapear
problemas/defeitos de desenvolvimento ou processos ineficazes, transmitindo o status da qualidade
para as principais partes interessadas, sempre que necessário. Já o trabalho de controle da qualidade
demanda monitorar e documentar os resultados dessa execução, avaliando o desempenho do trabalho
da qualidade como um todo e garantindo que as entregas do projeto sejam plenas, próximas da
perfeição (ou dentro de um limite de tolerância, conforme o planejamento da qualidade) e,
efetivamente, atendam às necessidades/oportunidades que motivaram as razões do projeto.
Para isso, serão descritas todas as etapas para um correto trabalho do gerenciamento do escopo
e da qualidade em um projeto, assim como serão demonstrados modelos de artefatos (incluindo
templates e dicas), técnicas, boas práticas, frameworks e ferramentas, que poderão auxiliar o trabalho
de qualquer profissional na utópica busca pela perfeição, desenvolvendo competências, objetivando
um trabalho de melhoria contínua de processos e a entrega de constante valor percebido por parte
das principais partes interessadas do projeto, notadamente, patrocinadores e clientes/usuários finais.
Por fim, lembre-se de que sempre é possível trabalhar uma gestão decorrente de um ambiente com
muita instabilidade.
Boa leitura!
SUMÁRIO
MÓDULO I – INTRODUÇÃO E CONCEITOS FUNDAMENTAIS DO ESCOPO ...................................... 11

CONCEITO HISTÓRICO .................................................................................................................... 11

ESCOPO E OS CICLOS DE VIDA DE UM PROJETO ......................................................................... 13
CONCEITOS IMPORTANTES: VISÃO DO PRODUTO (OU DO SERVIÇO), FUNCIONALIDADES,
CRITÉRIOS DE ACEITAÇÃO E CRITÉRIOS DE VALIDAÇÃO............................................................. 17
DIFERENÇA ENTRE ESCOPO DO PROJETO E ESCOPO DO PRODUTO ........................................ 22
TERMO DE ABERTURA DO PROJETO E PROCESSOS DE GERENCIAMENTO DO ESCOPO ............. 23
RETROSPECTIVA DO MÓDULO ....................................................................................................... 26

MÓDULO II – INTRODUÇÃO E CONCEITOS FUNDAMENTAIS DA QUALIDADE .............................. 27

CONCEITO HISTÓRICO .................................................................................................................... 27

QUALIDADE, PROCESSOS E A RELAÇÃO COM PRODUTIVIDADE, EFICIÊNCIA E EFICÁCIA ...... 29
DEFEITOS, CUSTO DA NÃO QUALIDADE, DESPERDÍCIOS E A VISÃO DOS 3 MS ....................... 32
CUSTO DA QUALIDADE (CDQ) ........................................................................................................ 38
MELHORIA CONTÍNUA: PDCA, 5 WHYS E RETROSPECTIVAS ....................................................... 42
O FLUXO DO GERENCIAMENTO DA QUALIDADE ......................................................................... 45
RETROSPECTIVA DO MÓDULO ....................................................................................................... 47

MÓDULO III – PLANEJAMENTO DO ESCOPO: PARTE I ...................................................................... 49

VALOR ................................................................................................................................................ 49
REQUISITOS: CONCEITO E CLASSIFICAÇÕES ................................................................................ 52
COLETA DOS REQUISITOS ............................................................................................................... 54
ANÁLISE, ORGANIZAÇÃO E CLASSIFICAÇÃO DOS REQUISITOS .................................................. 57
DOCUMENTAÇÃO DOS REQUISITOS ............................................................................................. 60
RETROSPECTIVA DO MÓDULO ....................................................................................................... 64

MÓDULO IV – PLANEJAMENTO DO ESCOPO: PARTE II ..................................................................... 65

PLANEJAMENTO DO ESCOPO EM VÁRIOS NÍVEIS ........................................................................ 65

LINHA DE BASE DO ESCOPO........................................................................................................... 68
ESTRUTURA ANALÍTICA DO PROJETO – EAP ................................................................................. 71
DICIONÁRIO DA EAP ........................................................................................................................ 77
SCOPE CREEP ...................................................................................................................................... 79
RETROSPECTIVA DO MÓDULO ....................................................................................................... 81
MÓDULO V – PLANEJAMENTO DA QUALIDADE ................................................................................ 83

OS TRÊS KS: KAIZEN, KAIKAKU E KAKUSHIN ..................................................................................... 84

PLANEJAMENTO DA QUALIDADE ................................................................................................... 90
DOCUMENTOS VINCULADOS AO PLANEJAMENTO DA QUALIDADE ......................................... 94
RETROSPECTIVA DO MÓDULO ....................................................................................................... 97

MÓDULO VI – ACOMPANHAMENTO, VALIDAÇÃO DOS REQUISITOS, ACEITAÇÃO DAS ENTREGAS

E CONTROLE DO ESCOPO ................................................................................................................... 99

ACOMPANHAMENTO DO ESCOPO E VALIDAÇÃO DOS REQUISITOS ........................................ 99

ACEITAÇÃO DAS ENTREGAS ......................................................................................................... 104
CONTROLE DO ESCOPO ............................................................................................................... 105
RETROSPECTIVA DO MÓDULO .................................................................................................... 107

MÓDULO VII – GERENCIAMENTO E CONTROLE DA QUALIDADE .................................................. 109

GERENCIAMENTO DA QUALIDADE ............................................................................................. 110

Processos integrados e de melhoria contínua ................................................................. 110
Testes em todos os níveis .................................................................................................... 113
Estudos/Análises de causa e efeito (ou causa-raiz).......................................................... 113
Inspeções ............................................................................................................................... 116
Cultura customer centric ....................................................................................................... 118
RELATÓRIO DE EXECUÇÃO DA QUALIDADE .............................................................................. 121
CONTROLE DA QUALIDADE E RELATÓRIO DO DESEMPENHO DO TRABALHO .................... 123
RETROSPECTIVA DO MÓDULO .................................................................................................... 128

BIBLIOGRAFIA .................................................................................................................................... 130

PROFESSOR-AUTOR ........................................................................................................................... 136

MÓDULO I – INTRODUÇÃO E CONCEITOS
FUNDAMENTAIS DO ESCOPO

Neste módulo, são apresentados os principais conceitos para a compreensão do trabalho de

gerenciamento do escopo de um projeto. É traçado um cenário histórico para determinar como a
fixação na busca pela definição de objetivos demonstra-se algo importante para as organizações e os
indivíduos, notadamente os que desempenham funções relacionadas ao gerenciamento de projetos.
Na sequência, são demonstradas algumas visões acerca de abordagens de trabalho com o escopo, as
quais podem servir a diferentes tipos e tamanhos de projetos. Dentre elas, são exibidas a visão do
Project Management Institute (PMI) sobre os diferentes tipos de ciclos de vida e como a percepção
do triângulo das restrições se adapta de acordo com a utilização de diferentes abordagens. Além
disso, os principais conceitos e respectivas importâncias para a compreensão do gerenciamento do
escopo são apresentados, tais como: visão do produto; funcionalidade; diferença entre critério de
aceitação e critério de validação; e, a diferença entre escopo do produto e escopo do projeto. Por
fim, são ilustradas as principais etapas envolvidas no gerenciamento do escopo e a sua conexão com
o momento do nascimento de um projeto, assim como as possíveis direções para a sequência natural
dos trabalhos que visam a um correto gerenciamento do escopo de um projeto.

Conceito histórico
Gerenciar projetos é uma arte, muitas vezes silenciosa, que existe há décadas. Desde que os
indivíduos começaram a perceber a importância de um método para o melhor encadeamento das
ações de trabalho nas suas respectivas organizações, mais se pôde fazer em função dessa arte.
Portanto, quando Peter Drucker, na década de 1950, disse “Lembre-me de um livro sobre a
anatomia humana que discute apenas uma junta do corpo – o cotovelo, por exemplo – sem
mencionar o braço e deixar de fora o esqueleto e a musculatura”. O hoje conhecido como o Pai da
Administração Moderna demonstrava que nada se faz sem uma visão sistêmica de conjunto, de
preferência, visando sempre a um mesmo objetivo.
Com o mundo dos negócios em ebulição, após um momento histórico vivido pelo período
de duas grandes guerras mundiais, a transformação se inicia exatamente por meio de um
questionamento 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).
A 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; estipulam-se
objetivos e são traçadas formas de monitoramento; responsabilidades são delegadas; e,
constantemente, comparam-se os resultados em relação ao planejamento que havia sido previamente
estabelecido, no sentido de gerar um senso de aferição de resultados. Também há necessidade de
delimitar objetivos de curto (operacionais), médio (táticos) e longo (estratégicos) prazos.
Não à toa, aproveitando o êxito da definição de APO, o conceito de gerenciamento de
projetos nasceu nos Estados Unidos ao final dos anos 1950, quando inicialmente era aplicado
apenas a análises de sistemas de informação e implantação de empreendimentos físicos, este último
limitando-se aos componentes de engenharia. Os primeiros institutos em gerenciamento de
projetos datam da década de 1960, e muitos deles foram lançar o que seria o início dos seus guias
de boas práticas apenas nos anos 1980. Mesmo período em que George Doran (1981), aprimorando
os trabalhos de Edwin Locke (1968), reconheceu que muitas organizações tentavam estipular
metas/objetivos, mas muitas vezes estes eram estabelecidos de maneiras difusas.
Objetivos não deveriam ser tratados como inarticulados – aqui, percebe-se uma pitada do
conceito inicial de Drucker – em vez disso, deveriam ser tratados como mensuráveis, no intuito de
alavancar o sucesso da organização. Então, uma 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 portuguê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 reforçar o
modelo APO e solidificar o conceito do estabelecimento de metas/objetivos em muitas organizações,
suportado por meio de uma técnica simples, e que ainda possui uma aplicabilidade bastante atual.
Essa jornada histórica da busca pelo entendimento do que seria o objetivo de um projeto,
idealizado por muitas décadas de erros e acertos, foi muito importante para que indivíduos pudessem
reconhecer que o foco de um projeto nunca poderá ser negligenciado. Quanto mais se aprende e se
compreende o objetivo a ser alcançado, maior é a chance de se conquistar o sucesso em uma empreitada.
Junto a tudo isso, faz-se mister também destacar a evolução do movimento lean (gestão
enxuta, em português), que vem a ser uma filosofia/metodologia centrada no cliente e utilizada para
a melhoria contínua de qualquer processo por meio da eliminação de desperdícios em tudo o que

12
se faz. Os dois principais pilares do lean são o melhoramento incremental contínuo e o respeito
pelas pessoas. Os princípios básicos trabalham com foco na entrega efetiva de valor ao cliente;
respeito e engajamento das pessoas; melhora no fluxo de valor por meio da eliminação de todos os
tipos de desperdício; manutenção do fluxo de trabalho; e, a busca da perfeição.
Para que uma organização consiga atender a esses princípios, a transformação cultural é
fundamental. Os líderes lean precisam influenciar diariamente os comportamentos dos indivíduos
de uma organização para que a proliferação da adoção do mindset (modelo mental) seja eficaz.
Hoje em dia, muito ainda se aprende com as definições dos objetivos de um projeto, e todas
essas abordagens históricas podem auxiliar, em muito, diversos times de projetos. 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. Continuaremos exatamente nesse caminho para nos aprofundarmos em nossos estudos.

Escopo e os ciclos de vida de um projeto

De acordo com o PMI (2017b), existem quatro tipos de ciclos de vida 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, de tempos em tempos,
algum tipo de retorno por parte dos principais stakeholders engajados no projeto. Os
feedbacks são recebidos pelo time do projeto sobre trabalhos ainda não finalizados, no
intuito de que se melhore o produto, o serviço ou a condição a ser gerada e de que se
consiga adaptá-los antes da 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 capacidade plena;
 ciclo de vida ágil – junção das abordagens iterativa e incremental em um único tipo de
ciclo de vida. Ao mesmo tempo 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 que se aprenda com a versão disponibilizada, para que ela seja
analisada e melhorada.

13
 Figura 1 – Continuidade dos ciclos de vida

Fonte: adaptado de PMI (2017b).

Nenhum ciclo de vida será perfeito para todos os tipos de projeto. Contudo, cada time deve
encontrar um ponto de continuidade para prover equilíbrio nas ações demandadas ao trabalho do
projeto, dependendo do contexto.
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, amenizando incertezas ou erros naturais
decorrentes de um planejamento incompleto ou incorreto, por exemplo. Já no ciclo de vida
incremental, o foco encontra-se nas entregas potencialmente escalonáveis, com o cliente ou o usuário
final tendo a possibilidade de aproveitamento imediato do produto, serviço ou condição, entregue
em uma versão inacabada. Testes e ajustes são praticamente imediatos. 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, como transparência de processos, confiança
e engajamento entre time do projeto e cliente, ou usuário final, adotando o foco de priorização das
funcionalidades (veja o significado desse conceito no próximo capítulo) mais importantes, as quais
geram mais valor às principais partes envolvidas.

14
 O grande argumento para a utilização desse tipo de ciclo de vida reside na questão estratégica,
pois a visualização do return on investment (ROI) (retorno sobre o investimento, em português) será
mais cedo do que em outros ciclos de vida, facilitando processos 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 do desenvolvimento de um produto, serviço ou
condição, 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 da criação do que é hoje conhecido como 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 reside 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 mas com grau de adaptabilidade
satisfatório para continuamente reconhecer onde e quando entregar valor, que precisa ser
percebido pelo cliente ou usuário final. Esse é 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.
Digamos, por exemplo, que um determinado cliente tenha solicitado a criação de um novo
tipo de caneta esferográfica. Como principais solicitações, determinou as características quanto ao
peso, ao tipo de material, às medidas, à cor etc. Porém, quando solicitou o produto, no primeiro
momento, ele também possuía o desejo de que a caneta tivesse uma luz fraca intermitente que seria
emitida no momento em que ela estivesse em utilização.
Ora, não podemos esquecer que a função primária de negócio detectada no desenvolvimento
desse produto (caneta) seria escrever em superfícies de papel e, que a função secundária, ou com
menor proposta de entrega de valor, seria a existência de uma espécie de luz intermitente.
A partir do momento em que as entregas constantes começam a ocorrer, e a caneta, mesmo
ainda não totalmente pronta, começa a receber as principais características que a habilitam a
desempenhar os objetivos (funções de negócio), não é difícil um cliente abdicar de determinadas
condições por já verificar que a principal funcionalidade desejada para o produto está performando
conforme o desejado. Portanto, é plenamente possível que, em determinado momento do projeto,
esse cliente desista da ideia da luz intermitente para economizar no prazo e, quiçá, nos custos do
projeto, pois o valor do produto entregue já foi percebido, sem a necessidade de complementação
futura. O escopo, então, não é tratado como fixo mas como variável ou estimado.
A próxima figura demonstra que, com a utilização de parâmetros de fixação de escopo
(triângulo da esquerda), 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. É comum, em determinados segmentos, escutar que o

15
ideal para um projeto é entregar apenas o que 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 (triângulo da direita),
o foco então passa a ser outro, e isso permite que, dessa vez, o escopo flutue, deixando as restrições
para as áreas de custos e de cronograma.

Figura 2 – Triângulo invertido das restrições

Fonte: adaptado de SERPA (2016).

É possível afirmar que 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 cliente ou usuário final, a tendência é que as
principais partes interessadas fiquem satisfeitas. Já em uma proposta de 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, e o que tiver
sido desenvolvido durante um timebox de dois meses será então o resultado final do projeto.
É 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 demonstra-
se voltado para a proposta de entrega de valor, comumente, escuta-se o termo escopo aberto.
Independentemente da maneira como se denominam as diferentes abordagens em cada
organização, o importante é sempre conseguir identificar como é tratado o assunto escopo dentro da
estratégia de condução de cada projeto.
Como pudemos perceber, ambas as possibilidades são boas e têm o potencial de trazer os
resultados esperados, sendo que a opção por uma das duas será em função da estratégia de condução
do projeto e da correta avaliação em relação ao ciclo de vida mais recomendado a ser adotado –
preditivo, iterativo, incremental, ágil ou híbrido –, de preferência alinhada com as estratégias
organizacionais do ambiente no qual o projeto está sendo gerado.

16
 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 execução dos processos inerentes
à conduçã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 possua a força necessária para a
produção do desempenho esperado.

Conceitos importantes: visão do produto (ou do serviço),

funcionalidades, critérios de aceitação e critérios de
validação
A grande beleza do gerenciamento profissional de projetos é não se prender a modelos
específicos e permitir que organizações e equipes fiquem sempre à vontade para adaptarem o que
for necessário para as próprias necessidades (ou necessidades do projeto em si),
independentemente de porte ou de tipo. Atualmente, muito do que é tratado como métodos ou
frameworks aplicáveis em diversos segmentos de mercado, como indústria, construção civil, saúde,
grandes eventos, entre muitos outros, foi concebido nos trabalhos de engenharia de software.
Afinal de contas, comumente, esse segmento lida com projetos de altíssimo grau de complexidade,
processos pesados, apoiados pela integração de muitas ferramentas e técnicas específicas. É
também verdade que, nem sempre, outros setores tiveram a necessidade de administrar os
trabalhos por meio de um gerenciamento profissional de projetos (raras exceções, apenas para
citar um exemplo do passado, alguns projetos militares). Com a natural popularização do
gerenciamento de projetos, muito do que se vê hoje é derivado desses primeiros esforços da área
de tecnologia da informação. No entanto, as versões adaptadas de métodos e frameworks estão,
muitas delas, plenamente alinhadas aos novos segmentos, desvinculando-se daquela linguagem
técnica de software que dominou e caracterizou o mercado durante muitos anos.
A questão atual, no entanto, é apenas uma: um bom trabalho do gerenciamento do escopo
inicia com um trabalho de qualidade no que tange à definição da visão do produto. Não há
necessidade de se compreender perfeitamente o escopo do produto no início do projeto, mas aquilo
que ele pretende ser (ou, de preferência, resolver), sendo que as técnicas para a geração da visão do
produto permitem compreender melhor a razão de existir da necessidade ou da oportunidade que
gerou a ideia do projeto em si.
Cruz (2015, p. 68) propõe uma pergunta inicial de grande relevância para que a definição da
visão do produto não se perca ao longo dos trabalhos da equipe do projeto: “Como podemos
transformar a visão do produto em um produto real da melhor maneira possível?”. Aliadas a tal desafio,
muitas técnicas associadas a métodos de design thinking, por exemplo, podem auxiliar o

17
desenvolvimento da visão do produto. São cada vez mais frequentes, equipes debruçando-se em
trabalhos de criação de personas, jornadas de usuário, mapas de empatia, técnicas de pitch, épicos e
histórias de usuário (epics e user stories), storyboard, prototipagem e análise SWOT (para melhor
compreender a estratégia do produto), dentre muitas infinidades possíveis. A intenção não é destrinchar
todas elas, mas demonstrar a essência do que seria um correto trabalho de definição de visão do produto.
Segundo o Chaos Report (STANDISH GROUP, 2018, on-line), relatório que realiza um
trabalho de pesquisa consistente com o foco em taxas de sucesso/falha em projetos, define-se que
uma visão do produto simples auxilia na entrega de um escopo, pela sua vez, também simples. Uma
pergunta comumente realizada é “[...] com que frequência você [ usuário ] realmente utiliza [ um
determinado recurso ] de [ um determinado produto ]?”. O resultado é simplesmente assustador,
pois 50% dos entrevistados dizem quase nunca, 30% dizem pouco frequente e apenas 20%
frequentemente. Ou seja, muito se gasta em termos de tempo e de esforços para a realização de
determinados detalhes que dificilmente serão notados, quiçá utilizados, em diversos produtos. Na
prática, tais informações poderiam ser utilizadas para evitar custos e melhorar a produtividade da
equipe do projeto, pois quanto maiores forem os objetivos atrelados ao produto, maior será o grau
de complexidade da sua realização, com possibilidade alta de incorrerem variáveis não antevistas,
aumentando significativamente o número de potenciais riscos.
Para isso, vamos conhecer técnicas simples de definição de uma visão de produto (ou de
serviço) que poderão ser adaptadas a qualquer projeto, como a técnica utilizada pelo modelo lean,
desenvolvida por Moore (1999).

Figura 3 – Visão de produto lean

Para [ cliente / usuário final ]

que [ problema que precisa ser resolvido ].

O / A [ nome do produto/serviço ]

é [ tipo ou categoria de produto/serviço ]

que [ benefício-chave/razão para ser criado ]

diferente de/da [ situação atual ],

pois nosso produto/serviço terá [ diferenças-chaves ].

Fonte: adaptado de MOORE (1999).

Um exemplo prático é o que aconteceu em uma empresa do setor de energia, que, por meio do
recém-criado departamento de inovação, realizou uma pesquisa anônima com uma parcela
significativa de funcionários e pode constatar que as chefias médias da organização tinham por hábito,

18
por diferentes motivos (insegurança, cultura organizacional, falta de incentivo etc.), vetar
sumariamente iniciativas oriundas de ideias de funcionários. Portanto, surgiu o conceito de uma caixa
de sugestões, carinhosamente apelidada de caixa de ideias, anônima, a qual viria a ser posicionada em
locais de passagem, considerados como estratégicos. A visão do produto ficou então assim:

Figura 4 – Visão de produto do projeto Caixa de Ideias

Para [ qualquer colaborador da empresa XPTO ]

Que [ não consegue se fazer ouvir por sua chefia ].

A [ caixa de ideias ]

é [ um depositário para sugestões anônimas ]

que [ serão avaliadas pelos integrantes da área de inovação ]

diferente da [ barreira criada por chefes muito ocupados ],

pois nosso produto/serviço terá [ a possibilidade de implementação de boas ideias que

servirão para uma melhor qualidade de trabalho a todos, ou ao menos para uma grande
parcela de nossos colaboradores ].

Fonte: elaborada pelo autor.

A caixa de ideias foi o primeiro projeto da nova área de inovação da empresa. Um setor que
começou com uma pessoa (a famosa EUquipe) e, até a última vez que se teve conhecimento, já
contava com um grupo de sete pessoas. O projeto da caixa de ideias foi um verdadeiro sucesso,
apesar de ter sido algo que, inicialmente, gerou uma grande desconfiança. Isso era algo esperado,
haja vista o tipo de cultura organizacional existente, a qual precisava sofrer algum tipo de
provocação. A partir do momento em que as primeiras ideias começaram a surgir e a área de
inovação começou a dar retorno sobre as iniciativas, o burburinho cresceu, propiciando muitas
novas ideias. O curioso é que, na maioria das vezes, as sugestões requeriam implementações simples
(projetos de reciclagem, dressing code para o período de verão, banheiros para visitantes com música
ambiente etc.) e com alto impacto; em outras, requeriam apenas alguns ajustes de situações já
existentes, como a extensão do horário de funcionamento da cantina. Ou seja, a caixa de ideias foi
somente o projeto precursor de muitas outras boas ideias que auxiliaram a disseminar uma melhor
qualidade do ambiente de trabalho, muitas gerando efeitos imediatos, com baixo custo (ou quase
nenhum) de implementação e ainda promovendo mudanças positivas na cultura organizacional.
Outra técnica que auxilia a caracterização de uma boa visão do produto, a qual permite um
melhor grau de compreensão de futuras condições que o produto, o serviço ou o resultado a ser
gerado precisará ter para que a solução possa ser implementada, está em uma das fases de

19
desenvolvimento da visão do produto, demonstrada pela metodologia lean inception (CAROLLI,
2015), sendo denominada É / NÃO É / FAZ / NÃO FAZ. De maneira colaborativa, de preferência
após a equipe do projeto já possuir algum grau de compreensão acerca do que precisa ser realizado
pelo projeto (aqui cabe um aparte, pois as duas técnicas – de Moore e de Carolli – trabalham muito
bem quando complementadas, em que esforços somados auxiliam em uma melhor percepção do
produto ou serviço), utiliza-se um quadro branco ou folha de papel para que a equipe possa
responder às seguintes perguntas:

Figura 5 – Técnica É / NÃO É / FAZ / NÃO FAZ

O que o produto/serviço É?

O que o produto/serviço NÃO É?

O que o produto/serviço FAZ?

O que o produto/serviço NÃO FAZ?

Fonte: adaptado de CAROLLI (2015).

Em termos práticos, vamos utilizar o mesmo exemplo do projeto caixa de ideias, para que
sejam preenchidas as informações apresentadas por essa nova técnica.
Poderíamos dizer que a caixa de ideias é um artefato de madeira, fechada por meio de um
cadeado, que pode ser pendurada por meio de ganchos em uma parede, com pequenas dimensões
suficientes para comportar uma quantidade significativa de sugestões/ideias, semelhante a uma
urna, na qual haverá um orifício para serem depositadas as sugestões/ideias, de preferência com uma
caneta (ou algo do gênero) e pedaços de papel disponíveis em conjunto, para imediata utilização.
Pode não ser o melhor formato possível para a implementação do produto em si, mas o que importa
nessa técnica é permitir que outras pessoas compartilhem a visão de produto (aquilo que o produto
precisa parecer, mesmo que seja apenas a sua primeira versão), para que haja um consenso naquilo
que precisa ser realizado no sentido de o produto ganhar vida. Por sua vez, a caixa de ideias não é
um depositório para reclamações, não é um depositório para lixo, não é uma brincadeira e não é
uma atitude para constranger pessoas, pois trata-se de um movimento voluntário. A partir dessas
novas definições que representam o seu não escopo, a caixa de ideias pode ser melhor compreendida.
Ela precisará demonstrar, pela forma ou por meio de alguma(s) ferramenta(s) de
comunicação/conscientização, o verdadeiro propósito, assim como os limites de utilização, evitando
assim interpretações equivocadas sobre o conceito do produto. Ao avaliar seus objetivos, define-se
que a caixa de ideias faz o recolhimento de sugestões/ideias de todos os colaboradores que desejarem
compartilhar sugestões/ideias e que, por qualquer razão, sentiam-se constrangidos para fazê-lo.
Além disso, o artefato permite que tais sugestões/ideias possam ser apresentadas de uma maneira
simples, anônima e sem necessidade de justificativas grandiosas, facilitando a perpetuação de

20
percepções de melhoria que, potencialmente, poderão ser realizadas em qualquer ambiente da
empresa. A documentação das ideias recebidas ou as futuras análises e a divulgação (transparência)
de resultados seriam detalhes da operação por trás da ideia do produto, cujo detalhamento não vem
ao caso neste momento. No entanto, por já ter participado da implementação de dezenas de
produtos/serviços por meio desse tipo de técnica de visão do produto, sugerimos que, durante o
momento colaborativo de preenchimento dessas respostas, não se deva excluir nada e os registros
de quaisquer insights, mesmo que não convenientes no momento, sejam realizados. Uma boa opção
é registrar os trabalhos, por meio de uma gravação de áudio, por exemplo. São detalhes que poderão
ser úteis no futuro. O que a caixa de ideias não faz poderia ser algo, como: não se responsabiliza
pela implementação da ideia apresentada (há necessidade de uma avaliação posterior). Pronto!
Mesmo tendo uma boa visualização do que poderia ter sido a visão do produto com a utilização do
modelo lean, o trabalho da equipe foi complementado por meio dessa segunda técnica, e as chances
de sucesso da idealização do futuro produto aumentaram consideravelmente, pois o grau de
percepção acerca do que ele deverá ser também foi, consideravelmente, aumentado.
Por fim, resta dizer que, por se tratar de um trabalho colaborativo, é importante que seja
realizado em condições prazerosas, para que a equipe do projeto possa fazer fluir a criatividade e o
pensamento crítico, não se privando de demonstrar qualquer viés que possa ser transformado em
um insight ou, ao mesmo tempo, ser registrado como um potencial item/problema/impedimento a
ser observado e, posteriormente, avaliado. Quanto mais tempo a equipe dispuser para descrever tais
detalhes, mais rica será a visão do produto.
Outro termo muito comum no momento de conduzir o trabalho do escopo ao longo de um
projeto é funcionalidade. Uma funcionalidade é algo passível de execução, ou seja, algo definido
como um comportamento ou até mesmo uma ação, delimitado por um período (caixa) de tempo
– timebox –, presumindo que exista um momento de início para a sua execução e um momento de
fim, claramente definidos.
As funcionalidades são definidas junto com a definição do escopo do produto e do escopo do
projeto, assunto que será estudado logo a seguir, na próxima unidade. É desejável que sejam criadas
por meio da junção de um verbo e de um substantivo.
É um trabalho que exige do time do projeto um grau de atenção redobrado, pois um início
mal estruturado poderá ser desastroso quando o projeto evoluir e as implicações de um trabalho do
escopo desestruturado começarem a influenciar os trabalhos das demais temáticas de um projeto,
por exemplo, cronograma, recursos, qualidade etc.
Naturalmente, como trabalharemos os assuntos do escopo e da qualidade ao longo da
disciplina, cabe aqui um aparte para diferenciar dois conceitos que são comumente confundidos e
que são também considerados de extrema importância para o sucesso do projeto: critério de
validação e critério de aceitação. O primeiro trata de garantir que a condição ou a característica
desejada seja efetivamente cumprida (um trabalho realizado pelo time de qualidade do projeto); o
segundo trata de realizar a formalização da entrega do produto – ou parte do produto, do serviço

21
ou da condição –, também conhecido como handover, que, pela sua vez, é função do time de escopo
do projeto. Aqui pode-se perceber a forte dependência em relação aos trabalhos do escopo e da
qualidade, pois, enquanto um atesta a veracidade ou a precisão das funcionalidades, o outro recebe
essas informações e promove, essencialmente, a entrega dessas funcionalidades.
Em termos práticos, e de uma maneira bem simples, digamos que um determinado projeto
seja construir uma ponte com 5 metros de comprimento, 2 metros de altura, além de dois pilares
de sustentação. Como validar que a ponte, após pronta, possua realmente 5 metros de
comprimento? Existem diversas maneiras de se fazer isso, desde processos simples e com baixíssimo
grau de exatidão, como técnicas de observação, ou processos mais complexos e com elevados graus
de exatidão, como medições com instrumentos aferidores e de precisão. A questão não é fazer juízo
de valor se o critério de validação é bom ou ruim, mas que exista um ou mais critérios, conforme
as múltiplas variáveis vinculadas ao projeto permitirem.
Logicamente, quanto mais preciso(s) e objetivo(s) for(em) o(s) critério(s), maiores as chances
de garantir que o produto foi desenvolvido conforme as orientações desejadas. Além disso, como
ter certeza de que os 5 metros de comprimento foram aceitos pelo cliente do projeto e que o time
do projeto não precisa – em tese – preocupar-se mais com esse detalhe? É necessário, por exemplo,
que haja uma lista de verificação de características do produto e o cliente chancele de tempos em
tempos os avanços das entregas.
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), em que ocorre a entrega final
do produto, do serviço ou da condição gerados.

Diferença entre escopo do projeto e escopo do produto

Segundo o PMI (2017a), o termo escopo pode ser utilizado, no 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 (condição);
 escopo do projeto – o trabalho realizado para entregar um produto, serviço ou resultado
(condição) com os recursos e as funções especificados pelo escopo do produto.

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
propriedades, no intuito de entregar uma versão final, de acordo com o que é esperado pelo cliente
do projeto ou pelo usuário final, conforme definido (ou a ser definido) no momento da visão do

22
produto. Já em relação ao escopo do projeto, depois de o time 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.
Na prática, como perceber melhor essa diferença? Vamos utilizar como exemplo um projeto
fictício de lançamento de 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 plataforma virtual a
ser adotado, dentre outras características. Já o escopo do projeto seria definir como conseguir as
licenças necessárias para registrar o curso em órgãos competentes, contratar mão de obra, alugar
servidores de internet etc. Apenas para corroborar alguns ensinamentos da unidade anterior,
algumas funcionalidades possíveis seriam: desenvolver conteúdo, estruturar trilha do curso e definir
pré-requisitos para participação.
Em determinados momentos, pode haver uma confusão natural entre os dois termos. Isso
ocorre quando o escopo do projeto é visto como incluindo o escopo do produto na sua definição
de trabalho. Não é uma prática proibida, mas é sempre importante o time do projeto compreender
como lidar com determinadas caracterizações do escopo, no intuito de não ocorrerem problemas
de interpretação desses conceitos durante o andamento do projeto.

Termo de abertura do projeto e processos de gerenciamento

do escopo
O gerenciamento do escopo possui influência direta no sucesso – assim como no fracasso –
de um projeto. Exatamente por isso, costuma ser um dos temas mais explorados na metodologia
proposta pelo PMI. Um escopo precisa ser extremamente bem definido e, mais ainda, bem
controlado. Todo o restante do projeto depende disso. O gerenciamento do escopo possui o dom
de potencialmente influenciar todos os demais temas pertinentes a um projeto, seja uma questão
relacionada a budget ou a trabalhos que visam à manutenção e à melhoria da qualidade de processos
organizacionais internos, por exemplo.
Sendo assim, um correto gerenciamento do escopo é visto como fator crítico de sucesso e visa
a garantir que o time do projeto realize todo o trabalho requerido no intuito de assegurar a fiel
entrega de todos os objetivos do projeto, da melhor maneira possível, de preferência com
reconhecimento de valor junto às principais partes envolvidas.
No entanto, 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 trabalhos após a
aprovação de um Termo de Abertura do Projeto (TAP).

23
 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).

Sugerido como primeiro documento do projeto, o TAP (ou qualquer outro documento que
possa substituir essa função, por exemplo, um sumário executivo) representa o esforço inicial do
time do projeto – o qual, provavelmente, ainda não estará plenamente definido – para depositar
todas as informações possíveis, e passíveis de serem transmitidas, a respeito do projeto, de maneira
sumarizada, por meio de um documento de autorização formal. Além disso, o documento deve
chancelar a autoridade do gerente de projeto selecionado para liderar as ações, definindo o seu grau
de autonomia, para que ele tenha toda a autoridade necessária para aplicar os recursos
organizacionais em prol do trabalho do projeto. É altamente recomendado que o TAP também
demonstre o grau de compromisso da organização com o trabalho que será desempenhado.
Além disso, 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 uma implementação formal de um 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. Na maioria das vezes, o TAP vem recheado de anexos contendo valiosos
documentos pré-projeto, como pesquisas de mercado ou estudos de viabilidade técnica. Dependendo
do grau de importância e de investimento do projeto, entre outros fatores, é comum por exemplo, a
realização de pré-projetos ou projetos-base para investigar melhor possíveis condições futuras.
É 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.
O PMI (2017a, p. 117) preconiza que “[...] ele documenta informações de alto nível sobre o
projeto e sobre o produto, serviço ou resultado que o projeto deve satisfazer” e, exatamente por
causa disso, possui a capacidade de garantir um grau ótimo de entendimento comum aos principais
stakeholders, descrevendo quais são as entregas e os marcos mais importantes, além de clarificar a
visão do produto – que será melhorada quando o time de escopo do projeto der sequência aos
trabalhos –, do serviço ou da condição que será gerada; sendo uma importante fonte de informações
para um futuro trabalho de especificação do escopo.
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º.

24
 Já em relação ao conteúdo de um TAP, o quadro 1 descreve o que é desejado e, se for o caso,
não somente isso, mas quaisquer outros detalhes que forem julgados pertinentes pelo responsável
na elaboração desse artefato.

Quadro 1 – Informações de alto nível requeridas em um TAP

 finalidade do projeto;
 objetivos mensuráveis do projeto e critérios de sucesso relacionados;
 requisitos de alto nível;
 descrição de alto nível do projeto, os seus limites e entregas-chave;
 risco geral do projeto;
 resumo do cronograma de marcos;
 recursos financeiros pré-aprovados;
 lista das partes interessadas chave;
 requisitos para aprovação do projeto (ou seja, o que constitui o sucesso do projeto, quem
decide se o projeto é bem-sucedido e quem autoriza o encerramento do projeto);
 critérios de término do projeto (ou seja, quais são as condições que devem ser cumpridas
para encerrar ou cancelar o projeto ou a fase);
 gerente do projeto designado, responsabilidade e nível de autoridade e
 nome e autoridade do patrocinador ou outra(s) pessoa(s) que autoriza(m) o termo de
abertura do projeto.

Fonte: PMI (2017a).

Depois do advento do TAP, os esforços serão voltados a um planejamento completo do projeto,

permitindo a sua posterior execução, e é seguro afirmar que uma das etapas iniciais desse planejamento
trata, exatamente, do planejamento do escopo, 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.
A integração do escopo com os demais temas, provenientes de um bom trabalho de
gerenciamento de projetos, é essencial, pois, a partir do momento em que as 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. Cumprem-se então todas as
atividades necessárias para estruturar, definir e conscientizar as principais partes interessadas a
respeito do trabalho necessário à concretização do escopo do projeto e, paulatinamente, os demais
processos serão realizados. Mesmo que não haja uma versão final do planejamento do escopo, essas
informações já geram energia suficiente para que os requisitos possam começar a ser coletados,
documentados, analisados e priorizados. É possível que haja a necessidade de a equipe do projeto
confeccionar alguns 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).

25
 Uma visão mais detalhada a respeito do planejamento do escopo, de como se dá a
especificação de um escopo, da execução dos trabalhos e de maneiras eficazes de monitoramento e
controle serão fornecidas nas próximas unidades.

Retrospectiva do módulo
O módulo I iniciou a sua trajetória trazendo a evolução histórica do escopo. Desde as
primeiras abordagens vinculadas a Peter Drucker e o conceito de Administração por Objetivos
(APO), passando pela visão lean e a necessidade de evolução para uma melhor definição e
mensuração de objetivos, até chegarmos à atualidade e à massiva importância destinada a esse
conceito por meio das principais associações de gerenciamento de projetos do mundo.
Foram demonstrados diferentes tipos de abordagens responsáveis por definir como o escopo
será trabalhado ao longo de um projeto. Pudemos visualizar que o tratamento destinado ao escopo
precisa ser determinado no momento de avaliar o tipo de ciclo de vida do projeto. As opções variam
entre ciclos preditivos, com maior previsibilidade e segurança para trabalhar um escopo fechado
com foco em uma documentação de planejamento restrita em muitas situações, até ciclos ágeis, em
que a palavra de ordem é mudança, e o time precisa estar preparado para adaptar-se às múltiplas
variáveis de um projeto, com um escopo aberto e flexível, voltado para a satisfação das principais
partes interessadas, por meio da proposta de constante entrega de valor.
Na sequência, tratamos da visão do produto, condição fundamental para a equipe do projeto
perceber como lidar com o que está por vir, ou seja, aquilo que precisa ser realizado/entregue para
o seu cliente/usuário final. Também avaliamos os conceitos de funcionalidade, assim como a
diferença entre critério de aceitação (vinculado aos trabalhos do time do escopo) e critério de
validação (vinculado aos trabalhos do time da qualidade), termos extremamente importantes, os
quais ainda são muito confundidos por profissionais do mercado. A diferenciação entre escopo do
projeto e escopo do produto também é vital para o bom andamento dos trabalhos do gerenciamento
do escopo em um projeto.
Por fim, adentramos em uma visão geral de como é esperado um trabalho por etapas do
gerenciamento do escopo do projeto, em que primeiro foi verificado o que é essencial para que um
projeto possa ser formalmente iniciado, os esforços de uma fase pré-projeto e um possível documento
que dá origem ao projeto: o Termo de Abertura do Projeto (TAP). Não só foram ilustrados detalhes
envolvidos para o nascimento de um projeto como também foi demonstrado o princípio dos trabalhos
com as possíveis etapas do gerenciamento do escopo, em que a parceria com equipes da qualidade
será fundamental para o sucesso do bom trabalho do escopo, ao longo do projeto.

26
MÓDULO II – INTRODUÇÃO E CONCEITOS
FUNDAMENTAIS DA QUALIDADE

Neste módulo, são apresentados os principais conceitos para a compreensão do trabalho de

gerenciamento da qualidade em um projeto. A introdução se dá por um apurado histórico para
determinar como o conceito de qualidade nasceu e evoluiu ao ponto de as organizações começarem
a desenvolver enormes esforços em busca de um padrão de excelência da qualidade, com foco em
agradar cada vez mais o seu cliente/usuário final. Logo a seguir, serão demonstradas as diferenças
entre qualidade de negócio e qualidade técnica, assim como serão apresentados os principais conceitos
para o trabalho da qualidade ao longo da disciplina, por exemplo: processos, produtividade,
eficiência, eficácia, defeitos, custos da não qualidade e desperdícios (por meio da visão dos 3 Ms).
Os conceitos de inspeção, tolerância, prevenção, avaliação e limites de controle também são
apresentados, com o objetivo de conseguirmos avaliar melhor o que significa o custo da qualidade
(contraponto às ideias da não qualidade) e a sua influência para muitos momentos de tomada de
decisão ao longo do ciclo de vida do projeto. Por fim, trataremos de um dos assuntos mais
destacados atualmente no trabalho de gerenciamento da qualidade: como implementar processos
ou a cultura de melhoria contínua, em equipes/organizações de projetos. Para isso, são
demonstrados três métodos/ferramentas que poderão auxiliar nesse tipo de processo: método do
ciclo PDCA, técnica dos 5 whys e rituais de retrospectivas.

Conceito histórico
O formato pelo qual muitas civilizações antigas realizavam atos de comércio era o escambo,
ou seja, uma espécie de acordo em que havia uma relação direta de troca, em que cada uma das
partes entregava um produto ou prestava um serviço, para receber algum tipo de compensação. A
evolução natural desse modelo foi o surgimento do dinheiro, que visava à padronização em uma
unidade única (ou mais conhecida/confiável pela maioria das pessoas) como referência para uma
espécie de pagamento, em vez da dependência de um processo de escambo por coisas distintas. No
entanto, muito antes do surgimento do dinheiro, e com a evolução natural de materiais e técnicas
na construção das primeiras ferramentas que tinham o objetivo de produzir alimentos (e a
necessidade dos seus aprimoramentos contínuos), teve início o estímulo por uma valorização
crescente dos componentes e da usabilidade desses artefatos – surgia então a essência do
reconhecimento da qualidade.
O aumento do comércio e a ampliação das tecnologias de manufatura geraram
oportunidades para as bases da produção em série e, com ela, a necessidade do descarte de
produtos defeituosos, especialmente nas indústrias naval e bélica, nas quais se iniciou o controle
da qualidade baseado na inspeção do produto final (JURAN; GODFREY, 1999), um método
bom para a época, mas demasiadamente caro e muito trabalhoso. O controle do trabalho por
etapas, instituindo a distinção dos processos e das responsabilidades entre o que deveria ser
produzido e o momento da produção, estabeleceu uma importante evolução e a base do esforço
da tentativa de garantir um determinado padrão de qualidade (DEMING, 1990). Na sequência
do período histórico ocasionado pela Revolução Industrial, que pela sua vez foi responsável por
aumentar exponencialmente a capacidade de produção e, consequentemente, a dificuldade de
controlar a qualidade dos produtos manufaturados, surgiu o conceito de inspeção por
amostragem, oriundo do segmento da construção civil, cuja evolução apontou para a
implementação de controles estatísticos de produção, fundamentais para o reconhecimento
formal do aumento dos custos ocasionados pela falta de um padrão de qualidade.
O reequilíbrio das atividades comerciais após o período das duas grandes guerras, na
primeira metade do século XX, gerou as condições de ampliação da participação e da exigência
crescentes dos consumidores, movimento que culminou, ao final da década de 1960, com a
implementação da gerência da qualidade em muitas organizações, enfatizando a busca pela
melhoria dos seus produtos por meio da compreensão acerca da opinião dos próprios
consumidores/usuários finais. No entanto, um pouco antes disso, Philip Crosby já era um dos
primeiros profissionais que associavam requisitos pré-estabelecidos, gerando um padrão objetivo
de referência, a conceitos de qualidade. Crosby foi um dos responsáveis por migrar a visão da
qualidade de algo simplesmente tido como bom para algo que pudesse ser tratado como
investimento. Além disso, defendeu conceitos de defeito zero, padrões estipulados para gerar
aumento de satisfação dos consumidores (atender necessidades), eliminação de retrabalho (conceito
de fazer certo logo na primeira vez) e que qualidade devia ser responsabilidade da alta direção de
uma organização e, pela sua vez, transmitida com bons exemplos.
Já ao longo da década de 1970, a disciplinada e emergente economia japonesa aprimorou as
práticas de gestão empresarial ocidentais e mudou o paradigma da sua linha de produção, que até
então era conhecida por produtos baratos e pouco duráveis, integrando conceitos como manufatura
lean, sistemas de produção just-in-time, heijunka (método de nivelamento de produção), entre

28
outras importantes técnicas que ganhavam o mundo junto com um movimento conhecido como
Total Quality Management (TQM) – Gestão para a Qualidade Total –, transformando a
responsabilidade da qualidade não só de um departamento ou de um grupo de pessoas, mas de todo
um complexo sistema de integração entre a postura de um ser humano e a sua capacidade de resolver
problemas no local e no momento em que eles ocorrem.
O desenvolvimento econômico alavancado pela acirrada disputa por consumidores cada vez
mais exigentes estimulou os países a criarem diversas normas de padronização das suas atividades
comerciais. Esse período marcou o nascimento dos standards – padrões de qualidade – que, em um
primeiro momento, surgiram por meio da publicação da norma BS-5750, de origem inglesa, e logo
a seguir, com a ISO (International Organization for Standardization), série 9000, vindo a se tornar
uma organização internacional de normalização globalmente conhecida.
Atualmente não importa fazer o melhor produto com os melhores processos, se o resultado não
vai ao encontro do ensejo do seu consumidor/usuário final, razão de ser de todos os processos
organizacionais. Nesse sentido, organizações precisam estar plenamente sintonizadas com os seus
principais stakeholders, focando na entrega de valor percebido ou na vivência de uma experiência
diferenciada no que tange à jornada de um potencial usuário em relação ao consumo de um
determinado produto ou serviço, e ainda, uma demanda cada vez mais crescente de sustentabilidade e
propósito, ou seja, além do viés de lucro, demonstrar diferentes tipos de responsabilidades e
preocupações, suportar causas e estarem constantemente presentes para os seus potenciais públicos-alvo.

Qualidade, processos e a relação com produtividade,

eficiência e eficácia
Até aqui, temos associado, constantemente, o conceito de qualidade ao valor percebido
proporcionado por uma entrega, vinculada ao trabalho da equipe de escopo de um projeto. Não à
toa, RIES (2012, p. 98) menciona que “[...] se não sabemos quem é o cliente, não sabemos o que é
qualidade”. No entanto, existem duas maneiras distintas de lidar com o conceito de qualidade ao
longo de um projeto. É fato que quem deve determinar os objetivos de negócio de um determinado
produto, serviço ou resultado esperado é o cliente (interno ou externo). Isso deixa muitos times de
projeto em situações inusitadas, pois, por vezes, lidam em demasia com o cliente no início do
projeto e pouco ao longo da jornada, ou às vezes simplesmente não definem os preceitos que
deveriam estar atrelados à qualidade, desde o início dos trabalhos. Portanto, a qualidade de
negócio deve sempre vir do cliente. Caso o cliente, por qualquer razão que seja, não puder ou não
fizer isso, cabe ao time do projeto definir tais detalhes de alguma maneira e, minimamente,
chancelar tais ideias com o cliente. Tal ação é fundamental para alinhar o atendimento de
expectativas (um tema também muito visado no que tange à gestão dos stakeholders) com aquilo
que vem sendo desenvolvido pela equipe do projeto.

29
 Existe também a preocupação com a qualidade vinculada aos processos e ao modus operandi
do time do projeto, conhecida pelo termo de qualidade técnica – fator que, por muitas vezes, difere
produtos que poderiam ser considerados similares, mas que distinguem-se por detalhes que são de
exclusiva responsabilidade do time do projeto –, refletindo nos esforços para conduzir a execução
do projeto, conforme critérios pré-estabelecidos.
É exatamente no momento em que destrinchamos as diferenças entre qualidade de negócio e
técnica, que iniciam-se os questionamentos sobre as diferenças entre os termos produtividade,
eficiência e eficácia. Apesar de muitos autores discutirem incessantemente sobre o tema, de uma
maneira bem simples, poderemos definir os três termos por meio de reflexões vinculadas às
perguntas descritas no quadro abaixo.

Quadro 2 – Diferença entre produtividade, eficiência e eficácia

conceito pergunta

produtividade A equipe do projeto realiza muito trabalho, mas é o trabalho certo?

O trabalho é realizado com facilidade (menos recursos, tempo, dinheiro

eficiência
etc.) mas sem perder o foco em obter o máximo de efeito possível?

A equipe faz o trabalho certo na hora certa. Esse processo/método

eficácia
consegue ser repetido, sistematicamente?

Fonte: elaborado pelo autor.

Imagine o seguinte caso fictício em que a equipe do projeto precisa entregar, por exemplo,
quatro pacotes de trabalho (ou histórias de usuário), dentro de um determinado ciclo iterativo
(sprint). Alinhar os esforços corretos de estimativa desses pacotes, com o fiel cumprimento das
condições dos seus requisitos e validá-los antes do momento da entrega, faz esse trabalho ser
altamente produtivo. De nada adiantaria entregar três pacotes de trabalho extremamente bem feitos
se um ainda estivesse em atraso. Isso seria considerado ser eficiente, sem ser produtivo. Portanto,
também vincular o que foi realizado/feito, apenas para citar alguns exemplos, a critérios como
redução de esforços, eliminação de desperdícios, melhoria de níveis de satisfação de trabalho, tanto
em razão de clima organizacional como também de superar as expectativas do cliente, pode servir
de alavancagem para que um trabalho tido como produtivo (no caso do exemplo: o time ter
entregado os quatro pacotes) possa também ser considerado eficiente. O básico da eficiência é fazer
o que é correto, com menos. E, por fim, alinhar tais critérios com o perfeito senso de oportunidade
(timing), levando ao fiel cumprimento de objetivos, de preferência permitindo que tais práticas
possam ser repetidas gerando ganho de performance. Tratar corretamente o sentimento de eficácia
significa dizer que a equipe do projeto produz resultados que correspondem às necessidades e aos
desejos do ambiente externo.

30
 Alguns autores acreditam que produtividade não deve ser considerado o ato de medida final
do potencial humano. Enquanto muitas técnicas e métodos de gestão profissional de projetos nos
auxiliam a ser mais produtivos, muito provavelmente, também estão nos auxiliando a ser mais
eficientes e eficazes. Apenas para citar um breve caso prático, o método Kanban trabalha com o
conceito de Work in Progress (WIP), em português, algo como trabalho em progresso, que nada mais
é do que uma prática para melhorar a produtividade ao limitar a capacidade de fluxo de trabalho
de um determinado time em um determinado momento da execução do projeto, evitando que
exista sobrecarga. Ou seja, uma maneira de gerenciar gargalos antes de estes se tornarem
bloqueadores, permitindo que uma equipe desempenhe melhor, mantendo um ritmo de trabalho
sustentável, sem exceder a sua capacidade. A técnica WIP, pela sua vez, também deixa o time do
projeto mais eficiente, pois permite a concentração de trabalho naquilo que realmente interessa,
com uma melhor velocidade de execução. Ou seja, gera impactos positivos na eficiência e melhora
a produtividade da equipe. A sua repetição, se assimilada corretamente, possui plenas características
para também deixar o trabalho mais eficaz, afinal de contas, poderá ser repetido com relativa
redução de esforços. No entanto, se por acaso o time exceder o WIP por alguma razão, é um claro
sinal de que os processos e as estimativas precisam ser revistos e, potencialmente, melhorados.
Todos somos capazes de gerar momentos de produtividade, eficiência e eficácia, por exemplo,
momentos específicos de trabalho com maior clareza, senso de propósito e autovalidação. Perceber, com
oportunismo, como desenvolver esses momentos em trabalhos coletivos é o significado de conseguir
tirar o melhor proveito de um determinado time de projeto, em um determinado período de tempo.
Quando somos verdadeiramente produtivos, eficientes e eficazes, é mais provável que gostemos do que
estamos fazendo e nos sintamos compelidos a fazê-lo melhor, criando um ciclo virtuoso.
Os três conceitos aparecem refletidos nas boas práticas de qualidade, acima de tudo, quando
idealizamos que, para lidarmos com o trabalho (execução) da qualidade, dependemos
essencialmente de processos. Processos são um conjunto de atividades inter-relacionadas que
necessitam de insumos (entradas ou inputs, em inglês) para gerar os produtos, os serviços ou os
resultados esperados (saídas ou outputs, em inglês), com base na aplicação de técnicas ou ferramentas
específicas. Se os processos de um projeto não forem de qualidade, o risco de gerar produtos de
baixa qualidade é alto. Entretanto, nem sempre o oposto é verdadeiro – a geração de produtos de
alta qualidade não é necessariamente uma indicação de que os processos mais adequados foram
seguidos. Portanto, a qualidade do projeto é medida não apenas pelo grau de adesão aos métodos e
processos mas também pelo grau de qualidade alcançado pelos resultados/benefícios gerados pelo
projeto. Solte um punhado de moedas misturadas no chão e o resultado não será uma matriz
alinhada em linhas por tipo ou tamanho. O resultado é um monte de moedas espalhadas
aleatoriamente pelo chão. O mesmo acontece com a qualidade. Seja como for definido, a qualidade
não é um evento que ocorre naturalmente. É o resultado de um trabalho árduo e deliberado que
começa com o planejamento, inclui a consideração de elementos contribuintes, aplica processos e
ferramentas disciplinadores e nunca termina. Obter qualidade na implementação do projeto não é
uma questão de sorte ou coincidência; é uma questão de gestão. Boa gestão.

31
Defeitos, custo da não qualidade, desperdícios e a visão dos
3 Ms
Um consumidor pode exigir qualidade, organizações podem oferecer (ou prometer)
qualidade, mas um time de projetos é quem deve planejar, executar e controlar essa qualidade, de
preferência de maneira auto-organizável. Portanto, é natural que equipes de projeto sintam a
necessidade da qualidade de uma maneira particularmente diferente. Defeitos podem ter
impactos imediatos, mas talvez seja pior quando são de longo prazo, pois possuem o potencial de
trazerem consequências devastadoras, não só para a equipe do projeto, mas também para a
organização detentora dele.
O maior problema reside no fato de que o assunto qualidade, em muitos casos (e posso falar
por experiência própria, por tudo o que já vi nas dezenas de organizações pelas quais passei – mas,
antes que me perguntem: sim, existem organizações com níveis excelentes de qualidade), ainda
continua sendo gerido por meio de objetivos de qualidade imprecisos, não associados ao contexto
organizacional ou minimamente adaptado a intangíveis, como a cultura organizacional. No
entanto, existem muitos métodos de qualidade e de tomada de decisão baseados em estudos de
causa-efeito, muitos deles adaptados das suas origens fabris. Nada contra adotar práticas de
qualidade que funcionam em outras circunstâncias (aliás, muito pelo contrário, pois serei sempre
um entusiasta de qualquer técnica ou processo que possa ser adaptado para o mundo do
gerenciamento de projetos e gere resultados), mas a equipe do projeto precisa ter sempre em mente
que existe uma necessidade latente de adaptar essas práticas às peculiaridades do projeto que está
sendo desenvolvido. Talvez, exatamente por isso, ferramentas e técnicas de qualidade foram
desenvolvidas e refinadas nas últimas (muitas) décadas e já não se trata mais de uma questão pura
de arte, mas de ciência, munida de muita informação e suporte estatístico.
O PMI (2017a) reforça que cada projeto é único e que a equipe precisará adaptar a forma
como os processos de gestão da qualidade do projeto serão aplicados. Comumente, os itens a serem
considerados para adaptação incluem:
 conformidade com políticas e auditorias – o que já existe em relação a políticas e
procedimentos de qualidade na organização detentora do projeto? Quais ferramentas,
técnicas e templates de qualidade já são utilizados na organização?
 padrões e conformidades com regulamentações – há algum padrão de qualidade
específico que precisa ser aplicado? Há alguma restrição governamental, legal ou
regulatória específica que precisa ser considerada?
 melhoria contínua – existe o hábito ou procedimentos estipulados de melhoria contínua na
organização detentora do projeto? Caso exista(m), como ocorrem os processos de melhoria
contínua da qualidade? Todos são implementados? A equipe do projeto possui autonomia?
 engajamento dos stakeholders – existe algum ambiente colaborativo ou procedimento
específico para as principais partes interessadas (incluindo sponsors e fornecedores)?

32
 Retornando ao tópico defeito, enquanto o conceito da qualidade pode ser subjetivo, caso não
seja corretamente definido, o defeito é algo nítido, pois denota imperfeição. Esta pode ser traduzida
de diferentes formas, como produtos/serviços diferentes de especificações técnicas,
desconformidades físicas, vícios, baixa capacidade de utilização etc. Quando se compra uma caneta
esferográfica, por exemplo, é esperada uma determinada conduta do produto. Se a caneta for
utilizada de acordo com as orientações corretas e não há qualquer tipo de variável externa que
comprometa a sua utilização, é esperado que ela funcione com a quantidade ideal de tinta logo na
primeira utilização sobre uma superfície de papel, por exemplo. Já uma caneta cuja carga tenha
ressecado ou, ainda, que apresente como característica física alguma rachadura, dá sinais imediatos
de defeito, passíveis de reclamação ou devolução.
Para a qualidade, os defeitos são benéficos, pois podemos e devemos aprender com as falhas que
nos rodeiam. Crosby, a contrario sensu, defendia uma visão completamente diferente, pois acreditava
que a ausência de defeitos deveria ser o padrão de desempenho dos sistemas de gestão. Portanto, o
segredo para não errar seria prevenir-se o máximo possível, antecipando potenciais defeitos e, sob
qualquer custo, evitando-os. A qualidade deve ser gratuita, ou seja, traduzida por um conceito conhecido
como custo da não qualidade, pois as implicâncias envolvidas em um possível não alcance da qualidade
seriam muito maiores do que os custos de prevenção. Devemos respeitar as opiniões do renomado autor
(e conhecido guru da qualidade), que para sistemas industriais refletia muitas necessidades da época,
mas precisamos desenhar um meio-termo, principalmente no que tange à aplicabilidade desses conceitos
perante o gerenciamento profissional de projetos (é o que veremos em breve).
Pelo viés positivo dos defeitos, a premissa maior é a de que, sempre que erramos rápido, temos
o poder de retomar rapidamente uma melhor rota e evitar novos problemas, além da proposta de
gerar aprendizado sobre o defeito... e, aí sim, tornar a evitá-lo. Muitos defeitos futuros de um
produto ou serviço, ou seja, pós-entrega, podem ser evitados pelo fato de a equipe do projeto ter
verificado um potencial erro ainda no momento da execução do projeto. Destarte, é muito
importante que o time do projeto aprenda com os erros e discuta sobre os impactos e os potenciais
cenários de uma determinada falha, visando a uma atmosfera de aprendizado contínuo, de
preferência com viés de implementação de melhorias. Exatamente por isso, é necessário que
tenhamos um controle explícito de erros/defeitos. Isso já me colocou em uma posição
desconfortável, pois, certa vez, um membro de uma equipe de um projeto cujo produto final era
um grande evento, questionou se não era desmoralizante ficar mensurando todos os defeitos
daquela equipe e os expondo abertamente para todos. De pronto, respondi que, sob hipótese
alguma, o monitoramento da métrica deveria servir para intimidar ou desmoralizar a equipe, mas
que se de alguma forma aquele painel (algo próximo do que está representado na figura 6) estivesse
transmitindo uma ideia diferente da pretendida, era fato que precisaríamos conversar melhor a
respeito do tema. Antes de tudo, convidei um amigo a realizar uma palestra para o grupo. Na época,
ele era vice-presidente de uma organização que adotava a cultura do erro como fator estratégico na
condução dos projetos. Logo após a primeira parte da conversa, ele já havia conseguido transmitir

33
a ideia de que tudo depende de como as pessoas interpretam a informação vinculada ao erro,
podendo ela ser tratada de uma maneira saudável, gerando aprendizagem, hábito, respeito e
oportunidades. A priori, ninguém erra de propósito. A questão é o que será feito em relação ao erro
em si. Mostrar os erros de uma equipe, e lidar de maneira transparente em relação às consequências
e respostas, gera um efeito motivador e tem o potencial de incentivá-la a evitar novas ocorrências.
Isso é um alimento poderoso para a cultura da melhoria contínua e a vontade de adaptar práticas,
processos ou detalhes que possam melhorar o padrão de trabalho de uma equipe. Massari (2016, p.
175) diz “[...] não dê visibilidade somente ao que precisa ser melhorado, dê visibilidade ao que
funciona bem também”. Evitar defeitos significa fazer um bom uso do gerenciamento da qualidade
dos projetos. No entanto, vale lembrar que os defeitos irão ocorrer, e quanto mais cedo eles
ocorrerem, menor será o impacto desse erro nos processos de controle de mudanças do projeto,
assim como melhor será a oportunidade de aprendizagem.

Figura 6 – Gráfico de defeitos

Fonte: adaptado de MASSARI (2016).

Aristóteles (apud AUDY, 2015, p. 9) afirmou que “nós somos aquilo que fazemos
repetidamente. Excelência, então, não é um modo de agir, mas um hábito”. Salvo melhor juízo,
qualidade não é uma opção. Em muitas ocasiões presenciei projetos reais em que se acreditava que,
por alguma razão, o padrão ou o índice de qualidade havia sido modificado porque algum
demandante passou a aceitar um nível menor de qualidade, muitas vezes influenciado diretamente
por baixa disponibilidade de orçamento ou cronograma apertado. Mas, na maioria dos casos, o que
dita a responsabilidade da qualidade de um produto, serviço ou resultado esperado é o timing. No
caso de produtos e serviços, o time-to-market (tempo entre a análise de viabilidade de um
produto/serviço e o seu lançamento no mercado). Bill Gates, então CEO da Microsoft, certa vez
mencionou que, se ele tivesse de esperar para desenvolver o sistema operacional perfeito, nunca teria
lançado o Windows 1.0, em 1985.

34
 Outro caso também muito interessante é o do lançamento da primeira versão do iPhone, em
2007. Dizem que os engenheiros de software solicitaram ao então CEO da Apple, Steve Jobs, que
dessem um prazo de três semanas para que algumas novas funcionalidades do então novo conceito de
smartphone pudesse ir para as prateleiras das lojas melhor equipado. Jobs, demasiadamente
preocupado com o time-to-market, optou por lançar o produto do jeito que estava, e que ele
considerava pronto e apto para o mercado. Podemos associar tal ação, fortemente, à famosa frase “O
ótimo é inimigo do bom”, associada ao filósofo iluminista francês, Voltaire. O detalhe (reclamação
mais clássica) que ficou de fora da primeira versão lançada foi a função de copiar e colar (copy and
paste). No entanto, a decisão de lançamento com a sensação de timing perfeito permitiu a venda de
mais de um milhão de unidades, somente no primeiro fim de semana do produto,
independentemente das funcionalidades responsáveis pelo copiar e colar estarem disponíveis. O fato
é que, mesmo sem determinadas funcionalidades (na época, de alguma maneira, consideradas como
não essenciais), o produto foi um sucesso de vendas, refletido pelas expectativas consumadas dos
usuários. A baixa qualidade gera defeitos, reclamações e tem o potencial de colocar todo um negócio
em risco (a não ser, obviamente, que a estratégia de negócio esteja vinculada a um produto com baixa
qualidade... mas isso é outra história). Já o baixo preciosismo gera o engajamento de um público-alvo
consumidor fiel, com direito a feedbacks e recomendações para a evolução do produto. Muitos dos
consumidores que adquiriram a versão 1.0 do iPhone esperaram e adotaram também a versão 2.0.
Em muitos casos, a questão não é de controle da qualidade e sim de controle de preciosismo.
Por fim, os desperdícios são comuns em qualquer meio, e nos times de projetos não seria
diferente. Geralmente, são as maiores causas de atrasos em cronogramas, estouro de budgets e
referências para altos índices de insatisfação dos principais stakeholders.

A eliminação dos desperdícios deve ser perseguida a todos os momentos.

No entanto, em muitas situações, no início dos trabalhos é mais difícil
detectar e perceber os desperdícios. Eles tendem a ficar muito mais claros
e evidentes ao final das iterações (CRUZ, 2016, p. 396).

Um grande legado deixado pelo movimento lean (gestão enxuta) é a maneira como são
tratados os desperdícios de uma linha de produção e, atualmente, tal conceito foi naturalmente
adaptado para as estruturas organizacionais que desenvolvem projetos de todos os portes e tipos.
Existem muitas formas de classificação de desperdícios, até mesmo algumas metodologias são
baseadas em muitas dessas técnicas, no entanto, estudaremos um dos conceitos mais simples, pela
genialidade como se conectam com o gerenciamento da qualidade: a visão dos 3 Ms.

35
 Quadro 3 – A visão de desperdício dos 3 Ms

3 Ms significado, em português, do termo japonês

mura irregularidades / inconsistências / erros

muri sobrecarga

muda desperdícios

Fonte: adaptado de CRUZ (2016).

A visão dos 3 Ms consiste em três classificações fundamentais de desperdício, cada uma delas
abordando um determinado ponto de vista, as quais precisam ser perseguidas ao longo da execução
de um projeto, visando a um ambiente produtivo, eficiente e eficaz. Cada um dos Ms é representado
por uma palavra de origem japonesa, conforme já demonstrado no quadro.
Mura é a palavra japonesa para inconsistências, erros ou irregularidades. Como já tratamos do
assunto defeito neste mesmo capítulo, entender a proposta do conceito mura será relativamente mais
simples, basta ter em mente que não estaremos tratando de um erro final pós-projeto, com o
produto ou o serviço já pronto para o mercado. Essas inconsistências são inerentes aos defeitos
advindos dos processos do gerenciamento do projeto, ou seja, de um erro oriundo do processo de
estimar a duração de uma tarefa, de validar uma entrega ou até mesmo de comunicar uma
determinada informação, apenas para citar alguns exemplos. Elas tendem a gerar retrabalhos ou
trabalhos não planejados, promovendo uma variação no ritmo da equipe. Comumente, são
percebidas em momentos do dia em que ocorrem picos de atividades muito altos em detrimento
de momentos relativamente mais tranquilos, em que a energia da equipe não foi distribuída
igualmente. Ou seja, promovem ritmos irregulares no fluxo de trabalho. A solução para lidar com
o mura é atacar a fonte do problema e eliminar por completo a origem do desperdício. Sempre que
isso consegue ser realizado, impede-se que o mesmo defeito ocorra, eliminando um mal pela raiz.
Então, por que a equipe do projeto gastou tempo desnecessário ao estimar as tarefas de um
determinado pacote de trabalho ou história de usuário? Por que a demora e todo o sacrifício
ocorrido no momento de validar determinada entrega? Entender as causas dessas questões é um
processo fundamental para evitar que elas ocorram novamente e eventuais inconsistências possam
ser corrigidas em processos internos que geram picos de trabalho desnecessários.
Muri diz respeito à sobrecarga e pode ser aplicado a equipamentos, ferramentas ou pessoas.
No caso de equipamentos, exigir que uma determinada máquina, por exemplo, opere acima do
número de horas recomendadas ou ainda que não se respeite os períodos de descanso ou de
manutenção. Em relação às ferramentas, quando um determinado template já não cobre mais a
totalidade de uma situação por insuficiência de espaço ou por inabilidade dos utilizadores (imagine,
por exemplo, um canvas em que o time do projeto sabe responder somente às perguntas sobre

36
riscos). Já em relação às pessoas, talvez seja o ponto que mais influencia o dia a dia dos projetos,
pois refere-se a desgastes físicos e morais, decorrentes de situações de estresses pontuais. Um
exemplo é estimar mais entregas do que um time pode realizar em um determinado período de
trabalho. O muri é muito comum em momentos-chave do projeto, como deadlines para
importantes milestones ou no encerramento do projeto. É comum o time trabalhar além do
necessário para entregar detalhes da melhor maneira possível. Quando se coloca uma equipe de
projeto para trabalhar por longos períodos em uma situação de capacidade máxima, os ânimos
tendem a acirrar e não sobra tempo para aprendizados ou melhorias. Como a capacidade já está no
máximo, significa dizer que o time vive num constante caminho crítico e qualquer contratempo
gerará perdas ou atrasos complicados, pois não há folga no sistema.
Por fim, o muda representa tudo aquilo que não agrega valor ao cliente/usuário final do
produto, serviço ou solução que está sendo gerado pelo time do projeto. Toda e qualquer atividade
do time que possa ser reduzida (ou eliminada) e possa representar um maior ROI (return on
investment) – basicamente, o esforço de realização ser menor do que o benefício gerado por uma
determinada entrega –, ou seja, aumentar a vazão das entregas aliadas à proposta de entrega de valor
percebido pelos principais stakeholders do projeto. Exemplos clássicos são aquelas funcionalidades
que são requisitadas e não agregam valor ao produto ou serviço; as reuniões sem término em que se
perde muito tempo com detalhes não importantes e não objetivos, ou ainda aquelas em que as
pessoas saem com a clara sensação de que não serviram para muita coisa. Pelo fato de o mura ser
mais comum ao ambiente de projetos, penso nesse conceito como algo mais abrangente e sempre
cito um exemplo do que acontecia em uma empresa na qual trabalhei. O andar em que trabalhava
tinha um sistema de baias, com diferentes equipes trabalhando juntas, separadas por pequenas
muretas. Devíamos ser cerca de cinquenta pessoas e o nosso time do projeto, com seis pessoas, no
meio de todo esse grupo. Erámos completamente integrados ao grupo e isso era uma coisa boa e
ruim ao mesmo tempo, pois muitos muras eram gerados. O exemplo mais clássico era o dos
aniversários. Invariavelmente ocorria o aniversário de alguém e, sempre por volta das 16 horas,
parava-se tudo o que estava sendo produzido para que as pessoas se ausentassem por preciosos
minutos para cantar parabéns e comer uma fatia de bolo, sendo que, por vezes, alguns doces e
refrigerantes estendiam ainda mais a jornada do aniversário. Nada contra esse tipo de atitude, pois
ela constrói relacionamentos e contribui para elevar o moral da equipe, mas as festas eram frequentes
e não era difícil acontecer em um dia importante, no qual muitos membros da equipe estavam
bastante atarefados. No princípio, para evitar conflitos, começamos a dizer que estávamos ocupados
e que depois daríamos os parabéns ao aniversariante. Funcionou uma ou duas vezes, mas quando
as demais pessoas passaram a perceber que era uma desculpa cada vez mais frequente, passaram a
nos tratar de forma diferente, como se nós não nos importássemos mais com os momentos de lazer
do grupo. O problema é que esses momentos ocorriam em horário de expediente e passaram a ser
um problema a ser discutido. Foi quando tive a ideia de conversar com uma das responsáveis pelos
eventos de aniversário e expliquei a situação propondo que os aniversários fossem comemorados

37
uma vez por mês, em um evento no qual cantaríamos os parabéns para todos os aniversariantes de
um determinado mês, num único dia. Isso otimizaria nosso tempo e faria das comemorações
momentos mais importantes. Nós não nos livramos completamente do problema (e não era o caso),
mas reduzimos consideravelmente o número de ocorrências, passando a dar o devido valor aos
momentos em que estávamos juntos.
Uma maneira interessante de aplicar bons processos de gestão de desperdícios é combater os
3 Ms juntos, defendendo um processo produtivo mais estável e um controle mais previsível de
eventuais adaptações. Dificilmente esse controle será infalível, pois sobrecargas, irregularidades e
desperdícios tendem a ocorrer em qualquer ambiente de trabalho. Por isso, destinar atenção especial
a esse tema é um fator crítico de sucesso para qualquer equipe de projetos.

Custo da qualidade (CDQ)

Uma das primeiras perguntas que surgem quando um esforço de melhoria de qualidade é
demandado é: Quanto isso nos custará? Independentemente de qual seja o modelo de gestão, sem
dúvida alguma, trata-se de um questionamento válido. Durante muito tempo, a alta qualidade foi
associada a altos custos de produção. No entanto, quando se melhora a qualidade dos processos de
gerenciamento de um projeto, embora o novo processo possa representar um montante maior de
investimento financeiro, a redução de defeitos e de problemas pós-produção pode gerar um retorno
maior que uma mera análise nos custos financeiros. Identificar quais são os custos de uma
determinada entrega de um projeto, a fim de quantificar de maneira específica todos os seus
requisitos, visando à redução dos custos de implementação, sem se esquecer dos padrões de
qualidade adotados no momento da definição das condições do produto, serviço ou desempenho
que será gerado pela equipe do projeto (ou seja, antes da existência de alguma entrega), é uma boa
prática, principalmente quando se busca uma relação entre os benefícios advindos dessa melhoria.
Obviamente, as decisões inerentes a essa boa prática precisam estar associadas a questões como
disponibilidade de recursos, índice de satisfação de stakeholders e cronograma, entre outras. Ocorre
que, no mundo real, a qualidade gera custos, mesmo que eles sejam superados pelos benefícios.
Portanto, é importante reconhecer que as fontes dos Custos da Qualidade (CDQ) são definidas por
três fatores: falhas, prevenção e avaliação.
O custo da qualidade incluirá todos os custos decorrentes do trabalho do gerenciamento do
escopo do projeto, desde o momento em que os requisitos são colhidos, tratados, categorizados e
priorizados, visando ao fiel cumprimento das suas condições após a execução, culminando com a
validação da área da qualidade. Serão visados os cumprimentos dos requisitos em relação ao
produto, ao serviço ou ao resultado que está sendo gerado pelo time do projeto, assim como o não
cumprimento dos requisitos, por exemplo, custos com retrabalho.

38
 Para que o conceito de CDQ fique mais claro, o PMI (2017a) define alguns termos, como:
 inspeção – método para manter erros/defeitos distantes do cliente/usuário final;
 prevenção – mantém os processos isentos de erros/defeitos;
 tolerância – determina uma margem de erro que possa enquadrar uma faixa específica
para resultados aceitáveis e
 limites de controle – define fronteiras que possam servir de referência para as possíveis
variações comuns em processos tidos como estatisticamente estáveis ou desempenho
de processos.

As organizações optam a investir em prevenção de defeitos, devido aos

benefícios ao longo da vida do produto. Como os projetos são temporários,
decisões sobre o CDQ ao longo do ciclo de vida de um produto com
frequência são a preocupação do gerenciamento de programas, do
gerenciamento de portfólio, do EGP ou de operações (PMI, 2017a, p. 310).

Ainda segundo o PMI (2017a), o custo da qualidade, sempre que associado com processos
do gerenciamento de um projeto, desencadeará um ou mais dos custos demonstrados a seguir:
 custos de prevenção – relacionados à antecipação de potenciais problemas vinculados à
má qualidade em produtos, entregas ou serviços de um projeto específico;
 custos de avaliação – relacionados a diagnosticar, mensurar, periciar e verificar produtos,
entregas ou serviços de um projeto específico e
 custos de falha (internos/externos) – relacionados à não conformidade de produtos,
entregas ou serviços em relação à documentação de definição de pronto de um projeto
específico, mas também podendo ser em relação às necessidades ou expectativas dos
principais stakeholders vinculados ao projeto.

39
 Figura 7 – Custos de conformidade x custos de desconformidade

Fonte: PMI (2017a).

Um CDQ propriamente avaliado precisa refletir a proporção dos gastos inerentes às situações
de prevenção e de avaliação em relação àqueles que serão realizados na tentativa de evitar falhas.
Sempre que um dos custos de um lado da balança começa a consumir esforços ou gastos em
demasia, é possível que a razão financeira já não esteja equilibrada e o investimento em, por
exemplo, custos de prevenção, já não justifique os elevados valores. Há sempre um momento em
que um investimento deixa de ser eficaz em função da proporção entre gastos e benefícios. No
entanto, em alguns casos, altos custos fazem parte do business, como investimentos altos em custos
de prevenção para projetos de perfuração de petróleo em alto mar. Tudo isso precisa ser levado em
consideração no momento do planejamento e da execução da qualidade de um projeto. Alguns
exemplos podem ser verificados na figura anterior.
Em linhas gerais, o mais perigoso é deixar que o cliente/usuário final descubra os defeitos
inerentes ao desenvolvimento do produto, serviço ou resultado gerado pelo time do projeto. A não
ser que seja um público-alvo específico que se envolva no processo de melhoria pós-lançamento,
como é muito comum acontecer em setores de tecnologia e editorial, nos quais o próprio usuário
pode descobrir o erro e informar ao fabricante, pois há uma cultura de certa tolerância com essa
proposta. No entanto, o que mais se vê, sempre que existe tempo e investimento suficiente para
isso, é a possibilidade de descobrir e corrigir os problemas antes que as entregas sejam aceitas pelo
cliente. Uma variação dessa abordagem seria usar a garantia da qualidade para examinar e corrigir
o processo em si e não apenas defeitos especiais. Outro tipo de abordagem, também muito comum

40
em muitos setores ou tipos de projetos, pode ser exemplificada pela figura a seguir, que demonstra
que os custos, quando aproximam-se das extremidades do gráfico de custo da qualidade (seja da
busca pelo perfeccionismo com 100% de conformidades ou uma necessidade extrema de melhora
com 0% de conformidades), fogem ao propósito por serem demasiadamente elevados. Então, uma
boa prática é estabelecer um limite de controle da qualidade, excetuando-se as extremidades,
permitindo que seja gerado, por exemplo, um padrão de 80% de conformidades. Dessa forma,
existirão padrões de qualidade que serão estritos, rigorosos e estabelecidos com respostas binárias:
sim ou não/go ou no go. Porém, também existirão os padrões que estipularão, por exemplo, uma
lista com 50 conformidades e, no momento da verificação, será aceita uma identificação de 40
conformidades mínimas como limite, ou seja, 80% em relação ao total, independentemente de
quais sejam as ocorrências.

Figura 8 – Custo da qualidade (CDQ)

Fonte: adaptado de KIRKPATRICK (1970).

Quando migramos para abordagens ágeis ou mais próximas de implementações híbridas, a

qualidade é comumente incorporada no planejamento do projeto e reflete na execução dos ciclos
iterativos, nos quais as equipes são responsáveis por avaliar e validar, mesmo que parcialmente,
potenciais entregas já utilizáveis e escalonáveis, no encerramento de cada sprint. Ou seja, a gestão
da qualidade e as medidas de monitoramento e controle constituem uma parte integral dos sprints,
em vez de serem executadas somente ao final do projeto, como um pensamento tardio. Além da
qualidade ser executada diversas vezes, em diversos níveis, há a possibilidade da construção de uma

41
sólida base de conhecimento e aprendizado sobre a qualidade do produto, serviço ou desempenho
que está sendo gerado pela equipe do projeto. Outra boa prática extremamente difundida é a
geração de uma cultura interna constantemente voltada para a melhoria de processos e da qualidade,
seja do produto final ou do ambiente de trabalho da equipe, por exemplo.

Melhoria contínua: PDCA, 5 whys e retrospectivas

Uma das heranças mais significativas do movimento lean é o princípio fundamental de
melhoria contínua. O amanhã precisa ser melhor que o hoje nem que seja em relação a minúsculos
detalhes, sendo fundamental a percepção de evolução por parte da equipe do projeto e, de
preferência, dos principais stakeholders. Apesar de o termo poder ser bastante abstrato – sempre
devemos avaliar o contexto em que está sendo utilizado –, no que tange ao gerenciamento de
projetos, significa buscar sempre por agregar mais valor para o cliente/usuário final daquilo que está
sendo gerado pela equipe do projeto e, ao mesmo tempo, reduzir (quiçá eliminar) etapas que geram
desperdícios (lembrar do conceito dos 3Ms), minimizando possíveis efeitos negativos.
Muitas são as técnicas, ferramentas e rituais disponíveis para que se implementem ações de
melhoria contínua. Trataremos neste material das três mais utilizadas/efetivas: aplicação do ciclo
PDCA, análise de causa-raiz com utilização da técnica dos 5 whys e o ritual de retrospectiva.
O ciclo PDCA, um acrônimo para Plan (Planejar), Do (Executar), Check (Checar ou
Verificar) e Act (Agir ou Controlar), é um processo iterativo em quatro grandes etapas, que serve
para implementar melhorias de processos. Historicamente, o modelo se baseou em um método
científico de hipótese-experimentação-avaliação, que acabou por ter uma série de corruptelas, sendo
ele próprio, o PDCA, a mais famosa de todas.
O PDCA não é uma prática exclusiva do gerenciamento de projetos, muito pelo contrário.
Ele nasceu da necessidade do aprimoramento de processos, inicialmente fundamental para muitas
organizações, ganhando o mundo do gerenciamento de projetos depois. O próprio modelo do Guia
PMBOK® é baseado em um formato ao estilo PDCA, pois, excetuando-se os processos que estão nas
extremidades (os de iniciação e o de encerramento), todos os demais acabam por representar uma
espécie de PDCA, pois o Plan corresponde ao grupo de processos de planejamento; o Do, ao de
execução; o Check, ao monitoramento; e o Act é relativo ao controle. Enfim, tudo muito sutil, mas
ainda assim um grande sistema PDCA para gerir o ciclo de vida de um projeto.

42
 Figura 9 – Ciclo PDCA

Fonte: adaptado de SITEWARE (2017).

No momento do P, de plan/planejamento, cabe ao time do projeto identificar o problema

que precisa ser resolvido/melhorado; selecionar as pessoas mais habilitadas para girar o ciclo PDCA;
mapear o problema do início ao fim, vinculando potenciais causas e consequências; identificar os
métodos de análise; e, definir os objetivos que precisam ser alcançados para aquela situação
específica que será trabalhada. A dica é elaborar um plano de ação bem estruturado para facilitar o
tratamento do problema. No D, de do/executar, o plano de ação toma forma e precisará ser
implementado. É quando a equipe do projeto demonstra que possui as competências para fazer o
planejamento funcionar e ganhar forma, engajando todos os stakeholders necessários para que isso
ocorra. Todos os resultados são documentados e aguardarão a próxima etapa, que vem a ser o C,
de check/verificar, responsável por avaliar o passo a passo de tudo o que foi realizado durante todo
o ciclo de implementação do plano, analisando a documentação e checando resultados. Trabalhos
de comparação entre o status quo e o momento pós atingimento dos objetivos propostos costumam
fazer parte das boas práticas dessa etapa, pois conseguem auxiliar o processo de descrição dos
problemas/defeitos que serão corrigidos no passo seguinte. Se os resultados mensurados nessa etapa
não forem adequados, em alguns casos, sugere-se que a equipe do projeto retorne ao momento do
planejamento. Em relação ao A, de act/agir, é o momento destinado a colocar em prática todas as
possíveis ações corretivas vinculadas ao problema estudado. Também destina-se a um momento de
reflexão para distribuir o conhecimento adquirido pelo trabalho realizado e avaliar futuras
investigações que demandem uma nova rodada do ciclo.

43
 A base para a abordagem científica da Toyota é perguntar “por que” cinco
vezes sempre que encontramos um problema… Ao repetir “por que” cinco
vezes, a natureza do problema, assim como sua solução, se torna clara
(KANBANIZE, s. d., on-line).

Outra técnica bastante utilizada é a dos 5 whys (os 5 porquês, em inglês), que proporciona a
sondagem das diferentes camadas de um problema, levando o nível de compreensão de uma
potencial solução até a sua causa primária (e também as intermediárias, se for o caso). Naturalmente,
sempre que se investiga um problema, a tendência é descobrir como ele surgiu. É exatamente o que
essa prática propõe, de uma maneira iterativa, aprofundando a análise do problema ao avaliar todas
as possíveis causas até que se atinja a raiz do efeito negativo. Para chegar à conclusão que a causa é
realmente a raiz do problema, basta continuar realizando a sondagem ao questionar os seguidos
porquês. A técnica é denominada de 5 porquês, mas, na verdade, trata-se de um número arbitrário.
É possível que se chegue a um grau complexo de entendimento do problema com apenas dois
porquês. Em outros casos, talvez seja necessário questionar vinte porquês, dependendo do grau de
complexidade da situação. O importante é nunca aceitar a primeira resposta como verdadeira e
tentar explorar ao máximo a técnica até que se chegue à causa-raiz (definitiva) do problema.
Veja este exemplo extraído do website kanbanize.com:

Problema: A newsletter sobre as últimas atualizações de software não foram enviadas no prazo correto.
WHY 1 – Por que as newsletters não foram enviadas a tempo?
“Porque as atualizações não foram entregues até o prazo final.”

WHY 2 – Por que as atualizações não foram entregues a tempo?

“Porque os desenvolvedores ainda estavam trabalhando nos novos recursos.”

WHY 3 – Por que os desenvolvedores ainda estavam trabalhando nos novos recursos?
“Porque um dos novos desenvolvedores não conhecia os procedimentos.”

WHY 4 – Por que o novo desenvolvedor não estava familiarizado com todos os procedimentos?
“Porque ele não foi treinado adequadamente.”

WHY 5 – Por que ele não foi treinado adequadamente?

“Porque o CTO acredita que os novos funcionários não precisam de um treinamento
extensivo e devem aprender enquanto trabalham.”

44
 Como resultado, o problema investigado, que parecia ter sido gerado por uma questão
técnica, acabou por demonstrar um erro nos processos internos da empresa, algo completamente
diferente do que parecia em uma primeira avaliação, mais superficial. A equipe negligenciou o fator
humano e se prendeu, ao menos no primeiro momento, a critérios técnicos relacionados ao
desenvolvimento do produto. Após a análise dos 5 whys, algumas possibilidades para resolver o
problema e não repetir mais uma conduta de atraso no envio da newsletter poderão ser idealizadas
e, potencialmente, compartilhadas com outros setores, se for o caso. Quanto aos processos internos,
é bem provável que outras áreas da mesma organização adotem processos semelhantes e estejam
aptas a incorrer em problemas semelhantes.

Retrospectivas recorrentes verificam regularmente a eficácia dos processos

de qualidade. Procuram a causa-raiz dos problemas e sugerem tentativas
de novas abordagens para aprimorar a qualidade. Retrospectivas
subsequentes avaliam quaisquer processos experimentais para determinar
se estão funcionando e devem ser continuados ou receber novos ajustes, ou
se devem ser abandonados (PMI, 2017a, p. 312).

A reunião de retrospectiva, também conhecida como sprint retrospectiva, em alguns casos, é

um dos rituais mais importantes de muitos dos métodos/metodologias ágeis, pois representa o
momento de fechamento de um ciclo iterativo e a oportunidade de aprender (e replicar o
aprendizado) o que foi realizado pela equipe durante um determinado período. A reunião tem o
poder de concentrar propostas de melhoria contínua em relação a processos, pessoas, estruturas e o
que mais se fizer necessário. Várias vezes ouvi equipes de projeto se referirem à retrospectiva como
o momento da DR (“discussão da relação”) e, apesar da analogia com relacionamentos amorosos,
faz sentido avaliá-la como uma excelente oportunidade para obter feedbacks individuais e coletivos,
assim como demonstrar orgulho naquilo que está sendo realizado pelo time. Assim como se
demonstra orgulho pelos detalhes bons (ou ótimos), é importante discutir os detalhes ou
procedimentos que deram errado, evitando repetir os mesmos erros, detectando soluções para
eliminar ou reduzir desperdícios. Não é um momento para reclamações e choradeiras. Não se deve
nunca perder o foco da melhoria contínua.

O fluxo do gerenciamento da qualidade

O gerenciamento da qualidade do projeto se faz presente em todos os momentos do ciclo de
vida de um projeto. Veremos que, ao trabalharmos o gerenciamento da qualidade como um sistema
amplo, dificilmente não se respira qualidade, até mesmo antes da iniciativa da formalização oficial
para um determinado projeto. É muito comum que organizações ou equipes de projeto orientadas
para a qualidade se preocuparem em estabelecer padrões e definir critérios/atributos de qualidade

45
antes de o projeto ser iniciado, muitas vezes refletidos nas necessidades do negócio ou em certificações
de qualidade já existentes. Na verdade, em organizações com o drive da qualidade, as normas são tão
poderosas que seria impossível não ter todos os procedimentos já estabelecidos de antemão, assim
como no momento do seu encerramento, pois, sem um bom roteiro da qualidade, dificilmente
concretizam-se resultados satisfatórios para a organização. Aqui, estamos tratando de uma série de
fatores vinculados à qualidade, como níveis de satisfação das principais partes interessadas, ROI –
return on investment, melhoria de processos internos e gestão do conhecimento, entre outros.
O fluxo de trabalho da qualidade, quanto ao roteiro de execução, é bastante simples. A proposta
básica é que a qualidade possa ser planejada (ou, em alguns casos, apenas confirmada, quando os
standards já existirem), executada, verificada e, em casos de problemas, ajustada, com potenciais reflexos
em atualizações do seu próprio planejamento. Veremos que muito do trabalho que decorre dessas quatro
etapas está constantemente alinhado com outros temas do gerenciamento de projetos, como o trabalho
de gerenciamento do escopo e dos requisitos, dos riscos, das comunicações e dos stakeholders, apenas
para citar os mais próximos. No entanto, muitos outros temas, apesar de não estarem ligados
diretamente ao fluxo da qualidade, serão eventuais fornecedores de informações e terão os seus trabalhos
potencialmente refletidos pela gestão da qualidade. Portanto, a partir do momento em que o
planejamento da qualidade está pronto, ainda que parcialmente, já é possível afirmar que existe
influência dessas informações nos demais trabalhos de planejamento do projeto.
Após o trabalho de planejamento da qualidade, teremos todas as normas e regulamentações
da qualidade confirmadas para o projeto, incluindo todas as métricas necessárias para a execução
dos processos formais de validação das entregas, vinculadas ao trabalho do gerenciamento do
escopo. Sempre que uma entrega puder ser verificada, esse trabalho será realizado pela gestão da
qualidade, que estará estruturada por meio de uma série de técnicas e ferramentas da qualidade para
que o roteiro de validação possa ser cumprido com o rigor estabelecido no momento do
planejamento. Em linhas gerais, a partir do momento em que desconformidades não são
encontradas e, consequentemente, a sequência de execução dos trabalhos é consumada conforme o
planejamento do escopo, as informações serão documentadas e transmitidas às partes interessadas
cabíveis, cumprindo o passo a passo das exigências para uma boa gestão da qualidade.
Sempre que ocorrer algum tipo de verificação da qualidade e desconformidades (até mesmo
novos defeitos fora de uma situação vinculada ao planejamento) entre a execução e o padrão
estabelecido no momento do planejamento forem detectadas, as informações também precisarão
ser documentadas e informadas, contendo os pareceres da qualidade necessários. Tais pareceres
servirão como base para futuros processos de tomada de decisão no intuito de avaliar se a
desconformidade será sanada no todo ou em parte, e como isso ocorrerá. Caso a equipe do projeto
opte por não sanar a desconformidade encontrada, ela terá de justificar e documentar os porquês
da decisão. Muitas vezes, por exemplo, essas decisões podem decorrer de uma necessidade de se
cumprir um momento importante do cronograma; de estarem vinculadas à decisão de algum
stakeholder importante para o projeto; ou, até mesmo dos custos elevados para a correção dos

46
problemas, alguns nem mesmo previstos no momento do planejamento do projeto. Enfim, tudo é
possível em relação ao que será realizado para o trabalho de gestão das desconformidades
encontradas, cabendo à gestão da qualidade, no entanto, deixar tudo corretamente documentado.
Isso é de suma importância para resguardar os responsáveis pelos processos de tomada de decisão
da qualidade, visando a pavimentar o caminho a ser tomado pela equipe, assim como a refletir os
impactos de cada possível alternativa.
Uma visão detalhada do fluxo da qualidade de um projeto e uma sorte de técnicas/ferramentas
comumente utilizadas nos trabalhos da qualidade serão tratadas nas próximas unidades.

Retrospectiva do módulo
Neste módulo, iniciamos o trabalho pelo conceito da qualidade e muitos dos termos
necessários ao seu estudo e à sua compreensão, especificamente no que diz respeito à sua correta
aplicação pelo gerenciamento profissional de projetos. Começamos, como não poderia deixar de
ser, com um breve cenário histórico para credenciar o assunto qualidade, não só como importante,
mas como primordial em um ambiente de gerenciamento de projetos. Entender as causas que
levaram o tema qualidade a ser alçado de meios fabris para uma questão de suma importância dentro
das organizações só reforça os cuidados que passaremos a ter para gerir corretamente os trabalhos
da qualidade de um projeto.
Estabelecemos a diferença entre a qualidade de negócio, vinculada aos objetivos daquilo que
se pretende atingir com a entrega do produto final, serviço ou resultado esperado, e a qualidade
técnica, responsável pelos atos da equipe especializada, que influencia diretamente a forma de
conduzir os trabalhos de implementação das entregas do projeto. Tratamos de temas como
produtividade, eficiência e eficácia e as suas reflexões em tudo o que pode ser credenciado como
trabalho da qualidade, seja vinculado ao planejamento, à gestão ou à verificação e aos ajustes.
Além disso, tratamos dos conceitos de defeitos (imperfeições), dos custos da não qualidade
(todo esforço admitido em ações que visam a garantir que processos e produtos finais coincidam
sempre com especificações pré-definidas), dos desperdícios (aquilo que pode ser melhorado ou
eliminado, pois não gera valor para o trabalho da equipe do projeto) e dos desdobramentos em
função da técnica dos 3 Ms (mura, muri e muda). Vimos que, segundo Crosby, a qualidade (como
um todo) deveria ser mensurada pelo custo dessa não qualidade, tendo ciência de que a qualidade
resulta exclusivamente da prevenção, mas também avaliamos o contraponto dessa proposta.
Pudemos compreender melhor a relação entre os gastos realizados por ações de prevenção ou
de avaliação dos gastos inerentes às falhas, tanto internas quanto externas, e como isso é revertido
para o conceito de custo da qualidade (CDQ). Um time de projeto (em muitos casos também as
organizações) precisa avaliar se os custos de um lado dessa proporção não estão elevados demais em
relação aos benefícios que poderão ser gerados, pois podem ser julgados como impraticáveis diante
do alto grau de investimento.

47
 Por fim, explicamos o conceito de melhoria contínua e a necessidade cada vez mais premente
da sua utilização em processos de gerenciamento de projetos. Oportunamente, navegamos em três
formas, dentre muitas outras possíveis, de implementação de melhoria contínua: o ciclo PDCA, os
5 whys e o ritual de retrospectiva. Ainda verificamos como se dá o fluxo da qualidade no
gerenciamento de projetos, objeto específico de um estudo mais detalhado à frente.

48
MÓDULO III – PLANEJAMENTO DO
ESCOPO: PARTE I

Neste módulo, iniciaremos os trabalhos de planejamento do gerenciamento do escopo em

projetos. Para que isso seja possível, será demonstrado o conceito de valor e como esse intangível
pode variar ao longo do tempo, ou, ainda, sofrer a influência de variáveis que fogem ao controle da
equipe do projeto. Também é demonstrado o conceito de requisito, as suas possíveis classificações
e tipos, além da correlação com o conceito de funcionalidade, assim como a necessidade de métricas
e padrões para o acompanhamento e a verificação dos parâmetros do requisito. Um fluxo de
trabalho de requisitos é demonstrado por meio do ciclo de coleta, análise, priorização e
implementação, fazendo-se acontecer sempre que justificado pela equipe ou pela natureza do
projeto. Vemos muitas das técnicas de elicitação de requisitos preconizadas pelo Guia PMBOK® e
algumas ferramentas de priorização eficazes para auxílio na organização das informações,
apresentando dois artefatos fundamentais: o documento de registro dos requisitos e a matriz de
rastreabilidade dos requisitos.

Valor
Trabalhar o escopo de um projeto e alinhá-lo com valores fundamentais que determinarão o
sucesso (ou não) de todo um esforço empregado em prol de um produto, serviço ou resultado a ser
gerado não é um segredo guardado a sete chaves, mas, ainda assim, muitas equipes tropeçam em
detalhes que podem fazer a diferença no momento de mensurar os resultados finais de um projeto.
Muito se estuda e se ouve acerca do conceito de valor. Acelerando um pouco a discussão e
traduzindo logo esse conceito para o mundo do gerenciamento de projetos, em linhas gerais, é aquilo
que as principais partes interessadas valorizam em relação aos esforços de uma equipe visando à
satisfação de diferentes expectativas com aquilo que será gerado. O curioso é que o tempo e muitas
outras variáveis atuam perante essas partes interessadas, influenciando novos comportamentos,
anseios e temores. Consequentemente, essas circunstâncias podem transmutar critérios que serviam
como base para a construção de expectativas. Então, ainda que de maneira imperceptível para muitos
dos envolvidos, altera-se uma possível visão desse valor. Por exemplo, o que seria o valor de um projeto
para um patrocinador? Poderíamos dizer que um projeto entregue dentro de um budget pré-definido,
que cumpriu o cronograma e entregou aquilo que foi documentado, com qualidade verificada, pode
ser considerado, tipicamente, um projeto de sucesso. E se essa entrega não gerar os efeitos estratégicos
pretendidos pela organização? Digamos que, em uma iniciativa estratégica para melhorar a gestão de
clientes de um determinado setor de uma organização, parte do projeto seria implementar um sistema
de CRM – Customer Relationship Management (Gestão de Relacionamento com o Cliente, em
tradução livre), responsável por otimizar o armazenamento da informação e por relacionar atividades
de um cliente com potenciais interações com a empresa. Seria muito simples dizer que um sistema de
CRM implementado no prazo, cumprindo todos os requisitos com qualidade e dentro do orçamento,
estaria de acordo com as expectativas do seu patrocinador (e, provavelmente, de muitas outras partes
interessadas). Mas, e se, em vez de o novo CRM colaborar com as ações comerciais da empresa, o tiro
sair pela culatra e os vendedores não se entenderem com a nova ferramenta, atrasando pedidos,
duplicando informações e fazendo horas extras por causa do retrabalho? Seria muito simples dizer que
o projeto deu certo, pois foi implementado como manda o figurino, mas a estratégia pós-projeto não
funcionou corretamente. Será que esse patrocinador está satisfeito? Será que a culpa é do time
comercial ou da equipe do projeto? Enfim, muitas são as variáveis que poderiam ter sido evitadas
visando a um melhor aproveitamento do êxito desse projeto, em vez de simplesmente olhar pelo lado
tático de entregar um produto, sem avaliar o fator humano envolvido. Possivelmente, muitas culpas
seriam lançadas e, no final das contas, se nada fosse realizado para que se entenda o problema
corretamente, diriam que o CRM é horrível e que o timing do projeto foi errado. E o tal valor
percebido pelo patrocinador que estava satisfeitíssimo com um projeto perfeito? Para se resguardar de
problemas como esses, é muito importante que a equipe do projeto consiga, desde o início, estabelecer
critérios para a definição do que será considerado valor, em relação ao que está sendo gerado. Portanto,
quando iniciamos os trabalhos de planejamento do escopo, definir valor é um sério fator crítico de
sucesso, ainda assim, negligenciado por muitas equipes. Ao definir, por exemplo, aquilo que os
clientes (internos/externos) ou usuários finais valorizam, automaticamente, a equipe do projeto estará
apta para definir o que fazer e como fazer, além de priorizar entregas, definindo se deverá ou não
realizar algum determinado detalhe.
Todos nós possuímos olhos de clientes/usuários finais. Por muitas vezes, o que uma equipe
de projetos necessita é um exercício de empatia. Colocar-se no lugar de quem vai receber o produto,
serviço ou resultado a ser gerado pela equipe do projeto pode auxiliar na prevenção de muitos riscos.
Além disso, humanizar a execução dos trabalhos é demonstrar que a equipe realmente se importa
com aquilo que está sendo realizado, promovendo uma conexão profunda entre as duas pontas:
aqueles que fazem/entregam e aqueles que utilizam/necessitam.

50
 Cito um exemplo extremamente simples de entrega de valor em uma situação na qual um
cliente/usuário final não esperava receber tal benefício. Era um dia agitado, com horários confusos
e aquela sensação de correria. Finalmente, o avião decolou e o serviço de bordo teve início. Eu só
queria um café e a comissária de bordo, gentilmente, perguntou se eu também não gostaria de um
copo d’água. Isso foi uma gentileza na qual eu não estava pensando. Na sequência, ela ainda me
perguntou se eu utilizaria açúcar ou adoçante (pergunta protocolar), mas eu respondi que não uso
nenhum dos dois. As mãos dela estavam prontas para me entregar algo e eu percebi uma pitada de
desapontamento quando dei a resposta rápida. No mesmo instante, eu pedi desculpas e solicitei
que ela me entregasse o que havia preparado. Qual não foi a surpresa quando percebi o meu nome
na embalagem do açúcar! Pode ser algo mínimo para muitos, mas, naquele momento estressante,
ver um esforço na dedicação da comissária para tentar deixar o meu dia mais agradável foi algo
muito prazeroso. Pode nem ter sido algo solicitado pela companhia aérea e ter sido uma ação
idealizada pela profissional, mas o fato é que isso me levou a perguntar a ela, mais tarde, se havia
sido uma ação proposital. Sim, ela me disse que como tinham tido tempo antes do embarque e
estava de posse da lista de passageiros, apenas tentou combinar alguns dos nomes disponíveis nos
pacotes de açúcar com os assentos ocupados, visando à prestação de um serviço mais customizado.

Figura 10 – Entrega de valor ao cliente

Fonte: acervo do autor.

Em suma, valor é a importância que alguém (ou um conjunto de pessoas) dá a uma

determinada coisa. Clientes/usuários finais são os responsáveis por definir o valor de um produto,
serviço ou resultado a ser gerado pela equipe de um projeto. Quando isso não ocorre, cabe à própria

51
equipe do projeto investigar informações acerca do que precisa ser realizado/entregue, de preferência
com um algum tipo de auxílio desses importantes stakeholders, para que a percepção de valor possa
ser fielmente representada por meio de padrões, condições e, muitas vezes, métricas, que servirão
para a criação de uma linguagem comum entre todos. A maneira pela qual o valor de um produto,
serviço ou resultado é representado passa pelo gerenciamento dos requisitos de um projeto. A partir
do momento em que a equipe do projeto conhece os requisitos e interpreta corretamente as
necessidades (do cliente/usuário final/organização) ou oportunidade detectada, consegue
compreender detalhes que tinham potencial de se perder ao longo de trabalhos até mesmo bem
gerenciados, mas, de alguma forma, ficava a sensação de ter deixado algo importante para trás.

Requisitos: conceito e classificações

Se você deseja conhecer o seu passado, verifique suas condições atuais. Se você
quer conhecer o seu futuro, analise as ações presentes (ditado budista, s. d.).

Como o próprio PMI (2017a, p. 166) preconiza, “[...] as tendências e práticas emergentes
para o gerenciamento do escopo do projeto incluem, mas não estão limitadas a um foco em
colaborar com os profissionais de análise de negócios para facilitar a implementação bem-sucedida
do produto, serviço ou resultado final do programa ou projeto”.
Isso denota maior preocupação com um trabalho de gerenciamento do escopo não sendo
meramente realizado dentro da esfera do projeto mas em um ambiente de governança corporativa
em que colaborações de setores de análises de negócio podem trazer grandes benefícios. Além disso,
como cada projeto é exclusivo, o time, com o auxílio do gerente, precisará ajustar a maneira como
as etapas do gerenciamento do escopo do projeto são conduzidas, no intuito de melhor adaptar o
trabalho realizado com o modelo de continuidade do ciclo de vida do projeto: preditivo, iterativo,
incremental, ágil ou híbrido (visto no módulo I).
O desafio de planejar o gerenciamento do escopo do projeto será realizado uma vez ou, então,
em momentos definidos previamente, consumando diversos atos ao longo do projeto. Mas, em
primeiro lugar, é importante salientar que requisito é “[...] uma condição ou capacidade que é
necessária estar presente em um produto, serviço ou resultado, para satisfazer um contrato ou
especificação formalmente imposta” (PMI, 2016, p. 2, tradução nossa). Essas especificações podem
ser normas ou metas organizacionais estratégicas. É comum que os requisitos expressem
necessidades, desejos, anseios ou expectativas explicitadas por partes interessadas específicas –
clientes internos/externos, patrocinador, usuário final, organizações, time do projeto etc. – e sempre
que relacionados podem vir a gerar novas funcionalidades que precisarão ser implementadas, muitas
vezes agregando trabalho ao gerenciamento de estruturação, que será realizado mais adiante.

52
 Requisitos nascem de informações que estarão diretamente vinculadas ao sucesso ou ao
fracasso do projeto, pois o gerenciamento é algo que demanda uma especial atenção por parte do
time do projeto. São muitos os fatores críticos de sucesso que precisam ser observados no momento
de lidar com o assunto requisito, sendo os principais:
 engajamento organizacional – todo trabalho que envolve um viés estratégico demanda
o comprometimento e o alinhamento da organização com as propostas de entrega de valor
e os objetivos do projeto. O representante maior desse engajamento é o patrocinador do
projeto, pois a falta de apoio de um patrocinador é um dos principais fatores que
contribuem para o fracasso de um projeto (PMI, 2018);
 reconhecimento do valor de um plano de gerenciamento dos requisitos – um plano
de gerenciamento dos requisitos corretamente elaborado e ativo, por meio do qual se possa
não só idealizar um trabalho de planejamento, mas, sobretudo, um trabalho de
monitoramento e controle, será percebido como um domínio valioso com um potencial
de alavancar o ROI – Return on Investment (retorno sobre o investimento) do projeto e,
em consequência, da organização capitaneadora do projeto;
 engajamento das partes interessadas – as partes interessadas devem ser engajadas com a
devida antecedência e com frequência ao longo do ciclo de vida do projeto,
independentemente do ciclo de continuidade escolhido pelo time para executá-lo. As
partes interessadas serão analisadas e gerenciadas de perto, com frequência, no intuito de
que o time do projeto possa perceber os impactos e as influências dos principais
stakeholders no processo de gerenciamento dos requisitos o mais cedo possível,
minimizando ou eliminando potenciais problemas e
 integração com as atividades do gerenciamento do projeto – o gerenciamento dos
requisitos não ocorre de maneira isolada. É necessário que todas as principais ações do
time do projeto, bem como das principais partes interessadas, estejam conectadas, de
alguma maneira, com o trabalho conduzido pelo time de requisitos.

Requisitos podem ser classificados de diferentes maneiras para auxiliar o processo de

transparência de informações e prover um melhor contexto para o seu gerenciamento. De acordo
como um determinado requisito é classificado, muito se pode dizer a respeito do trabalho que virá
a ser realizado, notadamente na questão da descoberta da fonte da informação e do futuro processo
de elicitação – ato de obter informações das principais partes interessadas.
Os requisitos classificam-se em:
 requisitos de negócio – são a verdadeira justificativa do início de um projeto. Descrevem
as necessidades ou ideias de alto nível estratégico organizacional, para que possa dar vazão
a uma ideia, ser resolvido um problema ou atender a uma necessidade;

53
  requisitos de partes interessadas – descrevem as necessidades de um determinado
stakeholder ou de um grupo de stakeholders. Costumam revelar as expectativas desse(s)
stakeholder(s) em relação ao que será gerado pelo projeto e são a base para identificar os
requisitos de solução;
 requisitos de solução – descrevem as funcionalidades e os recursos que o produto, serviço
ou resultado a ser gerado precisa exibir no intuito de atender aos requisitos de negócio e
aos requisitos das partes interessadas. Assim como é importante compreender o que precisa
ser exibido, muitos autores também defendem que o que não precisa ser exibido deve ser
tratado da mesma maneira. São comumente conhecidos como:
 requisitos funcionais – são comportamentos que precisam ser exibidos ou operações
específicas que a solução vai executar e
 requisitos não funcionais – são condições ambientais ou atributos exigidos, não
necessariamente obrigatórios, para que a solução gerada funcione de maneira eficaz.
 requisitos de transição – descrevem as capacidades temporárias essenciais para migrar de
um estado atual para um estado futuro, incluindo a conversão de dados e as formações de
preenchimento de lacunas;
 requisitos de qualidade – descrevem os padrões necessários para prover a conclusão das
entregas do projeto, demonstrando a conformidade das funcionalidades estipuladas ao
longo do planejamento com as que foram ou serão implantadas, assim como as métricas
de qualidade, fundamentais para o momento de chancelar uma entrega;
 requisitos do projeto – descrevem as ações ou quaisquer condições necessárias para que
o time do projeto possa executar o trabalho e entregar a solução proposta e
 requisitos do programa – descrevem as especificações e as saídas necessárias para entregar
os benefícios propostos pelo gerenciamento do programa.

Uma boa prática em gerenciamento de projetos é determinar, no planejamento do escopo,

como os requisitos deverão ser coletados, analisados (verificando o impacto sobre a abordagem de
desenvolvimento do produto ou do projeto), organizados e/ou classificados e, por fim,
documentados. A maneira de documentar os requisitos pode variar, por exemplo, de uma planilha
em Excel para um template mais elaborado, contendo macros, descrições e anexos detalhados, ou
ainda por meio de softwares específicos.

Coleta dos requisitos

O PMI (2017a, p. 174) define o ato de coletar os requisitos como “[...] determinar,
documentar e gerenciar as necessidades e requisitos das partes interessadas a fim de cumprir os
objetivos” e ainda afirma que “[...] o principal benefício deste processo é que o mesmo fornece a
base para definição e gerenciamento do escopo do produto e do projeto”.

54
 A prática de coletar requisitos será realizada uma vez ou, então, em momentos definidos
previamente, ao longo do projeto. Ainda segundo o PMI (2017a), muitas são as formas para que a
equipe de projetos consiga coletar requisitos, sendo que dificilmente descreveremos todas as
possibilidades, pois, para cada caso específico, pode existir uma maneira própria de descobrir
importantes informações. Há a sugestão para a utilização de opinião especializada, com uma clara
indicação de que as especialidades sejam voltadas para análise de negócio, obtenção e análise dos
requisitos, documentação dos requisitos, requisitos em projetos similares, técnicas de diagramas,
técnicas de facilitação e gerenciamento de conflitos. Contudo, há também a sugestão para a utilização
de coleta de dados por meio de brainstorming, entrevistas, grupos de discussão, questionários,
pesquisas e benchmarking. Não devemos, contudo, nos limitar à lista proferida pelo guia, pois pode
ser de grande valia, por exemplo, alocar um quadro branco com uma caneta marcadora em uma copa
ou local de refeições para permitir que os utilizadores desses ambientes deixem as suas ideias ou
impressões a respeito do que precisa ser executado por um determinado projeto em que eles são partes
interessadas na solução. Indivíduos ficam protegidos por um relativo grau de anonimato e não existe
qualquer nível de juízo de valor em relação às sugestões ou às ideias proferidas.
Todas são consideradas abordagens metódicas. Na primeira, com a utilização de um
facilitador ou um moderador, podem-se levantar ideias de maneira aleatória ou ordenada, em que
um conjunto de técnicas é aplicado em um grupo de indivíduos para que o pensamento criativo
possa ser estimulado e surja uma orientação final do que precisa ser feito ou uma direção a ser
tomada. Nada é descartado, pois não existe o conceito de errado ou absurdo. A mera citação de algo
absurdo pode gerar um insight para outro indivíduo e protagonizar uma nova funcionalidade.
Na realização de entrevistas, são formuladas perguntas relevantes e as respostas são
documentadas para, posteriormente, serem analisadas pelo time do projeto. Podem ser estruturadas,
com um determinado grau de planejamento, ou então desestruturadas, com as perguntas sendo
formuladas após o resultado das respostas anteriores, entre as muitas técnicas possíveis.
Grupos de discussão, normalmente, protagonizam sessões estruturadas com times
multidisciplinares com viés de identificação dos requisitos necessários por meio de consenso entre
os participantes. É uma excelente técnica para auxiliar o gerenciamento de conflitos do time.
Questionários e pesquisas são utilizados para um grupo específico ou quando se necessita de
informação em larga escala para uma futura análise de dados, no intuito de determinar padrões ou
preparar futuras elicitações. O cuidado a ser tomado é que as muitas maneiras de se apresentar um
questionário ou de se realizar uma pesquisa podem afetar direta ou indiretamente os resultados, por
exemplo, realizar uma pergunta ao vivo para uma pessoa ou solicitar resposta por meio de um e-
mail ou uma ligação telefônica. Cada um dos métodos está sujeito a inúmeras variáveis, em alguns
casos, alheias aos olhos do profissional responsável pelo questionário.
Já a técnica de benchmarking visa a comparar produtos, serviços ou resultados para a
verificação de status e a criação de uma base de referência.
Nenhuma dessas técnicas é excludente ou considerada sequencial de outra. Elas podem ser
utilizadas em separado, em conjunto, ou ainda, complementarmente, de acordo com a necessidade

55
de informações. Quando se menciona, por exemplo, a utilização de análise de dados por meio de
análise de documentos, significa dizer que uma substancial quantidade de informações pode ser
descoberta, basicamente, revisitando ou analisando documentações pré-existentes, mas, se for o
caso, essas documentações poderão ser geradas por outras técnicas/ferramentas, e então, na
sequência, analisadas por meio de técnicas de análises de documentos.
Acrescido a essas técnicas, em determinados momentos, o time do projeto precisará tomar
decisões que direcionarão o trabalho com os requisitos. Para isso, há a possibilidade de utilização
de técnicas de votação – nas inúmeras formas – ou análises de decisão envolvendo critérios
múltiplos. Neste último caso, a definição dos critérios pode vir a ser subjetiva, e é importante que
esses critérios sejam bem selecionados, explicados aos participantes e corretamente ponderados.
Há também a opção pela representação de dados via diagramas de afinidades, por meio dos
quais se pode perceber o acúmulo de determinados dados no intuito de se avaliar tendências,
evidências ou erros de amostragens, assim como técnicas de mapeamento mental que evidenciam,
novamente, um processo criativo, segmentado e interligado, com a proposta de destrinchar
problemas ou ideias no sentido de melhor compreendê-las. Outra finalidade é auxiliar a gerência
do fluxo de informações de um determinado sistema, produto, serviço ou resultado a ser buscado.
Segundo o PMI (2017a), podem ser utilizadas técnicas de habilidades interpessoais de equipe,
como grupo nominal, observação ou conversação e facilitação. Grupo nominal consiste em uma
técnica estruturada, que é considerada uma vertente do brainstorming, assim como o brainwriting,
indicada quando não se deseja que a opinião de um participante influencie as opiniões dos demais.
O resultado deverá ser consensual.

Figura 11 – Exemplo de diagrama de contexto

Fonte: adaptado de RESEARCHGATE (2016).

56
 A técnica de observação/conversação consiste em permitir que um determinado tipo de
trabalho ou procedimento, por exemplo, seja observado, discutido, por um ou mais indivíduos que
tomarão notas, farão medições e registrarão os momentos observados/conversados. Comumente
utilizada para verificar como um indivíduo utiliza (ou deseja utilizar) um determinado produto ou
serviço e quando determinados stakeholders têm dificuldade de expressão das necessidades em
relação a um determinado produto ou serviço. Também existem as técnicas de facilitação, que são
utilizadas para deixar procedimentos, reuniões ou discussões mais eficientes, sem que haja perda de
foco dos participantes, e as participações de todos sejam estimuladas.
Por fim, existem os diagramas de contexto e as técnicas de prototipagem. A primeira é uma
ferramenta muito utilizada para modelar o escopo, tanto do projeto quanto do produto, por meio
de referências visuais, conforme se pode visualizar na figura anterior. Já a segunda é uma técnica
utilizada para receber feedbacks e evitar desperdícios, pois serve para agilizar a definição de
funcionalidades, testar opções, implementar ajustes e reduzir futuros problemas com mudanças
inadvertidas do escopo.

Análise, organização e classificação dos requisitos

Segundo o site Project Builder (2017, on-line), “[...] a análise de requisitos é uma verdadeira
revolução no que diz respeito a dois importantes aspectos organizacionais da empresa: a
produtividade na execução do projeto e a maneira como a equipe colabora e se organiza”. É um
trabalho que, quando realizado com consistência, auxilia a equipe do projeto em todos os sentidos,
tendo influência direta em fatores que, potencialmente, conduzem ao sucesso do projeto.
Por tudo o que vimos até aqui, já temos a percepção de que as condições desejadas para a
idealização de um produto, serviço ou resultado devem vir diretamente do cliente/usuário final e
ser corretamente interpretadas pela equipe do projeto para gerar bons frutos. Para isso, visualizam-
se todas as informações recebidas, de uma maneira ordenada, avaliando cada necessidade para as
suas implementações, descrevendo detalhes e estimando esforços, mesmo que de uma maneira ainda
preliminar. É importante lembrar que, conforme a próxima figura, não existe necessariamente um
único fluxo para lidar com os requisitos ao longo de um projeto. A partir do momento em que um
determinado lote de requisitos é especificado e pode gerar outros tipos de trabalho para a equipe do
projeto, por exemplo, estimativas de cronograma, há uma evolução natural para lidar com a análise,
a priorização e a posterior execução desse lote. Mas é possível, por exemplo, que nasça um novo
lote (ou onda) de requisitos, para uma maior necessidade de compreensão de determinados detalhes
ou até mesmo, para novas ideias ou acréscimos ao escopo. Portanto, nada impede que, enquanto
um lote estiver em uma fase mais avançada, outro esteja iniciando o ciclo de vida. Isso se repetirá
quantas vezes forem necessárias para que a equipe do projeto consiga entregar o valor necessário
para atender às expectativas do cliente/usuário final.

57
 Figura 12 – Ciclo do caminho dos requisitos

Fonte: elaborada pelo autor.

Na primeira etapa, visualizada no quadrante superior direito, são realizados os atos de coleta
e de documentação dos requisitos. Muitos são os formatos possíveis para que isso ocorra, conforme
bem visualizamos anteriormente. No quadrante inferior direito, trata-se do fluxo natural dos
trabalhos, quando os requisitos são avaliados, no sentido de saber quais serão efetivamente
necessários para o projeto (pois colhe-se muita coisa que não chega a ser utilizada), podendo ganhar
diferentes tratamentos, como pesos, ordens de grandeza ou níveis de importância, para depois serem
organizados ou categorizados (muitas das formas possíveis de categorização foram descritas no início
deste capítulo). É comum complementar algum tipo de informação pendente nesse momento, pois
os requisitos, quando analisados, ganham níveis de detalhamento visando a uma futura
implementação. Uma boa prática é determinar as métricas pelas quais os requisitos serão
comparados no momento da verificação da qualidade. Isso significa estabelecer os padrões. Um caso
curioso de análise e organização dos requisitos aconteceu quando a equipe do projeto responsável
pela pesquisa histórica para o filme O resgate do soldado Ryan, do diretor Steven Spielberg, descobriu
que a coleta realizada havia sido tão rica em quantidade de informações e nível de detalhes, que
acabaram criando arquivos de material extra, para um futuro projeto. Tamanho foi o grau de
empolgação da equipe, que esses requisitos foram responsáveis por originar uma minissérie chamada
Band of Brothers, completamente amparada por esse material. O quadrante inferior esquerdo faz
referência a trabalhos de priorização, com o potencial de criar um backlog (espécie de fila de
funcionalidades prontas para serem criadas/implementadas). Existem muitas técnicas de priorização
dos requisitos, desde as mais simples, como elencá-los por níveis (alto, médio e baixo) ou por
números, por exemplo, mas o importante é caracterizar como serão demonstrados os requisitos
inegociáveis, no intuito de traçar uma estratégia de priorização de entrega de valor. Por fim, o
quadrante superior esquerdo faz menção a tudo aquilo que já foi priorizado (já planejado) e poderá

58
ser executado, ou mesmo gerando a necessidade de coletar mais informações para que se avance
com o desenvolvimento do produto, serviço ou resultado. Se isso ocorrer, potencialmente, um novo
ciclo dos requisitos será gerado.
Ainda como forma de priorização, existem técnicas simples que podem ser facilmente
adotadas pelo time do projeto e poderão agregar muito valor ao trabalho do gerenciamento dos
requisitos. Neste material, serão descritas apenas duas, das muitas possíveis: a matriz de importância
versus urgência e a técnica conhecida como MoSCoW.

Quadro 4 – Matriz importância versus urgência

urgentes não urgentes

importantes

Não são de resolução imediata,

Acrescentam valor e resultados
mas acrescentam valor e
e são de resolução imediata.
resultados.
importantes

São de resolução imediata, Não acrescentam valor nem

não

mas não acrescentam valor. são de aplicação imediata.

Fonte: elaborado pelo autor.

A matriz de importância versus urgência é uma técnica simples que utiliza os quadrantes de
uma matriz com o eixo de grau de importância – alta/baixa ou sim/não – e o outro eixo de grau de
urgência para avaliar os requisitos que serão implantados (idem). A técnica é simples, pois consiste
basicamente em separar os requisitos determinando se uma funcionalidade, por exemplo, é
considerada com alto ou baixo grau de importância e com alto ou baixo grau de senso de urgência.
Os requisitos que forem classificados com alta importância e alta urgência são aqueles que
visivelmente acrescentam valor ou trazem resultados imediatos e requerem uma resolução também
imediata. Serão considerados requisitos essenciais e precisam ser implantados o mais rápido possível.
Os requisitos classificados com baixo grau de importância e alta urgência são considerados
secundários, pois, apesar de serem de resolução imediata, não geram valor aos olhos dos principais
stakeholders. Os requisitos classificados entre alto grau de importância e baixo grau de urgência
também serão considerados secundários. A diferença é que, apesar de não serem considerados de
resolução rápida ou imediata, possivelmente acrescentam valor ou resultados ao projeto. Por fim,
os requisitos que não são nem importantes nem urgentes, pois não agregam valor nem são de
resolução imediata. Estes precisam ser mapeados, mas dificilmente serão implantados, dependendo
de um processo estruturado de tomada de decisão.

59
 Figura 13 – Técnica MoSCoW

Fonte: CRUZ (s.d.).

Segundo o PMI (2016), cada requisito levantado pela equipe do projeto tem a
possibilidade de ganhar uma classificação de prioridade determinada pela utilização do
acrônimo formado pela palavra MoSCoW.
A letra M significa must have ou, em português, algo como deve ter. Serão os requisitos tratados
em primeiro nível (primários), aqueles imprescindíveis e que trazem uma relação de retorno alto. Por
causa disso, são capazes de agregar valor ao produto, serviço ou resultado que está sendo gerado e,
quando corretamente implantados, afetam diretamente os níveis de satisfação dos principais
stakeholders. A letra S significa should have ou deveria ter. São os requisitos secundários. Não serão
tratados como vitais ao projeto, mas são importantes e, quando implantados corretamente, podem
influenciar diretamente os níveis de qualidade, tornando operacional um determinado detalhe de um
produto, por exemplo. A letra C significa could have ou poderia ter. Serão tratados como requisitos
terciários e, apesar de poder trazer algum diferencial àquilo que será gerado pelo time do projeto, não
são tão imprescindíveis. Salvo melhor juízo, costumam ser implantados apenas em caso de sobra de
recursos ou folga de cronograma. Por fim, há a letra W, de won’t have ou não terá. São requisitos que
não trazem qualquer tipo de valor agregado para o produto, serviço ou resultado que está sendo
desenvolvido e serão implementados apenas em último caso.

Documentação dos requisitos

Muitas são as possibilidades para o momento de documentação dos requisitos. Eu mesmo já
presenciei um projeto que foi completamente documentado por meio de fotografias. No entanto,
dois artefatos que podem ditar grande parte do sucesso de um projeto são: um documento
consistente para registro dos requisitos e uma matriz de rastreabilidade dos requisitos.

60
 Requisitos podem ser detalhados inicialmente em um formato e, gradativamente, alcançarem
níveis de detalhes mais complexos, por exemplo, a partir do momento em que novas informações
são recebidas pelo time do projeto ou novas funcionalidades são demandadas pelo cliente. Sendo
assim, é importante que todos os requisitos sejam documentados com a utilização das técnicas que
melhor convierem às necessidades da situação requerida pelo projeto e às restrições de
tecnologia/recursos, podendo variar de uma simples listagem, de preferência com os requisitos
categorizados e priorizados, até a utilização de sistemas de informações complexos ou sharepoints,
contendo descrições detalhadas e anexos.
O mais importante é que não haja espaço para interpretações equivocadas e, sempre que
possível, já se descrevam os critérios de aceitação e de validação no intuito de conduzir tanto os
trabalhos do time de escopo como os trabalhos do time de qualidade, no futuro.

Quadro 5 – Template para documentação (registro) dos requisitos

título do projeto data da versão

parte grau de critério de critério de

ID requisito categoria
interessada priorização aceitação validação

Fonte: adaptado de SNYDER (2013).

Uma boa documentação de requisitos diz muito sobre o grau de atenção que o time do
projeto dedica para implantar a solução que está sendo gerada. Definir, às vezes, o básico, mas
seguir e manter atualizadas essas informações com grau de atenção suficiente é determinante para
que os membros alocados nas demais áreas de conhecimento do projeto possam desempenhar os
seus papéis e responsabilidades com eficácia. Uma atualização de uma priorização de requisito
não documentada pode colocar todo um período de trabalho em xeque, com consequências em
curto e em longo prazos.
O template sugerido é simples, porém de grande valia. Começa-se identificando o requisito com
um código que poderá ser numérico ou de qualquer outro tipo e, logo na sequência, inicia-se a
descrição do requisito. Imagine, por exemplo, que o projeto seja um grande evento contendo
apresentações musicais ao vivo. Um dos patrocinadores comerciais solicitou ao time do projeto um
palco suficientemente alto para que a sua marca, quando apresentada na face frontal do palco, pudesse
ser vista por toda a área do evento. Estamos, claramente, lidando com um requisito de parte
interessada. Um dos requisitos de solução que poderia estar vinculado a esse desejo seria, por exemplo,
o estabelecimento da altura mínima do palco em 30 metros. O requisito técnico (condições do palco)
passa a corroborar então o requisito de negócio (funções do palco). Para preencher o campo inerente

61
 à parte interessada, basta descrever de onde veio a solicitação ou ideia para a implantação de um
determinado requisito. Se não houver um nome específico para essa parte interessada, pode-se alocar,
por exemplo, o nome de um setor, de um cargo ou de uma pessoa jurídica, apenas para que a
informação não permaneça incompleta e, posteriormente, seja atualizada.
Na sequência, podem-se categorizar os requisitos como temporários, de solução, de qualidade
etc., conforme classificação melhor recomendada.
Em relação às prioridades, pode-se simplesmente elencá-las como alta, média ou baixa, ou
utilizar qualquer ferramenta de priorização dos requisitos, adotando as respectivas terminologias.
Apenas para citar um dos exemplos trazidos na unidade anterior, se a técnica utilizada fosse a
MoSCoW, bastaria a utilização das iniciais M, S, C ou W, como códigos. Encerrando o
preenchimento do documento, descreve-se o critério de aceitação, determinando como ficará
caracterizado o aceite – ou formato de handover – daquele requisito e o critério de validação, que
descreverá como ter certeza de que o requisito alcançará a precisão vinculada à qualidade, no futuro.
No exemplo citado, como ter certeza de que o palco possui no mínimo trinta metros de
altura? O desejo do patrocinador não era ter a sua marca visualizada em toda a área do evento?
Então, como validar que a marca, depois de alocada, será de fato vista por toda a área do evento?
Aqui, temos diferentes técnicas de medições ou de inspeções que podem ser estipuladas para validar
tal requisito. Pode-se utilizar até mesmo uma técnica de observação. Para efeitos de teste, pendura-
se algo do tamanho do logotipo da marca no lugar desejado e percorre-se toda a área do evento para
avaliar se o material consegue ser visualizado conforme almejado.
Atenção, a ideia aqui não é gerar juízo de valor, aferindo se um determinado critério é
bom ou ruim. Essa análise será realizada pelo time do projeto, com o auxílio do líder do projeto,
em um momento futuro. O importante é que existam critérios de aceitação e de validação, ao
menos, para as principais etapas ou entregas do projeto, lembrando sempre que um requisito
sem critério de validação pode se transformar em um problema significativo. Determinar ao
menos um critério de validação para cada requisito é uma maneira de o time do projeto se
resguardar objetivamente, e não subjetivamente.

Quadro 6 – Template para a matriz de rastreabilidade dos requisitos

título do projeto data da versão

critério
parte entrega
ID requisito prioridade categoria objetivo métrica de
interessada da EAP
validação

Fonte: adaptado de SNYDER (2013).

62
 Assim como uma boa documentação dos requisitos é importante, uma correta rastreabilidade dos
vários atributos desses requisitos ao longo de todo o ciclo de vida do projeto também é um fator crítico
de sucesso. Trata-se de um documento muito utilizado no momento de avaliar a aceitação de entregas
parciais e definitivas de produtos, serviços ou resultados, assim como algo muito útil no momento da
solicitação de mudanças e como instrumento de suporte para processos de tomada de decisão.
As informações inseridas no registro dos requisitos (quadro 5) servirão como base de
informação para esse novo artefato. O template apresentado no quadro 6 é apenas um exemplo dos
muitos estilos que uma matriz de rastreabilidade dos requisitos pode ter. O template sugerido é
baseado nos objetivos do projeto, nas entregas da EAP, nas métricas e nos critérios de validação,
mas é possível, por exemplo, gerar uma matriz entre requisitos funcionais e não funcionais, entre
requisitos técnicos e de segurança ou ainda entre requisitos técnicos e de negócio.
É possível, em alguns casos, ver esses exemplos citados em materiais especializados com o
nome de Matriz de Rastreabilidade Inter-requisitos. Uma vez mais, como o template apresentado é
uma sugestão, ele poderá ser customizado conforme as necessidades de cada projeto, de acordo com
o que o time do projeto julgar cabível de ser rastreado.
Em relação às cinco colunas iniciais, o tratamento é o mesmo destinado ao template de
documentação dos requisitos. Exatamente por isso, a base inicial de informações dessa matriz utiliza
a documentação pré-confeccionada, mas, a partir da sexta coluna, com o item objetivo, muda-se um
pouco a maneira de tratar a informação, pois começa-se a descrever que tipo de objetivo será
cumprido ou está relacionado ao correspondente requisito.
Um exemplo de objetivo seria total visibilidade da marca do patrocinador master, que poderia
estar vinculado a um requisito de tamanho do palco, com características de trinta metros de altura.
A coluna seguinte determina a qual item da Estrutura Analítica do Projeto (EAP) esse requisito está
vinculado. Na sequência, para garantir a correta entrega desse requisito, demonstra-se então como
será realizada a medição para atender às suas condições ou características.
Por fim, qual será a técnica destinada para validar o fato de o requisito atender às condições
elencadas? Utilizando ainda o exemplo do palco do evento, pode-se simplesmente dizer, por
exemplo, técnica de inspeção com utilização de trena digital – para a medição da altura em metros.

63
Retrospectiva do módulo
O módulo III iniciou a sua trajetória demonstrando o que é valor e como esse conceito se
correlaciona com o trabalho de gerenciamento do escopo do projeto. Vimos como o sentido de
valor precisa, de alguma forma, ser definido visando à criação de um caminho que suporte o
trabalho da equipe do projeto, para que as expectativas das principais partes interessadas possam ser
atendidas da melhor maneira possível, culminando em benefícios tangíveis e intangíveis. Estes
poderão ser apreciados também pela organização detentora do projeto.
Na sequência, definimos o conceito e a importância de um requisito e foram citados os fatores
críticos de sucesso para tratar o assunto em um ambiente de projeto, a saber: engajamento
organizacional, reconhecimento do valor de um plano de gerenciamento dos requisitos,
engajamento das partes interessadas e integração com as atividades do gerenciamento do projeto.
O termo elicitação também ganhou uma atenção especial. Não que a palavra não existisse ou não
fosse utilizada anteriormente, mas ganhou uma nova proporção com o advento do novo Guia
PMBOK®, pois significa o ato de obter as informações das principais partes interessadas. Uma função
de extrema importância para o trabalho com requisitos.
Os diferentes tipos de requisitos também foram explorados, permitindo visualizar melhor
como classificar um requisito em funcional ou não funcional, de negócio, de partes interessadas, de
solução, de transição, de qualidade, do projeto ou do programa.
Demonstramos a importância de a equipe do projeto trabalhar corretamente um fluxo enxuto
de gerenciamento dos requisitos, em que um bom nível de atenção no momento inicial de entender
às necessidades/expectativas do cliente/usuário final é fundamental para o desencadear de outras ações,
como a sequência natural de análise, a categorização e a priorização desses requisitos. Somente depois,
a equipe do projeto poderá implementá-las, devidamente orientadas à proposta de entrega de valor.
Algumas sugestões de técnicas de priorização de requisitos, como a ferramenta da matriz
importância versus urgência e a técnica MoSCoW foram apresentadas. Estas, sempre que a
necessidade demandar, poderão ser customizadas, no intuito de melhor atender às características
de um determinado projeto.
Por fim, apresentamos dois dos principais artefatos para documentação e gestão dos
requisitos: o registro dos requisitos e a matriz de rastreabilidade dos requisitos. O primeiro é
responsável por ser a base de informações oficiais, constantemente atualizada acerca do tema, ao
longo do projeto; a segunda, uma maneira de conectar as informações dos requisitos com os
objetivos do projeto, as entregas da EAP, as métricas e os critérios de validação. Também
percebermos que é possível, por exemplo, gerar matrizes específicas com base em requisitos
funcionais e não funcionais, entre requisitos técnicos e de segurança, ou até mesmo entre
requisitos técnicos e de negócio.

64
MÓDULO IV – PLANEJAMENTO DO
ESCOPO: PARTE II

Apresentaremos o conceito de planning onion, que demonstrará como o planejamento do

escopo deve ser distribuído em vários níveis, combinando uma perfeita sensação de timing para
atender aos objetivos estratégicos da organização, além das questões táticas e operacionais de uma
equipe de projeto. Também será exposta a importância de se trabalhar uma linha de base do escopo,
seja ela como for, mas acima de tudo, preocupada em definir todos os termos e regras necessários
para uma visualização de planejamento do escopo ao longo do projeto. Trata-se de uma
documentação que acompanhará o projeto por todo o seu ciclo de vida e influenciando os demais
temas/equipes vinculados ao projeto, assim como no trabalho realizado do escopo, que será
comparado, constantemente, com a base planejada. Alguns artefatos são demonstrados, como a
declaração do escopo e a estrutura analítica do projeto e os seus componentes (pacotes de trabalho,
pacotes de planejamento, contas de controle, dicionário, entre outros). No entanto, não limitam o
trabalho de confecção de uma boa linha de base do escopo a tais documentos. Os principais
tipos/formatos de uma estrutura analítica do projeto também são demonstrados, assim como o
cuidado que uma equipe de projetos deverá ter com um fenômeno conhecido como scope creep.

Planejamento do escopo em vários níveis

O trabalho de gerenciamento dos requisitos é parte integrante do gerenciamento do escopo
e, a evolução natural desse trabalho, após um primeiro nível de esforço para a compreensão das
expectativas das principais partes interessadas e o início da documentação dos requisitos, cabe voltar
as atenções da equipe do projeto para a execução das tarefas ligadas aos pacotes de trabalho ou
histórias de usuário (aquilo que precisa ser feito/entregue), gerando entregas aptas a serem
verificadas e, posteriormente, validadas com o OK de um time da qualidade.
 Não podemos abrir mão de um bom trabalho de planejamento do escopo, que culmina com a
base de informações necessária à correta execução, conforme mencionado. É necessária uma definição,
logo em um primeiro momento, visando o nível de detalhamento do trabalho. Trabalhos de
planejamento podem ser exaustivos e produzir toneladas de informações que nunca serão utilizadas.
Então, saber o momento certo de encerrar (ou reduzir) os esforços do planejamento é tão importante
quanto saber o momento de iniciar os trabalhos. Além disso, esse trabalho precisa ser compatível com
o cronograma e com a quantidade/qualidade dos recursos disponíveis para o time do projeto, sendo
que o nível de detalhamento precisa corresponder a esses insumos. O segredo para a busca dessa
eficiência é distribuir o planejamento em diferentes níveis, lembrando sempre de utilizar tais insumos,
de maneira ordenada, para produzir o melhor produto, serviço ou resultado possível.
Segundo Cruz (2016, p. 257), um bom planejamento “[...] precisa ser quebrado em pedaços
menores e ser realizado em diferentes níveis”. Uma técnica que adapta bem esse conceito é
conhecida como Planning Onion (Planejamento Cebola ou Planejamento dos Anéis da Cebola),
demonstrada na próxima figura.

Figura 14 – Planning Onion

Fonte: adaptado de CRUZ (2016).

Os níveis representam os momentos em que os planejamentos são realizados, cada um com

durações e peculiaridades específicas, sendo que, quanto mais vinculado a uma camada externa da
cebola, com menor grau de detalhamento o planejamento será. Não que o anel 1 não seja
importante, muito pelo contrário, o planejamento do projeto é importantíssimo para todo o
contexto restante, mas poderá sobreviver com informações relativamente superficiais, já que o
determinante para o planejamento do projeto é a visão geral do escopo. No entanto, estamos
lidando com um nível de planejamento voltado para temas estratégicos e cumprimento de objetivos
organizacionais. Tópicos importantes para serem avaliados pela equipe no detalhamento do nível

66
de planejamento do anel 1 são (sem estarem limitados a esta lista): riscos ligados a diferentes setores
da organização ou a outros projetos com algum grau de dependência; objetivos estratégicos
organizacionais; macro informações, por exemplo, aprovação de orçamentos, cronogramas,
relacionamento com o patrocinador etc.; membros e autonomia da equipe do projeto; e, registro e
avaliação dos principais stakeholders.
O anel 2 trata do planejamento inerente ao produto, serviço ou resultado que será gerado
pela equipe do projeto, e é um elo natural entre as necessidades estratégicas organizacionais e as
questões táticas, pois começa a se preocupar com o resultado final do projeto, mesmo que a equipe
ainda não possua as características detalhadas vinculadas ao escopo do produto. São itens desejáveis
de planejamento nesse momento: necessidades priorizadas do cliente/usuário final (das mais básicas
às impreteríveis); expectativas das principais partes interessadas; condições especificadas do produto,
serviço ou resultado a ser gerado; aquisições e contratos; estimativas de recursos; e, tipo de
abordagem destinada ao projeto.
Para o nível 3, podemos visualizar duas situações distintas, desde projetos com abordagem
mais próxima da preditiva que determinam etapas para entregas-chave do projeto, até projetos com
abordagem ágil que trabalham com entregas escalonáveis ou incrementos de produtos. De qualquer
forma, é importante avaliar o que é necessário para o cumprimento dos requisitos mínimos
necessários, priorizados, de preferência com viés de entrega de valor para as principais partes
interessadas, nos momentos das entregas das etapas (vinculados a momentos-chave do projeto) ou
dos incrementos (vinculados ao final de ciclos iterativos). São propostas para o planejamento nessa
fase: classificações e priorizações de requisitos; restrições; padrões e métricas da qualidade; riscos
remotos; e, ferramentas e técnicas de comunicação.
Já no nível 4, trabalha-se o planejamento da iteração curta. Isso significa dizer que,
dificilmente um projeto com abordagem preditiva chegará a esse nível de planejamento (muito
menos o nível 5). Passamos a lidar com esse nível de planejamento apenas em abordagens iterativas,
incrementais, ágeis ou híbridas, visando aos ciclos (sprints) que costumam servir como referência
para a entrega de incrementos, potencialmente melhoráveis. Normalmente, não se condicionando
a estes detalhes, visam a: planejar, avaliar e programar respostas a ciclos de feedbacks; detalhamento
das atividades/tarefas; atualização/reorganização de prioridades; motivação de equipe; experiências,
interações e comportamentos; problemas e questões decorrentes da execução das atividades; gestão
de conflitos; e, experimentos e testes/validação de hipóteses.
Por fim, de todos os níveis de planejamento, aquele que será o mais curto (em termos de
tempo decorrido), mas o que servirá para situações extremamente pontuais, com um caráter de
inspeção e adaptação do trabalho, quase como uma sintonia fina para ajustes e orientações de curto
prazo. São desejáveis: alinhamento de expectativas da equipe; colaboração multifuncional;
impedimentos ou pequenas resolução de conflitos; e, realizações e previsões curtas.
O Planning Onion, sob hipótese alguma, é responsável por um trade-off entre momentos de
planejamento e execução. Isso não ocorre, pois a execução do projeto, inobstante do momento em
que ele esteja, não é parada para que ocorram trabalhos de planejamento. Por isso que a proposta é

67
ser cada vez mais superficial, de fora para dentro, sem perder tempo com discussões inócuas ou que
estejam fora do alcance da equipe. Limitar os momentos de planejamento aos seus respectivos
níveis, com os seus respectivos pesos, significa permitir o engajamento da equipe com o objetivo de
realizar trabalhos de execução, independentemente de estarem também envolvidos em atividades
de planejamento. O fato de não existir uma fórmula mágica para definir o quanto de planejamento
um projeto deve ter, deixa os limites de tempo para cada nível de planejamento dos anéis de cebola,
de livre escolha da equipe de projeto, seja administrando o cronograma (e o timing das informações)
disponível(is) para o projeto ou respeitando rituais ágeis, por exemplo.
Cabe uma última observação em relação ao método de planejamento Planning Onion, pois
apesar de o capítulo ser exclusivo sobre o tema escopo, em uma prática real da técnica, não devem
ser omitidas as demais informações no que tange, por exemplo, a esforços de planejamento de
comunicação ou de gerenciamento do engajamento das partes interessadas, entre muitos outros
tópicos já listados. Como bem pôde ser percebido, tudo o que envolve o planejamento do escopo
tem o potencial de influenciar outras temáticas do projeto e vice-versa. Ou seja, normalmente,
decisões sobre o assunto escopo são possíveis provocadoras de muitos impactos em áreas como riscos
e cronograma, entre outras, sendo que a visão do todo é fundamental para a compreensão dos
diferentes níveis propostos pela técnica Planning Onion.

Linha de base do escopo

Materialização do planejamento do escopo, que também servirá como referência para tudo o
que for efetivamente realizado no futuro do projeto, a linha de base do escopo é um compêndio de
informações formada por uma série de documentos que refletem todas as necessidade de trabalho
do escopo do projeto e do produto, para a equipe do projeto, assim como os principais stakeholders.
Segundo o PMI (2017a), uma linha de base do escopo pode conter uma Declaração do
Escopo do Projeto (DE), com descrições do escopo do projeto e do produto, entre outros detalhes;
uma Estrutura Analítica do Projeto (EAP), uma decomposição hierárquica daquilo que precisa
ser realizado; o dicionário da EAP, especificações detalhadas que complementam cada item da EAP;
pacotes de trabalho (último nível da EAP), que são parte de contas de controle, por sua vez,
responsáveis por integrar escopo, cronograma e custos; e, pacotes de planejamento, o nível acima
dos pacotes de trabalho e abaixo das contas de controle, sem descrição de atividades vinculadas ao
cronograma. Todas essas referências serão exploradas ao longo deste módulo.
O principal benefício ao definir o escopo do projeto é descrever os limites do produto, serviço
ou resultado e os respectivos critérios para aceitação. É exatamente o que propõe qualquer artefato
nos moldes de uma DE, que, por meio de uma descrição detalhada, serve para auxiliar, definir,
desenvolver e restringir o escopo do projeto e do produto. Considerado como um dos documentos

68
mais importantes do planejamento geral do projeto, em face de trazer informações cruciais acerca
do entendimento comum do escopo do projeto, bem como das partes interessadas, pode utilizar
para a sua confecção informações trazidas no TAP e na documentação dos requisitos, por exemplo.
O TAP continuará cumprindo a função preliminar de repositório de informações nesse
momento de definições do projeto. Alguns documentos do projeto, uns elaborados desde o
momento da iniciação e outros oriundos do planejamento, também se fazem úteis, como o registro
de premissas, o registro de restrições e a documentação dos requisitos. Não há como definir detalhes
importantes do escopo sem avaliar corretamente o que existe de premissas e restrições até o presente
momento. Imagine o seguinte projeto: reforma de um hotel, localizado em uma ilha. Uma das
restrições definidas pelo patrocinador do projeto desde os momentos iniciais pode ser que todo e
qualquer material relativo à obra deverá ser transportado exclusivamente por barcos, ou seja, via
marítima. Sendo assim, no momento de definir como a estratégia do escopo do projeto será
implementada, não adianta vincular materiais helitransportados para ganhar tempo ou facilitar
algum tipo de operação; afinal de contas, restrição é restrição.
A documentação dos requisitos precisa estar presente porque trata dos primeiros esforços de
coleta, análise e priorização dos requisitos e influenciará diretamente os trabalhos de definição do
escopo do produto, pois foram definidos, progressivamente, escutando as principais partes
interessadas do projeto. É muito provável que nem todos os requisitos do projeto e do produto
tenham sido plenamente registrados até o presente momento, principalmente se o trabalho será
realizado por meio de ciclos iterativos, em que a coleta dos requisitos vem a ser constante, em
intervalos regulares, durante todo o ciclo de vida do projeto.
Por isso, a declaração do escopo sofrerá influência constante da coleta dos requisitos, sujeita
a alterações ao longo da execução do projeto. O importante é que a descrição seja, sempre que
possível, para o momento vivido pelo time do projeto, a mais fiel em relação às descrições do
produto, serviço ou resultado a ser gerado. Isso ocorre porque o escopo do projeto é seguidamente
descrito com mais detalhes, conforme novas informações a respeito do projeto são trazidas a bordo.
Por fim, obviamente, o time do projeto não pode se esquecer de levar em consideração os
fatores ambientais da empresa – cultura organizacional, estrutura da empresa, níveis de tecnologia,
administração de pessoal, condições de mercado etc. – e os ativos de processos organizacionais,
representados por políticas, procedimentos e templates pré-validados para a confecção de uma DE,
documentação arquivada de projetos anteriores ou de projetos similares de outras organizações e
lições aprendidas, entre outros.
Em suma, uma especificação do escopo do projeto, que pode ser idealizada por meio de uma
DE, é um artefato que trará a descrição do escopo do projeto bem como as suas principais entregas,
já visando ao processo de confecção de uma futura EAP, premissas e restrições do escopo, e não de
todo o projeto, pois estas ficam alocadas nos registros de premissas e no registro de restrições. Além
disso, é de bom tom que contenha as exclusões ao escopo – o não escopo do projeto –, que propiciam
resguardar o time do projeto no gerenciamento de algumas das principais partes interessadas.

69
 Para ilustrar melhor a questão das exclusões no escopo, existem termos que são comuns a
determinados segmentos ou profissões e que podem ser interpretados de diferentes maneiras, por
diferentes pessoas. Em um recente caso real de um projeto, uma empresa, indo avaliar a entrega da
construção de um galpão, e os seus funcionários foram dotados de uma lista de verificação – checklist
– para avaliarem o encerramento da obra, ou seja, o produto final do projeto. Em um determinado
momento, um dos representantes da empresa perguntou onde estava o lançamento do sistema
hidráulico do galpão, assim como outros detalhes, como o sistema de água e esgoto. Então, o
responsável pela obra correu às especificações que tinha em mãos e apontou para o termo
infraestrutura básica. Sim, eles eram responsáveis por entregar a obra do galpão com a infraestrutura
básica pronta. No entanto, na sua maneira de ver o mundo, o termo infraestrutura básica dizia a
respeito de piso, pilares, cobertura, canteiro de obra etc., mas nunca sistemas hidráulicos e afins.
O curioso é que depois de presenciar essa situação, comumente, pergunto a engenheiros civis e
outros profissionais que vivenciam diferentes cenários de obras, o que pode ser considerado como
infraestrutura básica típica de uma obra. Não há qualquer tipo de surpresa em verificar que, nos seus
entendimentos, a resposta é sempre bem variada e não há um senso comum, apenas em situações em
que exista algum tipo de documentação na qual esse grau de detalhe esteja expressamente
discriminado. Ou seja, é possível que uma equipe de projeto não esteja preparada para diferentes
interpretações acerca de um mesmo requisito. Para isso, a saída é sempre determinar as exclusões ao
escopo, que, no exemplo, poderiam estar explicitamente descritas como os sistemas hidráulicos e o
que mais não julgassem características do termo infraestrutura básica de uma obra daquele nível.
Como não bastasse, ainda existe o problema de que muitos bons profissionais confundem,
no dia a dia do projeto, a exclusão do escopo com a restrição de escopo. Cuidado, pois elas são
completamente distintas! Quando alguém disser que está proibido para o time do projeto
trabalhar após um determinado horário, por qualquer que seja o motivo, isso deverá ser tratado
como uma restrição e não como uma exclusão. Tudo aquilo que lhe é imposto por terceiros,
deve ser verificado como restrição.
Trabalhar corretamente as exclusões do escopo permitirá ao time do projeto estar atento
para melhor avaliar solicitações de mudança ou trabalhos adicionais, pois será possível verificar se
itens, frutos dessa análise, estarão contidos na linha de base do escopo ou se serão considerados
externos aos limites do projeto.
A versão mais simples e eficaz de uma declaração do escopo passa a ser, então, segundo o
próprio PMI (2017a) a define, conforme o template demonstrado para especificação do escopo do
projeto, proposto na próxima figura. Além do trabalho avaliado para efetivar as ações de entrega do
produto, serviço ou resultado a ser gerado pelo projeto, é natural que ocorra uma descrição do
escopo do produto, pois detalhes inerentes às suas características precisarão ser retratados. É uma
consequência da utilização da documentação dos requisitos na elaboração da DE.

70
 Figura 15 – Template de declaração do escopo

Fonte: elaborada pelo autor.

Em relação ao conceito de entrega, o Guia PMBOK® (2017a, p. 744) diz que se define como
“[...] qualquer produto, resultado ou capacidade de realizar um serviço, que seja único, verificável
e necessário para concluir um processo, fase ou projeto”. Fica a cargo do time do projeto ou da
situação em que o projeto ocorre definir se essas entregas serão descritas de maneira detalhada ou
sucinta. Já os critérios de aceitação são a maneira como a área de escopo conseguirá avaliar se as
entregas têm condições para serem recebidas, aceitas. Além disso, como já bem dimensionado nos
parágrafos anteriores, significa definir o não escopo, ou seja, aquilo que não faz parte do projeto.

Estrutura Analítica do Projeto – EAP

A Estrutura Analítica do Projeto (EAP) é o artefato que define o trabalho que será
necessário para que os objetivos do projeto possam ser cumpridos, assim como a base de referência
que provê as principais informações para gerenciar o trabalho do projeto, do início até a sua
conclusão, servindo como fonte primária de métricas em relação ao escopo, além de instrumento
de comunicação entre as principais partes interessadas.
Por isso, as estimativas de trabalho do escopo de um projeto são melhor percebidas quando
gerenciadas de uma maneira visual e decomposta, demonstrando uma estrutura única de elementos
encadeados, que posteriormente farão a comunicação com as demais temáticas do projeto, como
cronograma, qualidade, custos, aquisições etc. A EAP consiste em uma estrutura hierárquica, não
necessariamente cronológica – essa cronologia será visualizada no cronograma do projeto e não na
EAP –, decomposta e com a intenção de guiar o time do projeto à execução do trabalho necessário
para que os objetivos estipulados possam ser cumpridos fielmente.

71
 Ela não só servirá de linha de base para o trabalho do time do projeto em relação ao
escopo, pois representará as informações disponibilizadas por meio da DE e de toda a
documentação dos requisitos, como também auxiliará em um melhor trabalho de estimativa
dos esforços do planejamento do projeto como um todo. Isso ocorrerá quando as informações
começarem a ser integradas com os demais temas, por exemplo, com as informações a respeito
dos custos e da qualidade.
A EAP é um instrumento que possui a tarefa de orientar todo o planejamento do projeto,
desde a elaboração da sua primeira versão. Exatamente por isso, mudanças na linha de base de
escopo tendem a infligir impactos nos trabalhos de muitas outras áreas de um projeto. Sempre que
houver qualquer tipo de mudança na EAP, há a chance de refletir potenciais impactos na qualidade
ou em recursos, por exemplo.
Um correto trabalho de decomposição é de suma importância, pois é muito mais fácil, por
exemplo, estimar os custos da reforma de um cômodo de uma casa do que de uma casa inteira.
Sendo assim, a EAP deverá incluir todo o trabalho a ser realizado no projeto, independentemente
de o trabalho ser realizado pelo time do projeto, pelas partes interessadas ou por participantes
internos ou externos, como membros de outros setores da organização ou subcontratados.
Na próxima figura é possível visualizar um modelo simples de como é realizada a decomposição
hierárquica de uma EAP. A estrutura é decomposta em níveis, cada vez menores, e os últimos níveis
serão conhecidos como pacotes de trabalho. Um pacote de trabalho poderá ser agendado, estimado –
nível de esforço, custos, entre outras possibilidades –, monitorado e controlado.
Para o time de escopo do projeto, o trabalho acaba na descrição dos pacotes de trabalho, mas
na verdade ainda existem informações que precisarão ser complementadas pelo time de cronograma
do projeto. Quando se alcança um último nível em uma EAP, o time de cronograma do projeto
precisa estimar as atividades (ou tarefas) inerentes à realização desse pacote de trabalho, com novas
estimativas de esforço e cronologia própria, sempre alinhadas ao trabalho inicial de decomposição
das entregas, preconizado pelo planejamento da linha de base do escopo do projeto.
O número de níveis exigidos por uma EAP dependerá do tamanho e do grau de
complexidade do projeto e do nível de detalhamento necessário para o seu planejamento e o seu
futuro gerenciamento. Em suma, o número de níveis deve ser apropriado ao gerenciamento
efetivo do projeto em questão.

72
 Figura 16 – Níveis de uma EAP

Fonte: elaborado pelo autor.

Segundo o PMI (2017a), uma EAP poderá ser confeccionada por meio de diferentes
abordagens. As mais utilizadas seriam a abordagem descendente (top-down) em que o processo de
decomposição depende da quebra de um item – pai – para verificar como os seus respectivos
componentes – filhos – serão tratados. Há também a abordagem ascendente (bottom-up), que é
comumente utilizada quando o processo é realizado com o raciocínio invertido, agrupando-se
subcomponentes. O elemento pai precisará corresponder às exatas junções de todos os subelementos
filhos. Não é difícil verificar, por exemplo, uma EAP que seja confeccionada por meio de uma
abordagem top-down e revisada por meio de uma abordagem bottom-up, ou o contrário.
Dificilmente uma EAP não passará por um trabalho de revisão ao longo do projeto, não só
por causa das muitas variáveis que assolam um projeto ao longo da sua realização, mas também
porque nem sempre todas as informações estarão disponíveis ou serão totalmente conhecidas do
time do projeto no momento da sua idealização. Portanto, de tempos em tempos, rever a estrutura
da EAP e avaliar o que pode ser alterado em prol de um melhor trabalho da equipe do projeto é
considerado, por muitos, uma boa prática.
Na verdade, uma EAP pode ser confeccionada de muitas maneiras e com diferentes tipos de
abordagens, que no final acabarão representando a mesma coisa, mas em formatos diferentes. O PMI
(2006) cita, por exemplo, a possibilidade de utilização de modelos gráficos, textuais ou tabulares.
Um exemplo de modelo gráfico, que é um dos mais conhecidos no mercado, seria o modelo
piramidal ou em blocos, representado por figuras em formato de retângulos que, sempre que
necessário, decompõem-se e formam os níveis subsequentes, proporcionando uma base sempre
maior que o topo, por isso a analogia com o formato de uma pirâmide.

73
 Figura 17 – Exemplo de EAP gráfica piramidal

Fonte: adaptado de XAVIER (2009).

Um modelo de mapa mental também se demonstra uma excelente maneira de desenvolver

uma EAP gráfica, conforme apresentado na próxima figura. Com um formato de fácil utilização
(com bons aplicativos/softwares gratuitos para auxiliar), pode ser uma excelente proposta de trabalho
colaborativo para o time do projeto, desde o início dos primeiros movimentos do planejamento do
escopo. O importante é que, assim como o formato gráfico piramidal, seja possível a visualização
decomposta e hierárquica de todas as entregas que visam à realização do trabalho para alcançar os
objetivos do projeto.

Figura 18 – Exemplo de EAP gráfica em mapa mental

Fonte: RIBEIRO (s. d.).

74
 Em relação ao modelo textual, poderíamos utilizar a EAP da figura anterior e transformá-la
no seguinte formato:

Figura 19 – Exemplo de EAP textual

1. projeto novas fronteiras

1.1. diagnóstico
1.2. software
1.2.1. sistema operacional
1.2.2. banco de dados
1.2.3. gerenciamento de projetos
1.2.4. gerenciamento eletrônico de documentos (GED)
1.2.5. teste integrado
1.3. hardware
1.3.1. servidor
1.3.2. clientes/usuários
1.4. treinamento
1.4.1. palestra
1.4.2. treinamento GP
1.4.3. treinamento software
1.5. padronização
1.5.1. templates (modelos)
1.5.2. GED
1.5.3. relatórios
1.5.4. modos de exibição
1.6. piloto
1.6.1. definição projeto-piloto
1.6.2. planejamento projeto-piloto
1.6.3. execução e avaliação projeto-piloto
1.6.4. ações corretivas
1.7. resultados

Fonte: elaborada pelo autor.

Por fim, o mesmo exemplo, se confeccionado em um modelo tabular ou no formato de uma

planilha (de Excel, por exemplo), estaria representado como no quadro a seguir:

75
 Quadro 7 – Exemplo de EAP tabular (ou planilha)

nível 1 nível 2 nível 3

1. projeto novas fronteiras

1.1. diagnóstico

1.2. software

1.2.1. sistema operacional

1.2.2. banco de dados

1.2.3. gerenciamento de projetos

1.2.4. gerenciamento eletrônico de documentos (GED)

1.2.5. teste integrado

1.3. hardware

1.3.1. servidor

1.3.2. clientes/usuários

1.4. treinamento

1.4.1. palestra

1.4.2. treinamento GP

1.4.3. treinamento software

1.5. padronização

1.5.1. templates (modelos)

1.5.2. GED

1.5.3. relatórios

1.5.4. modos de exibição

1.6. piloto

1.6.1. definição projeto-piloto

1.6.2. planejamento projeto-piloto

1.6.3. execução e avaliação projeto-piloto

1.6.4. ações corretivas

1.7. resultados

Fonte: elaborado pelo autor.

76
 Além disso, como os trabalhos de gerenciamento do escopo têm uma ligação muito próxima
com os trabalhos de gerenciamento da qualidade, existem ainda dois princípios de qualidade que
uma EAP precisa conter. Isso ocorre porque, ao planejar e desenvolver o que precisa ser feito para
alcançar os objetivos do projeto e, futuramente, garantir os critérios de aceitação, quando
necessários, estamos tratando do trabalho da equipe do escopo. Porém, a equipe da qualidade será
responsável pelos critérios de validação, ou seja, dizer que as entregas foram validadas ou, ainda,
que os requisitos documentados desde o momento de coletar os requisitos alcançaram a precisão
desejada por meio do atingimento das suas métricas. Somente depois que a área da qualidade definir
que uma entrega foi validada é que a área de escopo poderá, formalmente, promover a entrega total
ou parcial de um produto, serviço ou resultado.
O primeiro princípio da qualidade de uma EAP diz que “[...] uma EAP de qualidade é uma
EAP construída de tal forma que satisfaça todos os requisitos para o seu uso em um projeto”
(PMI, 2006, p. 19, tradução e grifo do autor). Para que um projeto atenda às necessidades do seu
cliente ou de um usuário final, assim como às expectativas dos seus principais stakeholders, é
importante que tenha sido realizado um bom trabalho de elicitação de requisitos, no intuito de
refletir em uma EAP a importância destes. Quando o trabalho descrito na EAP for de fato
implantado, devem existir condições de mensurar, avaliar, testar e controlar uma entrega, para que
se reflita se os requisitos inerentes a essa entrega foram, ou serão, devidamente atendidos, da maneira
como foram elicitados.
Já o segundo princípio da qualidade de uma EAP diz que “[...] as características de qualidade
de uma EAP aplicam-se a todos os níveis de definição do escopo” (PMI, 2006, p. 22, tradução e
grifo do autor). Significa dizer que não há qualquer tipo de diferença conceitual, por exemplo, entre
a EAP de um projeto ou a EAP de um portfólio. Uma EAP de qualidade será elaborada, dentro dos
mesmos preceitos e técnicas, para garantir que as mesmas características e atributos necessários à
idealização do trabalho do projeto – ou, no caso da comparação, do portfólio – sejam implantados.

Dicionário da EAP
Sobre o dicionário da EAP, podemos afirmar que:

O dicionário da EAP é um documento que fornece informações detalhadas

sobre entregas, atividades e agendamento de cada componente da EAP. O
dicionário da EAP é um documento que dá suporte à mesma. A maioria das
informações incluídas no dicionário da EAP é criada por outros processos e
adicionadas a este documento em um estágio posterior (PMI, 2017a, p. 198).

77
 O dicionário da EAP é um documento complementar à EAP. Esta, pela sua essência, precisa
ser clara e concisa, abordando uma macrovisão das entregas do projeto, no intuito de auxiliar o
trabalho do time de gerenciamento do escopo do projeto. No entanto, o dicionário deverá descrever
todos os detalhes inerentes a cada item da EAP. Para cada item, haverá uma potencial descrição
para uma declaração de trabalho resumida ou, ainda, uma definição do escopo daquele
componente, entre muitas outras informações possíveis.

Quadro 8 – Exemplo de um trecho de um dicionário da EAP preenchido

nível de
código item da EAP descrição critério(s) de validação
esforço

 Cobrir todos os
 Treinamento presencial
procedimentos da
para toda a equipe do
metodologia proposta
projeto sobre plano de
pela norma interna
emergência contra
nº 023/2019.
incêndios a fim de cumprir
 A turma deverá ter
norma interna nº 023/2019.
presença mínima de
O instrutor será o GP.
80% da equipe do
 Não há necessidade de
projeto.
roupas específicas.
 A participação no
 Realização na sede da
treinamento deverá
empresa, sala 808, das 8h
ser confirmada pelo
às 18h, com intervalo de
ramal 4548, com até
uma hora para almoço, na
72 horas da data
treinamento primeira segunda-feira do
1.2.1.4.3 prevista para a sua 9 horas
da equipe mês de outubro do
realização.
corrente ano.
 A avaliação do
 Será realizado um coffee
treinamento (1.2.1.4.6)
break (1.2.1.4.5) na parte da
não poderá ter média
manhã e um na parte da
inferior a 8,0, sob pena
tarde. Cada um, com
de repetição.
duração de 15 minutos.
 O controle de
Horário do intervalo a
frequência será
critério do instrutor.
obrigatório (1.2.1.4.8.
 Material didático (1.2.1.4.4.)
e 1.2.1.4.9).
será fornecido no dia da
 A avaliação dos alunos
aula.
(1.2.1.7) não pode ser
 Haverá entrega de
inferior a 7,0, sob pena
certificados (1.2.1.4.9.).
de reprovação.
Fonte: elaborado pelo autor.

78
 Enquanto a confecção de uma EAP visa ao mapeamento, de maneira gráfica, dos
componentes de um escopo do produto, no dicionário da EAP, o objetivo é descrever
detalhadamente expectativas, estabelecer critérios de medição (até mesmo indicadores) e definir
responsabilidades. Por vezes, associam-se detalhes, como estimativas de custos, recursos ou
esforços/duração. Portanto, quando for o caso e de acordo com o grau de complexidade das
informações do projeto, deve ser definida, para cada item da EAP, uma possível lista de atividades
ou marcos da implantação do componente, responsabilidades, estimativas de esforço de cronograma
– em alguns casos, períodos de início/término –, estimativas de recursos, custos, número
identificador associado ao item da EAP, informações contratuais, requisitos da qualidade, critérios
de aceitação, referências técnicas, premissas e restrições, entre muitas outras informações possíveis.
O dicionário da EAP funciona realmente como um dicionário, pois a intenção é que cada
verbete referencie um pacote de planejamento ou de trabalho (algumas versões mais enxutas
trabalham apenas com pacotes de trabalho), promovendo um melhor grau de compreensão para
todas as principais partes interessadas naquilo que será desenvolvido pela equipe do projeto.

Scope creep
Utilizar corretamente uma linha de base do escopo vai permitir ao time do projeto evitar uma
prática comumente conhecida no mercado como scope creep. Em tradução literal, seria algo similar
ao termo escopo assustador. Isso ocorre quando há uma descontrolada expansão do escopo do projeto
ou do escopo do produto, na maioria das vezes não autorizada pelas principais partes interessadas,
desencadeando uma série de efeitos não previstos sobre as demais temáticas do projeto, como por
exemplo, recursos, cronograma e custos. Dentre muitas ações que podem reduzir a probabilidade
de ocorrências de um possível scope creep, gerenciar de perto as exclusões ao escopo do projeto – ou
seja, o não escopo do projeto – é uma prática cada vez mis utilizada por times de projetos.
Entre muitos problemas que podem, potencialmente, desencadear o fenômeno do scope creep
em um projeto, os principais são:
 má definição do escopo ou um escopo em desalinho com a realidade, ou mesmo não refinado;
 ausência de um escopo formalizado ou de um gerenciamento dos requisitos para o projeto;
 processos inconsistentes para coletar os requisitos do produto;
 baixo grau de engajamento das principais partes interessadas (por exemplo, falta de
patrocínio) e
 projeto com cronograma muito extenso.

79
 Figura 20 – Scope creep

Fonte: elaborada pelo autor.

Trabalhar em entregas não aprovadas de um projeto pode levar uma equipe a dedicar esforços
a alterações não autorizadas com potencialidade de não agregar valor ao cliente ou usuário final do
produto, serviço ou resultado que será gerado pelo projeto.
Duas coisas podem ocorrer com a prática do scope creep: desalinho completo com
potencialidade para gerar atrasos de cronograma; despertar novos riscos, anomalias no controle dos
custos – em decorrência de trabalhar em partes não autorizadas sem a certeza de que elas serão
incorporadas ao trabalho do projeto –; ou, desenvolver um produto, serviço ou resultado final
completamente diferente daquilo que foi originalmente previsto, sem um histórico de controle de
mudanças que justifique essas ações.

80
Retrospectiva do módulo
O módulo IV demonstrou como desenvolver e integrar um planejamento do escopo do
projeto com o trabalho realizado pela equipe do projeto em função do gerenciamento dos
requisitos. Foi apresentado o modelo de planejamento dos anéis de cebola, demonstrando uma
profundidade de planejamento em até cinco níveis, sendo que alguns tipos de projeto chegam,
no máximo a três. O planejamento tem uma visão macro (e pelo ponto de vista da equipe do
projeto, mais superficial) e alinha-se de acordo com as necessidades do produto, serviço ou
resultado que está sendo desenvolvido, assim como a escolha da abordagem utilizada pelo time
do projeto/organização, sendo que, quanto mais interna é a camada da cebola, maior é o nível de
detalhes a serem trabalhados no escopo.
Na sequência, tratamos do conceito de linha de base, notadamente vinculado ao escopo do
projeto, permitindo um grau de planejamento completo para que as referências possam ser
acompanhadas, discutidas, avaliadas e adaptadas, sempre que a necessidade dos trabalhos assim
demandar. Uma linha de base do escopo é, tradicionalmente, constituída de uma especificação do
escopo do projeto (e do produto) – aqui, descrevemos e apresentamos como sugestão o template de
uma Declaração do Escopo – de uma EAP e os seus componentes, que norteiam os trabalhos
naquilo que precisa ser entregue/realizado pela equipe do projeto, objetivando as aceitações das
entregas do projeto perante as principais partes interessadas.
Ao iniciarmos os estudos da criação de uma EAP, descrevemos inicialmente algumas
definições importantes – por exemplo, pacotes de trabalho, níveis de uma EAP e princípios da
qualidade de uma EAP – para então demonstrar os principais tipos de confecção de uma EAP.
Ainda pudemos demonstrar que uma linha de base do escopo de um projeto, quando
corretamente dimensionada, é constituída da DE, uma EAP contendo os pacotes de trabalho e de
planejamento, assim como de um dicionário da EAP (cuja confecção também foi demonstrada).
Utilizar corretamente uma linha de base do escopo significa mitigar problemas em relação às
entregas de um projeto e os seus impactos em relação às demais áreas de conhecimento do projeto,
bem como evitar uma prática conhecida como scope creep, tendo, por fim, as suas mazelas expostas.

81
MÓDULO V – PLANEJAMENTO DA
QUALIDADE

O módulo V nos fornece todas as informações necessárias para um correto trabalho de

planejamento da qualidade de um projeto. Em um momento em que o time do projeto ainda vive
muitas incertezas, o plano de gerenciamento da qualidade surge como uma espécie de guia para os
futuros trabalhos de execução do projeto. Esse planejamento visa a servir de referência para que a
atividade da qualidade do projeto seja aderente às políticas e aos padrões da qualidade da
organização detentora do projeto, assim como, em muitos casos, também aderente às solicitações
dos responsáveis pelo pedido do produto, serviço ou resultado a ser gerado.
Antes de tudo, conheceremos três conceitos fundamentais para os trabalhos da qualidade,
derivados do modelo Toyota de gestão: Kaizen, Kaikaku e Kakushin. O primeiro visa à melhoria
contínua, o segundo visa à mudança e o terceiro visa à quebra de paradigmas. Todos são
amparados por sólidas filosofias e modelos mentais com potencial para sustentar verdadeiras
transformações em estruturas organizacionais, com impactos significativos em intangíveis, por
exemplo, a cultura organizacional. Trataremos também da identificação do trabalho da
qualidade com os métodos ágeis (ou híbridos), haja vista o constante processo de verificação e
validação ao final de cada ciclo iterativo, facilitando a aproximação do processo de gestão do
conhecimento e da cultura de aprendizagem com o estudo das falhas cometidas. Verificaremos,
também, algumas das principais técnicas e ferramentas preconizadas pela metodologia proposta
pelo PMI (2017a), culminando com alguns dos principais artefatos da qualidade vinculados ao
momento do planejamento, que são essencialmente o plano de gerenciamento da qualidade
(PGQ) e as informações sobre as métricas da qualidade.
Os três Ks: Kaizen, Kaikaku e Kakushin
Kaizen, em tradução literal, significa mudança (Kai) e para melhor (Zen). Em muitas
adaptações sofridas por esse conceito-filosofia, é possível verificar a sua aplicação atual algo como
um tipo de melhoria gradual ou aperfeiçoamento constante. Traduzido pela expressão fazer o hoje
melhor do que o ontem, muitos são os ambientes de negócio que adaptam os seus valores e as suas
práticas organizacionais para a implementação de um way of life (ou estilo de vida – às vezes um
modus operandi) que encoraja mudanças incrementais e contínuas, iniciando por aspectos
profissionais, mas que podem produzir profundas influências no ambiente pessoal, social e familiar.
Eu mesmo costumava cobrar muito de times de projetos que pensassem com o propósito da
melhoria contínua. Fazíamos treinamentos, trabalhávamos a comunicação, incentivávamos ideias,
mas a impressão era que sempre que a pressão por melhoria contínua arrefecia, os esforços da equipe
também minguavam e o status quo retornava. Era algo que, enquanto nos esforçávamos para
enxergar e praticar, conseguia produzir efeitos sustentáveis e situações extremamente agradáveis. No
entanto, para a minha surpresa, naturalmente, isso desaparecia com o tempo, mesmo com a
aplicação de práticas tidas como sucesso que agradavam a todos. Aquilo me intrigava
profundamente, pois, como não perpetuar comportamentos bons de uma maneira natural? Será
que o ser humano precisa ser lembrado constantemente para fazer coisas melhores? Então, reparei
que não adiantava acreditar que eu praticava a melhoria contínua no trabalho, se, na minha vida
pessoal/familiar, isso não se refletia da mesma forma. Para ser algo natural, é necessário que a
melhoria contínua faça parte de você, como uma filosofia. E talvez eu tenha aprendido isso de uma
forma muito dura, pois, quando meus filhos nasceram – sou pai de gêmeos –, os dois ficaram por
um longo período na UTI neonatal. Um deles, durante um período de sessenta dias, passou por
três cirurgias (a primeira logo nos primeiros dias de vida e em condições bem desfavoráveis). Logo
após a primeira cirurgia, quando ele estava se recuperando em um estado de coma induzido
(adormecido, segundo a gentil equipe técnica do hospital) e ainda não havia sequer tido a chance
de segurá-lo no colo, eu estava completamente imbuído de fazer tudo dar certo e respeitar
procedimentos hospitalares, mas, ao mesmo tempo, sentia uma necessidade imensa de ter um dia
melhor do que o anterior. A partir do momento que pude compreender melhor a situação e
evidenciar os ganhos de um longo processo de recuperação, sempre que eu chegava ao hospital para
visitá-lo, perguntava qual era a evolução do quadro clínico (eu buscava qualquer coisa que pudesse
evidenciar avanços e trazer boas notícias) e, em relação ao meu relacionamento com ele, perguntava
o que eu podia fazer. Certo dia, a enfermeira-chefe me disse que eu poderia sentar ao lado da
incubadora e conversar com ele, pois ele reconheceria a minha voz e isso o acalmaria. No dia
seguinte, quando ela me disse para fazer isso novamente, eu comentei que sim, mas queria fazer
algo mais... afinal de contas, isso foi o que eu fiz ontem, hoje eu queria fazer algo especial, diferente,
sempre visando a um processo de melhoria contínua. Não preciso nem dizer que esse longo período
me marcou profundamente, não só como ser humano, mas como profissional, pois hoje eu enxergo

84
processos de melhoria contínua de uma maneira completamente diferente. Apenas finalizando, para
que não existam dúvidas, meu filho, hoje, é uma criança saudável e dono de uma energia infindável,
como toda criança deve ser.
Para que exista uma melhoria contínua em todas as áreas de uma organização, a filosofia de
trabalho do Kaizen deve ser implementada desde pequenos detalhes até grandes avanços, para o bem
de todos que são influenciados por processos e resultados daquele sistema. Mas, basicamente,
podemos dividir o Kaizen em manutenção e melhoramento. O primeiro, define regras que auxiliam a
manter níveis de performance estratégicos, estipulados pela alta direção, e por padrões de execução de
processos ou operações. Já o segundo significa um esforço para a melhoria de padrões/processos
existentes ou incentivo à inovação, para abandonar padrões/processos obsoletos. Em times de
projetos, estamos diante de um fator crítico de sucesso, pois melhorias contínuas reforçam o
compromisso das pessoas com uma estratégia abrangente para todo o negócio, revelando uma melhor
disposição para influenciar o clima organizacional e deixar o trabalho da equipe muito mais agradável.

Figura 21 – Os três Ks

Fonte: QUALITYWAY WORDPRESS (s. d.).

Equipes da qualidade (e de lean thinking) trabalham o conceito de Kaizen essencialmente como

a ideia de melhoria contínua e, em muitos casos, até como um princípio de trabalho, com o propósito
de influenciar pessoas no sentido de incutir o modelo mental desejado para a realização de melhorias
sem grandes esforços, afinal de contas, a partir do momento que algo passa a ser tão natural para

85
alguém, estranho seria deixar de fazê-lo. Uma mentalidade Kaizen bem trabalhada é incremental e
viabiliza processos consistentemente melhores, perpetuando um ciclo virtuoso, indispensável ao
modus operandi de qualquer time de projeto, independentemente do tipo de segmento.
Muitos são os métodos de implementação do Kaizen e de busca de um padrão de adequação
contínuo ao conceito, desde observar como melhorar ações em relação aos 3Ms (mura, muda, muri
– vistos no módulo II), que por si sós resolverão problemas como subutilização (ou sobreutilização)
de recursos, esperas desnecessárias, defeitos/falhas e trabalhos extras, entre muitos outros possíveis
fatores, como também demonstrar insatisfação com zonas de conforto ou processos que são
realizados sempre da mesma forma, repetidas vezes. Certa vez, perguntei ao integrante de uma
equipe o porquê de ele entregar um relatório em determinado formato. Eu tinha plena consciência
que a resposta seria dolorosa (de fato foi): “Porque sempre fazemos isso desse jeito”. Inconformado
com tal comodismo, foi exatamente nesse dia que surgiu o roteiro apresentado na próxima figura,
sugerindo que primeiro haja a seleção de um processo, como escrever o relatório XPTO. Estude
como esse relatório foi realizado ao longo de um determinado período de tempo, reconheça as suas
nuances e as suas dependências, para então documentá-las. Converse com todos que, de alguma
forma, contribuam para que o processo seja executado. Depois, de preferência, de maneira
colaborativa, apresente o problema para o grupo: “Temos um relatório ineficiente que é realizado
sempre da mesma maneira”. Questões que precisam ser respondidas:
a) As informações provenientes desse relatório são necessárias/essenciais?
b) Se são necessárias, o documento pode ser substituído por algum método mais eficaz?
c) Se não puder ser substituído, como reduzir o tempo de confecção, envolver menos
recursos ou melhorá-lo, deixando o resultado mais atraente?

Pronto! O time passa a ter um processo novo apto a ser testado e com a possibilidade de
receber feedbacks das principais partes interessadas. Funcionou? Reflita sobre as causas e continue
dessa forma. Não funcionou? Reflita e tente resolver o problema com uma abordagem alternativa.
Registre os resultados para gerar uma base de gestão do conhecimento da sua equipe, que
potencialmente poderá ser transmitida a outros setores da organização ou a outros times que
enfrentam problemas semelhantes. Depois de certificar-se de que o processo novo está melhor que
o antigo, comece a provocá-lo novamente, repetindo o roteiro Kaizen visando sempre à qualificação
de pessoas e à imposição/manutenção de uma cultura de melhoria contínua.

86
 Figura 22 – Kaizen na teoria

Fonte: elaborada pelo autor.

Um exemplo simples de Kaizen (que também demonstra uma outra técnica de qualidade
conhecida como poka-yoke, funcionando como um dispositivo visual ou mecânico à prova de erros)
em serviços pode ser visualizado na próxima figura. Em lojas de aeroportos é comum a frequência de
muitas pessoas, no entanto, caracterizadas em três tipos: a) pessoas em trânsito, sem intenção de
compras; b) pessoas com intenção de compras, mas práticas ou sem tempo a perder; e c) pessoas com
intenção de compras, que podem, eventualmente, precisar de algum tipo de assistência dos
vendedores. A empresa que administra as lojas de duty free (que vendem produtos sem a incidência
de determinados impostos) em um determinado aeroporto, criou um sistema visual, à prova de falhas,
que veio a corrigir um problema clássico de má alocação da força de vendas para auxílio nas compras
dos clientes. Eram comuns reclamações de ausência de vendedores, ou ainda, de atenções demasiadas
a frequentadores que gostariam de privacidade no momento das compras. Após mapearem os
processos de vendas e, visando a evitar esforços desnecessários dos vendedores, a empresa
implementou um sistema de cores nas suas cestas de compras, com um roteiro explicativo e simples
logo na entrada da loja. A cesta na cor vermelha atende ao consumidor que pode necessitar de algum
tipo de ajuda. Ela fica na entrada da loja, com os dizeres: “Eu gostaria de ser atendido/assistido”. A
cesta preta serve aos consumidores práticos, que já sabem o que desejam ou não dispõem de tanto
tempo assim, e querem pegar os seus produtos, pagar e seguir viagem. Ela é acompanhada dos dizeres:
“Eu gostaria de comprar por conta própria”. Quem não utilizar qualquer tipo de cesta será

87
considerado apenas um passageiro em trânsito e, portanto, sem a intenção de adquirir produtos. A
partir do momento em que o código de cores das cestas foi implementado, todos os vendedores da
loja possuem um código de conduta para otimizar esforços e oferecer atenção apenas ao cliente
portador da cesta vermelha, a não ser que ela seja solicitada de outra maneira explícita.

Figura 23 – Kaizen na prática

Fonte: acervo do autor.

Quando estamos diante de desafios que impliquem a aplicação de ferramentas ou de métodos

(5S, por exemplo) para disciplinar pessoas a terem uma melhor consciência de utilização de um
determinado recurso ou aproveitar melhor a eficiência de um processo, a saída é implementar o
Kaizen. No entanto, quando desenvolvemos novas tecnologias ou materiais novos para substituir
uma ação ou adaptar um processo, com viés de transformação, ou seja, não simplesmente
melhorando aquilo que se tinha, mas revolucionando e transformando por completo o modelo
anterior para uma nova maneira de desenvolver algo, estamos então diante de Kaikaku, que em
tradução literal, significa mudança (Kai) e radical ou revolucionária (Kaku). Reduzir o tempo de
uma reunião de controle diária com a equipe do projeto por desenvolver uma nova técnica de
facilitação com o grupo é aplicar o Kaizen, mas realizar o mesmo propósito dessa reunião de uma
maneira diferente, impactando em mudança de cultura e de hábitos de trabalho que influenciam
em grande escala, é aplicar o Kaikaku. Tive a oportunidade de presenciar esse tipo de modelo mental
em equipes auto-organizáveis e é algo realmente surpreendente.

88
 É normal que a aplicação do Kaizen evolua e, em um determinado momento, chegue a um
ponto de estagnação. Ou seja, pequenas mudanças evolutivas deixam de ser significativas e o esforço
da equipe em implementar essas melhorias já não justifica mais o trabalho em prol de tentar
melhorar esse grau de eficiência, seja por meio do alcance de objetivos ou de necessidades
estratégicas. Sempre que o Kaizen chega em um limite no qual já não consegue mais ser eficaz, a
saída natural é rever as regras do jogo e inovar, provocando uma revolução conhecida como Kaikaku.
Quem acompanha corridas de automobilismo há alguns anos ou conhece o histórico da
modalidade, poderá lembrar que, na década de 1980, um pit stop (parada) de fórmula 1 para a troca
de pneus demorava, em média, algo como 20 segundos. Mais algumas décadas antes disso, chegava a
durar mais de 1 minuto. No entanto, em novembro de 2013, a equipe Red Bull Racing foi a primeira
a conseguir quebrar a barreira dos 2 segundos, realizando a troca de pneus do carro pilotado por Mark
Webber, durante uma corrida nos Estados Unidos, contando um intervalo de 1,923 segundos. Não
foi só o processo da troca de pneus que evoluiu (Kaizen), mas outros detalhes (Kaikaku) como tipos
de materiais que permitiram a utilização de um único pino para prender uma roda (em vez de quatro),
tecnologia de ferramentas, número de pessoas envolvidas (três para cada roda), regras da modalidade
desportiva, entre outros detalhes que permitiram uma mudança completamente diferente da forma
como as equipes conheciam e desenvolviam tal processo no passado. São movimentos que,
normalmente, geram forte intensidade de energia e aprendizado com elevado impacto de resultados,
propiciando a utilização de novas técnicas, conhecimentos e recursos.
E quando tudo parece estar às mil maravilhas, afinal de contas, quebram-se barreiras tático-
operacionais e equipes acabam passando por mudanças extraordinárias, ainda é possível um novo
nível de mudança, conhecido como Kakushin. Kaku já sabemos que significa radical ou revolucionário,
que agora junta-se a Shin que significa novo(a). Sendo assim, a palavra Kakushin remete a inovação,
renovação, ou ainda a uma inovação radical, para sermos mais atentos ao espírito da mensagem
vinculada ao termo. O conceito de Kakushin é transformar organizações ou setores de organizações,
ou ainda, dependendo do grau de maturidade delas, a maneira de trabalhar de algumas equipes de
projetos, movendo-se de um status atual para um status futuro desejado. A revolução provocada pelo
Kakushin envolve uma gestão integrada de mudanças que modifique significativamente o modelo de
negócio (por exemplo, de cost driven – voltado para custos – para value driven – voltado para a entrega
de valor), normalmente influenciado por intangíveis (aprendizados, novos modelos mentais, culturas,
valores etc.) que propiciarão a transformação organizacional/cultural, revelando novas atitudes e
comportamentos. Um exemplo clássico e muito atual tem sido a transformação de organizações que
adotam modelos clássicos de gerenciamento de projetos para modelos lean/ágeis (ou híbridos),
revolucionando completamente a maneira de agir das pessoas, com adoção de novos princípios e
valores, que tendem a influenciar todo o sistema de fluxo de produtos, serviços ou resultados
desenvolvidos pelas equipes de projeto e os seus principais stakeholders.

89
 Quadro 9 – Quadro comparativo entre os 3 Ks

Critério KAIZEN KAIKAKU KAKUSHIN

realizar pequenas
gerar grandes ampla reformulação
Conteúdo melhorias
mudanças técnicas e transformação
incrementais

Ator principal times multifuncionais especialistas técnicos diretores e gerentes

aplicar novas
eliminar desperdícios introduzir uma
Foco principal tecnologias, técnicas,
nos processos inovação radical
materiais

introduzir saltos de romper um cenário

Justificativa melhoria contínua
produtividade de mercado

Os três Ks são conceitos que podem atuar conjunta ou separadamente, pois, mesmo que
estejamos tratando de um conceito vinculado a uma espécie de inovação radical (Kakushin), em
momento algum subentende-se que seja necessário abandonar os dois conceitos que precederam à
transformação, vinculados ao Kaizen e ao Kaikaku. A vantagem do Kaizen é a sua autonomia, pois a
partir do momento em que se desenha uma cultura (na equipe ou na organização) de esforços em
prol da melhoria contínua, a adaptação e a aplicabilidade para a implementação do Kaizen é
instantânea e produz efeitos imediatos – como times de projetos que apresentam um determinado
problema em uma reunião de retrospectiva e, de pronto, avaliam a situação e discutem uma solução
para aderir a um novo formato de processo ou para enxergar determinados detalhes. O Kaikaku
normalmente já é tema de projetos específicos, em que a necessidade ou a oportunidade passa a ser
materializada em observância aos objetivos de negócio e de estratégia, envolvendo muitos stakeholders
que podem ser afetados pela solução. Já o Kakushin são necessidades reais, muitas vezes de
subsistência, como a aceleração digital provocada pelo cenário pós-Covid19 em muitas organizações,
ou de oportunidades/estratégias de inovação, como o lançamento de um novo produto ou serviço,
por exemplo, a inovação do conceito de hospedagem proposto pelo surgimento do Airbnb.

Planejamento da qualidade
Assim como todo trabalho de planejamento, o da qualidade não poderia ser diferente e
demonstrará todas as regras para que o assunto qualidade seja gerenciado e verificado ao longo do
projeto, sem permitir que o assunto gere dúvidas para os principais interessados. É necessário que se
desenvolva um documento base que será tratado como a principal referência no assunto, denominado

90
Plano de Gerenciamento da Qualidade (PGQ), o qual, entre outras missões, deverá definir os padrões
desejados da qualidade, as métricas para a validação das principais entregas vinculadas ao escopo do
produto e do projeto, as condutas para a melhoria contínua de processos e de detalhes que influenciam
os principais stakeholders do projeto, assim como a designação de técnicas, rituais e ferramentas que
auxiliarão na verificação da qualidade ao longo de todo o ciclo de vida do projeto.
No início dos trabalhos de desenvolvimento de um PGQ, é desejável que a visão do produto,
serviço ou resultado a ser gerado já esteja determinada pela equipe do projeto. A necessidade de
existir uma visão geral do escopo (mesmo que ligeiramente detalhada) serve para suportar as
premissas de qualidade que advirão das expectativas levantadas com o cliente/usuário final. Segundo
Pitchler (2011, p. 26) “[...] ser capaz de antever como um novo produto ou a sua próxima versão
deve se parecer e se comportar é essencial para chegar lá. Esta antevisão resulta em um esboço do
produto futuro”. A visão do produto deve comunicar tal essência de uma maneira que facilite o
processo de criatividade da equipe. Estamos tratando da razão de ser do produto, serviço ou
resultado a ser gerado, portanto, quanto mais se conhecer sobre a proposta de execução nesse
momento, melhor será para sustentar os detalhes do planejamento da qualidade.
Para que o planejamento da qualidade tome forma, toda e qualquer informação do projeto
será bem-vinda. Contudo, nem sempre o grupo trabalhará com informações muito sólidas nesse
momento protagonizado pela equipe do projeto (ou equipe da qualidade) e, portanto, todas as
fontes primárias de informações, por exemplo, o termo de abertura do projeto ou as documentações
do escopo, serão tratadas como boas referências de informação, contanto que estejam atualizadas e
sejam confiáveis, pois podem concentrar não só detalhes pré-projeto mas também os demais
conhecimentos oficiais do projeto até o presente momento. Um plano geral para o gerenciamento
do projeto provavelmente ainda não está completamente terminado, mas independentemente do
que esteja pronto ou não, informações oriundas do trabalho da equipe com o levantamento, a
análise e a classificação dos requisitos, por exemplo, são fundamentais para que as métricas da
qualidade possam ser corretamente descritas. Não obstante, é importante que se avaliem também
todas as especificações constantes da linha de base do escopo, pois minúcias do escopo do produto
projetados na EAP (ou qualquer outra técnica destinada para descrever o escopo do produto), o seu
dicionário e os pormenores de documentos de especificação do escopo serão de suma importância
para que a necessidade da qualidade possa ser bem caracterizada, afinal de contas, todas as entregas
e os processos que tenham como objetivo uma revisão de qualidade estarão (ou deveriam estar)
elencados nesse compêndio de informações. Utilizar os critérios de aceitação definidos na linha de
base do escopo para definir muitos critérios de validação pode aumentar consideravelmente o custo
da qualidade do projeto. No entanto, o cumprimento de todos os critérios de validação significa
dizer que as principais partes interessadas ficarão satisfeitas com o bom andamento dos trabalhos
da qualidade. Exatamente por isso, um plano de engajamento das partes interessadas, caso exista,
pode representar uma excelente fonte de informações sobre como as necessidades e as expectativas
dos stakeholders precisam ser saciadas. Um plano de gerenciamento dos riscos também demonstra-

91
se uma peça importante, pois análises detalhadas dos riscos e avaliações dos impactos nos demais
planejamentos do projeto, como cronograma, custos, recursos, devem ser consideradas.
São muitas as ferramentas e as técnicas possíveis para que esse planejamento tome forma. É
comum ao Guia PMBOK® (PMI, 2017a) sempre discriminar uma série de opções para que os
processos da qualidade tenham êxito, mas é sempre importante lembrar que as técnicas e
ferramentas nunca estão limitadas àquelas demonstradas pela metodologia, ou seja, não há porque
prender-se à seleção aqui apresentada, podendo existir muitas outras maneiras de transformar as
informações recebidas como inputs em futuros entregáveis do projeto.
A primeira técnica é a opinião especializada, cujo conceito já vimos em outros processos (os de
escopo, por exemplo). Nesse caso, refere-se a qualquer tipo de conhecimento da qualidade
disseminado para a equipe do projeto, como medições, garantias, controles, melhorias ou sistemas de
qualidade. Na sequência, temos a técnica de coleta de dados, aqui aberta em benchmarking
(comparações práticas de padrões da qualidade ou melhores práticas, tanto de projetos internos como
externos à organização executora); brainstorming (técnica utilizada para gerar momentos de ideação e
criatividade, sem restrições, tanto com a equipe do projeto como com especialistas em determinados
assuntos, mesmo que externos); e, a técnica de entrevistas (forma pela qual as principias partes
interessadas podem vir a contribuir fornecendo informações sobre as necessidades e as expectativas da
qualidade para o projeto e para o produto). Duas técnicas de análise de dados também são
mencionadas: análise de custo-benefício e análise de custo da qualidade (CDQ). A primeira trata de uma
ferramenta clássica de análise financeira que impulsiona muitas tomadas de decisão por parte da
equipe do projeto, pois permite avaliar os pontos fortes e fracos, fornecer alternativas e direcionar o
grupo em prol do melhor benefício. Essencialmente, direciona o time na avaliação de quais atividades
da qualidade são eficazes em relação aos seus custos, levando-se em consideração fatores como menos
retrabalho, aumento de lucratividade, aumento de satisfação das partes interessadas, maior
produtividade e custos reduzidos, entre outros. A segunda trata especificamente de outros custos,
aqueles vinculados ao CDQ, já mencionados no módulo II: custos de prevenção, custos de avaliação
e custos de falhas, sejam internas ou externas. Apesar de não ser algo tão simples de se determinar,
geralmente, os dois primeiros (prevenção e avaliação), quando equilibrados, podem gerar redução do
último (falhas). Existe também a sugestão de utilização de técnicas de tomadas de decisão, excetuando-
se tudo o que já foi demonstrado até aqui (que sempre será, de alguma maneira, incentivo para
processos de tomada de decisão), havendo uma maior carga de atenção para as análises de decisões
envolvendo critérios múltiplos. O PMI (2017a, p. 319) registra que “[...] ferramentas para análise de
decisão envolvendo critérios múltiplos (por exemplo, matriz de priorização) podem ser usadas para
identificar as principais questões e alternativas adequadas a serem priorizadas como um conjunto de
decisões para implementação”. Assim, fórmulas matemáticas são utilizadas para estabelecer
alternativas ponderadas e, futuramente, priorizadas. Um exemplo clássico de utilização dessa
ferramenta em relação à qualidade é a priorização de métricas da qualidade.
Fluxogramas (mapas de processos ou gráficos de procedimentos) são considerados uma das
sete ferramentas básicas da qualidade. Eles são uma representação gráfica, por meio de símbolos,

92
que podem significar desde a natureza da ação até o fluxo de desenvolvimento de processos
específicos. São simples e, ao mesmo tempo, ferramentas complexas, pois bons fluxogramas
demandam conhecimento real sobre o processo estudado ao explorar todas as possibilidades,
destrinchar ramificações de processos, demonstrar dependências de entradas e saídas, iluminar
pontos de decisão/atenção, atividades, gargalos, ordens e sequências paralelas, entre muitos outros
detalhes que permitam uma avaliação completa para que se entenda como estimar o custo da
qualidade. Acima de tudo, descrevem (como pode ser verificado no exemplo proposto na próxima
figura) as decisões que devem ser tomadas, permitindo que se visualize o percurso que trará o melhor
resultado quando avaliadas todas as hipóteses possíveis vinculadas ao processo.

Figura 24 – Exemplo de fluxograma para a implementação de um CEP –

Controle Estatístico de Processos

Fonte: ADAMY et al. (2017).

93
 Ainda tratando de possíveis técnicas e ferramentas, é factível a utilização de representações de
dados. Muitas são as técnicas que poderiam estar aqui discriminadas, mas nos limitaremos às
seguintes: modelos lógicos de dados (representações visuais dos dados de uma organização, traduzidos
em linguagem específica, que auxiliam na identificação de problemas na integridade dos dados ou
em situações vinculadas à qualidade); diagramas matriciais (demonstram correlações entre diferentes
fatores, causas e objetivos, que possam eventualmente existir em uma matriz, fornecendo uma
triangulação de informações que alinham a percepção das métricas da qualidade); e, mapeamento
mental (método visual de apresentação de informações que preconiza a cooperação do time do
projeto ou de partes interessadas, especialmente selecionadas para auxiliar na análise e na
necessidade dos requisitos da qualidade, assim como restrições, dependências e correlações). Por
fim, não podemos deixar de mencionar técnicas de testes e inspeções, visando à instituição das
verificações para possíveis validações (ou não) dos requisitos e técnicas de reuniões, que incluirão
quaisquer recursos (materiais, estruturais ou humanos) que possam ter responsabilidades ou graus
de dependência em atividades vinculadas ao planejamento da qualidade do projeto.

Documentos vinculados ao planejamento da qualidade

Para que o planejamento aqui mencionado produza uma sólida base de referência para os
trabalhos da qualidade ao longo do projeto, é recomendado que uma linha de base da qualidade
seja documentada, minimamente representada por um PGQ e uma documentação de métricas da
qualidade. Automaticamente, essa documentação, tão logo esteja concluída, terá o potencial de
atualizar muitas informações para a equipe do projeto e os seus principais stakeholders, e muitas
delas deverão ser transmitidas para as demais áreas de trabalho, permitindo que muitas
documentações complementares possam ser atualizadas.
O PGQ, um dos componentes mais importantes do planejamento de um projeto, além de
descrever todas as políticas, diretrizes, normas e procedimentos que serão instituídos para a
obtenção de todas as metas destinadas à qualidade do produto, serviço ou resultado que está sendo
gerado pelo time do projeto, também visa a descrever as atividades e a prever os recursos destinados
ao alcance do sucesso da qualidade para o projeto. Segundo o PMI (2017a), o PGQ deve conter,
não se restringindo a esta lista, as seguintes informações:

94
 Quadro 10 – Plano de gerenciamento da qualidade

O plano de gerenciamento da qualidade pode incluir, entre outros, os seguintes

componentes:
 padrões da qualidade que serão usados pelo projeto;
 objetivos da qualidade do projeto;
 papéis e responsabilidades da qualidade
 entregas do projeto e processos sujeitos a revisão da qualidade
 atividades de controle da qualidade e gerenciamento da qualidade planejadas para
o projeto
 ferramentas da qualidade que serão usadas pelo projetos
 procedimentos importantes relevantes para o projeto, como lidar com não conformidades,
procedimentos para ações corretivas e procedimentos para melhoria contínua

Fonte: PMI (2017a).

A fim de tornar fiáveis as muitas entregas vinculadas ao projeto, a determinação de padrões

da qualidade é o primeiro item de importância em um PGQ. Somente por meio dos padrões da
qualidade é que se pode buscar um alto grau de satisfação do cliente/usuário final do produto,
serviço ou resultado a ser gerado pela equipe do projeto, pois são essas definições que permitem
perceber a exatidão do que se está buscando, assim como auxiliam no processo de estipulação dos
indicadores para mensurar parâmetros. Em termos práticos, digamos que uma determinada
empresa deseja contratar uma consultoria especializada para realizar um trabalho de assessment
(diagnóstico) da estrutura de tecnologia da informação dela, para confirmar se está corretamente
dimensionada para as suas necessidades. Antes de realizar a contratação, é adequado que sejam
definidos padrões de qualidade para a empresa que realizará o serviço de consultoria, por exemplo,
exigir certificados de excelência proferidos por entidades respeitadas ou reconhecidas
internacionalmente, experiência mínima comprovada em serviços semelhantes com empresas do
porte da contratante, atestados de capacidade técnica, quadro de profissionais com determinadas
formações e capacitações ou expertises, entre outros quesitos que possam ser considerados como
imprescindíveis. Os demais itens de um PGQ são praticamente autoexplicativos e dependem das
muitas informações vinculadas ao projeto para que a customização desses detalhes traduza o melhor
possível a definição de ferramentas, processos, políticas, objetivos, papéis, responsabilidades,
procedimentos, controles e tudo o mais que for importante para que se defina o que será
determinante para a implementação do plano de gerenciamento da qualidade. Alguns projetos
tendem a incluir também planos de melhorias de processos no PGQ. No entanto, isso costuma ser
algo percebido em culturas organizacionais com alto nível de maturidade em gerenciamento de
projetos ou, ainda, alto grau de exigência por parâmetros da qualidade.
Vejamos dois detalhes importantes sobre o PGQ: o primeiro deles é que revisões do plano de
gerenciamento da qualidade são tratadas como boas práticas, pois permitem que o time do projeto

95
avalie constantemente os benefícios trazidos pelo fiel cumprimento do plano em relação aos custos
do projeto (verifique o que já estudamos sobre o custo da qualidade). Tomadas de decisão
provenientes desse tipo de análise precisam ser fundamentadas em uma sólida base de informações,
de preferência com o foco permanente em entrega de valor percebido pelo cliente/usuário final. O
segundo diz respeito a organizações que já possuem determinadas certificações da qualidade ou
rigores de práticas da qualidade estabelecidas por lei, que deixam padrões da qualidade acima de
qualquer plano de gerenciamento da qualidade escrito por qualquer time de projeto. Nesse caso, o
PGQ passa a assumir as condições de alto grau dessas certificações ou práticas, apenas auxiliando
na disseminação dessas informações aos principais stakeholders do projeto.
Quanto às métricas da qualidade, são especificações que descrevem os atributos de um
produto (serviço ou resultado) ou, até mesmo, do projeto em si. É um artefato de extrema
importância, pois essas informações serão a base para o trabalho da equipe no momento de controlar
a qualidade. Podem incluir percentuais de tarefas concluídas em um determinado período de
tempo, índices de falhas e pontuações para índices de satisfação, entre muitas outras propostas de
utilização. Conforme descrito na próxima figura, podemos observar um extrato de um caso prático
da implementação de um Serviço de Atendimento ao Cliente (SAC).

Figura 25 – Métricas da qualidade

PROJETO: Implementação de um SAC – Serviço de Atendimento ao Cliente.

ATRIBUTO: Atendimento do SAC.
REQUISITO: Rapidez no atendimento telefônico.
INDICADOR: % de chamadas respondidas até o segundo toque.
META: Responder 95% das chamadas até o segundo toque.
PADRÃO: Determinar % das chamadas até o segundo toque durante o período de testes, nas
primeiras 48 horas.

Requisito de Indicador Meta Técnica de Frequência Responsável

Qualidade medição

Rapidez no ICR* = % de ICR > Contar, Única Auditor de

atendimento chamadas ou = manualmente, (primeiras qualidade
telefônico atendidas 0,95 número de 48 horas do
do SAC até o 2º chamadas totais período de
toque/% de atendidas e número testes)
chamadas de chamadas
totais atendidas até o 2º
atendidas toque

(*) ICR = Índice de Chamadas Recebidas

Fonte: adaptado de ESCRITÓRIO DE PROJETOS (2017).

96
 Um artefato de métricas da qualidade dispõe sobre todas as informações necessárias para
responsabilizar, verificar e comunicar um grau de medição atrelado a um determinado
requisito/atributo da qualidade de um produto, serviço ou resultado a ser desempenhado pelo
projeto. Salienta-se que o erro mais comum a ser evitado é a atribuição de indicadores, sem vincular
a sua medição a uma possível meta (de preferência, mais de uma). Nada adiantaria, por exemplo,
mensurar o ICR, se não existisse o propósito (ou a necessidade) de atingir um objetivo com 95%
de sucesso. Toda métrica precisa ser representada por algum tipo de medida, sendo esta traduzida
por um número ou proporção (valor real). Se for o caso, devem-se definir limites de controle (ou
de tolerância – conforme estudamos no módulo II), podendo considerar uma variação aceitável
(margem de erro ou de sensibilidade) para aumentar o nível de abrangência do resultado. Uma coisa
é dizer “Amanhã estarei em casa às 18 horas”; outra é dizer “Amanhã estarei em casa às 18 horas,
podendo variar cerca de 10 minutos para menos ou para mais”. O nível de abrangência passará a
ser consideravelmente maior, pelo fato de ampliar em 20 minutos a margem de tolerância. Ou seja,
a probabilidade de acerto será bem maior. No entanto, a precisão da métrica pode ser questionada
por ser considerada muito tolerante. O fato é que, ao longo do projeto, muitos ajustes e tomadas
de decisão serão realizados com base no grau de informações existentes nesse documento. Quanto
melhor especificadas forem as informações constantes da métrica da qualidade, maior a chance de
obter um alto índice de satisfação das principais partes interessadas e de alinhar a entrega de valor
percebido ao cliente/usuário final.
Com o planejamento da qualidade completo e exibindo as primeiras versões de importantes
artefatos, o projeto começa a tomar um novo rumo. Muitas das informações necessárias para que a
equipe do projeto possa iniciar os trabalhos (caso ainda não tenha iniciado) estão disponíveis,
permitindo que a dinâmica da equipe do projeto passe a ser relativamente diferente, pois os esforços
destinados ao planejamento começam gradativamente a ser reduzidos e a se concentrar mais nos
trabalhos de execução e, em alguns casos, de monitoramento e controle.

Retrospectiva do módulo
O módulo V apresentou um breve resumo de como os três Ks do modelo de gestão Toyota
podem influenciar os trabalhos da qualidade de um projeto. Descobrimos que muito pode ser feito
no intuito de provocar modelos mentais de melhoria contínua afetando diretamente intangíveis
organizacionais e provocando profundas mudanças no modus operandi das equipes de projetos.
Vimos que o Kaizen se relaciona diretamente com o fazer desta vez melhor que da vez anterior,
notadamente por meio de uma boa gestão dos 3 Ms (mura, muda e muri), encorajando mudanças
incrementais e contínuas. Já o Kaikaku denota uma mudança mais radical, uma mudança de rumo
mesmo. Sempre que o Kaizen chega a um determinado limite é o momento de experimentar algo
novo, e isso ocorre por meio da exploração de novas tecnologias ou de novas expertises. Por fim, o

97
conceito de Kakushin significa algo totalmente revolucionário, em que o modelo de negócio pode
ser questionado e até mesmo o propósito de trabalho poderá sofrer influências, pois a aplicação de
inovação surge para quebrar paradigmas e redefinir padrões.
Além disso, vimos a influência dos principais artefatos do planejamento da qualidade no ciclo
de vida de um projeto, compreendendo como é a sequência dos trabalhos desencadeada após o
início do planejamento do escopo, que consequentemente disseminará informações preciosas para
os demais temas do projeto. A qualidade é uma sequência lógica, pois o trabalho de levantamento
dos requisitos, a especificação e a confecção de uma linha de base do escopo, leva a equipe do projeto
a novos desafios. É preciso determinar como aquilo que ficou detalhado no momento do temos de
fazer isso será efetivamente validado, evitando atritos com muitas das principais partes interessadas
do projeto. Para que esse trabalho possa ser realizado, verificamos a necessidade da confecção de
um plano de gerenciamento da qualidade e a importância das métricas da qualidade para o futuro
da execução e do controle da qualidade ao longo do projeto. Como resultado, identificamos os
templates de um plano de gerenciamento da qualidade e de uma documentação de métricas da
qualidade, detalhando componentes e algumas peculiaridades.

98
MÓDULO VI – ACOMPANHAMENTO,
VALIDAÇÃO DOS REQUISITOS, ACEITAÇÃO
DAS ENTREGAS E CONTROLE DO ESCOPO

O módulo VI trata do momento pós-planejamento do gerenciamento do escopo. Com o

trabalho de desenvolvimento da equipe do projeto sendo realizado, o time responsável pelo escopo
volta os olhos para as entregas. Todas (ou ao menos as mais importantes) as que são vinculadas à
linha de base do escopo serão (ou deverão ser), em algum momento, verificadas quanto à precisão
dos requisitos definidos na documentação do projeto. Entregas verificadas e chanceladas pela equipe
da qualidade são documentadas e encaminhadas para aceite sempre que necessário (nem todas as
entregas precisam estar vinculadas a critérios de aceitação). O aceite se dá de maneira formal ou
informal, mas sempre documentado conforme as necessidades do projeto e das principais partes
interessadas. Sempre que uma entrega for verificada e encontrar qualquer grau de desconformidade,
um momento de tomada de decisão precisa ser estabelecido. O realizado encontra-se diferente do
previsto e esforços precisam ser realizados para avaliar a situação de acordo com o momento vivido
pela equipe do projeto no sentido de compreender o problema, verificar causas e impactos de
possíveis ajustes, estabelecer solicitações para correções e processos de melhoria, além de registrar
todo o trâmite das ações para estimular a gestão do conhecimento organizacional. Escopo bom é
escopo verificado, chancelado, aceito (transmitido/entregue) e documentado.

Acompanhamento do escopo e validação dos requisitos

Uma das provas de que o gerenciamento do escopo não acontece sozinho em um projeto é o
(tenso) momento de validação. É impossível presenciar um momento mais oportuno para a
demonstração de como o trabalho do gerenciamento do escopo está intimamente ligado ao
gerenciamento da qualidade, além de depender de uma série de fatores que poderão levar a um
fluxo de controle integrado de mudanças.
 Existem duas situações ao analisarmos um fluxo de validação do escopo: a primeira ocorre
quando se recebe a confirmação, por parte da área ou do time da qualidade, de que uma determinada
entrega foi verificada e as precisões dos seus requisitos foram chanceladas. Quando isso ocorre, o fluxo
dos processos segue naturalmente para o encerramento do projeto, pois a área ou o time do escopo
concebe e documenta as informações necessárias para chancelar a aceitação dessas entregas. Baseado
nesse fluxo de validações das entregas, há a possibilidade de encerrar o projeto – à medida que todas
as entregas conseguem ser verificadas e, posteriormente, validadas – ou alguma fase intermediária (ou
uma etapa importante vinculada a algum milestone) do projeto. A segunda situação ocorre quando a
equipe da qualidade envia uma informação de entrega verificada, mas com viés de não conformidade
das precisões dos requisitos. É chegado então o momento da tomada de decisão. É preciso avaliar
quais são os objetivos estratégicos vinculados ao projeto para se decidir pelo avanço justificado ou por
uma solicitação de mudança (algumas organizações optam por manter a utilização do termo em inglês,
change request). Uma solicitação de mudança custa tempo e dinheiro ao time do projeto, apesar de ser
um dos principais instrumentos de aprendizado ao longo do ciclo de vida do projeto e algo muito
comum. Afinal, como todo processo de mudança, será necessário avaliar o impacto dessa solicitação
em uma série de eventos/artefatos do projeto, como mapas de riscos e planos de comunicações, entre
muitos outros. Como é possível afirmar que um projeto sem mudanças é algo utópico, ao menos em
algum momento é esperado que ocorra esse fluxo destinado a uma solicitação de mudança, acionando
o controle integrado de mudanças do projeto, normalmente vinculado a fluxos pré-definidos por um
plano de gerenciamento de mudanças.
O time responsável pelo escopo então, em vez de validar a entrega, dispara um alerta de
solicitação de mudança que, naturalmente, será avaliado por um comitê de mudanças. Contudo,
não há como se enganar, o objetivo maior do momento de validação do escopo é o de buscar e,
consequentemente, realizar a aceitação de todas as entregas. Afinal de contas, estando tudo a
contento, não haverá necessidade de qualquer tipo de controle do escopo, que no futuro poderá
gerar um novo fluxo de avaliação visando ao rigor das precisões das entregas e dos cumprimentos
dos requisitos do produto e do projeto (devidamente atualizados e especificados).
Uma boa ferramenta para acompanhamento dos escopos validados ou enviados para controle
é um quadro visual que possa ser atualizado constantemente, de preferência ao final dos ciclos
iterativos de entrega ou vinculado a um cronograma de marcos. Isso não só servirá de documentação
para o fluxo de entregas validadas ou enviadas para controle mas também poderá servir como ponto
de discussão e apoio para o aprendizado com erros e ajustes para a melhoria contínua.

100
 Figura 26 – Painel visual para acompanhamento de entregas

Fonte: elaborada pelo autor.

A vantagem de um painel visual de acompanhamento de entregas é que a equipe do

projeto estará sempre lidando com o fluxo de entregas (estará lá, para todos visualizarem) e
lembrando, constantemente, daquilo que tem algum tipo de pendência. É uma técnica visual
simples de ser atualizada e que envolve a colaboração de todos, ou seja, ao mesmo tempo deixa
toda a equipe ciente de pormenores sobre qualquer espécie de entrega, podendo atuar para que
o fluxo esteja sempre retificado e o mais próximo da eficiência desejada para a conclusão dos
trabalhos de um determinado período.
Outra técnica/ferramenta que também poderá ser utilizada é a própria EAP, pois, a partir do
momento em que ela existe, o acompanhamento das entregas (seja manual, seja por meio de
sistemas de informações/softwares de gestão) poderá ser facilmente visualizado. O importante é
apenas definir a necessidade de informação e, muitas vezes, a questão da acessibilidade. Talvez nem
todos os stakeholders tenham necessidade de visualizar todas as informações e, por vezes, algumas
legendas ou imagens deverão ser decifradas (decodificadas) por meio de outros formatos.

101
 Figura 27 – EAP como acompanhamento de entregas

Fonte: adaptado de XAVIER (2009).

A necessidade do projeto sempre definirá o nível de informação necessário sobre o

rastreamento das entregas. Muitos são as técnicas e os artefatos que auxiliarão a equipe do projeto,
como matrizes de rastreabilidade dos requisitos. No entanto, os sistemas de informação em projetos
e ferramentas de compartilhamento têm se mostrado verdadeiros aliados, e muitos protocolos
acabam surgindo por causa de padrões determinados pelos próprios softwares de gestão. Poderíamos
tratar de uma série destes, mas como isso não é o propósito de nosso estudo (ainda), veremos apenas
o extrato de um dos mais conhecidos no mercado, conforme apresentado na figura a seguir.

Figura 28 – Padronizações em acompanhamento de entregas

Fonte: elaborada pelo autor.

Uma padronização de utilização de cores é muito comum para avaliar o avanço de um pacote
de trabalho ou de uma entrega específica em uma conta de controle. Os três retângulos acima
representam a entrega de um mesmo pacote de trabalho, sempre associados a informações
financeiras, de uma EAP fictícia, porém cada um representando uma situação diferente em relação

102
à entrega, ou seja, cada um com uma peculiaridade vinculada ao seu acompanhamento. O da
esquerda, na cor azul, ilustra um trabalho integralmente realizado (o percentual de 100% é
demonstrado, sendo que as duas linhas que cortam diagonalmente o retângulo reforçam
visualmente a ideia), e dentro das expectativas financeiras, pois, ao compararmos o previsto em
relação ao realizado, há sobra de recursos financeiros. O retângulo central demonstra um trabalho
parcialmente realizado (50% concluído em termos de entregas daquilo que precisa ser realizado e
por isso o reforço visual de apenas uma linha cortando a imagem diagonalmente), mas ainda dentro
das expectativas financeiras, pois o valor gasto até o presente momento ainda está abaixo quando
proporcionalmente comparado aos 50% realizados do escopo. Mesmo que projetado no futuro,
esse valor continuaria dentro das estimativas iniciais dos recursos financeiros daquele pacote de
trabalho. No entanto, cabe aqui um aparte, pois nem sempre essa correlação será verdadeira, pois é
possível uma entrega consumir muitos recursos financeiros no início dos trabalhos e encontrar o
seu valor estimado apenas ao final. Se, nesse mesmo exemplo, os recursos financeiros tivessem sido
consumidos em 80%, mas o escopo tivesse avançado apenas 50%, ainda assim seria possível alcançar
o planejado ao final dos 100% (dos recursos financeiros e do escopo). É sempre importante avaliar
as informações disponíveis em conjunto com outros dados que possam auxiliar na avaliação da
situação e de futuras tomadas de decisão da equipe do projeto. O último retângulo, na cor vermelha,
demonstra que a entrega foi integralmente realizada (100% e duas linhas cortando a imagem), mas
que os recursos financeiros extrapolaram as estimativas iniciais. Caberá à equipe do projeto justificar
os gastos extras e avaliar o impacto disso no futuro do projeto, para decidir o que precisará ser
realizado no sentido de ajustar o planejamento inicial à realidade de execução do projeto.
A documentação dos requisitos assim como a linha de base do escopo são as principais
referências para que possa existir uma comparação entre o status quo e o que foi efetivamente
realizado, visando a determinar se uma solicitação de mudança, ou uma ação corretiva ou
preventiva, precisará ser acionada. Há também a preocupação em receber informação da matriz de
rastreabilidade dos requisitos, pois ela contém informações valiosas sobre como os requisitos
deverão ser aceitos e validados. Relatórios de lições aprendidas ou outros documentos que permitam
difusão da gestão do conhecimento do projeto, assim como relatórios da qualidade, também
poderão servir de grande valia para o auxílio na validação do escopo, pois aumentarão as chances
de eficiência e de eficácia no momento da aceitação das entregas.
Se um determinado pacote de trabalho não estiver corretamente definido na linha de base do
escopo, não há como passar pelo processo de verificação da qualidade e, posteriormente,
transformar-se em entregas aceitas (momento em que a informação deveria seguir adiante e ser
transmitida para viabilizar o encerramento – ou parte – dos trabalhos). Sem a verificação da
qualidade, o principal papel do momento de validação do escopo, que é o de buscar futuramente
todas as aceitações das entregas, não conseguiria ser executado.
É comum que o processo de verificação da qualidade ocorra antes do processo de validação
do escopo, mas é importante ressaltar que não há dependência entre um processo e outro, podendo

103
o controle da qualidade ocorrer em paralelo com a validação do escopo, por exemplo. Em alguns
casos, projetos utilizam critérios de aceitação vinculados ao cumprimento de alguns requisitos da
qualidade, sendo possível ganhar tempo em momentos importantes do projeto.

Aceitação das entregas

Quando um critério de aceitação é formalmente recebido pela parte interessada competente,
significa dizer que há uma entrega aceita. A priori, uma entrega aceita é o que melhor caracteriza o
momento de validação do escopo, pois trata-se do seu objetivo máximo conseguir todas as aceitações
do projeto. Contudo, existe a possibilidade de emissão de novos dados a respeito do desempenho
do trabalho, independentemente de as entregas serem aceitas ou não. Essas informações tendem a
ser documentadas e transmitidas aos principais stakeholders, assim como são documentadas todas as
peculiaridades em relação à aceitação das entregas. Aquilo que não recebe um aceite formal vira
motivo de uma potencial solicitação de mudança, que também vem a ser um processo de
formalização e documentação chave dentro do trabalho do escopo. Isso abre, porém, uma nova
possibilidade, pois visa a um processo de análise e entendimento da situação para que possa ocorrer
uma reavaliação do(a) problema/questão e a sua futura correção/resolução. Contudo, esse trabalho
será direcionado ao momento de controlar o escopo, acionando processos de mudanças também
preconizados no planejamento do projeto.
Um documento que pode auxiliar bastante no processo de aceitação de entregas é um
formulário de aceitação formal, que tanto vem a ser uma lista de verificação que pode auxiliar os
trabalhos oriundos da equipe da qualidade, quando o foco for verificar a exatidão da entrega ou a
precisão dos requisitos vinculados a ela, como sequenciar essas informações e promover o trâmite
integrado e natural para a equipe que lida com o gerenciamento do escopo, cujo foco é verificar se
a validação dos requisitos atende aos critérios de aceitação acordados com o cliente/usuário final.
Um modelo desse formulário pode ser visualizado no quadro a seguir.

Quadro 11 – Formulário de aceitação formal

título do projeto data de elaboração

critério de critério de
ID requisito status comentários aprovação
aceitação validação

Fonte: adaptado de SNYDER (2013).

104
 As quatro primeiras colunas são informações retiradas da documentação dos requisitos, o que
facilita muito o sistema integrado de informações do projeto. Na sequência, o que se vê é uma
informação a respeito do status da entrega – pode ser simplesmente aceito ou não aceito, ou ainda
parcialmente aceito –, além de um espaço para observações, por exemplo: informações detalhadas do
porquê de o requisito não ter sido aceito, quando a solicitação de mudança foi realizada e que tipo de
mudança espera-se desse processo. Por fim, coleta-se a confirmação de quem foi a parte interessada
responsável por aceitar respectiva entrega. É importante frisar que, apesar de estarmos lidando com
modelos de documentos em papel ou planilhas eletrônicas – que podem ser facilmente adaptados para
sistemas de informações digitais, promovendo um melhor grau de mobilidade – existem alternativas
mais modernas, disponíveis no mercado, que facilitam aceites virtuais entre outras alternativas.

Controle do escopo
Segundo o PMI (2017a, p. 203), controlar o escopo é o momento “[...] de monitoramento
do progresso do escopo do projeto e do escopo do produto e gerenciamento das mudanças feitas na
linha de base do escopo. O principal benefício deste processo é que a linha de base do escopo é
mantida ao longo de todo o projeto”. Trata-se de uma situação que só poderá ser acionada na
sequência de tentar validar um escopo e a equipe não obter êxito.
Caso o planejamento do projeto não tenha estipulado um plano integrado de mudanças
(como ocorrerão os fluxos das mudanças de um projeto), segundo Louzada (2017), algumas
diretrizes são recomendadas para desenvolver um bom processo para gerenciar mudanças
vinculadas ao escopo, como:
 definir critérios para avaliar as propostas de mudanças (iniciadas por uma change request –
solicitação de mudanças);
 manter a comunicação com as demais equipes/setores organizacionais para verificar como
será gerenciado o controle integrado da mudança;
 avaliar o impacto da mudança no objetivo de negócio (normalmente, viabilizado por
documentações de viabilização do projeto, como um plano de negócios ou estudos de
mercado/viabilidade);
 definir de quem serão as responsabilidades pelas mudanças; definir como elas serão
priorizadas e documentadas e
 atualizar as avaliações de riscos e os seus potenciais novos impactos.

Para que todas as análises do escopo – do projeto ou do produto – possam ocorrer da melhor
maneira possível, a linha de base do escopo precisa estar disponível, pois não só é a documentação
responsável por conter todas as referências que serão comparadas para verificar o(s) requisito(s)
afetados por uma solicitação de mudança, como também qualquer inovação que requeira uma
reavaliação geral daquilo que foi elicitado.

105
 Os cuidados com as informações para um possível controle do escopo são muito semelhantes a
um processo de verificação do escopo para efeitos de aceitação, pois a base de documentação que
servirá de referência para a análise será praticamente a mesma. Muitos documentos do projeto, como
o registro de lições aprendidas (no intuito de verificar se projetos similares ou fases anteriores do
mesmo projeto contêm informações que possam melhorar o gerenciamento do controle do escopo) e
a documentação dos requisitos (para avaliar se ocorreu qualquer tipo de desvio no escopo do projeto
ou no escopo do produto). Além disso, a matriz de rastreabilidade dos requisitos, para avaliar a visão
macro, de ponta a ponta do projeto, em relação aos impactos que qualquer mudança ou desvio de
linha de base possa desferir contra os objetivos do projeto. Dados sobre o desempenho de trabalho
também são bem-vindos, afinal, são relatórios precisos acerca, por exemplo, da quantidade de
solicitações de mudanças recebidas, das variações dos indicadores, da quantidade de entregas
verificadas, validadas ou não. Por fim, a equipe do projeto também não deve deixar de verificar alguns
ativos de processos organizacionais, aqui representados por meio de políticas, procedimentos e
diretrizes organizacionais de controle, além de métodos, frameworks ou templates de monitoramento.
Controlar o escopo nunca será algo isolado. Da mesma forma que o planejamento do escopo
exerce força em potenciais impactos nas demais áreas ou setores vinculados a um projeto, o controle
do escopo, necessariamente, precisa trabalhar com outros temas e os seus respectivos processos de
controle, por exemplo, a necessidade de aumentar o número de rodas de um determinado veículo
é um trabalho que precisaria estar alinhado com departamentos/fluxos de aquisições, avaliações
conjuntas com equipes de riscos e fatores técnicos da qualidade, somente para mencionar alguns.
Como o próprio PMI (2017a, p. 204) salienta: “[...] o aumento sem controle do escopo do produto
ou projeto sem ajustes de tempo, custos e recursos é chamado de distorção de escopo”.

Figura 29 – Controle do escopo

Fonte: adaptada de GUIMARÃES (s. d.).

106
 Em suma, toda equipe do projeto sabe de antemão que passará por momentos que requerem
ações corretivas/adaptativas com influências no escopo do produto, serviço ou resultado que está
sendo gerado pelo projeto. O trabalho de gerenciamento do escopo será responsável por não deixar
que esses momentos se perpetuem de maneira descontrolada, no sentido de evitar o fenômeno de
scope creep. As variações (mudanças) solicitadas precisarão ser avaliadas em conjunto com toda a
documentação e o conhecimento necessários, para que possam fluir pelos processos pré-
determinados de um controle integrado de mudanças.
Para efeitos de análises de variação, representadas por referências e métricas que acompanham
importantes pontos de qualquer projeto, é possível que mudanças do escopo impactem métricas
operacionais, por exemplo, o percentual de cumprimento de um cronograma, ou métricas de
desempenho, como um índice de satisfação do patrocinador do projeto (este último, mensurado
após o término do projeto ou de alguma fase importante).

Retrospectiva do módulo
O módulo VI fixou-se em apresentar todos os conceitos a respeito do momento pós-
planejamento do gerenciamento do escopo, notadamente em relação a ações de verificação (com fito
de validação) e, caso necessário, controle (por disseminação de solicitações de mudança que acionarão
o controle integrado de mudanças do projeto). Avaliamos, em primeiro lugar, como se acompanha o
trabalho de verificação das entregas e, posteriormente, como se realiza a validação dessas entregas. O
foco principal desse momento é a busca do aceite de todas as entregas, um trabalho realizado em
conjunto com equipes multifuncionais que respondem pelos trabalhos da qualidade e da gestão de
mudança, concomitantemente, com o trabalho de gestão do conhecimento.
Listamos os principais problemas/fatores que costumam estar relacionados ao escopo e têm
grande potencial de gerar revisões com chance de mudanças e exploramos algumas
técnicas/ferramentas com baixo grau de complexidade e alto grau de engajamento, como painéis
visuais para acompanhamento de solicitações de mudança e entregas em conformidade, além de
peculiaridades da já conhecida EAP, analisando um pouco mais de perto os pacotes de trabalho e
as suas propriedades. Se um determinado pacote de trabalho não estiver corretamente definido
dentro da linha de base do escopo, torna-se muito difícil (quase impossível) passar pelo processo de
verificação da qualidade e, posteriormente, transformar-se em entregas aceitas. Vimos que, um olhar
detalhado, com atenção às entregas do escopo e os seus critérios de aceitação/validação é chave
crítica para o sucesso do projeto.
Pudemos avaliar um template simples, porém eficaz, para um formulário de aceitação formal
que vincula critérios de aceitação e de validação, não deixando brechas para surpresas.

107
 Apesar de ajustes e ações corretivas serem recorrentes em projetos, sempre que é requisitada
uma solicitação de mudança oriunda do escopo, tem-se a certeza de que essa mudança precisará ser
avaliada em conjunto com toda a documentação e o conhecimento necessários, para que possa fluir
pelos processos pré-determinados de um controle integrado de mudanças.
Ao estudarmos esses últimos detalhes, fecha-se o ciclo do trabalho do gerenciamento do
escopo em um projeto. Quando um escopo é trabalhado de maneira correta, todo esse trabalho se
reflete no restante do projeto, sendo o contrário também verdade.
Com os ensinamentos deste módulo, torna-se mais fácil compreender como aceitar as entregas
ou promover as suas revisões, para buscar a perfeição do produto, serviço ou resultado que será gerado.

108
MÓDULO VII – GERENCIAMENTO E
CONTROLE DA QUALIDADE

O módulo VII nos mostra como é tênue a linha que separa o gerenciamento e o controle da
qualidade em um projeto. Muito do que se faz em prol da execução da qualidade evidencia possíveis
trabalhos de controle que depois remetem a novos esforços de execução, ou seja, é um ciclo virtuoso
que tende a explorar muitas boas práticas, técnicas e ferramentas para que tudo possa ser realizado
da melhor maneira possível. As dezenas de práticas adotadas pela qualidade são extensas e muitas
vezes adaptadas de outros meios, por exemplo, os de produção industrial. Por um lado, isso permite
que times de projetos disponham de um leque de opções para encaminhar assuntos da qualidade e
resolver possíveis problemas. Por ora, torna-se humanamente impossível falar de todos sem ser, de
alguma forma, injusto com um determinado método ou framework. A seleção que acompanha este
capítulo foi criteriosamente selecionada para poder atender às necessidades de estudo e ao roteiro
de aprendizado desenvolvido pelo nosso material. Alguns itens, contudo, terão um maior peso em
nosso ambiente virtual, por meio de estudos de casos e alguns outros exemplos práticos, facilitando
o intercâmbio dos métodos de aprendizagem que este curso proporciona. Além disso, é importante
frisar que executar a qualidade serve como referência para processos de melhoria contínua, pois
também auxilia na distribuição de informações geradas durante o processo de controle da qualidade.
Quanto a este, a equipe do projeto deve, antes de tudo, monitorar resultados e avaliar o grau de
precisão dos requisitos. De posse das constatações derivadas do monitoramento, caso sejam
encontradas desconformidades (falhas internas e externas), as causas dos resultados insatisfatórios
deverão ser mapeadas e as ações corretivas determinadas, evitando novas ocorrências. Para isso,
presenciaremos uma série de ferramentas, técnicas e práticas que poderão ser facilmente adaptadas
para qualquer tipo ou porte de projeto.
Gerenciamento da qualidade
Gerenciar a qualidade significa executar na íntegra aquilo que foi preconizado pelo plano de
gerenciamento da qualidade. Uma vez que o PGQ ganha vida, cabe ao time do projeto responder
por padrões, procedimentos, abordagens e tudo o mais que estiver determinado pelos artefatos
constantes desse compêndio da qualidade, que, além do PGQ, como bem recomendamos ao longo
do módulo V, também demonstra-se adequado confeccionar uma documentação de métricas da
qualidade, no intuito de facilitar os trabalhos de validação dos requisitos. Exatamente por isso, o
PMI (2017a, p. 307) determina que gerenciar a qualidade significa “[...] traduzir o plano de
gerenciamento da qualidade em atividades da qualidade executáveis que incorporam as políticas da
qualidade da organização do projeto”.
No entanto, vale recordar que mesmo com todos os requisitos da qualidade devidamente
mapeados e documentados, é possível que muitos aspectos vinculados à qualidade sofram
influências das múltiplas variáveis que assolam o dia a dia de trabalho de qualquer equipe de
projetos. Por isso, é correto afirmar que o trabalho da qualidade, mais que qualquer outro tema,
deve se prender àquilo que se encontra definido pelo plano de gerenciamento da qualidade,
documento que precisa ser constantemente revisado e atualizado para fazer frente a possíveis
desafios e necessidades de mudanças. De nada adiantará um excelente trabalho da qualidade por
parte da equipe do projeto, se, em qualquer momento, o cliente/usuário final decidir que um
determinado aspecto já não faz mais sentido ou não agrega valor ao produto, serviço ou resultado
que vem sendo gerado. Para Juran (2009, p. 99), o objetivo de um produto é “[...] satisfazer o
cliente com a qualidade certa. Nem mais nem menos”. Ou seja, a necessidade de um trabalho
próximo aos desejos, receios e expectativas do cliente/usuário final é uma condição que, cada vez
mais, reverte-se em modernas boas práticas, evidenciando-se como um fator crítico de sucesso para
o desempenho da qualidade de um projeto.
Algumas práticas comuns a muitos projetos poderão ser destacadas como essenciais para o
gerenciamento da qualidade. Iremos conhecê-las agora.

Processos integrados e de melhoria contínua

Servem para aprimorar o gerenciamento da qualidade do projeto e também a qualidade do
produto, serviço ou resultado final, pois frequentemente incorporam os erros (aprendizados) e
acertos da qualidade perante o conjunto do trabalho como um todo. Em um menor espaço de
tempo, é possível verificar se o produto inteiro ainda se porta como esperado. Beneficia não só o
resultado final do projeto como também propicia um mergulho em muitas questões que podem
auxiliar para melhorar o nível de maturidade da equipe (numa visão coletiva), assim como a

110
evolução profissional dos indivíduos. Talvez por serem bem eficazes e demonstrarem valor logo nas
primeiras vezes de aplicação, muitas são as práticas e ferramentas associadas ao tema (como as que
já exploramos no módulo II: ciclo PDCA, 5 whys e reuniões de retrospectiva; ou no módulo V: os
3Ks). No entanto, demonstraremos algumas outras técnicas/ferramentas a seguir.
Reuniões ou sprints de manutenção – reuniões de manutenção são, significativamente,
diferentes de reuniões de retrospectiva. A priori, são estimuladas em momentos específicos do
projeto, quando a capacidade da equipe está sobrecarregada e, portanto, realizada em momentos
extraordinários. Elevados índices de sobrecarga podem estar associados a altos índices de correções
ou ajustes, pois desviam os esforços de trabalho da equipe para cumprir funções que não agregam
valor ao produto, visto que estão associadas a retrabalhos ou defeitos. Podem ser sinais de falhas no
planejamento, na execução, no gerenciamento ou na priorização dos requisitos, entre muitas outras.
Com o viés de servir de instrumento da qualidade para a equipe do projeto, essas reuniões
conseguem equalizar os esforços da equipe, solucionando problemas e determinando novas
diretrizes de trabalho. Quando o problema é grande demais, uma variação dessa técnica é criar um
ciclo iterativo (sprint) de manutenção, freando-se o trabalho de desenvolvimento do produto ou
serviço, e o foco passa a ser a correção de problemas, quase como um mutirão para abrir caminhos
para que o time possa novamente trabalhar sem estar infestado de ocorrências.
Reuniões de refinamento ou grooming – um tipo de reunião diferente, preferencialmente
quando há necessidade de atualização de planejamento fazendo parte, normalmente, do
cronograma do projeto. Os objetivos são, entre outras possíveis ações: reavaliar estimativas que
possam estar defasadas em decorrência de informações atualizadas ou de qualquer outra variável
imposta ao projeto; eliminar requisitos que não se fazem mais relevantes; repriorizar requisitos cuja
classificação possa já não fazer mais sentido para a execução dos trabalhos; criar novas
funcionalidades que tenham passado despercebidas no momento do planejamento; e, decompor
funcionalidades ou pacotes de trabalho que pareciam suficientes e ganharam um nível maior de
esforço, por qualquer que seja a razão.

111
 Figura 30 – Ficha de controle de processo

Fonte: CALDAS; SALGADO (2017).

112
 Fichas de controle – uma ferramenta que funciona para capturar informações e atestar uma
atividade ou momento-chave do projeto enquanto ele acontece. Comumente utilizada em
operações, quando a responsabilidade de algo passa de mão em mão, a técnica foi adaptada para o
dia a dia das equipes de projetos. Trata-se de uma forma padrão, por meio de uma folha ou
formulário eletrônico, em que o novo responsável possa registrar o status atual de um produto ou
de uma determinada situação (processo). Talvez a situação de utilização mais conhecida de nosso
cotidiano sejam as fichas de controle utilizadas por firmas de seguro ou de locação de carros,
membros da polícia e serviços de manutenção (reboque), por exemplo, quando precisam transmitir
a posse de um determinado veículo, após um acidente. As fichas são preenchidas por terceiros, para
informar o estado atual do veículo, e podem relatar avarias, itens defeituosos e causalidades, entre
muitas outras questões. Equipes de projetos, entre muitos outros formatos, podem utilizar uma
ficha de controle para o registro de defeitos no produto (ou em componentes) que está sendo
desenvolvido. Em um determinado momento, a equipe pode sentar e avaliar detalhes acerca desse
histórico de defeitos para tentar resolvê-los ou preveni-los de uma outra forma, evitando que se
repitam, promovendo uma cultura de melhoria contínua.

Testes em todos os níveis

Efetuam-se testes unitários para componentes singulares (itens isolados, condições únicas etc.)
e testes em nível coletivo (de sistema) para obter informações mais complexas. Sempre que possível,
visualizar a necessidade de testes de integração e de testes automatizados, propiciando um dinamismo
maior de validação das entregas. Utilização de testes preliminares que revelem falhas simples, porém
capazes de gerar ocorrências graves no futuro, como encontrar uma funcionalidade com falha que
inviabilize a validação futura de uma versão de um MVP (também conhecido como smoke testing).

Estudos/Análises de causa e efeito (ou causa-raiz)

São abordagens práticas, fáceis e colaborativas com foco no entendimento de um
determinado problema, para solucioná-lo. Na maioria das vezes, aparecem combinadas com
ferramentas de tomadas de decisão. Costumam produzir grandes benefícios, não só para o nível da
equipe do projeto, como também para níveis estratégicos/direção. São muitas as ferramentas com
o viés de definição de um problema, identificação das possíveis causas e proposição de solução:
Diagrama de Ishikawa ou diagrama espinha de peixe – a aparência gráfica do diagrama
desenvolvido por Kaoru Ishikawa, como uma espinha de peixe, deixou a sua alcunha tão famosa
quanto o nome do seu criador. O diagrama foi gerado para associar um efeito (problema ou defeito)
às suas possíveis causas, no entanto, sob diversos pontos de vista. Por ser uma ferramenta
colaborativa, serve como meio de compartilhar entendimentos e gerar futuras discussões para que
se evidencie uma possível solução ao efeito registrado como uma consequência de uma ou muitas
origens. O modelo original se baseia em seis categorias de influência sobre um resultado: medida

113
(medição), método, mão de obra, máquina, meio ambiente e material. Para cada causa com origem
em uma dessas influências demonstra-se como se desenvolve a conexão entre causa e efeito para,
posteriormente, discutir uma solução para uma ou mais causas.

Figura 31 – Diagrama de Ishikawa

Fonte: BORGES (2014).

Diagrama de Pareto – desenvolvido por Juran, o diagrama de Pareto utiliza o mesmo padrão
de semelhança encontrado por Vilfredo Pareto, quando demonstrou uma relação de causa e efeito
numa proporção de 80/20 nas suas pesquisas econômicas do século XIX. Juran sugeriu que o
princípio de Pareto sustenta que (aproximadamente) 80% dos efeitos vêm de 20% das causas. Por
um viés de resolução de problemas, consequentemente, pode-se pressupor que, ao tratar 20% das
causas, 80% dos problemas desaparecerão. O gráfico demonstra não somente as porcentagens de
cada análise, mas também as cumulativas, definindo, como na próxima figura, que os cinco
primeiros produtos (da esquerda para a direita) representam cerca de 80% de concentração dos
problemas, sendo esses os prioritários para ações de correção e prevenção.

114
 Figura 32 – Diagrama de Pareto

Fonte: BORGES (2014).

Árvore do problema (problem tree) – a representação baseada na estrutura física de uma

árvore permite que o problema seja alocado ao centro (representando o caule) para que o time do
projeto possa então conjecturar sobre possíveis causas que determinaram (ou determinarão, no caso
da prevenção de um possível problema – muito comum no trabalho de levantamento de riscos) o
problema, assim como eventuais efeitos/consequências, caso o problema efetivamente ocorra.
Trata-se de uma análise situacional que gera grande empatia pelo problema e alto grau de
colaboração da equipe, pois avalia uma espécie de anatomia de causa e efeito, semelhante a modelos
de mapas mentais. É uma técnica facilmente adaptável, podendo, por exemplo, o problema ser
separado em partes gerenciáveis e definíveis, auxiliando a focar nos objetivos que priorizem uma
solução (mais imediata ou mais barata, apenas para citar uma opção).

115
 Figura 33 – Árvore do problema

Fonte: elaborado pelo autor.

Inspeções
A partir de normas e documentos, constituir responsabilidades para examinar
minuciosamente um determinado produto, componente, processo e experiência de serviço, entre
outras possibilidades, visando à garantia de que o resultado da aferição esteja alinhado com o
previsto. Pode ser realizada por meio de amostragens ou de maneira mais específica. Veremos, a
seguir, algumas das técnicas/ferramentas de inspeção.
Lista ou folha de verificação (checklist ou checksheet) – segundo o PMI (2017a, p. 751), é
“[...] uma ferramenta estruturada para verificar se um conjunto de etapas exigidas foi executado”. Pela
sua simplicidade, é outra ferramenta considerada como uma das sete básicas da qualidade e serve
como uma representação gráfica para a coleta de informações pré-estruturadas, visando à
uniformização dos processos de monitoramento. Alguns modelos mais conhecidos são padronizados
por organizações, por associações profissionais ou por provedores de serviços comerciais.

116
 Figura 34 – Lista de verificação

Lista de verificação

Problema:

Estágio de verificação: Data:

Produto: Seção:

Total inspecionado: Inspetor:

Lote: Turno:

Tipo de defeito Contagem Subtotal

Arranhão

Trinca

Revestimento inadequado

Mancha

Acabamento inadequado

Outros

TOTAL

Total rejeitado

Fonte: COUTINHO (s. d.).

Medições de controle da qualidade – técnica de documentação dos resultados das atividades

definidas para o controle da qualidade, exatamente como estipuladas no plano de gerenciamento
da qualidade, visando a uma correta definição do produto (ou parte), do serviço ou do resultado a
ser gerado. Costumam ser documentos extremamente técnicos e informativos, com alto grau de
responsabilidade pelas informações transmitidas.

117
 Figura 35 – Medições de controle da qualidade

Fonte: COLUMBUS MCKINNON (2012).

Cultura customer centric

Colocar o cliente/usuário final no centro da estratégia de desenvolvimento das soluções
geradas pela equipe de um projeto é demonstrar propósito de entrega de valor percebido, em cada
etapa do produto, serviço ou resultado apresentado. Técnicas e ferramentas customer centric
costumam ser estimuladas por organizações que adotam um tipo diferenciado de cultura

118
organizacional comumente com um nível de relacionamento muito próximo aos seus
clientes/usuários finais. Equipes com esse tipo de modelo mental costumam trabalhar antecipando
as necessidades dos clientes, por meio de processos empáticos, muitos ciclos de feedbacks e processos
de interação facilitados. São muitas as possibilidades de práticas voltadas a esse tipo de abordagem,
mas demonstraremos apenas algumas a seguir.
Mapa de empatia – são muitas as versões e as possibilidades trazidas por uma ferramenta tão
poderosa, pois o mapa de empatia, como o próprio nome diz, faz a equipe do projeto se colocar no
lugar do cliente e passar a pensar e se portar, como o cliente/usuário final, antevendo e avaliando
necessidades/expectativas que possam determinar requisitos da qualidade de um determinado
produto, serviço ou resultado. Também pode ser utilizada como ferramenta para gerir e
compreender melhor importantes stakeholders.

Figura 36 – Mapa de empatia

Fonte: PEREIRA (2017).

Personas – técnica que cria personagens semifictícios baseados em experiências de consumo

ou de utilização de serviços ao caracterizar avatares que correspondem ao perfil de um cliente ideal,
ou seja, permite compreender melhor quem é o seu potencial cliente e do que ele precisa. O objetivo
principal dessa técnica é basear ações comerciais, como as de mídias digitais, para permitir um maior
grau de conexão da marca/produto/serviço com o cliente/usuário final ideal. Quanto à qualidade,

119
antecipa a equipe do projeto a definir premissas e requisitos indispensáveis da qualidade.
Comumente é complementada com uma técnica conhecida como jornada do usuário, que permite
avaliar um estilo de vida de uma determinada persona e auxiliar a identificar os momentos em que
tal personagem se conecta com a marca/produto/serviço e quais desses momentos são mais propícios
para interações com o indivíduo, visando à melhoria da experiência de usuário.

Figura 37 – Personas

Fonte: NARAYAN (2016).

O universo de atuação do gerenciamento da qualidade é vasto e quase infinito, tamanhas são

as possibilidades de utilização de ferramentas, práticas e frameworks que podem auxiliar os trabalhos
de uma equipe de projetos. Apesar de não termos visto muitas delas, vale uma rápida menção a
algumas que também possuem utilizações consolidadas no mercado, como auditorias (avaliação
independente que visa a confirmar se as muitas atividades do projeto estão efetivamente cumprindo
normas, políticas, processos e procedimentos da qualidade da organização detentora do projeto),
design for X (significa, em um dado momento do projeto, direcionar o trabalho de design de um
determinado produto – ou parte – para algum tipo de customização ou aspecto específico do design,
como usabilidade, segurança, ergonomia, qualidade e confiabilidade, entre muitos outros possíveis);
técnicas para resolução de problemas (visam a descobrir soluções para potenciais desafios ou algum
tipo de questão específica, podendo incluir técnicas de observação, de criatividade – design thinking,
design service ou design sprint, por exemplo – métodos quantitativos/lógicos e ferramentas A3, entre

120
muitos outros possíveis); e, métodos para a melhoria da qualidade, como representações gráficas
(diagramas de dispersão e outros tipos de representação de dados), SIPOC – Supplier-Input-Process-
Output-Customer, BPM – Business Processes Management, seis sigma, Casa da Qualidade e ToC –
Theory of Constraints (teoria das restrições).
Já presenciei muitas maneiras de se adaptar grande parte das técnicas e das ferramentas
demonstradas neste capítulo. Vou tentar traduzir a minha preocupação por meio de um exemplo
prático. Certa vez, vi uma equipe de projeto utilizar uma variação de um diagrama de espinha de
peixe (fizeram as mesmas representações que transformariam a imagem final). No entanto, talvez por
desconhecimento da técnica completa, ou por algum aprendizado equivocado, não aplicaram
corretamente as técnicas destinadas à solução que foi gerada por Kaoru Ishikawa. O diagrama original
foi desenvolvido no segmento da produção industrial e servia para a avaliação de potenciais causas
vinculadas a métodos, materiais, mão de obra, máquinas, medidas e meio ambiente (os famosos 6Ms,
conforme vimos anteriormente). Eu percebi que, no momento da aplicação da ferramenta, os
membros da equipe faziam perguntas indiscriminadas e apenas alocavam as respostas como potenciais
grupos de problemas (categorizados em clusters), mas não necessariamente avaliando em relação aos
6Ms, como preconiza a aplicação da técnica. A verdade é que, independentemente de aplicarem a
técnica da maneira incorreta, o exercício de análise que foi realizado pela equipe gerou uma série de
insights importantes e conseguiu o efeito desejado, que era o de encontrar relações de causa e efeito
acerca dos problemas discutidos. No final, a técnica adaptada serviu ao propósito do time e beneficiou
o desenvolvimento do projeto. A questão então é, sem dúvida alguma, que é importante conhecer
técnicas, ferramentas e as suas corretas utilizações, mas não devemos nos privar de adaptá-las, caso
isso faça sentido para o trabalho de execução da qualidade que vem sendo desenvolvido pelo grupo.
Devemos ter cuidado apenas com invenções fora de propósito que façam o time do projeto perder
tempo e investir esforços apenas naquilo que realmente possa trazer benefícios. Além disso, devemos
abrir a cabeça para inúmeras possibilidades de ferramentas e técnicas que existem no mercado, pois a
lista é vasta e as propostas de utilização podem surtir efeitos interessantíssimos, não só no resultado
final do projeto mas também no moral da equipe.

Relatório de execução da qualidade

O trabalho da qualidade demonstra a sua força a partir do momento em que a execução da
qualidade ganha vida. É por meio dos muitos relatórios de qualidade (ou de auditoria de qualidade),
muitas vezes contendo informações traduzidas por gráficos, tabelas e avaliações
qualitativas/quantitativas, que as informações da qualidade são oficialmente compartilhadas com
todas as principais partes interessadas, servindo de referência para muitos outros processos que
necessitam ser complementados por meio desse tipo de informação. Em suma, a gama de

121
informações proveniente de um relatório de qualidade auxilia na adoção de ações corretivas/
preventivas e na busca plena por atingir o maior nível de satisfação possível das principais partes
interessadas. Segundo o PMI (2017a, p. 332), os relatórios de qualidade

[...] podem incluir todos os problemas de gerenciamento da qualidade

encaminhados pela equipe; recomendações para melhorias em processo,
projeto e produto; recomendações de ações corretivas (incluir retrabalho,
reparo de defeitos/bugs, inspeção de 100% e mais); e o resumo das
conclusões do processo de controle da qualidade.

Um template pode ser apreciado a seguir.

Figura 38 – Relatório da qualidade

Título do projeto: _________________________ Data de elaboração: ______________

Auditor do projeto: _______________________ Data da auditoria: _______________

1. Área auditada

2. Boas práticas a compartilhar

3. Oportunidades para melhorias

4. Relatório de defeitos

ID Descrição Ação Responsável Data de entrega

5. Comentários

Fonte: adaptado de SNYDER (2013).

Qualquer aspecto do projeto ou do produto é passível de ser auditado, sendo que é

importante frisar que todo e qualquer trabalho de auditoria precisa ser adaptado para melhor
atender às necessidades do projeto e da organização.

122
 No modelo disponibilizado, iniciamos o relatório de qualidade (item 1) com um informe
sobre a área ou o que está sendo auditado. De acordo com Snyder (2013, p. 152):

As áreas comuns para auditoria incluem: processos de projeto, documentos

do projeto, requisitos do produto, documentos do produto, implementação
das mudanças aprovadas, implementação da ação corretiva ou preventiva,
correção do defeito ou da deficiência, conformidade com as políticas e
procedimentos organizacionais, e conformidade com o plano de qualidade.

Para otimizar o trabalho de gestão do conhecimento e de aprimoramento da qualidade

visando aos esforços de melhoria contínua, o item 2 existe para que o responsável pelo relatório
possa descrever todas as práticas advindas do recém-trabalho de auditoria e que devam ser
compartilhadas, seja entre setores da mesma organização, seja entre diferentes times de projeto, seja
até mesmo entre diferentes organizações. Há quem goste de categorizar esse tipo de informação
diretamente no relatório. O item 3 deve descrever todas as áreas que tiveram algum tipo de
identificação de melhoria, assim como processos e estrutura, entre muitas outras informações que
possam representar um futuro com melhor aproveitamento de recursos ou de esforços, por exemplo,
medições específicas que precisam ser alcançadas. No item 4, temos o exemplo de um relatório
dentro do próprio relatório, em que todos os defeitos encontrados por ocasião da auditoria de
qualidade precisam ser catalogados, categorizados e descritos, assim como quais seriam as potenciais
ações corretivas sugeridas para solucionar cada um dos problemas, incluindo responsáveis e datas
limite. Por fim, no item 5, deve-se desenvolver qualquer tipo de comentário extra que possa ser útil
para o público-alvo desse documento. Indicações de documentos, como normas, pareceres técnicos
ou standards (padrões) são algumas das possíveis referências.
Documentos de teste e avaliação também costumam ser responsáveis por muitos relatórios,
pois avaliam o cumprimento dos objetivos da qualidade. Normalmente, são gerados com base em
modelos existentes na própria organização, adaptados às necessidades do mercado e do setor.

Controle da qualidade e relatório do desempenho do

trabalho
Se, eventualmente, existir a necessidade de algum tipo de ajuste durante as investidas da
equipe do projeto no gerenciamento da qualidade, a saída cabível é acionar o controle integrado de
mudanças do projeto, por meio de artefatos conhecidos como solicitações de mudança (change
request). Antes de tudo, porém, devemos olhar de uma maneira mais cuidadosa e perceber que para
que algo possa ser controlado deve também passar por algum tipo de verificação, pois somente
aquilo que se monitora é passível de controle. Então, a abrangência do conceito desse último

123
momento destinado ao trabalho da qualidade é ligeiramente maior do que se pode supor. Trata-se
de uma extensão natural do gerenciamento da qualidade, pois demonstra a necessidade de
monitoramento e documentação de todos os resultados dos processos derivados da execução da
qualidade. Além disso, os registros precisam ser avaliados para assegurar que o realizado vai ao
encontro do planejado. Caso esteja, significa dizer que a qualidade do projeto está sendo cumprida
e as entregas estão atendendo aos padrões da qualidade, de preferência, mapeados com os
clientes/usuários finais do produto, serviço, ou resultado que está sendo gerado pela equipe do
projeto. Com o OK da qualidade, o time responsável pelo escopo poderá prosseguir com os
trabalhos vinculados aos critérios de aceitação das entregas. No entanto, sempre que algo estiver em
desalinho com aquilo que deveria ter sido realizado ou, por exemplo, diferente da maneira como
um determinado estágio do produto deveria se portar, deve ser acionado o controle integrado de
mudanças, previsto por um plano de gerenciamento de mudanças do projeto.
Certamente, o rigor dispensado ao trabalho de controle da qualidade dependerá de uma série
de fatores, como estilos de gestão, restrições de budgets e setores para o qual o projeto será
desenvolvido, entre outros. Alguns setores naturalmente possuem controles de qualidade mais
rigorosos. Não dá para desenvolver um novo medicamento, por exemplo, sem que muitos rigores
da indústria farmacêutica sejam correspondidos à risca.
Então, para que possamos entender melhor como funciona o momento de controle da
qualidade, devemos antes avaliar que tipo de documentação a equipe do projeto terá em mãos para
desempenhar tal papel. Primeiramente, o plano de gerenciamento do projeto fornece informações
sobre o planejamento da qualidade, por meio do PGQ. É a maneira de possuirmos todas as
diretrizes e procedimentos da qualidade disponíveis para potenciais trabalhos de verificação. Na
sequência, potencialmente, devemos prestar atenção a alguns documentos do projeto, como o
registro das lições aprendidas (um dos documentos responsáveis por disseminar a gestão do
conhecimento, desde os primórdios do projeto, podendo trazer valiosas informações de fases
anteriores no intuito de aprimorar o trabalho do controle da qualidade); as métricas da qualidade
(documento necessário para que a verificação de conformidades possa ser realizada, pois serve para
descrever todos os padrões/atributos da qualidade desejados ao projeto e ao produto, serviço ou
resultado a ser gerado); e, a documentação de testes e de avaliações (documentos que auxiliam no
trabalho de mensuração dos objetivos da qualidade). Também chama atenção o fato de avaliarmos
dados de desempenho do trabalho, pois demonstram informações acuradas acerca do status do
produto, medições para desempenho técnico, assim como a correlação de informações da qualidade
e a sua influência para o desempenho do cronograma e dos custos, apenas para citar alguns dos
principais aspectos. Fatores ambientais da empresa comumente são apreciados, como a
possibilidade de utilização de sistemas de informações gerenciais (alguns específicos para a
qualidade), as regulamentações de órgãos governamentais, as normas e os padrões específicos para

124
uma determinada área de atuação. Por fim, restam os ativos de processos organizacionais, que
podem fornecer importantes informações acerca de padrões, certificações e políticas da qualidade,
templates da qualidade já existentes, políticas de comunicação de defeitos, procedimentos para a
emissão e a circulação de informações e de relatórios, entre muitos outros.
Como entrega, o PMI (2017a, p. 337) define “[...] qualquer produto, resultado ou
capacidade singular e verificável para realizar um serviço cuja execução é exigida para concluir um
processo, uma fase ou um projeto”. Simplesmente tudo aquilo que está pronto para a validação (ou
ser inspecionado), contanto que esteja determinado pelo plano do projeto para que isso ocorra. Ou
seja, potencialmente, tudo o que puder ser verificado, comparando-se o previsto com o realizado,
assim como todos os critérios de aceitação e de validação vinculados às entregas especificadas na
linha de base do escopo. É o ponto inicial da verificação, possuir algo para ser verificado. Essas
demandas chegam por meio de entregas mas também podem chegar por meio de solicitações de
mudanças aprovadas pelo comitê de mudanças do projeto. Solicitações de mudanças aprovadas que
chegam para o controle da qualidade são comumente vinculadas a reparos de defeitos e a revisão
dos métodos de trabalho, por exemplo, a necessidade de introduzir alguma ferramenta para o
controle da qualidade até então não discriminada pelo PGQ. Além disso, não é difícil surgirem
solicitações que são implementadas de maneira parcialmente correta ou, até mesmo, de maneira
errada, gerando novos registros de defeitos/falhas (e, potencialmente, futuras novas solicitações de
mudanças que ainda precisarão ser avaliadas pelo comitê de mudanças).
Nem sempre um projeto executa as tarefas de maneira perfeita e sempre que há a chance de
se avaliar uma situação de desconformidade, potencialmente, uma grande onda de dados é gerada
motivando ações e responsabilidades, que tendem a recolocar o trabalho da equipe do projeto em
um novo rumo (de preferência, o rumo correto). Portanto, independentemente de boas ou más
notícias, o papel fundamental desse processo é o de conscientizar a equipe sobre os resultados,
motivando-a para alcançar os objetivos elencados no plano de gerenciamento da qualidade, fornecer
feedback (o mais rápido possível) para a busca da garantia da qualidade (composta por análise de
dados, localização de defeitos, propostas de melhoria contínua e atualizações no PGQ) e prover
subsídios para que todas as ações corretivas possam ser realizadas, evitando-se novas ocorrências.
Exatamente por isso, há necessidade de documentar informações sobre o desempenho do
trabalho. Esses registros costumam ser documentos extensos, confeccionados com as referências
apontadas nos dados sobre o desempenho do trabalho, comumente materializados como relatórios
de status da qualidade ou de desempenho do trabalho (ou do projeto). Um exemplo de template
pode ser visualizado a seguir.

125
 Quadro 12 – Relatório de desempenho do trabalho

Título do projeto: _________________________ Data de elaboração: ______________

Gerente do projeto: _______________________ Patrocinador: ___________________

1.
1. Realizações para o período do relatório 2.
3.

1.
2. Realizações planejadas, mas não
2.
concluídas no período do relatório
3.

3. Causa-raiz / justificativas para o item 2

4. Impacto sobre marcos futuros ou data

de entrega do projeto

5. Ações corretivas ou preventivas

planejadas para o item 4

6. Recursos financeiros consumidos no

período do relatório

7. Causa-raiz / justificativas para o item 6

8. Impacto sobre o orçamento geral ou

recursos financeiros de contingência

9. Ações corretivas ou preventivas para o

item 8

1.
10. Realizações previstas para o próximo
2.
período ou próximo relatório
3.

11. Custos previstos para o item 10

12. Novos riscos identificados

13. Questões

14. Observações finais / comentários

Fonte: adaptado de SNYDER (2013).

No item 1, devemos informar todos os pacotes de trabalho ou demais realizações/tarefas

importantes que foram concluídas no período destinado ao relatório. No item 2 é a mesma coisa, mas
dessa vez, devemos informar aquilo que havia sido planejado e que, por alguma razão, não foi
concluído, no mesmo período. Na sequência (item 3), devemos informar todas as justificativas,
variações ou causas-raiz referentes às informações do item anterior. O número 4 também é referente

126
ao item 2, pois ainda é sobre aquilo que não foi realizado (mas deveria ter sido). Deve-se demonstrar
qualquer tipo de impacto em relação ao cronograma do projeto, fazendo menção de potenciais
problemas no caminho crítico e variações de indicadores de tempo. O item 5 trata de possíveis ações
necessárias para compensar as variações que foram influenciadas pelo item 2 ou, ainda, em uma visão
de futuro, já avaliar ações para evitar variações futuras do cronograma. Os itens 6 a 9 são uma análise
muito semelhante do que foi realizado em relação ao cronograma, mas dessa vez demonstrando as
informações financeiras. Deve-se avaliar os custos do período; informar as variações, assim como as
suas justificativas (por exemplo, as diferenças entre variações de custos de mão de obra versus variações
nos custos dos materiais); definir os impactos no orçamento geral ou informar se os recursos de
contingência deverão ser acionados; e, por fim, informar as ações necessárias para a recuperação das
variações dos custos já incorridos ou as visões de planejamento, no intuito de evitar variações futuras
no orçamento. Nos itens 10 e 11, devemos definir todos os pacotes de trabalho ou realizações/tarefas
que serão conduzidos até o período limite vinculado ao próximo relatório, incluindo os recursos
financeiros necessários. No item 12, devemos avaliar os riscos potenciais que possam advir das
informações já descritas no relatório. Essas informações serão remetidas como base de atualização do
registro dos riscos do projeto. No item 13, devemos registrar potenciais questões que possam advir
das informações já descritas no relatório. Essas informações serão remetidas como base de atualização
do registro das questões do projeto. Por fim, o item 14 é um campo aberto para registrar quaisquer
comentários ou observações finais, ou até menções a anexos ou informações externas que tenham um
grau de relevância para o conteúdo apresentado pelo relatório.
O controle da qualidade ocorre ao longo de todo o projeto, pois a todo instante existem
entregas (resultados oriundos de outros processos) que necessitam ter os seus padrões e as suas
especificações avaliados, ou seja, se os critérios de aceitação e de validação definidos pela equipe do
projeto, com base nas interações com o patrocinador do projeto ou os seus clientes/usuários finais,
foram corretamente atendidos. É comum, em abordagens ágeis ou híbridas, que toda a equipe
participe do propósito de controlar a qualidade. Já nos projetos com uma abordagem mais preditiva,
costumam-se determinar momentos específicos, normalmente, próximos do final de uma fase ou
do próprio projeto, além de demandarem profissionais específicos para o trabalho.
Um bom trabalho da equipe do projeto vinculado ao controle da qualidade gera uma série
de informações, muitas delas com o poder de influenciar processos importantes de tomadas de
decisão de apoio a medidas técnicas ou estratégicas. Pode-se dizer que, no caso de um trabalho
perfeito, o grande objetivo desse momento seria o de confirmar esse status de conformidade,
permitindo corroborar a ideia de que tudo está conforme planejado e que todas as métricas foram
confirmadas, estando de acordo com os padrões e as especificações da qualidade definidos no
momento do planejamento.

127
Retrospectiva do módulo
A unidade VII encerrou os trabalhos da qualidade apresentando como eles são conduzidos na
prática. Gerenciar a qualidade talvez seja um dos desafios mais estimulantes de um projeto, pois
muitas variáveis assolam o seu fiel cumprimento. O alinhamento perfeito dos trabalhos da qualidade
com o que ocorre em face do desenvolvimento do produto, serviço ou resultado que está sendo gerado
pela equipe do projeto visa ao alinhamento total com os demais temas trabalhados pela equipe, por
exemplo, o gerenciamento dos custos, dos recursos e dos riscos, entre muitos outros.
Tivemos a oportunidade de avaliar uma série de práticas adaptadas à qualidade que poderão
ser utilizadas pela equipe de projeto, cada uma delas dependendo dos objetivos estratégicos
estabelecidos para o cumprimento dos resultados e dos benefícios vinculados ao projeto. Entre essas
muitas práticas, demonstramos que processos integrados e de melhoria contínua devem receber
atenção constante, seja por meio das reuniões de manutenção (desejável sempre que o nível de
sobrecarga começa a atrapalhar o desempenho do time), seja pelas reuniões de refinamento
(importantes para reavaliações de prioridades e sintonias finas de planejamento), seja por meio de
fichas/folhas de controle. Também pudemos visualizar a importância de testes em todos os níveis
de desenvolvimento do produto, serviço ou resultado que está sendo gerado, assim como a
necessidade de estudos/análises de causa e efeito (ou causa-raiz). Estes últimos, referenciados por
uma série de ferramentas interessantes, que, na maioria das vezes, produz grandes momentos de
colaboração, desempenhando um papel sobrecomum no status de motivação das equipes.
Ferramentas como o diagrama de Ishikawa, o diagrama de Pareto e a árvore do problema são simples
de serem utilizados e têm o potencial de produzir excelentes ideias, que se transformam em ações
no intuito de solucionar problemas, dos mais simples aos mais complexos.
Inspeções também demonstram ser uma técnica que, quando bem trabalhadas, produzem
efeitos interessantes, principalmente, por permitirem uma avaliação relativamente rápida e a
chance de uma avaliação parcial, por meio de amostragens de grandes quantidades. Foram
demonstradas as técnicas de listas de verificação e de medições de controle da qualidade. Para
finalizar, vimos o poder da qualidade em projetos ou organizações que desenvolvem trabalhos
com o modelo mental centrado no cliente/usuário final e percebemos que a qualidade é
desenvolvida até mesmo de maneira preventiva, tentando conhecer o cliente/usuário final por
todos os pontos de vista, gerando níveis de interação elevados e um cliente/usuário final
fidelizado. Por fim, ainda demonstramos dois templates úteis para a qualidade: o de relatórios de
execução da qualidade e o do relatório de desempenho dos trabalhos.

128
 Uma correta aplicação da qualidade passa pela fase de planejamento e segue um curso natural
de aderência aos padrões e métricas da qualidade estabelecidos, culminando com a avaliação final
do cumprimento das condições técnicas, assim como de objetivos de negócio para os quais o
produto, serviço ou resultado estão sendo gerados. A busca pelo êxito no trabalho da qualidade visa
à execução de tudo aquilo que foi planejado no plano de gerenciamento da qualidade, com a
posterior obtenção de todos os padrões estipulados pelas métricas da qualidade.
Ao estudarmos esses últimos tópicos, encerra-se mais uma fase de aprendizado, pois não somente
é possível visualizar, compreender e praticar toda a abrangência da qualidade destinada a um projeto,
independentemente do setor, tipo ou porte, assim como integrar o assunto da qualidade com qualquer
outra temática do projeto. Percebemos que qualidade não é só uma maneira de avaliar o sucesso do
trabalho da equipe do projeto e os níveis de satisfação das principais partes interessadas mas também
serve para aperfeiçoar competências, gerando um maior grau de maturidade para as organizações.
A qualidade pode (e deve) ser mensurada constantemente em relação aos processos do
gerenciamento profissional de projetos, gerando impacto direto na redução de esforços, na sobrecarga e
no nível de defeitos; e também em relação à qualidade técnica do produto, serviço ou resultado que está
sendo gerado pela equipe do projeto, visando a melhorar, cada vez mais, os índices de entrega de valor
percebido e de satisfação do cliente/usuário final, além do patrocinador do projeto.

129
BIBLIOGRAFIA
ADAMY, A. P. do A. et al. O uso de controle estatístico de processo como forma de garantia
de qualidade para o cliente: aplicação em uma indústria metalmecânica. Revista Espacios, n. 03,
v. 38, p. 6, 2017.

ANDRADE, L. Como fazer PDCA passo a passo?. 2017. Disponível em:

https://www.siteware.com.br/metodologias/como-fazer-pdca-passo-a-passo/. Acesso em: 10 mar. 2020.

AUDY, J. Scrum 360: um guia completo e prático de agilidade. São Paulo: Casa do Código, 2015.

BECK, K. et al. Manifesto ágil para o desenvolvimento de softwares. 2001. Disponível em:
http://www.manifestoagil.com.br/. Acesso em: 5 fev. 2020.

BENSON, J.; BARRY, T. D. Personal Kanban. Mapping work. Navigating life. Modus
Cooperandi Press, 2011.

BORGES, L. O que é o famoso diagrama de Pareto (80/20) – passo a passo. 2014. Disponível em:
https://blog.luz.vc/o-que-e/diagrama-de-pareto-8020-passo-a-passo/ Acesso em: 18 mai. 2020.

CALDAS, L.; SALGADO, S. M. Gestão da qualidade aplicada ao processo de projeto de avaliação

do ciclo de vida (ACV) para edificações. In: SIMPÓSIO BRASILEIRO DE QUALIDADE DO
PROJETO NO AMBIENTE CONSTRUÍDO. 2017. João Pessoa. Anais... Porto Alegre:
ANTAC. p. 1-12. Disponível em: https://www.researchgate.net/publication/321058197
_GESTAO_DA_QUALIDADE_APLICADA_AO_PROCESSO_DE_PROJETO_DE_AVALI
ACAO_DO_CICLO_DE_VIDA_ACV_PARA_EDIFICACOES. Acesso em: 15 mai. 2020.

CAROLI, P. Direto ao ponto: criando produtos de forma enxuta. São Paulo: Casa do Código, 2015.

CAROLI, P. O canvas MVP. 2018. Disponível em: http://www.caroli.org/o-canvas-mvp. Acesso

em: 12 dez. 2019.

COLUMBUS McKINNON CORPORATION. Site oficial. 2012. Disponível em:

http://www.cmdobrasil.com.br/gn_manilhas.html. Acesso em: 29 abr. 2020.

COUTINHO, T. Folha de verificação: saiba tudo sobre essa ferramenta da qualidade!. [s. d.].
Disponível em: https://www.voitto.com.br/blog/artigo/folha-de-verificacao. Acesso em: 19 mai. 2020.

130
CLELAND, D. I. Why project management? Business Horizons. USA, 1964.

CRUZ, F. PMO Ágil. Escritório ágil de gerenciamento de projetos. Rio de Janeiro: Brasport, 2016.

CRUZ, F. Scrum e agile em projetos: guia completo. Rio de Janeiro: Brasport, 2015.

CRUZ, F. Estimativas. [s. d.]. Disponível em: http://www.fabiocruz.com.br/frameworkscrumold/

sprint-planning-sp1. Acesso em: 10 jun. 2019.

DEMING, W. E. Qualidade: a revolução da administração. São Paulo: Saraiva, 1990.

DORAN, G. T. There’s a S.M.A.R.T. way to write management’s goals and

objectives. Management Review, n. 70, v. 11, p. 35-36, 1981.

DRUCKER, P. The practice of management. New York: Harper & Brothers, 1954.

ESCRITÓRIO DE PROJETOS. Métricas da qualidade. 2020. Disponível em:

https://escritoriodeprojetos.com.br/metricas-da-qualidade. Acesso em: 28 abr. 2020.

GADDYS, P. The project manager. Harvard Business Review. USA, May/June, 1959.

GUIMARÃES, C. Escopo do projeto: 7 dicas para você ter sucesso nessa etapa. 2019. Disponível
em: https://www.voitto.com.br/blog/artigo/escopo-do-projeto. Acesso em: 15 mai. 2020.

JEFFERY, R. Putting de “V” in MVP. InfoQ. 2018. Disponível em: https://www.infoq.com/

presentations/mvp-lean-product. Acesso em: 12 jun. 2019.

JURAN, J. M. A qualidade desde o projeto. Os novos passos para o planejamento em produtos e serviços.
São Paulo: Cengage Learning, 2009.

JURAN, J. M.; GODFREY, A. B. (eds.). Juran’s Quality Handbook, 5. ed. New York: McGraw-
Hill Education, 1999.

KANBANIZE. 5 Porquês: a melhor ferramenta para a análise de causa raiz. [s. d.]. Disponível
em: https://kanbanize.com/pt/gestao-lean/melhoria/5-porques-ferramenta-de-analise. Acesso
em: 18 abr. 2020.

131
KURTZ, C. F.; SNOWDEN, D. J. The new dynamics of strategy: Sense-making in a complex
and complicated world. IBM Systems Journal, v. 42, n. 3, p. 462-483, 2003.

LOCKE, E. Toward a theory of task motivation and incentives. New York: Harper & Row, 1968.

LOUZADA, P. É possível controlar o escopo do seu projeto?. 2017. Disponível em:

https://www.fm2s.com.br/gestao-escopo-projeto/. Acesso em: 11 abr. 2020.

MASSARI, V. L. Agile scrum master no gerenciamento avançado de projetos. Rio de Janeiro: Brasport,
2016.

MASSARI, V. L. Gerenciamento ágil de projetos. Rio de Janeiro: Brasport, 2014.

MASSARI, V. L. Percepções sobre a 6ª edição do PMBOK e o Agile Practice Guide. 2017.

Disponível em: https://www.profissionaisti.com.br/2017/10/percepcoes-sobre-a-6a-edicao-do-
pmbok-e-o-agile-practice-guide. Acesso em: 11 nov. 2019.

MENEZES, L. C. de M. et al. Gerenciamento de escopo em projetos. 3. ed. Rio de Janeiro: FGV, 2014.

MOORE, A. G. Crossing the Chasm: marketing and selling high-tech products to mainstream
customers. USA: Harper Business Essentials, 1999.

NARAYAN, A. Growth hacking 101: growth metrics, lean analytics & growth culture. 2016.
Disponível em: https://www.slideshare.net/anirudhnarayan/growth-hacking-101-growth-metrics-
lean-analytics-growth-culture. Acesso em: 19 maio 2020.

PEREIRA, D. Mapa de empatia. 2017. Disponível em: https://analistamodelosdenegocios.com.br/

mapa-de-empatia-o-que-e/. Acesso em: 19 mai. 2020.

PICHLER, R. Gestão de produtos com Scrum. Implementando métodos ágeis na criação e

desenvolvimento de produtos. Rio de Janeiro: Elsevier, 2011.

PROJECT BUILDER. 4 segredos para especificar requisites de forma ágil. 2017. Disponível em:
https://www.projectbuilder.com.br/blog/4-segredos-para-especificar-analise-de-requisitos/. Acesso
em: 28 mar. 2020.

PROJECT MANAGEMENT INSTITUTE (PMI). Practice standard for work breakdown

structures. 2. ed. USA: PMI Inc., 2006.

132
PROJECT MANAGEMENT INSTITUTE (PMI). Requirements management: a practice guide.
USA: PMI Inc., 2016.

PROJECT MANAGEMENT INSTITUTE (PMI). A guide to the project management body of

knowledge: PMBOK Guide. 6. ed. USA: PMI Inc., 2017a.

PROJECT MANAGEMENT INSTITUTE (PMI). Agile practice guide. USA: PMI Inc., 2017b.

PROJECT MANAGEMENT INSTITUTE (PMI). The PMI guide to business analysis. USA: PMI
Inc., 2017c.

PROJECT MANAGEMENT INSTITUTE (PMI). Pulse of the profession. 2018. Disponível em:
https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-
leadership/pulse/pulse-of-the-profession-2018.pdf?sc_lang_temp=en. Acesso em: 30 jun. 2019.

RIES, E. A startup enxuta. Como os empreendedores atuais utilizam a inovação contínua para criar
empresas extremamente bem-sucedidas. São Paulo: LeYa, 2012.

RESEARCH GATE. Disponível em: https://www.researchgate.net/figure/Figura-3-Diagrama-de-

Contexto-Sistema-de-Analise-Espaciais-para-Planejamento-Urbano-SPAE_fig16_321949922.
Acesso em: 8 dez. 2019.

RIBEIRO, R. Gerência de projetos em sistemas de informação. [s. d.]. Disponível em:

https://slideplayer.com.br/slide/11315661. Acesso em: 12 jun. 2019.

ROCHA, A. V. et al. Gerenciamento da qualidade em projetos. Rio de Janeiro: FGV, 2014.

ROSE, K. H. Project quality management. Why, what and how. J. Boca Raton: Ross Publishing, 2005.

SERPA, S. Project Management Knowledge Base (PMKB): restrições de projetos para reduzir
custos. 2017. Disponível em: https://pmkb.com.br/artigos/restricoes-de-projeto-para-reduzir-
custos. Acesso em: 3 dez. 2019.

SNYDER, C. S. Guia de templates para gerenciamento de projetos. Rio de Janeiro: Campus, 2013.

STANDISH GROUP. The chaos report: beyond infinity. 2020. Disponível em:
www.standishgroup.com/. Acesso em: 7 fev. 2020.

133
SUAREZ, G. A. 3Ks no lean: kaizen, kaikaku e kakushin. [s. d.]. Disponível em:
https://qualityway.wordpress.com/2019/02/17/3ks-no-lean-kaizen-kaikaku-e-kakushin-por-
gregorio-suarez/. Acesso em: 15 mai. 2020.

XAVIER, C. M. S. Gerenciamento de projetos: como definir e controlar o escopo do projeto. 2. ed.

São Paulo: Saraiva, 2009.

Bibliografia recomendada
PROJECT MANAGEMENT INSTITUTE (PMI). Practice standard for work breakdown
structures. 2. ed. USA: PMI Inc., 2006.
Um dos padrões (standards) vigentes mais antigos do PMI continua atual para aquilo a que
se propõe, ou seja, explicar o conceito e a importância estratégica na utilização de uma EAP
de alta qualidade. O livro é um roteiro simples e pode ser facilmente utilizado,
demonstrando os benefícios da utilização de uma EAP, não só em situações organizacionais
mas também em relação a situações cotidianas. A obra fornece elementos para o
desenvolvimento preliminar de uma EAP, a sua integração no contexto geral do
planejamento do escopo e a sua futura implementação como linha de referência do escopo
de um projeto.

PROJECT MANAGEMENT INSTITUTE (PMI). Requirements management: a practice guide.

USA: PMI Inc., 2016.
Com a referência de que organizações continuam experimentando problemas no
gerenciamento de projetos associados a baixos desempenhos em atividades relacionadas ao
gerenciamento dos requisitos, esse livro traz uma luz ao tema, fornecendo ferramentas e
desmistificando uma das principais etapas dos processos de gerenciamento do escopo, assim
como a sua ligação com os processos do gerenciamento da qualidade. O livro aborda o
desenvolvimento, a elicitação e o gerenciamento dos requisitos em um nível detalhado e
prático, seja para a implementação em projetos, programas ou portfólios, preenchendo uma
lacuna que perdurou durante muito tempo na área de projetos.

134
PROJECT MANAGEMENT INSTITUTE (PMI). A guide to the project management body of
knowledge: PMBOK Guide. 6. ed. USA: PMI Inc., 2017.
A principal publicação do PMI continua sendo um recurso fundamental para o
gerenciamento eficaz de projetos em qualquer setor. O Guia PMBOK® compõe os padrões
globais da metodologia proposta pelo PMI, refletindo de forma contínua e precisa uma
profissão que permanece em constante evolução. A novidade dessa última edição é que se
torna necessário avaliar diferentes abordagens para se trabalhar em um projeto, não mais
ficando um time preso a abordagens tradicionais. Exatamente por isso, essa publicação
precisa ser utilizada em sintonia, de maneira complementar, com o Agile Practice Guide.
Juntas, as duas publicações são uma ferramenta poderosa que permitirá definir qual deverá
ser a melhor abordagem a ser adotada para um determinado projeto.

PROJECT MANAGEMENT INSTITUTE (PMI). Agile practice guide. USA: PMI Inc., 2017.
Trata-se da grande inovação recente do PMI, que reflete as últimas tendências de pesquisas
mercadológicas e impulsiona um trabalho de décadas a um novo nível, abrindo a visão de
trabalhar gerenciamento de projetos por meio de práticas ágeis, de maneira específica ou
mesclada, com abordagens híbridas. As orientações são complementares ao padrão global
do Guia PMBOK® e, quando aplicadas em conjunto, apresentam soluções importantes para
profissionais de projetos que trabalham em busca das melhores soluções para os seus
produtos, serviços ou resultados que serão desenvolvidos. É uma leitura especialmente útil
para membros de times de projetos acostumados a um ambiente mais tradicional se
adaptarem a um mindset ágil, em busca de entrega de percepção de valor e verificação de
resultados mais imediatos.

SNYDER, C. S. Guia de templates para gerenciamento de projetos. Rio de Janeiro: Campus, 2013.
Muitos profissionais do gerenciamento de projetos se perdem diante das complexidades de
documentação ou, por exemplo, de monitoramento, em determinadas situações vinculadas
a um projeto real. A autora nos brinda com uma bela seleção de templates que podem ser
otimizados em relação às verdadeiras necessidades de cada projeto. Porém, a grande valia
desse livro, que está plenamente alinhado com as boas práticas preconizadas pelo Guia
PMBOK®, é mostrar modelos de documentos desde o início de um projeto até o seu
encerramento, passando por templates simples como o de uma ata de reunião – que serve,
entre outras coisas, para monitoramento e controle das comunicações de um projeto – até
um mais complexo, como um relatório de auditoria da qualidade.

135
PROFESSOR-AUTOR
Guilherme Hoffmann é mestre em Marketing
Internacional, pela Universidad Nacional de La Plata (Argentina),
especialista em Gerenciamento de Projetos e em Direito da
Economia e da Empresa, ambos pela Fundação Getúlio Vargas, e
graduado em Direito, pela Universidade Católica de Petrópolis.
Negociador certificado pela Fundação Getúlio Vargas e pelo
programa Negotiation and Leadership da Harvard Law School.
Business Executive Program, pela Donghua University – China.
Certified ScrumMaster® (CSM) e Certified Scrum Product Owner
(CSPO), ambos pela Scrum Alliance. UX designer pela Glasgow
Caledonian University. Agile Facilitator pela Knowledge21. Kanban
certified pela Lean Kanban University. HCMBOK 3G Practitioner
e HCMP 3G Expert Professional, ambos pelo Human Change Management Institute (HUCMI).
Formado em Management 3.0 – Change and Innovation Practices. Formado em Design Thinking
pela Echos Design Thinking. Teampreneur workshop certified pela Team Academy (Finlândia).
Consultor, agilista e facilitador com dezenas de projetos realizados, tanto em empresas
privadas como públicas, nos mais variados setores: Navegação, Óleo e Gás, Energia, Engenharia,
Serviços, Tecnologia da Informação, Educação, Grandes Eventos, Saúde, Bancário etc. Consultor
em Gerenciamento de Projetos e advogado. Conteudista e revisor técnico de materiais em
Gerenciamento de Projetos. Revisor oficial da Scrum Alliance. Professor convidado da Fundação
Getúlio Vargas, do Grupo IBMEC e da Escola Politécnica da Universidade Federal do Rio de
Janeiro (UFRJ).

136