Diferenças

Aqui você vê as diferenças entre duas revisões dessa página.

--- start:memoria_organizacional:frameworks:canvas_model_project [2019/08/02 14:32]
Hudson Fernando
+++ start:memoria_organizacional:frameworks:canvas_model_project [2022/01/25 15:26] (atual)
@@ Linha 94: / Linha 94: @@
 ====== Restrições ======
-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:
+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
@@ Linha 118: / Linha 118: @@
 === Observações ===
-As restrições são os limetes que o projeto tem que respeitar.
+As restrições são os limites que o projeto tem que respeitar.
 === Nota do facilitador ===
+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.
 ====== Stakeholders ======
+Pessoas externas que possuem interesse no projeto ou que serão impactadas de alguma forma pelo projeto.
 === Exemplo de condução ===
+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?
 === Observações ===
+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.
+<font inherit/inherit;;#c0392b;;inherit>**Exemplo ruim:**</font> Servidor público.
+<font inherit/inherit;;#27ae60;;inherit>**Exemplo bom: **</font>Tecnico em praticas jurídicas da Assessoria tecnicada da EPR,
+<font inherit/inherit;;#c0392b;;inherit>**Exemplo ruim:**</font> Empresa privada
+<font inherit/inherit;;#27ae60;;inherit>**Exemplo bom:**</font> Empresa fauna e flora de artigos de jardinagem.
 === Nota do facilitador ===
+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.
 ====== Equipe ======
+Pessoas envolvidas diretamente com a execução do projeto. Todos que participarem, mesmo por uma parte pequena, deve ser descrito nessa area.
 === Exemplo de condução ===
+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.
 === Observações ===
+Todo mundo que vai está envolvido com a execução do projeto deve ser colocado nessa area.
 === Nota do facilitador ===
 ====== Premissas ======
+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.
 === Exemplo de condução ===
+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?
 === Observações ===
+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.
 === Nota do facilitador ===
+Hudson: Lembre-se sempre que toda premissa gera um risco que deve ser observado.
 ====== Riscos ======
+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.
 === Exemplo de condução ===
+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?
 === Observações ===
+Deve ter no minimo 01 (um) risco para cada premissa.
 === Nota do facilitador ===
+Hudson: Foque em riscos que realmente podem causar o fracasso do projeto.
 ====== Grupo de entregas ======
+São elementos mensuravéis e tangiveis que devem ser entrege. São [[https://sitecampus.com.br/user-story-epico-e-tema-qual-diferenca/|Épicos]] que devem ser entregue para que o produto/serviço seja construido.
 === Exemplo de condução ===
+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?
 === Observações ===
+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.
+<font inherit/inherit;;#c0392b;;inherit>**Exemplo ruim:**</font> Desenho da sala, desenho da cozinha, desenho do quarto, desenho do banheiro.
+<font inherit/inherit;;#27ae60;;inherit>**Exemplo bom:**</font> Projeto estrutural da resisdência.
+<font inherit/inherit;;#c0392b;;inherit>**Exemplo ruim:**</font> Arquitetura do software, codigo back-end, codigo front-end, elementos responsivos
+<font inherit/inherit;;#27ae60;;inherit>**Exemplo bom:**</font> Software de estoque
+<font inherit/inherit;;#c0392b;;inherit>**Exemplo ruim:**</font> Fluxo do recebimento de processo, fluxo do aceito do processo, fluxo do despacho do processo, fluxo de finalização do processo
+<font inherit/inherit;;#27ae60;;inherit>**Exemplo bom:**</font> Mapeamento de processo.
 === Nota do facilitador ===
+Hudson: Cuidado com as extremidades, não é bom ser especifico demais pior se for muito abrangente.
 ====== Linha do tempo ======
+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.
 === Exemplo de condução ===
+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?
 === Observações ===
+A tendência natural é que o prazo seja menor que a realidade. Todos mundo prefere algo rapido e imediato. Cuidado com essa estimativa.
 === Nota do facilitador ===
+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.
 ====== Custo ======

Superintendência Estadual de Tecnologia da Informação e Comunicação

Ferramentas do usuário

Ferramentas do site

Diferenças

Ferramentas da página