0

17º Seminário Internacional de GP

JORGE HORÁCIO NICOLÁS AUDY Consultor, DBServer Jorge Audy é consultor sobre métodos ágeis na DBServer, professor na Escola Politécnica da PUCRS, mestre pela Escola de Negócios da PUCRS na linha de pesquisa sobre Gestão da Informação, blogueiro e autor dos livros SCRUM 360º, Toolbox 360° e Jogos 360°. Escoteiro e agilista 24 horas por dia.

INSCREVA-SE! • 18, 19 e 20 de SETEMBRO • 1º LOTE • 30% DE DESCONTO • Saiba mais em: https://goo.gl/PxPy4e

Coisas boas acontecem quando você se envolve com o PMI !!! #gopmisp #17SIGP #pmisp20anos

Algumas fotos de workshops e start de Toolbox Walls:

0

Jogo de Robótica

Um jogo destinado a mostrar a importância de ações iterativo-incrementais, através da programação de robôs. Eu levei caixas de papelão com furos para a cabeça e braços, rolos de papel-alumínio, tesouras e fitas adesivas.

Os robôs terão os olhos vendados para executar os movimentos.      De posse do material, cada equipe monta o seu robô, enquanto o facilitador (eu) monta um percurso com linhas a direita e a esquerda, com um slalom.

Caberá a cada time fazer o seu robô realizar o percurso com o menor número de comandos, mas se ele pisar ou atravessar uma das linhas é penalizado com 2 comandos a mais no geral.

PLANEJAMENTO – O time deve planejar e combinar com o seu robô os comandos – perna direita, perna esquerda, giro a esquerda, giro a direita, em frente, parar, recuar, bem como o tamanho ou ângulo de cada movimento.

ITERAÇÃO 1 – Cada equipe deve tentar fazer toda a programação previamente e executá-la, verificando qual o robô conseguiu ir mais longe nesta tentativa waterfall;

ITERAÇÃO 2 – Cada equipe irá comandar o robô passo-a-passo, adaptando-se a realidade, trabalhando de forma iterativo-incremental, verificando quem faz em menos comandos e em menos tempo.

PRINCÍPIOS: Um jogo que perpassa situações típicas de projetos waterfall ou iterativo-incremental, adaptando-se a imprevistos ou erros gerados durante o percurso.

DICA: Eu levo caixas de papelão com buracos para a cabeça e os braços, mais rolos de papel alumínio, canetão e fita adesiva. Assim, no começo de tudo as equipes brincam de criar o seu robô, laminá-lo e caracterizá-lo.

0

Value Stream Mapping

A criação de um mapa de fluxo de valor de estado atual é um passo importante quando estamos debatendo nosso processo de trabalho, mas a meu ver é fundamental que entendamos os conceitos, os processemos e a luz de nossa realidade adaptemos ou simplifiquemos à nossa necessidade.

Tenho cases bem legais em áreas como financeiro, contratos, compras, RH, educação, conteúdo, baseados em “Genchi Gembutsu” e “Gemba Walk”, que traduzem o conceito de verificar in loco onde as coisas acontecem, com quem faz acontecer. Porque o primeiro passo é não tomar decisões sem convidar para o debate quem faz acontecer, inexiste entendimento sem envolver as pessoas.

O mapa de fluxo de valor do estado atual é um trabalho onde a equipe, com ajuda de um facilitador, debate e mapeia os limites e passos do processo, os dados e fluxo, os tempos de execução e transição, tudo isso para debater gargalos, problemas e oportunidades para planejar e experimentar melhoria.

No slideshare encontrei este desenho de processo para execução iterativo-incremental de mapeamento e melhoria do mapa de fluxo de valor (Lean Webinar Series):

Eu muito usei este conceito ajudando áreas de escritório (Lean Office) a mapear e tentar melhorar seus fluxos de valor, mas para ilustrar este post eu procurei exemplos de desenvolvimento de software para tornar mais legível para a maioria, exemplo de indústria há milhares no gloogle.

O que é VSM

Mapeamos o fluxo de valor do estado atual com o intuito de enxugá-lo e construirmos o estado ideal ou futuro, para tanto representamos o passo-a-passo de cada um de nossos fluxos de trabalho, entendendo atores, responsabilidades, informações, recursos e tempos médios.

