Estimativas imprecisas estão entre os desafios mais comuns do gerenciamento de projetos. Ao iniciar um novo projeto de TI, você quer saber duas coisas: quanto tempo vai levar e quanto vai custar. Para responder a essas perguntas, você deve estimar os projetos que está prestes a executar. Não existe uma regra mágica que diga que o projeto X leva 12 semanas e custa $150.000. Ou que um site do tipo Y leva 10 semanas para ser desenvolvido e custa $100.000.
O que você aprenderá com este artigo:
- Como os gerentes de projeto se preparam para a estimativa de custos no gerenciamento de projetos?
- Quais técnicas de estimativa são úteis para a estimativa de projetos?
- Como o planejamento é necessário para se preparar para estimar custos com fórmulas?
Não é possível avaliar o cronograma ou o custo de um projeto sem uma estimativa completa, mesmo que o escopo do projeto seja muito semelhante ao que você já fez antes. No entanto, as coisas pioram: a estimativa nunca lhe dará uma resposta 100% precisa para essas perguntas também. Então, por que fazemos estimativas? Porque essa é a única maneira de fazer suposições sobre o cronograma e o orçamento do projeto, a carga de trabalho e os recursos necessários para realizá-lo.
Ao estimar o projeto, você também pode programar funcionários com a experiência e o conjunto de habilidades corretos. O que você pode fazer a respeito disso é usar metodologias e técnicas que permitam estimar com a máxima precisão possível. Veja a seguir como usar a metodologia Agile e a técnica Planning Poker para criar estimativas significativas do seu projeto.
James Grenning desenvolveu a sessão de pôquer de planejamento conhecida por sua estratégia em 2002, chamada Scrum Poker. No início da década de 1950, seu método de estimativa, Wide band Delphi, consumia muito tempo e tinha outras limitações. No caso de Grenning, o plano de pôquer era originalmente para resolver um problema no qual os jogadores estavam muito entusiasmados e excessivamente concentrados para vencer. Mike Cohn, fundador das alianças Agile e das alianças Scrum, mais tarde usou essa técnica em um artigo intitulado Agile Estimation and Planning.
O início de um projeto bem-sucedido depende principalmente de sua compreensão do que realmente se trata. Isso inclui:
- Compreender as expectativas de seu cliente
- Compreender os objetivos do projeto e sua meta principal
- Criação de uma lista de recursos necessários
Depois de analisar o briefing do cliente e obter o máximo possível de informações sobre os requisitos do projeto, você poderá listar todos os recursos e passá-los para a sua equipe.
Para isso, crie um backlog do produto que consista em todos os recursos pendentes. Em seguida, você pode priorizá-los, avaliar sua complexidade e estimar quanto tempo levará para concluí-los. Um backlog de produto adequado deve ser composto por:
- Histórias de usuários - descrevem as ações que os usuários podem realizar em cada etapa do uso do produto
- Critérios de aceitação - lista dos itens necessários para que uma história seja concluída
- Pontos da história - estimar a quantidade de trabalho, os riscos e a complexidade no valor relativo de pontos
- Tarefas para histórias de usuários - liste as tarefas necessárias para entregar uma história de usuário
É fundamental envolver a equipe de desenvolvimento na criação e priorização do backlog do produto para garantir avaliações precisas e realistas.
Com uma lista de recursos pronta, atribua prioridade a cada um deles. Você pode usar o método de análise MoSCoW para classificá-los como:
- Deve ter
- Deveria ter
- Poderia ter
- Não terá
Ao desenvolver um projeto, concentre-se nas coisas que você precisa entregar em primeiro lugar. A criação de um MVP oferece a possibilidade de testar hipóteses sobre a sua ideia antes de concluir todo o projeto, mostrá-la às partes interessadas ou aos usuários beta e coletar feedback importante para o desenvolvimento do restante dos recursos.
A atribuição de prioridade também pode ajudá-lo a estimar o projeto. Ao se concentrar nos principais recursos e naqueles que precisam ser feitos primeiro, você pode fazer suposições mais precisas sobre a conclusão estimada. Para os recursos que "poderiam ter", você pode começar com uma estimativa aproximada, pois eles estão mais adiante no processo de desenvolvimento e muita coisa pode mudar até que sua equipe chegue a eles (e se sua equipe chegar a eles, pois depois de coletar feedback sobre seu MVP você pode mudar e não incluir todas as funcionalidades inicialmente planejadas).
No entanto, é importante estimar todos os recursos, independentemente de sua prioridade (exceto os que "não terão", é claro), pois você deseja obter uma visão geral de todo o projeto de uma só vez. E, à medida que você avança para os próximos estágios do projeto, pode reavaliar o escopo do trabalho para garantir que suas estimativas permaneçam precisas.
Agora que você tem o backlog do produto concluído, é hora de estimar cada um de seus itens. Para isso, usamos pontos de história. Eles são unidades que as equipes ágeis usam para avaliar o trabalho necessário para concluir cada item do backlog. Os pontos de história ajudam a atribuir valor relativo aos itens do backlog do produto. Eles não estão relacionados ao tempo e podem ter valores diferentes para equipes diferentes, portanto, não carregam o valor emocional. Assim, é provável que os membros da equipe não aumentem as estimativas apenas por segurança. O Planning Poker ajuda as equipes de software a planejar fluxos de trabalho e melhorar as taxas de entrega do projeto.
Usando pontos de história, uma equipe pode estimar:
A Sessão de Planejamento é uma das técnicas de estimativa de nível bruto, usando uma versão modificada da sequência de Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40, 100. Para estimar itens do backlog do produto, os membros da equipe recebem os mesmos conjuntos de cartas de pôquer de planejamento com números. Em seguida, após uma breve apresentação do item do backlog do produto pelo proprietário do produto (que não vota) e a discussão, eles escolhem, em particular, a carta com o número de pontos de história que consideram relevantes para a quantidade de trabalho necessária para concluir esse item e as revelam ao mesmo tempo.
Se os números forem diferentes, os membros da equipe discutem por que escolheram tal quantidade de pontos de história e votam novamente. Isso faz parte do processo de pôquer de planejamento, um método de estimativa baseado em consenso usado no Agile para estimar o esforço das histórias de usuários. Eles fazem isso até chegarem a um consenso e, em seguida, passam para o próximo item do backlog do produto. E se o número acordado for alto, digamos 20, 40 ou mais, isso significa que uma história pode exigir muito trabalho para um sprint e pode precisar ser dividida em tarefas menores. Idealmente, a apresentação do item, a discussão e a votação devem levar cerca de dois minutos, o que permite estimar todo o backlog em um curto espaço de tempo. Mas como o objetivo aqui é estimar todo o backlog de uma só vez, não tenha pressa e não se preocupe quando algumas histórias demorarem um pouco mais para serem avaliadas.
A velocidade da equipe mostra qual é o ritmo de desenvolvimento do projeto. Ela ajuda a entender duas coisas:
- A quantidade de trabalho que sua equipe é capaz de fazer em um sprint
- Qual é a data prevista para a conclusão de todo o escopo, supondo que ele seja fixo?
A velocidade é diferente para cada equipe. Você pode avaliá-la após as iterações iniciais, quando sua equipe já tiver trabalhado em alguns recursos. Por exemplo, se você incluiu quatro itens do backlog do produto na primeira iteração para um número total de 20 pontos de história, e a equipe concluiu três deles, o que equivale a 15 pontos de história, essa é a velocidade atual da sua equipe. Lembre-se de que somente os itens concluídos contam. Mesmo que a equipe tenha conseguido iniciar o quarto item, mas não o tenha concluído, ele não conta.
O scrum master desempenha um papel fundamental na facilitação do processo de estimativa e na garantia de avaliações precisas durante essas sessões.
Depois de negociar os pontos da história e avaliar a velocidade da equipe, você poderá determinar o cronograma do projeto. Para fazer isso, some a velocidade da equipe das três últimas iterações e divida-a por três. Por exemplo, se a velocidade dessas iterações foi 20, 23 e 17, a velocidade média seria igual a aproximadamente 20 pontos. Se a quantidade total de trabalho tivesse sido estimada em 100 pontos de história, então, com a velocidade média de 20 pontos, seriam necessárias 5 iterações para concluir o projeto. Supondo que uma iteração leve duas semanas, você deve entregar o projeto em 10 semanas.
Para determinar o orçamento do seu projeto, você pode usar esta fórmula básica: (total de pontos de história / velocidade * horas da equipe por sprint) + custos não relacionados à mão de obra = orçamento estimado. Com um número total de pontos de história dividido pela velocidade média, multiplique o número de sprints por 40 horas semanais por membro da equipe para obter o custo de mão de obra. Em seguida, adicione os custos não relacionados à mão de obra, como custos de capital, custos de equipamentos, custos de manutenção, custos de treinamento etc. Por exemplo, temos um projeto estimado em 100 pontos de história e a velocidade média da nossa equipe é 20. Atribuindo uma equipe de 5 pessoas ao projeto com taxas horárias de $50, as horas da equipe por sprint valem $20.000 e $100.000 para 5 sprints. Com um custo hipotético não relacionado à mão de obra de $50.000, o orçamento estimado para nosso projeto seria de $150.000. Considerando os intervalos de confiança em níveis exemplares de 80-120%, o intervalo informado de nosso orçamento agora é de $120.000 a $180.000.
Lembre-se de que nenhuma estimativa é 100% precisa. É melhor reestimar seu projeto a cada poucas iterações, pois coisas como disponibilidade de recursos, velocidade da equipe ou escopo do projeto podem mudar com o tempo. Ao refazer a estimativa, você se certifica de que ela está atualizada. O uso de software de controle de tempo e programação de recursos também o ajudará a gerenciar a disponibilidade da sua equipe e a reatribuí-la, se necessário. Com as técnicas e ferramentas certas, você pode tornar suas estimativas mais confiáveis e planejar melhor seu próximo projeto.
A estimativa precisa do projeto é fundamental para o sucesso do gerenciamento de projetos. Compreendendo as expectativas e os objetivos, criando um backlog detalhado do produto, priorizando recursos e usando técnicas como pontos de história e Planning Poker, você pode melhorar a precisão das suas estimativas. A reestimativa regular e o uso de ferramentas para controle de tempo e gerenciamento de recursos aumentam ainda mais a confiabilidade dos cronogramas e orçamentos do projeto. Seguindo essas práticas, você pode superar os desafios das estimativas imprecisas e garantir melhores resultados para o projeto.
Use a técnica de estimativa do Planning Poker com facilidade
Veja o motivo pelo qual nosso software de gerenciamento de recursos é escolhido pelos gerentes de projeto da Hill-Knowlton ou da Stormind Games
O planejamento eficaz de recursos é um objetivo crucial para empresas de todos os portes, independentemente de operarem on-line ou em setores tradicionais. Dada a grande variedade de empresas que exigem planejamento de recursos, é um desafio fornecer uma recomendação única para todos...
As empresas geralmente se esforçam muito na alocação de recursos. Você quer manter todos ocupados e, ao mesmo tempo, garantir que suas tarefas sejam valiosas (o que geralmente significa faturáveis) para a empresa. Isso se torna realmente complicado quando sua equipe...
Equipes de todo o mundo estão enfrentando desafios semelhantes quando se trata de planejar o cronograma de sua equipe. Criar um plano de projeto é difícil por si só, e mantê-lo atualizado e reagir às mudanças é ainda mais...