Systems Thinking Approach to implementing kanban

/0 Comentários/em /por

O Pensamento Sistêmico é uma forma de entender como o sistema se comporta como um todo, ao invés de de analisar componentes isolados. Entender o sistema é fundamental e vai influenciar na definição dos passos para introduzirmos o Kanban em uma organização. As etapas neste processo não são necessariamente sequenciais, mas são iterativas, usando o aprendizado de uma etapa para informar e influenciar as outras em um ambiente colaborativo. Os passos são:

Passo 0: Identificar os serviços

Para cada serviço:


Cursos de Excel e Power BI

Passo 1: Entender o que faz um serviço ser ajustado ao propósito do cliente

Passo 2: Entender a origem das insatisfações do processo atual

Passo 3: Analisar a demanda

Passo 4: Analisar a capacidade

Passo 5: Modelar o fluxo de trabalho

Passo 6: Descobrir as Classes de Serviço

Passo 7: Projetar o sistema kanban

Passo 8: Socializar o design e negociar a implementação

STATIK é aplicável a apenas um serviço. Quando tivermos mais de um serviço as práticas e cadências do Kanban são aplicadas para equilibrar a demanda e o fluxo através dos vários serviços, e melhorar continuamente. A ordenação das etapas podem variar na prática e é normal para revisar os passos em busca de melhorias.

PASSO 1: ENTENDER O QUE FAZ UM SERVIÇO SER AJUSTADO AO PROPÓSITO DO CLIENTE

Esta primeira etapa é considerada um tópico mais avançado e em muitos casos em implementações iniciantes ou com baixa maturidade ele é ignorado.

Explore os critérios que definem a satisfação do cliente com a prestação dos serviços. Os critérios são geralmente relatados, mas não são limitados ao tempo de entrega, qualidade, previsibilidade, segurança ou marcos regulatórios. Estes critérios são conhecidos como critérios de adequação, porque determina como o cliente avalia se a prestação do serviço é aceitável, ou se servem ao propósito.

Explorar e estabelecer níveis de expectativa para cada critério. Estes são conhecidos como os limites aplicados aos critérios de adequação. Eles representam o “bom o suficiente” ou o ponto onde o desempenho é satisfatório. Essas métricas devem tornar-se indicadores chave de desempenho (KPIs) e ser usado para estabelecer Níveis de Expectativas de Serviços (SLEs) ou informar negociações dos Acordos de Níveis de Serviço (SLAs) onde apropriado. Os critérios limites de adequação são usados para conduzir melhorias e mudanças evolutivas.

Onde este passo é inicialmente ignorado, teremos que retroceder na para a implementação do Kanban. O aumento da maturidade organizacional e rigor quantitativo são necessários para futuras melhorias.

PASSO 2: ENTENDER A ORIGEM DAS INSATISFAÇÕES DO PROCESSO ATUAL

Esta etapa é feita em duas etapas: perguntar ao cliente porque eles não estão felizes; perguntar a organização que está prestando o serviço se eles têm fontes internas de insatisfação — levantar os itens que estão impedindo-os de fazer um trabalho bom e profissional e de satisfazer as expectativas dos clientes.

Frequentemente as fontes de infelicidade em cada lado, externas e internas, podem ser combinadas — consertando uma, você conserta a outra. Por exemplo, um cliente pode reclamar da entrega imprevisível e atrasada, enquanto que internamente, os trabalhadores podem se queixar de serem interrompidos e prejudicados com pedidos não planejados ou novas requisições em uma classe de serviço mais urgente.

Se pudermos identificar as fontes das demandas não planejadas e o que está prejudicando a equipe, podemos eliminar as interrupções, tornando nossa prestação de serviços mais previsível. Corrigindo um problema, pode-se fazer ambos os lados mais feliz — os trabalhadores não sendo interrompidos, eles podem se concentrar em fazer um trabalho profissional e consequentemente o cliente receberá a entrega dentro de um intervalo razoável em relação a sua expectativa inicial.

