Porque o trabalho em andamento (work in progress) pode matar sua empresa
Ao desenvolver diversos projetos na empresa é comum separarmos os produtos e atividades em esperando realização (fila), trabalho em andamento (work in progress) e concluídos. O work in progress (WIP), ou trabalho em andamento, é um bem parcialmente acabado de uma empresa à espera de conclusão e eventual venda. O termo é usado na produção e na gestão de suply chain. Uma prática da metodologia ágil de gestão é limitar o work in progress, o que nem sempre é bem visto por gestores e mesmo colaboradores.
Neste post vamos falar como o work in progress (WIP) pode ser prejudicial para o seu time e para sua empresa e como limitar ou nem implantar o WIP é o ideal.
Por que limitar o work in progress?
Quando uma empresa resolve limitar os work in progress influencia mudanças de comportamento dos colaboradores. Mas mudanças nem sempre são bem vindas e o que geralmente escutamos é que a introdução de limites de WIP é difícil para muitas equipes. Há resistência contra o mecanismo, que é percebido como uma prática coercitiva pois as pessoas naturalmente tendem a fazer o que eles fazem sempre: pegar mais trabalho e ponto.
Se houver resistência da equipe e da gestão da empresa, o gerente de projetos deve fazer um trabalho de sensibilização com eles sobre os benefícios dessa técnica de administração e como, na verdade, essa mudança vai melhorar a produtividade de todos. Mas atenção, caso a resistência seja muito grande não force a barra, pois implantada a força esse método simplesmente não vai funcionar. Tente convencê-los a pelo menos testar por algum tempo ou determinado projeto. Se precisar de mais dicas para lidar com stakeholders, leia este e-book tem dicas valiosas para você!.
Benefícios
Os ganhos com um limite para o work in progress são muitos e geralmente logo a equipe compreende isso e o ânimo melhora bastante. Essa metodologia reduz a necessidade de multitarefa e mudança de contextos. Os ciclos são menores, o que acarreta em um maior senso de realização. E o melhor, a pressão no time cai.
Outra dica para motivar a todos é mostrar como eles se tornaram produtivos, medindo as datas inicial e final de itens no trabalho. Isso permite descobrir tanto o tempos de ciclo (quanto tempo leva para concluir um item de trabalho) e rendimento (como muitos itens de trabalho são concluídos em um determinado espaço de tempo). O objetivo é que as pessoas peguem menos trabalho e se concentrem em terminar itens em vez de iniciá-los. Menos multitarefa e mais foco.
Os limites de WIP devem ser acordados pela equipe antes de um projeto começar. Por exemplo, uma equipe de desenvolvedores pode dividir as tarefas que devem ser executadas em design, código, testar e implantar. Quando um limite de WIP para uma determinada tarefa tenha sido alcançado, a equipe para e trabalha em conjunto para eliminar o gargalo. O objetivo de trabalhar assim é garantir que toda a equipa tome posse do projeto e produza um código de alta qualidade e sem atrasos.
Work in progress limitado e Kanban: Exemplo prático
Já falamos do modelo kanban, grande aliado das metodologias ágeis (inclusive, em janeiro lançamos este template gratuito exclusivo para Google Drive). Agora, vamos dar um exemplo prático do controle de work in progress utilizando com essa poderosa ferramenta.
Sempre que você terminar um item, verifique se existem bloqueadores. Se houver, tente resolvê-los. Se não houver, olhe para todos os itens não atribuídos começando da parte do quadro mais próxima da coluna completada (normalmente mais à direita). Depois, gradualmente, vá para o início do fluxo de valor. Inicie um novo item apenas quando não houver literalmente nada que você possa fazer pelos itens em curso.
Se tomamos um desenvolvedor como exemplo o processo pode parecer como o da ilustração acima. Uma vez que terminou de escrever o código de um trabalho, ele olhou para o quadro e viu que tem um item bloqueado. Acontece que o bloqueador está esperando por uma resposta de um cliente. Uma breve conversa na equipe revelou que não há porque importunar o cliente sobre feedback agora, mas que pode ser um bom momento para lembrar o sobre o bloqueador.
Em seguida, o desenvolvedor volta para o quadro e observa que o próximo passo é aceitação. Se não há nada para agir sobre a aceitação, então temos os testes e assim sucessivamente até a conclusão do trabalho como um todo.
O interessante é que na grande maioria dos casos haverá alguma coisa para fazer. Basta tentar imaginar uma situação em que não há literalmente nada bloqueando, precise de ajuste ou melhorias. Se enfrentarmos uma situação assim, provavelmente não precisa limitar o trabalho em andamento mais. Se conseguirmos orientar a equipe a adotar a orientação para escolher tarefas nós vamos conseguir que eles limitem o trabalho em andamento e com bem menos resistência.
E você, já implantou uma política de work in progress limitado? Está pensando em implantar e quer mais ideias? Comente e vamos aprofundar essas questões!