Antes de falar sobre o TaktPM é preciso discorrer sobre a real natureza do trabalho de um projeto durante sua execução. Os deliverables dos projetos movem-se em lotes de quantidades determinadas entre os membros da equipe, os quais assumem alternadamente posições de fornecedores e clientes entre si. Podemos enxergar esse processo como uma cadeia de valor onde os insumos do projeto vão sendo transformados em deliverables cada vez mais próximos daquilo que o cliente deseja e que, ao longo da cadeia, vão sendo integrados, constituindo o produto final do projeto a ser entregue. Temos, portanto, no início dessa cadeia, insumos, e no final dela, o produto do projeto pronto e aceito.

Podemos pensar um projeto em termos de macroprocessos em cadeia, cada um recebendo subsídios e alimentando os processos subsequentes em fluxo contínuo. A divisão em macroprocessos do value stream seria diferente da clássica divisão de um projeto em fases, pois nesta há acumulo de deliverables até a aprovação de evolução de fase e não fluxo contínuo. Os macroprocessos do value stream podem ser quebrados em processos menores, cada um com um dono, como no conceito de pacote de trabalho, formando uma rede conectada por relações clientes-fornecedor.

Durante a execução do projeto, quando um membro da equipe com papel de fornecedor envia deliverables para um membro da equipe com papel de cliente em um fluxo maior que o consumo, ocorre um acúmulo de deliverables aguardando para serem processados, formando-se um estoque. Pode acontecer também a situação contrária, na qual o cliente consome os deliverables num ritmo maior que o fornecedor consegue enviar, levando o cliente a ficar ocioso aguardando remessas de deliverables.
Uma maneira de ter uma visão dinâmica dessa organização é imaginar uma corrida de revezamento, com diversas passadas de bastão (handoffs) entre os membros da equipe. Infelizmente, num projeto real, ao contrário da corrida de bastão, existem devoluções de deliverables entre a equipe e nem sempre esta trabalha de maneira sincronizada.

Existe ainda outra perspectiva a ser pensada, a dos recursos. Os recursos podem ser alocados de maneira dedicada a um processo, focando toda sua energia em transformar um lote de input recebido em outputs; ou o contrário disso, o recurso pode ser compartilhado simultaneamente entre outros pacotes de trabalho do mesmo projeto, ou entre outros projetos, ou com trabalho operacional do dia-a-dia, e nesse caso sua energia e foco serão fracionados entre essas diversas frentes, alongando os prazos de finalização de todos eles.

O tradicional, e já antigo, gráfico de Gantt modela de maneira pobre e imprecisa a realidade do trabalho em projeto, sem movimento em lotes de deliverables, sem loopings e devoluções, sem relações cliente-fornecedor, sem levar em conta fluxo e estoques. O gráfico de Gantt não mostra um projeto, mas um calendário com marcações de quando achamos que atividades inventadas por nós deveriam terminar. A gestão pelo Gantt resume-se a verificar se as atividades foram realizadas na data planejada, cabendo ao gerente de projeto “dar broncas” na equipe no caso de atrasos. Talvez essa não seja a melhor maneira de gerenciar projetos.

Se a equipe tiver alguma esperança de ter o projeto nas mãos terá que modelá-lo e gerenciá-lo como um PROCESSO. Dessa maneira, poderá identificar gargalos, agir sobre estes e evitar investir suas energias em pontos que apenas criam mais estoques.

Na metodologia Takt PM, proponho que você se prepare para a execução do projeto alcançando um conhecimento sintético, mas profundo, do processo de trabalho do projeto por meio da construção de um novo diagrama que chamei de Relay Race Diagram. Nesse diagrama, que pode lembrar uma WBS, ao mesmo tempo que os elementos de menor nível são pacotes de trabalho, eles também são processos no formato S.I.P.O.C (Supplier-Input-Process-Output–Customer), o que batizei de S.I.WP.O.C ‘s, sendo o WP Work Package. No diagrama, os pacotes de trabalho são modelados como clientes e fornecedores, os deliverables de input e suas quantidades são representados à esquerda do pacote de trabalho, os deliverables de output e suas quantidades de produção e devoluções são mapeados à direita dos pacotes de trabalho. No topo do diagrama temos os macroprocessos que constituem a cadeia de valor. Os pacotes de trabalho possuem múltiplas ocorrências , normalmente elas representam os múltiplos lotes nos quais o trabalho é entregue. O diagrama é construído de trás para frente, o que é chamado de pull planning. Imaginamos o produto sendo entregue para o cliente e nos perguntamos recorrentemente o que é o mínimo necessário para isso acontecer, quais pacotes precisam ser feitos. Esse processo visa excluir trabalho que não contribui para entregar o produto final do projeto.

O Relay Race Diagram é a primeira ferramenta que apresentarei sobre a TaktPM. Existem outras bem interessantes e que se integram com ele, mas por enquanto que tal trazer esse conhecimento para seu projeto? Sintetize junto com sua equipe um Relay Race Diagram de seu projeto e depois conte o que descobriu.

Se você desejar, poderá testar um Relay Racer Diagram para seu projeto numa versão teste do software que desenvolvi para o ensino do TaktPM e que pode ser baixada no seu iPad. Existe como produzir um relay racer diagram no papel utilizando post-its (notas adesivas). Tudo isso está bem explicado nesse vídeo: