Plataforma de documentação operacional e gerencial da SETIC
Essa é uma revisão anterior do documento!
Para construção do Canvas devem ser seguidas a ordem dos tópicos abaixo.
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.
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.
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?
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 limetes de atuação da equipe e ajudará a equipe a não perder o foco. Explore os limetes 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 limetes 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 juridicas da Assessoria tecnicada da EPR,
Exemplo ruim: Empresa privada
Exemplo bom: Empresa fauna e flora de aritgos 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.