时间估计出错时该怎么办？

假设您估计一个案件的时间为3天。在第二天中，您会注意到情况不断增长，并且弹出了新的方案，这些新方案在进行时间估算时并未计算在内。新的发现导致额外的2天（总共5天）。这是一个典型的问题，您作为开发人员迟早会遇到。

• 当您要通知项目负责人新的交货时间时，可以使用哪种策略？
• 通常您会得到一个问题，为什么？您如何激发新的交货时间？

事实是，在SDLC期间，许多项目没有花太多时间进行分析和设计。

编辑： 在非常复杂的项目中，无论您花费多少合理的时间进行分析与设计，由于业务规则过于复杂，总是会感到意外。但是，在这种情况下，我认为项目负责人必须意识到复杂性，并在出现意外情况时保持正确的态度。问题是如何应对那些不了解复杂性的项目负责人。

传递坏消息

您绝对需要立即提出此问题，但是，如果可以在合理的时间范围内（即几个小时，而不是更长的时间）提出问题，则应该先进行一些影响评估。

与所有坏消息一样，最好提供详细信息（而不是仅仅脱口而出“它要迟到了”），因此请提供尽可能多的信息：

1）修订的任务估计/时间表。

2）考虑到某些事情已经超支，您现在认为对未来任务的修订估算/时间表可能会花费更长的时间。

3）发生滑倒的原因非常简短（不要旋转，说实话，但听起来不像是在找借口）。在这种情况下，您要声明“我们是根据规则X和Y估算的，但是现在它们包含了从未提及的Z”。他也许可以以此来向客户解释延误，并首先教育他们进行全面培训的重要性。

4）如果有其他选择可以使事情重回正轨（通常会缩小范围，但可能会有其他选择-项目的其他部分可能会提前，并且可能会转移任务）。

请记住，滑倒的心理/信誉影响是累积的。您也许可以摆脱其中的一个，但第二个要强得多，而第三个要强得多。

这就是为什么要点2很重要的原因-不仅修改已经漏掉的内容，而且还要修改将来您认为比以前预期花费更多时间的任务。滑倒发生在IT部门，而不是从错误中吸取教训是更大的罪过。

防止必须传递坏消息

这里有两种情况：首先，您自己没有进行估算，在这种情况下，除了下一次推动参与估算之外，您无能为力。

其次，您自己做了估算，在这种情况下，您需要研究如何进行更好的估算。对我来说，问题中的关键词是“由于业务规则过于复杂，总会有惊喜”。

顺便说一句，如果它总是发生，那就不足为奇了。如果您仅获得一半的业务规则，则需要在估计中假设这一点，并考虑到功能的蔓延。

您可以通过增加自己所拥有规则的估算值来做到这一点（它可以起作用，但是您没有教育任何人实际发生的事情），但是最好使用估算值进行说明：“从历史上看，我们得到的规则是简化版本他们说的规则将需要3天的时间来实施，但是对于未提及但可能在开发和测试中发现的规则，我们应该允许3天的应急时间。”

如果PM对此提出疑问，那么您需要提醒他所有的事情都是真实的（举几个例子-很难争辩这些例子），并温柔地暗示准时交付与您一样符合他的利益，不是吗最好保守一点？

但最重要的是：如果您总是由于特定因素（在本例中为特征蠕变）而低估了，那么请将其计入您的估计中。

基于时间的估计是对未来的猜测，从长远来看，这总是会失败的。你赢不了，这是一场毫无意义的战斗。

在几天内停止估算，而开始使用相对估算。这是一个简单的示例：

1. 为每个任务分配一个编号。最困难的任务可能是10，最容易的任务是1。
2. 开始编程以完成您的任务。
3. 一周后，停止工作并汇总所有已完成任务的编号。可以说您以14结尾。这就是您的每周运动速度。

下周，再次重复该过程。我敢打赌，您的速度会改变，但不会太大。经过几个星期，您的速度应该会非常稳定，这就是我们的目标。现在您可以放心地制定计划了。挑选适合您速度的任务，您的PM可以肯定地完成了。这就是您应该如何与项目负责人联系的方法。

一旦您发现估计错误，就需要提高警钟。通知那些希望交付的人有关延迟的信息。

如果可能，请队友寻求帮助。确保您仍然提供尽可能高质量的软件。

捷径最终很可能会造成更大的伤害，每个参与人员都应该知道这一点。或者至少应该向他们解释。

这种情况经常发生，以至于没有经验丰富的项目经理会做很多事情。诚实地说，不要对新的估计过于乐观。当您看到它需要更长的时间时，请说出来。每天不要说“我需要更多时间”。

您将不得不向经理解释：最初的估算是错误的，还是不利的情况（花一天时间找虫子）是造成延误的原因吗？在第一种情况下，估算过程出了点问题，也许是过于乐观或天真。在第二种情况下，希望将缓冲区包含在项目计划中。

始终让相关的利益相关者知道您的进度，包括（尤其是！）您的估计过于乐观的事实。他们不会很高兴，但是他们会知道项目的真正位置并可以据此计划。

理想情况下，您的功能列表应该是MoSCoWed-必须，应该，不能，不会。

当您要超车时，先切成小块，然后切成小块。削减功能，以便您可以按时发货：您的项目通常不会孤立地生活，而且您过了发布日期就意味着下游项目现在也将超期。

理想情况下，您只有大约60％的必需品。如果您必须削减这些成本，那么您将面临非常严重的麻烦（存在严重的超支），在这种情况下，您将不得不削减成本。

确保释放后给自己足够的时间来清理因偷工减料而造成的混乱！

项目估算是赌博，简单明了。没有风险就没有回报。

如果经理不明白这一点，那是我要解释的第一件事。

问题是，谁来承担风险？

如果您使用固定价格合同，则可以承担风险。

如果花时间和材料，那么他将承担风险。

因此，在进行估算时，重要的是要了解自己在猜测，并且需要了解估算的不确定性以及由谁承担风险。

我相信最好的策略是不断完善您的估计。我知道，我是说：您的问题在某种程度上是错误的。

我读了Dan North的《故意发现介绍》一书，得出的结论是，将估计工作放在开始阶段就等于在您对问题和领域的无知程度达到最大值时进行准确的预测。面对现实，您无法预测不确定的事物，尤其是在不确定的事物之前。

敏捷的方法论解决了这个问题，将项目的生命周期分为几段（冲刺，在Scrum中），并每周重复一次估算（调整故事大小）。每个星期，您对问题的了解都会不断完善，估计也会不断完善。

对我而言，估计不能为真或假。只是可以不断完善。估算不是承诺。这就是为什么将其称为估算。

迟到时（以及由于问题相同：您有“提前交付的危险”：您估计不好），您可以做的最好的事情就是升级并尽快将事实告知客户。这就是所谓的风险管理。您越早提供反馈，抵销行为就会越有效。通常，这意味着，如果您有证据证明您无法交付所有东西，则yu应该与您的客户交谈，告诉她您只能交付70％的承诺，然后让她自己决定什么对她而言具有更大的商业价值，应该首先进行部署。

我在这里写下有关错误的估计，请帮助！我迟到了！剪切特征并停止瀑布！

之所以称为估算，是因为这是有根据的猜测。这不是对未来的无懈可击的描述，对于那些以这种方式对待软件估算的人，我几乎没有耐心。最终，许多事情将花费比您预期更长的时间，在极少数情况下，它们可能会花费更多时间。即使世界上最优秀的程序员也会遇到这种情况。经理如何期望它不会发生在您身上？如果您的经理不明白这一点，那么她就没有太多经验。如果她假装不理解它以施加进度压力，那么她就是不合理的。

最好的方法是最明显的。一旦您清楚地知道某个功能将花费比预期更长的时间，请与您的经理讨论。通常有很多方法可以解决您的问题和经理的问题。也就是说，正在减慢速度的功能部分可能相对不重要，或者很容易修改，以使更快的进度成为可能。但是无论如何，都不要欺负第二个乐观估计。

让所有团队都知道，并尝试找到解决方案。我推荐3种解决方案，从高到低优先级：

一种。尝试查找临时修补程序或快速解决方案

b。您可以做到的工作，做到最好。向客户展示您出色的工作后，请他们帮助：我们可以这样做，但是有一些问题，这可能会降低您的工作效率……也许您可以问他们是否有任何不必要的要求/可以删除或减少的功能。

为他们的问题提出替代方法也许是个好主意。

C。加班

选项：

• 剪切功能
• 降低质量（保留错误修复以供以后使用）
• 提高生产率
  • 查找并删除阻止程序
  • 休息/休息
  • 减少个人/睡眠时间
  • 获得更多的劳动力
  • 获得更好的工具
  • 训练
  • 增加动力
    • 免费食物
    • [承诺]提高/晋升/休假/奖金/等等。
    • 威胁
    • 改善工作条件（更好的硬件，家具等）
    • 改变环境-在咖啡店工作还是将整个团队转移到凉爽的地方-山间小屋还是湖边小屋？

这是一个常见问题：）

一种更简单的方法是为您所做的任何估计添加一个缓冲区，因为总是会出现无法预料的问题。缓冲区的大小取决于团队的大小以及技术和问题本身的不确定性。

更大的团队有更多的可能会生病的人，以及更少的了解“一切”的人。

新技术总是比您已经知道的风险更大。

并且，如果您发现自己无法在预计的日期完成工作，请尽早与利益相关者进行沟通。与客户/利益相关者交谈后，也许您可​​以重新安排内容的优先级或延迟某些功能。