Rapidinhas sobre o gerenciamento ágil de projetos

Acabo de completar o meu ano sabático – um ano fora da gestão de projeto.

Foi uma decisão muito importante para a minha carreira. Depois de 8 anos estudando gestão, tive tempo para atualizar o meu “lado” técnico.

Também foi possível fazer autocrítica à minha forma de gerenciar projetos e pessoas. Alguns comportamentos que eu (gestor) julgava naturais, eu (não-gestor) percebi que eram bastante prejudiciais à equipe. Talvez até explicassem porque eu não conseguia obter algumas coisas da equipe.

Mas o fato é que foi ainda sob a minha gestão que implantamos o gerenciamento ágil de projetos para a equipe.

E o que diabéisso?

O que é gerenciamento ágil?

É gerenciar o projeto mais rapidamente? Gestor correndo? Equipe correndo? Terminar o projeto mais rápido? Gerenciar com agilidade? VAI, VAI, VAI, VAI!?

Nada disso!

O gerenciamento ágil de projetos é um conjunto de técnicas e metodologias que objetivam gerar mais valor para o cliente, através de entregas incrementais e frequentes e do empoderamento de uma equipe auto-organizada. Sendo a sua metodologia principal o Scrum.

Como assim?

A base de toda a metodologia é o conceito de sprint: um espaço de tempo fixo. Geralmente é medido em semanas e pode ter de 2 a 4 semanas dependendo do projeto e da equipe.

O objetivo da sprint é entregar uma nova versão do produto com mais valor para o cliente de acordo com as prioridades dele!

A sprint é subdividida em 4 espaços de tempo fixos, todos com participação de TODA a equipe:

• Primeiro dia da sprint: dedicado ao planejamento do que será executado dentro da sprint. Esse planejamento é democrático e coletivo;
• Primeira metade do último dia da sprint: revisão, ou seja, demonstração para o cliente da nova versão do produto desenvolvida na sprint;
• Segunda metade do último dia da sprint: retrospectiva (ou lavagem de roupa suja). É um momento para a equipe discutir francamente o que foi bom e o que foi ruim durante o trabalho na sprint. O que poderia ser melhorado, evitado ou ratificado nas próximas sprints?
• O restante do tempo da sprint é dedicado à execução, à produção, ao desenvolvimento do que foi planejado.

(Perceba que o tempo é fixo e, portanto, a sprint não atrasa. Podemos até não concluir tudo o que planejamos como objetivo inicial da sprint, mas haverá uma entrega no último dia.)

Durante a execução, a equipe se reúne diariamente para alinhar os ponteiros: estamos conseguindo avançar rumo ao objetivo da sprint? O que nos atrasa ou impede o nosso andamento?

Como fizemos gerenciamento ágil de projetos?

O nosso planejamento inicial era feito em uma planilha. Na primeira aba, os objetivos da sprint (a última coisa a se preencher, por sinal).

Na próxima aba, a disponibilidade da equipe, ou seja, quais pessoas, quantos dias, quantas horas por dia… Somando tudo, a gente saberia quantas horas de trabalho a equipe dispunha para a sprint.

E aqui, um pulo do gato: a gente só contava com 75% das horas possíveis. Os demais 25% eram a “gordura” (reserva gerencial) da sprint, reservada para imprevistos, planejamento falho, coisas que atrasam, coisas que não funcionam, licenças médicas etc.

Parece um desperdício não planejar 25% das horas de uma equipe, mas acredite nos nossos resultados: é melhor planejar 75% das horas disponíveis e entregar tudo o que você prometeu do que planejar 100% das horas e entregar metade do prometido!

Perceba a sutil diferença entre horas planejadas e horas trabalhadas. Existem tarefas planejadas para 8 horas que são feitas em 4. Assim como, o contrário também é verdadeiro. O importante é ter margem de erro para conseguir cumprir todos os objetivos da sprint. Uma equipe que trabalha com criatividade e consegue ser produtiva em 75% do seu tempo é uma equipe extremamente eficiente.

Na próxima aba, a gente listava todas (todas, mesmo) as atividades necessárias para concluir as novidades do produto conforme solicitado pelo cliente. Para cada atividade, a estimativa de horas necessárias. E isso era totalmente democrático (todos opinavam sobre qual atividade e quantas horas necessárias) e anônimo (inicialmente, a atividade listada poderia ser executada por QUALQUER pessoa da equipe).

A gente tentava não criar atividades muito grandes que dificultavam o seu acompanhamento. O ideal era termos atividades de no máximo 8 horas para que pudessem ser concluídas em, no máximo, 1 dia de trabalho. Uma atividade de muitas horas era séria candidata a ser dividida em subatividades menores.

Esse planejamento continuava com a inclusão de novos pedidos do cliente até que a gente conseguisse aproximar as horas das duas abas: horas disponíveis para trabalho x horas necessárias para concluir a entrega.

