A justificativa do projeto deve ser a primeira a ser questionada/construída, e deve ter a semântica que demonstre que de fato é um problema o que está sendo posto no pauta.

Abaixo exemplo de indagação que podem ser feitas para os participantes da construção.
- Os textos deste campo deve trazer desconforto ao ser lido.
- Os cards devem mostrar uma dor
- Quem ler esse card deve “chorar”
- Quem ler esse card deve entender que é um grande problema.

• Não é salvável que um projeto tente resolver o mundo inteiro, para aumentar a chance de sucesso do projeto tente dar foco a 3 a 6 problemas.

Hudson: E comum que as pessoas descrevam um problema desta forma: “Falta de informações sobre o processo de aquisição”. Essa construção não causa impacto, pois estamos acostumados a sentir falta de algo. Minha sugestão para dar mais potência seria “Processo de aquisição mau gerido causa desperdício de R$ 200.000,00 anuais”.

Os benefícios futuros deve ser descritos de forma que deixe quem ser o projeto com “água na boca”, e veja no projeto o potencial que cada um que está na sala sabe que têm. Benefícios abertos não são atrativos, imagine que existe duas lojas concorrentes de um produto qualquer. No caso uma jaqueta de motoqueiro, você vê coincidentemente duas propagandas dessas lojas: “Loja A” anuncia “Toda loja com descontos imperdíveis” “Loja B” anuncia “Toda loja com descontos de 30% a 50% parcelados no cartão” Então qual loja você vai escolher ir?

Abaixo exemplo de indagação que podem ser feitas para os participantes da construção.
- Para os problemas colocados nas justificativas, quais são os benefícios esperados?
- Como esse projeto vai mudar o mundo?
- Quais as características que tornam esse projeto um diferencial.

Não há limites para os benefícios, porém não “viaje demais”, por mais que um projeto tem impactos em varias áreas não se perca colocando benefícios que não tenham um problema pontuado anteriormente. Essa fase deve ser no minimo a mesma quantidade que os problemas.

Hudson: Seja marqueteiro, esse campo salta aos olhos, mas não venda o que não pode entregar. Aqui tudo tem que ser alcançável.

O objetivo smart deve ser um link entre a justificativas e os benefícios futuros. Esse objetivo pode ser difícil de construir com a equipe, e realmente não deve ser, ele vai exigir muito e vai colocar a prova o que realmente é importante.

Abaixo exemplo de indagação que podem ser feitas para os participantes da construção. - Nosso objetivo tem que ser claro e apresentar nossa justificativa. Precisa ser uma frase impactante. - Esse objetivo é o que move o projeto e deve fazer todos remarem para o mesmo lugar.

• O projeto só deve ter 1 objetivo smart.
• Todas as justificativas e benefícios devem está expresso no texto.
• A frase deve ser empolgante, então se você não se arrepiar ao ler o objetivo tem alguma coisa errada.
• Não é simplesmente transcrever o que já foi feito, tem que ser motivador.

Hudson: Releia a justificativa e os benefícios antes de começar a construção da frase. E sempre que o objetivo não estiver relação com algo colocado na justificativa e benefícios conduza a reunião para que volte ao foco. E muito comum que nesse momento as pessoas percam o foco, então seja incisivo e sempre fique instigando, perguntando, questionado, desafiando para que a cada devesa o objetivo fique cada vez mais claro.

O produto ou produtos do projeto deve ser claros. E acima de todo deve ser o que se espera ter com o fim do projeto.

Abaixo exemplo de indagação que podem ser feitas para os participantes da construção. - Se fosse para entregar a solução em uma “caixa” o que teria dentro dela? - Para que a gente possa alcançar o objetivo quais são os produtos que vamos ter que utilizar para chegar lá? - (Utilizar uma caixa de papel de preferência grande) Chegamos ao fim do projeto, e dentro dessa caixa está o seu produto. O que vocês esperam encontrar quando abrir?

