Posts

Dependências em projetos

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.

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

Método Kanban – Informações

Muitos alunos me perguntam sobre as referências em relação ao Método Kanban. Nas aulas eu apresento o livro clássico do David Anderson, mas nós temos outros livros que servem de apoio para aprimorarmos nosso conhecimento no método.

Vou atualizar este post com frequência caso tenhamos novas referências.

Livros

Kanban: Mudança Evolucionaria de Sucesso Para Seu Negocio de Tecnologia

Autores: Donald G. Reinertsen, David J. Anderson, e outros.

Link para comprar

Quem quer começar com o método deve ler este livro. É leitura obrigatória! No livro, David Anderson explica os fundamentos do método, e como foi a transição do kanban da manufatura para nós, trabalhadores do conhecimento. O livro é repleto de cases e exemplos práticos. 

 

Fit for Purpose: How Modern Businesses Find, Satisfy, & Keep Customers (English Edition) por [Anderson, David J, Zheglov, Alexei]Fit for Purpose: How Modern Businesses Find, Satisfy, & Keep Customers

Link para comprar

Autores: David J Anderson e Alexei Zheglov

Este livro também apresenta muitos exemplos comerciais altamente acessíveis. Este livro ajudará você a encontrar novos clientes em novos segmentos de mercado, a satisfazer melhor seus clientes existentes e a mantê-los.

O livro destina-se a planejadores estratégicos, gerentes e planejadores de produtos, gerentes de portfólio, projetistas de serviços, gerentes de prestação de serviços e a qualquer pessoa que queira entender como lançar e manter produtos nos mercados complexos e voláteis do século XXI.

 

Kanban Maturity Model: Evolving Fit-for-Purpose Organizations

Autores: David J Anderson e Teodora Bozheva

Link para comprar

O Kanban Maturity Model (KMM) é uma ferramenta nova e poderosa para coaches e consultores que assessoram empresas de médio e grande porte na transformação e melhoria usando o Método Kanban. Este livro mapeia sete níveis de maturidade organizacional contra as seis práticas gerais do Kanban para assegurar a aplicação apropriada do Kanban e a adoção bem-sucedida da abordagem. O KMM descreve um roteiro e ações concretas que permitem que as organizações atinjam a agilidade de negócios adequada ao propósito.

 

Practical Kanban: From Team Focus to Creating Value (English Edition) por [Leopold, Klaus]Practical Kanban: From Team Focus to Creating Value

Autor: Klaus Leopold

Link para comprar

Neste livro o autor descreve em detalhes os princípios e funcionalidades do Kanban, que nem sempre são intuitivas. Ele discute problemas típicos que observou em seu trabalho com sistemas Kanban do mundo real. Klaus ilustra as possibilidades que existem quando toda a cadeia de criação de valor de uma empresa é levada em conta. Fica claro que o Kanban não é um método de equipe, mas sim um método de melhoria que considera toda a cadeia de criação de valor de uma empresa.

 

Lessons in Agile Management: On the Road to Kanban (English Edition) por [Anderson, David J]

Lessons in Agile Management: On the Road to Kanban

Autor: David J Anderson, Alan Shalloway, Stephen Denning

Link para comprar

Esta coleção de mais de 150 artigos compilados do blog Agile Management e de várias outras fontes representa 12 anos de insights inestimáveis ​​de David J. Anderson no gerenciamento de desenvolvimento de software de 1999 até 2011. Cada artigo foi cuidadosamente selecionado e agrupado em 16 capítulos sobre temas como Liderança, Gestão, Teoria das Restrições, Políticas de Recursos Humanos, Agile, Lean e Leading Change Initiatives. Cada capítulo é apresentado com comentários contemporâneos, explicando sua relevância e contribuição para o Ágil e o Kanban.

 

Kanban Change Leadership: Creating a Culture of Continuous Improvement (English Edition) por [Leopold, Klaus, Kaltenecker, Siegfried]Kanban Change Leadership: Creating a Culture of Continuous Improvement

Autor: Klaus Leopold, Siegfried Kaltenecker

Link para comprar

Este livro fornece uma compreensão do que é necessário para entender adequadamente o gerenciamento de mudanças com o Kanban, bem como como aplicá-lo de maneira ideal no local de trabalho. Os autores organizaram o livro em três seções. A primeira seção foca os fundamentos do Kanban, estabelecendo a base técnica e indicando os mecanismos necessários para promulgar a mudança. Na segunda seção, os autores explicam o contexto do gerenciamento de mudanças – as opções de mudança, como elas podem ser colocadas em movimento e suas consequências para um negócio. A terceira seção aborda os tópicos das seções anteriores e os relaciona ao sistema social de negócios – o objetivo é guiar os leitores no processo de construção de uma cultura de melhoria contínua, revisando estudos de casos reais e vendo como o Kanban é aplicado em várias situações.

 

Kanban from the Inside: Understand the Kanban Method, connect it to what you already know, introduce it with impact (English Edition) por [Burrows, Mike]Kanban from the Inside: Understand the Kanban Method, connect it to what you already know, introduce it with impact

Autor: Mike Burrows, Luke Hohmann

Link para comprar

Kanban from the Inside tem uma abordagem distinta do Método – usando um sistema de nove valores para explicar o que é o método. Também dá uma ideia de como seus praticantes pensam, e ainda apresenta algumas dicas sobre como aplicá-lo. Leitores novatos no Kanban entenderão por que e como funciona, enquanto aqueles com experiência apreciarão sua nova perspectiva e as conexões que ela faz com uma série de modelos relacionados.

 

Certificações

A principal certificação de Kanban hoje no mundo é a KMP. Ela é dividida em dois níveis: O KMP I e o KMP II. Para se certificar em Kanban Management Professional, os dois treinamentos são necessários. A principal certificadora é a Lean Kanban University.

Confira as certificações em Kanban da Lean Kanban University

Team Kanban Practitioner
Kanban Management Professional
Kanban Coaching Professional
Accredited Kanban Trainer

No Brasil temos excelentes treinadores de Kanban, com destaque para duas empresas: Aspercom e a Knowledge 21.

As duas empresas fornecem o treinamento oficial da Lean Kanban University!

Link para o meu perfil na LKU: Rodrigo Zambon

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

Kanban: nivelamento e times multifuncionais

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.

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

Introdução ao Pensamento Sistêmico

Ouvimos a todo momento a palavra sistema. Está presente em nosso dia a dia, em casa, onde trabalhamos, nas instituições que frequentamos, nas coisas que compramos. Somos membros de diversos sistemas e todos os dias interagimos com os elementos que compõem cada um.

Em um sistema, a soma de suas partes não representa o todo. Mesmo que todas as partes isoladamente sejam boas, isso não significa que vamos ter um bom sistema. Mais importante que cada parte são as interações existentes entre cada uma e claro conhecer o todo a qual estão inseridas. Systems Thinking é uma maneira de pensar as relações entre as partes de um sistema, saber onde ajustar para conseguir as melhorias desejadas e expandir nossos horizontes em buscas de soluções mais efetivas.

Se você é da área de design ou já trabalhou com softwares tais como o photoshop, você deve conhecer a ferramenta Zoom Out. Basicamente, para gerenciarmos um sistema precisamos dar um zoom out no nosso cenário e enxergar quais os demais aspectos estão influenciando o problema ou situação que queremos resolver.

Por exemplo, as taxas de obesidade estão crescendo cada vez mais e vamos supor que você foi designado como gestor de um programa para reduzir estes índices. O primeiro instinto é criar um programa para as pessoas se exercitarem. Mas, o que na realidade podemos esperar desta abordagem? System Thinkers acreditam que ver apenas uma parte do problema, de forma isolada sem considerar o sistema maior onde isto opera não é o ideal. Tendemos a ignorar outros aspectos que podem influenciar no impacto. Por que? Pesquisas nos mostram que a obesidade é um resultado de uma combinação de muitos problemas: fisiológicos, psicológicos, sociais, e econômico interagindo uns com os outros.

Por exemplo, no nível do indivíduo, existem questões hereditárias, hábitos exercicios, escolhas do que comer,  e ainda a forma como trabalham. Mas, indo além do indivíduo, nós temos outros fatores tais como o ambiente físico que permite, por exemplo, fácil acesso a lanchonetes de fast food e diversos anúncios de promoções, principalmente as práticas deste tipo de restaurante, como o tamanho das porções, combos e sobremesas. A interação de todas estas influências faz da obesidade o que nós chamamos de um Complex System.

Vamos supor que você tenha em sua organização um problema de comunicação, e você é indicado para resolver este tipo de questão. A intuição nos condicionará a irmos até nossa área de comunicação e ampliar nossos canais. Mas será que o simples fato de ampliarmos os canais resolveria os problemas? E se o processo de comunicação for lento e a informação demorar para chegar até as pessoas? E se a forma de escrever as notícias não for atraente? E se as pessoas preferem vídeos ao invés de textos escritos? Certamente, quando nós ampliarmos este cenário, vamos descobrir mais partes deste sistema que nos ajudarão a buscar soluções mais efetivas. Vamos descobrir outros pontos de alavancagem, fora das soluções tradicionais.

Daniel Kin define um sistema como sendo um grupo de partes que interagem e formam um todo com um propósito específico. A chave é lembrar que as partes são interrelacionadas e interdependentes de alguma forma, sem essas interdependências nós temos apenas uma coleção de partes e não um sistema.

Para Russell Ackoff, um sistema é um conjunto de dois ou mais elementos que se relacionam com as seguintes caraterísticas:

  • Cada elemento tem efeito no funcionamento do todo;
  • Cada elemento é afetado por pelo menos um outro elemento do sistema;
  • Todos os possíveis subgrupos de elementos, possuem as duas propriedades acima.

Para ilustrar as definições acima, vamos classificar a seguinte lista em um conjunto de itens ou um sistema:

  • tigela de frutas;
  • time de futebol;
  • torradeira;
  • uma cozinha;
  • banco de dados com nomes de clientes;
  • ferramentas em uma caixa de ferramentas;
  • um casamento.

Quais destes são sistemas ou simplesmente são um conjunto de itens? Vamos analisar cada um:

Uma cozinha, a base de dados com os nomes do clientes e as ferramentas em uma caixa de ferramentas são somente um conjunto de itens. Não há relação entre as partes que compõem estes conjunto, embora a cozinha por exemplo esteja repleta de sistemas (geladeira, microondas, lavadora de roupas), isto são um conjunto de elementos em um lugar (cozinha).

Time de futebol e a torradeira, ambos são sistemas. Eles são colocados juntos para atenderem a um propósito específico. O propósito atua como força organizadora predominante em qualquer sistema. Se você quiser entender o porquê de um sistema estar organizado de alguma forma específica, procure entender o propósito.

Tigela de frutas. Muitas pessoas classificariam como um conjunto, porque as frutas não estão interrelacionadas e não interagem uma com as outras. Na verdade em um nível microscópico elas estão interagindo. Por exemplo, se você colocar certas frutas juntas, elas irão se decompor mais rápido, pois interagem em um nível molecular.

Um casamento. Para qualquer um que viu um casamento como um conjunto, é melhor procurar um aconselhamento matrimonial imediatamente. Brincadeiras a parte, o casamento é um estado de interdependência voluntariamente escolhido com outra pessoa (não a co dependência que é completamente diferente). Existe alguém entre nós que não costumamos lembrar, ou que nossas ações tenham impacto sobre ele ou ela? Às vezes, é assim que nós descobrimos que estamos em um sistema, e como aprendemos de maneira dolorosa que somos parte de um sistema maior do que podemos perceber.

Espero que estes exemplos possam contribuir para o nosso entendimento. Estamos inseridos em diversos sistemas que interagem entre si. No próximo artigo vamos detalhar a Quinta Disciplina: Pensamento Sistêmico!

Referências:

The Systems Thinker – http://thesystemsthinker.com/introduction-to-systems-thinking/

Vídeo Youtube: http://www.youtube.com/watch?v=2vojPksdbtI

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

Systems Thinking Approach To Implementing Kanban

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

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

A Retrospectiva GameStorm

GameStorm é uma técnica de brainstorming desenvolvida por Bart Hufen da  BrandNewGame. Utiliza gamification com o objetivo de identificar áreas para melhoria e tornar seu impacto transparente. Nós fizemos uma adaptação para uso em Retrospectivas Sprint e melhoria contínua nas equipes. Este formato é excelente para uma série de Retrospectivas de Sprint focados em um desafio recorrente e torna muito transparente o que precisa ser melhorado e como.

Os créditos completos para a forma do game vão para  BrandNewGame  – nós apenas o simplificamos para uso em Retrospectivos Sprint. Você pode obter todos os materiais oficiais do GameStorm (e muitas técnicas de jogo e ferramentas digitais), tornando-se membro da Gamification Academy. Junte-se ao seu  próximo treinamento nos dias 21 e 22 de março ou em setembro para aprender a aplicar este jogo a mudanças organizacionais e obter mais jogos. Ele se encaixa perfeitamente com o Scrum.

Material

  • Uma sala com uma grande mesa no meio e espaço para se mover;
  • Um GameStorm-canvas (modelo abaixo) por grupo;
  • Post-its laranjas e rosas;
  • Pincéis ou canetinhas;
  • Dois relógios para marcar o tempo;

O canvas do GameStorm

Abaixo, compartilhamos um canvas do GameStorm vazio. Este não é o oficial que a BrandNewGame usa, é uma versão personalizada que usamos para as  Retrospectivas.

No final da Retrospectiva, a tela deve conter o seguinte:

  • Post-it azul: o desafio global que a equipe quer abordar;
  • Post-it’s amarelos na parte superior: os três maiores obstáculos que precisamos abordar;
  • Post-it’s rosas (no canvas eles estão em vermelho): ações para manter o obstáculo no lugar ou fortalecê-lo;
  • Post-it’s laranjas (no canvas eles estão em verde): ações que são necessárias para remover ou reduzir o obstáculo;
  • Post-it’s amarelos na parte inferior: uma definição de sucesso por obstáculo;

Começando

Jogue este jogo com até 12 pessoas. Divida em grupos paralelos se você tiver mais;

Configure a sala com uma grande mesa no meio, com o canvas nela. Crie ainda dois espaços para as duas equipes;

Parte 1 – 30 minutos

  • Identificar coletivamente um desafio abrangente . Alguns exemplos podem ser: “Expandir a coluna “concluído” para incluir a versão testada em produção”, “O Time de Desenvolvimento se manter estável por pelo menos 3 meses” ou “Definir e alcançar os Objetivos da Sprint para as próximos 3 Sprints”. Escreva o desafio no post-it azul no topo;
  • Identificar coletivamente os três maiores obstáculos que precisam ser abordados e escrevê-los nos post-it´s amarelo, diretamente abaixo do post-it azul. Você pode fazer um brainstorming ou usar 1-2-4-ALL  para identificá-los;
  • Peça ao time que determine o valor relativo dos obstáculos. A ideia é dividir 1.000 reais nos três obstáculos: “Quanto é economizado ou obtido pela remoção desses obstáculos?”. Escreva os valores nos três post-it’s amarelos na parte inferior do canvas. Não estamos tentando voar para a lua com esses valores, então não se preocupe em ser preciso;

Parte 2 – 30 minutos

  • Crie duas equipes com tamanhos iguais (4 a 8, sendo 6 o número ideal): Os terroristas identificarão ações ações concretas que a equipe (já) executa e que mantêm os obstáculos no lugar ou os fortalece. Os contra-terroristas identificarão ações concretas que são necessárias para remover ou reduzir o obstáculo;
  • Ambas as equipes tem 15 minutos para identificar as ações dentro de cada obstáculo.  Escreva-os em post-it´s individuais e guarde-os com o seu time, agrupado por obstáculo. Você pode usar 1-2-4-ALL para ser democrático dentro dos grupos e evitar que membros dominantes ou mais extrovertidos influenciem demais os resultados;

Parte 3 – 30 minutos

  • Peça às equipes para mudar fisicamente de lado, o que significa que os Terroristas agora conseguem ver o que os contra-terroristas elaboraram e vice-versa;
  • As equipes tem 10 minutos para  votar nas três principais ações por obstáculo. Os terroristas votam nas três melhores ações sugeridas pelos contra-terroristas, e vice-versa. Peça às equipes que considerem a viabilidade, o impacto e a forma como os itens serão executados.
  • Ambos os times  escolhem as 3 principais ações  por obstáculo e movem para o canvas. O canvas resultante agora deve ter dezoito ações; Nove ações que mantêm obstáculos no lugar, e nove que podem ajudar a removê-los;

Parte 4 – 30 minutos

  • Peça ao grupo que  divida o valor por obstáculo nas seis ações identificadas (laranja e rosa). Então, se os obstáculos na coluna 1 tiverem um valor de 400, a equipe pode dividir 400 reais nas seis ações acima;
  • Determine uma definição de sucesso por obstáculo. Como você pode medir o progresso? Quando você pretende resolver este obstáculo? Faça isso da forma mais tangível possível. Escreva no post-it amarelo na parte inferior do canvas.
  • Agora você tem uma tela com dezoito atividades acionáveis para começar ou parar de fazer, endereçar com soluções os obstáculos e resolver o desafio abrangente. Decida quais itens o time irá pegar primeiro (por exemplo, durante o próximo Sprint). Você pode revisitar e atualizar o Canvas durante a Sprint ou durante as próximas Retrospectivas Sprint – até que o desafio seja resolvido;

Dicas

  • Forneça dinheiro de mentira para a equipe, para tornar o jogo mais divertido;
  • Crie uma tabela  de classificação para promover a competição amigável entre membros ou equipes. Quem completar uma ação laranja ou impedir que uma ação rosa aconteça novamente (conforme decidido por toda a equipe) ganha os pontos atribuídos por essa ação;
  • Crie avatares  para os membros da equipe, ou as próprias equipas se você jogar com mais equipes;
  • Acompanhe os desafios superados pela (s) equipe (s)  criando uma linha de tempo . Você pode até tratá-los como “conquistas” que desbloqueiam as equipes;
  • Para um pouco de diversão,  decorar os cantos para os terroristas e contra-terroristas com os atributos apropriados;

De uma chance!

Nesta forma simplificada, o GameStorm é um formato muito divertido para a série de Retrospectivos Sprint. Isso cria uma concorrência amigável estabelecendo um quadro simples de melhoria. Isso ajuda as equipes a trabalhar desde grandes desafios a atividades pequenas e executáveis ​​que contribuem para resolver o desafio. Também ajuda a criar transparência no que a equipe está melhorando atualmente.

Quer saber mais sobre GameStorm? Junte-se ao seu próximo treinamento nos dias 21 e 22 de março ou em setembro para aprender a aplicar este jogo a mudanças organizacionais e obter técnicas.

Artigo original: https://www.linkedin.com/pulse/gamestorm-retrospective-barry-overeem/

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

Seu projeto não é uma ilha!

Todas as organizações querem crescer e gerar lucros, por isso é fundamental criar novos produtos e conquistar o mercado. À medida que expandimos, mais complexos nos tornamos. Pelo menos aquelas organizações que querem sair do lugar e prosperar em um mundo cada vez mais competitivo estão fazendo a gestão da complexidade e acreditem, nem toda complexidade é ruim!

A complexidade existe quando perdemos a nossa capacidade de simplificar. E estamos perdendo essa habilidade. Hoje a maioria das coisas consideradas simples há 40, 50 anos ficaram extremamente complexas. Os fatores que levaram a isso não são pontos a serem debatidos neste artigo, mas a globalização decorrente da tecnologia e o acesso a informação foram os grandes catalisadores dessa mudança.

A divisão organizacional proposta por Taylor em 19071 que legitima a profissão de gestão e diferencia a pessoas que pensam das que executam está se achatando. Apesar de ainda presente, na minha modesta opinião tende a desaparecer, a não ser que você contrate pessoas restritas a execução que não tenham tido contato com um smartphone, por exemplo!

Ainda dentro das instituições, um elemento muito comum são as organizações temporárias formadas. Neste contexto estou me referindo as pessoas que por um tempo determinando se agrupam para entregar um objetivo comum que atenderá a estratégia organizacional. As equipes de projetos podem ser encontradas em praticamente todos os segmentos de mercado2 e essas pequenas organizações dentro de uma organização maior, conseguem lidar melhor com a complexidade. Estão mais aptas a responder com mais rapidez as constantes mudanças e podem se adaptar com precisão a qualquer situação.

Para unirmos o pensamento sistêmico ao gerenciamento de projetos, podemos usar quatro temas centrais para fazermos nossa análise: tempo, equipe, tarefa e contexto3, além é claro dos drives específicos de cada projeto.

Em relação ao tempo, cada projeto é único, com início e fim bem determinados. Este tempo não é só do projeto, mas serve também para a equipe ganhar maturidade, para mensuramos o quanto se perde por não ter aquele projeto pronto e o que é possível alterar à medida que o tempo avança. A gestão do tempo de um projeto é diferente da gestão do tempo da organização.

Em relação ao contexto, o comparativo é feito entre a organização temporária e a organização permanente. Esta relação não deve ser negligenciada. As estruturas e os procedimentos empregados em um projeto devem ser entendidos em relação aos cursos anteriores e simultâneos de atividades, aos planos futuros e aos procedimentos operacionais padrão, tradições e normas do entorno4.

Esqueça o resto da organização, temos que tomar conta de nós mesmos.

Os gerentes de projetos que não possuem um olhar sistêmico, tendem a tratar o projeto e a sua equipe de forma isolada em relação a organização. Alguns dos problemas gerados em um projeto estão fora dos limites dele mesmo. Eles são problemas derivados da estratégia ou dos recursos que são comuns a organização.

Sempre que uma organização quer fazer algo, tudo sempre se concentra em uma única pessoa, que pode atrasar todo o projeto. Um engenheiro empaca à espera de decisão de um gerente; uma gerente pensa que não tem autoridade para fazer uma compra importantíssima. Essas pequenas hesitações, aparentemente insignificantes, podem causar terríveis atrasos5. Essas questões podem ser minimizadas com a ampliação da cena. Precisamos consentir que estas decisões não tomadas estejam além do gerente e concentradas em pessoas de outros departamentos.

Como podemos aplicar o pensamento sistêmico

Muitas pesquisas sobre a organização do gerenciamento de projetos separaram a estratégia / tomada de decisão da execução6. A divisão entre os decisores e gerentes de projetos cria dois sistemas gerenciais diferentes; um formal, usado para cumprir especificações externas (geralmente contratuais) e uma informal com base na intuição dos gerentes de projeto e na dinâmica de grupo nos projetos7.

O que realmente melhora um sistema não é o foco nas partes. O mais importante é a interação entre as partes. Precisamos ajustar como os membros do time do projeto se relacionam com as demais áreas. Quais os pontos de convergência? O que está limitando as ações do projeto? Qual o fluxo de comunicação? Até onde eu posso flexbilizar?

Para usar o pensamento sistêmico no gerenciamento de projetos, comece hoje mesmo a olhar o seu entorno. Uma das sete deficiências da aprendizagem é “o inimigo está lá fora”. Peter Senge coloca que precisamos olhar para dentro, olhar para o projeto e como estamos nos relacionando com o restante da organização. Primeiro eu modifico o que está ao alcance do gerente, da equipe e observo os feedbacks decorrentes destas mudanças. Quando as consequências acabam retornando e nos prejudicando, interpretamos incorretamente esses novos problemas como se fossem provocados por causas externas8.

A maior parte das organizações está passando por uma transformação, e esse estágio será cíclico. Uma vez que você termine, precisará rapidamente recomeçar!

Referências lidas:

1 – Taylor, F. W. Princípios de Administração Científica, Atlas; Edição: 8ª.
2 – Hanisch, B. and A. Wald (2014). “Effects of complexity on the success of temporary organizations: Relationship quality and transparency as substitutes for formal coordination mechanisms.” Scandinavian Journal of Management 30(2): 197-213.
3 – Bakker, R. M. (2010). “Taking Stock of Temporary Organizational Forms: A Systematic Review and Research Agenda.” International Journal of Management Reviews 12(4): 466-486.
4 – Engwall, M. (2003). “No project is an island: linking projects to history and context.” Research Policy 32(5): 789-808.
5 – Horowitz, B. (2015). O Lado Difícil das Situações Difíceis, WMF Martins Fontes; Edição: 1ª.
6 – Artto, K., et al. (2008). “What is project strategy?” International Journal of Project Management 26(1): 4-12.
7 – Jaafari, A. (2001). “Management of risks, uncertainties and opportunities on projects- time for a fundamental shift.” International Journal of Project Management.
8 – Senge, P. M. A Quinta Disciplina, Best Seller.

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

