Gestão de Processos Ágeis de

Desenvolvimento de Software
Aula 04
Project Model Canvas

Objetivos Específicos
• Conhecer a abordagem do Project Model Canvas como modelo para a gestão
de projetos ágeis.

Temas

Introdução
1 Project Model Canvas
Considerações finais
Referências

Professor Autor
Everton Michels
 Gestão de Processos Ágeis de Desenvolvimento de Software

Introdução
Nesta aula, abordaremos o tema “Project Model Canvas”. Esse canvas (quadro) foi
desenvolvido por José Finocchio Júnior e busca desburocratizar a criação de planos de projeto,
tornando-os mais simples e colaborativos.

Primeiramente abordaremos a concepção do plano, para entendermos detalhadamente

o que conceber e como definir o canvas.

Seguindo o modelo, o próximo passo será entender como se dá a integração de todo o

canvas para que seja algo coeso e conciso.

Após a abordagem da integração, trataremos da verificação de possíveis problemas que

ainda podem existir mesmo depois da integração, e assim tais questões são devidamente
resolvidas.

Por fim, veremos a saída do plano devidamente integrado e alinhado, o que fazer com
esse plano na prática e como o compartilhamento, que permite conhecer outras ferramentas
e técnicas, pode ser uma solução para a aplicação prática do plano.

1 Project Model Canvas

O Project Model Canvas é uma ferramenta lúdica capaz de ajudar o gerente de projetos,
bem como as partes interessadas, a melhor definir um plano de projeto por meio de uma
colaboração eficaz. Além disso, auxilia no entendimento amplo do projeto.

Esse canvas é desenvolvido com base em uma sequência bem definida de passos e
componentes, o que também facilita a construção de um modelo mental diferenciado e
coeso.

Para melhor contemplar todos os conceitos e o funcionamento do Project Model

Canvas, vamos dividir nosso estudo em 4 tópicos principais, são eles: concepção, integração,
resolução e compartilhamento. Em cada tópico, iremos detalhar essa poderosa ferramenta
para construção de planos de projeto visuais.

1.1 Concepção do canvas

A concepção do Project Model Canvas é talvez a parte principal do processo de
construção do modelo. Sua concepção se dá justamente por meio da colaboração entre as
partes interessadas, tornando assim o canvas muito mais realista. A figura 1 demonstra como
se dá a criação do modelo e, depois, explicaremos cada parte desse processo nos tópicos
seguintes.

Senac São Paulo - Todos os Direitos Reservados 2

 Gestão de Processos Ágeis de Desenvolvimento de Software

Figura 1 – Concepção do projeto segundo o Project Model Canvas

GP PITCH
JUSTIFICATIVAS PRODUTO STAKEHOLDERS PREMISSAS RISCOS
Passado EXTERNOS
& fatores externos

POR QUÊ? O QUÊ? QUANDO E

QUEM? COMO? QUANTO?
OBJ SMART REQUISITOS

EQUIPE GRUPO DE
ENTREGAS LNHA DO TEMPO

BENEFÍCIOS
Futuro

CUSTOS
RESTRIÇÕES

Fonte: Adaptada de Finocchio Júnior (2013, p. 49).

1.1.1 Gerente de projetos e pitch

Pertencem ao topo do canvas. Na figura 1, o espaço com a denominação “gerente de

projetos” deve conter o nome do gerente de projeto responsável pelo plano que se está
criando. Já o espaço designado “pitch” deve ser preenchido com uma frase curta que
identifique de forma clara o projeto.

1.1.2 Justificativa

O primeiro quadrante do modelo é o por quê, ou seja, a justificativa do projeto. A razão do

projeto está diretamente relacionada com a intenção de realizá-lo. As “dores” e os problemas
da organização podem fazer com que ela tenha a intenção ou necessidade de realizar ações
para mudar esse cenário, e tais ações são realizadas geralmente por meio de projetos.

As “dores” e os problemas acabam por apresentar situações atuais que não estão sendo
atendidas, o que leva justamente à necessidade de um projeto para que o projeto gere os
benefícios esperados.

As justificativas podem abordar também as oportunidades ainda não exploradas pela

