O que fazer quando a estimativa de tempo der errado?

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.

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.

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.

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.

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.

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!

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.

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!

É 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.

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

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?

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.