Flight Levels: níveis de melhoria organizacional

Assim que você assimilar algo que está escrito abaixo, considere, mas continue a desenvolver. Esta foi exatamente a forma que os Flight Levels foram construídos. Eles estavam sendo lançados no meu livro “Kanban in der Praxis”, e apesar de já terem sido discutidas muitas e muitas vezes, ao consultar clientes, nos treinamentos e nas apresentações, meu ponto de vista mudou – graça ao feedback dos leitores e da audiência dos participantes dos treinamentos.

O modelo Flight Model apresenta uma questão principal: quais níveis de organização oferecem qual alavanca para melhoria? Nesta linha, eu reorganizei o Flight Level porque a entrada ocorre ou não de forma controlada ou desordenada (até agora, esta é a característica que distingue o nível 1 do nível 2) e é uma questão de detalhes que confunde os fundamentos do modelo. Na maioria das empresas, existem mecanismos para decidir o que deve ser feito em seguida. Se esses mecanismos são eficientes ou não, este é um tema da melhoria, mas isto não importa muito para o modelo Flight Level. Como resultado a partir das mudanças, surgiu uma nova estruturação para o Flight Levels que vou descrever abaixo:

Flight Level 1 – Nível operacional

Flight Level 2 – Coordenação

Flight Level 3 – Gestão estratégica de portfólio

Embora o Flight Level aconteça através do Kanban, ele ainda é uma modelo de propósito geral para o desenvolvimento organizacional. Quando eu trabalho com os meus clientes, por exemplo, frequentemente o foco é implementar medidas nos níveis 2 e 3 para melhorar a coordenação e a direção estratégica, enquanto que o nível da equipe ou o nível operacional funcionam com Scrum. Como tal, não é importante qual o método é usado no nível individual. O importante é como a comunicação e a coordenação entre os níveis serão organizados. Se você pode fazer melhorias na comunicação e na coordenação, toda a criação de valor começará a ser otimizada – e isso é, em última análise, nosso objetivo.

Eu não escolhi aleatoriamente o nome “Flight Levels”. O nível de voo relaciona-se com a altitude e a analogia também deve ser feita no contexto organizacional: quanto mais alto você voa, sua visão geral aumenta, entretanto com menor nível de detalhes. Quanto mais baixo você voa, você pode ver mais detalhes, mas não verá a paisagem inteira.

O modelo Flight Level é um instrumento de comunicação que revela o efeito de etapas específicas de melhoria em diferentes níveis, e também ajuda a encontrar o ponto de partida mais eficaz dentro da organização para começar com estas melhorias.

Flight Level 1: nível operacional

O primeiro nível de voo pertence a equipe, que faz o trabalho diário. Muitas vezes os envolvidos são especialistas que encontram-se diariamente para fazer o trabalho, mais comum em ambientes de alta tecnologia. Este especialistas trabalham em uma parte de um sistema maior, tais como o sistema de injeção de combustível para automóveis, ou no processamento gráfico de um radar meteorológico para aviões. Outra característica dos nível 1 são as equipes multifuncionais, compostas por designer, desenvolvedor e testador, que trabalham juntas em um produto ou em um subsistema. Geralmente uma demanda grande é dividida em pedaços menores e é implementada passo-a-passo. Deste ponto de vista, o sistema de trabalho ajuda o time a visualizar, limitar e melhorar continuamente seu processo de trabalho. Quando uma empresa é composta de muitas equipes, e não apenas uma, os limites para a otimização ocorrem na interface de uma unidade para outra, e como já vimos no experimento de fluxo, isso pode acarretar a sub-otimização de todo o sistema. As melhorias são limitadas apenas dentro da equipe e pode causar dificuldades as demais equipes que compõem a organização.

A maior desvantagem é que os desejos dos clientes não são plenamente compridos, apesas de todo o empenho da equipe. Para explicar isso, vou usar o teclado como exemplo.

tastatur-1024x583

Vamos imaginar que o cliente deseje escrever uma carta. Vamos imaginar ainda que cada equipe da organização seja responsável por uma linha do teclado. Cada equipe é excelente em  desempenhar seu papel, mas sempre há margem para melhoria. Por exemplo, o time 3 pode otimizar-se até bater o novo recorde mundial para apertar a tecla “a” mais rápido. Seria fantástico! No entanto, a carta do cliente não será escrita mais rápido por causa disto. Quando estamos escrevendo a carta, não se trata apenas de poder apertar com rapidez apenas uma letra do alfabeto. É mais importante que a letra correta seja digitada no momento certo, a fim de alcançar um aumento real no desempenho. É por isso que o foco na melhoria deve envolver toda a organização. A organização deve ser aquela que se ajusta ao cliente em um processo evolutivo: o que deve ser feito para gerar o maior valor para o cliente? Se houver mais de uma equipe no nível operacional, é importante coordenar o trabalho. Não importa seu ramo ou a sua área: no caminho do “conceito ao dinheiro” existe como regra, dependências entre os times. Cada time, ou cada unidade completa apenas uma parte da criação do valor a ser entregue ao cliente, Para que a coordenação seja útil, precisamos primeiro identificar o caminho que o valor percorre até a entrega. Se uma organização é ágil ou não, isto não tem nada a ver com a quantidade de equipes ágeis atuando dentro da organização. A interação entre as equipes é que deve ser ágil.

Flight Level 2: coordenação

Observe como isso é típico no mundo dos negócios. A seguinte imagem mostra uma situação que vejo vez ou outra em empresas maiores (40 a 40.000 funcionários). Várias equipes são necessárias para gerar valor para o cliente.

mehrTeams-1024x457 (1)

Na maioria dos casos, o cliente não obtém valor quando o código testado é entregue. O valor é alcançado quando o código é integrado a um sistema maior dentro da empresa. Por outro lado, os clientes raramente especificam seus desejos claramente a ponto de poderem ser imediatamente implementados. Na verdade, é bem o contrário. Como regra, há muito a ser feito antes do trabalho de desenvolvimento real possa ser iniciado. É necessário o engajamento dos líderes, a formação das equipes, entender o que o cliente precisa, contratos devem ser assinados, etc. Assim que examinar as demais áreas do trabalho a ser desenvolvido, você vai perceber que o fluxo de valor é completamente diferente, tais como na manutenção do produto ou no gerenciamento de produtos. No entanto, a idéia por trás destes processos é a mesma: criar valor para o cliente é mais importante do que uma super produtiva.

No nível 2 de operação, a interação das equipes é otimizada. Na metáfora do teclado, no nível 2, asseguramos que a equipe certa esteja empurrando a alavanca certa no tempo certo, ou seja, executando o trabalho certo no tempo certo. Um sistema nível 2 coordena o trabalho de várias equipes, que juntas estão envolvidas no cumprimento dos desejos dos clientes e produzem serviços específicos na cadeia de criação de valor. O objetivo é otimizar o fluxo de trabalho além da borda da equipe. Os sistema de trabalho nível 2 conseguem melhorias de desempenhos massivas por dois motivos:

1 – Os funcionários trabalham nas coisas certas no momento certo porque o fluxo de trabalho é coordenado e vai além dos limites das equipes.

2 – O número de itens de trabalho é limitado, de modo que o sistema de trabalho como um todo pode ser otimizado.

Um vez que o fluxo de trabalho é otimizado ao longo de toda cadeia de valor, o tempo de espera entre uma equipe e outra é reduzido e o que é mais importante: os gargalos se tornam visíveis. Qualquer um que tenha conhecido organizações neste nível só pode achar engraçado quando os times de alta performance descobrem que o segredo para o sucesso é a integração entre eles. Quanto maior a empresa, maior a cadeia de valor. Assim, os quadro de coordenação podem ser estruturados de maneira hierárquica.

Se olharmos para o nível 2 com a perspectiva de gestão de mudanças, as iniciativas neste nível são mais fáceis do que no nível 1, mesmo que você coordena muitas pessoas. A decisão de implementar uma mudança para toda a equipe requer um nível de gerenciamento mais alto. Isso significa que o gerenciamento deve dar um bom exemplo e ser a mudança que eles querem ver. Ao mesmo tempo, não há necessidade imediata de mudar a forma como as equipes individuais trabalham no nível operacional. Se uma equipe usa kanban ou scrum, ou simplesmente faz o trabalho, isto é completamente irrelevante. A única mudança, se você quiser chamar assim, são os líderes das equipes começarem a fazer reuniões de rotina.

Isso é Waterfall?

Quando você olha para isso, você pode achar que a aplicação do nível 2 é do tipo waterfall. O que significa waterfall? Só porque as coisas são trabalhadas de forma sequencial, não significa necessariamente que você está método waterfall (à propósito, Winston Royce descreveu o modelo waterfall como um processo iterativo). No entanto, é um bom modelo – programar o software antes de entregá-lo.

Trabalhar de acordo com os princípios do método waterfall significa que os itens de trabalho são muito grandes, cada item é quase um projeto inteiro. Não é conveniente primeiro analisar um projeto inteiro, desenvolvê-lo e depois implementar.  Este não é o propósito aqui. Em vez disso, os itens de trabalho devem ser pequenos para que você possa o quanto antes definir a abordagem que irá utilizar. Isso requer obter feedback mais rápido e ser capaz de aprender com ele.

Flight Level 3: Gerenciamento Estratégico de Portfólio

Normalmente as organizações não trabalham em apenas um projeto ou produto. O portfólio da empresa é composto com uma variedade de projetos e produtos, bem como iniciativas estratégicas que preparam a organização para o futuro. O nível 3 gerencia exatamente esta mistura. Você precisa obter uma visão geral do que acontece na empresa. Você também quer saber a forma que os os projetos e iniciativas estratégicas estão fazendo efeito, e até que ponto a implementação evoluiu. Um novo projeto pode ser iniciado ou você deve esperar até que um outro projeto seja concluído? Que investimentos devem ser feitos? Um novo mercado deve ser conquistado ou uma parcela de mercado existente deve ser aumentada? Quais iniciativas de mudança estão atualmente em execução na empresa?

Esta última pergunta – o que está sendo executado atualmente em relação aos objetivos da empresa – é especialmente adequada para ser visualizada em um quadro de estratégia. Desta forma, a alta administração pode identificar se as ações estão alinhadas com o propósito da organização e se alguma iniciativa está impedindo outra de se desenvolver. Tais contradições ocorrem principalmente quando as empresas querem se tornar ágeis e há diversos consultores trabalhando internamente com diversas opiniões. Em um dia a auto organização é feita e no dia seguinte um relatório feito de maneira tradicional é solicitado. Neste nível, trata-se do gerenciamento estratégico de toda a organização e não do micro gerenciamento. Grandes empresas com escritórios em todo o mundo tem várias estratégicas devido às exigência de mercados locais.

Ter mais demanda do que capacidade de execução e fundamentalmente um bom problema, caso contrário sua empresa deveria reduzir a força de trabalho. Como resultado disto, vamos ter concorrência no nível de portfólio. Essa disparidade entre as opções aptas a implementação deve ser muito clara, caso contrário, poderá passar uma impressão de que os recursos são limitados. E este não é o caso aqui, na verdade este é o ponto chave do sistema nível 3: fazer escolhas prudentes, combinar projetos, desenvolver produtos e iniciativas estratégicas, reconhecer dependências e otimizar o fluxo através da cadeia de valor e dos recursos atualmente disponíveis.

No nível 3, os tipos de trabalhos a serem tratados são grandes itens, tais como: “entrada no mercado da Hungria”, ou “menos automóvel e mais aviação”. Neste nível, essas vastas funcionalidades competem entre si, de modo que a organização é forçada a tomar uma sólida decisão sobre o que deve ser feito em seguida. O foco não são os objetivos dos projetos individuais, e sim o resultado geral para a organização. A demanda e as possibilidades existentes devem ser equilibradas.

Resumo

O diagrama a seguir consolida os níveis em uma imagem completa:

O nível 3 de voo é o coração estratégico da organização. A gestão estratégica e as iniciativas da empresa convergem aqui. O nível 3 está conectado com os diversos sistemas nos níveis 1 e 2, onde o trabalho operacional é gerenciado. O exemplo “entrada no mercado da Hungria” só pode conter dois tickets, “preparar o grupo de produtos X” e “preparar o grupo de produtos Y”, mas no nível 2, estes itens serão divididos em itens menores e serão então entregues às equipes do nível 1.

Também acontece com frequência o trabalho fluir do nível 3 diretamente para o nível 1. Vamos assumir que nossa empresa é uma fornecedora de peças automotivas e a estratégia presente no nível 3 seja: “mais negócios de aviação”. Já existe na organização um produto sendo desenvolvido para o mercado automobilístico que com uma leve modificação, este produto poderia interessar também para a indústria de aviação. Uma equipe de especialistas de encarrega de testar a teoria. Desta forma o item de trabalho do nível 3 flui diretamente para uma equipe especializada no nível 1.

Os Níveis de Voo não são um modelo de maturidade ou avaliação. O problema de uma equipe não será resolvido com um quadro de estratégia, bem como uma estratégia não pode ser implementada através da iniciativa de uma equipe dispersa. No entanto, vejo processos de pensamento semelhantes com iniciativas ágeis. Existe um problema estratégico sobre a incerteza futura do mercado. Embora não saibamos que o futuro nos trará, as equipes estão se tornando ágeis como precaução. A agilidade é um tópico estratégico e não pode ser resolvido no nível operacional, especialmente onde as áreas não achem necessário. Se você quer fazer melhorias em uma organização, primeiro você deve deixar claro qual o nível necessário para que a mudança possa ocorrer. Os níveis de voo devem ajudar a identificar o nível necessário. Geralmente, podemos dizer que quanto mais alvo o nível de voo, maior é o efeito da alavanca. Se houve possibilidade de iniciar o processo no nível 3, você deve começar. A única equipe ágil que é necessária para a organização se tornar ágil é a equipe ágil que está no topo, é a que realiza o gerenciamento estratégico do portfólio, e é está equipe que deve dar o exemplo.

Traduzido do original: https://www.leanability.com/en/blog-en/2017/04/flight-levels-the-organizational-improvement-levels/
Tradução: Rodrigo Zambon

Apresentação feita em novembro de 2013, ainda com 4 níveis de voo!

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.