empresa. É importante salientar que, para a identificação e escrita tanto das justificativas

Senac São Paulo - Todos os Direitos Reservados 3

 Gestão de Processos Ágeis de Desenvolvimento de Software

quanto dos outros pontos do canvas, as descrições devem ser claras e objetivas. A ideia é
que tais descrições sejam feitas, por exemplo, com post-its. Por isso, não podem ser textos
extensos e desinteressantes.

1.1.3 Objetivo (SMART)

O próximo passo do quadrante por quê é o preenchimento do objetivo. É por meio dele
que o projeto terá um entendimento geral. Finocchio Júnior (2013) explicita que, nesse caso,
a objetividade continua sendo importante: imagine que você terá que explicar o objetivo do
projeto, com seu escopo, prazo e custo, para um presidente de uma empresa dentro de um
elevador que percorrerá somente 4 andares.

Logo, a descrição do objetivo para o canvas deve ser direta, resumida, persuasiva e
pertinente. Deve ser indicado em não mais que 1 parágrafo.

Outro ponto importante para melhor guiar a definição de um objetivo claro e coeso é
um acrônimo em inglês: SMART. Para o canvas, o objetivo deve ser SMART. O acrônimo tem
a seguinte definição:

• S - specific (específico): devem-se utilizar qualificadores e adjetivos suficientes, para

deixar claro o projeto;

• M - measurable (mensurável): faz-se necessário indicar alguns números referentes ao

esforço do projeto ou aos resultados principais;

• A - achievable (alcançável): indicar como o projeto é possível de ser realizado com as

competências que estão ao alcance da empresa;

• R - realistic (realista): deve-se mostrar que o projeto é passível de realização com o

tempo e recursos disponíveis;

• T - time-based (baseado no tempo): deve-se definir em quanto tempo o projeto será

realizado (FINOCCHIO JÚNIOR, 2013).

1.1.4 Benefícios

São o último item do quadrante por quê. Resumidamente, os benefícios poderão ser
visualizados por meio das melhorias e do valor agregado gerado pelo produto do projeto.
Para guiar a elaboração dos benefícios, pode-se levar em conta 4 ou mesmo 5 grandes
categorias, são elas: aumento de receita; diminuição de custos; uso mais eficiente dos ativos
existentes; melhoria da imagem da empresa e, quando a empresa está engajada com o fator
sustentabilidade, o atenuamento dos impactos sociais e ambientais.

Senac São Paulo - Todos os Direitos Reservados 4

 Gestão de Processos Ágeis de Desenvolvimento de Software

Finocchio Júnior (2013) explicita que, se o projeto possui benefícios que atendam aos
objetivos estratégicos da organização, tais melhorias podem ser classificadas com base em
alguma escala para identificar quais são as que mais e menos atendem aos objetivos. Dessa
forma, os benefícios podem ser priorizados e cobrados quando possível.

Essa identificação de “benefícios estratégicos” poderá auxiliar posteriormente na

priorização do portfólio da organização, pois, como sabemos, os recursos são finitos. Em
dados momentos, nem todos os projetos previstos serão realizados, e a priorização poderá
ajudar a definir os projetos que serão executados com base nos seus benefícios.

Os benefícios serão a resposta direta para cada justificativa indicada no canvas. Pode-se
ter para cada justificativa um benefício correspondente, não limitando-se a apenas um, é
claro.

1.1.5 Produto do projeto

Neste ponto, entramos no quadrante o quê. O produto do projeto é a saída direta que ele
irá gerar no final do seu prazo de desenvolvimento. Todo projeto terá um produto, serviço ou
resultado vinculado, e este deverá gerar os benefícios esperados para atender às justificativas
levantadas.

O produto do projeto é justamente o que será entregue ao cliente no final do projeto.

Assim, tal produto deve possuir características claras e mensuráveis.

Para melhor explicar os 3 tipos de saídas geradas por um projeto, vamos verificar alguns
exemplos dados por Finocchio Júnior (2013).

a. produto – Desenvolvimento de um novo aplicativo para controlar estoques.

b. serviço – Migração da versão antiga de um aplicativo para a nova em um cliente.

c. resultado – Obtenção de uma certificação de maturidade organizacional fornecida

por uma certificadora tradicional.

1.1.6 Requisitos

São o último item do quadrante o quê. Para Finocchio Júnior (2013, p. 67), os requisitos
“são a maneira de o cliente comunicar para a equipe aquilo que lhe parece necessário ou
desejável no produto que vai receber ao término do projeto”.

No entanto, há que se lembrar que, como o canvas é um modelo simplificado, as

partes interessadas devem relatar os principais requisitos de forma sucinta, sem entrar em
especificidades e detalhes.

Senac São Paulo - Todos os Direitos Reservados 5

 Gestão de Processos Ágeis de Desenvolvimento de Software

1.1.7 Stakeholders externos e fatores externos

Para o Project Management Institute (PMI, 2013, p. 30), os stakeholders ou partes

interessadas são “um indivíduo, grupo ou organização que pode afetar, ser afetada ou sentir-
se afetada por uma decisão, atividade ou resultado do projeto”.

É o quadrante quem do Project Model Canvas, que complementa a definição do PMI

ao explicitar que os stakeholders externos podem ser as pessoas ou organizações que não
necessariamente realizam trabalho no projeto, mas podem interagir com ele. Finocchio
Júnior (2013, p. 120, grifos do autor) ainda acrescenta que “os STAKEHOLDERS EXTERNOS não
estão subordinados ao gerente de projeto e estão fora de sua esfera de controle. FATORES
EXTERNOS que afetam o projeto também podem ser listados para que com frequência sejam
monitorados”.

1.1.8 Equipe

Também pertence ao quadrante quem. Para o PMI (2013), a equipe do projeto também
faz parte dos stakeholders do projeto. Para o Project Model Canvas, essas partes interessadas
são divididas entre externas, como já foi visto, e internas, em que a equipe de desenvolvimento
se enquadra.

Finocchio Júnior (2013, p. 121) aborda a equipe de desenvolvimento como sendo “todos
aqueles que trabalham e efetuam entregas do projeto. Podemos considerar da equipe
terceiros que efetuam entregas do projeto e são gerenciados pelo gerente do projeto”.

No quadrante quem, ainda temos o item “restrições”, que será abordado mais adiante.

1.1.9 Premissas

Entramos no quadrante como. Para saber como o trabalho será realizado, o primeiro
item a ser preenchido são as premissas.

Para Finocchio Júnior (2013, p. 122), as premissas “são suposições arbitrariamente dadas
como certas sobre o ambiente externo e fatores externos ao projeto os quais não estão sob
controle do gerente de projetos”.

É interessante enaltecer o fato de as premissas serem aspectos não controlados pelo

gerente de projetos. Isso é o que diferencia uma premissa de uma restrição, como veremos
posteriormente. Além disso, uma ou mais premissas podem invariavelmente gerar uma ou
mais restrições.

Senac São Paulo - Todos os Direitos Reservados 6

 Gestão de Processos Ágeis de Desenvolvimento de Software

1.1.10 Entregas

Também pertencem ao quadrante como. Finocchio Júnior (2013, p. 123) define as

entregas ou grupo de entregas como os “componentes concretos, tangíveis e mensuráveis
produzidos pelo projeto e que se integrados constituirão tudo que é produzido no projeto.
Podem ser entregas finais ou intermediárias”.

As entregas correspondem àquilo que o projeto vai oferecer de forma gradativa,

ou intermediária, até sua finalização. Como o canvas está baseado na simplicidade e na
generalidade, sem a preocupação com detalhamentos infinitos, é interessante frisar que essas
entregas são macros e, por não estarem detalhadas neste momento, são tratadas justamente
como grupo de entregas.

1.1.11 Restrições

Para finalizar, pertencente aos quadrantes como e quem, temos o item “restrições”.
Como vimos anteriormente, as próprias premissas podem gerar restrições.

Então o que seriam restrições? Finocchio Júnior (2013, p. 123) explicita como sendo
“limitações de qualquer natureza e origem impostas ao trabalho realizado pela equipe de
projeto”.

Um pouco diferente das premissas, as restrições têm um nível maior de controle do que
as premissas, justamente porque estão diretamente ligadas ao trabalho da equipe do projeto.

Para melhor entender a diferença entre premissas e restrições, vejamos o exemplo

dado por Finocchio Júnior (2013). Cada trator Yuga 300 é capaz de entregar até 200 m2 de
pavimentação com operadores sênior. Não temos controle sobre a capacidade do trator, já
que a fabricante é que a define. Assim, teremos 2 restrições com base nessa premissa:

a. o gerente deverá alocar 4 tratores Yuga 300 por turno para obter 1.000 m2 de
pavimentação em cada turno;

b. todos os operadores de trator Yuga 300 devem ter nível sênior.

Logo, temos 2 restrições sobre as quais o gerente de projetos tem controle e que
precisam ser atendidas para não eliminarem uma premissa, o que pode vir a se tornar um
risco para o projeto.

1.1.12 Riscos

Entramos no último quadrante do canvas: quando e quanto. Os riscos invariavelmente

Senac São Paulo - Todos os Direitos Reservados 7

 Gestão de Processos Ágeis de Desenvolvimento de Software

poderão ser gerados pelas premissas e também pelas restrições, porém não se limitam
somente a isso.

Para Finocchio Júnior (2013, p. 123), os riscos “são eventos futuros e incertos que têm
relevância para os objetivos do projeto. Devem ser identificados, analisados e para os mais
significativos devemos implantar respostas”.

Para melhor esclarecer o que pode ser um risco, vejamos um exemplo dado por Finocchio
Júnior (2013).

• Causa do problema – pouco costume de exercitar-se;

• Risco – lesão com paralisação do treino;

• Efeito – diminuição do resultado, menor condicionamento físico.

1.1.13 Linha do tempo

É o segundo item do quadrante quando e quanto. A linha do tempo está diretamente

ligada às entregas ou aos grupos de entrega, por isso que, no canvas, uma fica ao lado da
outra.

Finocchio Júnior (2013) elucida a linha do tempo como um compromisso da equipe para
com as entregas do projeto ao longo de um dado tempo, ou seja, o tempo transcorrido do
início ao fim do projeto.

1.1.14 Custos

São o último item do quadrante quando e quanto. Finocchio Júnior (2013, p. 125) aborda
os custos como sendo o “quanto gastaríamos de mão de obra, materiais, equipamentos e
serviços em cada entrega? Em qual intervalo de valor situam-se as estimativas de custos do
projeto?”.

Assim, da mesma forma que a linha do tempo, os custos podem ter uma relação com as
entregas ou os grupos de entrega. As entregas servem como base para facilitar a estimativa
dos custos do projeto.

Finalizamos, portanto, o detalhamento de cada quadrante e cada item do Project Model

Canvas. Agora daremos início ao estudo da integração desses itens.

1.2 Integração dos itens do canvas

Nesta seção, descreveremos como se dá a integração dos 13 itens do Project Model

Senac São Paulo - Todos os Direitos Reservados 8

 Gestão de Processos Ágeis de Desenvolvimento de Software

Canvas, a fim de torná-la clara e compreensível para todos os envolvidos do projeto.

O processo de integração pretende tornar o modelo mental que o canvas representa

ainda mais forte. Essa integração é feita por amarrações entre 2 ou 3 itens do canvas,
permitindo à equipe agrupar suas ideias de forma mais eficiente. O ideal é que isso aconteça
logo após a construção do canvas, já que a equipe está no auge de sua motivação e com o
problema ainda em mente.

A integração acontece através de 8 passos bem definidos. Vejamos a seguir cada um

deles.

Passo 1: Os itens levantados na justificativa foram contemplados? Os problemas que foram

explicitados para a construção do projeto foram solucionados pelo canvas? Os problemas
traduzidos nas justificativas podem aparecer como soluções em pelo menos 3 outros itens
do canvas, são eles: benefícios, requisitos ou entregas. Dessa forma, podemos verificar se os
problemas levantados para a construção do projeto foram realmente solucionados no canvas.