Fontes de insatisfação fornecem subsídios para desenharmos o Kanban. Vamos tentar projetar o Sistema Kanban, a capacidade alocada e as classes de serviços para eliminar o máximo de problemas possível. A julgar o quanto pode ser alcançado sem criarmos uma resistência significativa, estas alterações são consideradas um tema de treinamentos avançado e fora do âmbito do Kanban Essencial.

PASSO 3: ANALISAR A DEMANDA

A fim de criar um sistema kanban adequado, precisamos saber a natureza da demanda: quem são os clientes; o que eles pedem; como é a taxa de chegada; o padrão de entrada dos pedidos e quais são suas expectativas — seria uma versão mais light, mais qualitativa do passo 1. Se o passo 1 foi ignorado, por exemplo, “esperamos entregas mais previsíveis para a maioria dos pedidos”.

A primeira tarefa é identificar os tipos de itens de trabalho. Por exemplo, se nós operamos um café, nós estamos no negócio de servir café. O que é equivalente a um pedido de uma xícara de café no ambiente de análise? Quantos tipos diferentes de requisições existem?

Descobrir o tipo de trabalho pode ser um problema não tão óbvio e as pessoas muitas vezes lutam para chegar a um equilíbrio entre o os níveis de detalhes suficiente e um nível adequado de abstração. Por exemplo, uma xícara de café pode ser muito abstrato, mas cada item no menu como um tipo de item de trabalho separado remete a muitos detalhes.

O equilíbrio pode ser atingido ao separarmos café expresso, café filtrado,café por gotejamento, separar café de chá e outras infusões. Ter vários tipos facilita uma melhor gestão dos riscos e indica o fluxo e os recursos necessários, tais como a máquina de café expresso. Ter muitos tipos de trabalho não provê uma agregação suficiente de requisições similares que facilitem a abordagem probabilística para a gestão da natureza não-determinística da demanda.

Para cada tipo de item de trabalho identificado, queremos entender a taxa de chegada — o volume de demanda — o padrão de chegada — a taxa de demanda ao longo do tempo e em diferentes momentos do dia, das semanas, dos meses e do ano. Queremos entender o fluxo e o refluxo da demanda.

Por exemplo, um café pode reconhecer um aumento na demanda por xícaras de café das oito às nove da manhã, ou imediatamente depois do almoço.

Compreender o volume da demanda, a natureza de chegada e as expectativas ou os riscos do negócio associados aos pedidos, nos permitirá projetar um sistema kanban elaborado com a atribuição de capacidade para diferentes tipos e diferentes classes de serviço para gerir riscos específicos. Por exemplo, um demanda com data fixa, tais como eventos sazonais, feiras, grande eventos mundiais como Jogos Olímpicos ou mesmo datas impostas sem possibilidade de negociação. O quanto deste tipo de demanda existe? Qual a taxa de chegada deste tipo de demanda e quando chega? Com quanto tempo de antecedência ela chega? Este tipo de trabalho pode exigir sua própria classe se serviço para assegurar que receba um tratamento prioritário e seja sempre entregue no horário.

Em implementações maduras e avançadas, a demanda é analisada em categorias como valor versus falha, entrega versus demanda por informação, contestáveis versus incontestáveis, planejada versus demanda não planejada. Está análise adicional é informada no sistema kanban, mas também servirá para ações de melhorias que deverão ser tomadas mais tarde.

PASSO 4: ANALISAR A CAPACIDADE

Analisar a capacidade é um passo que em muitas implementações é ignorado, principalmente em organizações com baixo nível de maturidade ao se criar um sistema novo.

Analisar a capacidade envolver estudar os dados históricos em relação ao que já foi entregue: tempo de atravessamento, qualidade funcional e não funcional, previsibilidade, conformidade com os requisitos ou normas regulamentares. A capacidade atual pode ser comparada com as expectativas de nível se serviço dos clientes.

