Dúvidas e inquietações cotidianas que não estão nos livros – Parte 3: Alocação

Sem dúvidas a alocação é um dos temas mais complexos quando lidamos com projetos, isso porque as variáveis são muitas e cada estrutura organizacional funciona de uma forma e portanto necessita de adaptações para o seu meio a ponto de ser difícil dar uma resposta confiável sem cair no famoso “depende”. Nos artigos anteriores falamos sobre duas variáveis: precificação e times. Neste artigo vamos trazer alguns cenários e entraves referentes a alocação.

Como montar sprints caso o projeto possua prazo e escopo fixo? 

Basicamente, será preciso adaptar um pouco o conceito de sprints. Minha recomendação é que ao invés de planejar as sprints durante o projeto, acredito que o ideal é fazer todo o levantamento de backlog acordado no escopo fixo, ter dimensão das entregas e em seguida já separá-las por sprints, do início ao fim do projeto e em uma única vez. Feito isso, o time irá fazer o balanceamento das entregas dentro das sprints (o time é quem diz o que é possível entregar).

Tendo o escopo e prazo fixo como realidade, você irá perder muito do empirismo, descoberta de novos itens de valor durante o projeto, além da necessidade de replanejamento (tendo em vista que o que planejamos pode mudar, e vai rs), por outro lado, ainda assim você irá diminuir o microgerenciamento e a necessidade de colocar um deadline para cada atividade, o que faz total sentido tendo em vista que o atraso de uma atividade pequena e de pouca importância, pode muito bem ser contornada quando estão inseridas em pacotes de entrega. Isso evita um alarmismo desnecessário que não necessariamente é o principal risco e ponto de atenção do projeto.

Como fazer divisão de sprints, caso haja múltiplos projetos?

Aqui as coisas começam a complicar um pouco mais. Dentro do universo ágil muitas vezes os conceitos são muito associados (por mais que não cite) a realidade de produto, ou de grandes projetos de software, onde você possui um time fixo que trabalha nas demandas, evoluindo e aprimorando elas constantemente. Um excelente laboratório para o empirismo e melhoria contínua. Dessa forma seria muito mais simples de compreender como fazer a divisão de demandas, contudo em agências, por exemplo, o cenário de múltiplos projetos e limitação de times é uma realidade. 

Em um treinamento preparatório fiz este questionamento a um instrutor e conheci uma analogia com a chuva, muito interessante para explicar este contexto. No caso, ao invés de “fechar” um time para o projeto, o ideal seria inverter a lógica, para que os times resolvam problemas dos projetos. Neste caso, as demandas de diversos projetos caem como “chuva” sob os times. Veja abaixo:

Esse método faz total sentido para reforçar a ideia de que os times resolvem problemas , além de quebrar o excesso de especialização (um time só executa projetos do tipo X). Outro ponto é de que em uma divisão por projeto (ao invés do modelo acima), por mais que haja o nivelamento de conhecimento dos times, ainda assim acontece de determinado indivíduo do time “A” ser a única pessoa qualificada para resolver algo pontual do projeto do time “B”, logo os times deixam de ser times e são desmanchados organicamente e os projetos passam a ser divididos por indivíduos, o que gera microgerenciamento da alocação, que é algo muito similar em colocar deadlines por atividades ao invés de sprints. Quanto mais você categoriza, mais fácil de gerenciar.

Por outro lado, temos de ter cuidado com este modelo, pois transitar em mais de um projeto atrapalha o foco do time, gera excesso de comunicação e muitas pessoas diferentes colocam a mão no mesmo trabalho, podendo ocasionar problemas de qualidade. Dependendo do número de projetos e times, o ideal é fazer uma divisão por núcleos, contendo poucos projetos de forma que o volume de informação não seja imenso. Obviamente, o nivelamento do conhecimento, deve ser considerado por núcleo também, gerando uma complexidade maior para a montagem de times, mas resolvendo a questão das entregas.

E se o número de times for menor que o número de projetos?

Seria ótimo se sempre tivéssemos alocação a nossa disposição, contudo normalmente nem sempre isso é possível. Responder essa pergunta depende muito da estrutura de alocação dos projetos.

Em um exemplo hipotético onde se tenha 10 projetos para 8 times podemos visualizar algumas alternativas:

• 1 – Fila de espera: A primeira é 2 projetos ficarem em espera até que outros sejam finalizados. Percebam que neste caso, essa alocação não funcionaria caso os outros 8 projetos ficassem em constante iteração, gerando melhorias em ciclo.

• 2 – Backlog único contendo todos os projetos: A segunda opção seria utilizar a alocação “em chuva” (nome figurativo) que mostramos acima, que é capaz de gerar entrega para todos os projetos. Entretanto com os 10 projetos alocados simultaneamente, o volume de entregas no backlog por projeto, tende a ser bem menor, além dos problemas de foco e queda de qualidade que mencionei anteriormente. Neste caso, seguindo o virtuoso valor da transparência, o ideal seria dividir com o cliente o backlog semanal e o velocity do time, mas temos de encarar de que caso seu time esteja na “marcha lenta” por conta do alto número de projetos e baixo volume de entrega por projeto, quem está do outro lado da mesa pode não reconhecer esse valor ágil, além de não necessariamente colaborar. É neste caso que encontramos um tipo de ruptura comum no ágil: o cliente passa a querer “empurrar” as demandas e encher o backlog de uma maneira que o time não consiga corresponder as entregas de uma maneira saudável.

• 3 – Formação de mais time: Continuando com os cenários, outra opção possível é a contratação e montagem de time que é a solução ideal para não prejudicar as entregas e nem os indivíduos, contudo temos de ter serenidade, tendo em vista que é um processo longo e que dificilmente vai resolver seu problema de imediato.

• 4 – Freela: Muito parecido com o tópico acima, há também o famoso freela, que muitas vezes resolve o problema de imediato. Como GP, eu particularmente não gosto muito, pois perde-se um pouco o tato com o time, ponto crucial para alavancamento das entregas e tomada de decisões na hora da distribuição de demandas e decisões compartilhadas para o rumo do projeto.

Concluindo o assunto, e trazendo um pouco da minha opinião, a menos que os 10 clientes tenham comprometimento com a colaboração e entendimento do seu limite de cargas, acredito que o melhor cenário seja a “Fila de espera” de 2 projetos, pois dessa forma você conseguiria focar em 8 com qualidade, além de conseguir revelar com clareza um problema que não é de projeto, mas sim, de operação. Esconder a ferida irá fazer com que outras pessoas não vejam que o problema de fato existe, impossibilitando a resolução na raiz.

Apesar de delicado, vejo que este é uma questão que deve ser discutida de maneira mais aberta e clara por todos, até para que hajam mais discussões a fim de resolvê-lo ou mitigá-lo.

Por fim, finalizo este artigo de três partes com a intenção de que seja um daqueles textos que você lê e pensa “Isso acontece comigo!” e então sente uma sensação de pertencimento (risos). Espero também que possa deixar pistas de problemas na operação que são mais comuns do que imaginamos e não podem ser resolvidos com frameworks e métodos pré estabelecidos de mercado (apesar de ajudarem em muita coisa).

Até a próxima!