• Comumente as pessoas não entendem que projeto tem um fim. Então reforce que o produto é o que o projeto tem como objetivo de alcançar no final de tudo. Então deve ser coerente com o objetivo smart. Exemplo ruim: Objetivo smart = Acabar com o retrabalho na confecção de documentos, aumentando a produtividade dos servidores públicos em 30% em 12 meses. Produto = Caderno impresso de boas praticas.

Hudson: A definição do produto é um marco para o projeto. Tudo envolve essa etapa, além de ser o compromisso de entrega. E por esse produto que estamos aqui, e por esse produto que todos se mobilizaram. Depois de definido conduza todas as outras etapas pensando nesse produto. Desta forma ele sempre estará sendo posto a prova, sendo constantemente validado ou será percebido que não é o produto adequado. As duas são considerando um sucesso.

Os requisitos são os aspectos que vão agregar qualidade ao produto/serviço que está sendo proposto. Reforçando, requisito = qualidade.

Abaixo exemplo de indagação que podem ser feitas para os participantes da construção. - O que esse produto/serviço deve ter para que as pessoas gostem dele? - O que esse produto/serviço deve ter que torne ele um diferencial? - Quais características esse produto/serviço tem que ter para cumprir seu proposito?

Para melhor entendimento oriente a construção das frases começando com verbos no imperativo. Dessa forma sempre que alguém ler inconscientemente vai entender que é algo que deve ser executado.

Hudson: Lembre-se sempre o que está sendo buscado aqui é qualidade, não especificidade. Dessa forma evite colocar aspectos triviais ou de detalhe muito especifico.

Exemplo ruim: Deve cadastrar o nome da pessoa, deve cadastrar o número da pessoa, deve cadastrar o endereço da pessoa ….

Exemplo bom: Deve armazenar as informações das pessoas.

Expresse os limites que o(s) produto(s)/serviço(s) ou até mesmo o projeto deve ter. Essa area vai definir os limites de atuação da equipe e ajudará a equipe a não perder o foco. Explore os limites para identificar cada um deles. Exemplos de limites:

- Orçamentário

- Pessoal

- Funcional

Abaixo exemplo de indagação que podem ser feitas para os participantes da construção.

- (Orçamento) O custo de aquisição de ferramentas não pode passar de 20% do orçamento do projeto.

- (Orçamento) Não existem verba para aquisição de licenças de software

- (Pessoal) A equipe não poderá ser menor que 5 integrantes.

- (Pessoal) O time deve ter pelo menos um membro com experiência em campo.

- (Funcional) O time de desenvolvimento não irá dar manutenção no software

As restrições são os limites que o projeto tem que respeitar.

Hudson: Os limites impostos nessa etapa ajudará o projeto a não desfocar ao longo do tempo. Comumente existe o anseio que durante o projeto ele acabe inflando com mais solicitações. E essa area pode ser utilizada como argumento para solucionar.

Pessoas externas que possuem interesse no projeto ou que serão impactadas de alguma forma pelo projeto.

Abaixo exemplo de indagação que podem ser feitas para os participantes da construção.

- Quais são os patrocinadores do projeto?

- Quem são as pessoas que podem ajudar/interferir o projeto?

- A quem o projeto é destinado?

Os Stakeholds devem ser bem definidos e especificos. Evite utilizar descrições abrangentes, lembre-se que essas pessoas são as interessadas pelo processo então devem ser bem definidas.

Exemplo ruim: Servidor público.

Exemplo bom: Tecnico em praticas jurídicas da Assessoria tecnicada da EPR,

Exemplo ruim: Empresa privada

Exemplo bom: Empresa fauna e flora de artigos de jardinagem.

Hudson: Cuidado com essa parte, os stakeholds colocados aqui devem ser constantemente informados ou consultados ao longo do projeto. Então se tiver algum nome nessa lista que não precisa ser informando ou consultado possivelmente não é um stakehold.

Pessoas envolvidas diretamente com a execução do projeto. Todos que participarem, mesmo por uma parte pequena, deve ser descrito nessa area.

