 |
TenStep PGP®
(V7.0) |
 |
|
Planejamento |
Gerenciamento |
2.2.1 Construir o
Cronograma e o Orçamento / Técnicas / Técnicas de Estimação
Técnicas para Estimativas
(2.2.1.P1)
Existem cursos
de capacitação focados especificamente em técnicas de estimativas.
Algumas destas técnicas são baseadas nas estatísticas avançadas e nas
formulas cientificas que na metodologia TenStep Processo de
Gerenciamento de Projetos ficam fora do escopo.
As seguintes técnicas
podem ser utilizadas em nível de projeto ou nível de atividade e em
qualquer lugar entre os dois. Por exemplo, um parecer técnico pode ser
utilizado para auxiliar na criação da estimativa de um projeto ou de uma
parte específica do trabalho. As técnicas para estimativas em um nível elevado
tipicamente referem-se as técnicas de "cima para baixo". As técnicas de
"cima para baixo" incluem Histórico, Analogia e Razão. As estimativas
que requerem melhor decomposição de trabalho são chamadas de “baixo para
acima”. Por exemplo, A técnica da Estrutura Analítica do Projeto (EAP) é
uma técnica de “baixo para acima”.
As técnicas de "cima para
baixo" tipicamente são mais fáceis e rápidas para se organizar e
utilizar. Normalmente, elas são menos precisas, exceto para estimativas
baseadas no histórico e na analogia dos projetos parecidos. Se possível
você deve utilizar múltiplas técnicas para estimar um projeto,
especialmente se você utilizar as técnicas de "cima para baixo".
-
Histórico Prévio:
Esta é sem dúvida a melhor maneira para calcular o trabalho. Se
sua organização documentar e arquivar as horas de trabalho de
projetos anteriores, você terá informações que o ajudarão a calcular
um novo trabalho. Com este método, as características do trabalho
anterior, juntamente com as horas de trabalho reais são armazenadas
em uma base de dados. Então você poderá descrever as características
do seu projeto e procurar para ver se um trabalho semelhante foi
executado no passado. Neste caso, você terá uma boa idéia do empenho
exigido para realizar seu trabalho.
-
Analogia: Mesmo
que você não tenha o histórico das horas reais utilizadas em
projetos anteriores, você ainda poderá alavancar o trabalho
anterior. Analogia significa que você procura projetos similares.
Não importa, se as características não forem exatamente as mesmas.
Descreva o seu trabalho e verifique primeiramente a base de dados da
sua empresa e interrogue a organização para ver se algum trabalho
semelhante foi realizado no passado. Em caso de não ter uma base de
dados interrogue a organização. Se você encontrar
alguma combinação, pegue as horas de trabalho que o projeto demandou
e utilize estas informações para criar as suas estimativas. Se a
organização não documenta as horas reais de trabalho do projeto,
descubra se há uma estimativa do esforço requerido e da duração das
mesmas. O gerente do projeto anterior não deve ter as informações
sobre o esforço real utilizado, mas deve ter informações sobre a
duração real do projeto.
Se a duração real bater a duração estimada, você poderá supor que as
horas do esforço também eram aproximadas. Por outro lado, se o
projeto ultrapassar 20% da duração estimada, você poderá concluir
que as horas do esforço também ultrapassaram 20%. Por exemplo,
deixe-nos dizer, um projeto prévio foi estimado para completar em
seis meses e com 2000 horas de esforço. Se o projeto realmente for
concluído em seis meses, há uma boa probabilidade de que o projeto
também utilize aproximadamente 2000 horas do esforço. Por outro
lado, se o projeto
exigiu
sete meses para conclusão, você pôde concluir que o projeto utilizou
mais ou menos 2300 horas.
-
Razão: A razão
é semelhante à analogia, exceto que você tem alguma base para
comparar trabalhos que têm características semelhantes, mas em uma
escala maior ou menor. Por exemplo, você pode descobrir que o
trabalho exigido para completar uma instalação de software no
escritório do Rio de Janeiro é de quinhentas horas e um dos grandes
motivos sobre o esforço requerido é o numero de pessoas que há no
escritório. Se existem duas vezes mais pessoas no escritório de São
Paulo, o que leva você a acreditar que poderá necessitar de mil
horas para instalar este software neste escritório.
-
Parecer Técnico:
Em
muitos casos você pode precisar de um perito interno ou
externo para obter ajuda para estimar o trabalho. Por
exemplo, se esta é a primeira vez que você vai utilizar
uma nova tecnologia, você poderá necessitar da ajuda de
uma empresa externa para lhe fornecer informações.
Muitas vezes, estas estimativas baseiam-se nas
experiências de outras empresas. Mas, você poderá
descobrir que já tem um perito interno na empresa que
tenha feito isto muitas vezes.
|
 |
