Taglean

A arma de Tchekhov

Anton Tchekhov (1860-1904) foi um dramaturgo e escritor russo que dizia que qualquer objeto apresentado ao público em uma obra de entretenimento deve ser utilizado em algum momento da trama ou descartado para não causar distrações:

Remove everything that has no relevance to the story. If you say in the first chapter that there is a rifle hanging on the wall, in the second or third chapter it absolutely must go off. If it’s not going to be fired, it shouldn’t be hanging there.

Em minha trilogia de filmes favorita, aliás, há um excelente exemplo de arma de Tchekhov: Na segunda parte de “De volta para o futuro”, o hoverboard fica dentro do Delorean depois de ser usado por Marty McFly para derrotar Griff Tannen. No terceiro filme, o mesmo hoverboard acaba sendo essencial não apenas para que Marty resgate Doc Brown e sua namorada Clara de um trem em alta velocidade, mas também para a construção do trem voador, baseado em sua tecnologia.

Aliás, como assisto a muitas séries e filmes e também leio bastante, tive oportunidade de encontrar muitos outros exemplos da arma de Tchekhov em ação: nem sempre é um objeto — pode também ser uma pessoa, um local, uma magia. Mas o fato é que toda vez que percebo algum elemento que pode vir a ser uma arma, já fico desconfiado e, se constato que era isso mesmo, fico bastante satisfeito.

Só que também gosto de pensar que a arma de Tchekhov se encaixa nos contextos da filosofia lean, do storytelling e da analogia do copo com água pela metade, já que para evitar distrações e desperdícios, a criação de histórias enxutas exige pensar muito bem no porquê de apresentar um elemento e em suas causas e efeitos, tanto quanto ao invés de ver o copo meio cheio ou meio vazio deve-se na realidade questionar se o copo tem o tamanho correto.

O segredo de um A3

O segredo de um A3 é que a história nele descrita deve ser curta — e não um romance completo como “Guerra e Paz”, do grande romancista russo Leon Tolstoi.

Escrever uma história curta leva tempo: mas são exatamente as iterações que ajudam a refinar um A3 até sua essência, tornando-o fácil de comunicar.

Há uma famosa citação de Blaise Pascal, aliás, que resume o conceito por detrás de um A3:

“Eu teria escrito uma carta mais curta, mas não tive tempo”

Invista o tempo necessário para refinar a história: use diagramas simples, tópicos e imagens — uma imagem vale mais do que mil palavras.

Finalmente, não caia na armadilha de tentar espremer tanta informação quanto possível em um A3 usando fonte de tamanho 6: torne-o fácil de ler. Menos é mais! Leva-se tempo para coletar nossos pensamentos e contar uma história: a filosofia Lean trata de reduzir desperdícios e o A3 é uma peça chave para ajudar a eliminar desperdício nos processos de gestão.


*Traduzido e adaptado por mim a partir do livro “Toyota by Toyota”, de Darril Wilburn e Samuel Obara, capítulo 12 — “Hoshin Kanri”, página 203.

Torne o trabalho de TI visível com Kanban

Este artigo foi publicado originalmente no meu perfil do Linkedin.

Você sabia que o trabalho em um departamento de TI é essencialmente invisível?

Ao contrário do que pode ser encontrado no chão de fábrica — pilhas de produtos não concluídos espalhados pela linha de produção —, as informações e os conhecimentos aplicados na execução das atividades de Tecnologia da Informação para a entrega de projetos estão registrados em documentos sistemas.

É aí que entra o Kanban, técnica trazida para o mundo dos projetos de TI por David Anderson, que em 2003 publicou o livro “Agile Management for Software Engineering — Applying the Theory of Constraints for Software Projects”, onde adaptou os conceitos de sistema puxado ao desenvolvimento de software.

O emprego do Kanban expõe o fluxo de trabalho (ou a falta dele), e ser capaz de enxergar o fluxo é essencial para gerenciar um projeto de software! Afinal, sem um entendimento claro do que uma equipe precisa fazer, a gestão eficiente do seu fluxo de atividades é praticamente impossível.

O desenvolvimento de software com emprego do Kanban envolve a utilização de quatro práticas:

  1. Visualizar o fluxo de trabalho, usando um quadro Kanban para que o time de projeto possa conversar sobre o que efetivamente importa no momento correto, e com isso criar oportunidades de melhoria.
  2. Limitar as atividades em andamento, o trabalho em andamento (WIP), ou seja, aquilo que o time de projeto ainda não concluiu, através de uma técnica que permite avaliar o máximo de trabalho exequível pelo time, por vez.
  3. Gerenciar as atividades efetivamente em andamento, visando evitar o “envelhecimento” dos itens de trabalho e sua conclusão dentro das expectativas de prazo definidas.
  4. Personalizar adaptar uma definição de “*fluxo de trabalho*” que seja compreendida pelos membros da equipe do projeto de software. Com um entendimento mutuo, documentar políticas e indicadores que possam ser usados para melhorar o desempenho do time a cada projeto desenvolvido.

Não é algo fácil de aplicar: o Kanban requer engajamento, disciplina e, sobretudo, patrocínio da direção, mas é uma receita vencedora nos projetos de TI, e certamente pode fazer com que seu departamento contribua mais ativamente para os resultados da empresa.

A história do “deixa que eu deixo”

Esta semana estava me lembrando de uma historinha que ouvi há muito tempo, quando comecei a trabalhar com gestão de processos, e que passei a contar às pessoas, em geral para ilustrar uma das situações mais corriqueiras que existem, o famoso “deixa que eu deixo”.

Trata-se do seguinte:

Havia quatro funcionários que trabalhavam em uma empresa. Seus nomes eram Todo Mundo, Alguém, **Qualquer Um **e Ninguém.

Nesta empresa existia uma tarefa muito importante, que precisava ser executada o mais rapidamente possível. Todo Mundo tinha certeza absoluta de que Algúem executaria a tarefa. Qualquer Um poderia ter executado, mas Ninguém executou. E acontece que Alguém ficou muito aborrecido: Afinal de contas, era obrigação de Todo Mundo.

Todo Mundo pensou que Alguém ia executar a tarefa, mas Ninguém percebeu que Todo Mundo deixaria de executá-la. No final das contas, Todo Mundo acabou culpando Alguém quando Ninguém executou a tarefa que Qualquer Um poderia ter executado.

É triste, mas muito mais comum do que se imagina. E você, tanto quanto tanta gente que você conhece, pode já ter sido vítima desses quatro.

O cavalo de Schilda

Existe uma velha história do folclore alemão que foi recontada por Sigmund Freud ao final de sua palestra “Cinco Lições de Psicanálise“, na Clark University, em Worcester, Massachusetts, no mês de setembro de 1909, que é assim:

A literatura alemã conhece um vilarejo chamado Schilda, de cujos habitantes se contam todas as ‘espertezas‘ possíveis. Dizem que possuíam eles um cavalo com cuja força e trabalho estavam satisfeitíssimos. Uma só coisa lamentavam: consumia aveia demais e esta era cara. Resolveram tirá-lo pouco a pouco desse mau costume, diminuindo a ração de alguns grãos diariamente, até acostumá-lo à abstinência completa. Durante certo tempo tudo correu magnificamente; o cavalo já estava comendo apenas um grãozinho e no dia seguinte devia finalmente trabalhar sem alimento algum. No outro dia amanheceu morto o pérfido animal; e os cidadãos de Schilda não sabiam explicar por quê.

Nós nos inclinaremos a crer que o cavalo morreu de fome e que sem certa ração de aveia não podemos esperar em geral trabalho de animal algum.”

Apesar da história original se referir a psicanálise, gosto de adaptar esta situação que viveram os habitantes de Schilda aos conceitos da melhoria contínua e do kaizen.

Como sabemos, a filosofia e as práticas de kaizen consideram que sempre é possível tornar qualquer atividade melhor, não importando a qual processo de negócios ela pertença. Assim, é extremamente natural — e, sem dúvida, correto — acreditar que nenhum dia deva se passar sem que alguma melhoria tenha sido implantada, por menor que seja.

Agora pensem na força e no trabalho do cavalo que existia em Schilda, e em como seus habitantes estavam satisfeitos com estas características: era a combinação de ambas que os deixava em uma situação muito boa, e, sendo assim, porquê não aplicar melhoria contínua e tornar algo bom ainda melhor, não é mesmo?

Para melhorarem a situação que já possuíam, os habitantes de Schilda pensaram em otimizar um dos elementos do processo, composto, como já disse antes, da força e do trabalho realizados pelo cavalo — mas também composto pela quantidade de ração consumida pelo animal.

Mas vejam, o pobre cavalo acabou morrendo de fome depois de lhe retirarem, grão após grão, toda a ração que comia, mesmo que a ração tenha sido otimizada. Se perguntem agora, então, se o problema a ser resolvido realmente tinha qualquer coisa a ver com otimizar a ração.

Deve-se tomar cuidado com as otimizações a serem feitas.

A otimização da ração, neste caso, não tinha a ver com reduzir as porções oferecidas ao cavalo até que ele morresse. Ao invés disso, os habitantes de Schilda deveriam se perguntar: “o que poderíamos fazer para reduzir o custo da ração que damos ao cavalo e, ainda assim, mantê-lo tão forte, trabalhador, produtivo e alimentado quanto antes?“.

Com um pouco de esforço e de brainstorming, discutindo o problema de fato, eles certamente conseguiriam pensar em uma combinação de ingredientes diferentes para compor a ração oferecida ao cavalo, e, quem sabe, conseguir torná-lo ainda mais produtivo, mesmo que com um custo de ração menor, aí sim verdadeiramente exercendo aquilo que pregam os conceitos de kaizen e de melhoria contínua.

A lição aqui é sempre pensar direito no que será otimizado: Assim como sem certa quantidade de ração não se pode esperar trabalho de animal algum, não se pode esperar que um processo funcione adequadamente sem certa quantidade dos recursos e etapas que naturalmente lhe pertencem.

© 2020 Daniel Santos

Theme by Anders NorénUp ↑