Comunicando Impedimentos através do Andon

Sabe aqueles momentos em que estamos profundamente mergulhados na resolução de um problema técnico dentro de um projeto? Muitos desses momentos são importantes em função de comumente nos oferecer grandes desafios intelectuais e que uma vez resolvidos, nos trazem grandes momentos de satisfação ao nosso sistema mental de recompensas.

Sendo que muitas vezes, principalmente quando se está num projeto solo, realmente não há outro jeito, temos que ter essa heróica atitude para sermos “matadores de problemas” no projeto, leve o tempo que for necessário (minutos, horas ou dias) e a qualquer custo, afinal senão as coisas realmente não caminham.

Porém, caso o cenário seja pertinente a uma equipe de trabalho, imagine qual o custo para o projeto quando ocorrem essas situações? E outro questionamento interessante, é que quando há uma resolução heróica e individual desses problemas, qual o prejuízo ao compartilhamento de conhecimento a essa organização?

Agora imagine como essas questões funcionam numa linha de produção dentro de uma fábrica (de qualquer coisa, carros, móveis, alimentos, etc.)? Pois como essas fábricas normalmente trabalham com medidas de tempo em minutos (até mesmo segundos), tente mensurar o impacto negativo ao custo, ao prazo ou a qualidade caso ocorra um problema nalgum ponto da linha de produção e que o mesmo seja escondido (leia não comunicado).

Claro que em desenvolvimento de software a visão muda bastante, mas com base nesses questionamentos, é que ofereço esse breve texto, que têm como objetivo elucidar como podemos usar com mais efetividade o gerenciamento ágil e enxuto para a remoção de impedimentos dentro de nossos projetos de desenvolvimento de software.

Nesse contexto, assumimos que a chave para que as soluções sejam efetivas dentro de uma equipe, é ter uma forma de comunicação simples e assertiva, para facilitar o processo de descoberta de problemas, bem como ter meios para alavancar a solução apropriada do respectivo problema que fora descoberto.

É importante compreender que uma base conceitual que influenciou a forma atual de gerir impedimentos nas metodologias ágeis, é ferramenta Andon, proposta e utilizada pelo TPS (Toyota Production System), que consiste em algum meio físico baseado num sistema de cordas ou luzes, para que seja possível um aviso visual de alto impacto quando há algum problema qualquer ponto do processo de produção.

O dispositivo físico em si é relativamente simples, porém, por trás dessa ferramenta, existem importantes atitudes que realmente agregam valor ao processo quando apoiados pelo Andon, por exemplo:

• Dentro do TPS, há uma forte cultura de buffers (pulmões) para amortecer possíveis desvios oriundos da resolução de problemas na linha de produção.
• Inspeções na fonte e Inspeção 100% – As verificações de qualidade não são feitas por amostragem de lotes e sim são verificadas unitariamente em casa etapa do processo, ou seja, é muito pequena a margem de algum problema não ser detectado antes do produto ser puxado pela operação seguinte.
• A cultura de parar e resolver – Quando há algum problema na linha de produção, por mais simples que o mesmo possa ser, muito provavelmente a qualidade será afetada negativamente, portanto a cultura TPS estimula que linha de produção não seja levada a frente, até que o problema seja resolvido.
• A cultura de prevenção das reincidências é outro motor que move o TPS, ou seja, soluções paliativas, não são bem-vindas, em função das mesmas impactarem negativamente a qualidade do produto que será entregue.
• Eliminar o desperdício – Nesse ponto o raciocínio é simples, pois quanto mais eficiente e eficaz, for a solução aplicada, menor é desperdício gerado pelo problema em questão.
• E claro, há uma estrutura muito eficaz de pessoas com capacidade analítica e criativa para resolver efetivamente o problema, no menor espaço de tempo possível.

Claro que existem outros detalhes que fascinam qualquer pessoa interessada por temas de engenharia da produção, porém, gostaria de focar mais no conceito principal e mostrar a aplicabilidade dele no contexto de desenvolvimento de software.

Apesar do mecanismo pelo qual podemos obter um Andon na área de desenvolvimento (por exemplo, usar um cartão com uma cor diferente para um impedimento), ser potencialmente mais simples que o Andon original do TPS, sua aplicação em equipes de desenvolvimento é muito mais complexa, pois como já mencionei no artigo “Vencendo o Estado de Negação na Sprint Retrospective” existem alguns mecanismos de nossa complexa mente humana, que nos impedem de transparecer nossos problemas e nossas limitações, isso ocorre devido a uma reação de defesa para que nossa imagem que é vista por outras pessoas, seja sempre a mais perfeita possível.

Mesmo sendo complexo romper com esse mecanismo de defesa, essa prática de remoção de impedimentos foi potencializada e tornou-se popular no desenvolvimento de software, através das idéias do Scrum, onde tornou-se fundamental para o trabalho do ScrumMaster, que os impedimentos sejam manifestados em algum meio (por exemplo quadro de KanBan) e algum momento (exemplo Reunião Diária), para que assim, sua remoção seja realizada da maneira mais eficiente e eficaz possível.

Observe que o nosso Andon é muito mais subjetivo (baseado em atitudes) do que físico, pois como um dos pilares da atividade de ScrumMaster é ser um “líder servidor” através da facilitação e coaching, faz parte de seu dia-a-dia ajudar o time a remover os impedimentos, portanto é fundamental que o mesmo estimule os membros nas reuniões e através das ferramentas cabíveis, que qualquer impedimento seja manifestado.

Termino esse texto, reforçando a idéia de que a essência de um Andon (manifesto de impedimento) dentro de um projeto de desenvolvimento de software, vai muito além de usar apenas uma ferramenta visual (cartão de Kanban de cores diferentes) para expor os impedimentos, pois é vital seja quebrada de alguma maneira a natureza humana de esconder as nossas imperfeições e assumir que não somos um “super-homem” imune a erros e capaz de resolver sozinho tudo e qualquer tipo de problema, mas sim, somos seres limitados (em alguma coisa) e muitas vezes precisamos de ajuda para resolver alguma questão, pois como já dizia o Velho Guerreiro (Chacrinha), “quem não se manifesta se trumbica.“

 

Sobre o autor:

Manoel Pimentel, CSP

É Engenheiro de Software, com 15 anos na área de TI, atualmente trabalha como Coach em Agile, Lean e TOC para empresas do segmento de serviço, financeiro e bancário. É Diretor Editorial da Revista Visão Ágil e Editor Chefe da InfoQ Brasil, Já escreveu sobre agile para importantes portais e revistas do Brasil e exterior e Também palestrou em eventos nacionais e internacionais sobre agilidade. Possui as certificações CSM e CSP da Scrum Alliance e foi um dos pioneiros na utilização e divulgação de métodos ágeis no Brasil.

Contatos: manoel@visaoagil.com