Alguns conselhos do lado sombrio de quem aprendeu da maneira mais difícil.
Os requisitos não são claros. Ninguém fez uma análise aprofundada de todas as implicações.
Não faça uma estimativa neste momento. Não se estima quantos soldados são necessários para vencer uma batalha sem nenhuma pista sobre o número de inimigos. A estimativa é feita após a verificação. Isso é a menos que você já tenha lutado contra esse inimigo.
O novo recurso provavelmente quebrará algumas suposições feitas no seu código e você começará a pensar imediatamente em todas as coisas que talvez precise refatorar.
É sua responsabilidade levar em consideração, a menos que você espere que outros tenham conhecimentos sobre esta área.
Você tem outras coisas a fazer em tarefas passadas e precisará elaborar uma estimativa que leve em conta esse outro trabalho.
O mesmo que acima, mesmo para o trabalho imprevisto que é criado por um colega de equipe slob próximo a você com um procedimento de teste quase inexistente que faz com que seu código ocorra, que você não pode prever perfeitamente com antecedência. É uma previsão do tempo.
A definição de 'pronto' provavelmente não é clara: quando será feito? 'Concluído' como acabado de codificá-lo ou 'pronto' como em "os usuários o estão usando"?
Entenda o requisito de usuário final aqui, pense como um usuário. Não faça o que seus colegas fazem se estimarem que algo deve ser "feito" apenas porque alguma funcionalidade básica com um fluxo de trabalho de barebones que nenhum usuário pode tolerar é o que eles consideram "feito" . Pense nisso do ponto de vista do usuário, porque isso é tudo que o cliente que você está fazendo a estimativa normalmente entenderá. Faça uma estimativa para os requisitos completos do usuário final, não para os requisitos técnicos do barebone. E saiba que seus clientes que solicitam estimativas serão totalmente imprecisos aqui sobre como eles expressam as coisas e entendem os aspectos técnicos do que você diz.
Não importa o quão consciente você esteja de todas essas coisas, às vezes o seu "orgulho do programador" faz com que você aceite / aceite tempos mais curtos do que você supõe que possa levar. Especialmente quando você sente a pressão dos prazos e das expectativas da gerência.
Não faça isso! Você parece um trabalhador motivado e possivelmente um que cede facilmente à coerção.
O problema aqui é o seguinte: digamos que você e Joe fizeram estimativas de tempo para a mesma tarefa (mas entre dois funcionários separados, desconhecendo as duas estimativas ao mesmo tempo). Você estima valentemente "uma semana" . Tudo bem, você pensa que trabalha mais de 100 horas por semana, horas extras não remuneradas. Agora você está três dias atrasado.
Enquanto isso, Joe estima 5 meses. Você acha que isso é ridículo, você pode conseguir isso em uma semana. Quanto Joe trabalha? 10 horas por semana? ... exceto que ele termina no prazo em exatamente 5 meses.
Adivinha quem é percebido como o imbecil? Isso mesmo, você. Joe parece ser um grande trabalhador, você não parece confiável agora. Não importa tanto que você possa ter conseguido um resultado ainda melhor em ~ 7% do tempo que Joe levou. O que importa é que você tinha três dias de folga de uma estimativa de uma semana.
Nunca erre no lado da estimativa mais apertada. Erre no lado da estimativa mais flexível. Há uma reputação a ser construída em sua empresa e ela não se baseará no comprimento de suas estimativas quase tanto quanto na precisão de suas estimativas. É fácil ser preciso com uma estimativa muito longa, você só tem mais tempo para trabalhar no problema e resolvê-lo melhor. Uma estimativa muito curta não deixa espaço para respirar, ou você a encontra desesperadamente ou está ferrado.