Definir o modelo de gestão ideal nem sempre é uma tarefa fácil. Hoje em dia temos muito material sobre metodologias ágeis, frameworks e métodos para gestão de projetos.
Mas, encontrar o modelo ideal e adaptá-lo ao dia a dia da empresa pode ser mais complicado do que parece.
Neste post, vou contar um pouco da nossa experiência aqui na ez. De como testamos diferentes modelos de gestão, e os resultados obtidos com cada um deles.
Quer saber um pouco mais dessa trajetória? Então confere abaixo.
Identificando os problemas: A necessidade de ter um modelo de gestão
Assim que começamos os primeiros projetos, a ideia foi logo montar um board para acompanhar o desenvolvimento.
Na época achávamos que apenas ter algumas colunas com cards das atividades, era o suficiente. Mas como escrevi neste post sobre Kanban, para usar o método de verdade é preciso muito mais que isso.
Neste momento, nossa gestão tinha um formato mais tradicional. Eu era o gerente de projetos, que conversava com o cliente, entendia os requisitos e depois adicionava isso no board para a equipe sem muitos detalhes.
Esse modelo pareceu funcionar no início, no entanto começamos a ter uma taxa de retrabalho muito alta.
Tínhamos a seguinte situação: a equipe desenvolvia e entregava rápido, porém sem muitos testes, e algumas vezes sem cumprir os requisitos da funcionalidade.
Isso ocorria devido a tarefas mal escritas, pressão do cliente e um fluxo de trabalho confuso e cheio de indefinições.
Dessa forma, tínhamos muito retrabalho e alta insatisfação do cliente. A gestão precisava melhorar sua atuação e resolver todos esses problemas, foi ai que começamos os primeiros testes.
Primeiro passo: Definição do fluxo e padronização na escrita das tarefas
Neste momento nossos maiores problemas eram taxa de retrabalho alta, e falta de visibilidade de como estava o projeto.
Na tentativa de resolver, fiz junto com o time o processo de STATIK e assim definimos nosso primeiro kanban.
Dessa vez era um quadro que fazia sentido, e que tinha um fluxo a ser percorrido. Com isso, a visibilidade de como estavam os projetos e a organização das atividades ficou bem melhor.
Além disso, os princípios do Kanban de priorização e de terminar mais ao invés de começar novas atividades, contribuíram para entregas mais efetivas.
Uma parte do problema estava se encaminhando para a solução, mas ainda faltava a qualidade.
Para resolver, comecei a melhorar a estrutura dos cards que escrevia, além de critérios de aceite, comecei também a escrever os casos de teste com a ajuda do Forrest, isso auxiliou o time a ter entregas com mais qualidade.
Dessa maneira, adotando as práticas do Kanban, com um fluxo bem definido e uma nova estrutura para escrever as tarefas, os resultados começaram a aparecer.
No entanto, ainda tínhamos muitos desafios pela frente, até chegar ao modelo de gestão ideal.
Segundo passo: Replicar o modelo de gestão
Agora já havíamos criado um processo funcional, e a situação estava começando a melhorar. Mas como nem tudo são flores, um novo problema surgiu.
Na época eu rodava esse modelo de gestão em três projetos, mas precisava replicar para os outros projetos da empresa.
Porém, com este acompanhamento mais de perto, participando de todos os rituais dos projetos e dando manutenção nos boards, eu estava no limite e não sobrava tempo para os outros projetos.
Na verdade, algumas vezes havia até gaps com os times, por me esperarem para uma refinamento ou para a escrita de uma nova tarefa.
Por que não contratar outro gerente de projeto?
Nosso objetivo sempre foi encontrar um modelo de gestão enxuto, para obtermos o máximo de qualidade sem “inflar” os custos. Dessa maneira, ter um gerente de projeto para cada projeto não combinava com os nossos planos.
Na teoria, nosso modelo de gestão funcionava bem. Mas não para nossa realidade. Então percebemos que para replicá-lo seria necessário adaptá-lo ao nosso dia a dia. Aqui começa nossa próxima missão!
Terceiro passo: Percebendo as falhas no modelo de gestão
Aqui começou uma etapa dolorosa. Pois apesar das dificuldades em replicar o modelo, os resultados em utilizá-lo estavam sendo bons.
Fui um pouco relutante no começo, no entanto percebi que algumas coisas que estava fazendo já não tinham mais sentido.
Os casos de teste por exemplo, ajudaram muito no começo. Mas depois que a equipe entendeu a importância de realizar testes com qualidade, já não era mais necessário escrever todos aqueles casos de teste.
Pois o time percebeu que fazendo os testes, o retrabalho diminuiu e consequentemente a satisfação do cliente aumentou.
Além disso, no modelo de gestão da época, todas as demandas passavam por mim. Mas no final eu só replicava para o time de desenvolvimento. Estava sendo um simples repetidor, funcionava como um “proxy“, e isso não fazia sentido.
Já havia passado da hora de rever o modelo de gestão e delegar algumas funções para a equipe de desenvolvimento.
Quarto passo: A concepção do novo modelo de gestão
Finalmente havíamos entendido que nosso modelo precisava ser revisto. E neste ponto, minha relutância já havia acabado. Então começamos a estruturar um novo modelo de gestão.
A ideia principal era me colocar como um “consultor ágil” dentro da empresa.
Os desenvolvedores teriam contato direto com o cliente e eu acompanharia tudo de forma macro, participando apenas de reuniões especificas, como por exemplo entrada de demandas mais complexas e de todas as reuniões de entrega.
A manutenção do board, ficaria por conta dos próprios desenvolvedores, e eu só os auxiliaria na organização e priorização das atividades.
O alinhamento do que seria entregue era alinhado diretamente entre o time de desenvolvimento e cliente. Como trabalhamos com escopo aberto, o cliente faz um acompanhamento mais próximo, então isso não seria um problema.
Na teoria a ideia até parecia funcionar, mas na prática o resultado não foi muito bom. E mais uma vez, precisamos rever nosso modelo.
Quinto passo: Identificando as falhas no modelo de gestão (de novo)
Começamos a rodar o novo modelo, mas haviam muitas falhas e percebemos isso logo no início.
O fato é que não havíamos conseguido definir muito bem os papéis, o time de desenvolvimento estava confuso com o que precisa fazer, e eu mais ainda.
Dessa forma, a ideia de delegar funções ficou mais com um ar de abandono e começamos a ter vários problemas.
Estávamos com 5 projetos acontecendo simultaneamente e eu ficava sem saber muito bem do que acontecia em cada um deles.
Quando fazia o alinhamento com os desenvolvedores para saber sobre o andamento das atividades, parecia estar tudo bem e as expectativas alinhadas. No entanto, quando fazíamos a reunião de entrega com o cliente surgiam muitas insatisfações e a situação do projeto não estava como o esperado.
Os problemas eram vários, e entre as causas estavam:
- Falta de alinhamento de expectativa com o cliente.
- Falta de visibilidade do projeto, por parte da gestão.
- Mudança de prioridade constante por parte do cliente.
- Time de desenvolvimento desorganizado com as demandas.
Mais uma vez tínhamos um grande trabalho pela frente, mas pelo lado bom já era outro modelo testado e várias lições aprendidas.
Sexto passo: Utilizando o aprendizado para chegar ao modelo de gestão ideal
Neste ponto nossa bagagem e experiência com gestão de projetos já era bem maior.
Havíamos feito vários testes e recolhido alguns fracassos no percurso até aqui, e certamente já tínhamos uma boa ideia do que não funcionava pra nossa empresa e nossos clientes naquele momento.
A partir dai, começamos a desenhar o novo modelo. Tomamos como base alguns aspectos dos modelos de gestão anteriores e resolvemos utilizar também os princípios do Kanban, que deram ótimos resultados até aqui. E alguns rituais do Scrum, com os quais já havíamos tido experiência trabalhando em outras empresas.
A ideia ainda era manter o time mais perto do cliente, só que agora com um acompanhamento bem próximo da gestão e adaptando a manutenção do board para cada equipe. O fato é que no nosso caso, algumas coisas precisam ser adaptáveis a cada projeto.
Sétimo passo: A criação do modelo de gestão ideal (para nós)
Com todo esse histórico, pudemos conceber o novo modelo. E a ideia foi criar um modelo de gestão base para replicar com todas as equipes, mas ficamos abertos para ajustes de acordo com as necessidades e preferências de cada time. Dessa forma, chegamos a um modelo base com os seguintes princípios:
- Reunião semanal entre o GP e time de desenvolvimento para alinhamento dos seguintes pontos:
- Review: Aqui falamos das atividades finalizadas pela equipe neste ciclo. Com isso, consigo acompanhar melhor o andamento do projeto. Poderíamos fazer daily, mas como nossas equipes são pequenas, não tem muita mudança de um dia pro outro.
- Refinement: Nesta parte falamos sobre os próximos itens que serão entregues pelo time. Ajudo a equipe no refinamento e priorização das tarefas, de acordo com o backlog do projeto.
- Retrospective: Fazemos um bate papo sobre o que aconteceu na semana. Dentro desse ritual, uma vez por mês ocorre uma pesquisa onde peço para o time de desenvolvimento realizar uma avaliação de alguns quesitos que envolvem o processo e o projeto, como por exemplo:
- Modelo de gestão
- Apoio da gestão
- Apoio técnico
- Taxa de retrabalho
- Efetividade do QA
- Efetividade do Devops
- Reunião quinzenal de entrega para o cliente acompanhar a evolução do projeto.
- A priorização do backlog é feita sobre demanda, junto com o cliente.
- Fluxo do board seguindo os princípios do método Kanban.
- A manutenção do board em alguns casos é feita pelo próprio time, que prefere criar suas tarefas com os checklists do que precisa fazer. Outras equipes preferem que eu crie essas tarefas, no entanto, hoje nossos cards são mais objetivos, não escrevo os casos de teste, apenas o que o desenvolvedor precisa entregar.
Ao infinito e além
Como vocês podem ver, não há nada de novo ou surpreendente, afinal não precisamos redescobrir a roda para conseguir ter um modelo de gestão ideal, basta utilizar aquilo que você já sabe de uma forma inteligente. No nosso caso, misturamos um pouco do Scrum com Kanban, em um ambiente colaborativo e estamos tendo ótimos resultados.
O fato é que nosso modelo está mais simples, tem menos coisas envolvidas, funciona bem para nosso momento atual e contexto dos projetos nos quais estamos atuando. Antes investia muito tempo em boas práticas, mas não dava conta de atender nossas necessidades. Estava fazendo um “gold plating” da gestão de projetos.
Hoje considero que o tempo investido na gestão precisa ser proporcional aos benefícios alcançados com isso. Ou seja, precisamos ter uma boa relação custo benefício para fazer sentido.
Sabemos também que esse “modelo de gestão ideal” é um processo evolucionário, que sempre precisará ser melhorado e adaptado a nossa realidade. Por isso, nossa trajetória não acaba aqui, porém agora estamos mais preparados para essa missão.
E ai, qual modelo de gestão você utiliza na sua empresa? Tem alguma dúvida? Deixe nos comentários.
