Customer Journey Mapping (CJM) vs Value Stream Mapping (VSM)

Customer Journey Mapping (CJM)

O Customer Journey Mapping (CJM) é um processo colaborativo, muito utilizado em projetos de customer experience improvement, para entender o que motiva seus clientes – suas necessidades, preocupações e problemas. O CJM usa storytelling e diagrama visual para ilustrar as jornadas desejadas pelos clientes e identificar gaps entre suas expectativas e percepções.

Por quê utilizar?
Ajuda a comunicar sob a perspectiva do usuário. Mesmo que sua empresa já tenha dados suficientes, por si só, não conseguem expressar as frustrações e expectativas dos usuários, e por isso, o CJM utiliza o storytelling. Os principais benefícios do CJM são:

  • O ponto de partida para priorizar as iniciativas de melhorias de CX
  • Revelar gaps entre canais e departamentos
  • Ajuda a melhorar o Customer Experience em outside-in
  • Foco em Customer Experience e perspectiva
  • Revela ineficiências e interdependências ao longo da jornada

No template CJM acima, podemos ver como é mapeada a jornada end-to-end da organização. A identificação da persona (necessidades, objetivos, desejos e pain points) , o que o cliente está fazendo, pensando e sentindo, touchpoints (canais e pontos de interação entre o cliente e empresa), goals, what if (o que pode dar errado?) e backstage (referente a sistemas internos, processos e pessoas envolvidas na entrega dessa jornada).


Value Stream Mapping (VSM)

Value Streams (ou fluxos de valor) são as etapas que ocorrem para prover serviços ou produtos aos clientes. A técnica VSM (Value Stream Mapping) é oriunda do Lean Six-Sigma e atualmente é muito utilizada em Agilidade e DevOps para apoiar os times a construir o fluxo de valor, que concretiza uma necessidade em um produto ou serviço para entrega de valor ao cliente.

enterprise-value-stream-mgmt

Figura: Collabnet

Entre os principais motivos que as equipes devem utilizar VSM:

  • Ajuda a identificar gargalos, desperdícios e handoffs
  • Permite acelerar o aprendizado e reduzir o time to market
  • Elimina processos redundantes e desnecessários
  • Promove a colaboração multifuncional e a entrega de valor
  • Contribuem para melhorias na qualidade e produtividade
  • Melhora o feedback integrado e mais rápido



Quando utilizar CJM e VSM?

O CJM é usado quando se espera uma visão real da jornada que os clientes têm com sua marca, serviço ou produto. Isso signfica mudar a perspectiva inside-out para outside-in. Também planejar mudanças a longo prazo de melhorias em CX, criando novas jornadas e inovação.

Já o VSM é mais aplicável a processos repetíveis, especialmente quando há handoffs (tempo de espera) entre os times, que é onde a maioria das demoras e desperdícios se encontram.

Customer Journey Mapping (CJM)Value Stream Mapping (VSM)
Prioriza melhorias de CX e motivação do clientePrioriza value streams de impacto no cliente e na estratégia
Foco na experiência do cliente e perspectivaFoco total nos clientes dos processos
Identificar gaps entre expectativas e percepções do clienteIdentificar gargalos, desperdícios e handoffs
Utiliza storytelling e diagrama visualConstruir o fluxo de valor (oriundo do Lean Six-Sigma)

Referências

Value Stream Mapping
This is Service Design Doing

Amazon’s culture of innovation: insights a todas empresas

O Amazon Way tem despertado o interesse de muitas outras empresas, devido aos resultados obtidos com o modelo de inovação, criação de produtos, customer-centric e outros princípios de liderança da Amazon. A empresa que começou vendendo livros em 1995, teve uma grande ascensão e hoje é a empresa mais valiosa do mundo.

Alguns insights do Jeff Bezos são apresentados anualmente na relação com os acionistas, e são valiosos a qualquer empresa que pensa em inovação, criação de produtos e orientação ao cliente. A True Customer Obsession e o High-Velocity Decision Making são dois bem conhecidos. Outros insights que podemos destacar:

  • Vagar é um contrapeso essencial à eficiência, pois vagar para longe do óbvio (longe das idéias antigas) é essencial para ajudar a criar novos produtos. Mais do que confiar num plano.
  • Surpreender e encantar os clientes: cria confiança a longo prazo
  • Crie altos padrões na cultura da empresa
  • Avance rapidamente e concentre-se nos resultados
  • Descentralizar a tomada de decisões para gerar inovação
  • Missionários (pessoas apaixonadas e empáticas com os produtos) constroem melhores produtos
  • Aposte em ideias com vantagens ilimitadas

O Jeito Amazon

O que na pratica é inspirador e pode ser aproveitado por outras empresas no jeito Amazon de trabalhar? O maior destaque é o Good intentions don’t work, but mechanisms do. Isso significa ter mecanismos que façam a empresa funcionar apropriadamente em seus fluxos de valor. Crie mecanismos que funcionem na sua organização, que inclui o processo de contratação, avaliação de projetos, gestão de demandas, entre outros. O mecanismo é composto de quatro peças:

  • Process: fundamental para haver melhoria, mesmo que seja uma representação simples do início – o que deve acontecer – ordem – fim
  • Tool: essencial para a visibilidade e previsibilidade do seu processo
  • Adoption: o processo e a ferramenta devem fazer sentido as pessoas para elas utilizarem
  • Audit: garantir que o mecanismo continue funcionando

Os benefícios refletirão na organização das agendas (e gestão do tempo), priorização de atividades, avaliação dos colaboradores, e assim, evitar a sobrecarga, recorrência de problemas e depender do “favor” de alguém para cumprir as entregas (existe um mecanismo para acioná-la).

Flywheel

O flywheel é outro conceito muito recomendado a empresas que buscam a estratégia customer-centric e melhorar continuamente a experiência do cliente.

A engrenagem começa com a obsessão pelo cliente. Saber ouvir e surprendê-lo para gerar uma experiência fantástica. Satisfeitos, os clientes utilizam e recomendam a outros. Com o aumento do uso, recebemos mais feedbacks que são insights valiosos a criação de produtos e investimentos. O empoderamento dos times, automações e decisões descentralizadas são essenciais para habilitar a redução no time to value.

Leadership Principles

São utilizados diariamente pelos colaboradores na discussão de ideias e novos projetos, decidindo a melhor solução para o problema de um cliente ou entrevistando candidatos. E na sua empresa? Quais são os princípios utilizados pelos colaboradores em suas atribuições?

Os Princípios de Liderança da Amazon são: Customer Obsession – Ownership – Invent and Simplify – Are Right, A Lot – Learn and Be Curious, Hire and Develop the Best – Insist on the Highest Standards – Think Big – Bias for Action – Frugality – Earn Trust – Dive Deep – Have Backbone; Disagree and Commit – Deliver Results.

Mais detalhes: https://www.aboutamazon.com/working-at-amazon/our-leadership-principles


Working Backwards

É um dos mecanismos mais utilizado pela Amazon no processo de inovação. Possui três componentes: Press Release, FAQs e Visuals.

Press Release
É uma narrativa one-page que explica a visão do projeto de forma customer-centric. Ajuda a visualizar como será a experiência dos usuários com os produtos e na comunicação com stakeholders. Começa com cinco questões que ajudam a clarear o pensamento para o press release:

  1. Who is the customer?
  2. What is the customer problem or opportunity?
  3. What is the most important customer benefit?
  4. How do you know what customers need or want?
  5. What does the customer experience look like?