Dado que existam fontes de insatisfação, é provável que exista uma lacuna, talvez uma das mais importante entre a capacidade atual e as expectativas dos clientes existentes. É comum um Diagrama de Fluxo Contínuo histórico ser utilizado na análise de capacidade e ainda podemos tentar alguns cálculos de eficiência de fluxo se os dados estiverem disponíveis saber o tempo de trabalho (esforço despendido) e a duração das atividades (tempo decorrido no calendário).

PASSO 5: MODELAR O FLUXO DE TRABALHO

A modelagem do fluxo de trabalho deve ser realizada para cada tipo de trabalho. É importante não confundir modelagem de fluxo de trabalho com o mapa da cadeia de valor, ou a ida ao Gemba do lean manufacturing e o Sistema Toyota. Mais uma vez, estamos trabalhando em serviços profissionais em ambiente de bens intangíveis. Kanban se adaptou a isso adotando técnicas de mapeamento de fluxo vindos do Desenvolvimento de Produto Enxuto. Ambos Reinertsen e Kennedy têm descrito técnicas de modelagem de fluxo de trabalho semelhantes, mas usando uma linguagem um pouco diferente. Em geral, nós preferimos a linguagem de Kennedy, mas a abordagem do Reinertsen nos leva ao resultado.

Você mapeia a série ou a sequência dos passos principais para descobrir novos conhecimentos. Nós estamos modelando o trabalho do conhecimento. Que atividade nos dá mais conhecimento? Em algum momento haverá retorno decrescente desta atividade e então teremos que nos mover para a próxima atividade dominante. Em um processo de desenvolvimento de software nós adquirimos conhecimento ao analisarmos um problema ou mesmo um domínio do negócio. Mais tarde nós poderemos utilizar o desenho do sistema para resolver problemas ou simular funcionalidade do negócio. Mais tarde nós desenvolvemos os códigos e os testes. Depois executamos os testes. Em cada fase temos mais conhecimento, mais detalhes da entrega final. È uma abordagem iterativa, onde mais conhecimento está na camada de cima onde existe menos conhecimentos específicos. Reinertsen usa a palavra “informações” em vez “conhecimento”, mas são equivalentes — definir a sequência de atividades dominantes utilizadas para descobrir informações sobre o produto acabado.

È importante mapearmos as atividades e não as transferências entre as pessoas. Ao contrário do mapa da cadeia de valor ou da ida ao gemba, nós não queremos um quadro Kanban que mapeia a transferência entre as pessoas, em vez disso, queremos o focar no trabalho e no que acontece com ele. Nós queremos nosso sistema kanban (e o quadro) para incentivar a colaboração em vez de evidenciar o engessamento dos setores ou especializações funcionais existentes.

A palavra “dominante” também é importante. A qualquer momento pode haver várias atividades acontecendo, mas uma delas é a atividade dominante para descobrir novos conhecimentos. Por exemplo, quando uma função de um software está sendo testada, dizemos que ela está em teste. É a atividade de teste que é a atividade dominante para a produção de novos conhecimentos. Os testes podem falhar e resultar em retrabalho no código, no design ou mesmo na análise. No entanto, é a falha no teste que produz novos conhecimentos. Neste exemplo, o uso da palavra informação pelo Reinertsen faz mais sentido. É a falha no teste que nos fornece a nova informação sobre o produto acabado.

PASSO 6: DESCOBRIR AS CLASSES DE SERVIÇO

A classe de serviço é um conjunto de políticas que descrevem como algo deve ser tratado. Normalmente com os sistemas kanban, as classes de serviços descrevem a disciplina de enfileiramento ou prioridade dos tickets. Classes de serviços também podem descrever a política que afeta o fluxo de trabalho, tais como se um item precisa receber tratamento de um especialista ou ser testado com um nível específico de qualidade. Classes de serviço também podem fornecer informações sobre cronograma ou se determinado item pode exceder o WIP ou não.

