我的员工中有一个开发人员长期超过截止日期和估计。在过去一两周的几个项目中，我每天都会听到“应该在一天结束前完成”。这个开发者做得很好。
我已经和他谈过他的问题。他似乎真的很沮丧，并且对如何纠正它们感到恼火。
我的问题是：
更新：根据回复；这就是我想出来的。
感谢您的链接和信息。也感谢您更新我的想法。
我认为问题不在于他错过了这些最后期限。
我认为他在估计完成一项任务所需的时间方面确实存在问题。
让他开始记录他所说的任务将花费的时间以及他完成任务实际花费的时间。最终，这本期刊将成为他做出更好估计的指南。一旦他变得更好地估计，他就不应该感到匆忙或烦躁。
Joel Spolsky 有一篇有趣的文章：基于证据的调度
1) 分解
当我看到以天甚至几周为单位的时间表时，我知道它不会奏效。你必须把你的日程安排成非常小的任务，这些任务可以用小时来衡量。不超过16小时。
这迫使你真正弄清楚你要做什么。编写子程序 foo。创建此对话框。解析 Fizzbott 文件。个人开发任务很容易估算，因为您以前编写过子例程、创建对话框和解析文件。
如果您马虎，并且选择了为期三周的大任务（例如，“实施 Ajax 照片编辑器”），那么您还没有考虑过您将要做什么。详细地。一步步。而当你还没有想过你要做什么的时候，你不知道需要多长时间。
设置 16 小时的最大值会迫使您设计该死的功能。如果您有一个名为“Ajax 照片编辑器”的手动波浪式三周功能而没有详细设计，我很抱歉成为您破坏它的人，但您注定要失败。你从来没有想过它会采取哪些步骤，而且你肯定会忘记很多。
重点是他（和你）应该从他的错误中吸取教训，并在下一次估计时考虑到它们。
另外，如果您是开发人员，我会在一天结束时进行定期代码审查，以更好地了解他的开发过程。
当然，更小的迭代和更细化的任务。将最长任务持续时间设置为 1 天。这就是我们的规则。
如果你的第一个问题是 要考虑什么样的惩罚， 我认为你马上就输了。如果你觉得他做得很好，你可能需要查看最后期限/估计，看看它们是否一开始就切合实际。谁设置了它们，如果有问题的开发人员没有参与，那么这可能是问题的一部分。
我同意@OTisler 的观点，即结对编程以及可能与您自己定期进行的一天结束进度审查可以帮助他完成……尽管如果从一开始就截止日期/估计不切实际，那不是您的问题所在。
对一些特定任务进行更密切的监控应该突出任何问题所在。
什么样的逾期处罚是有效的？
没有任何。如果你激怒了他，他不会做这项工作，或者他会另找工作。你应该帮助他弄清楚为什么他的估计是错误的。史蒂夫·麦康奈尔 (steve McConnell) 有一本书是关于估算的。我会从那里开始。
我可以通过什么方式让该员工自己监督他的行为（时间估计等）？
通过帮助他找到正确的估算方法。
首先，确保您的要求非常明确。
我不想这么说，但根据我的经验，最后期限过长通常是主管要求不明确或规范薄弱的问题。首先要做的是确保问题不是源于您，也不是由您加剧。
此外，请确保您的要求以及他的估计是现实的。
确保您自己的期望不会促使他做出不切实际的估计以满足不切实际的要求。
请记住，您完成了需求，但开发人员总是进行估算，并且不应被“我们能不能更快地做到这一点”所左右，除非您还指定要删除的功能。
然后，确保他准确地跟踪他的时间/任务，这样你就可以很好地了解项目的进展情况。
此过程将显示任何缺乏适当的时间/任务跟踪，这可能最终成为改进的第一步。如果您在项目结束后看不到某个特定项目花费了多长时间，那可能就是问题的原因——估计中没有足够的定义，或者缺少在项目中期发现但从未估计过的“依赖”任务.
您必须准确地知道花了多少时间在做什么，然后才能找出蠕变在哪里，或者可以做些什么。
然后，看看他的估计在哪里失败并找出原因。回顾一个被吹的项目的估计，把它变成一个项目本身——一个有待解决的问题。
一旦您确定他的估计确实是问题的根源，请检查他的估计，也许还有另一个开发人员，并找出原因。
这将帮助您找出问题的原因。对问题的深刻理解可能是实际的解决方案。
最后，如果你真的到了必须尝试惩罚或胁迫的地步，是时候解雇他并重新开始了。
在某些情况下，惩罚和胁迫是对故意不法行为的适当回应。
但是，如果该开发人员正在积极尝试做好工作，那么您只会通过产生消极态度和挫败感来恶化情况。
如果问题无法解决，并且您确定问题出在他身上，而不是您身上，那么是时候解雇他并找一个能按时完成的开发人员了。当您的成本被夸大并且利润消失时，出色的工作并不意味着什么。
好的，这是相当普遍的——开发人员很乐观。处理它是管理层的工作。如果有人应该受到惩罚，那就是经理（你？）
我很高兴你至少问了，看起来你从这个列表中得到了一些很好的答案，我希望他们能帮助你，你找到一种方法来实际实施一些工作。
当我年轻的时候，我的第一个好经理是这样处理的：
首先，他让我列出一个分项清单——将任务分解为几个小时，并用非常宽松的估计来估计每一个——不管任务有多小，时间都不应该少于 4 小时。
然后他看着他们，告诉我把我所有的估计翻一番。（开发人员，尤其是年轻的开发人员，不要考虑这样一个事实，如果你幸运的话，你一天只有大约 1/2 的工作效率——而其中的一半都花在了你没想到会做的事情上做）。
然后，在制定他的时间表之前，他将我所有的估计翻了一番（没有告诉我）。
他以这种方式转动它们，而不考虑上面的时间表要求。一个好的经理应该意识到，说需要在 2 天内完成，并不能让它成为可能。
随着我的估计越来越好，我们都注意到并相应地进行了调整。
经理的工作不仅仅是做一个项目，而是建立一个团队。这通常需要某种形式的培训。这也是不是工程师的工程经理不能接受的原因，他们对这种事情真的无能为力。
项目或时间表的失败实际上绝不是开发人员的错（除了在一些长期案例中，他无法真正修复或没有任何价值并且需要被解雇）。经理在雇用开发人员、信任他、管理他或为项目配备人员方面做出了错误的决定。
真的，有什么错呢？我想如果经理不是很擅长使项目发生，他将需要有人指点...如果他的经理有什么好，他会问为什么它会走到这一步，你做了什么来解决它， ETC。
雇用经理就是雇用某人来解决问题。使开发人员富有成效。如果他不能让他们富有成效，那么他就不是合适的人选。
对于您的问题：
但我有一些问题我认为你需要考虑。
他比其他人晚吗？如果是这样，为什么——是因为他是一个过于乐观的估计者还是一个缓慢的工人？过于乐观的估计很容易解决 - 只需将他的所有数字乘以上述基于证据的调度的一个因子。如果他是一个慢工，为什么？他会分心吗？他是否非常小心地产生了非常低的缺陷代码？他是否过度设计解决方案？他没有有效地重用代码吗？
截止日期是否重要，或者它们只是基于估计的任意日期，以报告管理层的进度？如果是后者，您可以通过自己调整他的估计来解决这个问题。
什么样的逾期处罚是有效的？
你陈述了重点并错过了它。超过最后期限的明显惩罚是死亡。如果开发人员在过了最后期限后仍然活着，那么“最后期限”显然不是真正的最后期限。你觉得用军事语言给开发者施加压力很有趣吗？
修正你的措辞。
首先：阅读Peopleware
下一个。为什么你认为惩罚将是管理应该有创造力的人的有效方法？我认为你必须重新考虑管理与团队的整个方法。
在我看来，经理首先，也是最重要的角色是确保开发人员能够富有创造力和生产力。并不是说他们富有成效。那些小字有很大的不同。要发挥创造力，您需要一个安全的环境。通过不断受到最后期限和惩罚威胁的压力，你创造了与安全完全相反的东西。
此外，作为经理，您需要准确的信息作为决策的依据。这也需要一个安全的环境。如果因为诚实和直言不讳而有受到惩罚的风险，那么您肯定会得到谎言和缺乏信息。一个非常危险的决策基地。
正如其他所指出的，估计是估计。在我们的团队中，我们根本不进行任何个人估算，我们作为一个团队进行估算。（我有点不愿意称我们所做的为 Scrum，但其中大部分都试图效仿） ,1/2,1,3,5,8,13,20,40,60,100 和在估计任务时每个开发人员选择一张卡片（卡片隐藏，直到每个人都选择一张卡片以避免影响估计）和平均选择的卡片作为估计值。
注意数字是如何逐渐变得不那么准确的。这是设计使然，因为大估计必然不太准确。
对于我们的团队，我们选择使用单位“理想工日”进行估算。早在我们任何人的记忆中，理想的一天还没有发生，但是当您知道如何将日历天转换为“理想的人日”时，这是一个很好的基础。
正如 Scrum 规定的那样，开发是在两周的冲刺中完成的，然后在生产环境中部署新版本。在每个 sprint 之后，我们将已完成任务的估计总和除以 sprint 的计划工日。然后，这个因素是估计团队在两周内可以花费多少“理想人日”的基础。
单个开发人员完成的实际工作项目不需要估算。第一个近似值始终需要 1/2 - 1 天才能完成。如果这个估计结果是错误的，你只需找一个开发人员一起做就可以完成它。或者您将工作项分解为较小的任务，以便更好地分配。
按照@OTisler 的建议设置里程碑并尝试敏捷。
我认为你不应该惩罚他。只要让他了解如何做出准确的估计。
作为团队负责人，我的团队成员告诉我，在截止日期前完成 X 功能“没问题”。然后我通常会和他们坐下来讨论我认为需要完成哪些任务和子任务才能完成该功能，以及开发人员认为每个任务需要多长时间。
在我们做完这个练习，并把所有的任务和子任务估计加起来之后，它不可避免地会比开发人员在他们最初的估计中认为的要长得多。在他们开始做出更准确的估计之前，我通常只需要和他们一起做几次这个练习。
令我惊讶的是，你只有其中一个人。
工程师在估计某件事需要多少时间方面很糟糕。我敢打赌，如果您仔细查看其他开发人员的估计，您会发现很多填充。有时填充不是必需的，但任务会扩展以填充可用时间。
解决这个问题的方法是改变你做估计的方式——对每个人。开发人员可能不擅长估计绝对时间，但他们在相对时间方面相当出色。所以在星期一，不要问“添加 whoosiwhatsit 需要多长时间？”而是问“在不到一周的时间内，你能在 whoosiwhatsit 上完成什么？” 这成为他们本周的任务。
下周一你看看它是怎么回事。“好吧，我在两天内安装了 floogle，但结果证明它影响了 mcphee……所以这周我需要解耦这些家伙，这样 whoosiwhatsit 文件就不会被覆盖。” 好的，这是他们本周的任务。
您可能认为这无济于事，因为您仍然不知道 whoosiwhatsit 什么时候准备好。确实如此。您在这里有两个选择：
如果你需要一个截止日期，那么你必须强迫你的错误开发者像其他人一样填充他的估计。他很快就掌握了窍门，而且他很快就会花“两周”的时间来写一些本来应该花一天时间的东西。
你的另一个选择是用虚构的估计来换取更多的可见性。从长远来看，这种方法会让你的工程师更有效率，也更快乐。
所以开发人员做得很好，但在估计交付时间方面很差？我不确定你手上是否有惩罚的情况。
也许再过一段时间，让他引导您完成估算交付点的过程。这可能是一个问他为什么步骤 X、Y 和 Z 需要一定时间的机会。他可能会发现自己只是通过以几乎可以肯定是较慢的速度进行练习来修改他的估计。
问问自己：你的工作是什么？
如果你只是盲目地将开发人员的估计（你知道他们不能给出好的估计）传递给管理人员，而不是自己决定这个估计是否可以实现，那么你就没有做好你的工作。
试着从“增值”的角度来思考（我的一位老雇主经常使用这个词，我讨厌它，但在这种情况下它可能对你有用）。你在增加什么价值？如果你只是在高层管理人员和开发人员之间双向传递东西，那么最终你不会赚钱。你可能会被删除，什么都不会改变。
我曾经遇到过的最好的经理是一个看过另一支球队给他的一系列要求的人，并直截了当地告诉他们，其中近三分之一是公牛，并在我还没看到名单之前就将其删除。我曾经让我编写所有这些额外的管理类型文档的最糟糕的文档，我曾经要求我做的其他经理都没有（我真的觉得我真的是在为他做他的工作），没有甚至给我项目截止日期，几乎没有上班。他们都在同一家公司，很奇怪。
90 小时是一种常见的短期项目期限。简单的方法不是估计“你的时间”，而是测量另一个。计算机程序员不应该为他们的项目做时间估计，因为有证据表明计算自己的时间会导致比观察他人更大的错误。