I don't think the problem is that he is missing these deadlines.
I think he has a real problem in estimating the amount of time it will take to complete a task.
Have him start keeping a journal of what he says a task will take and how long it actually took him to complete the task. Eventually, this journal will become a sort of guide for him to create better estimates. Once he becomes better at estimating, he shouldn't feel as rushed or harried.
When I see a schedule measured in days, or even weeks, I know it’s not going to work. You have to break your schedule into very small tasks that can be measured in hours. Nothing longer than 16 hours.
This forces you to actually figure out what you are going to do. Write subroutine foo. Create this dialog box. Parse the Fizzbott file. Individual development tasks are easy to estimate, because you’ve written subroutines, created dialogs, and parsed files before.
If you are sloppy, and pick big three-week tasks (e.g., “Implement Ajax photo editor”), then you haven’t thought about what you are going to do. In detail. Step by step. And when you haven’t thought about what you’re going to do, you can’t know how long it will take.
Setting a 16-hour maximum forces you to design the damn feature. If you have a hand-wavy three week feature called “Ajax photo editor” without a detailed design, I’m sorry to be the one to break it to you but you are officially doomed. You never thought about the steps it’s going to take and you’re sure to be forgetting a lot of them.
The main point is that he (and you) should learn from his mistakes, and take them into account on the next estimation.
Also, if you are a developer, I would do regular code review at the end of the day to get a better insight into his development process.
And, of course, smaller iterations and more granularity with tasks. Set the maximum task duration to 1 day. That's the rule we have.
If your first question is what kind of punishments to be considering I think you're on a loser straight off. If you feel he does good work you may have to look at the deadlines/estimates and see if they were realistic in the first place. Who set them, if the developer in question was not involved then that may be part of the problem.
I agree with @OTisler that pair programming and possibly a regular end of day progress review with yourself can help him through... although if the deadlines/estimates were unrealistic to begin with thats not where your problem lies.
Closer monitoring on a few specific tasks should highlight where any issues lie.
What kinds of punishments for passing a deadline are effective?
None. If you anger him, he won't do the work, or he'll find another job. You should help him figure out why his estimates are off. There is a book by steve McConnell about making estimates. i would start there.
What ways can I coherence this employee to police his actions(time estimates, etc.,) himself?
By helping him find the right way to make estimates.
First, make sure you are crystal clear in your requirements.
I hate to say it, but in my experience, blown deadlines are just as often a matter of unclear requirements or weak specifications on the part of a supervisor. First thing to do is to make sure the problem isn't either originating with, or exacerbated by, you.
Also, make sure your requirements are realistic, as well as his estimates.
Make sure that your own expectations aren't pushing him to make unrealistic estimates in order to meet unrealistic requirements.
Remember, you do the requirements, but the developer ALWAYS does the estimates, and should not be swayed with "can we do this any faster" unless you are also specifying functionality to be dropped.
Then, make sure he is tracking his time/tasks accurately, so you can get a good view of what is going on with the project.
This process will show any lack of proper time/task tracking, which may end up being the first step to improvement. If you can't see after the project how long a particular item took, that is probably the cause of the problem right there - not enough definition in the estimate, or missing "dependency" tasks that are discovered mid-project, but never estimated.
You HAVE to know how much time was spent doing what, accurately, before you can find out where the creep was, or what can be done about it.
Then, see where his estimates are failing and figure out why. Go over an estimate of a blown project, make that into a project itself - a problem to be solved.
Once you've determined that his estimates are indeed the source of the problem, go over an estimate that went over with him, and perhaps another developer, and figure out why.
This will help you figure out what the cause of the problem is. A solid understanding of the problem will likely be the actual solution.
Lastly, if you actually reach a point where you have to try punishment or coercion, it's time to fire him and start over.
Punishment and Coercion are appropriate responses to willful wrongdoing in certain situations.
However, if this developer is actively trying to do a good job, then you would only worsen the situation by generating negative attitude and frustration.
If the problem can't be solved, and you are sure the problem is with him, and not you, then it's time to fire him and get a developer who can meet deadlines. Great work doesn't mean much when your costs are blown up and profit goes out the window.
Okay, this is fairly common--developers being optimistic. It's the job of Management to deal with it. If anyone should be punished, it's the manager (you?)
I'm glad you at least asked, It looks like you got some good answers off this list, I hope they help and you find a way to actually implement some that work.
When I was young, my first good manager dealt with it this way:
First of all, he had me come up with an itemized list--breaking tasks down to hours, and estimating each one with a very liberal estimate--no period should be less than 4 hours regardless of how small the task was.
Then he looked at them and told me to double all my estimates. (Developers, especially younger developers, don't think about the fact that you are only productive for about 1/2 the day, if you're lucky--and half of that is spent at things you didn't expect to have to do).
Then, before creating his schedule, he doubled all my estimates (Without telling me).
He turned them in this way regardless of schedule requirements from above. A good manager should realize that saying it needs to be done in 2 days, doesn't make it possible.
As I got better at estimating we both noticed and adjusted accordingly.
A managers job isn't just to make a project, it's to build a team. More often than not that's going to require training of some sort. This is also the reason that an engineering manager that is not an engineer is unacceptable, they can't really help with this kind of thing.
Failure of a project or schedule is VIRTUALLY NEVER the fault of the developer (except in a few chronic cases where he isn't really fixable or of any worth and needs to be fired). The manager has made bad decisions either in hiring the developer, trusting him, managing him or staffing the project.
And really, what is fault anyway? I suppose if the manager isn't very good at making the project happen, he's going to need someone to point at... If HIS manager is any good, he'll ask why it got this far, what you did to fix it, etc.
Hiring a manager is hiring someone to solve the problems. To make the developers productive. If he can't make them productive, he isn't the right person.
If you choose to punish people for missing deadlines you will not get good results. They will be demotivated and feel belittled. If you keep pushing people to meet deadlines the quality of work will suffer and you will end up with a lot of time spent bug fixing afterwards.
To improve his time estimates you could try using Joel Spolsky's evidence based scheduling which has a nice feedback loop to improve the resulting estimates.
But I have some questions that I think you need to think about.
Is he later than everybody else? If so why - is it because he is an over optimistic estimator or a slow worker? Over optimistic estimates are easy to fix - just multiply all his numbers by a factor as per evidence based scheduling above. If he is a slow worker why? Does he get distracted? Is he very careful to produce very low defect code? Is he over engineering solutions? Is he not re-using code effectively?
Do the deadlines matter, or are they just arbitrary dates based on the estimates for the purposes of reporting progress up the management hierarchy? If the latter you can solve this by tweaking his estimates yourself.
What kinds of punishments for passing a deadline are effective?
You stated the point and missed it. The obvious punishment for passing a deadline is death. If the developer is still alive after passing a deadline the "deadline" obviously was not a real deadline. Do you think it's funny to put developers under pressure using martial language?
Next. Why do you think punishment will be an effective way to manage people that is supposed to be creative? I think you have to rethink the whole approach to management vs. team.
As I see it the managers first, and most important, role is to make sure that the developers can be creative and productive. Not that they are productive. There is a big difference in those small words. To be creative you need a safe environment. By being constantly under pressure from both deadlines and threats of punishment you create the exact opposite of safe.
Also, as a manager, you need accurate information on which to base decisions. This also requires a safe environment. If there is a risk for punishment for being honest and outspoken you are guaranteed to get lies and absence of information. A very dangerous base to take decisions from.
Estimates
As other as pointed out, estimates are estimates. In our team we don't do any individual estimates at all, we do estimates as a team. (I'm a bit reluctant to call what we do Scrum, but most of it tries to emulate if nothing less) I think this is a really great way to do estimates: Each team member is given a deck of cards consisting of numbers 0,1/2,1,3,5,8,13,20,40,60,100 and when estimating a task each developer picks a card (the cards are hidden until everyone has picked a card to avoid influencing estimates) and the average of the selected cards is taken as the estimate.
Notice how the numbers gets progressively less accurate. This is by design because large estimates are by necessity less accurate.
For our team we have opted to use the unit "ideal man days" for estimates. As far back as any of us can remember an ideal day hasn't occurred yet, but it is a good basis when you know how to translate calender days to "ideal man days".
As Scrum prescribes, development is done in sprints of two weeks after which the new version is deployed in the production environment. After each sprint we take the sum of the estimates of the completed tasks and divide that by the planned man days for the sprint. This factor is then the basis of estimating how many "ideal man days" the team can spend in a two week period.
Actual work items done by an individual developer don't need an estimate. The first approximation is always 1/2 - 1 day to complete. If this estimate turns out to be false you just grab a fellow developer and do it together to get it done. Or you break down the work item in smaller tasks so it can be distributed better.
I don't think you should punish him. Just get him to understand how to make accurate estimates.
As a team lead I've had my team members tell me that it will be "no problem" to finish X feature by the deadline. Then I usually sit down with them and go over what tasks and sub-tasks I think need to be done in order for the feature to be finished, and how long the developer thinks each will take.
After we do this exercise, and add up all the task and sub-task estimates, it will inevitably take much longer than the developer thinks in their original estimate. I usually only have to do this exercise with them a few times before they start making more accurate estimates.
What amazes me is that you only have one of these guys.
Engineers are horrible at estimating how much time something will take. I bet if you look carefully at your other developers' estimates, you'll find a lot of padding. Sometimes the padding isn't necessary, but the task expands to fill the available time anyway.
The solution to this is to change around how you do estimates - for everyone. Developers may be bad at estimating absolute time, but they're pretty good at relative time. So on Monday, instead of "how long will it take to add a whoosiwhatsit?," ask "what can you get done on the whoosiwhatsit in less than a week?" That becomes their task for the week.
The following Monday you look at how it went. "Well, I got the floogle installed in two days but it turns out it impacted the mcphee...so this week I need to decouple those guys so the whoosiwhatsit files don't get overwritten." Ok, there's their task for the week.
You might think it won't help, because you still don't know when the whoosiwhatsit is going to be ready. That's true. You have two choices here:
If you need a deadline, then you have to force your errant developer to pad his estimates like everyone else. It won't take him long to get the hang of it, and in no time at all he'll be taking "2 weeks" to write something that should have taken a day.
Your other choice is to trade the fictitious estimates for more visibility. In the long run this approach gets you more productive and much happier engineers.
也许接下来一段时间，让他引导您完成估计交货点的过程。 这可以是一个询问他为什么步骤 X、Y 和 Z 需要一定时间的机会。 他可能会发现自己只是通过以几乎肯定较慢的速度进行练习来修改他的估计。
So the developer does good work, but is poor at estimating the amount of time for delivery? I'm not sure you have a punishment situation on your hands just yet.
Maybe going forward for some time, have him walk you through his process for estimating a delivery point. This can be an opportunity to ask him why steps X,Y, and Z take certain amounts of time. He may find himself revising his estimates simply by doing the exercise at what is almost certainly a slower pace.
If you're just blindly passing estimates from developers (who you know can't give good estimates) up the management line, and not deciding for yourself whether that estimate is achievable, then you're not doing your job.
Try to think in terms of "value-add" (One of my old employers used that term a lot , and I hated it, but it probably works for you in this situation). What value are you adding? If you're just passing stuff in both directions between upper management and the developers, then ultimately you're not earning your money. You could be removed , and nothing would change.
The best manager I ever had was one that looked through a set of requirements given to him by another team , and told them straight out that almost a third of them was bull, and had them removed, before I ever even saw the list. The worst one I ever had made me write all this extra management-type documentation which none of the other managers I'd ever had asked me to do (I really got the impression I was literally doing his job for him), didn't even give me project due dates, and hardly turned up to work. They were both in the same company , bizarrely enough.
90 hours is one common short project deadline. The easy way is instead of estimating "your time", you measure another. Computer programmers shoudn't make time estimates for their projects since evidence shows calculating one's own time results in larger error than observing another.
发布评论
评论（15）
我不认为问题在于他错过了这些最后期限。
我认为他在估计完成任务所需的时间方面确实存在问题。
让他开始记下他所说的任务将花费的时间以及他完成任务实际花费的时间。 最终，这本日记将成为他做出更好估计的指南。 一旦他能够更好地进行估算，他就不会感到匆忙或烦恼。
I don't think the problem is that he is missing these deadlines.
I think he has a real problem in estimating the amount of time it will take to complete a task.
Have him start keeping a journal of what he says a task will take and how long it actually took him to complete the task. Eventually, this journal will become a sort of guide for him to create better estimates. Once he becomes better at estimating, he shouldn't feel as rushed or harried.
Joel Spolsky 写了一篇有趣的文章：基于证据的调度
要点是他（和你）应该从错误中吸取教训，并在下次估计时考虑到这些错误。
另外，如果您是开发人员，我会在一天结束时定期进行代码审查，以更好地了解他的开发过程。
当然，更小的迭代和更细化的任务。 将最大任务持续时间设置为 1 天。 这就是我们的规则。
There is an interesting article by Joel Spolsky: Evidence Based Scheduling
The main point is that he (and you) should learn from his mistakes, and take them into account on the next estimation.
Also, if you are a developer, I would do regular code review at the end of the day to get a better insight into his development process.
And, of course, smaller iterations and more granularity with tasks. Set the maximum task duration to 1 day. That's the rule we have.
如果您的第一个问题是
要考虑什么样的惩罚
我认为你立刻就输了。 如果您觉得他做得很好，您可能需要查看截止日期/估算，看看它们是否现实。 谁设置了它们，如果相关开发人员没有参与，那么这可能是问题的一部分。
我同意@OTisler 的观点，即结对编程以及可能定期与自己进行一天的进度审查可以帮助他度过难关……尽管如果截止日期/估计一开始就不切实际，那不是您的问题所在。
对一些具体任务进行更密切的监控应该可以突出问题所在。
If your first question is
what kind of punishments to be considering
I think you're on a loser straight off. If you feel he does good work you may have to look at the deadlines/estimates and see if they were realistic in the first place. Who set them, if the developer in question was not involved then that may be part of the problem.
I agree with @OTisler that pair programming and possibly a regular end of day progress review with yourself can help him through... although if the deadlines/estimates were unrealistic to begin with thats not where your problem lies.
Closer monitoring on a few specific tasks should highlight where any issues lie.
没有任何。 如果你激怒了他，他就不会做这份工作，或者他会去找另一份工作。 你应该帮助他弄清楚为什么他的估计不正确。 史蒂夫·麦康奈尔（Steve McConnell）写了一本关于估算的书。 我会从那里开始。
通过帮助他找到正确的估算方法。
None. If you anger him, he won't do the work, or he'll find another job. You should help him figure out why his estimates are off. There is a book by steve McConnell about making estimates. i would start there.
By helping him find the right way to make estimates.
首先，确保你的要求非常清楚。
我不想这么说，但根据我的经验，截止日期的提前通常是由于主管的要求不明确或规范薄弱造成的。 首先要做的是确保问题不是由您引起的，也不是由您加剧的。
此外，请确保您的要求以及他的估计都是现实的。
确保您自己的期望不会促使他为了满足不切实际的要求而做出不切实际的估计。
请记住，您执行需求，但开发人员始终执行估计，并且不应受到“我们可以更快地完成此操作”的影响，除非您还指定要删除的功能。
然后，确保他准确地跟踪他的时间/任务，以便您可以很好地了解项目的进展情况。
此过程将显示任何缺乏适当的时间/任务跟踪的情况，这会导致可能最终成为改进的第一步。 如果您在项目结束后看不到某个特定项目花费了多长时间，这可能就是问题的原因 - 估计中没有足够的定义，或者缺少在项目中发现但从未估计过的“依赖项”任务。
在找出蠕变发生在哪里或可以采取什么措施之前，您必须准确地知道在做什么事情上花费了多少时间。
然后，看看他的估计在哪里失败并找出原因。 检查对失败项目的估计，将其纳入项目本身 - 一个需要解决的问题。
一旦你确定他的估计确实是问题的根源，就检查已通过的估计他，也许还有其他开发人员，并找出原因。
这将帮助您找出问题的原因。 对问题的深入理解可能是实际的解决方案。
最后，如果你确实到了必须尝试惩罚或强制的地步，那么就应该解雇他并重新开始。
惩罚和强制是在某些情况下对故意不当行为的适当反应。
然而，如果该开发人员积极努力做好工作，那么您只会产生消极态度和沮丧，从而使情况变得更糟。
如果问题无法解决，并且您确定问题出在他身上，而不是您身上，那么是时候解雇他并找到一位能够按时完成任务的开发人员了。 当成本大幅增加、利润消失时，再出色的工作也没有多大意义。
First, make sure you are crystal clear in your requirements.
I hate to say it, but in my experience, blown deadlines are just as often a matter of unclear requirements or weak specifications on the part of a supervisor. First thing to do is to make sure the problem isn't either originating with, or exacerbated by, you.
Also, make sure your requirements are realistic, as well as his estimates.
Make sure that your own expectations aren't pushing him to make unrealistic estimates in order to meet unrealistic requirements.
Remember, you do the requirements, but the developer ALWAYS does the estimates, and should not be swayed with "can we do this any faster" unless you are also specifying functionality to be dropped.
Then, make sure he is tracking his time/tasks accurately, so you can get a good view of what is going on with the project.
This process will show any lack of proper time/task tracking, which may end up being the first step to improvement. If you can't see after the project how long a particular item took, that is probably the cause of the problem right there - not enough definition in the estimate, or missing "dependency" tasks that are discovered mid-project, but never estimated.
You HAVE to know how much time was spent doing what, accurately, before you can find out where the creep was, or what can be done about it.
Then, see where his estimates are failing and figure out why. Go over an estimate of a blown project, make that into a project itself - a problem to be solved.
Once you've determined that his estimates are indeed the source of the problem, go over an estimate that went over with him, and perhaps another developer, and figure out why.
This will help you figure out what the cause of the problem is. A solid understanding of the problem will likely be the actual solution.
Lastly, if you actually reach a point where you have to try punishment or coercion, it's time to fire him and start over.
Punishment and Coercion are appropriate responses to willful wrongdoing in certain situations.
However, if this developer is actively trying to do a good job, then you would only worsen the situation by generating negative attitude and frustration.
If the problem can't be solved, and you are sure the problem is with him, and not you, then it's time to fire him and get a developer who can meet deadlines. Great work doesn't mean much when your costs are blown up and profit goes out the window.
好吧，这很常见——开发人员很乐观。 处理这个问题是管理层的工作。 如果有人应该受到惩罚，那就是经理（你？）
我很高兴你至少问了，看起来你从这个列表中得到了一些很好的答案，我希望他们能有所帮助，并且你找到一种方法来实际实施一些有效的方法。
当我年轻的时候，我的第一位优秀经理是这样处理这个问题的：
首先，他让我列出了一份逐项清单——将任务分解为几个小时，并以非常自由的估计来估算每一个任务——任何时期都不应该无论任务多小，时间都应少于 4 小时。
然后他看着它们并告诉我将所有估计值加倍。 （开发人员，尤其是年轻的开发人员，不要考虑这样一个事实：如果幸运的话，您每天只有大约 1/2 的时间是高效的，其中一半花在了您不希望做的事情上做）。
然后，在制定他的时间表之前，他将我的所有估计增加了一倍（没有告诉我）。
他不顾上面的进度要求，就这样把它们转过来。 一个好的经理应该意识到，说需要在 2 天内完成是不可能的。
随着我的估计能力越来越强，我们都注意到了并进行了相应的调整。
经理的工作不仅仅是制定一个项目，而是建立一个团队。 通常这需要某种培训。 这也是非工程师的工程经理无法接受的原因，他们无法真正帮助解决这种事情。
项目或进度的失败实际上绝不是开发人员的错（除非在一些长期案例中，开发人员无法真正修复或没有任何价值并且需要被解雇）。 经理在雇用开发人员、信任他、管理他或为项目配备人员方面做出了错误的决定。
说实话，到底有什么错呢？ 我想如果经理不太擅长使项目发生，他将需要有人来指出......如果他的经理有任何能力，他会问为什么事情会发展到这一步，你做了什么来解决它等等。
雇用经理就是雇用某人来解决问题。 使开发人员富有成效。 如果他不能让他们富有成效，那么他就不是合适的人选。
Okay, this is fairly common--developers being optimistic. It's the job of Management to deal with it. If anyone should be punished, it's the manager (you?)
I'm glad you at least asked, It looks like you got some good answers off this list, I hope they help and you find a way to actually implement some that work.
When I was young, my first good manager dealt with it this way:
First of all, he had me come up with an itemized list--breaking tasks down to hours, and estimating each one with a very liberal estimate--no period should be less than 4 hours regardless of how small the task was.
Then he looked at them and told me to double all my estimates. (Developers, especially younger developers, don't think about the fact that you are only productive for about 1/2 the day, if you're lucky--and half of that is spent at things you didn't expect to have to do).
Then, before creating his schedule, he doubled all my estimates (Without telling me).
He turned them in this way regardless of schedule requirements from above. A good manager should realize that saying it needs to be done in 2 days, doesn't make it possible.
As I got better at estimating we both noticed and adjusted accordingly.
A managers job isn't just to make a project, it's to build a team. More often than not that's going to require training of some sort. This is also the reason that an engineering manager that is not an engineer is unacceptable, they can't really help with this kind of thing.
Failure of a project or schedule is VIRTUALLY NEVER the fault of the developer (except in a few chronic cases where he isn't really fixable or of any worth and needs to be fired). The manager has made bad decisions either in hiring the developer, trusting him, managing him or staffing the project.
And really, what is fault anyway? I suppose if the manager isn't very good at making the project happen, he's going to need someone to point at... If HIS manager is any good, he'll ask why it got this far, what you did to fix it, etc.
Hiring a manager is hiring someone to solve the problems. To make the developers productive. If he can't make them productive, he isn't the right person.
对于你的问题：
但我有一些问题我认为你需要考虑一下。
他比其他人都晚吗？ 如果是这样，为什么——是因为他是一个过于乐观的估计者还是一个行动缓慢的人？ 过度乐观的估计很容易解决——只需将他的所有数字乘以上面基于证据的调度的一个因子即可。 如果他是一个慢工，为什么？ 他会分心吗？ 他是否非常小心地生产缺陷率非常低的代码？ 他是否已经完成了工程解决方案？ 他没有有效地重用代码吗？
截止日期是否重要，或者它们只是基于估计的任意日期，以便报告管理层的进展情况？ 如果是后者，你可以通过自己调整他的估计来解决这个问题。
To your questions:
But I have some questions that I think you need to think about.
Is he later than everybody else? If so why - is it because he is an over optimistic estimator or a slow worker? Over optimistic estimates are easy to fix - just multiply all his numbers by a factor as per evidence based scheduling above. If he is a slow worker why? Does he get distracted? Is he very careful to produce very low defect code? Is he over engineering solutions? Is he not re-using code effectively?
Do the deadlines matter, or are they just arbitrary dates based on the estimates for the purposes of reporting progress up the management hierarchy? If the latter you can solve this by tweaking his estimates yourself.
你陈述了这一点，但错过了。 超过最后期限的明显惩罚是死亡。 如果开发商在超过最后期限后仍然活着，那么“最后期限”显然不是真正的最后期限。 您认为用军事语言给开发人员施加压力很有趣吗？
修正你的措辞。
You stated the point and missed it. The obvious punishment for passing a deadline is death. If the developer is still alive after passing a deadline the "deadline" obviously was not a real deadline. Do you think it's funny to put developers under pressure using martial language?
Fix your wording.
动机
首先：阅读 Peopleware
接下来。 为什么你认为惩罚是管理富有创造力的人的有效方式？ 我认为你必须重新思考管理与团队的整个方法。
在我看来，管理者首先也是最重要的角色是确保开发人员能够具有创造力和生产力。 并不是说他们有生产力。 那些小词却有很大的不同。 要发挥创造力，您需要一个安全的环境。 由于不断受到最后期限和惩罚威胁的压力，你会创造出与安全完全相反的东西。
此外，作为一名经理，您需要准确的信息来做出决策。 这也需要一个安全的环境。 如果因为诚实和直言不讳而面临受到惩罚的风险，那么您肯定会得到谎言和缺乏信息。 这是一个非常危险的决策基础。
估计
正如其他所指出的，估计只是估计。 在我们的团队中，我们根本不进行任何个人估算，而是作为一个团队进行估算。 （我有点不愿意称我们所做的为 Scrum，但大多数都试图模仿）我认为这是一种非常好的估算方法：每个团队成员都会得到一副由数字 0 组成的卡片,1/2,1,3,5,8,13,20,40,60,100，在估计任务时，每个开发人员都会选择一张卡（这些卡会被隐藏，直到每个人都选择了一张卡，以避免影响估计）以及所选卡片将作为估计值。
请注意数字如何逐渐变得不准确。 这是设计使然，因为大的估计必然不太准确。
对于我们的团队，我们选择使用“理想工日”单位进行估算。 就我们所知，理想的一天还没有出现，但当您知道如何将日历日翻译为“理想的人日”时，这是一个很好的基础。
按照 Scrum 的规定，开发是在两周的冲刺时间内完成的，然后新版本就会部署在生产环境中。 每次冲刺之后，我们将已完成任务的估计总和除以冲刺的计划工日。 这个因素是估计团队在两周内可以花费多少“理想工日”的基础。
单个开发人员完成的实际工作项目不需要估计。 第一个近似值始终需要 1/2 - 1 天才能完成。 如果这个估计结果是错误的，你只需找一位开发人员一起完成即可。 或者您将工作项分解为更小的任务，以便更好地分配。
Motivation
First of all: Read Peopleware
Next. Why do you think punishment will be an effective way to manage people that is supposed to be creative? I think you have to rethink the whole approach to management vs. team.
As I see it the managers first, and most important, role is to make sure that the developers can be creative and productive. Not that they are productive. There is a big difference in those small words. To be creative you need a safe environment. By being constantly under pressure from both deadlines and threats of punishment you create the exact opposite of safe.
Also, as a manager, you need accurate information on which to base decisions. This also requires a safe environment. If there is a risk for punishment for being honest and outspoken you are guaranteed to get lies and absence of information. A very dangerous base to take decisions from.
Estimates
As other as pointed out, estimates are estimates. In our team we don't do any individual estimates at all, we do estimates as a team. (I'm a bit reluctant to call what we do Scrum, but most of it tries to emulate if nothing less) I think this is a really great way to do estimates: Each team member is given a deck of cards consisting of numbers 0,1/2,1,3,5,8,13,20,40,60,100 and when estimating a task each developer picks a card (the cards are hidden until everyone has picked a card to avoid influencing estimates) and the average of the selected cards is taken as the estimate.
Notice how the numbers gets progressively less accurate. This is by design because large estimates are by necessity less accurate.
For our team we have opted to use the unit "ideal man days" for estimates. As far back as any of us can remember an ideal day hasn't occurred yet, but it is a good basis when you know how to translate calender days to "ideal man days".
As Scrum prescribes, development is done in sprints of two weeks after which the new version is deployed in the production environment. After each sprint we take the sum of the estimates of the completed tasks and divide that by the planned man days for the sprint. This factor is then the basis of estimating how many "ideal man days" the team can spend in a two week period.
Actual work items done by an individual developer don't need an estimate. The first approximation is always 1/2 - 1 day to complete. If this estimate turns out to be false you just grab a fellow developer and do it together to get it done. Or you break down the work item in smaller tasks so it can be distributed better.
按照 @OTisler 的建议设置里程碑并尝试敏捷。
Set Milestones and try Agile as @OTisler suggested.
我认为你不应该惩罚他。 只要让他了解如何做出准确的估计即可。
作为团队领导，我的团队成员告诉我，在截止日期前完成 X 功能“没问题”。 然后我通常会和他们坐下来讨论我认为需要完成哪些任务和子任务才能完成该功能，以及开发人员认为每个任务需要多长时间。
在我们完成此练习并将所有任务和子任务估计加起来之后，不可避免地会比开发人员在最初估计中认为的时间长得多。 我通常只需要和他们一起做几次这个练习，他们就开始做出更准确的估计。
I don't think you should punish him. Just get him to understand how to make accurate estimates.
As a team lead I've had my team members tell me that it will be "no problem" to finish X feature by the deadline. Then I usually sit down with them and go over what tasks and sub-tasks I think need to be done in order for the feature to be finished, and how long the developer thinks each will take.
After we do this exercise, and add up all the task and sub-task estimates, it will inevitably take much longer than the developer thinks in their original estimate. I usually only have to do this exercise with them a few times before they start making more accurate estimates.
让我惊讶的是你只有这些人中的一个。
工程师们很难估计某件事情需要花费多少时间。 我敢打赌，如果您仔细查看其他开发人员的估计，您会发现很多空白。 有时，填充是不必要的，但任务无论如何都会扩展以填满可用时间。
解决这个问题的方法是改变你为每个人进行估算的方式。 开发人员可能不擅长估计绝对时间，但他们很擅长估计相对时间。 因此，在周一，不要问“添加 whoosiwhatsit 需要多长时间？”，而是问“在不到一周的时间内，你能在 whoosiwhatsit 上完成什么？” 这成为他们本周的任务。
接下来的星期一你看看事情进展如何。 “好吧，我在两天内安装了 floogle，但事实证明它影响了 mcphee...所以本周我需要将这些家伙解耦，这样 whoosiwhatsit 文件就不会被覆盖。” 好的，这就是他们本周的任务。
您可能认为这没有帮助，因为您仍然不知道 whoosiwhatsit 何时准备好。 这是真的。 这里你有两个选择：
如果你需要一个截止日期，那么你必须强迫犯错误的开发人员像其他人一样填充他的估计。 他很快就能掌握窍门，而且很快他就会花“两周”的时间来写一些本应花一天的东西。
您的另一个选择是用虚构的估计来换取更多的可见性。 从长远来看，这种方法可以让您的工程师更加高效、更加快乐。
What amazes me is that you only have one of these guys.
Engineers are horrible at estimating how much time something will take. I bet if you look carefully at your other developers' estimates, you'll find a lot of padding. Sometimes the padding isn't necessary, but the task expands to fill the available time anyway.
The solution to this is to change around how you do estimates - for everyone. Developers may be bad at estimating absolute time, but they're pretty good at relative time. So on Monday, instead of "how long will it take to add a whoosiwhatsit?," ask "what can you get done on the whoosiwhatsit in less than a week?" That becomes their task for the week.
The following Monday you look at how it went. "Well, I got the floogle installed in two days but it turns out it impacted the mcphee...so this week I need to decouple those guys so the whoosiwhatsit files don't get overwritten." Ok, there's their task for the week.
You might think it won't help, because you still don't know when the whoosiwhatsit is going to be ready. That's true. You have two choices here:
If you need a deadline, then you have to force your errant developer to pad his estimates like everyone else. It won't take him long to get the hang of it, and in no time at all he'll be taking "2 weeks" to write something that should have taken a day.
Your other choice is to trade the fictitious estimates for more visibility. In the long run this approach gets you more productive and much happier engineers.
那么开发商做得很好，但在估计交付时间方面却很糟糕？ 我不确定你现在是否面临着惩罚。
也许接下来一段时间，让他引导您完成估计交货点的过程。 这可以是一个询问他为什么步骤 X、Y 和 Z 需要一定时间的机会。 他可能会发现自己只是通过以几乎肯定较慢的速度进行练习来修改他的估计。
So the developer does good work, but is poor at estimating the amount of time for delivery? I'm not sure you have a punishment situation on your hands just yet.
Maybe going forward for some time, have him walk you through his process for estimating a delivery point. This can be an opportunity to ask him why steps X,Y, and Z take certain amounts of time. He may find himself revising his estimates simply by doing the exercise at what is almost certainly a slower pace.
问问自己：你的工作需要什么？
如果您只是盲目地将开发人员（您知道他们无法给出良好的估计）的估计传递给管理线，而不是自己决定该估计是否可以实现，那么您就没有做好自己的工作。
尝试从“增值”的角度思考（我的一位前雇主经常使用这个术语，我讨厌它，但在这种情况下它可能对你有用）。 您要增加什么价值？ 如果你只是在高层管理人员和开发人员之间双向传递东西，那么最终你就赚不到钱。 你可能会被移除，但什么都不会改变。
我遇到过的最好的经理是一个会仔细查看另一支团队向他提出的一系列要求，并直接告诉他们其中几乎有三分之一是公牛的，并且在我看到清单之前就将其删除的人。 我经历过的最糟糕的一次让我写了所有这些额外的管理类型文档，而我从未要求我这样做的其他经理都没有这样做（我真的得到了我实际上是在为他做他的工作的印象），没有甚至给我项目截止日期，但我几乎没有去上班。 奇怪的是，他们都在同一家公司。
ask yourself this: What entails your job?
If you're just blindly passing estimates from developers (who you know can't give good estimates) up the management line, and not deciding for yourself whether that estimate is achievable, then you're not doing your job.
Try to think in terms of "value-add" (One of my old employers used that term a lot , and I hated it, but it probably works for you in this situation). What value are you adding? If you're just passing stuff in both directions between upper management and the developers, then ultimately you're not earning your money. You could be removed , and nothing would change.
The best manager I ever had was one that looked through a set of requirements given to him by another team , and told them straight out that almost a third of them was bull, and had them removed, before I ever even saw the list. The worst one I ever had made me write all this extra management-type documentation which none of the other managers I'd ever had asked me to do (I really got the impression I was literally doing his job for him), didn't even give me project due dates, and hardly turned up to work. They were both in the same company , bizarrely enough.
90 小时是一种常见的短项目期限。 最简单的方法是测量另一个时间，而不是估计“你的时间”。 计算机程序员不应该对他们的项目进行时间估计，因为有证据表明计算自己的时间比观察他人的时间会产生更大的误差。
90 hours is one common short project deadline. The easy way is instead of estimating "your time", you measure another. Computer programmers shoudn't make time estimates for their projects since evidence shows calculating one's own time results in larger error than observing another.