Dependência em projetos impactam diretamente o seu fluxo de trabalho. Se o seu fluxo está impactado certamente os atrasos começarão a acontecer. Caso estes atrasos venham a se concretizar, a sua entrega será tardia. A entrega de valor neste caso ficará comprometida e as insatisfações começam. As dependências devem ser muito bem gerenciadas.

Para começar esse post, interdependência pode ser concebida como duas dependências distintas; nos estudos organizacionais, os dois termos são tratados como equivalentes.

Strode & Huff (2012) definem dependências da seguinte forma:

uma situação que ocorre quando o progresso de uma ação depende da saída rápida de uma ação anterior ou da presença de uma coisa específica.

O fato é que dependências ocorrem em projetos ágeis e waterfall. Vamos procurar abordar neste breve post dependências em ambos os tipos de projetos.

Quando temos duas ou mais atividades em um projeto, poderemos ter dependências. Imagine que avanço do seu trabalho tenha as atividades A e B. Se A tem que ser feita antes de B, podemos dizer que você tem uma dependência e isso irá atrasar seu fluxo.

Thompson em 1967 concebeu três tipos de interdependência relacionados ao fluxo de trabalho: combinado, sequencial e recíproco.

No fluxo de trabalho combinado, o trabalho entra em uma unidade de trabalho e os atores realizam atividades de forma independente; o trabalho não flui entre eles. Podemos descrever essa situação como uma em que cada parte tem uma contribuição discreta para o todo e cada uma é apoiada pelo todo. 

O fluxo de trabalho sequencial ocorre quando o trabalho entra em uma unidade, passa entre os atores em uma única direção. Temos aspectos de atividades combinadas aqui, entretanto temos uma ordem não simétrica. 

No caso de fluxo de trabalho recíproco, a saída de uma atividade é a entrada da atividade na sequência. Você acaba criando uma contingência entre  duas ou mais atividades.

A autor relaciona os tipos de dependências à complexidade organizacional. Todas as organizações têm interdependências combinadas, organizações mais complicadas tem atividades sequenciais e consequentemente combinadas. As mais complexas tem os três tipos.

Thompson ainda afirma os pontos de dependências são onde as organizações ficam mais vulneráveis. Atribuiu a complexidade a profundidade das dependências e que quanto mais complexa for, mais explicita as políticas devem ser. O autor conclui que a própria civilização traz consigo o aumento das dependências.

Quanto mais complexa a dependência, maior será o custo de coordenação. Para minimizar o impacto destes custos, uma das vias plausíveis é a padronização. Isso inclui rotinas, processos definidos, cadências e eventos para tratar dependências adequadamente. Em dependências mais complexas, a coordenação deve ser por meio da aprendizagem e troca de informações constantes entre os membros do time. Encurtar o ciclo de feedback é fundamental para minimizar os impactos causados.

Com a evolução do trabalho, os conceitos de dependências também precisam ser revistos. O identificado por Thompson foi fundamental, entretanto existem vários questionamentos na literatura sobre o estudo. Embora ainda muito citado, ele não leva em consideração a natureza e a complexidade do trabalho. Simplesmente atribui dependências a uma relação padrão de estruturas de tarefas.

Dependências são consideradas importantes em vários domínios relevantes para o desenvolvimento de software. Abrangendo esses domínios está uma teoria interdisciplinar da coordenação desenvolvida por Malone e Crowston (1994). Sua Teoria da Coordenação enfoca a dependência como um elemento fundamental na coordenação.

A Teoria da Coordenação baseia-se no princípio de que “coordenação é o gerenciamento de dependências entre atividades” (Malone e Crowston, 1994, p. 90). Mais tarde, Malone et al. (1999) propuseram que uma dependência pertence a um dos três tipos fundamentais: ajuste, fluxo ou compartilhamento. Neste conceito, recursos e atividades interagem para formar dependências.

Uma dependência de ajuste ocorre quando várias atividades produzem um único recurso.

Uma dependência de fluxo ocorre quando uma atividade produz um recurso usado por outra atividade

Uma dependência de compartilhamento ocorre quando duas ou mais atividades usam um único recurso. Por exemplo, esse tipo de dependência surge quando duas atividades precisam ser feitas pela mesma pessoa, quando precisam usar a mesma máquina em um chão de fábrica, ou quando ambas usam dinheiro do mesmo orçamento.

Já Wagerman define a interdependência de tarefas quando “cada membro deve agir para que qualquer outro membro faça qualquer parte de seu trabalho”, e localiza a fonte de tal interdependência não na tarefa em si, mas sim na “estrutura organizacional, nas instruções de trabalho e materiais”, ou seja, devemos busca o cunho sistêmico das dependências. De acordo com essa interpretação, as mesmas tarefas poderiam exibir diferentes tipos ou graus de interdependência em diferentes estruturas organizacionais.

Um outro exemplo é de Eppinger et al (1994). Ele foca na forma ou no padrão de relacionamentos de tarefas em projetos de design complexos, separando tarefas interdependentes (acopladas) (“quando a tarefa A precisa de informações da tarefa B, e a tarefa B também requer conhecimento dos resultados de A”), tarefas dependentes (serial) (“se a tarefa B simplesmente requer a saída da tarefa A”) e tarefas independentes (paralelas) “se as tarefas A e B pudessem ser realizadas simultaneamente sem interação entre os projetistas”).

O modelo para tratar as dependências em projetos e nas organizações deve ser customizados. Uma boa gestão visual e transparência nas ações dos membros do time são pré-requisitos essenciais nesta coordenação. Minimizar as dependências deve ser uma atividade rotineira do time, tanto em relação aos outros membros, quanto à organização.

Referências Bibliográficas

EPPINGER, Steven D.; WHITNEY, Daniel E.; SMITH, Robert P.; GEBALA, David A. A Model-Based Method for Organizing Tasks in Product Development. Research in Engineering Design, Massachusetts Institute of Technology, Cambridge, Massachusetts, USA, v. 6, p. 1-13, 4 mar. 1994.

STRODE, Diane E.; HUFF, Sid L. A Taxonomy of Dependencies in Agile Software Development. 23rd Australasian Conference on Information Systems, Geelong, p. 1-10, 3 dez. 2012.

Thomas W. Malone, Kevin Crowston, Jintae Lee, Brian Pentland, Chrysanthos Dellarocas, George Wyner, John Quimby, Charles S. Osborn, Abraham Bernstein, George Herman, Mark Klein, Elissa O’Donnell, (1999) Tools for Inventing Organizations: Toward a Handbook of Organizational Processes. Management Science 45(3):425-443.

THOMPSON, James D. Organizations in action: Social science bases of administrative theory. New York: MC Graw-Hill, 1967. 192 p. v. 1. ISBN 07-064380-6.

Tweet do Troy Magennis que motivou a pesquisa: https://twitter.com/t_magennis/status/804032573542277120

WAGEMAN, Ruth. Interdependence and Group Effectiveness. Administrative Science Quarterly, Johnson Graduate School of Management,Cornell University, v. 40, n. 1, p. 145-180, 3 mar. 1995.

O Sistema Toyota de Produção, foi criado no Japão após a Segunda Guerra Mundial com o intuito de produzir lotes pequenos de muitos tipos de produtos. O grande objetivo do TPS (Toyota Production System) é a eliminação de desperdícios na produção. Tornar a produção mais econômica através da identificação e correção do que está causando atrasos, perda de material, de tempo e outros fatores que não agregam em nada determinada atividade.

A coordenação da produção no TPS era feita pelo Sistema Puxado, orientado a demanda. Somente vamos produzir o que cliente solicitar. A parte principal do sistema desenvolvido pela Toyota é o kanban. Os kanbans, cartões em português, são elementos de informação que controlam a produção. São eles que impulsionam o mecanismo do sistema puxado, controlam o estoque, transporte, o que está sendo produzido e o que será entregue.

O processo de produção na manufatura acontece em diversas etapas, sendo que em cada uma estabelecemos os limites da quantidade de itens, e uma etapa não pode começar sem que um kanban indique que de fato ela pode começar.

Uma outra característica do TPS é o Heijunka, utilizado para nivelar e balancear a linha de produção. Este nivelamento é utilizado em conjunto com os kanbans. Nós utilizamos o nivelamento para ajustar a demanda com a capacidade das máquinas definir os ciclos padrão de produção. Empresas com um desnível muito grande e orientadas aos estoque acabam produzindo demais em uma semana e na outra ficam ociosas. O desequilíbrio de recursos são causados por falhas no upstream.

Nivelamento

O Método Kanban, desenvolvido por David Anderson, busca fazer a analogia do que foi descrito acima, para os trabalhadores do conhecimento.

Em times com baixa maturidade, o desnivelamento das atividades acabam gerando os temidos gargalos. Muitas vezes em sala de aula, quando explico o conceito, é comum os alunos se identificarem. Muitos deles, inclusive são os gargalos.

Em organizações públicas geralmente encontro vários projetos em um único time, com extrema dificuldade para priorização das tarefas. Muitas delas urgentes, que podem surgir a qualquer momento. Isto inviabiliza qualquer tipo de nivelamento e dificulta a previsibilidade e o EPEI (each part, each interval), o que ajustamos para – este projeto, este intervalo.

Quando você consegue nivelar a demanda, com as pessoas do time, nossa capacidade de responder as interferências aumenta. O objetivo do nivelamento é atender a mais de um cliente, com lotes pequenos a um fluxo contínuo, fornecendo previsão de acordo com os demais itens do sistema. O nivelamento também ajuda a eliminar o efeito chicote, relacionado a variação da demanda.

Times Multifuncionais

Para que possamos dentro de um mesmo time, produzir o ponta a ponta de um processo, precisamos ampliar nossa capacidade de formar times multifuncionais dentro das organizações. O Heijunka chama isso de balanceamento da linha.

Quando temos times de especialistas, a interdependência aumenta o tempo para entregarmos uma tarefa. Cada time cuida apenas da parte que lhe foi atribuída, dependendo dos demais para  concluir todo o trabalho. E por falar nisso, o objetivo de cada time é atender àquela especialidade, deixando o todo em segundo plano. Complementando, temos a falsa sensação de produtividade quando alocamos 100% da capacidade de um time. Manter todos sempre ocupados é a missão de muitos gestores.

As vantagens de se ter um time multifuncional são inúmeras, principalmente na qualidade das entregas. O desperdício por espera por informações também é reduzido, visto que este time tem recursos para completar todo o trabalho, sem depender de outros. O conflito entre a variação da demanda e um desenvolvimento saudável é minimizado em times com características multifuncionais.

Fechamento

Para que possamos diminuir os desperdícios, primeiro precisamos identificá-los. Em uma linha de produção é mais fácil, em um escritório é mais difícil. Uma boa dica é para de começar tarefas e terminar as que já foram iniciadas. Estoque de tarefas inacabadas aumentam o tempo de setup quando você muda de uma tarefa para outra.

Procure montar times que possam entregar todo o trabalho. A visão fragmentada dos processos aumenta o tempo e diminui a qualidade além de agravar os conflitos nas prioridades.

Em times com baixa maturidade e que estejam começando a utilizar o Kanban, opte por quadros físicos. No início a transparência pode ser um problema. Meça o sistema e não as pessoas.

Trabalhe sempre pela melhoria contínua!

Referências:

M. Di Mascolo · K. Furmans,  Buffer sizing of a Heijunka Kanban system

Monden, Y. (1998). Toyota production system: An integrated approach to just-in-time, 3rd edn. Norcross, Georgia: Engineering and Management Press.

Spearman, M. L., Woodruff, D. L., & Hopp, W. J. (1990). CONWIP: A pull alternative to Kanban. International Journal of Production Research, 23, 879–894.

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:

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