-
Técnica Delphi:
A Técnica Delphi é semelhante ao Parecer Técnico, exceto que você
utiliza múltiplos peritos e tenta obter um consenso sobre as
estimativas entre eles. Primeiramente, identifique duas
(preferivelmente três) ou mais pessoas que você considere
especialistas no tipo de trabalho que você está avaliando. A seguir,
envie a eles as informações importantes que eles necessitam para
entender o trabalho. Eles devem lhe fornecer uma estimativa do
esforço requerido, juntamente com todas as Premissas, riscos, etc.,
que eles identificaram.
Se os números forem
relativamente próximos, você deve sentir-se à vontade para utilizar uma
média para sua estimativa final. Se as estimativas não forem próximas,
ou se algumas são próximas e outras não, envie todas as estimativas,
incluindo as Premissas e riscos, para os peritos revisarem. Peça aos
peritos que considerem as estimativas, riscos, Premissas, etc. dos
outros avaliadores. Então solicite a cada um deles que forneçam uma
segunda estimativa do trabalho. Possivelmente você encontrará várias
estimativas mais próximas, pois um perito terá a oportunidade de ver o
trabalho do outro perito. Com base em um conjunto comum de Premissas e
riscos, os peritos podem alcançar um consenso sobre as estimativas, caso
contrário, você pode analisá-las para ver se a maioria das estimativas
são semelhante e utilizar este número. Você também poderá necessitar
documentar um risco de estimação em relação aos peritos que não chegaram
a um consenso. Por exemplo, se três peritos estimaram um trabalho de
cerca de mil horas, mas um perito defende a idéia de que o trabalho é de
duas mil horas, você pode seguir o consenso de mil horas com um risco
declarado de que poderá necessitar de até duas vezes mais horas para
completar o trabalho, com base no parecer de um dos especialistas.
Uma
segunda opção, se você tiver tempo e inclinação, é pedir mais opiniões a
outros peritos. Isto lhe dará mais confiança se as estimativas dos novos
peritos forem próximas ao número do consenso, e menos confiança (e mais
risco) se as estimativas novas não se aproximarem ao número do consenso.
Os cenários acima são exemplos de o que pode acontecer quando
múltiplos peritos dão suas opiniões. A técnica Delphi utiliza
múltiplos
peritos e então fornece uma orientação sobre como fazer se os
peritos não concordarem.
-
Estrutura
Analítica do Projeto (EAP). A metodologia TenStep para
construção de um Cronograma (no
Passo 2.1 - Construir o Cronograma e o Orçamento /
Processo) discute a decomposição do
trabalho em partes cada vez menores. Um dos objetivos da EAP é poder
estimar o trabalho com mais facilidade. Você pode olhar para uma
parte grande do trabalho e ter dificuldade em determinar uma
estimativa do esforço requerido. Porém, com o trabalho decomposto em
atividades menores, os componentes individuais serão mais fáceis de
estimar. Depois que você estimar todas as atividades, junte-as para
obter uma estimativa total. Se você tiver tempo para criar uma boa
EAP, normalmente você terá uma boa estimativa. Se você utilizar
múltiplas técnicas para criar as estimativas, uma delas deve ser a
abordagem do EAP.
-
Estimativa de Três Pontos (ETP):
ETP é uma técnica para estimação que utiliza uma média ponderada de
três números para propor uma estimativa final. Se for solicitada uma
estimativa de um projeto ou atividade, você inicia com três
estimativas – o caso mais pessimista (P) será quando tudo dá errado,
e o mais otimista (O) quando tudo dá certo e o mais provável (M),
dado a problemas e oportunidades normais. A estimativa ETP
resultante é (O + 4M + P)/6. Por exemplo, você avalia uma parte do
trabalho que provavelmente levará 10 horas, o melhor caso (tudo dá
certo) é 6 horas, o pior caso (tudo dá errado) é 26 horas.
Utilizando a estimativa ETP, onde O = 6, M = 10 e P = 26, obtém-se
a seguinte equação: (6 + 4(10) + 26)/6. A resposta é 72/6, ou 12
horas. Veja que o número foi levemente “puxado” para a extremidade
da estimativa pessimista, pois no resultado ainda pesa muito o valor
mais provável.
-
Modelagem de
Paramétricas: Nesta técnica, existe um padrão no trabalho que
permite a você utilizar um algoritmo para direcionar a estimativa.
Por exemplo, se você souber que pode construir um quilômetro de
rodovia de uma pista por um milhão de reais, você deverá poder
calcular facilmente uma estimativa para dez quilômetros de rodovia
com quatro pistas (quarenta milhões de reais). Ou, se lhe pedirem
que você crie quarenta relatórios novos, primeiro estime o esforço
para um relatório médio (talvez a média entre um relatório pequeno,
médio e grande), então, multiplique o resultado por quarenta para
obter a estimativa final.
Timeboxing. Esta é uma maneira para estabelecer uma das
estimativas para estar dentro de um determinado parâmetro.
Normalmente, isto pode ser realizado através da focalização em um ou
ambos dos outros parâmetros da "Restrição
Tripla". Geralmente quando você aplica a técnica Timeboxing,
você está forçando o projeto a terminar em uma determinada data.
Então, você tem que focalizar nos outros parâmetros "Custo" e
"Escopo" da Restrição Tripla de modo que a data possa ser alcançada.
Por
exemplo, vamos dizer que você cria um cronograma e baseado no
seqüênciamento das atividades, o projeto necessitará de nove meses
para ser completado. Entretanto, o seu patrocinador diz que o
projeto deve ser completado de sete meses. O prazo indicado pelo
patrocinador transforma-se no "Timebox" o qual o projeto deve ser
terminado. Para bater este prazo, você poderá necessitar de recursos
adicionais para facilitar a habilidade de executar algumas
atividades em paralelo, que originalmente foram programadas para
serem executadas em seqüência. Este é um exemplo de situações que
aumentarão o custo final do projeto. Se você não tiver aprovação
para ajustar o orçamento, para alcançar o "Timebox", você poderá ter
que eliminar algum detalhe do escopo do projeto. Normalmente, para
alcançar um "Timebox", você necessita aumentar o custo, diminuir o
escopo ou talvez uma combinação de ambos.
-
Pontos de Função.
Algumas organizações de desenvolvimento de TI utilizam pontos de
função como meios para fornecer estimativas do trabalho requerido
para concluir um projeto de desenvolvimento de um sistema. Os pontos
de função fornecem um mecanismo para determinar a complexidade
relativa de uma aplicação. A complexidade pode ser expressada como
uma contagem de pontos de função. Desta maneira, uma aplicação de
1000 pontos de função é geralmente dez vezes maior e mais complexa
do que uma aplicação de 100 pontos de função.
Começar sem muitos detalhes, os pontos de função avaliam o tamanho de
uma aplicação em uma perspectiva do usuário. Os usuários olham
relatórios, telas, e talvez arquivos de dados. Também vejam a
funcionalidade do negócio, as interfaces as outras aplicações, as bases
de dados, as tabelas, etc. Faz sentido que uma aplicação com oitenta
(80) telas e vinte (20) relatórios seja provavelmente maior do que uma
aplicação com vinte (20) telas e cinco (5) relatórios. Esta maneira de
ver o tamanho é independente da língua de desenvolvimento e da
tecnologia. De fato, uma aplicação com um número menor de telas pôde
requerer mais linhas de código, mas isto não é mais relevante nos
cálculos do tamanho.
Nos
primeiros estágios do processo de planejamento, você não pode utilizar a
técnica ponto de função para criar as estimativas. Entretanto, uma vez
que você souber o número de telas, de relatórios, de interfaces, de
transações, etc., você pode criar uma estimativa em um nível elevado dos
pontos de função. Uma vez que você obteve experiência em contagem de
pontos de função em alguns projetos anteriores, você começará a ver o
esforço médio requerido para concluir um ponto de função. Após
isto, somente aplique as matemáticas para determinar o esforço total
requerido, seguido pela duração e o custo.
Estimar em Fases
(2.2.1.P2)
Um dos aspectos mais
difícil nas estimativas dos projetos é quando você não saber exatamente
qual atividade ou trabalho será realizado no futuro. Pode ser muito
difícil definir e estimar atividades programadas para começar somente
após três meses, e mais difícil ainda estimar atividades programadas
para começar somente após seis ou nove meses. A principal razão disso é
que as decisões tomadas e as entregas produzidos anteriormente,
podem ter um impacto positivo ou negativo nas atividades futuras. Com
isso, quanto mais longo for o prazo para iniciar uma tarefa, mais riscos
serão introduzidos.
A melhor abordagem para
projetos grandes é fracionar os trabalhos em uma série de projetos
pequenos. Cada projeto pequeno poderá então ser planejado, estimado e
gerenciado com maior chances de sucesso (Para melhores detalhes sobre
este assunto veja a sessão
1.2 Definir Tarefas / Técnicas - Fracionar Projetos Grandes em Projetos
Pequenos e
gerenciar como um programa).
Na perspectiva da
estimação, o primeiro projeto pode ser estimado com maior precisão e os
projetos subseqüentes em um nível elevado. Quando um projeto for
completado, o próximo projeto poderá ser estimado com um grau maior de
confiança e estimativas redefinidas para os projetos restantes. Esta
técnica também fornece pontos de checagem (Marcos) ao final de cada
projeto, fazendo com que toda essa iniciativa possa ser revalidada,
baseada nas estimativas atuais e para validar que o programa continua
viável.
Estimando Custos Fixos e Variáveis
(2.2.1.P3)
|
Você poderá ouvir falar nos
termos “custos fixos e variáveis” quando estiver estimando um projeto.
Custos variáveis são aqueles que variam relativamente ao número de
unidades utilizadas. O custo variável mais óbvio em um projeto é o de
contratação de mão-de-obra. Quanto mais horas você alocar de um
contratado, mais custo terá o seu projeto. È importante compreender os
custos fixos e variáveis para o seu projeto e o impacto no projeto
quando você acrescentar ou diminuir as horas dos contratados. Muitas
vezes, os custos dependem de recursos específicos, por exemplo: Um
funcionário interno efetivo pode ter um custo hora de R$ 50,00 (mais
benefícios) e um contratado temporário similar pode ter um custo hora de
R$ 90,00. |
 |
Os custos fixos
basicamente não alteram, ou seja, valores “fixos” não importando os
recursos que estão sendo utilizados no projeto. Por exemplo, se você
está construindo uma casa, os custos relacionados ao material como
tijolos e concreto serão os mesmos quando o projeto for aprovado pelo
contratante e o contratado. Se você terceirizar uma parte do seu
projeto, por um preço fixo, a um contratado, este custo se tornará um
custo fixo dentro do projeto (Não importando se o trabalho terminará
dentro ou fora do prazo estimado, porque o custo aprovado entre o
contratante e o contratado antes de iniciar os trabalhos do projeto é
fixo).
Estimando Atividades Classificadas como Recurso Restrito
ou Tempo Restrito
(2.2.1.P4)
As atividades ou tarefas
podem ser classificadas como “Tempo Restrito” baseado no fato da duração
da atividade poder ou não, mudar, através da alocação de recursos
adicionais. Uma atividade é classificada como “Recurso Restrito” se a
duração variar baseada no número de recursos aplicados. Por exemplo,
você estima duzentas horas para uma pessoa construir o telhado da sua
casa, se esta pessoa trabalhar quarenta horas por semana, o trabalho
deverá ter uma duração de cinco semanas para ser concluído. Se você
colocar duas pessoas neste trabalho, o esforço continua sendo de
duzentas horas, mas a tarefa levará duas semanas e meia para ser
concluída. Se houvessem cinco pessoas trabalhando nesta tarefa, esta
levará uma semana para ser concluída (O tempo da atividade não cai tão
proporcionalmente como apresentado acima, mas este trabalho poderá ser
feito no total de oito dias). Uma atividade é classificada como “Recurso
Restrito” se a duração for baseada na quantidade de recursos que podem
ser utilizados nesta atividade. O restrição é baseada na quantidade de
recursos e não no tempo.
Por outro lado, se a
atividade é de “Tempo Restrito” a duração continua a mesma não
importando a quantidade de recursos aplicados. Por exemplo, se você
cursar um dia de aula, a atividade terá uma duração de oito horas, se
duas pessoas cursarem a mesma aula, o tempo do curso será as mesmas
oito horas. A mesma coisa acontece com o tempo que leva para um concreto
secar, ou enviar uma carta. O tempo destas atividades não tem a ver com
a quantidade de pessoas envolvidas, elas apenas alocam uma certa
quantidade de tempo. Se você achar que aplicar os recursos adicionais
não possui nenhuma influência na duração do projeto (ou pequena
influência), então esta atividade é de “Tempo Restrito”.
Inclua o Tempo de Reuniões do
Projeto e os Encontros Colaborativos na Estimativa do Projeto
(2.2.1.P5)
Tipicamente, as reuniões
da empresa e dos departamentos não estão sob seu controle e também não
são contabilizadas no cronograma ou nas estimativas do
projeto.
Estes encontros poderão ser contabilizados nas estimativas de
duração se você utilizar um fator de um número reduzido de horas
disponíveis por dia para cada recurso (exemplo; 6.0 ou 6.5 por dia). No
caso onde as reuniões departamentais são agendas de forma fixa
(Semanalmente ou mensalmente), você poderá incluir estas reuniões no
cronograma. Este tempo poderá não impactar o orçamento do projeto, mas
impactará o cronograma do mesmo.
Por outro lado, reuniões
que são relacionadas ao projeto deveriam ser incluídas no Cronograma e adicionadas nas estimativas de esforço
e custo do projeto,
porque estes tipos de reuniões estão sob o controle da equipe do
projeto. O Gerente do Projeto pode marcar estes encontros para ser
realizado com a duração de uma hora, em uma base quinzenal, ou diária.
Da mesma forma, tente
contabilizar o tempo total requerido para todos os participantes em
reuniões colaborativas. Por exemplo: Se você estiver planejando revisar
todas as entregas (walkthroughs), assegure-se de que você incluiu o
tempo de todos os participantes. Quando estiver circulando os documentos
para aprovação, inclua também algum tempo de revisão que será necessário
para cada participante envolvido. Se você estiver planejando fazer
reuniões no final de cada Marco, tenha certeza de incluir o tempo
para cada participante.
Inicie com uma Margem para sua Estimativa
(2.2.1.P6)
Muitas vezes você é
solicitado a fazer uma estimativa em um nível elevado para um projeto ou
para uma atividade de trabalho individual. Normalmente lhe pedem para
produzir um número, por exemplo, 1000 horas. Porém, se possível, todas
estas estimativas em nível elevados deveriam ser fornecidas dentro de
uma margem. Esta margem refletirá o nível de incerteza da estimativa.
Por exemplo, uma estimativa em nível elevado poderia ter uma margem de
precisão de + ou - 50%. Em nosso exemplo anterior de 1000 horas, o que
você poderia dizer ao invés é que o trabalho provavelmente levará entre
500 e 1500 horas. Uma outra maneira de dizer a mesma coisa é dizer que
você estimará o trabalho em 1000 horas, mais ou menos 50%. Se existir
muita incerteza em relação à estimativa, você poderá até mesmo dar uma
margem de erro de +/- (mais ou menos) 100%. Porém, o objetivo de
fornecer a margem é auxiliar no gerenciamento das expectativas. Se você
disser que o trabalho estimado é de 1000 horas, provavelmente este será
o número ao qual você terá que se prender. Devido as informações que
você conhece, este poderia ser um número difícil de alcançar. Se você
fornecer uma margem de estimativa, você terá uma probabilidade muito
maior de entregar o trabalho dentro da estimativa, e você terá uma
maneira de mostrar o grau de incerteza nos números.
|
1 Sigma –
68% de Precisão |
2 Sigma –
95% de Precisão |
|
3 Sigma –
99,7% de Precisão |
6 Sigma –
99,9999% de Precisão |
|
 |
