O que fazer quando a estimativa de tempo der errado?

26

Digamos que você tenha estimado o tempo para um caso em três dias. No segundo dia, você percebe que o caso está crescendo e novos cenários estão surgindo, que não foram contados quando a estimativa de tempo foi concluída. A nova descoberta leva a 2 dias extras (total de 5 dias). Esse é um problema típico que você enfrentará mais cedo ou mais tarde como desenvolvedor.

  • Qual estratégia pode ser usada quando você notificar o líder do projeto sobre o novo horário de entrega?
  • Muitas vezes você recebe a pergunta por quê? Como você motiva o novo horário de entrega?

O fato é que muitos projetos não dedicam muito tempo à análise e design durante o SDLC.

EDIT: Em projetos muito complexos, não importa quanto tempo razoável você dedique à Análise e Design, sempre há surpresas, pois as regras de negócios são muito complexas. No entanto, nesses casos, acredito que o líder do projeto deve estar ciente da complexidade e ter a atitude correta quando surgirem surpresas inesperadas. A questão é como lidar com os líderes do projeto que não entendem a complexidade.

Amir Rezaei
fonte
1
Acho que a melhor pergunta é: o que você faz quando a estimativa estava correta ? Na maioria das vezes, não será.
Tim Post
@ Tim Post Você está certo sobre "Na maioria das vezes, não será" eu queria estar reservando.
Amir Rezaei
1
+1 - Obrigado pela edição, que contém palavras de sabedoria. O fato de você destacar ("" Em projetos muito complexos, não importa quanto tempo razoável você dedique à Análise e Design, sempre há surpresas, pois as regras de negócios são muito complexas. "" É muito verdadeiro.
Karthik Sreenivasan

Respostas:

17

Entregando más notícias

É absolutamente necessário levantar a questão prontamente; no entanto, se você puder fazê-lo em uma escala de tempo razoável (isto é, algumas horas, não mais), faça uma avaliação de impacto antes de fazê-lo.

Como em todas as más notícias, é melhor fornecer informações detalhadas (em vez de apenas deixar escapar "será tarde"), forneça o máximo / muitos de:

1) Estimativas / prazos revisados ​​para as tarefas que caíram.

2) Estimativas / prazos revisados ​​para tarefas futuras que você pensa agora, tendo em vista que algumas coisas já acabaram, podem levar mais tempo.

3) Razões muito breves por que o desvio ocorreu (não gire, apenas a verdade, mas não pareça que você esteja dando desculpas). Nesse caso, você declara "Estimamos com base nas regras X e Y, mas agora elas incluem Z que nunca foi mencionado". Ele pode ser capaz de usar isso para explicar o atraso aos clientes e educá-los sobre a importância de ser minucioso em primeiro lugar.

4) Se possíveis alternativas para trazer as coisas de volta aos trilhos (geralmente reduzindo o escopo, mas pode haver outras opções - outras partes do projeto podem estar adiantadas e pode ser possível mudar as tarefas).

Lembre-se, com derrapagens, o impacto psicológico / de credibilidade é culmulativo. Você pode se safar de um, mas o segundo será muito mais difícil e o terceiro ainda mais difícil.

É por isso que o ponto 2 é importante - revise não apenas o que já escorregou, mas também as tarefas futuras que você acha que podem levar mais tempo do que o inicialmente previsto. Escorregar acontecer nas TIs, não aprender com seus erros é um pecado maior.

Evitando ter que entregar más notícias

Existem dois cenários aqui: primeiro, você não fez as estimativas sozinho; nesse caso, não há muito o que fazer além de pressionar para se envolver nas estimativas na próxima vez.

Segundo, você mesmo fez as estimativas e, nesse caso, precisa ver como fazer estimativas melhores. Para mim, a frase-chave da pergunta é "sempre há surpresas, pois as regras de negócios são muito complexas" .

Com respeito, se sempre acontece, não deve ser uma surpresa . Se você conseguir apenas metade das regras de negócios, precisará assumi-lo nas suas estimativas e permitir a subida do recurso.

