Entregue mais de 300 tarefas no prazo utilizando PERT/CPM

No post anterior descobrimos como a Matriz de Dependência pode nos ajudar no processo de planejamento das tarefas. Também vimos que ela gera insumos importantíssimos para o PERT/CPM. Mas que dupla é essa, afinal?

[http://www.cemeai.icmc.usp.br/images/noticias/pde_grafos_pre/grafos.jpg]

PERT/CPM são duas metodologias utilizadas na gestão de projetos. Comumente utilizada em projetos mais estáticos - como na área da construção civil, por exemplo - elas ajudam a gestão a identificar pontos de atenção e a gerenciar os recursos. Principalmente o recurso tempo.

Preciso dizer que estou explicando bem por cima (e apenas a parte que nos é interessante) esta metodologia. Se você pesquisar mais - ou for aluno ou aluna de engenharia de produção - vai encontrar mais material falando sobre os cálculos possíveis de serem feitos à partir dos dados extraídos desse gráfico. Médias, desvios padrões... É aqui que as suas aulas de cálculo serão bem empregadas.

As duas metodologias são muito parecidas, tanto que é difícil separá-las. De modo geral podemos dizer que:

Pert: Program Evaluation and Review Technique

Com base na Matriz de Dependência, você cria um grafo com os caminhos possíveis para a implementação. Além de colocar as tarefas, você indica também o tempo gasto para a produção delas. No final, teríamos um gráfico assim:

[Exemplo do gráfico de pert: https://pt-static.z-dn.net/files/db8/328b1b784f5768c4801aedfeff5decf1.png]

Existem várias implementações desse gráfico. Cada uma delas visa trazer mais informação de forma visual. Na internet você vai encontrar vários vídeos e legendas distintas. Meu conselho é que você procure algo que faça sentido para o seu projeto. Do contrário, pode poluir o quadro com informações desnecessárias.

[A seta]

A seta indica uma ação. Pode ser uma story ou uma feature, ou um passo qualquer do processo de produção. A letra e o número ao redor dela são um identificador da tarefa e o tempo que será gasto na sua execução

[A seta pontilhada]

A seta pontilhada indica uma uma dependência. Para que a tarefa X (ponta da seta pontilhada) possa ser executada, é preciso que a tarefa Y (origem da seta pontilhada) seja concluída antes.

[O círculo ou nó]

O circulo indica junções entre as tarefas. Eu vi algumas pessoas colocando informações nesses círculos, como tempo gasto até aquele ponto, identificação da tarefa e assim por diante. Eu não acho tão interessante assim. Mas, como eu disse, faça o que fizer sentido para o seu time.

Além do gráfico, a metodologia PERT também envolve o cálculo dos caminhos Otimista, Pessimista e Mais Provável. Não entrarei nesses detalhes para não fugir ao escopo dessa matéria. Há extenso material disponível na internet, caso você queira se aprofundar ainda mais no assunto.

CPM: Criticam Path Method

Uma vez que o gráfico esteja pronto, você pode traçar os vários caminhos possíveis. Some os tempos de cada tarefa e anote, próximo ao nó, o tempo gasto até ali (em caso de nós que centralizem bifurcações, anote o maior tempo somado até então). Quando todos os caminhos estiverem anotados, verifique qual é o maior. Este será o Caminho Crítico.

Este caminho leva esta nome porque, como é o caminho que levará mas tempo para ser concluído, cada uma das suas atividades podem impactar diretamente no tempo de conclusão. Você vai perceber que haverá situações de folga entre as atividades. Identificar essas folgas irá ajudar você na gestão de recursos e de pessoas. Talvez transferindo para apoiar em outra tarefa, ou auxiliar na contenção do retrabalho... A folga, portanto, é apenas "virtual".

Aplicando em um projeto de TI.

Você vai encontrar vasta literatura falando sobre como essa metodologia pode ser aplicada na área de construção civil. Mas nos somos da área de TI e é sobre isso que vamos falar.

Montando o gráfico de PERT

Nossa equipe trabalha com SCRUM e FDD (Feature Driven Development). Então nossa matriz de dependência envolvia tanto as features quanto as stories do projeto. Nela nós apontamos a relação de dependência Obrigatória (impossível continuar sem as dependências acabadas) e de dependência Desejável (se as dependências estivessem prontas, facilitaria os testes ou algum outro processo).

No momento de gerar o gráfico de PERT, levamos em consideração as duas formas de dependência (anotando com formas diferentes). Para que o quadro ficasse de forma mais sucinta, agrupamos as stories que fossem altamente dependentes e com curto prazo de desenvolvimento. Assim um Dev estaria focado em um grupo de tarefas por um tempo maior ([quase] uma Sprint), sem perder a linha de raciocínio.

Concluída a primeira versão do gráfico, identificamos alto número de dependências e o projeto poderia se estender para muito além do prazo desejado do cliente. O que fazer? Procuramos meios de diminuir as dependências e favorecer o paralelismo. Como? Interfaces! Enquanto parte da equipe executava tarefas mais triviais, traçamos um caminho (mais longo) em que um dos devs ficaria responsável por escrever Interfaces e classes abstratas que permitiriam o trabalho em paralelo. Assim um dev poderia trabalhar em uma tarefa com o insumo de uma outra tarefa ainda não finalizada.

Aumentar a paralelização das tarefas, do ponto de vista da gestão do tempo, foi o diferencial para que pudéssemos alcançar um prazo real de entrega e que fosse satisfatório para o cliente. Durante a análise do quadro identificamos algumas possíveis "folgas" nos prazos. Estas foram consumidas por alterações de escopo que surgiram durante o desenvolvimento da demanda.

O caso é que a matriz de dependência e o PERT/CPM sozinhos não fazem milagres. Ainda é preciso saber:

Conhecer bem a equipe.

Conhecer o nível técnico de cada pessoa da equipe é algo já esperado e realmente importante. Quanto mais apertado o cronograma, mais determinante é atribuir a pessoa certa à tarefa correta. Mas só isso não é suficiente. Demandas grandes geralmente exigem muito esforço e provocam desgastes entre os envolvidos. O time precisa estar motivado. E para que isso aconteça, é preciso gerenciar outros aspectos pessoais e papeis dentro do time. Se o nível técnico pode definir papéis práticos dentro do time, pessoas com as chamadas soft skills auxiliam a manter o cliente feliz e o time motivado. Empatia, capacidade de negociação, comunicação clara, resiliência são exemplos de soft skills desejáveis nos componentes do grupo.

Múltiplos caminhos

Nem sempre um dev precisa concluir todo um caminho. É possível alternar entre os vários caminhos - ou focar em apenas um conforme a possibilidade. Ainda, não há uma relação direta entre o caminho crítico e a senioridade das pessoas do seu time. Um caminho é crítico por conta do tempo que ele leva para ser desenvolvido e não por conta da sua complexidade. É importante, claro, que todos os dev tenham pleno conhecimento da demanda. Mas sempre haverá aqueles que estão mais à vontade. Ou por melhor compreensão da demanda ou por maior conhecimento técnico. Se puder escolher, opte por esses profissionais para alternar entre os vários caminhos do gráfico de PERT.

O time deve estimar

Estamos lidando com estimativas. E a melhor pessoa para estimar um trabalho é quem irá fazê-lo. Para construir as estimativas, metodologias aplicáveis em equipe: Planning Poker é um bom exemplo. O importante é não chutar um número ao esmo. Aqui vale a máxima do Uncle Bob, no livro The Clean Coder:

O problema é que nós encaramos estimativas de formas diferentes: O pessoal dos negócios preferem entender as estimativas como compromisso. Devs preferem entender estimativas como "chutes". A diferença é profunda

Busque fundamentar a sua estimativa. Leve em consideração o que você sabe - e não sabe - sobre o ferramental técnico e sobre o negócio a ser implementado. Não se esqueça das cerimônias do SCRUM (ou qualquer outro framework que você utilize), o tempo que você gasta ajudando os coleguinhas, o tempo do café... E só então apresente um número. E não negocie. A não ser que você queira trabalhar de madrugada.

A etapa de planejamento também é desenvolvimento!

Antes do início do desenvolvimento e no começo de cada sprint, um tempo considerável foi empreendido para planejamento. Primeiro de maneira mais macro, distante do código, pensando nas soluções possíveis de serem implementadas. E a cada nova reunião, aumentávamos a precisão até que antes de cada sprint era possível saber que algoritmo implementar e onde ele deveria ser implementado no código.

O tempo de planejamento precisa ser contado como tempo de desenvolvimento. Você pode não criar linhas de código neste momento. No entanto, você está criando a solução na sua cabeça ou numa folha de papel. A qualidade desse tempo irá refletir diretamente na qualidade do seu código, e por consequência na quantidade de tempo de retrabalho.

O fim da estória 

No final, considerando que houveram alterações solicitadas pelo cliente dentro do que havia sido combinado no início da demanda, entregamos o código com apenas duas horas de atraso em relação ao prazo final estipulado. Considerando que foi um projeto que fugiu à todos os padrões da produção de software (sendo o principal, escassez de definição), com um tempo estimado de aproximadamente 6 meses, 101 stories e média de 300 tarefas, foi uma pontaria certeira. Você não acha?