Escreva de uma forma que o cliente consiga entender. Use o mínimo de palavras possível e evite buzzwords., Descreva o que é a nova experiência (ao invés do nome do produto). Incluir métricas e dados relevantes ao cliente. O parágrafo pode ser escrito por último.

Veja um exemplo do Press Release. O template contém o cabeçalho, resumo, oportunidade/problema, abordagem/solução, quote, experiência do usuário, testemunho e o rodapé.

FAQs
É um canal com respostas a dúvidas que os stakeholders podem ter durante o projeto. Ajuda a prover detalhes e dados da ideia descrita na press release. Também a manter o foco e clareza nas decisões do projeto. Pergunte: Who? What? Where? When? How? Why?

Exemplos:Que decisões e orientações precisamos hoje?

  • Quais são as features do MLP (minimum loveable product)?
  • Quais problemas do cliente estamos resolvendo? Por que agora?
  • Etc.

Visuals
Ajudam a comunicar a experiência do cliente, descrita na PR e FAQs. Pode ser utilizado protótipos, wireframe, diagramas, workflows, customer journey map, entre outros. A fidelidade deve endereçar a maturidade da ideia.

Outros

  • Two pizza teams: “every internal team should be small enough that it can be fed with two pizzas“. O foco é na eficiência e escalabilidade. Times menores permite maior interação e facilita a comunicação e o senso de ownership (maior clareza no trabalho e outcomes).
  • Bar Raiser Program: o Bar Raiser é uma pessoa (de outra área) inserida no processo de contratação, que avalia as informações coletadas nas entrevistas, desafiando os entrevistadores p/ garantir a “barra alta”, baseado no princípio de liderança Hire and Develop the Best.
  • MGHD (Making Great Hiring Decisions): é um processo fantástico, pois viabiliza uma boa avaliação dos candidatos (performance – hard skills, competências – soft skills e resultados – impact) com o uso de técnicas como STAR, interrupting BIAS, ciclo de entrevistas e tempo de resposta aos candidatos.
  • Learning Paths: trilhas de desenvolvimento e capacitação das competências necessárias aos roles da empresa, e fortalecimento da identidade, aspectos de segurança, conduta e produtos (ou serviços) oferecidos pela empresa.
  • Self-service: blogs, forums, procedimentos, wiki, manuais, eventos, treinamentos online, etc. ajudam a tornar a empresa escalável. O conhecimento compartilhado evita uma forte dependência de outras pessoas para realização de tarefas, e fortalece o aprendizado nos processos e produtos da empresa,

Times orientados a produto e organizações projetizadas?

Se por um lado, as startups (modelo enxuto e pouca dependência com sistemas legados) tiveram muita facilidade em adotar um modelo experimental e empírico, muitas outras organizações ainda enfrentam dificuldades em alavancar a transformação ágil, em razão da estrutura atual, competências, sistemas fortemente acoplados, aplicabilidade, entre outros.

Enquanto o Lean Startup, Lean UX e Lean Enterprise propõem o modelo experimental, baseado em validação de hipóteses e MVPs para lidar em domínios de extrema incerteza, o modelo projetizado enfatiza o processo linear, documentações e o upfront planning. A tríplice restrição em projetos tradicionais é estruturada com o tempo e custo variáveis, já o escopo fixo (com alterações via change request).

Software projects are a popular way of funding and organizing software development. They organize work into temporary, build-only teams and are funded with specific benefits projected in a business case. Product-mode instead uses durable, ideate-build-run teams working on a persistent business issue. Product-mode allows teams to reorient quickly, reduces their end-to-end cycle time, and allows validation of actual benefits by using short-cycle iterations while maintaining the architectural integrity of their software to preserve their long-term effectiveness.

https://martinfowler.com/articles/products-over-projects.html

As principais diferenças entre a estrutura projetizada e “produtizada”:

Não é o objetivo desse post discutir a melhor abordagem. O foco é compartilhar alguns drivers que ajudam a quebrar paradigmas na reestruturação organizacional (e viabilizar o trabalho as abordagens).

  • Qual é a melhor estratégia para transformar uma organização projetizada em produtizada? É aplicável a minha empresa?
  • É possível conviver com ambas na mesma organização?
  • Qual seria a função do PMO e outros departamentos nesse contexto?

O Cynefin framework é muito utilizado para entender e distribuir os projetos e portfólios no domínio de acordo com a sua complexidade e evitar os problemas que surgem quando seu estilo de gerenciamento preferido os leva a cometer erros. A gestão e distribuição adequada é fundamental.

Ok. Agora você já distribuiu os projetos nos domínios adequados e viu que a sua organização pode precisar de mais de um modelo (ágil e phase gate) para gerenciar o portfólio organizacional da melhor forma. Se for aplicável o uso de métodos Ágeis em todos os projetos, mas ainda necessária a transição, saiba que ela não pode acontecer somente a nível de time. Priorize a entrega de valor! A gestão estratégica de portfólio é essencial para alcançar o Business Agility, alinhando a estratégia e execução, baseado no Lean e systems thinking.

Descubra quantos flight levels existem na sua organização. Muitas possuem três níveis – operacional, coordenação e estratégico. Traga o top management on board e comece pelo nível estratégico de portfólio com foco nos problemas que precisam ser resolvidos e time to market. O TTM precisa incluir a nível de projetos, e não somente nas tarefas dos times.

A gestão da dependência entre os times (e não do time) é essencial no fluxo do produto. Também a criação de value streams, que são as etapas necessárias para prover serviços ou produtos aos clientes. Evite a gestão em silo com os times, controlando somente suas atividades interna.

Para as organizações que não se aplicam a transição ágil total, os projetos podem ser estruturados conforme a distribuição citada anteriormente. Em cenários preditivos, o modelo tradicional (waterfall) será utilizado com planejamento detalhado na fase inicial e requisitos claros. O escopo é fixado e o time trabalha para cumprir as datas de entrega no prazo.

Mesmo com a fase de planejamento realizada no modelo tradicional (custo, escopo, tempo, riscos, etc.), nada impede o time de adotar práticas ágeis na fase de execução para obter alguns benefícios, conforme a figura abaixo. A simples adoção de Sprints e cerimônias ágeis já trariam mais visibilidade e redução de riscos na execução. Claro, que a maioria dos benefícios vem da cultura/mindset (being agile), e não apenas de práticas (doing agile).

Como ficam os times nesse contexto? Para atender projetos gerenciados em modelos diferentes. Muitas vezes, não há como capacitar ou modifcar a estrutura hierarquica de imediato, o que dificulta a execução, já que não terá times totalmente dedicados e estruturado para entrega contínua. Sem contar os demais benefícios que being Agile poderia trazer.

A adequação é o único caminho nesse caso. Ajustar a capacidade do time, as responsabilidades, as cerimônias, entre outros. Não deixe atribuições sem um responsável. Por exemplo, no Scrum, o Product Owner é o responsável pelo backlog e priorização. Na ausência desse papel, essa atribuição deve estar com alguém no time.

A cadência em múltiplos níveis é uma opção a ser utilizada, permitindo a execução (a nível de Squads) com práticas ágeis e a sincronização dos times no nível intermediário (Scaled). A camada executiva é voltada ao report do projeto em nível estratégico.

Muitas empresas ainda possuem o portfólio com mais de um modelo de gerenciamento e utilizam o PMO para ajudar a priorizar e dar visibilidade ao nível estratégico. O SAFe prescreve muita coisa boa a nível de portfólio. Também sugiro a leitura de livros e artigos sobre como o PMO se modificou em meio a transformação ágil.

Nesse cenário, a FBS (Feature Breakdown Structure) é um recurso que representa o produto (Epic – Feature – User Story) e facilita a comunicação com os times. Também apoia na prorização baseada em valor de negócio e acompanhamento do trabalho realizado vs valor produzido.

No status report executivo, uma página que consolide os resultados da Sprint, com os dados qualitativos e quantitativos, além dos riscos e melhorias discutidos na retrospectiva do time.

* sabemos que há muitos contrapontos em reportar story points como medição de performance do time. Trata-se de uma sugestão (mediante o contexto de maturidade do time).

Conclusão
Mesmo que a organização “produtizada” tenha características, propósito, fundamentação e aplicabilidade bem distintas da projetizada, vimos que a transição ágil não é algo trivial, e por isso, deve-se distribuir os projetos em domínios de complexidade e avaliar a melhor forma de gerenciá-los para obter êxito nas entregas de cada um.

Em cenários complexos, em que os problemas são difíceis de serem previstos, utilizamos métodos ágeis por ser fundamentado no empirismo, onde é realizada uma pequena quantidade de trabalho para adquirir experiência (iteração) e mudança rápida, se necessário. Em cenários preditivos, segue o conceito de Big Design Up Front (BDUF).

Quando há ambos, e não é feita a criação de uma Business Unit dedicada a inovação ou outros meios para gerar independência de recursos e formato de atuação, pode-se ainda utilizar as recomendações feitas nesse post.

O roteiro DMAIC na melhoria dos processos – Six Sigma – parte II

Continuando o post anterior sobre o roteiro DMAIC, onde tivemos a introdução de conceitos e as fases D (Define) e M (Measure), nesse aqui iremos abordar as fases seguintes que são A (Analyze), I (Improve) e C (Control).

4. Analyze

O objetivo da fase Analyze é desenvolver as mudanças e encontrar a causa raiz do problema. A análise é essencial para trazer conhecimento ao processo atual, por isso veremos técnicas que ajudam a criticar o processo atual e sugerir mudanças que resultarão em melhorias.

Evite procurar a perfeição (síndrome da utopia e da paralisia) e fazer mais do mesmo, pois são problemas conhecidos no desenvolvimento da mudança.

Comparação entre os dois tipos de mudança:

1ª ordem2ª ordem
SistemaNão é alteradoÉ alterado
Percepção do clienteSolução do problemaMelhoria
PrazoImediato, curtoMédio, longo

4.1. Diagrama de Causa e Efeito

Também conhecido como Diagrama Espinha de Peixe ou Ishikawa, o Diagrama de Causa e Efeito é uma técnica para descobrir, organizar e agrupar conhecimento a respeito das causas que contribuem para um determinado efeito. É muito usada no início do desenvolvimento de mudanças para alinhar o conhecimento da equipe a respeito do problema.

Há seis causas “comuns” (método, mão-de-obra, máquina, meio-ambiente, material e medição) proposta pela técnica. É claro que, ao aplicar na área de TI, pode haver outras causas necessárias a testar, coletando dados e realizando experimentos.

4.2. Lean

Enquanto o Six-Sigma está mais relacionado ao controle da qualidade, o Lean é uma filosofia de gestão inspirada nas práticas do Sistema Toyota, focada no controle da quantidade de produção para reduzir os desperdícios. Os sete desperdícios considerados são: superprodução, transporte, movimentação, excesso de processamento, estoque, defeito e tempo de espera.

A imagem abaixo resume os 4 P’s e os 14 princípios do TPS, além do JIT (Just in time) e Jidoka, pilares do Lean.

A análise de valor é percepção do cliente para determinar o que é desperdício:

  • Atividade que agrega valor (AV): atividade necessária p/ produzir um produto ou serviço e adiciona valor sob o ponto de vista do cliente
  • Atividade que não agrega valor (NAV): atividade realizada para produzir um produto ou um serviço, mas que não adiciona valor sob o ponto de vista do cliente.

4.2.1. A Casa do Lean

Assim como uma casa, que precisa ser construída apropriadamente para ter êxito, o Lean considera o uso adequado de estratégias para obtenção do sucesso.

A fundação inicia-se pela confiança, objetivos e o buy-in dos colaboradores e da liderança, sendo o suporte aos demais processos. As paredes, em geral, servem para otimizar os processos (eliminar desperdícios, melhorar a eficiência e a qualidade). O telhado é o foco no cliente e protege o resto da estrutura de encontrar problemas.

4.3. Sistema empurrado e puxado

No sistema empurrado, cada atividade entrega o resultado quando está pronto. Isso pode resultar em acúmulo de lotes com muitos intervalos.

Já o sistema puxado, cada atividade entrega o resultado apenas quando a próxima atividade precisa de sua entrada.

  • Disparado pelo cliente (externo e interno)
  • Minimiza o inventário e retrabalho devido a defeitos
  • Há poucos desperdícios
  • São ágeis em responder à demanda do cliente

4.4. VSM (Value Stream Mapping)

O Mapeamento do Fluxo de Valor é utilizado para apoiar os times a construir o fluxo de valor, que concretiza uma necessidade em um produto ou serviço para entrega de valor ao cliente. Facilita a identificação de desperdícios, gargalos, custos, etc.

É aplicável quando se busca oportunidade de melhoria em uma linha de produção, segundo a teoria dos desperdícios.

4.5. Poka Yoke

É uma ferramenta que ajuda a prevenir falhas humanas nos processos. “Tornar fácil fazer certo e difícil (quase impossível) fazer errado”. Muitas vezes é mais fácil alterar sistema do que o comportamento humano para prevenir os erros.

Os métodos Poka Yoke são: lembretes, diferenciação, restrições e exibições.

Tipos de Poka-Yoke

A prova de erro (preventivo)A prova de falha (detectivo)
Elimina a possibilidade de ocorrência da falha ou defeito específico, através do projeto   Detecta a falha ou defeito, caso ocorra, e previne que a não-conformidade continue no processo

5. Improve

A mudança como uma predição. Nessa fase, as soluções são criadas para resolver os problemas identificados na fase de Analyze (causa raiz de cada um). As principais ferramentas e praticas utilizadas são:

  • Plano de Ação – 5W2H
  • Kaizen
  • Matriz de Priorização
  • 5S

E verificar o grau de convicção da mudança: desenvolvendo, testando (em ciclos) e implementando as mudanças. Utiliza-se base de comparação histórica / simultânea e verificação de pontos vulneráveis.

Adicionar estágios para exibir mudanças no processo - Minitab

6. Control

O objetivo de monitorar os resultados obtidos é de perpetuar os conhecimentos e as melhorias conquistadas. Um plano de controle recomendado para manter as melhorias:

  • Realizar o plano de implementação com a abordagem 5W2H
  • Documentar o novo sistema
  • Treinar os envolvidos
  • Monitorar o sistema: manter o resultado e fonte de aprendizado. Existem técnicas simples, como a elaboração check-lists, e técnicas mais complexas, como o uso de controle estatístico de processos.
  • Estender o conhecimento e as melhorias conquistadas
  • Reconhecimento das pessoas envolvidas

O roteiro DMAIC na melhoria dos processos – Six Sigma – parte I

O roteiro DMAIC (Define-Measure-Analyze-Improve-Control) é um componente do Six-Sigma utilizado para melhorar os processos existentes da empresa, e assim apoiar as mudanças para que resultem em melhorias, tais como redução de problemas, defeitos e desperdícios.

Possui cinco etapas e um objetivo de conclusão para cada uma, afim de garantir a progressão do projeto de melhoria.

  • Define: definição do problema e prioridades
  • Measure: medição do estado atual
  • Analyze: encontrar a causa raiz do problema
  • Improve: mudança como uma predição
  • Control: perpetuar os conhecimentos e as melhorias conquistadas

1. Mudança e melhoria

Como é essa relação? Sabemos que a mudança nem sempre resulta em melhoria, mas a melhoria requer mudança. Por isso, os modelos de melhoria são utilizados para apoiar a realização da mudança, com análise de dados e entendimento de variabilidade.

Que mudanças podemos fazer que resultarão em melhoria? A mudança de fato somente é uma melhoria se ela é duradoura. A análise crítica sobre o processo atual, o uso de novas tecnologias e o pensamento criativo são alguns conceitos de mudança utilizados pelos modelos de melhoria.

Veja uma comparação (resumida) das fases do PDCA, DMAIC e MASP:

2. DMAIC – Define

É a fase de definição do escopo do projeto de melhoria. A elaboração do contrato do projeto declara o patrocinador / stakeholders envolvidos, contexto, objetivos, indicadores, prazos, restrições e o business case. As principais ferramentas que ajudam nas tarefas dessa fase:

  • SIPOC (suppliers – inputs – process – outputs – customers): uma representação dos aspectos relevantes do processo, onde será o foco de melhoria.
  • Diagrama direcionador: é uma ferramenta para organizar as ideias a respeito das possíveis mudanças.
  • Matriz RACI: definição de papeis e responsabilidades para as tasks do projeto

3. DMAIC – Measure

É imprescindível mensurar a mudança para determinar se houve uma melhoria significativa ou não. A confiabilidade da informação é essencial para apoiar as decisões e refletir a realidade. O time decide o que deve ser medido e como medi-lo. Alguns indicadores de aferição:

  • Medidas de resultado: as mudanças estão levando à melhoria?
  • Medidas de processo: estamos fazendo as coisas certas para atingir o nosso objetivo?
  • Medidas de equilíbrio: contra indicadores. A melhoria não pode gerar impacto em outros processos.

3.1. Ferramentas

3.1.1. Fluxograma

Identificar desconexões e oportunidades de melhoria no fluxo de trabalho. Inicia-se por um nível macro e verifica se já há oportunidades de melhoria, adicionando detalhes conforme necessário. Existe o fluxograma vertical e o multifuncional.

3.1.2. Gráfico de tendência e controle

O gráfico de tendência é uma ferramenta analítica simples para estudar a variação nos processos (eixo horizontal e vertical). O gráfico de controle é usado para analisar se um processo está ou não sob controle, e identificação das causas (comuns ou especiais) das variações.

Gráfico de tendência
Gráfico de controle

Exemplos de variações (observadas em gráficos de controle):

  • Um ponto muito afastado dos demais
  • Uma sequência de dez ou mais pontos acima da média

3.1.3. Gráfico de tendência

O Dot Plot é um gráfico que consiste em pontos de dados plotados em uma escala simples (conjuntos de dados de tamanho pequeno a moderado). O seu uso é para destacar clusters e gaps, além de discrepantes. A distância entre a média e os pontos máximo e mínimo são bons orientadores.

Dot plot
Histograma
Adding fitted distribution lines - Minitab

O histograma é usado para grande quantidade de dados (mais de 50 pontos) e checar a simetria dos dados. A diferença entre o ponto máximo e mínimo demonstra que este gráfico é pouco simétrico.

3.1.4. Gráfico de barras e setores

São ferramentas para estudar a distribuição de dados classificatórios (qualitativos).

Selecione as opções de exibição para Gráfico de barra - Minitab

3.1.5. Gráfico de pareto

Conhecida como regra 80/20, onde 80% das consequências provêm de 20% das causas. Também chamado de Vitais vs Triviais, onde a maioria dos problemas acontece muito pouco, e um pequeno grupo das categorias representa a maioria da frequência dos problemas.

Pareto se aplica
Exemplo de Gráfico de Pareto - Minitab
Pareto não se aplica
Fundamentos do gráfico de Pareto - Minitab

3.1.6. Estratificação

É a separação em grupos e classificação dos dados, de acordo com fatores ou variáveis selecionadas. O objetivo é encontrar padrões que auxiliem na compreensão dos mecanismos causais de um processo.

Quando utilizar? Sempre que houver interesse em estudar se o “comportamento” é o mesmo em todos os grupos definidos pelos fatores ou variáveis.

3.1.7. Gráfico de controle (Shewart)

Identificar a causa (comum e especial) das variações no processo. A partir de cálculos estatísticos estabelece três linhas: LC (limite central), LSC (limite superior de controle) e LIC (limite inferior de controle). Os tipos de variáveis são dados contínuos ou de classificação/contagem.

  • Gráfico U: usado para contar o número de defeitos. O indicador é uma taxa e pode ter valores maior que 1.
  • Gráfico P: usado para contar o número de unidades defeituosas. O indicador é uma proporção e precisa ser menor que 1.
  • Gráfico X: em dados contínuos com tamanho do subgrupo 1 e a distribuição dos dados é normal.
  • Gráfico X-barra/R ou X-barra/S: em dados contínuos coletados em subgrupos (amostras) de tamanho constante ou variável (/S).

3.1.8. Capabilidade

São medidas que indicam a capacidade de um processo atender às especificações de clientes. O Histograma é uma forma de representar graficamente a distribuição dos dados de uma amostra – capabilidade para variáveis contínuas.

Dentre as distribuições contínuas usadas em estatística, a distribuição normal (Gaussiana) é a mais usada. A distribuição normal possui dois parâmetros: a média (μ), ou seja onde está centralizada e a variância (σ ² > 0) que descreve o seu grau de dispersão. A dispersão ainda é referida em termos de unidades padrão, ou seja desvio padrão (σ).

Standard error - Wikipedia

No próximo post (parte II), continuaremos o roteiro DMAIC, detalhando as etapas de Analyze, Improve e Control.

Why are Cloud services so important in digital strategy?

Voltando ao contexto da transformação digital, onde os modelos de negócio (business agility, inovação, etc.) e tecnologias são utilizados para alavancar o desempenho da empresa e a experiência do cliente, um enabler imprescindível nessa jornada (a ser abordado nesse post) é Cloud e por isso, tem sido a “fundação” que habilita a transformação do negócio e o foco estratégico (cloud-first) de muitas organização -avançar o uso de Cloud Services.

A estratégia cloud-first deve ser compreendida pela organização toda (não somente TI) e assim, buscar a obtenção dos benefícios de negócio, tais como redução do custo operacional, time to market e melhora na escalabilidade e segurança das aplicações. O objetivo das empresas pode variar, onde algumas buscam a migração completa de seus data centers, já outras apenas alguns subsets de aplicações para Cloud pública. Por isso, cloud-first não significa cloud-always.

Uma boa vantagem em utilizar Cloud Services é o uso sob demanda (otimização de recursos, sem grandes investimentos para começar a usar e sem desperdícios), escalabilidade e segurança, pois os recursos são gerenciados pelo provedor.  O desenho abaixo representa os principais Cloud Services que a AWS oferece:

aws-services

Inovação – Build, Buy e Borrow

Em geral, continuar com o recursos que você já domina, ampliando o uso da tecnologia existente é uma das opções consideradas. Evite a armadilha do resume-driven development, deixando as pessoas escolherem as tecnologias boas para o seu próprio currículo, e não para o problema.

Caso não seja possível ampliar o uso da tecnologia existente, então utilize os serviços do tipo pay-as-you-go. Esses serviços gerenciados (ou SaaS) reduzem a carga de trabalho em configuração e gestão de itens de infraestrutura, dedicando mais tempo a inovação e publicação de novas releases. A decisão build para novas tecnologias in-house pode gerar desperdício de custo, tempo e oportunidade. Avalie bem, pois o produto criado, em geral, é o diferencial competitivo, e não a tecnologia construída.

buy-build-borrow

Alguns elementos críticos para a inovação: cultura e pessoas, processos e organização, produtos e tecnologia. A estratégia Build, Buy or Borrow pode ser utilizada nesse contexto, e resumida da seguinte forma:

  • Build: quando já possui a expertise na empresa, core business, propriedade intelectual / patente ou pioneira no segmento.
  • Buy: quando é atividade core ao negócio, tem relação estratégia de mercado ou tempo crítico para lançamento.
  • Borrow: reduzir o risco, aumentar o time to market e customização em mercados específicos.

buy-build-borrow-matrix

Ao decidir a migração para Cloud Services, alguns benefícios comumente obtidos são:

  • Redução de riscos: capacidade de adaptar-se rapidamente as mudanças (por permitir testar com frequência e efetuar correções rápidas).
  • Escalabilidade: redimensionar seus recursos conforme necessário.
  • Confiabilidade: capacidade do sistema se recuperar de falhas de infraestrutura ou serviço ou adquirir recursos para atender à demanda e mitigar interrupções.
  • Segurança dos dados: propriedade total sobre seus dados.

cloud-benefits

 

Estratégias de migração Cloud

Uma das estratégias mais recomendadas para migração de aplicações em Cloud é o 6R’s da AWS, baseada no 5R’s de Gartner. Essa discussão, em geral, ocorre na segunda fase (Portfolio Discovery and Planning) do processo de migração, onde são determinados os ambientes, interdependências e o que será priorizado na migração.

A complexidade de migração varia, dependendo muito da arquitetura e do licenciamento existente. Enquanto uma arquitetura orientada a serviços possui baixa complexidade, um mainframe monolítico certamente trará uma alta complexidade. A figura abaixo resume os 6R’s:

6Rs-migration
Figura: AWS

  • Rehosting (“lift-and-shift”): não há mudanças na arquitetura. É a reimplantação do aplicativo em um ambiente de hardware diferente (em cloud). Isso altera a configuração da infraestrutura do aplicativo.
  • Replatforming: a arquitetura ainda não sofre alterações, mas há otimizações em Cloud para obter benefícios. Por exemplo, a migração do banco de dados para uma plataforma de banco de dados como serviço, como Amazon RDS.
  • Repurchasing : mudança para um produto diferente (geralmente em SaaS), tal como um CRM para SFDC.
  • Refactoring / Re-architecting: alterações nas práticas de desenvolvimento e arquitetura, usando recursos nativos em Cloud, que provê a infraestrutura para a execução do seu aplicativo.
  • Retire: descobrir o que não é mais utilizado em seu ambiente e que pode ser desativado, e assim, focar a atenção da equipe em aplicações que trazem benefícios ao negócio.
  • Revisit: não fazer nada (por enquanto). Isso acontece em aplicativos que foram atualizados recentemente ou que não fazem sentido migrar por enquanto.

 

Estágios de adoção

A AWS possui um conjunto de estágios que descrevem a postura associada as organizações na adoção Cloud. São quatro estágios:

  • Stage 1 – Project: inicia com alguns projetos para entender como a nuvem vai atender as necessidades do negócio. Utiliza experimentação em projetos early cloud, POCs, análise TCO/ROI e preparação a riscos/segurança.
  • Stage 2 – Foundation: com a percepção dos benefícios iniciais, a empresa pode escalar a adoção em toda a organização. A recomendação é criar um CCoE (Cloud Center of Excellence), responsável pelo treinamento/capacitação dos colaboradores, gestão de custos e ativos, estratégia de arquitetura híbrida, arquitetura de referência, entre outros.
  • Stage 3 – Migration: define-se então a estratégia de migração, geralmente iniciada com o processo de descoberta de aplicativos e um business case, seguido por migrações individuais (em várias estratégias de migração diferentes).
  • Stage 4 – Optimization: muitas empresas acham mais fácil otimizar seus aplicativos depois de migrá-los para a nuvem. Nesse estágio há infraestrutura automatizada e gestão própria do stack de soluções.

Targeted Business Outcomes - AWS Prescriptive GuidanceFigura: AWS

Processo de migração

A preparação e o planejamento para migração envolve work streams que atuam nas áreas de Landing Zone, Modelo Operacional, Governança, Security & Compliance, Pessoas (skills), Application Portfolio, Processo de Migração e Business Case.

Com o uso de metodologia, processos, ferramentas e recursos, define-se um objetivo de migração, geralmente avaliado em 3 à 4 meses de trabalho (estruturado em Sprints). Durante essa fase, as equipes realizam migrações iniciais para criar experiência e confiança através de quick wins. Os principais deliverables de preparação a migração são:

  • Landing Zones: configuração de ambiente seguro de várias contas.
  • CCoE (Cloud Center of Excellence) / Cloud Operations Model: treinamento e capacitação adequada aos times. Determinar as práticas operacionais para maximizar os benefícios de negócio.
  • Security and Compliance: resolução de gaps e implementação de práticas de segurança e compliance.
  • Portfolio Discovery and Migration: sequenciamento e planejamento das migrações.

 

Conclusão

Como vimos acima, a utilização de Cloud Services é um enabler muito estratégico a ser considerado no seu plano de transformação digital ou estratégia digital. Há diversas estratégias de migração, pois sabemos da dificuldade em manter os serviços core (nem sempre criados com as melhores práticas) em funcionamento e o custo que essa decisão pode acarretar na criação de novos produtos para a empresa.

A escolha de um bom parceiro é essencial para apoiar a jornada de adoção Cloud. Essa jornada exige skills especializados, tanto no conhecimento do negócio e aplicações da própria empresa, quanto em tecnologias Cloud. Além disso, uma boa governança é fundamental para habilitar o plano de migração e readiness e garantir em conjunto com a equipe que os objetivos serão atingidos.

Por fim, verifique os benefícios e aplicabilidade real em seu ambiente. As análises financeiras, tal como o TCO (Total cost of ownership), também são importantes para apoiar suas decisões. Quais são os custos de oportunidade e operacionais em manter aplicações ou serviços no ambiente atual? É possível ser inovador nesse cenário? Já avaliou alguma PoC? As features que mais geram receita para o negócio estão bem dimensionadas (custo x retorno)? Há insights com o uso de dados coletados? E o monitoramento e segurança das aplicações?

VSM (Value Stream Mapping) – do current ao future state

Após a introdução do Value Streams Mapping e seus benefícios, veremos aqui as etapas de criação, sequenciando as atividades que a empresa realiza para atender as demandas do cliente. O fluxo de valor percorre todas as áreas da organização, rompendo silos (entre áreas), em busca de oportunidades de melhoria e redução de desperdícios.

O mapeamento, em geral, envolve colaboradores experientes (e de áreas chaves) por ser um processo complexo e multifuncional. O cliente é a principal razão de acontecer o VSM. Por isso, verifique os benefícios e melhorias que podem ser feitas para os clientes. Quais os problemas que estamos resolvendo? Estamos melhorando a nossa capacidade de entregar valor e remover desperdícios?

O VSM é mais aplicável a processos repetíveis, especialmente quando houver handoffs (tempo de espera) entre os times, que é onde a maioria das demoras e desperdícios se encontram. O mapeamento possui três principais etapas: current state (estado atual; identificar os processos core business), future state (onde devemos estar em alguns dias com os recursos atuais) e next future state (visão estratégica “ideal” de onde poderia estar com recursos e automações ainda não disponíveis).

Um exemplo clássico, representado no desenho abaixo, demonstra todas as etapas de um processo para concluir a entrega do cliente. O value added time é tempo gasto em atividades que agregam valor ao produto. E o Lead Time é a soma de todos os tempos, do início ao fim do processo (inclui os tempos de espera entre as etapas). Percebe-se então a presença de gargalos no fluxo, devido a somente 15 minutos em atividades que agregam valor ao produto, e 68 dias para concluir o processo.VSM

Entre as principais métricas consideradas no VSM que ajudam a compreender os fluxos de entrega ao cliente estão: 

  • Lead Time: tempo decorrido entre o pedido e a entrega, medindo seu processo de produção da perspectiva do cliente.
  • Cycle Time: considera entre o tempo de inicio do trabalho e termina quando está pronto para entrega.
  • Takt Time: é a taxa de demanda do mercado (o ritmo do mercado), ou seja, o que precisa ser cumprido para atender à demanda do cliente.

lead-time-cycle-time

Current state
O desenho abaixo é um exemplo real de como era o ciclo de desenvolvimento em uma empresa, onde o Lead Time era de 19 horas – tempo médio entre o recebimento de uma demanda (via abertura de ticket) e o deploy em produção. Por questões de compliance, a empresa precisava de algumas aprovações e documentos durante o processo.

ALM-analise

Foram identificados alguns gargalos nesse fluxo:

  • Tempo de espera alto para validação do usuário e aprovação da mudança (change management). Causa: documentos preenchidos manualmente durante o processo geravam um checklist demorado.
  • Deploy manual demandava tempo de preenchimento do documento de publicação e do publicador em seguir as etapas.
  • A fase inicial (planning design) exigia a preparação de documentos que seriam utilizados no decorrer das etapas.


Future state

Ao reunir os colaboradores para discutir o future state do fluxo de valor, lembre-se de seguir alguns princípios Lean, tais como a criação do Flow (fluxo), processos vinculados aos clientes, eliminar os desperdícios, evitar super produção (seguir o takt time) e lotes grandes.

Existem diversas ferramentas que ajudam a mapear o fluxo de valor. O desenho abaixo é somente para ilustrar o fluxo to be com as principais mudanças (sem o uso de uma ferramenta específica para VSM), automatizando o deploy e simplificando o registro das informações das RDMs. Essas ações reduziram significativamente os tempos de espera entre trabalhos e o tempo que era gasto com preenchimento manual de documentos (documento de teste técnico, homologação e publicação).

change-management-process

VSM Symbols
Para conhecer melhor os símbolos que podem ser utilizados no VSM, recomendo assistir esse vídeo abaixo:


Playbook
Após ver todos esses conceitos importantes no VSM, como você planeja reunir as pessoas e conseguir mapear os fluxos de valor da sua organização? Um Workshop de VSM (2-3 dias) seria muito apropriado para isso, desde que considere alguns pontos:

  • Identificar um facilitador com experiência em VSM.
  • Identificar e priorizar Value Streams que tenham impacto no cliente e na estratégia organizacional. Escolha a que mais atenda a necessidade da empresa.
  • Envolver um Sponsor (ou champions) comprometido com o future state.
  • Empoderamento do time para realização das mudanças.
  • Na dinâmica, considerar o uso de Charter para discutir escopo, declaração do problema, objetivos e métricas.
  • Considerar a visão ideal future state (de longo prazo) com tecnologias e automações que ainda não estão disponíveis, mas que a visão estratégica deseja ter.
  • Levantar oportunidades e atribuir owners para as implementações.
  • Governança para acompanhamento das ações e planejamento de melhorias.

Também acordar uma reunião com o Sponsor e stakeholders para revisar os objetivos do Workshop, treinamentos (caso seja necessário), atividades Pre Workshop, facilities e a logística dos colaboradores.

VSM-agenda


Outcomes
Os resultados esperados com o VSM incluem melhorias nos tempos de entrega e percepção do cliente (lead time e cycle time), da qualidade e experiência de uso, além da redução de desperdícios no processo. Após a execução da agenda citada acima, os outcomes gerados são:

  • Mapa do fluxo current state
  • Mapa do fluxo future state (e ideal future state)
  • Métricas de performance
  • Plano de transformação para atingir o future state

VSM-outcomes

Entrega contínua de valor, mas o que é valor?

Muitas organizações vem investido na transformação ágil c/ a corriqueira reestruturação de times multifuncionais e “produtizados”, mudança de cultura, práticas DevOps, etc. para obter a tal a entrega contínua de valor. Mas o que é valor? Será que a sua organização compreende bem o value driven no ciclo de entrega e de fato, gera valor ao negócio?

Veremos mais adiante que o significado de valor pode variar para cada cliente, baseado na sua percepção em relação a aquisição, retorno financeiro, aderência compliance, posicionamento de mercado, entre outros. Esses conceitos iniciaram no Value-driven design (VDD), desenvolvido pela AIAA com a estratégia de realizar escolhas de design para maximizar o valor do sistema, em vez de atender aos requisitos de desempenho.

vdd

O Lean Startup aborda o trabalho em condições de extrema incerteza, com foco na descoberta de modelos de negócio disruptivos e valor gerado. A Values hypothesis verifica o valor gerado ao usuário pela resolução de um problema real. E a Growth hypothesis testa com que rapidez podemos adquirir novos clientes.

Também como identificar quando o product/market fit foi alcançado e como explorar o produto com o mercado identificado. E o uso de métricas para verificar se os resultados de negócio estão sendo obtidos, por exemplo, utilizando vanity metric e o correspondente actionable metric.

vanity versus actionable metrics

Ao utilizar o Scrum, por exemplo, certamente há o papel do Product Owner (PO) para maximizar o valor de negócio, priorizando as user stories de acordo com estudos e validações de hipóteses. Como o Scrum não prescreve uma definition of value, o PO fica como o responsável em decidir o que é valor ou não para o time. Claro, que em muitos casos alinhado com o  Product Manager.

organizacao-agil

Mas será que mesmo o time cumprindo a Sprint (ou outros ciclos de entrega) com produtos de qualidade e em ritmo sustentável, está entregando valor a organização? E o que acontece se não houver uma boa definition of value? Veja algumas perguntas reflexivas sobre a geração de valor na sua organização:

  • De que forma é verificado se todo o trabalho feito pelo time resulta em valor?
  • Há uma relação entre o esforço na construção das features e retorno?
  • Quais critérios são usados p/ verificar se uma feature tem mais valor que a outra?
  • Afim de maximizar o valor entregue, como são as decisões e comportamentos?
  • Plan Driven x Value Driven: como está o planejamento e aprendizado contínuo?

 

Geração de Valor

Embora haja inúmeras definições sobre a geração de valor e aplicabilidade em diferentes áreas, o nosso foco aqui é explorar a entrega de valor no contexto de desenvolvimento de software e produtos, utilizando métodos ágeis. Veja duas definições bem conhecidas:

Manifesto Ágil: um dos doze princípios ressalta a entrega de valor.

Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.

DevOps: definição da própria Microsoft sobre o propósito em adotar práticas DevOps.

É a união de pessoas, processos e produtos para permitir a entrega contínua de valor aos nossos usuários finais.

O termo business value é um dos meus preferidos, pois enfatiza o trabalho em prol da empresa ou do negócio como um todo de alguma forma. Acredito que tenham esses tipos diferentes de valor ao negócio (comentem caso utilizem algum outro):

business-value

  • Commercial Value: são as funcionalidades que geram receita ou saving para a empresa, tais como assinatura de serviço, versões ou módulos pago a usuários, aquisição de produtos e % attrition.
  • Market Value: tem mais relação com as ações de conversão/retenção de clientes e posicionamento da marca. Pode usar métricas de engajamento em redes sociais, taxa de conversão, custo de aquisição do cliente, entre outros. Também ser orientadas a inovação, criando novas funcionalidades que concorrentes não possuem.
  • Customer Value: a percepção de valor e experiência de uso dos clientes para aumentar as chances de continuar usando seus produtos. Testes A/B de usabilidade, interação, tempo de permanência, % retenção e NPS (Net Promoter Score).
  • Efficiency Value: melhorar a eficiência organizacional com a identificação dos fluxos de valor e automação de processos. A percepção de valor é na redução de erros em aplicações, lançamento frequente de novas funcionalidades (redução do time to market) e na redução de custos com suporte e manutenção.
  • Others: empresas regidas por compliance possuem percepção de valor em processos sob controle e auditáveis. Por isso, nesses casos, é muito importante construir funcionalidades que garantam a aderência as leis e regulamentações, por exemplo validação de passwords fortes, segregation of duties (SoD) e gestão de acesso.

Por fim, sabemos que o processo de Validated learning (muito abordado no Lean Startup) é descobrir empiricamente informações valiosas para o futuro e presente negócio da empresa. E que o modelo de experimentação contínua e validação de MVPs (Minimum Viable Product) é muito usado em Startups para criação de valor e evitar desperdícios.

Há nesse contexto o burn rate, adotado por muitas Startups para definir o valor gasto em um determinado produto, antes de começar a gerar receita. Ou então a decisão de pivotar para outra solução. Como a análise é muito investigativa (sobre estar construindo a solução correta a um mercado), a percepção de valor e métricas devem ser revisadas frequentemente.

 

 

 

 

Inovação contínua – Design Thinking, Lean Startup, Agile e DevOps

Não somente as Startups, mas diversas empresas tem adotado o modelo Spotify (ou outros modelos), para ajudar na estruturação de times multifuncionais e orientados a produtos “produtizados”, afim de trabalhar na entrega de valor contínua aos clientes. Tudo isso, certamente em virtude de uma estratégia organizacional que desdobra ações para atingir seus principais objetivos, tais como aquisição de novos clientes, ROI, retenção, NPS (Net Promoter Score), etc.

squads

O livro Lean Enterprise – Enabling Innovative Culture traz conceitos fundamentais para melhorar a visão de negócio e criar um modelo de experimentação / validação de hipóteses na empresa. Assim como o livro The Lean Startup que aborda o Value Vs. Waste, onde o Lean thinking “define valor como um benefício para o cliente; qualquer outra coisa é desperdício”.

Se a reestruturação tem ocorrido da melhor forma? Em outros posts, acrescento conteúdos de Value Streams, Business Agility e gestão de dependência entre os times para complementar esses temas. O acordo por enquanto é que o processo de inovação engloba a cultura de aprendizado, pessoas colaborativas e experimentação – ou seja, modelar uma hipótese, testá-la rapidamente, aprender/ajustar e tentar novamente.

build-measure-learn-loop

Para isso, muitas empresas precisam de uma engrenagem que conduz o ciclo completo, desde a concepção até a entrega dos produtos (introduction – growth – maturity – decline) e entregar o produto que as pessoas precisam e querem comprar, termo conhecido como product / market fit. É isso que vamos falar mais adiante nesse post.

Antes de escolher o seu toolbox ou as melhores metodologias, verifique a aplicabilidade delas, mediante o seu contexto. O Cynefin Framework é utilizado para entender e distribuir os projetos e portfólios no domínio de acordo com a sua complexidade. Esse é o caminho inicial para avaliar o uso das melhores práticas, em meio a análise estratégica.

cynefin-framework

time to value é quando os clientes começam a perceber o valor em seus produtos, podendo utilizar e se beneficiar da inovação. O ideal é poder inovar e entregar continuamente. Por isso, muitas organizações estão mudando sua abordagem de “projeto” para “gerenciamento de produto”. Entre as principais diferenças:

project-manager-vs-product-manager

E como orquestrar as fases compreendidas no processo de inovação? Ao criar novos produtos, em geral, ainda não existem hipóteses validadas com dados reais para análise e revisão. A construção da Value Proposition declara os principais motivos pelos quais seus produtos/serviços satisfazem as necessidades dos clientes.

Com essa visão do produto, da estratégia, customer understanding e product execution, algumas abordagens foram criadas para representar os ciclos iterativos e experimental, oriundos de práticas como Design Thinking, Lean Startup, Lean UX, Agile, Growth Hacking e DevOps. A ideia é conectar desde a concepção das ideias até a liberação dos produtos aos usuários. Façam seus comentários e quais ajustes são aplicados em sua organização para os modelos abaixo:

design-thinking-lean-agile-growth-hacking

Um breve resumo sobre cada fase:

Discovery e Inception
Traz abordagens de criação de produtos e soluções inovadoras para os problemas. Será discutido o problema do cliente a ser resolvido, valor entregue do produto,  abordagens de customer acquisition, MVP (Minimum Viable Product) e customer understanding (como os clientes vão interagir com o produto – jornadas, personas, pesquisas, funcionalidades e métricas de validação).

O Design Thinking busca de forma colaborativa (com pessoas ao centro do desenvolvimento do produto) encontrar soluções inovadoras para os problemas. O foco está em necessidades do mercado, e não em pressuposições estatísticas. Utiliza dois diferentes tipos de pensamento:

  • Divergente: pensamento amplo, considerando qualquer ideia.
  • Convergente: pensamento estreito, identificando e focando em um ou dois dos principais problemas e soluções.

design-thinking-II

Lean Startup
Criação de um modelo dinâmico para produtos e validar hipóteses no mercado, como os testes A/B por exemplo. Também viabilizar o time-to-market, trabalhando com entregas contínuas e criando MVPs (Minimum Viable Product) para validar as principais premissas do negócio.

O modelo Build-Measure-Learn Feedback Loop habilita o ciclo de criação e teste de hipóteses, começando pequeno para clientes potenciais, medindo suas reações e aprendendo com os resultados. O objetivo é evoluir o produto para entregar exatamente o valor esperado para o cliente.

lean-startup


Agile
Utiliza abordagem incremental e iterativa. A cadência baseada em Sprints maximiza as oportunidades para feedback e previsibilidade, entregando um incremento potencialmente liberável do produto “Pronto”.

Entre alguns benefícios da gestão ágil:

  • Visibilidade: visibilidade e transparência durante todo o ciclo.
  • Adaptabilidade: planejamento iterativo torna fácil a adaptação em caso de mudança de requisitos.
  • Business Value: o planejamento e feedback contínuo trazem entrega de valor desde o início do projeto.
  • Risco: e assim diminuem os riscos associados ao desenvolvimento.