Trata-se de um exercício coletivo e colaborativo, envolvendo representantes de todas as áreas e equipes, todos temos condições de fazê-lo se desapegarmos de notações, foque no fluxo e não no formato, debata e ao mesmo tempo registre diagramaticamente de forma clara aos presentes.

Um rabiscoframe legível e claro a todos os presentes vale muito mais que um diagrama cheio de regras e notações, quando perdemos tempo abertos a comentários e rec
lamações que nada agregam em valor ao assunto, apenas a regras de representação absolutamente dispensáveis.

Quem nós somos e o que fazemos?

Sugestão, use um Role Model Canvas, um Design Ops Canvas, inicie alinhando quem nós somos, qual é a nossa missão, restrições, informações, ferramentas, … liste os principais fluxos de trabalho, escolha aquele que mais tem a agregar se o analisarmos e enxugarmos.

A escolha diz respeito a Pareto, queremos mapear um fluxo de projeto, operação, relacionado a um produto ou serviço, interno ou externo, frequentemente diz respeito a algo que está gerando problemas, mas pode ser algo novo, um desafio ou objetivo organizacional em enxugar.

Quem fará a facilitação?

É importante ter alguém que faça a facilitação, mediação, provavelmente alguém com alguma experiência ou habilidade na diagramação de mapas de valor ou processos, podendo ou não ser alguém do time ou (frequentemente) um profissional dedicado a este tipo de trabalho.

Ele alinhará de início algumas regras e técnicas Lean ou Ágeis para debates colaborativos, registrará o objetivo e criará alguns quadros auxiliares, bem como combinará em comum acordo alguns acordos sobre simbologia, significado de cores, postits, etc.

Essas combinações são essenciais para direcionar os debates, diz respeito a fazer um pacto de trabalho, delimitando algumas balizas e restrições, acordando o(s) principal(is) foco(s) de atenção e dedicação.

Desenhando o fluxo?

O desenho incia invariavelmente por um storytelling, com key-users, usuários e operadores contando como realizam este trabalho, onde ele inicia, por onde passa, suas operações, filas, transformações, evitando entrar a nível de tarefas ou detalhamento de atividades.

É muito importante neste momento incluir os fluxos de informação envolvidos, solicitações, registros, workflows, aprovações, aguardando, manipulações, sempre a partir de um paradigma de operação e não detalhando atividades, mergulharemos nela mais adiante se necessário.

Esta discussão tem valor per si, o simples fato de colocar as pessoas para discutir seus trabalho atual explicitam eventuais desperdícios ocultos, alguns preconizados pelo Lean desde a década de 50, como estoques de inacabados, deslocamento desnecessário, complexidade desnecessária.

Se a equipe for provocada desde o início a sair da caixa, analisar críticamente sem prévios conceitos e questionando regras e hábitos, é muito provável que todo e qualquer fluxo terá desdobramentos para otimização e enxugamento de seus passos, potencializando seus recursos e tempo.

Dados, medidas e informações?

Agregue informações pertinentes a métricas do seu fluxo, de cada passo e entre eles, mas evitem percepções abstratas ou históricas, gere informações atualizadas e reais para evitar birras e distorções pessoais ou mesmo coletivas.

Ao registrarmos tempos médios, se necessário também mínimos e máximos, muito do valor pertinente a demora e oportunidades de redução se explicitam automaticamente, informações básicas do Lean são Lead Time (desde a requisição inicial) e Cycle Time (tempo de execução).

No mapeamento de fluxo de valor dedicamos algum tempo na análise de tempo, quer no de execução de uma operação quanto no tempo de fila ou aguardando algo, o que muitas vezes se reflete em desperdícios.

Obs: A imagem abaixo retirei de um post em que Al Shalloway destaca que um bom Kanban com seus status visíveis de fluxo seria um passo dado para incrementar médias e informações para análise de gargalos, algo que tentamos fazer sem explicitar um VSM, mas usando quadros auxiliares com Lead Time, Cycle Time, Throughput, …

Como criar o mapa de fluxo de valor do estado ideal?

Iniciamos combinando qual é o ideal que queremos ou necessitamos, para então começar ciclos de análise, debate, proposição a partir dos pontos de maior desperdício ou “dor”. Iniciamos debatendo o ponto em comum acordo que é onde maior valor agregaria se o otimizassemos e assim por diante.