Passo 2: O objetivo continua sendo suficiente? Deve-se checar se o objetivo continua sendo
adequado para atender aos benefícios e, assim, às justificativas levantadas. É fundamental
analisar é preciso melhorar o objetivo (SMART) acrescentando algum item relevante que foi
esquecido até então, ou se alguma descrição do objetivo não faz mais sentido e pode ser
retirada.

Passo 3: Os requisitos identificados possuem um dono e de fato contribuem para a

geração do produto? Se um requisito não contribuir para a geração do produto, será que não
seria uma restrição mal posicionada? Falta algum requisito que contribua para a construção
do produto? Existe algum stakeholder externo ligado à posse de algum requisito? Nesse
caso, ele pode ser o cliente do projeto. Existe mais de um dono para um requisito? Caso
sim, é preciso relacioná-los para deixar claro quem são os devidos responsáveis. Por fim, é
necessário verificar se os requisitos estão priorizados; caso contrário, isso deve ser feito.

Passo 4: Corresponde à identificação das partes interessadas de fato no projeto. A

primeira coisa a se perguntar é: o patrocinador está devidamente identificado? Além disso, o
gerente de projeto está relacionado à equipe no canvas e tem ligação com o patrocinador?
Por fim, é importante verificar se existe alguma entrega que não possua alguém relacionado,
ou mesmo se alguém da equipe não contribui para a realização de alguma entrega, ou ainda
se a equipe que vai entregar o core business do projeto está sob o controle direto do gerente
de projetos.

Passo 5: As premissas foram definidas de forma a serem convergentes e válidas? Para

Finocchio Júnior (2013, p. 136), 2 perguntas são essenciais neste passo, diretamente ligadas
aos stakeholders e aos fatores externos, são elas: “O que contamos que será provido por
cada um dos stakeholders externos ao projeto? No âmbito de quais parâmetros dos fatores
externos nosso plano vai funcionar?”. Além desses questionamentos, uma outra pergunta

Senac São Paulo - Todos os Direitos Reservados 9

 Gestão de Processos Ágeis de Desenvolvimento de Software

pode gerar as devidas premissas a serem incluídas: com base nas entregas ou no produto
final, como esperamos que nossos stakeholders externos se comportem?

Passo 6: As restrições refletem de forma clara as limitações do projeto? Para que uma
restrição seja relatada do modo correto, devem estar ligadas a um destes 3 questionamentos:
A restrição está relacionada a algum membro da equipe? A restrição refere-se a alguma
entrega do projeto? Ou a restrição está ligada ao projeto como um todo? Tais perguntas
também podem ser feitas em relação às entregas e à equipe, para ver se ainda falta ou sobra
alguma restrição.

Passo 7: Os riscos conseguem contemplar o que é possível de se saber no projeto e são

capazes de vislumbrar o que ainda não se tem certeza? Como abordado anteriormente, é
preciso primeiro revisar as premissas para depois fazer o inventário dos riscos. As premissas
irão gerar pelo menos um risco para cada uma delas, de forma fácil, basta fazer a negativa
dessa premissa. Também é importante revisar as entregas, pois nelas estarão o maior número
de riscos após seu detalhamento. Por fim, é necessário verificar o nível de probabilidade e
impacto dos riscos, a fim de dar o melhor tratamento. Caso algum risco tenha uma possibilidade
muito alta de ocorrer, é preciso analisar se ele não pode ser eliminado de alguma forma.

Passo 8: A linha do tempo e os custos estão devidamente orientados pelas entregas

do projeto? De forma a facilitar o detalhamento e o controle posterior, é fundamental que
o cronograma e os custos do projeto estejam baseados nas entregas levantadas. Assim, a
integração entre cronograma e custo se dará de forma natural durante o controle.

Para finalizar esse tópico sobre integração, Finocchio Junior (2013) aborda um ponto
bem interessante no que tange à carreira do gerente de projetos. A intenção do Project Model
Canvas é justamente oposta às práticas tradicionais, que adotam a burocracia como base de
construção do plano. O autor explicita que existem dois tipos de gerentes de projetos: os que
entendem a lógica por trás do trabalho de um gerente de projetos e aqueles que se escondem
atrás de formas burocráticas de gerenciar projetos, e assim não compreendem o que estão
fazendo de fato. A pergunta que fica aqui é: que tipo de gerente de projetos você quer ser?