|
Maior
precisão na estimativa, maior margem de estimação. |
Estimando os Riscos - Modelo de Monte
Carlo
(2.2.1.P7)
Uma das maneiras de você
reconhecer a incerteza em suas estimativas é acrescentar um fator de
contingência. A reserva para contingência é aumentada quando reconhecemos uma maior
incerteza no entendimento daquilo que estamos estimando. Para a maioria
dos projetos pequenos e médios, acrescentar uma reserva de contingência razoável é
perfeitamente válido, e deve lhe dar uma estimativa final daquilo que
você pode alcançar.
Porem para projetos
maiores, há técnicas mais poderosas disponíveis para reconhecermos os
riscos associados com as estimativas. A mais comum é o modelo de Monte
Carlo. O modelo de Monte Carlo inicia mais ou menos como a técnica de
Estimativa de Três Pontos (ETP).
Mas, ao invés de dar uma estimativa para a duração de uma atividade, por
exemplo, você fornece uma série de estimativas que representam o melhor
caso, o caso mais provável, e o pior caso. Para cada um destes casos,
você atribui também uma probabilidade. Por exemplo, pode haver uma
chance de 10% de atingir a estimativa de seu melhor caso, uma chance de
80% de atingir a sua estimativa provável e uma chance de 10% do trabalho
atingir o pior caso. Em outras palavras, tem uma chance cumulativa de
90% da atividade ser concluída dentro do cenário provável (10% + 80%) e
uma chance cumulativa de 100% do trabalho ser feito segundo a estimativa
do pior caso (10% + 80% + 10%). Você não precisa determinar a
probabilidade percentual dos pontos intermediários – somente estes três
pontos. (Tecnicamente, você poderá fornecer estimativas para algumas ou
todas as probabilidades.)
Então, você deve ter
preparado essas três estimativas para cada atividade principal no
Cronograma. Por exemplo, No caso mais provável, você pode
estimar uma atividade de 60 horas, nos casos mais otimistas de 50 horas
e nos piores casos de 90 horas. Essas três estimativas podem necessitar
ser preparadas para dezenas (ou centenas) de atividades no Cronograma.
Quando você terminar, a
maioria das ferramentas do Cronograma tem a função de
executar uma simulação de Monte Carlo. Basicamente, a simulação modela
como o projeto progredirá, e alcançará a data estimada para o final. O
cronograma é traçado novamente, desta vez utilizando
probabilidades diferentes, e calculando uma data diferente do término. A
razão pela qual o modelo é executado muitas vezes é para que os
percentuais de risco tenham uma chance de acabarem. Por exemplo, em
nosso exemplo acima, se a simulação fosse executada 100 vezes, você
deveria esperar que cada atividade atingisse o melhor caso 10 vezes
(10%), o pior caso 10 vezes (10%) e o caso esperado 80 vezes (80%). Como
as ferramentas de modelagem escolhem aleatoriamente os valores
calculados com base em probabilidades, muitos cenários de projeto
diferentes acabam. Contudo, um padrão básico que surge lhe permite
projetar a data em que seu projeto provavelmente será concluído. Isto
normalmente é feito buscando-se o limiar onde o projeto termina em 80% -
90% das vezes.
Embora o exemplo acima
utilize riscos associados ao cronograma, você também pode utilizar esta
técnica para fornecer estimativas dos custos e do empenho. O bom sobre a
Simulação de Monte Carlo é que se você fornecer estimativas de
atividades em margens, a maioria das ferramentas executarão todos os
cálculos estatísticos automaticamente. Você só precisa ter certeza de
que forneceu estimativas válidas e razoáveis para as atividades. Você
pode ver que o trabalho extra exigido durante o processo de avaliação,
fez deste um modelo para ser utilizado em projetos que são muito
grandes, ou aqueles que contêm um risco muito grande. Projetos pequenos
e médios provavelmente não achariam valor nesta técnica.
Erros Comuns
Cometidos na Criação das Estimativas
(2.2.1.P8)
O processo de estimação é uma arte e uma
ciência. Entretanto, uma vez que você aprende bons processos e técnicas
de estimação, você poderá mover-se mais para o lado da "ciência" e
confiar menos no lado da "arte". Você nuca será perfeito na criação das
estimativas, mas pode evitar os erros comuns cometidos na criação das
estimativas. Veja abaixo uma lista dos erros que freqüentemente são
cometidos.
-
Não contabilizar todo o trabalho. Este é um problema comum,
principalmente com estimativas em nível elevado. Por exemplo, pode
passar despercebido algum trabalho importante que você não
compreendeu como uma parte do projeto, tal como a documentação ou o
treinamento. Entretanto, tipicamente você subestima o tamanho das
entregas que necessitam ser completadas ou não inclui todas as
atividades requeridas para completar a entrega.
-
Criação ilusória.
Qualquer pessoa que já forneceu estimativas de trabalhos sabe, que
poderá haver uma certa pressão por parte do cliente para que uma
estimativa seja a mais baixa possível. Afinal, o cliente quer
receber o que ele necessita com pouco esforço e com o menor custo
possível. Em muitos casos, também há uma tendência da parte do
estimador em deixar se levar e pensar da mesma forma. No final o
estimador "reza" para que o trabalho seja completado dentro das
expectativas do cliente.
-
Comprometer o
cenário do melhor-caso. O cliente quer o trabalho concluído o
mais rápido possível. O seu gerente quer o mesmo. Você acha que o
trabalho poderá ser concluído rapidamente. Entretanto, você
encontrou-se em dificuldades, porque você pensou somente no que
faria para concluir o trabalho se tudo desse certo. Você poderá ter
pensado em uma escala do esforço para o trabalho (otimista, mais
provável e pessimista), mas então no melhor dos casos você
comprometeu a estimativa mais baixa, ou mais otimista na extremidade
da escala.
-
Assumir um nível
qualidade maior do que você pode entregar. Este problema inclui
as estimativas baseadas em construir em um determinado nível de
qualidade na primeira vez. Entretanto, depois que o projeto começa a
ser executado, você descobre que a sua habilidade de construir em um
nível elevado da qualidade na primeira vez é limitado, tendo por
resultado o retrabalho, os reparos de erros, etc.
-
Comprometer-se
baseado no orçamento disponível.
Neste caso, o cliente tem uma
quantidade fixa disponível para o orçamento. O gerente do projeto
acha que há uma possibilidade de completar o trabalho dentro do
orçamento disponível, assim ele se compromete baseado nesse número.
Este é similar ao problema mencionado acima de “Comprometer o
cenário do melhor-caso”.
-
Não reconhecer os
preconceitos de estimativas. Os preconceitos de estimativas
sempre entram no processo de estimação. Alguns deles são otimistas e
outros são pessimistas. Os preconceitos otimistas resultam em
subestimar o trabalho e podem incluir:
-
Tendências para
pensar que o trabalho é simples.
-
Tendências para
pensar que sua equipe pode realizar mais do que ela realmente
pode.
-
Não contabilizar
os riscos do projeto, das incidências problemáticas, da má
comunicação, etc.
-
Tendência para ser
otimista.
Os preconceitos
pessimistas resultam em superestimar o trabalho e podem incluir:
-
A má
experiência em um projeto similar no passado.
-
Não desejar
realmente fazer o trabalho. Você superestima e espera que o
projeto seja cancelado.
-
Tendência para ser
pessimista.
Todas as pessoas têm
preconceitos. A chave é reconhece-los e ir contra os mesmos quando estes
surgirem. Isso lhe ajudará a preparar estimativas mais válidas e mais
corretas possíveis.
Validar uma Estimativa Velha Quando
uma Equipe Nova Estiver no Local
(2.2.1.P9)
Normalmente, uma equipe de
projeto é formada para definir o projeto, construir o Cronograma, e então executar o projeto. Porém, às vezes, o empenho e a
duração de um projeto são estimados muito cedo, talvez porque a
informação seja necessária como parte das finanças anual da organização.
Nestes casos, uma outra equipe poderá ser formada e solicitada para
entregar o trabalho baseado nas estimativas criadas anteriormente. Se
isto acontecer, uma das primeiras tarefas da nova equipe do projeto é
validar as estimativas. Ninguém deseja estar em uma situação de ter que
entregar algo dentro das estimativas de outra pessoa. Se você não
validar e desafiar as estimativas cedo, a expectativa é que você aceitou
as mesmas. O gerente do projeto deve desafiar as estimativas cedo. Se
você concordar com as estimativas, muito bom. Se você não concordar,
esta é a hora para erguer a bandeira vermelha. Isto é melhor para você e
também para a empresa. Por exemplo, você poderá descobrir que se sua
nova estimativa é mais alta, a analise dos custos vs. benefícios do
projeto já não fazem mais sentido. Novamente, é melhor descobrir isso
antes do que depois.
Decidir se Você Deverá Incluir os
Custos e o Esforço do Cliente
(2.2.1.P10)
Esforço do cliente inclui o tempo para
revisar e aprovar as entregas, fornecer exigências, participar de
reuniões, de treinamentos, etc. Algumas empresas querem entender o
esforço e o custo total de um projeto, incluindo a equipe do projeto e o
cliente. Em algumas empresas, os custos dos projetos incluem somente as
equipes diretas dos projetos. Assim, incluir horas e custos dos clientes
em sua estimativa é uma área que você deverá discutir com o seu gerente
e com o patrocinador. Se a sua estimativa incluir horas e custos do
cliente, estas horas deverão ser mantidas separadas. Embora o número
combinado forneça uma estimativa global melhor, o gerente do projeto
normalmente não é responsável pelos recursos do cliente e, assim, não
deverá ser responsabilizado pelo fato de alcançar ou não estas metas
particulares.
Esteja Preparado se o
Cliente Disser que a Estimativa é Muito Alta
(2.2.1.P11)
Depois de preparar sua estimativa, você poderá precisar defendê-la se o
cliente pensar que os números são muito alto. Você terá que ser capaz de
defender sua estimativa explicando as técnicas de cálculo utilizadas, o
processo seguido, e as Premissas que você fez. Se o cliente ainda pensar
que os números são muito alto, ou não pode dispor da solução com esse
custo, existe outras opções:
-
Determine
se o cliente tem
qualquer informação
adicional que lhe
permita revisar suas
Premissas e talvez
revisar a estimativa.
Por exemplo, se a data
final do projeto tiver
um pouco de
flexibilidade, talvez a
estimativa possa ser
revisada com base nessa
nova informação.
Determine
se pode ser reduzida
algumos requisitos e
funcionalidade em um
nível elevado. Em muitos
casos, o conjunto
inicial dos requisitos é
mais do que uma lista de
desejos. Após ver uma
etiqueta de preços, é
possível que o cliente
possa viver sem
determinadas
características.
Se você
incluiu uma Reserva de
contingência alta para
refletir um risco
elevado da estimativa,
solicite ao cliente mais
tempo para obter mais
detalhes para atualizar
a estimativa. Isso
poderá resultar em menor
incerteza e riscos e
permitir que você
reflita isso com uma
Reserva de contingência
menor.
Reestruture o projeto
para incluir somente a
fase de análise
detalhada. Após a fase
de analise ser
completada, reestime o
resto do projeto baseado
na confirmação daquilo
que realmente foi
solicitado. O empenho e
o custo total podem ou
não ser menor, mas no
mínimo, você terá mais
informações detalhadas
para defender suas
estimativas.
Utilize
um Pacote de Informações para
dar Suporte a Suas Estimativas
(2.2.1.P12)
Na próxima vez que você for
solicitado para fornecer uma
estimativa para uma parte
principal de um trabalho,
considere a apresentação de
um pacote de informações.
Não necessita ser um
documento muito extenso. É
somente para mostrar o rigor
que você utilizou. Você deve
considerar esta abordagem
principalmente se o trabalho
for político de natureza, ou
se você achar que sua
estimativa não será aceita.
Ao invés de fornecer somente
um número final, ou uma gama
de números para sua
estimativa, forneça as
seguintes informações.
A estimativa
do esforço do trabalho (de
duração e custo, se
aplicável).
A informação
detalhada da estimativa para
o caso da pessoa que a
receber querer revisá-la.
Por exemplo, se você fez uma
Estrutura Analítica do
Projeto (EAP), você pode
incluir suas estimativas
detalhadas do trabalho.
As Premissas
que você fez durante o
desenvolvimento da
estimativa.
O nível de
incerteza nos números, o
qual se reflete na reserva
de contingência ou no
tamanho da gama da
estimativa. (Quanto mais
ampla a gama, mais a
incerteza é refletida).
Este seria um poderoso pacote de
informações para ser fornecido ao solicitante. Se houver discordância na
sua estimativa, os fatos dirão. Muitos desafios também cessarão, porque
as pessoas terão dificuldades para desfiar seus fatos. Podem lhe pedir
que mude suas Premissas, ou que tente outras técnicas de estimativa.
Estas são solicitações legítimas e você pode reestimar com base nestes
novos critérios. Mas, pelo menos, os desafios são em termos do processo
de estimação, e não encima do fato de você ter feito ou não um trabalho
ruim.
Fazer
Estimativas baseado no Entendimento do Nível de Exatidão
Requerido
(2.2.1.P13)
Normalmente, dependendo de quando a estimativa é solicitada, o cliente
espera diferentes níveis de exatidão nas estimativas do gerente do
projeto (ou da equipe do projeto). Por exemplo, quando um projeto é
proposto a primeira vez, o cliente poderá solicitar uma estimativa, em
um nível elevado de esforço, de custos e de duração. Neste ponto, o
projeto é vago e a estimativa também será vaga. Em muitos casos, a
estimativa é utilizada somente para determinar o tamanho do projeto, de
modo que o cliente tenha uma compreensão sobre a quantidade de trabalho
que será requerido. Por exemplo, o projeto necessitará de 1000 ou de
100.000 horas de esforço. Este é um tipo de estimativa grosseira
(Inglês: Rough Order of Magnitude) e poderá estar na escala de -50% a
+100%. Ou seja, se a estimativa preliminar do trabalho for de 1000 horas,
você poderá propor a estimativa grosseira (ROM) de 500 a 2000 horas.
Normalmente, quando o projeto chega ao meio do processo de aprovação, o
estimador torna-se mais informado sobre as expectativas e sobre as
entregas, isso permite que as estimativas se tornem mais precisas.
Quando o projeto estiver sendo proposto em termos de financiamento, você
deverá estimar com maior precisão, talvez -15% a +25%. Ou seja, se sua
estimativa for de 1000 horas, você poderá propor uma escala de 850 a
1250 horas.
Após
ter definido o trabalho e construído o Cronograma e orçamento
formalmente, o gerente e a equipe do projeto deverão revalidar a
estimativa. Agora, a estimativa resultante deverá ser mais próxima de
-10% a +15%. Ou seja, se a sua estimativa final para o esforço for de
1000 horas, você deverá sentir que realmente poderá entregar o projeto
dentro de 900 a 1150 horas.
|
ESTIMATIVA |
PRECISÃO |
FINALIDADE |
|
ESTIMATIVA
GROSSEIRA (ROM) - (CONCEPTUAL) |
-25% a +100% |
Avaliação dos
projetos ou alternativas |
|
PRELIMINAR
(ORÇAMENTO) |
-15% a +25% |
Estabelecer
o orçamento inicial, reservar capital para o projeto |
|
DEFINITIVO |
-10% a +15% |
Estabelecer
o orçamento atual do projeto – Após a definição do projeto |
Estimando a
Necessidade para uma Reserva de Recursos
(2.2.1.P14)
Se
possível você deve solicitar um orçamento de reserva para contingência para ir contra
a incerteza em suas estimativas do orçamento e da duração do projeto.
Você poderá necessita descrever e documentar um plano para executar esta
reserva de contingência, incluindo quais e quando os recursos serão requeridos. Por
exemplo, Recursos de mão de abra, ferramentas, equipamentos, hardware,
software ou as fontes, etc.
Há
inúmeras razões para planejar antecipadamente uma reserva de recursos.
-
O tempo é a essência.
Em um projeto típico, se você descobrir que o trabalho está
utilizando mais tempo do que o antecipado, você solicitará tempo e
orçamento adicional. Entretanto, se a data final do projeto for fixo
e não puder ser movida, você poderá não ter o tempo necessário para
procurar recursos. Você poderá necessitar um plano que explica onde estão
os recursos e como adquiri-los. Por exemplo, deixe-nos olhar os
projetos sobre o assunto do “Ano 2000” (Y2K). Se o projeto estiver
entrando nos últimos seis meses de 1999 e houver muitos trabalhos
restantes, provavelmente o projeto teria um plano para terminar
dentro de prazo, incluindo um plano para adquirir pessoas adicionais
se necessário. Ter empregados internos identificados e na reserva
permitirá que o projeto mova-se rapidamente no caso do mesmo
determinar que mais recursos serão necessários.
-
Um custo
incremental elevado dos recursos. Você pode ter os recursos que
são menos caros quando comprados em grande volume, mas muito caro
quando comprados incrementalmente. Por exemplo, se a entrega de
seu projeto requer um hardware novo, você poderá descobrir que o
preço por unidade diminui quando você compra mais unidades. Se você
o estima que necessita de 100 unidades, dependendo da incerteza,
você poderá decidir-se para comprar 110 unidades, e ter dez unidades
na reserva. Você faria isto porque o preço para comprar as dez
unidades extras (como uma parte da ordem de volume) é muito mais
barato que mais tarde ter que comprar somente dez unidades, quando o
custo incremental seria muito mais elevado.
-
Dificuldade para
encontrar recursos especializados. Às vezes há um tempo de
espera longo para adquirir os recursos especialistas e uma
dificuldade muito grade para encontra-los. Você poderá decidir
reservá-los se achar que os mesmos serão necessários mais tarde. Por
exemplo, você poderá trabalhar com uma empresa de RH antecipadamente
para encontrar um recurso especialista, tais como um perito em
alguma ferramenta obscura, mas a compreensão da exigência não é 100%
certa. A empresa de RH pode trabalhar antecipadamente para encontrar
este tipo de especialista e tentar ter o mesmo disponível em curto
prazo se a caso e quando você o necessitar mais tarde no projeto.
Na
maioria dos projetos, se você descobrir que necessita de mais recursos,
você precisa somente falar com o seu patrocinador e revisar o orçamento
e a programação se necessário. Entretanto, em alguns projetos você não
tem o luxo do tempo adicional. Nestes casos o gerente do projeto deve
identificar onde o projeto pode estar em risco e criar um plano para
assegurar-se que os recursos sejam reservados se necessário. Às vezes
você necessita realmente ter os recursos fisicamente disponíveis. Outras
vezes, você necessita somente saber que poderá adquirir-los em curto
prazo, se necessário. A necessidade para reservas tipicamente seria
identificadas e controladas através do processo de gerenciamento dos
riscos, com os recursos reservados que são uma resposta a um risco
especificamente identificado no projeto.
Estimando o Trabalho de um Projeto Antes de Coletar os
Requisitos Detalhados
(2.2.1.P15)
Uma das preocupações
de muitos gerentes de projetos é que eles são expectados fornecer uma
estimativa detalhada do trabalho do projeto quando o documento Termo
de abertura do projeto e o cronograma forem criados. Entretanto,
nesse ponto, os requisitos detalhados ainda não foram coletados, então
como poderão estimar detalhadamente o trabalho do projeto? A pergunta
parece ser válida, contudo, quando falamos sobre o recolhimento de
requisitos detalhados, normalmente estamos falando sobre a fase de
análise, que faz parte do ciclo de vida do projeto, e não do trabalho
preliminar de definição e de planejamento do projeto.
Seu primeiro
pensamento poderá ser que talvez você deva ter os requisitos detalhados
antes de se comprometer com uma estimativa para o trabalho. Mas será que
isso realmente é prático? Vamos dizer que há um projeto típico de
desenvolvimento de software. O projeto poderá durar seis meses e o
processo de coleta dos requisitos poderá durar de seis a oito semanas
(ou mais). Então, será que realmente devemos esperar para fornecer as
estimativas do projeto somente quando os requisitos forem coletados e
aprovados? Em caso afirmativo, o projeto poderá estar um terço concluído
antes de validarmos o custo total e a data final do projeto. Caso o
projeto não faça mais sentido na perspectiva de análise do
benefício/custo, esta descoberta será muito tarde e você poderá já ter
consumido uma quantia significativa de dinheiro. Esta é a razão por que
a maioria das metodologias de gerenciamento de projetos não inclui o
processo de coleta dos requisitos detalhados do projeto.
Da mesma
forma, se você usar este mesmo argumento, você poderá dizer que ainda
não está confiável para estimar o trabalho do projeto sem primeiramente
concluir a fase de design, e então você não estará confiável para
estimar o trabalho do projeto até que você tenha a fase de construção
concluída, etc. Observe que esta mesma lógica poderá ser levada ao
extremo.
As três
abordagens seguintes, permitirão que você estime o trabalho do projeto
antes de coletar os requisitos detalhados do projeto. (Isto supõe que
você está coletando os requisitos como parte da primeira fase de
execução do projeto. Se você usar técnicas ágeis ou iterativas você
poderá coletar os requisitos de maneira iterativa durante todo o
projeto.)
-
Abordagem tradicional: Quando você criar o documento Termo de
Abertura do Projeto e o cronograma do projeto, estime o trabalho
dentro de uma média de 10% a 15% . Entretanto, há uma suposição
subjacente de que o gerente do projeto e/ou a equipe do projeto já
realizaram esse tipo de trabalho antes, e baseado nos requisitos em
um nível elevado poderão estimar o trabalho dentro de uma média de
15%. Se você descobrir que estimou incorretamente depois que os
requisitos foram coletados, você deverá levar a situação ao
patrocinador para resolução.
-
Fracionar o trabalho em partes menores: Se você não se sentir
confortável para fornecer uma estimativa do projeto dentro de uma
média de 15%, você poderá fracionar o projeto em múltiplos projetos
menores. Quando você utiliza esta técnica, normalmente você cria
somente o documento Termo de Abertura do Projeto e o
cronograma para fazer a coleta dos requisitos do projeto. Você
deverá poder estimar este projeto de coletar os requisitos do
projeto dentro de uma média de 15%. Depois que este projeto de
coletar os requisitos for completado, você poderá utilizar a
informação para criar um segundo projeto para executar o restante do
trabalho, que deverá ser estimado dentro de uma média de 15%. No
final das contas, as entregas finais terão sido criadas através de
dois projetos, cada um foi estimado e gerenciado dentro de uma média
de 15% do orçamento (Fundos e prazos).
-
Estimar
o trabalho em um nível elevado baseado no documento Termo de
Abertura do Projeto e o cronograma, e então ajustar a estimativa
depois que os requisitos forem coletados. Esta é uma variação da
primeira técnica acima. Nesta abordagem, o gerente do projeto e a
equipe fornecem uma estimativa (melhor adivinhação) do trabalho
baseada no documento Termo de Abertura do Projeto e o
cronograma do projeto que já foram criados. Esta estimativa poderá
ser dentro de uma média de mais ou menos 25%. Entretanto, baseado
nas normas da organização, esta não é a estimativa que o gerente do
projeto deverá se comprometer para entregar o projeto. Esta
estimativa é apenas a melhor adivinhação baseada na informação
disponível no momento. Depois que os requisitos forem coletados, o
gerente do projeto fornece uma estimativa mais detalhada do trabalho
dentro de uma média de 15%. Esta é a estimativa que o gerente do
projeto deverá comprometer-se.
Muitos gerentes de projetos pensam que a melhor abordagem é coletar os
requisitos de forma iterativa. Entretanto, o ciclo de vida iterativo não
fornece resposta nos termos de como estimar o projeto dentro de uma
média de 15%. De fato, as abordagens iterativas poderão fazer este nível
de exatidão mais difícil, porque você está coletando somente um
subconjunto dos requisitos em cada iteração.
As três soluções acima
fornecem um grupo das técnicas mais viáveis para estimar o trabalho
dentro de uma média de 15%.
|
|
