Na terceira semana de um ciclo de lançamento de seis semanas, sua equipe de software está travada. O gerente de produto precisa de uma data confirmada para uma demonstração ao cliente, o gerente de engenharia alerta sobre um pico de defeitos e a equipe de QA já está trabalhando à noite. Dois engenheiros estão alocados em três iniciativas cada um, o rodízio de suporte à produção constantemente os desvia de suas tarefas, e o designer está dividido entre duas squads. A decisão pendente parece simples no papel: manter a data e reduzir o escopo, manter o escopo e adiar a data, ou adicionar uma capacidade que, na verdade, você não possui. A cada dia de espera, o retrabalho aumenta e a confiança diminui. Este curso desenvolve os hábitos e cria os artefatos necessários para destravar a situação. Você aprenderá a identificar demandas ocultas de recursos em um cronograma, construir um modelo de capacidade que reflita a realidade de trabalho da equipe e usar IA para gerar opções negociáveis com os stakeholders.
O primeiro sinal não é o gráfico de Gantt. É o padrão de interrupções. Um engenheiro começa uma funcionalidade, é chamado para resolver um incidente de severidade 2 (Sev 2), volta para lidar com conflitos de merge e, em seguida, faz uma revisão de código às pressas para outro projeto porque está bloqueando um colega de equipe. O marco (milestone) atrasa, e a equipe compensa pulando testes. Uma semana depois, o número de defeitos aumenta, o QA vira o gargalo e a versão candidata ao lançamento (release candidate) sofre com retrabalho. O burnout surge na forma de tempos de ciclo mais longos, transferências de responsabilidade frágeis e mais tempo gasto solicitando atualizações de status do que executando o trabalho propriamente dito.
Um erro comum de gerentes de projeto (PMs) é tratar isso como um problema de execução. O instinto parece correto, pois é possível convocar mais reuniões diárias (stand-ups), apertar o controle no Jira e exigir mais foco. A consequência é que você aumenta a carga de coordenação sobre as mesmas pessoas que já estão sobrealocadas. O problema real é que o cronograma exige mais horas-pessoa — e nas semanas erradas — do que a equipe consegue fornecer sem comprometer a qualidade.
Ao alocar pessoas, você está resolvendo um problema de restrições, não apenas preenchendo lacunas. Escopo é o trabalho que você prometeu entregar. Cronograma é o prazo para a realização desse trabalho. Capacidade é a quantidade de horas de trabalho efetivo que a equipe pode oferecer por semana. Habilidades referem-se a quais pessoas podem executar quais tarefas sem riscos inaceitáveis. Premissas de disponibilidade são as regras implícitas — como escalas de sobreaviso, reuniões e solicitações de serviços compartilhados — que reduzem a capacidade.
Antes de decidir uma ação, identifique qual restrição é a que realmente limita a sua situação: cronograma, habilidades ou disponibilidade.
Isso é importante porque um mesmo sintoma pode ter causas diferentes. Na entrega de software, as limitações de competências costumam ser o fator dominante; por exemplo, apenas uma pessoa pode conhecer o pipeline de implantação. Em uma campanha de marketing, a restrição determinante pode ser o cronograma vinculado a eventos externos. Na implementação de operações de saúde, premissas de disponibilidade — como tempo de treinamento e cobertura de turnos — podem criar gargalos, mesmo quando o tamanho da equipe parece adequado. Sua função é identificar a restrição e escolher uma solução que a altere, em vez de uma que apenas aumente a pressão.
Não é possível equilibrar a alocação de recursos sem saber exatamente com o que você conta. Um modelo de capacidade é a sua estimativa explícita de horas semanais utilizáveis por função, descontando o tempo que não contribui para o avanço do projeto. Comece pelas horas nominais. Subtraia folgas (férias, licenças) e feriados. Subtraia reuniões fixas e cerimônias. Em seguida, aplique um fator de foco — a porcentagem do tempo restante que pode ser realisticamente dedicada ao trabalho planejado do projeto, levando em conta interrupções e atividades de coordenação. Por fim, subtraia o tempo destinado a serviços compartilhados, como suporte à produção ou solicitações internas que não podem ser ignoradas.
Utilize a ferramenta de criação para elaborar um plano de capacidade da sprint que inclua folgas e a carga de reuniões para cada função.