Aqui entra em ação nossa Toolbox, apoiados por frameworks, técnicas e boas práticas para otimização de cada operação analisada, como o uso de quadros Kanban para eliminar desperdícios de tempo e estabelecer um fluxo puxado.

Naturalmente vamos planejar algumas melhorias, priorizadamente, em ciclos evolutivos, iterativo-incrementais-articulados, para avaliar, planejar o próximo passo e seguir adiante. A técnica recomenda que demarquemos os pontos que estão sendo priorizados e a ação que está sendo realizada a cada novo passo (kaizen Burst).

As vezes temos resultados imediatos, mas para atingir um estado ideal otimizado é preciso persistência e dedicação.

0

Ishikawa para análises de causa-efeito

Não sou preconceituoso com boas práticas só pela idade, talvez por empatia, afinal já ultrapassei a barreira dos 55 anos há algum tempo, então uma técnica conhecida e fácil sempre é uma opção conforme o perfil, formação e área do grupo. Dito isto, já usei Ishikawa e continua sendo uma opção na minha Toolbox.

O Diagrama de Ishikawa é usado para análises causais, por isso é conhecido como “Diagrama de Causa-Efeito”, mas devido ao formato é conhecido como “Espinha de peixe”. Em grandes grupos sigo os princípios de Dojo com piloto e copiloto como no Managing Dojo e World Coffee.

  • Efeito – O que queremos entender e solucionar;
  • Categoria – Principais grupos de problemas;
  • Causa – Causa possível pertencente a um grupo;
  • Soluções – Alternativas ou oportunidades.

Análise causal de problemas, utilizada por equipes empenhadas na busca por soluções ou melhorias em seu processo ou produto. Apesar do original da década de 50 ter sido criado em um formato para a indústria, eu não uso os temas originais e defini-los faz parte da dinâmica, como tecnologia, ambiente, processo, pessoas, empresa, cliente, etc.

Segundo a Wikipedia: “O Diagrama de Ishikawa, também conhecido como Diagrama de Causa e Efeito ou Diagrama Espinha de peixe, é um gráfico cuja finalidade é organizar o raciocínio em discussões de um problema prioritário, em processos diversos, especialmente na produção industrial. Originalmente proposto pelo engenheiro químico Kaoru Ishikawa em 1943 e aperfeiçoado nos anos seguintes.”

No original, Ishikawa fixou as seis áreas (6M) que exigem reflexão para a identificação de soluções para um problema em uma unidade fabril – Método, Máquinas, Medidas, Mão-de-Obra, Material ou Meio-Ambiente. Entretanto, para desenvolvimento de software é mais flexível – Processo, Ambiente, Ferramental, Tecnologia, Time e Relacionamento.

  • Método: causas no método que estava sendo executado o trabalho;
  • Material: causas no material que estava sendo utilizado no trabalho;
  • Mão-de-obra: causas nas atitudes – pressa, imprudência, qualificação;
  • Máquina: causas envolvendo a máquina que estava sendo operada;
  • Medida: instrumentos de medida, calibração, indicadores, acompanhamento, frequência;
  • Meio ambiente: poluição, calor, poeira, layout, falta de espaço, dimensionamento.
0

One Page Change Plan

Um canvas com uma abordagem concentrada e singular, que privilegia o debate e planejamento do fluxo de distribuição, implantação e transição, eu não a uso explicitamente, mas são questões comumente trabalhadas quando estamos debatendo a pré-inception para alinhar expectativas e contextualização com stakeholders.

  • A primeira parte resume o que é, o que impacta, como será monitorado e medido;
  • O segundo bloco, intermediário, esclarece quem será impactado e como serão apoiados na mudança;
  • No terceiro bloco, o plano, a mudança e a preparação para que dê certo, além dos próximos passos.

Mais informações podem ser encontradas na página da Lean Change.Org

Uma ferramenta poderosa para um alinhamento antes e depois de um planejamento, uma canvas de amplitude para entendimento do contexto e responsabilidade:

1. Que mudança estaremos fazendo? Qual o nosso objetivo? O que queremos implementar ou mudar?

2. Por que é importante para a organização? Por que estamos fazendo essa mudança? Quais as justificativas ou mesmo benefícios?

3. Qual é e como vamos medir o sucesso? Quais as métricas e indicadores que serão utilizados?

4. Como vamos apresentar o progresso? Quas o plano de comunicação para compartilhar e validar diferentes percepções?

5. Quem são as pessoas, áreas, stakeholders afetados pela mudança? Qual o seu papel?

6. Como nós ajudaremos as pessoas na transição? Além de requisitos de transição, como potencializar, manter o foco?

7. Qual é o nosso plano em alto nível? Preparação? Introdução? Estratégia de Rollout? Retroalimentação?

0

Lean UX Canvas

Primeiro entender o trabalho como um problema de negócios a resolver, não apenas como uma solução a implementar, somente após entendido e contextualizado é que debateremos pressupostos e hipóteses – Jeff Gothelf. Ele informa em seu site que inspirou-se no Opportunity Canvas de Jeff Patton.

“O Lean UX Canvas ajuda as equipes a estruturar seu trabalho como um problema de negócios a ser resolvido. Ao dissecar esse problema de negócios em suas principais suposições, você pode desenvolver hipóteses para projetar experimentos e testes” – Jeff Gothelf.

Os campos do canvas são auto-explicativos:

Business Problem – Qual é o problema, desafio ou oportunidade?

Business Outcome – Quais os resultados esperados desta iniciativa;

Users & Customers – Quais as personas, identificá-las e entendê-las;

User Benefits – Quais os benefícios esperado pelas personas mapeadas;

Solution Ideas – Quais as alternativas e possibilidades de resolução;

Hypotheses – Quais são o(s) plano(s) de ação, propostas de atuação;

What’s the most important things we need to learn? – Primeiro(s) pontos a validar;

What’s the least amount of work we need to do to learn the next most important thing? – MVP

O post do autor é http://www.jeffgothelf.com/blog/leanuxcanvas/

Este canvas materializa o processo proposto originalmente em seu livro “Lean UX”. Segundo o autor, eles usam esse processo para ajudar as equipes a orientarem seu trabalho como um problema de negócios a ser resolvido, compreender esse problema de negócios em suas principais premissas. Tais premissas gerarão posteriormente hipóteses, para as quais desenvolveremos modelos ou protótipos a serem validados.

https://www.amazon.com.br/Lean-UX-Applying-Principles-Experience/dp/1449311652

0

Jogo da Fábrica de Triângulos (Caroli)

Há um jogo do grande Paulo Caroli da TW que mexi um pouco. O jogo é ótimo e mantém sua essência, pedindo a um grupo de pessoas, dispersas em uma sala, que formem triângulos usando os braços como vértices de triângulos, cada qual com três pessoas. Primeiro de forma gerenciada e depois de forma auto-organizada.

Eu mexi um pouquinho, com provocações sobre limites da liberdade, negociação e estipulei valores para tipos diferentes de triângulos – equiláteros (tamanho lados iguais) valem mais que não equiláteros. Eu uso notinhas de R$10 com o Seu Madruga no centro impressas e recortadas  \o/

  • Todos se misturam aleatoriamente por toda a sala;
  • Peço que parem onde estão e não podem se mexer mais;
  • Alerto que somos uma fábrica de triângulos;
  • Um cliente pediu o máximo que pudermos entregar;
  • Cada triângulo equilátero vale R$50;
  • Cada triângulo isósceles vale R$20;
  • Cada triângulo escaleno vale R$10;
  • Um triângulo é feito por três pessoas como vértices;
  • Cada um levanta os braços e aponta para outros dois;
  • Podem girar o corpo, mas não sair de onde estão.

Eu rodo três rodadas, uma com um chefe designado (eu escolho o mais novo) decidindo e ordenando, outra(s) com o time se auto-organizando, cada um posicionando-se e fazendo o seu melhor com opiniões e ações junto ao seu entorno e na terceira para repetir já com alguns aprendizados.

PRINCÍPIOS: Comando-controle versus Auto-organização, organização versus caos, lideranças positivas e colaborativas, foco em resultados.

DICA: Sempre discuto que mesmo auto-organizados, temos um cliente, que quer triângulos, com critérios claros. Auto-organização não quer dizer que podemos fazer quadrados ou retângulos, nem fugir dos critérios de aceitação, podemos negociar, mas o cliente tem a palavra final.