dad-safe-scrum

DevOps
A habilitação de DevOps é fundamental na transformação digital e entregas contínua com atuação nos pilares pessoas, processos e produtos. As práticas essenciais do DevOps incluem planejamento ágil, integração contínua (CI), entrega contínua (CD) e monitoramento de aplicativos.

O termo pipeline é muito utilizado em DevOps, pois é onde está o foco em automatizar os processos e garantir a entrega contínua de aplicações em produção com eficiência e confiabilidade. O Fluxo de valor cobre desde a concepção do produto até a geração de valor para a empresa.

As práticas DevOps são essenciais para criar o pipeline de implantação, disponibilizando novas versões de software o tempo todo ao cliente. O Feedback contínuo vai guiando a estratégia da empresa, eliminando barreiras entre os departamentos. Isso permite a colaboração entre as pessoas para gerar valor ao cliente.

principios-derivados

Growth Hacking
É o marketing orientado a experimentos, ou seja, o Growth Hacking é uma prática que promove o crescimento acelerado, através da descoberta de gatilhos. Visa encontrar oportunidades/brechas (hacks) e criar estratégias de resultados rápidos para o crescimento (growth) da empresa.

O Growth Hacking é totalmente focado na experimentação, seguindo o funil  de Dave McClure – AARRR (Acquisition – Activation – Retention – Revenue – Referral) Pirate Funnel Metrics.

AARRR

Como o funil do Growth Hacking não tem demarcação de fronteira, para alguns produtos/serviços a Retention e Revenue podem andar juntas. Por exemplo, quando o cliente continua utilizando algum serviço e continua pagando (receita). Identifique em quais estágios estão os problemas de maior urgência. É um bom meio de começar a aplicar o Growth Hacking. Em resumo, o processo compreende:

  • Geração de ideias
  • Seleção de ideias
  • Modelagem de experimentos
  • Realização de experimentos
  • Análise de resultados

Priorização de requisitos e projetos – product management

Com a evolução contínua no modelo de negócios, onde as empresas precisam de adaptação rápida e time to market, um bom critério de priorização é primordial para avaliar os projetos (ou requisitos dos times) e evitar desperdícios, além de maximizar ao máximo a entrega de valor ao negócio.

Muitas empresas ainda estão viciadas no ciclo de receber/trabalhar/entregar muita demanda, porém isso entrega valor ao negócio? E quanto aos critérios de priorização? Desta forma, vamos abordar algumas técnicas de priorização que ajudam a direcionar o esforço das equipes, baseado em critérios.

Outro ponto é a aplicabilidade. As técnicas abaixo foram criadas com um propósito específico (a serem utilizadas em projetos ou requisitos), mas podem ser adaptadas a outros níveis (time, programa ou portfólio). Também vale avaliar se o mercado é B2C ou B2B, pois a validação de hipóteses com os usuários finais podem gerar indicadores que servem como critério de priorização (tais como conversão, churn, uso, etc.).

MoSCoW

O MoSCoW (Must haveShould haveCould have and Won’t have) é uma das técnicas de priorização, geralmente utilizada com timeboxing – deadline fixado e o foco é nos requisitos mais importantes. Ajuda a comunicar o que será feito de imediato ou não.

  • Must Have (Deve Ter): são as funcionalidades imprescindíveis para o projeto. Devem ser refinadas (ou aprofundadas) para melhorar o entendimento do time.
  • Should Have (Deveria Ter): é importante ter, mas não são imprescindíveis.
  • Could Have (Poderia Ter): seria bom ter, mas não são essenciais. Porém, entregá-las pode ser um diferencial ao cliente.
  • Won’t Have for Now (Não Terá por Enquanto): por hora não será feito, já que não gera valor ao negócio naquele momento.

moscow

RICE

Outro acrônimo para Reach (Alcance), Impact (Impacto), Confidence (Confiança) e Effort (Esforço). Os três primeiros itens da matriz são pontuados e divididos pelo último. Isso ajuda a medir o impacto de cada tarefa no todo e a determinar a prioridade mais alta do backlog.

Fórmula: R * I * C / E

  • Reach: qual o alcance desta tarefa (pessoas impactadas)?
  • Impact: o grau do impacto nas pessoas
    • Impacto Massivo: 3
    • Grande Impacto: 2
    • Médio: 1
    • Baixo: 0,5
    • Impacto Mínimo: 0,25
  • Confidence: quão confiante estamos nas estimativas
    • Alta confiança: 100%
    • Confiança média: 80%
    • Baixa confiança: 50%
    • Mínima confiança: 20% ou menor
  • Effort: o tempo necessário para concluir a tarefa

 

BASICO

A BASICO possui seis critérios que apoiam a priorização de projetos e processos. Cada critério é pontuado de 1 a 5 e o resultado é a soma dos critérios (1 = pior cenário; 5 = melhor cenário). As maiores notas são priorizadas.

  • Benefícios para a empresa
  • Abrangência dos resultados
  • Satisfação do cliente interno
  • Investimento necessário
  • Cliente externo satisfeito
  • Operacionalidade simples

 

GUT

Outra opção é a GUT que possui três critérios e pontuação de 1 a 5 também para classificar a prioridade dos projetos.

  • Gravidade: classifica as ações que você precisa realizar conforme o impacto que elas terão em outras atividades ou projetos;
  • Urgência: considera o tempo restante para resolver cada situação;
  • Tendência: é uma projeção da velocidade que um problema não resolvido pode levar para piorar.

gut

 

WSJF (Weighted Shortest Job First)

A técnica WSJF, criada por Don Reinertsen e recomendada no SAFe, apoia a priorização de features, maximizando o custo do atraso (COD – Cost of Delay) e a duração do trabalho. E assim, em regra geral:

  • Features com a mesma duração = priorizar as que possuem maior custo do atraso, pois assim minimizaria o custo total.
  • Features com o mesmo custo de atraso = priorizar as que podem ser lançadas mais rapidamente, pois assim minimizaria o custo do atraso.

Como o custo do atraso e duração das features podem variar muito de uma para outra, o WSJF contribui muito na priorização com a seguinte fórmula:

  • WSJF = Cost of Delay / Job Duration (Job size)

E o custo de atraso é calculado da seguinte forma:

  • Cost of Delay = User Business Value + Time Criticality + Risk Reduction and/or Opportunity Enablement

WSJFFonte: SAFe (Scaled Agile Framework)

 

Technical Certainty x Business Agreement

Entre as diversas matrizes que existem para priorização de requisitos, a matriz da Tech and Business Review da Lean Inception é uma que sintetiza bem o valor do negócio x esforço para construção das features. Possui nove quadrantes.

  • Technical Certainty: como o time de desenvolvimento avalia a complexidade para criar a funcionalidade.
  • Business Agreement: quão bem o negócio concorda com o que entra na feature.

As features de certeza técnica baixa (E) e valor de negócio baixo ($) são descartadas do MVP de imediato. Assim como, certeza técnica média (EE) e valor de negócio baixo ($); também são descartadas as features do quadrante certeza técnica baixa (E) e valor de negócio médio ($$). As demais serão avaliadas conforme a técnica da Lean Inception.

business-effort-matriz

Outras técnicas

  • Modelo Kano
  • QFD (Quality Function Deployment)
  • Opportunity Scoring
  • Buy a feature
  • Matriz de Eisenhower (Urgência X Importância)
  • Matriz Esforço x Impacto
  • Matriz de Custo x Benefício