1.3 Resolução de problemas

Para o Project Model Canvas, a resolução de problemas é a parte na qual assumimos que
nem todas as informações para planejar o projeto estão devidamente esclarecidas. Com isso,
encontraremos os chamados nós, ou seja, os pontos que acabam por travar o andamento do
projeto em dado momento.

Finocchio Júnior (2013) sugere 3 passos para a resolução dos problemas referentes aos
nós, são eles:

1. Identificar o nó, caracterizando de forma clara qual problema está impedindo a

Senac São Paulo - Todos os Direitos Reservados 10

 Gestão de Processos Ágeis de Desenvolvimento de Software

concepção do canvas.

2. Fazer lição de casa, ou seja, conhecendo o problema, levantam-se as alternativas

para a solução.

3. Alterar o canvas com base na solução escolhida e prosseguir com o seu

desenvolvimento.

A etapa de alteração do canvas, segundo Finocchio Júnior (2013), deve seguir a mesma
sequência da concepção, isto é, primeiro é preciso verificar se a questão por quê foi
devidamente respondida e se houve geração de valor que contemple o propósito do projeto.
O próximo passo é verificar se a pergunta o que o projeto se propôs a entregar por meio
dos requisitos está em um nível ideal. Em seguida, deve-se verificar se a pessoa a quem foi
delegado o projeto possui autoridade, conhecimento, disponibilidade e responsabilidade. A
próxima questão é analisar se existe clareza em como o trabalho será desenvolvido e se está
controlado. Por fim, deve-se verificar se questões relativas aos itens quando e quanto estão
alinhadas ao que já se sabe até o momento e às incertezas existentes.

Esse processo de 3 etapas pode se repetir algumas vezes, até que todos os nós tenham
sido solucionados da melhor forma possível.

Para finalizar, Finocchio Júnior (2013) explicita alguns tipos de problemas mais comuns e
que podem ser encontrados mais facilmente nos projetos, são eles:

• o projeto não gera valor;

• o cliente não tem claro o que deseja;

• os recursos necessários para executar o projeto não estão garantidos ou alocados;

• o gerente de projetos não tem autoridade ou influência necessária para executar o

projeto;

• falta identificar as entregas por parte da equipe de projeto;

• os riscos levantados pelos envolvidos não são condizentes com o projeto ou, na
linguagem popular, “são pra bonito”;

• o prazo de entrega do projeto não deixa a equipe confortável;

• os parceiros de negócio não interagem com a equipe;

• ainda existem partes interessadas que não foram levantadas no canvas;

• há resistência quanto ao desenvolvimento do projeto.

Senac São Paulo - Todos os Direitos Reservados 11

 Gestão de Processos Ágeis de Desenvolvimento de Software

1.4 Compartilhamento de informações

Depois de validado o canvas, o compartilhamento de informações é fundamental. Essa
troca torna-se a alma do projeto, e as informações compartilhadas podem servir de base para
outros documentos ou ferramentas, como planos de projetos, cronogramas, apresentações,
orçamentos, etc.

Diante disso, veremos como os itens do Project Model Canvas podem auxiliar na
construção de outras ferramentas e outros documentos, ou seja, qual a utilidade de cada
item do canvas ou para que eles servem.

As justificativas podem ser usadas para mostrar às partes interessadas que as “dores” e os
problemas do cliente foram devidamente entendidos e explicitados. Além disso, os gerentes
podem demonstrar que os problemas das áreas estão sendo verificados e devidamente
analisados para posterior atendimento por meio de um projeto.

O objetivo do projeto, por sua vez, pode servir para que o gerente faça o projeto ser
comunicado e compreendido por meio de poucas palavras, além de medir o sucesso do
projeto em nível macro.

Os benefícios auxiliam primeiramente os patrocinadores a verificar a geração de valor