A planilha nos dava o gráfico mágico de burn down. Basicamente, esse gráfico mostra a linha ideal da sprint, ou seja, uma linha projetando a quantidade de trabalho restante pelos dias. Pense em uma linha reta começando com o máximo de horas no dia 0 e terminando com 0 hora no último dia da sprint.

Essa planilha ficava no Google Drive para que todos pudessem atualizá-la durante a sprint. A atualização consistia em cada membro da equipe dizer quantas horas ainda seriam necessárias para concluir as suas atividades. Essas atividades também eram criadas em um quadro do Trello (kanban) para que a equipe pudesse atribuí-las para si e informar sobre andamento e conclusão.

A equipe era obrigada a atualizar a planilha de horas restantes pelo menos uma vez por dia, antes da reunião diária citada anteriormente. O objetivo era divulgar para todos em tempo real e de forma transparente o gráfico de burn down atualizado. A planilha produzia uma segunda linha com as horas que realmente restavam para a conclusão do trabalho. Assim, poderíamos comparar visualmente o estimado com o realizado. Se a nossa linha estivesse acima, estávamos atrasados, pois faltavam mais horas de trabalho do que o estimado para aquele dia da sprint. Obviamente, linha abaixo, equipe adiantada.

Também chamado de microgerenciamento (do tempo, do trabalho, das atividades, das horas, da alocação…).

No final da sprint, utilizávamos o Agile DMAIC. Trata-se de uma ferramenta criada por um membro da equipe (Thiago Ferraz) que nos ajudava a avaliar a nossa aderência às práticas do Scrum e nos apontava como melhorar nas próximas sprints.

> Site do Agile DMAIC

Obviamente, ter na equipe dois gerentes de projetos com larga experiência em gerenciamento ágil nos deu muita segurança para mudarmos a nossa forma de trabalhar.

Prós e contras do gerenciamento ágil de projetos

Eu notei um aumento brutal da produtividade da nossa equipe. Eu não tinha métricas precisas da nossa produtividade anterior, mas estimo que a nossa produtividade tenha aumentado em torno de 300%!

E daí, eu lembrei lá do livro do Scrum que eu printei acima…

A produtividade melhorou bastante por conta da comunicação e do fluxo de trabalho. Todo mundo já sabia prévia e publicamente tudo o que precisava ser feito na sprint. Eu não tinha que estar orquestrando tudo o tempo todo. Deixei de ser um gargalo. Não importava se eu estivesse em uma reunião e indisponível para a equipe: todos já sabiam o que fazer.

Eu passei a ser mais um orientador conduzindo a equipe pelo processo e usando a minha experiência para tentar alertar a equipe sobre problemas futuros e pegadinhas em potencial.

A equipe estava muito mais comprometida em fazer o projeto dar certo e em cumprir o planejado. Afinal, foi a equipe (praticamente sem pressão) quem disse o que dava para entregar naquele tempo.

Havia um sangue nos olhos para concluir atividades e baixar horas (diminuir as horas restantes de trabalho). Havia uma necessidade de se mostrar útil para a equipe. Não deveria, mas era um tanto constrangedor você chegar na reunião dizendo que não baixou nenhuma horinha. E a própria equipe se cobrava para que todos “funcionassem”.

Naturalmente, notei a equipe mais cansada e mais estressada. Com pequenas sprints, quase toda semana é a semana decisiva da entrega. A equipe estava quase sempre em tensão total, trabalhando a 200% para não perder a sprint.

Essas entregas rápidas (“ágeis”) nos davam um feedback igualmente ágil, tanto do cliente, como dos nossos pares. Trazendo agilmente melhoria contínua para a próxima sprint.

O gerenciamento ágil investe pesado em psicologia: entregar o que prometemos, zerar as horas de trabalho via gráfico, prestar contas nas reuniões, vencer a sprint, fazer ainda melhor na próxima… Funciona porque mexe no íntimo dos seres humanos. Como assim a gente não consegue o que a gente mesmo prometeu?

(Logo do projeto "Sim, nós podemos" que arrecada brinquedos e comida para orfanatos e asilos)

O gerenciamento ágil, com seus rituais e artefatos, nos obrigou a gerenciar o projeto de forma mais organizada.

E valeu a pena?

Como diz um radialista aqui do Ceará: ora se valeu!

Eu não me vejo mais gerenciando projetos de uma forma que não seja a que tentei descrever nesse post.

Um abraço e vamos correndo até a próxima!

Post Scriptum

Nessas coincidências doidas da vida, no dia 23/11/16 eu precisei assumir temporariamente a gestão do nosso projeto uma vez que o gestor precisou tirar uma licença imprevista. Foi muita coincidência isso acontecer exatamente 1 ano após o dia 23/11/15, quando eu comecei a minha pausa.

Ei, psiu, se liga…

Dá para ficar sabendo das novidades do blog pelas redes sociais. Sigam-me os bons!

        

Conheça a minha obra completa em:

> paulodetarso.art.br