WIP é um acrónimo que significa "Work in Progress" ou "Work in Process", e basicamente representa trabalho que se encontra a ser executado dentro de um determinado sistema. Este acrónimo é bastante conhecido junto da comunidade Lean, sendo muito utilizado em processos de produção fabril, como por exemplo na montagem de um automóvel, desde o momento em que entra na linha de montagem até ao momento em que sai. Apesar do sucesso que as práticas Lean têm tido nesse tipo de ambientes, junto de processos onde o trabalho é considerado mais invisível, como por exemplo, num departamento de IT, a sua utilização não tem sido adotada. Os argumentos variam, alguns afirmam que não se pode comparar trabalho altamente especializado e complexo como por exemplo desenvolvimento de software com a montagem de um automóvel. Contudo, quanto mais leio e investigo sobre o assunto mais similaridades encontro. Na linha de montagem de um automóvel, existem várias estações de trabalho, por exemplo, montagem de motor, montagem de componentes elétricos, pintura, etc. O automóvel, o qual vou passar a chamar unidade de trabalho, desloca-se desde o início do processo até ao seu final, saltando de estação de trabalho em estação de trabalho, até chegar finalmente ao final do processo e ser considerado pronto. Cada estação de trabalho tem um número máximo de unidades de trabalho que pode aceitar, e durante por exemplo 8h, passam pelo processo várias unidades de trabalho (automóveis). Isto significa que a data altura, se parássemos o sistema, teríamos x automóveis dentro do sistema, chegando assim ao nosso WIP. Todo o sistema é continuamente otimizado, e atividades que permitam melhorá-lo são rapidamente implementadas pelos seus trabalhadores. Em sistemas deste género, é também fácil perceber que não podemos aumentar o WIP sem antes realizarmos otimizações ao nosso processo. Por exemplo, se apenas temos uma câmara de pintura, então não podemos pintar dois automóveis ao mesmo tempo, estando o WIP nessa estação de trabalho limitado a 1 unidade.

Ora, se olharmos com atenção para um departamento de IT, mais concretamente uma equipa de desenvolvimento, encontramos muitas similaridades. De forma análoga ao que acontece com a linha de montagem, no desenvolvimento de determinada funcionalidade de software (para facilitar, chamada também unidade de trabalho), também se devem seguir determinados passos até que esta seja considerada concluída. Em organizações com hierarquias mais tradicionais, não existe o conceito de equipas multidisciplinares, logo uma unidade de trabalho tem que saltar de estação de trabalho em estação de trabalho, tal como acontece na linha de montagem. Estas estações de trabalho podem ser por exemplo, análise funcional, desenvolvimento da solução, testes de integração e de utilizador, deployment, acompanhamento ou service desk, entre outras que não coloco para não tornar o exemplo demasiado complexo. Em determinada altura, cada uma destas estações de trabalho tem um WIP específico, muitas vezes a tender para infinito, já que não existe qualquer bloqueio ao nível de trabalho em curso. Como o tipo de trabalho acaba por ser mais invisível, é possível cada estação de trabalho ter um número incrivelmente alto de temas em curso, e outro tanto em espera para ser iniciado. Ou seja, seria o equivalente a termos uma câmara de pintura e 10 automóveis em espera para serem pintados, não faz sentido.

Em IT, existirem inúmeras unidades em curso em cada uma das estações de trabalho leva a atrasos cada vez maiores. Está mais que provado que o multitasking não funciona, ter inúmeros temas em curso significa que nenhum deles será realizado com velocidade, e pior, fará com que unidades que venham de outras estações de trabalho fiquem muito tempo em espera até serem realmente realizadas. O segredo para que isto não aconteça é não incluir trabalho no sistema até ele rebentar. Uma linha de montagem de automóveis tem um limite, e de forma similar, as equipas de IT têm igualmente um limite de pedidos que conseguem realizar. Se assim é, porque continuam as empresas a inserir mais unidades de trabalho num sistema que já está a rebentar pelas costuras? Cada estação de trabalho tem um número de pessoas, com uma capacidade finita para realizar pedidos. Por exemplo, se tens uma equipa de 4 pessoas numa estação de trabalho, e se definires que cada uma delas pode laborar em simultâneo em 2 temas, então a tua capacidade de unidades máxima que deves aceitar nessa estação de trabalho é de 8 e não mais que isso. Ou seja, para adicionar mais 1 unidade, esta estação deve retirar do seu WIP igualmente 1 unidade.

Nota: E como podes controlar o WIP no teu processo? Os quadros Kanban são ótimos aliados, através deles é possível saber a dada altura qual o WIP em cada estação de trabalho e consequentemente qual o WIP total do processo. Noutro artigo prometo falar-te mais dos quadros Kanban.

