作为软件行业的新手，我遇到了一个关于截止日期执行的问题：
回到学术界的田园诗般的时代，截止日期是学期末，惩罚是明确定义的“F”（或当地同等学历）。在现实世界中，我们需要编写我们当前和未来的同行可以使用的代码，我面临截止日期到来，截止日期过去，项目仍未完成的情况。
怎么办？在一个极端，我们可以解雇所有相关人员，另一方面，我们可以丰厚奖励所有相关人员。
您看到哪些操作被用作错过最后期限的“惩罚”，哪些操作最终会产生更好的代码？
哪些项目管理响应导致项目彻底失败，
哪些响应恢复了工作秩序并导致之后可以维护的代码？
哪些响应导致更糟糕的代码？
截止日期是关于如何进行软件开发的一个根本错误想法的一部分。软件开发行业的新手或外人不明白这一点：
软件完成即完成，不早不晚。
如果开发人员有一个任务和一周的时间来完成它，并且看起来需要一个多星期的时间，那么没有什么可以改变它。无论开发人员多么努力，无论增加多少人，它仍然会花费尽可能长的时间（实际上增加人通常会花费更长的时间）。
相反，请阅读敏捷开发过程。软件应该迭代开发，每次迭代都应该基于前一次迭代的结果，而不是强加的外部需求。
根据以下广泛的评论进行编辑：
我绝不会争辩说开发人员不能被某种交付期望所束缚。我的观点是对提问者提出的具体假设的回应——商业软件开发的性质在某种程度上类似于学校作业或任何其他类型的工作。我认为绝对不是。“截止日期”不仅仅是一个简单的交货日期。它是一个固定点，必须完成固定数量的工作。软件根本不是那样工作的。我又写了几段来解释原因，但老实说，如果你还不相信，我所说的一切都无法说服你。
如果您正在从事一个软件项目并且很明显您将无法达到截止日期，那么您可以做些什么来纠正它？答案是众所周知的：几乎没有。你不能添加更多的人。你不能“更快地工作”。只是不会按时完成。你告诉利益相关者，每个人都在调整，并继续工作（或不工作）。那么，原来的日期是什么意思呢？
任何声称软件开发类似于架桥或家庭作业的人，或者如果开发人员只是拼命拼命工作，仍然可以满足即将到来的最后期限，他们对自己的职业深感困惑。
你的第一反应不应该是如何应对错过的最后期限，而是分析你错过最后期限的原因。由于原因，对错过最后期限的反应自然会随之而来。
例如，如果参与其中的每个人都没有做好自己的工作，那就解雇他们。
但是，如果他们完成了他们的工作，甚至更多，那为什么仍然错过了呢？同一个人进行了太多其他活动？截止日期范围太大（即不切实际的截止日期）。或者……等等。
根据我的经验，错过最后期限的首要原因是人们不允许 100% 地在手头的项目上工作，因此你可能拥有的任何估计，尽管它们自己是准确的，但根本没有真正的用处。再加上不切实际的估计和最后期限。
开发人员不应该因为管理层的错误而受到惩罚。
这就像父母惩罚孩子，因为父母度过了糟糕的一天。
推理：
截止日期是生活中的事实。人们想知道某件事需要多长时间。我们能做的最好的就是估计/猜测。管理人员的职责是试图弄清楚这个神奇的、永远不会正确的猜测。当他们创建截止日期时，他们需要使用正确的工具（经验、向开发人员、律师、人力资源等寻求帮助）
然而....
错过最后期限的处罚不应该落在工人身上。错过最后期限是管理层的错。他们应该说不，应该缩小项目规模，或者应该更好地激励工人。
在建筑工人中，如果你惹了工人，你就会开始打架。在我的公司，如果我们错过最后期限，管理层就会遇到麻烦。不是工人。控制项目和完成的工作是经理的工作。工人们只做他们能做的。经理负责分配角色和任务。
我并不是说工人的素质不是一个因素，但管理层应该知道这一点！不需要天才就能知道一个项目没有经过深思熟虑或没有得到很好的控制。询问任何人他们的经理是否知道发生了什么，你会发现问题。
当经理们意识到设置/同意截止日期是他们的错时，我们不再错过尽可能多的截止日期。
</rant>
回复：问题：
1.您认为哪些措施适用于错过最后期限的“惩罚”，哪些措施实际上让事情“变得更好”？
2. 哪些项目管理响应导致项目彻底失败，哪些响应恢复了工作秩序并导致之后可以维护的代码？
死亡。干净简单。
取决于开发人员是否为每个修改请求设置最后期限，或者这些是否由管理层为他们设置。
在后一种情况下，除非您的所有开发人员整天都坐着玩 Halo 3，否则错过最后期限通常表明管理层或团队领导方面存在错误。所以解雇所有人并不能解决问题。在您的软件过程中引入更好的指标可能是有意义的，这样您就可以看到最后期限会在它发生之前很久就被错过。
如果您的开发人员确实给出了时间估计，那么我会非常小心地奖励和惩罚满足期限或错过期限的开发人员。这样做的结果可能是他们会在时间估计中调整他们的“软糖因素”。他们会给自己太多额外的时间（来获得回报），如果他们擅长估计，事情就会变得一团糟。你的目标应该是让他们给出好的和可靠的估计，而不是改变他们的工作方式来满足这些估计。
这首先取决于最后期限是否可能，也许是计划和估计需要多长时间的错误。在决定惩罚之前确保你知道为什么错过了最后期限
天啊...
首先，有外部截止日期和内部截止日期，它们应该是不同的。
内部截止日期发生的情况是活动的频率随着截止日期的临近而增加，在截止日期达到峰值，然后随着截止日期的缩短而下降。因此，计划外部截止日期至少在内部截止日期之后几个星期。
然后，确保最后期限是现实的。在某种程度上，您通过让开发人员参与设置它们并决定将要完成什么来做到这一点。
最后，我主要是一名开发人员，但是当我尝试管理时，我永远不想将最新最好的版本带入会议或演示文稿中。我想要一个至少几周前的版本，并且我知道问题出在哪里，并且我可以肯定不会包含令人不快的惊喜。
在他关于项目管理的精彩书籍—— “截止日期”中——汤姆·德马科告诉我们一个故事，关于一个西方世界的项目经理正在一个虚构的后共产主义东欧狂野国家管理一个项目（狂野是一个非常好的术语，因为公民有点……不文明）。
有一天，PM 发现出了点问题，他的项目的某些部分严重错过了不切实际的时间表。前任总理简单地将负责人吊在屠夫的钩子上，对错过最后期限进行处罚，但由于时间表不切实际，一个人已经错过了最后期限。
所以这个故事告诉我们有一天，西式首相遇到了一个负责人，他应该把他送上屠夫的钩子。PM 和大多数人一样，害怕仅仅因为有些人永远无法按时完成他的项目而将某人判处残忍死刑。而且——无论如何——吊死这个可怜的人并不能推进这个项目。由于这是一部关于项目管理的小说，而不是关于折磨的小说，我们的主人公取消了惩罚。
但是这个关于吊死某人的故事背后有一个大问题：如果你设定了一个截止日期，并为错过这个截止日期设定某种惩罚，那一天就会到来，你可能不得不实际惩罚某人。你会这样做吗？无论惩罚是什么：绞刑、奖金损失、解雇、破坏交易或一些费用——你可能不得不惩罚某人。这个惩罚会对你的项目有好处吗？你必须自己回答。
所以：不要因为错过最后期限而受到惩罚，你不会想要执行......</p>
正如其他人所提到的，在谈论处罚之前，先从“我们如何确定这些截止日期是否现实”开始？
或者正如我的老板曾经说过的那样，“当你给我们一个行之有效的计划时，我们会很乐意制定一个计划”。
我仍然认为应该在T恤上。
一旦你到了人们已经超过最后期限的地步，你必须问自己 (A) 这样做的自然后果是什么，以及 (B) 你如何才能最好地完成任务并保持对业务的某种运动目标（即使您不经营企业）。
除非他们相信他们已经赢得了最后期限，否则明确惩罚超过最后期限的人不太可能有帮助。如果截止日期不切实际，如果团队中的某些元素是主要的失败点，如果需求存在严重问题，或者如果涉及的大多数团队认为上述因素是正确的，则不会发生这种情况。
在一个案例中，我所在的团队将一个小型交付物的截止日期提前了三个多月——而最初的交付物到期日是三个月后！我们误解了要求，没有与客户充分交谈，并且低估了所涉及的时间。管理层对推卸责任根本不感兴趣。这部分是因为这对完成可交付成果会适得其反，部分是因为我们都不是“问题员工”，部分是因为管理层知道我们都非常积极地解决问题并让客户满意。所以我们完成了它，客户和预期的一样高兴，我们继续我们的生活，并获得了一些关于如何避免将来出现这种情况的宝贵经验。
到目前为止，在我的职业生涯中，我还没有看到因错过最后期限而受到任何真正的惩罚（而且我错过了很多）。我想，对于在公司向公众做出承诺的商店销售软件或游戏的公司来说，情况会有所不同。
但在定制软件开发领域，很难准确估计一个项目需要多长时间。很多时候，世界各地的公司都不情愿地接受这一事实。
没有惩罚。“截止日期”和估算一直是并将继续是软件开发中最困难和最具挑战性的部分之一。
为这个问题对开发者进行处罚是荒谬的。
这当然不是一个简单的答案。以下是我权衡的一些事情以及我做/鼓励的事情，以确保事情按时完成。
1.) 正确设置优先级。项目总是会有不同程度的完成。这不是二进制“完成”/“未完成”开关。如果优先级最高的事情先完成，就更容易下咽。理想情况下，您应该快速达到它可以工作的程度，但它并不能完成我们需要它做的所有事情，而且看起来也不漂亮。在那里，如果绝对需要，它可以被释放。
2.) 我发现处理它的最佳方法是使版本尽可能小。这使得估计更准确。如果你的老板或“市场”认为你的估计是不可接受的，如果可能的话，考虑分配更多的开发人员来完成这项任务。有时一项任务并不能很容易地划分，或者只有一个熟悉代码的人。如果这不是一个高优先级，只需告诉当权者这将需要更长的时间。设定合理的目标和管理期望是关键。
3.) 至于动机、奖励和惩罚……有很多医生就这些主题写了整本书。以我的经验，给程序员一些具有挑战性的东西并让他们有一些自由按照自己的方式去做是一个好的开始。倾听是管理者为了成功而需要做好的事情。如果开发人员经验丰富，您应该能够只解释问题并让开发人员提出解决方案。如果他们的解决方案不如您想象的那么好，您可以提出建议并从那里开始。仅仅指示如何做某事，即使对于新程序员，也很少有效。让开发人员思考问题将有助于他们自己解决问题。这与委派有关，因为只有开发人员可以自己完成工作时才有效。
4.) 如果员工做得好，就给他们高薪，从而减少营业额。找到好人通常要花更多的钱。熟悉庞大的代码库需要时间，招聘过程还可以帮助避免花时间在无法切入芥末的人身上。
5.) 询问（不要要求）开发人员是否可以在周末加班/加班。仅在非常关键的情况下才这样做（例如，安全漏洞使用户可以访问他们不应该访问的数据；您必须遵守的新法律/法规通过；等等）。如果他们说不，不要反对他们。事情没有完成可能不是他们的错。即使是这样，他们也可以合理地安排他们不应该上班的时间。如果他们愿意进来，请确保他们知道您的真诚感谢。在他们没有义务帮忙的时候给予他们很好的补偿，买午餐不会花很多钱，这是一个非常好的姿态。不要养成期望人们工作到很晚/周末的习惯，除非它'
6.) 了解为什么事情落后于计划。您是否承诺了一些不可能的事情（考虑到可用的人员、预期的质量和分配的时间）？有没有其他项目上来占用资源，截止日期没有调整？代码是否比预期的更难？给出时间估计是困难的。您需要计划好一切，拥有经验并知道每个开发人员将花费多长时间来完成任务。补偿可能出现的意外问题，并给程序员比你的老板或客户更早的截止日期。早点做总是好的。而且，如果您几乎总是提前或按时完成，那么如果您有某种解释，那么您错过最后期限的那一次会更容易理解。
7.) 请记住，它通常归结为时间、质量和金钱。您通常可以选择任何两个，但第三个需要平衡等式。因此，如果需要快速完成且预算有限，您可以预期质量会受到影响。如果您需要快速且高质量地完成它，预计会付出很多钱，等等。
8.) 我想说对我有用的第一件事就是倾听。如果您忙于吠叫订单，那么您甚至可能不知道公司的问题。现在仅仅因为开发人员说“代码很烂，设计很糟糕，如果我们想及时完成任何事情，我们需要重新编写所有内容”并不意味着它会发生。但是，如果您听到这样的评论并解释说我们负担不起这样做，否则我们会在市场上被杀，那太贵了。并询问可以做些什么来确保事情不会变得太多/更糟。询问我们是否有办法随着时间的推移对其进行清理。我们可以只（重新）编写一个类并基于它构建新的东西吗？我们可以一次慢慢地迁移到一个新的设计特性/细分/模块吗？您了解它们的来源，反之亦然，您可能至少可以解决一些问题。请记住，妥协是双向的。
9.) 消极的强化似乎会导致更高的营业额，这是代价高昂的。拥有一群不熟悉您的代码的人也无助于截止日期。金钱是一种动力，但我已经辞掉了一份薪水更高的工作，去了一个我以前更快乐的工作，而且我知道我并不孤单。当团队做得很好时，免费的食物并不是那么贵。我不太热衷于团体活动，因为它们要么会缩短员工的时间，要么会占用工作时间。它有时会奏效，但减少员工的私人时间以便他们可以与同事闲逛而不是与他们的朋友在一起并不是那么好的奖励。让每个人都停止工作也很昂贵……所以这取决于公司的规模、文化等。
希望这有助于回答您的问题。该线程中的其他答案也是很好的建议...设计在编写代码的速度方面起着重要作用。
虽然我从未见过任何纪律处分或解雇，但我见过很多“强制性”加班和同事要求加班的压力。
作为一名经理，我几乎被解雇了，因为我告诉向我报告的团队不要在周末上班和工作到很晚。我知道这些事情不利于项目和士气。
一般来说，“惩罚”的形式是让人感到内疚或焦虑，但我相信有些地方做的“官方”事情更多。
世界上到处都是白痴。管理也不例外。
我认为这个问题本身就表明了对管理和项目管理角色的误解。
不幸的是，在许多人的头脑中，他们的标题中带有“经理”一词的普遍看法是，管理意味着治愈/踢懒惰的工人的屁股。它也适合那些相信帕金森定律的人。
它不是。这是为了让工作能够完成他们的工作——无论是作为他们与组织其他部分之间的沟通渠道，为他们获取资源，还是运行干扰（将家具移开）。
也就是说，PM 应该已经知道项目/任务将错过截止日期。他们应该问问题，并且知道发生了什么。他们有权削减任务或增加/重新平衡资源以完成工作（或对赞助商说，如果您不提供资源，则无法按时完成）。因此，无论是什么都不做、大骂、降级还是解雇，惩罚都归于总理。
有时延迟是不可避免的。这就是为什么我们要建立应急时间。有时，这是已知的风险；只要你有一个备用计划 - 你就可以了。
至于响应，您有四个参数：范围、时间、金钱和质量
没有足够积极地（在需要时）做这些事情肯定会导致你失败。
如果您错过了最后期限，请修正您的估计。
从企业发展的角度来看...
如果截止日期来自执行工作的人以外的其他人，请检查情况以确定超限的原因。在这些情况下，它通常与不完整的需求、范围蔓延、管理不善等有关。不应该因为错过这个人一开始就没有提供的最后期限而受到惩罚。
如果执行工作的个人提供或同意了截止日期，则该人需要解释导致延迟的因素。此外，应提醒此人在意识到可能错过最后期限时立即通知其主管、项目经理或其他责任方。截止日期过后，不应公开此信息。如果这种情况反复发生，则应遵循贵公司的纪律处分程序。这可能涉及增记、暂停或终止。
当人们设定最后期限时，他们往往会真正拥有自己的所有权。如果在没有他们输入的情况下将截止日期放在他们身上，那么截止日期对于执行工作的人来说往往变得毫无意义。
你的问题本质上是有缺陷的：它假设惩罚是管理人的最佳方式。一般而言，人们对惩罚或惩罚威胁反应不佳；它带出最坏的行为，使动机外部化，并分散内部动机的注意力。奖励和贿赂（奖励威胁）是同一枚硬币的另一面，并没有做得更好。
然而，这些力量是为雇佣而建立的，所以你永远不会从你的程序员那里得到最好的创造性工作，但你不必在他们错过最后期限时惩罚他们，从而使情况变得更糟。
取而代之的是，思考创作过程，多人进行创造性工作的混乱，以及哪些工具可以有效地管理混乱。
要管理任何混乱的系统，请进行大量测量并准备好快速改变路线。在编程的情况下：
尽可能采取最小的步骤。不要“把任务分解成小步骤”，因为你会浪费很多时间来计划那些不会像你计划的那样成功的步骤。混沌，还记得吗？
选择提供最大价值的最小步骤。
一段时间后，根据你学到的知识重新评估你的计划
尽快将工作软件交付给实际的、真实的客户，这样他们就可以告诉你你真正应该做什么。
您可能认为这是 SCRUM 背后的思想。
一旦项目延迟，就没有太多的“管理”（好的、坏的、善意的或恶意的）可以做，这不会导致项目更晚
...唯一的例外可能是消除/避免外部干扰。
你问“惩罚应该是什么……”。看来您是从“公司内部”的角度提出问题的。
在现实生活中，惩罚往往是迅速而严厉的——业务损失、诉讼、行业声誉不佳。这些是客户在某个日期之前承诺的事情没有兑现的真实处罚。
在内部，您通常可以做任何您喜欢的事情。但是，一旦您开始涉及付费客户，那么管理这些客户就成为整个工作的关键部分。
像我描述的那样的惩罚通常可以通过与客户的“顶级”沟通来避免（或减轻）。如果客户想要添加一些东西（所谓的特性蠕变），那么应该立即用这些变化对项目的影响来回答这个问题（成本更高，稍后交付，等等）。应该鼓励客户根据他们的截止日期和预计成本对所有此类请求进行分类（即让客户管理功能蠕变，而不是您）。
如果其他事情改变了交货时间，那么一旦你知道会有滑点，你必须通知客户。如果提早完成，客户非常愿意与您合作。但是，如果您在为时已晚之前什么都不说，他们就不太可能原谅……尤其是如果他们发现您早知道并且没有告诉他们。
干杯，
-理查德
这不是一个真正的编程问题，而是更多的管理问题。
错过最后期限很少是开发人员的错。作为开发人员，您应该尽最大努力将工作做好，但最终每个人都只能做到这么多。如果开发人员付出了诚实的努力，尽管如此，最后期限还是被错过了，这意味着最后期限从一开始就是不现实的。
处理最后期限是经理的责任。有不同的方法，但没有一种方法包括“惩罚”开发人员的工作。这里要理解的重要一点是所谓的项目管理三角形。这意味着软件项目可以是好的（即满足要求、良好的质量）、快速（满足最后期限）和便宜的（人数、工具）。问题是这 3 个属性中只能选择 2 个。
因此，如果管理层想要一些好的和快速的东西 - 它不会便宜。
如果管理层想要一些又好又便宜的东西 - 它不会很快。
最后，如果管理层想要便宜又快——你猜怎么着，这不会有任何好处。
因此，对错过最后期限的正确响应取决于所选场景。好和快需要添加一些额外的帮助、更好的工具、对高于平均水平的开发人员的投资等等。
好和便宜的定义是假设最后期限会被错过（暴雪，魔兽世界的制造商就是这种方法的好例子）
最后，廉价和快速通常意味着削减功能并发布错误。
项目管理的主要目标是及时计划如何构建应用程序。如果您没有时间表显示项目将持续的每一天您将要做什么，那么您不应该开始您的项目开发。
这样，只要您定期（每周，如果不是每天）跟踪项目的发展，您就可以检测到您会迟到。你越早知道，你就能越早采取相应的行动。
你通常有两种选择：
对于第二种选择，我并不是说永远不会受到处罚。但从我个人的经验来看，只要提前通知客户并提供解决方案（最好是三个：为额外的工人提供更多的钱/删除功能以节省一些时间/接受项目延迟），他们就会愿意谈判. 这总是比冲突好:)
根据开发人员及其领导的所有建议设置不切实际的短开发时间框架应该受到什么惩罚？
巧合的是，这似乎与开发团队错过发货日期一样频繁。
也许更好的问题是，面对不准确的估计，最后期限是否有意义？企业在评估软件方面做得很糟糕——这是事实。管理层和开发人员都参与其中，而且似乎谁都不愿意承认他们在这个问题上的责任。
但要回答您的具体问题：
1.您认为哪些行为是对错过最后期限的“惩罚”，哪些行为最终会产生更好的代码？
我见过的经理和开发人员因错过最后期限而受到的“惩罚”从一无所有，到晋升，再到简单的转移。我亲眼目睹的最严厉的惩罚是经理“调到”一个不太重要的项目，业务部门失去了财务奖金。
我唯一一次看到有人在错过最后期限后被解雇是在员工已经被解雇的时候——最后期限给了企业解雇员工的合法理由。
2. 哪些项目管理响应导致项目彻底失败？
这本身就是一个完全独立的讨论……但是这个问题存在一些固有的偏见——项目管理有问题。
我个人看到的 PM 破坏项目的三件最重要的事情是（按严重程度排序）：
3.哪些响应恢复了工作秩序并导致之后可以维护的代码？
我还没有看到一个功能性软件开发组织。因此，解决办法通常是几个英勇的开发人员与一位知道如何抵御公司内部政治的高能力 PM 一起工作的英勇开发人员付出大量的鲜血、汗水和泪水（例如，让他们的员工不屑一顾）。
4. 哪些响应导致更糟糕的代码？
我见过一些高管在错过一些最后期限后不久就离开了公司。这改变了一切，但并不一定会使事情变得更好或更糟。我已经看到了一些合同义务，例如回拨，作为惩罚某人错过最后期限的一种方式，我不确定他们的工作情况如何。
当一个人在项目分配的时间中途完全改变项目应该做的事情时，往往会导致初始轨迹不再有效，因此项目将失败，因为它可能无法满足预算内的初始期限。将项目重新计划为最多几个月的短期增量是一种回应，我认为这是一个合理的方向，可以让项目获得良好的结果，因为许多项目可能必须适应不断变化的需求，这些需求很容易改变截止日期、人数或时间工作。
有两种可能：
我建议不要考虑处罚，而是进行事后分析以确定出了什么问题并找到改进下一个截止日期估计的方法。
我因为错过了最后期限而被解雇了，我已经完成了 98% 的产品，外部力量和最后期限是该公司不允许正确开发软件的。即使我承认我在这种情况下写了一些糟糕的代码，但我也写了一些很好的可维护代码。没有考虑功能蔓延，事实上没有预先详细说明技术规范，并且由于软件的有限和错误版本可供管理层审查，因此需要对功能进行调整。我本可以更好地沟通，但当我进行沟通时，强调截止日期是不可协商的。
当错过最后期限时，会想到两个明显的问题：
显然，如果有人给你一个没有意义的截止日期，那么错过截止日期不应该受到任何处罚。此外，如果有人因为被召集担任陪审团职责而错过了最后期限，也不应该对他们不利。
如果这些问题不适用，那么接下来要做的就是找出问题所在。如果您根据开发人员对编写代码需要多长时间的估计来估计某件事需要多长时间以及最后期限，那么他们的反应可能过于乐观。
你谈论最后期限和代码质量，就好像它们是零和游戏的一部分，你有一个或另一个。退一步来说，项目的整体成功取决于为公司/社区提供的整体收益——收益应在项目开始时明确确定，并且可以包括质量代码或上市时间或功能或整体质量或任何组合。成本/工作量是根据目标、环境和所涉及的人员估算的……无法准确确定成本或时间表（您无法预测未来），但您可以将它们设置为帮助导航的指南并确保最终的收益不会被努力所抵消。对于您的具体问题：
1. – 我看到使用了哪些惩罚措施？从解雇到不处罚——在大多数情况下，我没有看到任何行动，这可能是项目失败的最大原因（回答 #2）
2 – 导致项目失败的项目管理响应 – 不采取行动或专注于设定未来的任意时间表，而不纠正或解决未满足初始时间表的原因。
3 – 什么反应恢复了工作秩序？根本原因/风险分析，了解项目偏离的基本问题是什么。时间表和成本只是项目可能存在问题的指标，还有其他更有意义的指标，例如整体质量、团队道德和沟通，表明项目处于胁迫状态。
4 – 什么响应导致更糟糕的代码？没有回应或专注于按时完成任务，而不是实现预期收益。
项目经理应该因为错误计算截止日期而受到惩罚，而不是因为错过它......
给出估算后，规格或要求是否发生了变化？
我不提倡这一点，也没有实施任何这些，它们只是我听到的有趣/奇怪的东西
刚刚阅读和观看有关发布周期的视频（通常在 FOSS 中），常见的事情似乎是：
虽然我想那是给你的开源软件！
“谁在什么时候做什么”是每个项目团队成员在任何职业中都必须提供专业承诺/回应的问题。当错过最后期限时，使用该证据来改进估计过程并要求个人做出新的承诺。这假设他们实际上是对上一个截止日期的承诺。manager-tools上有一个关于“谁在什么时候做什么”的精彩系列。
另外，我建议您区分估计、目标和承诺。并管理估计<---差距--->承诺之间的'差距'或风险。 看看软件估计：揭开黑色艺术的神秘面纱。
他们最多会错过 2 次截止日期，之后他们可以错过任意数量的截止日期......
处罚应仅基于最初给予（或要求）截止日期的目的。