Estimar melhor um projeto: do cálculo ao trabalho real

Para melhorar suas estimativas de horas, compare a previsão que você guardou antes de começar com o esforço que exigiu esse mesmo trabalho ao terminar. Mantenha separados o que você subestimou, o trabalho adicionado e o tempo de espera. Se você misturar essas três coisas, um projeto que precisou de mais horas e outro que ficou bloqueado vários dias parecem o mesmo problema.

Defina o escopo no orçamento e diferencie correções de revisões antes de comparar as horas.

Guarde uma previsão que possa ser contrastada depois

A estimativa congelada é aquela que foi escrita antes de começar, junto com sua data, o entregável e as premissas utilizadas. Se você fizer uma nova previsão durante o trabalho, guarde-a como outra versão: não sobrescreva a referência inicial.

O esforço real do escopo original inclui correções de erros próprios, coordenação e a revisão acordada. Meça as horas ativas dedicadas a entregar todo esse trabalho. O esforço adicionado fora do escopo é registrado em outra coluna, sem apagá-lo do total trabalhado.

O tempo de espera mede horas de calendário em que esse projeto ficou bloqueado por um dado, uma aprovação ou um arquivo. Durante esse tempo, você pode ter trabalhado em outra coisa. Por isso, uma espera de 24 horas não equivale a 24 horas de esforço.

O guia de estimativa de custos GAO-20-195G inclui documentar escopo e premissas, coletar dados e atualizar estimativas com custos reais. Aqui, adaptamos esses princípios a um registro de esforço; o guia não valida os fatores nem os intervalos do exemplo freelance.

Oito projetos fictícios, dois grupos comparáveis

A tabela a seguir é inteiramente fictícia: é um exemplo calculado, não um registro de clientes reais nem uma amostra representativa de nenhum ofício. Serve para praticar o método, não para extrair uma taxa de erro típica do trabalho freelance.

Há dois grupos de quatro projetos cada um. Landing (landing_v1) supõe uma landing de 500-700 palavras com brief fornecido e uma revisão. Relatório (report_v1) supõe diagramar seis páginas com texto fornecido e uma revisão. Dentro de cada grupo, presume-se o mesmo processo e nível de experiência; as estimativas variam deliberadamente para mostrar erros em ambos os sentidos, para mais e para menos.

Todo o escopo original foi entregue nos oito casos; nada foi retirado. O adicionado são horas de trabalho extra fora desse escopo, registradas à parte: não são subtraídas da estimativa nem desaparecem do total trabalhado. Se em um registro real faltasse algo disso —parte do escopo retirado, horas misturadas ou um trecho sem anotação—, o correto não é assumir zero nem forçar um cálculo: é marcar essa comparação como não utilizável até ter uma base equivalente.

Onde você subestimou e onde não

Com E a estimativa inicial e A o esforço real do mesmo escopo, o desvio com sinal é A − E e o quociente é A / E, que exige E > 0. O desvio percentual é (A − E) / E × 100, sempre sobre a previsão como base.

L03 ilustra o caso mais marcado: 6 h previstas, 9 h reais, ou seja +3 h, quociente 1,5, +50%. Com as 3 h de alteração adicionada, esse projeto consumiu 12 h ativas no total. As 48 h de espera medem tempo de calendário: não se somam a essas 12 h nem permitem calcular uma data de entrega. Um projeto pode ter muita espera e pouco esforço, ou vice-versa.

L04 mostra o sentido contrário: 8 h previstas e 6 h reais dão −2 h, −25% e um quociente de 0,75. Isso descreve menos esforço do que o previsto; não demonstra por si só uma melhoria de qualidade ou produtividade. Primeiro é preciso verificar se todo o escopo foi entregue.

No resumo por grupo, as colunas de tempo medem horas ativas.

O total de 70 h ativas é uma soma de trabalho registrado, não uma duração de calendário: não incorpora o tempo de espera, que em um registro real poderia se sobrepor entre projetos distintos. Não use um único quociente desses totais para estimar trabalhos de natureza distinta: landing e relatório não são intercambiáveis.

Um intervalo da amostra para revisar o próximo projeto

Os quocientes de landing, ordenados, são 0,75; 1,1; 1,25; 1,5. Sua mediana é (1,1 + 1,25) / 2 = 1,175. Para uma nova estimativa inicial fictícia de 8 h de landing, a referência central resultante é 8 × 1,175 = 9,4 h, com extremos escalados de 8 × 0,75 = 6 h e 8 × 1,5 = 12 h.

Para relatório, os quocientes são 0,8; 1; 1,1; 1,2, com mediana 1,05. Sobre outras 8 h iniciais fictícias, a referência central é 8 × 1,05 = 8,4 h, com extremos entre 6,4 e 9,6 h.

Convém distinguir esta mediana de quocientes do quociente de somas do grupo landing: 36 / 32 = 1,125. O quociente de somas equivale a uma média dos quocientes ponderada pelas horas estimadas: um projeto de 10 h pesa mais que um de 6 h. A mediana ordena os quatro quocientes e faz a média dos dois centrais, sem ponderá-los por tamanho. Nenhuma das duas é “a correta” em abstrato: são medidas distintas e convém não apresentá-las como intercambiáveis.

Em uma apresentação de 2006 hospedada pelo PMI, Christine Green explica a utilidade de registrar esforço e características com definições consistentes, e de revisar a similaridade antes de reutilizar um histórico. É uma referência sobre estimativa de software, não um padrão atual do PMI nem uma validação desta fórmula editorial.

Quando esse histórico deixa de ser útil

O intervalo de 6–12 h para a landing apenas escala os extremos observados em quatro casos fictícios. É uma demonstração, não um intervalo de confiança, uma probabilidade de cumprimento nem uma garantia de esforço ou data. O próximo projeto pode ficar fora.

Este tipo de cálculo deixa de ser útil quando as condições que tornavam os casos comparáveis mudam: se o tamanho do projeto é muito diferente, se há mais ou menos contribuições por parte do cliente, se o processo interno mudou, se o nível de revisão acordado já não é o mesmo, se a experiência com esse tipo de tarefa é distinta, ou simplesmente se os dados disponíveis estão incompletos. Em qualquer um desses casos, não faz sentido aplicar o fator da amostra anterior de forma automática: é preciso investigar a diferença antes de assumir que o histórico continua sendo representativo.

O mais simples para começar a construir isso com dados próprios é registrar, desde já, a estimativa inicial congelada de cada novo projeto e, ao finalizá-lo, o esforço real do mesmo escopo, o adicionado separadamente e o tempo de espera separadamente, sem reescrever a previsão que já foi anotada no início.