Todos sabemos o quão difícil é gerir um departamento de IT, existe constantemente trabalho "urgente" e não planeado que aparece no caminho. O maior desafio passa por escolher muito bem o trabalho que é realizado, distinguir o que são urgências verdadeiras de urgências sem fundamento. É que muitas vezes essas urgências servem apenas para beneficiar uma área, ou pior, uma pessoa específica (portanto para essa pessoa é a atividade mais urgente que a empresa tem para fazer). O trabalho não planeado é o verdadeiro cancro de um departamento de IT. Quando uma equipa passa todo o tempo a combater incêndios, sobra muito pouco tempo e energia para planear e para pensar. Ao estar constantemente a reagir não existe energia para fazer o trabalho mental difícil de escolher muito bem o que se deve ou não aceitar. A consequência disto é que mais trabalho entra no sistema, o que significa mais multitasking, mais trabalho "feito à pressa", mais atalhos e mais débito técnico. É uma bola de neve e uma espiral descendente. Fazendo a analogia com uma autoestrada, se a sua capacidade estiver perto dos 100%, existe um engarrafamento gigante, e consequentemente, ninguém anda 1 metro que seja. Se a capacidade estiver um pouco mais baixa, o trânsito fluirá com maior facilidade. Se a capacidade das equipas está perto dos 100%, todo o sistema terminará unidades de trabalho a um ritmo quase nulo.

A melhor forma de exemplificar este conceito é com uma fórmula bastante simples:

Wait Time = % Busy / % Idle

O que esta fórmula significa? Se a % de tempo de ocupação de determinada estação de trabalho é igual a 50%, então a % de tempo disponível é igualmente de 50%. Dividindo uma pela outra obtemos 1, por motivos de exercício poderemos considerar 1 hora de tempo de espera.

Se a % de tempo de ocupação de uma estação de trabalho é igual a 90%, então a % de tempo disponível é de 10%, logo o tempo de espera é igual a 9 (9 vezes mais tempo que no exemplo que dei acima).

Agora vem a parte interessante, se a ocupação de uma estação de trabalho é igual a 99%, significa que a % de tempo disponível é de 1%, logo o tempo de espera é igual a 99 (99 vezes mais que o primeiro exemplo que te dei).

Na prática, isto significa que quando menos % de capacidade disponível a estação de trabalho tiver, mais tempo as unidades de trabalho ficam em espera até serem realizadas. Isto é tão mais grave quanto maior a quantidade de estações de trabalho que uma unidade deve percorrer até ser dada como concluída. A título de exemplo, se o sistema fosse composto por 3 estações de trabalho, todas elas a trabalhar a uma capacidade de 99%, cada unidade de trabalho teria de esperar 99h em cada uma delas até ser concluída, ou seja, 297h! Não admira que digam que o departamento de IT leva 6 meses a entregar um desenvolvimento. Deve ser reservada capacidade das equipas para trabalho não planeado e para pensarem em melhores formas de otimizar o processo. Trabalho com a finalidade de melhorar o processo como um todo é tão ou mais importante que o trabalho atual. A capacidade de as equipas introduzirem melhoria contínua nos seus processos e nas suas formas de trabalhar permitirá reduzir muitas dores de cabeça no futuro. Por exemplo, se em 75% das vezes obtemos bugs em desenvolvimentos de determinada funcionalidade porque o código está complexo e não estruturado, então deve ser reservado tempo para o melhorar, esperando com esta ação reduzir a percentagem de bugs, permitindo que a equipa ganhe ainda mais tempo no futuro. Isto não é teoria, é a realidade, equipas com esta capacidade de se melhorar têm maiores hipóteses de se tornar numa equipa de alto rendimento. No espectro contrário, equipas em que não exista melhoria, rapidamente vão tornar-se obsoletas por efeito da entropia. Dou um exemplo muito simples, um cubo de gelo num copo com água. Com o tempo a entropia aumenta, e o calor faz com que o gelo fique mais desordenado e consequentemente líquido. Para que o gelo possa manter-se no estado sólido será necessário fornecer mais energia para que ele mantenha a sua temperatura, caso contrário e devido à entropia este irá ser transformado em água. O mesmo acontece nas organizações e nas equipas. Deve ser aplicada mais energia ao sistema para que este se mantenha em pleno funcionamento, caso contrário a entropia encarregar-se-á de o transformar em algo caótico e desordenado. É aí que entra a melhoria contínua, é a energia que uma organização/equipa necessita para se manter forte.

Em jeito de conclusão, é fundamental que os departamentos de IT saibam escolher muito bem o trabalho que têm que realizar, sempre alinhado com o que são para a empresa os seus objetivos estratégicos. É fundamental que reduzam o seu WIP, deixando margem para outras atividades como melhoria contínua e otimização de todo o sistema, e é fundamental que se deixe de pensar em ter os recursos o mais ocupados possível, pois isso irá diminuir o fluxo de todo o processo.

Qual a tua opinião?