Question

作为一个相对较新的软件行业，我遇到了最后期限执行的问题：

回到学术界的田园时代，截止日期是学期结束，惩罚是明确定义的'F'（或当地的等价物）。在现实世界中，我们需要制作当前和未来同行可以使用的代码，我面临截止日期到来，截止日期，项目仍未完成的情况。

现在怎样？在一个极端，我们可以解雇所有参与者，另一方面，我们可以丰富地奖励所有参与者。

您认为哪些行为被视为错过截止日期的“惩罚”，哪些最终会产生更好的代码？
哪些项目管理响应导致项目彻底失败，
哪些响应恢复了工作订单并导致后续维护的代码？
哪些回复导致更糟糕的代码？

Answer 1

截止日期是关于如何进行软件开发的根本错误观点的一部分。新手或软件开发行业之外的人不理解这一点：

软件在完成后即刻完成。

如果开发人员有一个任务和一个星期的时间来执行它，看起来需要一周以上的时间，那么就无法做任何改变。无论开发人员工作多么困难，无论有多少人加入任务，它仍然需要花费的时间（实际上添加人员通常需要更长的时间）。

相反，请阅读敏捷开发过程。软件应该迭代开发，每次迭代应该基于前一次迭代的结果， not 强加的外部要求。

根据以下广泛评论进行编辑：

我永远不会说开发商不能满足某种交付期望。我的观点是对提问者所提出的特定假设的回应 - 商业软件开发的性质在某种程度上类似于学校作业或任何其他类型的工作。我认为绝对不是。 “截止日期”不仅仅意味着简单的交货日期。这是一个固定的点，必须完成一定数量的工作。软件根本不起作用。我写了几段解释原因，但说实话，如果你还没有相信，我说的任何话都不会说服你。

如果您正在开发一个软件项目并且很明显您将无法达到截止日期，那么您可以采取哪些措施来解决这个问题？答案现在众所周知：几乎没有。你无法添加更多人。你不能“更快地工作”。它不会按时完成。你告诉利益相关者，每个人都要调整，并继续工作（或不工作）。那么原始日期是什么意思呢？

任何声称软件开发的人都类似于桥梁建设或家庭作业，或者如果开发人员只是把他们的狗屎放在一起并完成他们的工作，那么即将到来的最后期限仍然可以得到满足，他们对自己的专业感到非常困惑。

Answer 2

你的第一反应不应该是在错过最后期限时做什么，而是分析为什么你错过了截止日期。由于这个原因，对错过截止日期的回应将自然而然地跟随。

例如，如果所涉及的每个人都没有完成他们的工作，那就解雇他们。

但如果他们完成了自己的工作，那么为什么还要错过呢？同一个人做了太多其他活动？截止日期的范围太大（即不切实际的截止日期）。或者......等等。

在我的经历中错过最后期限的最主要原因是人们不允许100％在手头的项目上工作，因此您可能拥有的任何估计虽然准确无误，但在所有。那，加上不切实际的估计和截止日期。

Answer 3

开发人员不应因管理层的错误而受到处罚。

这就像父母惩罚孩子一样，因为父母有一个糟糕的一天。

<强>推理：

截止日期是生活中的事实。人们想知道需要多长时间。我们能做的最好的就是估计/猜测。管理层的角色是试图想象这个神奇的，永远不正确的猜测。当他们创建截止日期时，他们需要使用正确的工具（经验，寻求开发人员的帮助，律师，人力资源等）

<强> 然而....

错过截止日期的处罚应该不依靠工人。错过最后期限是管理层的错。他们应该说不，应该缩减项目或者应该更好地激励工人。

在施工人员中，如果你惹恼工人，你就会开始战斗。在我的公司，如果我们错过最后期限，管理层会遇到麻烦。不是工人。控制项目和完成工作是管理者的工作。工人们只是尽他们所能。经理负责分配角色和任务。

我不是说工人的素质不是一个因素，但管理层应该知道！知道一个项目没有经过深思熟虑或控制得很好，这并不是一个天才。问任何人，如果他们的经理知道发生了什么，你会发现问题。

当管理人员意识到设置/同意截止日期是他们的错误时，我们不再错过任意截止日期。

</rant>

回复：问题：

