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. <br> Exemplo ruim: Deve cadastrar o nome da pessoa, deve cadastrar o número da pessoa, deve cadastrar o endereço da pessoa …. <br> Exemplo bom: Deve armazenar as informações das pessoas.