que o projeto poderá ou não proporcionar. Os patrocinadores ainda podem alinhar os
benefícios aos objetivos estratégicos da organização, caso esta tenha um portfólio de projetos
e objetivos bem definidos.

Já o produto do projeto pode ajudar a equipe de parceiros e fornecedores a direcionar o

que deve ser desenvolvido e também a promover a aceitação final do cliente.

Os requisitos, por sua vez, podem contribuir para as ações de qualidade. Seu detalhamento
pode possibilitar o melhor desenvolvimento pelos fornecedores. Os requisitos ainda podem
ser objetos integradores entre sistemas e subsistemas do produto.

Com os stakeholders e os fatores externos, pode-se e deve-se verificar quais premissas

serão geradas no projeto e identificar os itens que precisarão ser monitorados, já que
mudanças nos cenários do mercado podem alterar significativamente o que já foi estabelecido
no projeto.

Com a equipe, é possível se identificar questões relativas ao escopo, pois não existe
trabalho a ser feito sem a participação de da equipe, seja interna, seja fornecedor. A equipe
ainda pode fornecer ao gerente de projeto informações valiosas que podem ajudar na
negociação de recursos com o patrocinador.

As premissas, por sua vez, servem para que o gerente de projetos tenha coerência tanto
na construção de restrições adequadas quanto na identificação de riscos no projeto. Outro
ponto importante é que elas fornecem às partes interessadas externas coisas que só elas
Senac São Paulo - Todos os Direitos Reservados 12
 Gestão de Processos Ágeis de Desenvolvimento de Software

podem fazer no projeto.

O grupo de entregas do canvas auxilia tanto na construção de um cronograma quanto no

orçamento do projeto. Além disso, pode ajudar no monitoramento do progresso do projeto,
verificando o que já foi ou não entregue.

As restrições, quando detalhadas adequadamente pelo gerente de projetos, deixam

claras para os envolvidos as soluções que melhor atendem aos objetivos do projeto, caso
contrário este pode se tornar inviável. As restrições servem também como forma de auditoria,
para um melhor controle do projeto.

Já os riscos ajudam o patrocinador na tomada de decisão, pois, dependendo da gestão

dos riscos, ele pode decidir se o projeto continua viável ou se é necessário o seu cancelamento.
Para o gerente de projetos, os riscos servem como insumo para uma análise completa da
situação e para o estabelecimento de um plano de respostas.

A linha do tempo, como tem ligação direta com as entregas, permite a construção de um
cronograma mais realista e detalhado, além de interligar compromissos e atividades.

Por fim, temos os custos. Assim como a linha do tempo, eles auxiliam nas entregas,
permitem um detalhamento melhor e maior do orçamento do projeto, ajudam no cumprimento
das metas assumidas ou servem como alerta para uma renegociação que possa vir a ser feita
com o patrocinador.

Considerações finais
Nesta aula, explicamos os diversos conceitos a respeito do Project Model Generation,
especialmente seu canvas.

O primeiro tema abordado foram os quadrantes e os itens do canvas e sua concepção.

Depois, vimos como deve acontecer a integração desses itens e ao que devemos estar
atentos para que essa integração seja feita da forma mais eficiente e eficaz possível.

Estudamos, também, os possíveis problemas gerados mesmo após a integração do

canvas e como devemos desatar os nós para a melhor resolução do problema.

Por fim, verificamos o compartilhamento de informações do canvas, ou seja, do

conhecimento através dele gerado e para que esse conhecimento serve mesmo após sua
conclusão, ou seja, quem poderá se beneficiar com os itens do canvas de forma prática.

Senac São Paulo - Todos os Direitos Reservados 13

 Gestão de Processos Ágeis de Desenvolvimento de Software

Referências
FINOCCHIO JÚNIOR, J. Project Model Canvas: gerenciamento de projetos sem burocracia. Rio
de Janeiro: Elsevier, 2013.

PROJECT MANAGEMENT INSTITUTE. Um guia do conhecimento em gerenciamento de

projetos: guia PMBOK®. 5. ed. Pensilvânia: Project Management Institute, 2013.

Senac São Paulo - Todos os Direitos Reservados 14