我在第二个环境中工作了很多

这也是我在核动力海军中的经历，与软件开发完全无关。我是我部门的维护计划员，还有其他职责，所以我需要计划我们何时完成大约20个不同系统的预防性维护。通常计划是按季度进行的，但还有半年、一年及以上的维护项目也需要考虑进去。进一步复杂的是，许多项目有特定的工厂条件需要满足（有些很容易，比如“反应堆必须关闭”），其中一些在每个季度最多只会出现一次。最后，如果你想提高效率，还需要仔细阅读每个维护项目，以确定是否有重叠，这样你可以利用一个维护项目来部分为另一个维护项目做准备。 我在Microsoft Project中制作了一个巨大的依赖关系表，并生成了甘特图…

在"第二种环境"中进行估算也是不靠谱的。某些法律或监管责任的存在，并不会真正让该环境中的估算变得更好。 一个典型的例子是波士顿的Big Dig项目：严重延误且超支了七倍。在软件方面，奥巴马医保网站的初次发布是一场灾难。技术上并没有延误，但设计和部署都非常糟糕。我亲身了解很多政府研究（如NSF、SBIR等）项目资金的交付经常严重延迟或未能完成。 因此，我不认为某些环境真的能让估算变得更好。人类在估算上表现不佳，主要是由于社会和文化原因，而不是技术和工程原因。

>在第二种环境（截止日期是真实的且有后果的）中工作过的人，通常在不经历最后冲刺的情况下，就能很好地估计和管理进度。 我不确定。以我的经验来看，估计是软件工程中最困难的方面之一。一个黑天鹅事件或一些未知的未知因素会破坏你的周密估计（尤其是在开发周期的后期）——无论你在这方面多擅长。我宁愿手边有一个水晶球，让一切顺其自然，也不愿费尽全力去准确预测未来。 编辑：格式

在一种迟到会有严重后果的环境中工作时，每个人都会更容易接受为了在截止日期前推出解决方案而必须做出艰难的选择。范式从“我们想要这个特定的解决方案，需要多长时间？”转变为“我们有一个硬性截止日期，如何解决它？”。

这有两面性。以我之前在第二种环境中的经验来看，那里的截止日期是随意设定的，管理者和领导并不去做决定，去确定什么是重要的，或者什么是“完成”的含义。你一开始可能认为截止日期很重要，但后来会发现有些可能需要完成的活动会打乱你的截止日期。你可以寻求关于应该做什么的澄清，但可能会得到诸如“不要告诉我细节”、“自己想办法”、“我相信你会做出正确的决定”之类的回应。 而在截止日期真正重要的环境中，管理者会更愿意对范围做出决策，并密切控制它，与同事合作定义完成的状态，因为这确实很重要。

> 在第二种环境（截止日期是真实的且有后果）中工作过的人，通常在不进入最后冲刺模式的情况下，就能很好地估计和管理进度。他们擅长提前沟通截止日期的问题，以避免意外。 所以，激励措施很重要——令人震惊，真是令人震惊。 或者，也许得出的结论是，如果没有激励措施，有人编造了它，而且这并不重要。