Planejamento e propósito para modelos de gestão

Um dos assuntos crescentes no mercado de gestão de projetos em agências é a utilização de metodologias e ferramentas para apoiar no dia a dia, sendo as metodologias ágeis e principalmente o Scrum, os mais requisitados. Essa crescente se dá pela eficácia destes métodos e também pelo exponencial número de cursos, certificações e conteúdos a este respeito permeando nas redes.

Quando fazemos uma imersão nas mais diversas teorias, nos deparamos com um material muito rico, contudo é importante ter consciência entre a teoria e a sua aplicação na prática. Vejo muitos profissionais que advogam por vertentes (seja ágil ou “tradicional”) e acabam se frustrando por não conseguir aplicá-las 100%. Muitos até perdem o prazer de atuar nos projetos por esta falta do alinhamento do time com a sua proposta de trabalho.

Em minha carreira de projetos, sempre fui muito observador sobre esse tema dentro das agências e acredito que seja uma questão de entender as situações com maturidade. Experimentando a implementação de novos métodos de trabalho você acaba se deparando com diversas variáveis, como: budget, equipe, prioridades, cultura, alocação, maturidade e pessoas. E o pior: muitas vezes essas questões acabam fazendo mais sentido do que a aplicação do que estamos almejando em si.

De nenhuma forma devemos nos contentar em como as coisas estão postas. É nosso papel apresentar novas formas de organizar o trabalho e trazer valor para o mesmo, contudo é preciso ter consciência de que a aplicação de um método / ferramenta por completo quase nunca é viável; as mudanças são graduais e que muitas vezes temos de saber atuar no projeto com apenas parte das implementações. Precisamos encarar isso simplesmente como parte do processo, e prestigiar os avanços graduais, ao invés de se abater por não alcançar o todo.

Aproveitando este tema, gostaria de destacar dois pontos a considerar antes de trazer qualquer tipo de processo na sua operação: propósitos e carga.

Propósitos

Certa vez um instrutor de gestão de projetos fez uma analogia sobre ter uma caixa de ferramentas (repertório) e aplicar cada uma delas dependendo da necessidade do projeto e/ou operação. Essa analogia faz total sentido pra mim até hoje e diz respeito a utilizar as ferramentas ao nosso favor, ao invés de trabalhar para elas.

Por isso, antes de trazer qualquer nova implementação, é preciso dar um passo atrás e se perguntar:

• Quais são os principais problemas que precisamos resolver? Aqui é importante trazer fatos e histórico que validem a pergunta, se possível exibido com Pareto
• Por qual motivo devemos implementar isto?
• Há outras ferramentas que resolvem este problema?
• Estamos aplicando para resolver problemas ou porque faz parte de determinada teoria?
• Mesmo que encontre dificuldades, a sua aplicabilidade é factível dentro do cenário atual?

Outro exercício para trazer propósitos a tona, é entender o que na prática significa cada implementação. Por exemplo, não se faz daily, porque faz parte do scrum, mas sim porque esta é uma maneira identificar impedimentos e riscos com antecedência. Não se faz uma retrospectiva porque faz parte do scrum, mas sim porque é uma oportunidade para colher melhorias contínuas e ter um espaço democrático para todo o time. Estes são apenas alguns benefícios concretos de suas aplicações. Basicamente, nunca aplique por aplicar.

Carga

Mesmo as implementações “magras”, possuem atividades que despendem tempo. Por mais que elas substituam outras mais pesadas, é preciso dar um passo atrás e colocar no papel antes de sair oficializando. Pegue cada atividade, rito, ferramenta ou o que seja, e leve em conta o seguinte:

• Qual é o tempo médio que a pessoas irão investir? É importantíssimo ter um timesheet bem apurado para se ter uma fotografia do cenário atual. PS: levar em consideração todas as pessoas que serão impactadas
• Qual a frequência que irei aplicar? Ex: daily todos os dias, retrospectiva a cada X semanas, documento Y em uma periodicidade tal, etc

Após isso em mãos, eu costumo colocar estes dados em um histograma:

Após montar o histograma é possível ter um cenário, do quanto o que está implementando consome. Outros pontos:

• Jogue as horas das atividades “cotidianas” junto com as novas atividades que irão fazer parte do dia a dia e verifique se não ultrapassa a carga horária diária
• Leve em consideração que normalmente as atividades variam de semana pra semana, contudo é bem difícil que seja algo extremamente inconstante, portanto, tenha conhecimento das altas e baixas. No caso de projetos, por exemplo, você consegue “sentir” essas nuances dependendo do estágio que ele se encontra e também de algumas características do mesmo
• Após considerar o tópico acima, faça diversos cenários, validando que o que está planejando é minimamente factível
• Leve em consideração todas as pessoas que irão se envolver no processo, inclusive você
• Caso os cenários apresentem sobrecarga, verifique quais atividades podem ser eliminadas para o que está propondo possa ser compatível

PS: O método acima não é uma receita de bolo, mas sim, uma das maneiras que uso para planejar novas implementações.

Após fazer o exercício acima, você irá se deparar com as variáveis que comentamos no início deste artigo. Muitas vezes vamos “cair na real”, de que uma daily de “apenas” 15 minutos pode impactar muito na operação, principalmente se os times tratarem múltiplos projetos (outra variável). 

Montar times pode ser um desafio, por questões como: conhecimento técnico restrito a algumas pessoas (que precisam permear por vários projetos para resolver questões pontuais), impossibilidade de alocação full time (ou próximo disso), múltiplos projetos que geram inúmeros ritos durante o dia, etc. Neste caso, normalmente a realidade de uma agência é bem diferente de quem trabalha com produto, por exemplo.

Em outros casos é perceptível de que é preciso mais time para representar alguns papéis, mas o budget não é suficiente, ou mesmo compensa trazer este profissional, por questões lógicas e matemáticas. Essa é a linha tênue entre o que desejamos e as razões concretas de uma não implementação. É o tipo de coisa que eu também me frustrava no passado, mas passei a entender com maior racionalidade.

Infelizmente no início da minha trajetória, eu já me prejudiquei muito aplicando as coisas que eu estava estudando com toda a euforia do mundo. Empolgação essa que impactou tanto os projetos, quanto minha capacidade de executar atividades que anteriormente eu desempenhava bem. 

Por fim, antes de adotar um método como seu, planeje e valide-o. Priorize o que é prol aos projetos e traz valor ao mesmo. Seja crítico, tenha um olhar sobre o impacto das suas sugestões sobre as pessoas envolvidas e muito cuidado com sobrecargas.