Abaixo exemplo de indagação que podem ser feitas para os participantes da construção.

- Quem vai produzir esse produtos/serviço.

- Quem vai ser o responsável por monitorar a execução do produto/serviço.

Todo mundo que vai está envolvido com a execução do projeto deve ser colocado nessa area.

A primissa é uma informação que consideramos como verdade mesmo sendo incerta. Todo projeto é idealizado e construido supondo que o cenário vislumbrado será mantido, então o que acontece se o cenário mudar? O que acontece se uma premissa se mostrar falsa?

Identificar as premissas são de extrema importância pois cada premissa aceita deve gerar um risco. Então devemos ter plano de ação para quando uma premissa se torne falsa.

As premissas podem levar o projeto ao fracasso. Lembra da kodak? Ela assumiu a premissa que as pessoas continuariam a comprar filmes analogicos mesmo com o advento das fotos digitais.

Abaixo exemplo de indagação que podem ser feitas para os participantes da construção.

- Quais são as verdade que aceitamos para construção desse projeto?

- Qual cenário ideial para que esse produto/serviço tenha sucesso?

Priimissas são verdades que podem por em risco o projeto. E for algo que não afeto o projeto não precisa está nessa area.

Hudson: Lembre-se sempre que toda premissa gera um risco que deve ser observado.

São eventos que podem fazer com que o projeto fracasse. Esses eventos devem ser monitorados constantemente e ter estratégias bem definidas para mitigar os problemas causados se um desses eventos realmente acontecerem.

Abaixo exemplo de indagação que podem ser feitas para os participantes da construção.

- Quais são os eventos que podem causar o fracasso do projeto?

- Vamos entraga em uma maquina do tempo para uma viagem para o futuro. Chegando lá descobrimos que o projeto não deu certo. Quais os problemas que fizeram ele não dar certo?

Deve ter no minimo 01 (um) risco para cada premissa.

Hudson: Foque em riscos que realmente podem causar o fracasso do projeto.

São elementos mensuravéis e tangiveis que devem ser entrege. São Épicos que devem ser entregue para que o produto/serviço seja construido.

Abaixo exemplo de indagação que podem ser feitas para os participantes da construção.

- Como podemos dividir as etapas de produção?

- Quais as etapas necessárias para construção do produto?

- (Ágil) Que valor podemos agregar com cada entrega?

Identifique os grupos de entrega que agregam valor ao projeto. Não faz sentido colocar no grupo de entrega algo que não tem um potencia de utilização.

Exemplo ruim: Desenho da sala, desenho da cozinha, desenho do quarto, desenho do banheiro.

Exemplo bom: Projeto estrutural da resisdência.

Exemplo ruim: Arquitetura do software, codigo back-end, codigo front-end, elementos responsivos

Exemplo bom: Software de estoque

Exemplo ruim: Fluxo do recebimento de processo, fluxo do aceito do processo, fluxo do despacho do processo, fluxo de finalização do processo

Exemplo bom: Mapeamento de processo.

Hudson: Cuidado com as extremidades, não é bom ser especifico demais pior se for muito abrangente.

A linha do tempo determina as datas de entrega dos grupos de entrega. Esta estapa é a firmação do compromisso com cada um dos Épicos. Não pode ser generosa nem gananciosa demais. Essa é a etapa mais complicada pois existe um choque de sonho com realidade.

Abaixo exemplo de indagação que podem ser feitas para os participantes da construção.

- De acordo com a equipe que temos disponiveis, quais são os prazos que podemos estipular para a evolução do projeto?

- Para cada grupo de entrega qua o tempo que eles devem levar para serem concluidos?

A tendência natural é que o prazo seja menor que a realidade. Todos mundo prefere algo rapido e imediato. Cuidado com essa estimativa.

Hudson: Analise o prefil do time que está montando o canvas com você. Pessas mais voltadas a negócio tendem a reduzir o tempo e pessoas voltadas a operacional tendem a inflar o tempo. Trabalhe o meio termo.