Ep. 105 - Chega de falar de ocupação

O que eu vejo bastante é a galera tentando usar estratégias de fluxo, com um olhar de trabalho linear, de manufatura, para aplicar no trabalho do conhecimento. E isso está gerando alguns problemas, porque a gente acaba usando para o trabalho do conhecimento estratégias que nasceram para o trabalho linear. Trazer essas diferenças é a parte essencial. E a outra polêmica é: para de falar de ocupação, gente. A gente precisa parar de falar de ocupação de pessoas, isso é muito insano. Se a gente puder trazer os argumentos para fazer as pessoas pararem de falar de ocupação no trabalho do conhecimento, essa é a principal intenção desta conversa. As primeiras coisas que se ouve sobre fluxo tentam transformar pessoas em máquinas, que têm espaço, velocidade e capacidade de execução de tarefas. E se isso nunca funcionou direito nem no chão de fábrica, onde o trabalho é mais estanque, funciona muito menos na área de software, porque quem produz conhecimento não trabalha de forma estanque: não dá para dizer que alguém vai fazer duas horas de programação, duas horas de bug e pronto, porque o problema pode ser mais complexo do que se imaginava e o trabalho fica pela metade, exigindo que a pessoa reconstrua o raciocínio no dia seguinte.

O episódio reúne o Panda com dois convidados que vieram do chão de fábrica: o Ugs (engenheiro que hoje toca a WA Solutions, especializada em DDMRP - Demand Driven MRP, o MRP tradicional de planejamento de materiais agora dirigido pela demanda do cliente) e a Cindy, que atua com desenvolvimento de software e discovery. A proposta é olhar o fluxo de trabalho por um ângulo diferente e entender por que ainda se fala tanto em ocupação, em marcar tarefas, em apontar horas, em "onde está seu avatar no Jira".

Antes da Toyota, a lógica de produção era de domínio de ponta a ponta, empurrando a produção: Ford queria controlar até a mineração do ferro para fundir o próprio bloco de motor, num mercado em que a demanda variava pouco. A Toyota revolucionou esse olhar ao trazer a ideia de que é a demanda que guia a produção - nasce daí o just-in-time. Ugs conta que, numa indústria química tradicional, o processo era literalmente: alguém olhava para o estoque, via um espaço vazio e mandava produzir para preencher aquele espaço, sem nenhuma conexão com o que o cliente realmente precisava. Quando ele chegou questionando "o que o cliente está comprando, o quanto ele precisa, para quando", a mudança pareceu loucura para quem estava de dentro da fábrica.

Todas as metodologias de produção são perfeitas quando seus pré-requisitos são respeitados: previsão de demanda com 100% de acurácia, insumos chegando sempre na data certa e máquinas que nunca quebram. Se essas três premissas se cumprem, ocupar espaços funciona, porque o tamanho do espaço está definido. O problema é que o mundo mudou: nos anos 60 se produzia o Fusca, hoje se produz o Tesla, com alta variabilidade e customização. Faltava entender o que o consumidor realmente está demandando, e não o que a equipe de vendas achava que ia vender - mas também não dá para esperar o cliente pedir, porque existe um tempo de produção. A saída foi desacoplar: tornar o tempo de atendimento ao cliente curto, mas protegido, isolando cada etapa da produção para que a variabilidade do pedido não precise mexer no fluxo produtivo inteiro. A informação de venda real passou a valer mais do que a previsão de venda, e ficou claro que as máquinas não precisam estar 100% ocupadas - produzir por produzir, algo que não vai ser vendido, não gera valor nenhum, é como jogar uma bomba na mesa: as consequências vêm depois.

Essa mesma lógica de ocupação aparece, hoje, na gestão do trabalho do conhecimento do século XXI. A correlação é direta: as pessoas viraram as "máquinas" que precisam estar sempre produzindo, mesmo quando o que produzem não tem uso nenhum. Tentar separar "duas horas de inovação" na agenda, como se fosse possível ligar a criatividade sob comando, é tratar gente como máquina - e ninguém sabe direito quando isso passou a ser considerado normal. Mas gerenciar o fluxo de trabalho não é o mesmo que deixar de olhar para as pessoas: são coisas diferentes, e a ideia de que tudo que não é olhar para o fluxo é "abraçar árvore" é uma falsa dicotomia. O convite do episódio é trocar "ocupação" por "folga" - não um slack de jornada reduzida, mas um sistema, um fluxo de trabalho controlado de forma a estar constantemente em folga, porque é essa folga que permite que as pessoas se desenvolvam, busquem soluções melhores e que a organização antecipe riscos. É exatamente o que os buffers do DDMRP fazem na cadeia de suprimentos: garantir folga para que o sistema não fique acoplado de ponta a ponta e quebre.

Cindy conta sua trajetória: no início, seu fluxo era empurrado - o cliente pedia o que achava que precisava, ela entregava, e só na metade do caminho ou na entrega descobria que não era bem aquilo. A mudança veio ao entender a diferença entre puxar e empurrar: "o balde tem que estar sempre cheio" é, na prática, empurrar o balde para dentro da equipe, não deixar que ela puxe. Essa reflexão dialoga com o que Donald Reinertsen discute (num artigo de 2012 na Harvard Business Review sobre mitos do desenvolvimento de produtos) a respeito da relação entre utilização de recursos e tempo de espera: quanto mais se aumenta a ocupação, mais cresce a fila. No trabalho do conhecimento essa gestão de filas é ainda mais difícil porque os itens de trabalho normalmente são novos, ao contrário de uma linha de produção que repete itens conhecidos, e a constante troca de contexto aumenta a complexidade.

Ugs lembra que a ideia de não tratar pessoas como máquinas não é nova - já aparecia no discurso de Charlie Chaplin - e conta como sempre rejeitou controle de ponto e de horas: contratou pensando em entrega de resultado, não em jornada, e até hoje não usa apontamento de horas na própria empresa, ainda que o parceiro colombiano cobre isso para precificar projetos. Para ele, o que importa é o valor entregue, não quantas horas um projeto consumiu. O Demand Driven bebe de metodologias conhecidas - Kanban, MRP, Lean, Teoria das Restrições - e todas, no fundo, falam da mesma coisa: reduzir e melhorar fluxo. E empresas existem para ganhar dinheiro, não apenas para produzir produtos - um aprendizado que ele credita a um professor, Carol, que perguntava a cada aluno o que a empresa dele fazia e corrigia: "vocês fazem dinheiro".

Ugs explica o papel do buffer com o exemplo de uma peça em formato de "L": se o processo de fundir metal, transformar em chapas, dobrar e pintar leva oito semanas, e o cliente só define a cor e o formato final no pedido, o lead time percebido pode cair de oito semanas para um dia se a empresa mantiver um estoque de "L's" já dobrados e só pintar sob demanda. O buffer absorve a variabilidade do pedido sem propagar o impacto para as etapas anteriores da cadeia. No trabalho do conhecimento existe uma vantagem que a indústria não tem: dá para puxar restrições para o começo do processo, por exemplo, antecipando testes (como no TDD) em vez de deixá-los só no fim do fluxo.

Cindy traz o mob programming: um item de trabalho é desenvolvido com o time inteiro presente, decidindo e revisando ao vivo, o que elimina as filas de espera por revisão de código ou teste. Ela também destaca o pair programming, o compartilhamento do trabalho de teste entre todo o time (em vez de depender de uma única pessoa) e a automação de testes e deploys como formas de reduzir o tempo de espera no fluxo. Panda questiona: existe tempo de produção não válido, trabalho que ninguém usa? A resposta de Ugs é direta: sim, isso é comum - inclusive Lula, outro host do podcast, já contou casos de software que desenvolveu e que ninguém usava.

Para Ugs, o mob programming é a redução de desperdício levada ao extremo: parar tudo para esperar uma decisão soa absurdo numa linha de produção, mas no trabalho do conhecimento serve para olhar com mais consciência para dependências e decisões, buscando automatizar ou antecipar o que for possível. O trabalho do conhecimento é altamente perecível: um item que ficou parado no fundo do "balde" pode já não fazer sentido quando finalmente é puxado, porque o entendimento e até a arquitetura pensada podem estar defasados. Por isso os "baldes" (buffers) precisam ser pequenos e variáveis, não fixos, já que a própria equipe varia (alguém doente, de férias, saindo mais cedo). Sem proteger o sistema dessa variabilidade - de demanda, interna, ou de um discovery mal feito - o resultado são gargalos, atrasos, hora extra e estresse; com o Demand Driven, por exemplo, a rotina de quem planeja produção deixou de ser trabalhar 24 horas por dia para caber num horário comercial.

Panda resume que grande parte do que foi dito descreve um mundo ideal - nem sempre é a realidade das empresas, onde existe muita dependência entre áreas e passagem de bastão. Por isso, olhar para o fluxo de trabalho não é sobre fazer mais coisas, e sim sobre fazer a coisa certa na hora certa: começa por dar visibilidade ao fluxo, depois considerar limites de WIP por etapa. Cindy conta que, na prática, o maior ganho recente tem vindo de gerenciar dependências entre times - reduzir o tempo que um time fica esperando outro para subir algo ou liberar uma decisão, o que às vezes exige conversas fora do próprio time. Como diz o livro do Klaus que ela cita, agilidade de negócio não é esporte de time, é esporte de organizações: não adianta um time otimizado se o impacto de ponta a ponta não muda. As filas no trabalho do conhecimento são especialmente impactantes porque, quanto mais um item espera, maior a chance de que a necessidade do cliente já tenha mudado quando ele finalmente for entregue - virando trabalho inútil.

Fechando o raciocínio sobre ocupação, Ugs lembra que todo mundo produz de acordo com o que é medido: métricas moldam comportamentos. Se a métrica de uma fábrica é ocupação de máquina, ela vai ocupar a máquina com o que rende mais nessa métrica, ainda que não seja o que o cliente precisa. Pessoas confortáveis, fazendo o que sabem e gostam, entregam resultado - não é preciso dizer "são oito horas nessa atividade". O convite final é usar uma fila única e bem gerenciada, em vez de várias filas fixas por etapa, e amortizar a variabilidade tanto na entrada quanto na saída do fluxo, protegendo o sistema como o Demand Driven protege a cadeia de suprimentos. Nas mensagens finais, Cindy pede que quem trabalha com agilidade cuide do próprio fluxo e não deixe a cultura da empresa cobrar 100% de produtividade: "hackeiem esse sistema e não deixem ser corrompidos por ele". Ugs reforça: lutem para que as pessoas não tratem outras pessoas como máquinas, porque ninguém é máquina.