1.你看到哪些行为被视为错过截止日期的“惩罚”，哪些行为实际上让事情“变得更好”？

经理责任较少。这个人没有得到晋升或公开表示感谢。最有可能的是，这个人将被转移到“不太关键”的项目中。

2.项目管理响应是什么导致项目彻底失败，以及哪些响应恢复了工作订单并导致代码可以在以后维护？

功能蠕变：经理不断在列表中添加更多内容。＆lt; - 使用按优先级排序的任务列表来解决此问题。当您向列表中添加内容时，请将它们的优先级与周围的内容进行比较。让新事物更难被设定为“头等大事。”
代码中存在太多错误：Manager需要测试（至关重要）和自动化。构建需要标准化和自动化。真正的用户需要在“完成”之前查看代码。
不可读的代码：研究所同行代码审查。如果某人有脏代码，请让某人用项目“帮助”他们。
如果您有销售员问题，销售员承诺不存在/工作的功能：管理层需要介入并向该销售员解释问题。此外，不让销售人员公开肯定工作做得好有时有助于此。

Answer 4

而不是惩罚，如何实际估计和奖励准时发布？

受到对我的回复的评论的启发

也许问题应该是“如何进行实际估算？”对我来说，我使用FogBugz estimation history和completion date图。这些给出了我估计要完成任务的时间和实际花费的时间的数据点。这有助于指导我从长远来看实际的发布日期（它不会在一夜之间发生）。我发现估计时间表是一个交互过程：我

设计
估计
开发
找到设计中的缺陷＆amp;迭代。

Answer 5

取决于开发人员是否为每个修改请求设置了截止日期，或管理员是否为他们设置了这些截止日期。

在后一种情况下，除非您的所有开发人员全天都坐着玩Halo 3，否则错过的截止日期通常表明管理层或团队领导的错误。因此解雇所有人都无法解决问题。在您的软件过程中引入更好的指标可能是有意义的，这样您就可以看到截止日期很早就会错过。

如果您的开发人员确实给出了时间估算，那么我会非常小心奖励和惩罚开发人员以满足截止日期或错过他们。这样做的结果可能是他们会在时间估计中调整他们的“软糖因子”。他们会给自己太多的额外时间（获得奖励），如果他们擅长估计会让事情变得混乱。您的目标应该是让他们提供良好可靠的估算，而不是改变他们的工作方式来满足这些估算。

Answer 6

死亡。干净简单。

Answer 7

这取决于最初的截止日期是否可行，可能是计划和估计需要多长时间的错误。在决定处罚之前，请确保你知道截止日期的原因

Answer 8

哦，伙计......

首先，有外部截止日期和内部截止日期，它们应该是不同的。

内部截止日期发生的事件是活动频率随着截止日期的临近而增加，在截止日期达到峰值，然后随着截止日期的消退而下降。因此，计划外部截止日期至少在几个星期内遵循内部截止日期。

然后，确保截止日期是真实的。部分是通过让开发人员参与设置，以及决定将要完成什么来做到这一点。

最后，我主要是一名开发人员，但有一次我在管理层工作时，我绝不想将最新版本的版本带入会议或演示文稿中。我想要一个至少几个星期的版本，我知道问题出在哪里，我确信不会包含令人不快的意外。

Answer 9

在他关于项目管理的精彩书中 - "Deadline" - 汤姆德马科告诉我们一个故事，关于来自西方世界的项目经理正在管理一个虚构的后共产主义东欧野生国家的项目（野生是一个真是个好词，因为公民有点......不文明）有一天，PM发现，出了问题，他的项目的某些部分突然错过了不切实际的时间表。前任总理只是将责任人挂在屠夫的钩子上，对失踪期限设定了处罚，但由于时间表不切实际，一名男子已经错过了截止日期。
所以这个故事告诉我们一天，当西方式的PM出现在一个负责任的人身上时，他应该让他被绞死在屠夫的钩子上。正如大多数人所做的那样，PM害怕将某人判处残酷死亡的愿景只是因为有些人无法及时完成他的项目。并且 - 无论如何 - 挂这个可怜的人并没有推进这个项目。由于这是关于项目管理的小说小说，而不是关于折磨，我们的英雄取消了惩罚但这个故事背后有一个重要的问题就是悬挂某人：如果你设定了截止日期，并因错过这个截止日期而设置某种惩罚，那么这一天将会到来，你可能不得不实际惩罚某人。你会这样做吗？无论惩罚是什么：悬挂，奖金损失，解雇，破坏交易或一些费用 - 你可能必须惩罚某人。这种惩罚会对你的项目有所帮助吗？你必须自己回答。
所以：不要因为错过最后期限而设定惩罚，你不会想要执行......

Answer 10

正如其他人所说，在谈论处罚之前，先从“我们如何确定这些截止日期是否切合实际”开始？

或者正如我的老板曾经说过的那样，“当你给我们一个有效的计划时，我们会很乐意制定一个计划”。

我仍然认为这应该是T恤。

Answer 11

一旦你达到了人们的最后期限，你必须问自己（A）这是什么的自然结果，以及（B）你如何才能最好地完成任务并保持某种运动实现业务目标（即使您没有经营业务）。

明确惩罚人们因为截止日期限制不太可能有所帮助，除非他们相信他们已经赢得了它。如果截止日期不切实际，如果团队的某些要素是主要的失败点，如果要求存在严重问题，或者所涉及的大多数团队都认为上述因素是真的，那么这种情况就不会发生。 / p>

在一个案例中，我在一个团队中，将一个小型交付项目的截止日期超过三个月 - 原始交付日期从开始就是三个月！我们误解了要求，没有充分与客户交谈，并低估了所涉及的时间。管理层完全没有责任指责。这部分是因为它对完成可交付成果起反作用，部分原因是我们都不是“问题员工”，部分是因为管理层知道我们都非常积极地解决问题并满足客户。所以我们完成了它，客户就像预期的那样快乐，我们继续我们的生活，并提供了一些关于如何避免将来出现这种情况的宝贵经验。

Answer 12

没有罚款。 “截止日期”和估算已经并将继续成为软件开发中最难和最具挑战性的部分之一。

对这个问题对开发者施加惩罚是荒谬的。

Answer 13

到目前为止，在我的职业生涯中，我没有看到错过截止日期的任何真正的处罚（而且我错过了很多）。我认为，在公司向公众承诺的商店中销售软件或游戏的公司会有所不同。

但是在定制软件开发领域，要准确估计项目需要多长时间是如此困难。而且这种事实常常被各地的公司所接受。

Answer 14

虽然我从未见过任何纪律处分或解雇，但我看到很多“强制性”加班和同伴压力要长时间工作。

我几乎被解雇作为经理告诉球队报告我不要在周末进来并且工作到很晚。我知道这些事情对项目和士气都是有害的。

一般来说，“惩罚”的形式是让人感到内疚或焦虑，但我确信有些地方可以做更多“官方”的事情。

这个世界充满了白痴。管理层也不例外。

Answer 15

我认为这个问题本身就表明了对管理和项目管理角色的误解。

不幸的是，许多人心中都有一种共同的看法，即管理者在其头衔中用“管理”这个词来表示对慵懒工人的屁股进行治疗。它也适合那些相信帕金森定律的人。

不是。这是为了使作品能够完成他们的工作 - 无论是他们与组织的其他部分之间的沟通渠道，获取资源，还是干扰（将家具移开）。

也就是说，PM应该已经知道项目/任务将错过它的截止日期。他们应该提问，并知道发生了什么。他们有能力削减任务或增加/重新平衡资源以完成工作（或者说赞助商，如果你不提供资源，它没有按时完成）。因此，无论是什么都没有，舌头鞭打，降级或终止，惩罚都归于PM。

有时延迟是不可避免的。这就是我们建立应急时间的原因。有时，这是一个已知的风险;只要你有备份计划 - 你没事。

对于回复，您有四个参数：范围，时间，金钱和质量

范围 - 你可以削减截止日期。
时间 - 是固定的。你可能会让你的员工在60小时内拉一两个星期，但之后你的工作效率会开始下降。如果你公平地支付它，它也会花费更多的钱。
金钱 - 你可以从别人那里购买零件来加速这个过程。你甚至可以雇佣更多的人，如果你的工作足够脱节，你就不需要与现有员工进行大量的沟通 - 参见布鲁克定律
质量 - 理想主义的傻瓜声称你永远不会吝啬质量。但是你可以。你没有添加错误（一种形式的反质量）;但你可以降低质量。你编写你的功能，以便它可以处理无限长度的字符串，或者这个版本足够100个字符？您是否可以轻松地进行下一次升级以锁定新模块，或者将其焊接关闭并担心在执行下一个版本时添加插件模块。

没有足够积极地做这些事情（必要时）肯定会导致你失败。

Answer 16

一旦项目迟到，就没有太多“管理”（好的，坏的，好的或恶意的）可以做到，这不会导致项目甚至更晚

......唯一的例外可能是移除/避免外部干扰。

Answer 17

你的问题本质上存在缺陷：它假设惩罚是管理员工的最佳方式。一般而言，人们对惩罚或惩罚威胁反应不佳;它揭示了最糟糕的行为，使动机变得外在，并分散了内部动机。奖励和贿赂（奖励的威胁）是同一枚硬币的另一面，并没有更好的效果。

然而，这些力量是为了招聘而工作的，所以你永远不会从你的程序员那里得到最好的创造性工作，但你不必在他们错过截止日期时惩罚他们。 / p>

相反，冥想创作过程，多人做创造性工作的混乱，以及哪些工具可以有效地管理混乱。

要管理任何混乱的系统，请进行大量测量并准备好快速更改课程。在编程的情况下：

尽可能采取最小的步骤。不要“把任务分成小步骤”，因为你会浪费很多时间来计划不会像你计划的那样工作的步骤。混乱，还记得吗？
选择提供最多值的最小步骤。
经过一段时间后，根据您所学的内容重新评估您的计划
尽快向实际客户提供工作软件，以便他们可以告诉您真正正在做什么。
< / LI>

你可能认为这是SCRUM背后的思想。

Answer 18

如果您错过了截止日期，请修改预算。

Answer 19

取自企业发展的观点......

如果截止日期来自执行工作的人以外的其他人，请查看情况以确定超限的原因。在这些情况下，它通常与不完整的要求，范围蔓延，管理不善等有关。不应该因错过该人从未提供过的最后期限而受到惩罚。

如果截止日期是由执行工作的个人提供或同意的，那么该人需要解释导致延迟的因素。此外，应提醒此人在他们意识到可能错过最后期限时立即通知他们的主管，项目经理或其他责任方。截止日期过后，此信息不应曝光。如果反复发生这种情况，应遵循贵公司的纪律程序。这可能涉及报告，暂停或终止。

人们倾向于在设定截止日期时真正拥有截止日期。如果在没有他们输入的情况下对他们进行截止日期，那么截止日期往往对执行工作的人毫无意义。

Answer 20

我因错过截止日期而被解雇，我98％完成了产品，外部力量和截止日期，该公司不允许软件正确开发。即使我可以承认我在这种情况下写了一些不好的代码，但我也写了一些很好的可维护代码。没有考虑特征蠕变，事实上没有提前详细说明技术规范，并且需要对功能进行调整，因为有限的和有缺陷的软件版本可用于管理评审。我可以更好地沟通，但当我确实沟通时，强调最后期限是不可协商的。

Answer 21

或许更好的问题是，面对不准确的估算，最后期限是否有意义？企业做lousy job of estimating software - 这是事实。管理层和开发人员都参与其中，似乎没有人愿意承担他们在这个问题上的责任。

但是要回答你的具体问题：

1.你看到哪些行为被视为错过截止日期的“惩罚”，并且其中哪一个最终导致了更好的码？

对于管理人员和开发人员错过最后期限我看到的“惩罚”从无到有，从促销到简单转移。我亲眼目睹的最严厉的处罚是经理“转移”到一个不太重要的项目，并且业务部门失去了经济奖金。

我唯一一次看到有人在错过的截止日期前被解雇是因为该员工已经被解雇了 - 截止日期为该企业提供解雇员工的合法理由。

2.项目管理层的回应是什么导致项目彻底失败？

这是一个完全独立的讨论......但这个问题存在一些固有的偏见 - 项目管理有问题。

我亲眼看到的三件最重要的事情是，破坏项目的是（按严重程度排序）：

忽略其技术人员的数据/建议/警告。
在开发过程的早期询问估算。这导致估计误差为10倍（需要一个月，给予或需要十个月）。
拒绝/修改/要求软件估算，以便它们适合任意预算和计划。这并不是说开发人员应该忽视业务需求 - 而是需要开发人员和非开发人员平等地设置业务需求。

3.什么响应恢复了工作订单并产生了可能的代码以后要保持？

我还没有看到一个功能性的软件开发组织。因此，修复通常是一些英雄开发人员的大量血液，汗水和眼泪，他们与一位知识渊博的PM工作，他们知道如何在公司内部捍卫政治（即将BS从他们的员工中转移）。

4.什么回复导致更糟糕的代码？

喊叫。咒骂。侮辱。（可悲的是，这仍然发生在一些工作场所）
更多“项目管理” - 通过人员，会议，状态报告。
在此过程的早期获得软件估算，以便“我们可以更好地进行规划”。当您的员工拥有更多数据并更好地了解问题时，估计需要更晚。
溺爱开发人员（这不是你的错，经理搞砸了）。
溺爱项目经理（这不是你的错，开发人员搞砸了）。
为项目添加额外的，不合格的员工。

Answer 22

项目管理的主要目标是及时规划应用程序的构建方式。如果你没有一个计划表明你将在项目将持续的每一天做什么，你就不应该开始你的项目开发。

通过这种方式，您可以检测到您将会迟到，只要您按照常规（每周，如果不是每天）的方式跟踪项目的演变。而且你知道的越早，你就越早采取行动。

您通常有两种选择：

赶上（通过雇用额外的工作人员，工作更多或删除功能）。
告诉您的客户出现了问题（甚至更好：出了什么问题），您将需要更多时间。

对于第二种选择，我并不意味着不会有任何惩罚。但从我个人的经验来看，只要提前通知客户并提供解决方案（最好是三个：为额外的工人提供更多的钱/删除功能以节省一些时间/接受项目迟到），他们将开放协商。哪个总是好于冲突:)）

Answer 23

这不是一个编程问题，而是更多的管理问题。

错过最后期限很少是开发人员的错。作为开发人员，你应该尽力做好尽可能好的工作，但最终每个人都能做到这一点。如果开发人员付出了诚实的努力，尽管如此，错过了截止日期，这意味着开始时的截止日期是不现实的。

处理最后期限是管理者的责任。有不同的方法，但没有一个包括“惩罚”开发人员做他们的工作。这里要理解的重要一点是所谓的项目管理triangle。这意味着软件项目可以是好的（即满足要求，质量好），快速（满足最后期限）和廉价（人员，工具）。麻烦的是，这3个属性中只有2个可以选择。

因此，如果管理层想要一些好的和快速的东西 - 它就不会便宜。

如果管理层想要一些好又便宜的东西 - 那就不会很快。

最后，如果管理层想要便宜又快速 - 猜猜是什么，它就没有任何好处。

因此对错过截止日期的正确回答取决于所选择的方案。好又快需要添加一些额外的帮助，更好的工具，对高于平均水平的开发人员的投资等等。

好的和廉价的定义假设最后期限将被错过（暴雪，魔兽世界的制造商就是这种方法的好例子）

最后，廉价和快速通常意味着削减功能和释放错误。

Answer 24

根据开发人员及其潜在客户的所有建议设置不切实际的短暂开发时间表会受到什么惩罚？

巧合的是，这似乎几乎与开发团队错过发货日期的情况一样频繁发生。

Answer 25

我看到高管在错过一些截止日期后不久离开了公司。这改变了一切，但并不一定会使事情变得更好或更糟。我已经看到了一些合同义务，比如回扣，这是一种惩罚某人错过截止日期的方式，我不确定他们的工作情况。
当一个项目在项目的分配时间中途完全改变项目时，往往导致初始轨迹不再有效，因此项目将失败，因为它可能不会满足预算内的最初截止日期。将项目重新计划为最多几个月的短增量是一个响应，我认为这是一个合理的方向，可以让项目取得好成绩，因为许多项目可能需要适应不断变化的要求，这可能很容易改变最后期限，人数或工作时间。

Answer 26

你问“惩罚应该是什么......”。看起来你是从“公司内部”的角度提出的。

在现实生活中，处罚往往是迅速和严厉的 - 业务损失，诉讼，业内不良声誉。这些是客户在某个特定日期之前承诺的未实现的罚款。

在内部，你经常可以做任何你喜欢的事情。但是一旦你开始涉及付费客户，那么管理这些客户就成了整个工作的关键部分。

我所描述的惩罚通常可以通过与客户的“最高”沟通来避免（或减少）。如果客户想要添加一些东西（所谓的特征蠕变），那么应立即回答这些变化对项目的影响（成本更高，后期交付，无论如何）。应鼓励客户根据截止日期和预计成本对所有此类请求进行分类（即让客户管理功能蠕变，而不是您）。

如果其他事情改变了交货时间，那么一旦您知道会出现滑点，您必须通知客户。如果提前完成，客户非常愿意与您合作。但是，如果你没有说什么，直到为时已晚，他们就不太可能原谅......特别是如果他们发现你早知道这段时间并且没有告诉他们。

干杯，

-Richard

Answer 27

有两种可能性：

错过了截止日期，因为有人没有做好自己的工作。
截止日期不切实际。

我会建议进行验尸以确定出现问题并找出改善下一个截止日期估算的方法，而不是考虑处罚。

Answer 28

“谁在何时做什么”是每个项目团队成员必须在任何职业中提供专业承诺/回应的问题。在错过截止日期时，使用该证据来改进估算过程并要求个人做出新的承诺。这假设他们实际上是对上一个截止日期的承诺。在manager-tools上可以找到关于“谁在什么时候做什么”的精彩系列。

另外，我建议您区分估算，目标和承诺。并管理“差距”或估算之间的风险＆lt; --- gap ---＆gt;承诺。 Look at Software Estimation: Demystifying the Black Art.

Answer 29

你谈论截止日期和代码质量，好像它们是零和游戏的一部分，你有一个或另一个。只需退一步，项目的整体成功基于提供给公司/社区的整体利益 - 应在项目开始时明确确定收益，COULD包括质量代码或上市时间或功能或整体质量或任何组合。成本/工作量是根据目标，环境和相关人员估算的......没有办法确切地确定成本或时间表（您无法预测未来），但您可以将它们设置为帮助导航的指南并确保努力不会超过最终的利益。针对您的具体问题：
1. - 我看到过哪些惩罚行动？从射击到没有惩罚 - 在大多数情况下，我看到没有采取任何行动，这可能是项目失败的最大原因（回答＃2）

2 - 导致项目失败的项目管理响应 - 没有采取行动或专注于设置未来的任意时间线而不纠正或解决未达到初始时间线的原因。

3 - 恢复工作顺序的响应是什么？根本原因/风险分析，了解项目偏离的基本问题。时间表和成本只是项目可能存在问题的指标，还有其他更有意义的指标，如整体质量，团队道德和沟通，这些都表明项目受到胁迫。

4 - 什么响应导致更糟糕的代码？没有回应或者专注于达到最后期限而不是实现预期的利益。

Answer 30

在给出估算后，规格或要求是否发生了变化？

Answer 31

错过截止日期时会想到两个明显的问题：

截止日期是否可行？
外部因素是否会影响绩效？

显然，如果有人向您提出了没有意义的截止日期，那么错过截止日期不应该受到任何惩罚。此外，如果有人错过了截止日期，因为他们被征召出任陪审员，也不应该对他们提起诉讼。

如果这些问题不适用，那么接下来要做的就是弄清楚出了什么问题。如果您根据开发人员估计他们编写代码需要多长时间来估计需要花多长时间以及截止日期，那么他们的回答可能过于乐观了。

Answer 32

项目经理应该因错误地计算截止日期而受到处罚，而不是错过它......

Answer 33

我不是在鼓吹这一点，我也没有实施任何这些，他们只是我听到的有趣/奇怪的事情

刚刚在发布周期中阅读和观看视频（通常在FOSS中），常见的事情似乎是：

嘲
本周佩戴'笨蛋帽'（对于没有及时投稿的人）
从树上禁止（用于ABI / API破损和事物）

虽然我认为这是开源软件！

Answer 34

罚款应仅基于首先给出（或要求）截止日期的目的。

Answer 35

他们最多会错过2次截止日期，之后他们会错过最多截止日期......

错过截止日期的罚款/回应应该是什么？

37 个答案: