Gestão Ágil na prática
Antes de começarmos a discutir sobre a importância de uma gestão ágil, vamos do começo:
O que é gestão?
Gestão, nada mais é do que direcionamento a objetivos que potencializam o crescimento através de esforço organizado.
Teoricamente, quando falamos de gestão, falamos de hierarquia e ordem. Um gestor quase sempre é visto como alguém com vasta experiência e sabedoria para superar os problemas do dia-a-dia de uma instituição ou de um time. Na pratica, temos pessoas fechadas, que se veem como “seres” superiores as outras pessoas da companhia e que não aceitam opniões contrárias a sua.
Mas essa é outra discussão. Não vou entrar no mérito de liderança, isso pode ficar para um outro texto. Por enquanto, vamos continuar só com o conceito de gestão.
E qual o papel de um gestor?
No século XX, Henry Fayol definia o gestor com um simples apontamento:
Um gestor é a pessoa que está apta a interpretar os objetivos levantados pela empresa, atuando sempre com base no planejamento, organização, liderança e controle, convergindo tudo para a obtenção do que foi estipulado.
Fazendo uma analogia simples, um gestor é como o piloto de um avião. Levando passageiros de um ponto A a um ponto B.
É ele quem sabe se está tudo certo com o avião, se está voando na velocidade ideal, se todos os tripulantes estão desempenhando seu papel, se os passageiros estão bem, qual rota seguir, como está o clima até o destino, se há percalços no meio do caminho, onde deve parar pra se reabastecer, etc.
A gestão ágil
Agora que já entendemos o que é gestão e qual o papel de um gestor, vamos começar a conversar sobre o que é gestão ágil.
O termo “gestão ágil” é relativamente novo. Surgiu com o crescimento de todo o mercado de tecnologia nos ultimos 20 anos. Este mercado demanda de alta produtividade e mais qualidade em seus produtos, por que no final, o mais importante é sempre a satisfação do cliente.
Gestão ágil nada mais é do que a mínima intervenção no gerenciamento de projetos.
A gestão ágil se baseia em metodologias ágeis. Se você não conhece, recomendo os estudos. Tais metodologias pregam o conceito de aderência ao negócio utilizando melhorias contínuas em seu software. Pequenas entregas realizadas constantemente. E para que esse modelo funcione, cada pedaço do software deve ser quebrado em pequenas partes, o que facilita o entendimento e o desenvolvimento das funcionalidades.
Como premissas, a gestão ágil segue os mesmos 4 conceitos das metodologias ágeis:
– Comunicação: Tem o objetivo de evitar lacunas em processos e problemas entre clientes, equipes e fornecedores.
– Simplicidade: Ela deve ser aplicada durante todo o processo, desde a definição dos requisitos até a entrega da solução.
– Feedback: Muito atrelado ao conceito de Comunicação, o Feedback consiste em retornar prontamente informações entre aos membros da equipe e clientes.
– Coragem: Basicamente a coragem de dizer não quando necessário, para que a qualidade do software não seja afetada.
Com isso, o gestor deixa de estar em uma posição diferenciada e começa a trabalhar como um facilitador, atuando para retirar os impedimentos e maximizar todo o potencial do time ou da companhia. E esses acompanhamentos são possíveis com métricas e gráficos, que sempre dão embasamentos ao gestor sobre o que está acontecendo com seu time.
A importância das métricas
A partir do momento que se está trabalhando com melhoria contínua, a primeira dúvida que aparece é:
Quando meu produto ficará pronto?
Para essa pergunta, há sempre uma resposta diferente. Mas para tranquilizar seu cliente, há um modelo chamado “burndown” que basicamente diz o quão distante você está de concluir o que foi planejado. Acompanhando este modelo, temos um conceito chamado de “forecast” que basicamente recalcula as suas entregas baseando-se nos percalços encontrados. Vou exemplificar mostrando um modelo que eu uso no meu dia-a-dia.
Neste gráfico, temos a projeção de um projeto fictício composto de 140 tarefas. Aqui, não estamos levando em consideração a quantidade de pessoas, e sim, a quantidade de tarefas que precisam ser realizadas para que o projeto seja concluído. Se o ritmo for constante, com uma única pessoa, temos o total de 15 semanas de desenvolvimento. Se o ritmo diminuir para 50% da capacidade, chegamos a 19 semanas. E se aumentarmos a capacidade em 100% conseguimos em 11 semanas.
Este mesmo calculo é refeito a cada entrega. Neste caso, semanalmente.
Vejamos como fica esse mesmo gráfico na terceira semana de entregas.
Na terceira semana, tivemos um bom ritmo de entregas, o que faz com que nossos calculos sejam refeitos. Através da mesma projeção de capacidade, conseguimos traçar uma linha de tendência baseada na vasão de entregas. Com isso, adicionamos a linha mais importante de todas. A projeção baseada na velocidade real de desenvolvimento. Que neste exemplo, aponta o “termino” do projeto em 13 semanas.
Estes números são verdade absoluta? Não.
Mas eles dão uma idéia muito próxima do real. Nos ultimos projetos que estive a frente, utilizando essa metodologia consegui uma aderência superior a 90% das expectativa de entrega.
Além do burndown, também é bastante utilizado o modelo de Velocity, que basicamente aponta a quantidade de tarefas executadas por um ou N times.
Neste gráfico, conseguimos observar que o time 2 está com a vasão de atividades muito superior ao time 1. Normalmente, times com pessoas de níveis semelhantes tendem a ter um velocity semelhante. Utilizando isso como premissa, seria recomendado que o gestor ficasse um pouco mais próximo do time 1 e entendesse o que está acontecendo e atuar para que esses números melhorem.
Ambas as ferramentas são baseadas no time como um todo. E ambas tem como objetivo, o calculo do andamento dos projetos. São ferramentas básicas para qualquer gestor e entender como as coisas estão sendo feitas dentro de um projeto. E só é possível extrair todo o seu potencial se o gestor agir onde for necessário.
Existem diversas tecnicas de ação em cima de um “problema” identificado, desde entender como cada pessoa do seu time funciona até mapeamento dos processos de negócio.
Mas acho que já falei bastante. Se for de interesse das pessoas que lerem isso aqui, podemos iniciar uma série de textos exemplificando o dia-a-dia no desenvolvimento de um produto de software e discutirmos sobre o assunto.
Acho que o que foi mencionado aqui já pode gerar muitas discussões interessantes.
Até a próxima! ;-)