Se houver classes existentes de serviço, elas devem ser declaradas explicitamente, e devem ser acomodadas pelo sistema Kanban. No entanto, é mais comum que estejamos lidando com classes de serviços ocultas ou implícitas. Por exemplo, se há a política de que um tipo de trabalho permite interromper um outro tipo, consequentemente interromper um desenvolvedor para dar prioridade a outro tipo de trabalho, essas políticas são descritas como classes de serviços implícitas. Queremos expor esse tipo de política, pois nos leva a perguntar: “Você realmente quer nos dizer que trabalho do tipo X tem prioridade sobre trabalhos do tipo Y?”

Classes de serviços ocultas existem quando não há política, mas alguns itens recebem o tratamento diferente dos outros. Muitas vezes isso acontece por causa da fonte de demanda ou o destino da entrega. É comum encontrar pedidos de um executivo sênior que não estejam passando pelo processo formal de governança e seleção formal e vão para o topo da priorização. Queremos identificar essa classe, atualmente oculta e serviço e torná-la explícita. Será importante que todo o nosso sistema Kanban seja projetado para lidar com as classes de serviço, ou que eles sejam expostas aumentando a transparência para facilitar uma discussão que nos permite incluí-las no quadro.

PASSO 7: PROJETAR O SISTEMA KANBAN

Um sistema kanban consiste em quatro elementos principais: o sistema e o kanban; os tickets, o quadro; ajustes as reuniões existentes, bem como a introdução de novas para acomodar os ciclos de feedback conhecidas como as Cadências do Kanban.

Para projetar o sistema kanban, precisamos de modelo de fluxo de cada tipo de trabalho, conhecer as atividades dominantes para descobrir novos conhecimentos e as classes de serviço.Vamos querer inventar limites (WIP) para cada fase, tipos e classes de serviços através do quadro.

Para incluirmos um ticket, vamos precisar entender quais as informações são requeridas em cada estágio do fluxo, a fim de tomarmos a decisão de puxar um item para o próximo estágio. Normalmente precisamos do tipo de item, da classe de serviço, datas de início e fim se aplicáveis, se será no fluxo do especialista ou não, e espaço para gravar o tempo decorrido desde do início, os bloqueios, tempo em cada etapa, riscos de negócio, técnico ou de entrega, associados a um determinado item que poderia afetar sua seleção, seu sequenciamento ou agendamento.

Para projetar o quadro, precisamos entender o fluxo de trabalho de cada item. Precisamos tomar a decisão de ter um único quadro para todos os tipos ou classes, ou ter dois ou mais quadros. Precisamos decidir como alocar as colunas — usualmente as fases do fluxo — as linhas — usualmente os tipos ou composições destes — e as cores dos tickets — geralmente para as classes de serviços.

É possível que haja trocas entre o sistema, o quadro e o fluxo e o ticket. Por exemplo, se termos um conjunto de atividades opcionais que podem acontecer em qualquer sequencia, mesmo que simultâneo, podemos optar por termos um quadro simples com uma única coluna , um fluxo simples e um sistema kanban com apenas um tipo de ticket para todas estas atividades, e usar um checkbox no próprio ticket com as etapas “requerido” — “pronto” a fim de lidar com o sequenciamento não determinado e potencial concorrência entre as atividades.

Como regra geral, quanto mais determinista nosso sistema, vamos esperar ter um quadro e um fluxo mais complicado, quanto menos determinista mais simples, porém com um cartão de ticket mais complicado.

Temos um total de 7 reuniões de cadência no método Kanban. É comum que em novas implementações comecemos com algumas delas. Também é comum redirecionarmos as reuniões existentes. Decida quais as reuniões serão implementadas. Decida quais as reuniões existentes serão redirecionadas. Você pode usar os exercicio da formação Kanban Management Professional para definir a cadência das suas reuniões: selecione quem será o facilitador, a frequência e a duração, quem deve participar e quais informações precisam trazer, quais as decisões serão tomadas nas reuniões e quais métricas e relatórios serão necessárias.

PASSO 8: SOCIALIZAR O DESIGN E NEGOCIAR A IMPLEMENTAÇÃO

O método STATIK incentiva oficinas colaborativas para análise e criação de sistemas Kanban e os quadros. Como consequência da natureza colaborativa dos workshops e dos exercícios seguindo os passos do STATIK, é comum para todos os envolvidos participarem da mudança e ficarem orgulhosos da implementação. Em outras palavras, nossa abordagem é ganhar adeptos e envolvê-los no projeto.

Ao selecionar os grupos para a construção do STATIK, é interessante contarmos com pessoas internas e externas à organização. Times multifuncionais, clientes, stakeholders externos e tomadores de decisão.

Dito isto, não é realista que todos os stakeholder terão um papel definido nas oficinas de STATIK. É necessário circular o produto da oficina, a fim de obter um grupo mais amplo para aderir ao projeto. Embora este seja um campo avançado, existem alguns princípios básicos:

Faz sentido se reunir com as partes interessadas em particular. Se eles são stakeholders externos, vale a pena começar com humildade. Explique como você entende a prestação de serviços e que está procurando fazer as alterações para melhor atender os clientes. Explique que as mudanças são principalmente internas, mas os que estão de fora poderão notar as mudanças de como interagimos, mudança na interface de como eles fazem novos pedidos, como aprovam ou selecionam os trabalhos para serem entregues, mudança nas métricas, relatórios e visibilidade do que eles tem no novo sistema, comparado com o anterior.

Caminhe com eles através do sistema, explicando como funciona do ponto de vista deles, ouvindo o feedback. Você vai obter algumas objeções que exigirão ajustes nas classes de serviços, nas atribuições de capacidades, nos desenho do quadro e nas exigências de relatórios. Quando for possível, faça as mudanças no quadro e nos istema. Procure pelo consenso ao mostrar que as alterações propostas irão atender as necessidades do stakeholders, assumindo que as mudanças serão adequadamente aplicadas.

Retrabalhar seu projeto para acomodar o que você aprendeu com a socialização. revisitar algumas partes interessadas para o ateste de que suas preocupações foram incorporadas.

Depois de ter feito isso, você está pronto para realizar uma reunião de kick-off para lançar a iniciativa Kanban e a introdução das mudanças. Convide todos os stakeholders.

Mais uma vez, comece com humildade. Você entende que a prestação de serviço não foi eficiente, você está procurando fazer mudanças para melhorar e satisfazer todos os envolvidos considerando que os recursos são limitados e não infinitos e alguns compromissos tem que ser aceitos. na medida do possível preserve o que está funcionando bem e foque apenas no necessário para melhorar a prestação do serviço. Os presentes podem notar mudanças na forma de como eles interagem com o grupo, mas por outro lado os papéis e responsabilidades não devem ser afetados. Agora apresentamos o detalhe do projeto explicando como cada parte interessada, os tipos de trabalho e as classes de serviços foram acomodadas. Para os agentes internos que são afetados pela mudança nas suas funções ou responsabilidades, explique o que estas mudanças significam. Forneça detalhes sobre a revisão das reuniões existentes para acomodar as cadências do Kanban. Explique onde os quadros ficarão situados ou onde o software está sendo implantado.

Você deve estar pronto para começar.

Tradução do artigo publicado por David Anderson

Sobre o autor

Rodrigo Zambon
Sólida experiência em Metodologias Ágeis e Engenharia de Software, com mais de 15 anos atuando como professor de Scrum e Kanban. No Governo do Estado do Espírito Santo, gerenciou uma variedade de projetos, tanto na área de TI, como em outros setores. Sou cientista de dados formado pela USP e atualmente estou profundamente envolvido na área de dados, desempenhando o papel de DPO (Data Protection Officer) no Governo.
0 respostas

Deixe uma resposta

Want to join the discussion?
Feel free to contribute!

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *