错过最后期限的惩罚/回应应该是什么？

Question

作为软件行业的新手，我遇到了一个关于最后期限执行的问题：

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

这次又是什么？在一个极端，我们可以解雇每一个参与其中的人，另一方面，我们可以丰厚地奖励每一个参与其中的人。

1. 你认为对错过最后期限采取了哪些措施作为“惩罚”，其中哪些行动最终产生了更好的代码？
2. 是什么项目管理回应导致项目彻底失败，
3. 哪些响应恢复了工作秩序并导致了随后可以维护的代码？
4. 是什么反应导致了更糟糕的代码？

Answer 1

最后期限是关于如何进行软件开发的一个根本错误想法的一部分。对于软件开发行业的新手或外部人士来说，他们不明白这一点：

软件是在完成时完成的，很快就会完成。

如果开发人员有一项任务和一周的时间来完成这项任务，而且看起来需要超过一周的时间，那么就什么也做不了。无论开发人员的工作多么辛苦，无论任务中增加了多少人，只要花费时间(事实上，添加人员通常会花费更长的时间)，这仍然需要花费很多时间。

相反，阅读敏捷开发过程。软件应该以迭代的方式开发，每一次迭代都应该基于上一次迭代的结果，而不是基于强加的外部需求。

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

我绝不会认为开发人员不能满足某种交付期望。我的观点是回应提问者提出的特定假设--商业软件开发的性质在某种程度上类似于学业，或任何其他类型的工作。我认为绝对不是。“截止日期”意味着不仅仅是一个简单的交货日期。它是一个固定的点，通过这个定点必须完成一定数量的工作。软件根本就不是这样工作的。我写了更多的段落解释为什么，但老实说，如果你还不相信，我说什么都不会说服你。

如果你在做一个软件项目，很明显你不能达到你的最后期限，你能做些什么来纠正这个问题呢？现在，答案是众所周知的:几乎什么都没有。你不能增加更多的人。你不能“工作得更快”。只是不能按时完成。你告诉干系人，每个人都会调整，继续工作(或不工作)。那么，原来的约会是什么意思？

任何声称软件开发类似于桥梁建设或家庭作业的人，或者说，如果开发人员齐心协力并努力工作，那么即将到来的最后期限仍然可以完成，他们对自己的职业深感困惑。

Answer 2

你的第一反应不应该是如何回应错过的最后期限，而应该分析你为什么错过了最后期限。由于这一原因，对错过最后期限的反应自然会随之产生。

例如，如果每个人都没有尽到自己的职责，就解雇他们。

但是如果他们做了他们的工作，还有更多，那为什么还会错过呢？同样的人做的其他活动太多了吗？对截止日期来说范围太大了.不现实的最后期限)。或者..。等。

在我的经验中，错过最后期限的主要原因是，人们不允许在手头的项目上100%地工作，因此，你可能有的任何估计，虽然他们自己都是准确的，但实际上是没有用的。再加上不切实际的估计和最后期限。

Answer 3

开发人员永远不应该因为管理人员的错误而受到惩罚。

就像父母惩罚孩子，因为父母的日子不好过。

推理：

最后期限是生活中的一个事实。人们想知道一件事需要多长时间。我们所能做的就是估计/猜测。这是管理的作用，试图发现这种神奇的，从来没有正确的猜测。当他们设定最后期限时，他们需要使用正确的工具(经验、向开发人员、律师、人力资源等寻求帮助)。

然而.

如果而不是重蹈工人的覆辙，他们将因错过最后期限而受到惩罚。这是管理层的错，因为错过了最后期限。他们应该说不，应该缩减项目，或者应该更好地激励工人。

在建筑工人中，如果你对工人撒尿，你就开始打架。在我的公司，如果我们错过最后期限，管理层就会陷入困境。不是工人。控制项目和完成什么是经理的工作。工人们只做他们能做的事。经理负责分配角色和任务。

我不是说工人的素质不是一个因素，但管理层应该知道这一点！不需要一个天才知道一个项目没有经过很好的思考或良好的控制。问任何人他们的经理是否知道发生了什么事，你就会发现问题所在。

当经理们意识到设定/同意最后期限是他们的错时，我们就不再错过那么多的最后期限了。

</rant>

Re:问题：

1.对于错过最后期限，你认为采取了哪些行动作为“惩罚”，哪些行动实际上使事情“更好”？

• 经理的责任较小。这个人不会得到晋升或公开感谢。这个人很可能会被转移到一个“不那么重要”的项目中。

2.什么样的项目管理响应导致项目彻底失败，哪些响应恢复了工作秩序，并导致了随后可以维护的代码？

• 特性爬行:经理不断在列表中添加更多的内容。<- -用一个按优先级排序的任务列表来解决这个问题。当你将事物添加到列表中时，将它们的优先级与其周围的事物进行比较。让新事物更难被设定为“首要任务”。
• 代码中有太多的bug:管理者需要测试(至少是关键的)和自动化。构建必须是标准的和自动的。真正的用户需要在代码“完成”之前看到它。
• 不可读代码:协会同行代码评审。如果有人有肮脏的代码，请让别人“帮助”他们做一个项目。
• 如果你有销售员的问题，推销员承诺的特性并不存在/工作:管理层需要介入并向那个推销员解释这个问题。而且，并不是，给销售人员公开肯定一份出色的工作有时会有所帮助。