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