Você pode fazer isso aumentando as estimativas para as regras que possui (funciona, mas você não está educando ninguém sobre o que realmente está acontecendo), mas é melhor afirmar com suas estimativas "Historicamente, as regras que obtemos são uma versão simplificada do que eles realmente querem. As regras que eles declararam levarão três dias para serem implementadas, no entanto, devemos permitir outros três dias de contingência para as regras que não foram mencionadas, mas que provavelmente serão descobertas durante o desenvolvimento e o teste ".

Se o PM questionar isso, você precisará lembrá-lo de que sempre foi verdade (com exemplos - é difícil argumentar sobre exemplos) e também sugerir gentilmente que é do seu interesse entregar pontualmente, assim como o seu, então não é? melhor ser conservador?

Mas o ponto principal: se você sempre subestima por causa de um fator específico (neste caso, o recurso de fluência), entenda isso em suas estimativas.

Jon Hopkins
fonte
2
+1 "Como em todas as más notícias, é melhor fornecer informações detalhadas". No entanto, todo mundo não entende os detalhes / complexidade do problema.
Amir Rezaei
@Amir - Adicionei um pouco mais, embora, como a pessoa que entende a complexidade, a simples verdade seja que é sua responsabilidade explicá-la. Eles não vão aprender de outra maneira.
Jon Hopkins
Bons pontos! "com exemplos - é difícil argumentar exemplos" e "sugerem gentilmente que é do seu interesse entregar pontualmente". Em relação a "se isso sempre acontece, não deve ser uma surpresa", o problema é que o tempo extra para a surpresa não é constante. Portanto, você pode nem ter uma média deles, pois eles tendem a ter grandes variações.
Amir Rezaei
+1 "Lembre-se com derrapagens, o impacto psicológico / de credibilidade é cumulativo."
Karthik Sreenivasan
16

As estimativas baseadas no tempo são suposições sobre o futuro, e que sempre falharão a longo prazo. É uma batalha sem sentido que você não pode vencer.

Pare de estimar em dias e comece a usar a estimativa relativa . Aqui está um exemplo simples:

  1. Atribua um número a cada tarefa. A tarefa mais difícil pode ser 10 e a tarefa mais fácil 1.
  2. Comece a programar para concluir suas tarefas.
  3. Após uma semana, pare seu trabalho e some todos os números de tarefas concluídas. Digamos que você termine com 14. Essa é a sua velocidade semanal.

Na próxima semana, repita o processo novamente. Aposto que sua velocidade mudará, mas não muito. Depois de algumas semanas com isso, sua velocidade deve estar bem estável e é isso que estamos buscando. Agora você pode começar a fazer planos com confiança. Escolha tarefas que sintetizam a sua velocidade e o seu gerente de projetos pode ter certeza de que será concluído conforme prometido. É assim que você deve abordar seus líderes de projeto.

Martin Wickman
fonte
Você pode dar um exemplo de como acompanhar o tamanho das tarefas? Você cria uma tabela com tipos de tarefas (como "criar um novo formulário", "adiciona um método ao serviço da web X") ou é mais um pressentimento?
cringe
Basta comparar com as tarefas estimadas e concluídas anteriormente.
Martin Wickman
+1 - "As estimativas baseadas no tempo são suposições sobre o futuro, e que sempre fracassam a longo prazo. É uma batalha inútil que você não pode vencer." Esta é a primeira vez que estou aprendendo sobre estimativas relativas e é definitivamente um alimento para reflexão. Obrigado.
Karthik Sreenivasan
Que ideia brilhante! Definitivamente vou explorar isso ainda mais.
Meetpd
3

Assim que a estimativa estiver errada, você precisará disparar a campainha de alarme. Informe quem espera a entrega sobre o atraso.

Peça ajuda aos companheiros de equipe, se possível. Certifique-se de entregar o software da mais alta qualidade possível.

Um atalho provavelmente fará mais mal no final, e todos os envolvidos devem saber disso. Ou pelo menos deve ser possível explicar isso a eles.

Morten
fonte
3

Isso acontece com tanta frequência que nenhum gerente de projeto experiente fará muito disso. Apenas seja honesto e não faça novas estimativas muito otimistas; quando vir que vai demorar muito mais, diga. Não diga "preciso de um pouco mais de tempo" diariamente.

Você precisará explicar ao gerente: a estimativa estava errada em primeiro lugar ou as circunstâncias adversas (passadas um dia caçando um bug) foram a razão do atraso? No primeiro caso, algo está errado com o processo de estimativa, talvez seja muito otimista ou ingênuo. No segundo caso, é o caso do buffer que, esperamos, foi incluído no plano do projeto.

user281377
fonte
2

Sempre mantenha as partes interessadas relevantes cientes de seu progresso, incluindo (especialmente!) O fato de suas estimativas serem excessivamente otimistas. Eles não ficarão felizes, mas saberão onde realmente está o projeto e poderão planejar adequadamente.

Idealmente, sua lista de recursos terá sido MoSCoWed - Deve, Deve, Poderia, Não.

Quando você estiver indo para a superação, corte os Coulds e os Shoulds. Recursos de corte para que você possa enviar a tempo: seu projeto normalmente não vive isolado e a data de lançamento anterior significa que os projetos posteriores agora também ultrapassarão o cronograma.

Idealmente, você terá apenas ~ 60% de mostos. Se você precisar cortar aqueles que estão com problemas muito profundos (com uma superação muito séria), nesse caso, terá que cortar custos.

Certifique-se de reservar um tempo suficiente após a liberação para limpar a bagunça feita cortando cantos!

Frank Shearar
fonte
4
+1 @Frank Bom argumento sobre "Recursos de corte para que você possa enviar a tempo". O problema aqui é que eu não sou o líder do projeto.
Amir Rezaei
@Amir Nesse caso, seu cliente é (tipo) seu líder de projeto. Você diz: "Estou atrasado. Posso cortar esse recurso ou esse recurso. O que devo fazer?"
Frank Shearar
@Frank Como fazemos o Scrum, e o caso é transferido do backlog para o sprint, parece que está escrito em pedra para o PM reduzir os casos. No entanto, uma experiência em MP pode não ter esse tipo de problema.
Amir Rezaei
Eu não gosto de MoSCoW. O único inteligente com isso é o acrônimo. Apenas mantenha suas tarefas em uma lista de pendências priorizada.
Martin Wickman
1
@Martin encolher os ombros "Deve" significa "se você não envia esse recurso, não tem nada". São informações diferentes de uma lista de pendências priorizada, que é "qual recurso você prefere primeiro?" Você ainda teria uma lista de pendências priorizada no MoSCoW.
Frank Shearar
2

A estimativa do projeto é jogo, pura e simples. Não há recompensa sem risco.

Se o gerente não entender isso, essa é a primeira coisa que eu explicaria.

A questão é: quem cobre o risco?

Se você tiver um contrato de preço fixo, estará cobrindo o risco.

Se houver tempo e materiais, ele estará cobrindo o risco.

Portanto, ao fazer uma estimativa, é importante entender que você está adivinhando e precisa ter uma idéia de quão incerta é a estimativa e quem está cobrindo o risco.

Mike Dunlavey
fonte
1

Acredito que a melhor estratégia é refinar constantemente sua estimativa . Eu sei, estou dizendo: sua pergunta é de alguma maneira equivocada.

Lendo Introduzindo a Descoberta Deliberada de Dan North, cheguei à conclusão de que colocar o esforço de estimativa na fase inicial é igual a fazer uma previsão exatamente quando a sua ignorância do problema e do domínio está no nível máximo. Enfrente, você não pode prever o que é incerto, especialmente se ainda é desconhecido .

As metodologias ágeis resolvem esse problema, dividindo a vida útil do projeto em várias partes (sprints, no Scrum) e repetindo a estimativa (histórias de dimensionamento) a cada semana. A cada semana, o que você sabe sobre o problema é refinado e a estimativa também.

Para mim, uma estimativa não pode ser verdadeira ou falsa. Apenas pode ser cada vez mais refinado . Uma estimativa não é um compromisso. É por isso que é chamado de estimativa.

O melhor que você pode fazer quando se atrasa (e também quando "corre o risco de entregar antecipadamente", porque o problema é o mesmo: você calculou mal) é escalar e levar o fato ao cliente o mais rápido possível. Isso se chama gerenciamento de riscos. Quanto mais cedo você enviar um feedback, mais eficaz será a contra-medição. Normalmente, isso significa que, se você tiver evidências de que não pode entregar tudo, deverá conversar com seu cliente, dizer-lhe que pode cumprir apenas 70% do compromisso e deixá-lo decidir o que tem mais valor comercial para ela e deve ser implantado primeiro .

Eu escrevi sobre isso aqui Estimativa errada, ajuda! Estou atrasado! Cortar recursos e parar de cair em cascata!

Arialdo Martini
fonte
1

É chamado de estimativa, porque é um palpite. Não é uma descrição infalível do futuro, e tenho pouca paciência para as pessoas que tratam as estimativas de software dessa maneira. Por fim, muitas coisas levarão mais tempo do que o esperado, em casos raros, elas podem levar uma ordem de magnitude mais tempo. Isso acontece mesmo com os melhores programadores do mundo. Como um gerente pode esperar que isso não aconteça com você? Se o seu gerente não entende isso, ele não tem muita experiência. Se ela finge não entender, a fim de aplicar pressão no cronograma, ela está sendo irracional.

A melhor abordagem é a mais óbvia. Assim que tiver uma ideia clara de que um recurso levará mais tempo do que o esperado, discuta-o com seu gerente. Muitas vezes, existem maneiras de proceder que resolverão os seus problemas e os do seu gerente. Ou seja, a parte do recurso que desacelera as coisas pode ser relativamente sem importância ou fácil de modificar de uma maneira que possibilite um progresso mais rápido. Seja qual for o caso, não se deixe intimidar por uma segunda estimativa otimista.

PeterAllenWebb
fonte
0

Informe a equipe toda e tente encontrar uma solução. Eu recomendo 3 soluções, de alta a baixa prioridade:

uma. Tente encontrar uma correção temporária ou uma solução rápida

b. O trabalho que você pode fazer, faz melhor. Depois de mostrar sua excelente parte do trabalho ao cliente, peça sua ajuda: podemos fazer isso, mas há algum problema e isso pode diminuir a produtividade do seu trabalho ... Talvez você possa perguntar se há algum pedido desnecessário / recurso que pode ser descartado ou cortado.

Propor uma abordagem alternativa para o problema deles, talvez uma boa idéia.

c. Trabalho extraordinário

Hoàng Long
fonte
Eu atualizei minha pergunta. É o líder do projeto que será notificado.
Amir Rezaei
Eu não entendo direito. Você é o líder do projeto ou apenas um programador?
Hoàng Long
0

Opções:

  • Recursos de corte
  • Qualidade de corte (deixe correções de erros para mais tarde)
  • Aumentar a produtividade
    • Encontre e remova bloqueadores
    • Pausa / descanso
    • Reduzir o tempo pessoal / de sono
    • Obtenha mais força de trabalho
    • Obtenha melhores ferramentas
    • Treinamento
    • Aumentar a motivação
      • Comida grátis
      • [Promessa de] aumento / promoção / férias / bônus / etc.
      • Ameaças
      • Melhorar as condições de trabalho (melhores equipamentos, móveis, etc.)
      • Mudar o ambiente - trabalhar em uma cafeteria ou levar toda a equipe para algum lugar legal - um chalé na montanha ou uma casa no lago?

fonte
1
Deve-se notar que cada palavra é uma resposta de CURTO PRAZO à pergunta "o que fazer quando a estimativa do tempo der errado". Mais notavelmente, as ameaças aumentam brevemente a motivação e, em seguida, têm o efeito oposto.
Dan Ray
Concordo que as ameaças são ruins, embora tenha certeza de que funcionam para algumas pessoas e em algumas situações, especialmente se você planeja deixá-las desaparecer de qualquer maneira.
0

Esse é um problema comum :)

Uma das abordagens mais simples é adicionar um buffer a qualquer estimativa que você faça, pois sempre ocorrem problemas imprevistos. O tamanho do buffer depende do tamanho da equipe e da incerteza da tecnologia e do problema em si.

Equipes maiores têm mais pessoas que podem ficar doentes e menos pessoas que sabem "tudo".

As novas tecnologias são sempre mais arriscadas do que as que você já conhece.

E quando perceber que não terminará na data estimada, comunique-se cedo com as partes interessadas. Talvez você possa redefinir a prioridade das coisas ou atrasar certos recursos depois de conversar com o cliente / parte interessada.

Patrick Cornelissen
fonte