Firstly, you need to distinguish between deadlines and estimates.
Deadlines come from external sources, eg, "Feature X needs to be ready for the trade show".
Estimates come from internal sources, eg, "Feature X will take N weeks to complete".
Generally, programmers should create estimates, and sales/marketing will create deadlines.
Problems occur when the two cannot be resolved - if the deadline is closer than the estimate.
Helpful hints for dev (leads):
Let the person doing the work create the estimate.
Ensure estimates are based on tiny tasks, each no longer than a day or two.
Use a feedback loop to let developers improve their estimation skills.
Accurate estimation skills lets you push harder against deadline demands.
Helpful hints for marketers / deadline creators:
Don't override an estimate with a deadline.
If a deadline conflicts with an estimate, the only real options are (a) developers work overtime, (b) the requirements for the deadline are trimmed, or (c) the deadline is missed.
Explain why the deadline is important, and what the purpose of the feature deadline is ("customer X will sign a six-figure contract").
Understand that people who feel they cannot meet aggressive deadlines will not be motivated.
It's almost impossible to accurately estimate how long a piece of code will take to design, write and debug until you have done it.
From my personal experience I have spent over a week getting a "simple" shell script to work which I would have estimated at about an hour. On the other hand took about a week to write a parser for COBOL data definitions (including all the weird COMP COMP-3 OCCURS redefines SYNC and slack bytes stuff) which I had estimated at about two months.
The other big problem is that faced with a tight deadlines programmers skip best practice and start hacking. Thus saving about 50% of the coding time but adding 300% to the test and debug time.
Traditionally you can only adjust quality, features or time, the last being the deadline. Quality you really don't want to mess around with. So as long as the process you're using allows you to calibrate features to reach deadlines, I'm ok.
Developers need to be involved in creating the deadlines. If they are arbitrary and created without input from developers then they have a right to complain. Projects legitimately get time constraints from business, but resources and features must be adjusted to compensate. Those adjustments can't be made without input from developers (not to mention BAs, QA and operations folks).
The only software engineers/developers I've met who hate deadlines feel that way for one of two reasons:
They are completely disorganized, and know that they won't meet the deadline, and so don't like them because when they miss the deadline it makes them look bad.
They don't have a problem with deadlines, as long as someone who understands the work involved is setting the deadline. The worst deadlines are made by managers trying to sell a project and saying "3 weeks? No problem!" and then telling their development team that they have 3 weeks to produce a working version of MS Office and recreate the internet for the CEO's little kid.
如果高层管理人员只是简单地规定“功能 X 需要由 Y 完成”，而没有很好地了解实际需要多长时间（有些事情实施起来比听起来要复杂得多），那么这是一个糟糕的情况事物。 然而，如果他们与开发人员合作来估计实际所需的工作量，并将其与公司的其他需求进行平衡，那么通常效果会很好。
I think it depends on how the schedules are created. The developer needs to have a significant role in coming up with the schedule. Otherwise how will you know if it's reasonable or not?
If someone in upper management simply dictates that "Feature X needs to be done by Y" without having any good insight in to how long it might actually take (some things are a lot more complicated to implement than they sound like) then that's a Bad Thing. However, if they work with the developers to estimate the amount of effort actually required and balance that with the rest of the company's needs, then it generally works out pretty well.
Well, I'm quite happy with a deadline if that deadline has been determined through well thought-out estimate process with input from both managers and engineers and the requirements for what is supposed to be delivered on said deadline are well defined.
You must have deadlines, but equally those deadlines must be realistic and measurable. Moving the specification around is going to annoy the developer - it might be unavoidable, but don't be afraid to move things (after discussions).
Deadlines and work estimates are never going to be particularly accurate, but so basic Project Management techniques should mean that people are aware of missing them - and why it happened.
发布评论
评论（8）
首先，您需要区分截止日期和估算。
一般来说，程序员应该创建估算，而销售/营销人员将创建最后期限。
当两者无法解决时，如果最后期限比预计的时间更近，就会出现问题。
对开发人员（领导）的有用提示：
对营销人员/截止日期创建者的有用提示：
Firstly, you need to distinguish between deadlines and estimates.
Generally, programmers should create estimates, and sales/marketing will create deadlines.
Problems occur when the two cannot be resolved - if the deadline is closer than the estimate.
Helpful hints for dev (leads):
Helpful hints for marketers / deadline creators:
程序员讨厌截止日期是有充分理由的！
在完成一段代码之前，几乎不可能准确估计它需要多长时间来设计、编写和调试。
根据我个人的经验，我花了一个多星期的时间才让一个“简单”的 shell 脚本运行起来，我估计大约需要一个小时。 另一方面，花了大约一周的时间为 COBOL 数据定义编写解析器（包括所有奇怪的 COMP COMP-3 OCCURS 重新定义 SYNC 和松弛字节的东西），我估计大约需要两个月的时间。
另一个大问题是，面对紧迫的期限，程序员会跳过最佳实践并开始黑客攻击。 因此节省了大约 50% 的编码时间，但增加了 300% 的测试和调试时间。
Programmers HATE deadlines for very good reasons!
It's almost impossible to accurately estimate how long a piece of code will take to design, write and debug until you have done it.
From my personal experience I have spent over a week getting a "simple" shell script to work which I would have estimated at about an hour. On the other hand took about a week to write a parser for COBOL data definitions (including all the weird COMP COMP-3 OCCURS redefines SYNC and slack bytes stuff) which I had estimated at about two months.
The other big problem is that faced with a tight deadlines programmers skip best practice and start hacking. Thus saving about 50% of the coding time but adding 300% to the test and debug time.
传统上，您只能调整质量、功能或时间，最后一个是截止日期。 您真的不想乱搞的品质。 因此，只要您使用的流程允许您校准功能以达到最后期限，我就可以。
Traditionally you can only adjust quality, features or time, the last being the deadline. Quality you really don't want to mess around with. So as long as the process you're using allows you to calibrate features to reach deadlines, I'm ok.
开发人员需要参与制定最后期限。 如果它们是任意的并且在没有开发人员输入的情况下创建，那么他们有权抱怨。 项目合法地受到业务的时间限制，但必须调整资源和功能来弥补。 如果没有开发人员（更不用说 BA、QA 和运营人员）的投入，这些调整就无法进行。
Developers need to be involved in creating the deadlines. If they are arbitrary and created without input from developers then they have a right to complain. Projects legitimately get time constraints from business, but resources and features must be adjusted to compensate. Those adjustments can't be made without input from developers (not to mention BAs, QA and operations folks).
我见过的唯一讨厌截止日期的软件工程师/开发人员有这样的感觉，原因有二：
并且知道他们不会满足
截止日期，所以不喜欢他们
因为当他们错过最后期限时
这让他们看起来很糟糕。
有截止日期的问题，例如
只要有人懂得
涉及的工作是设置
最后期限。 最糟糕的截止日期是
由试图出售的经理人制作
项目并说“3周？不
问题！”然后告诉他们
他们有 3 名开发团队
几周来制作一个工作版本
MS Office 并重新创建
首席执行官的小孩子的互联网。
The only software engineers/developers I've met who hate deadlines feel that way for one of two reasons:
and know that they won't meet the
deadline, and so don't like them
because when they miss the deadline
it makes them look bad.
have a problem with deadlines, as
long as someone who understands the
work involved is setting the
deadline. The worst deadlines are
made by managers trying to sell a
project and saying "3 weeks? No
problem!" and then telling their
development team that they have 3
weeks to produce a working version
of MS Office and recreate the
internet for the CEO's little kid.
我认为这取决于时间表的制定方式。 开发商需要在制定时间表方面发挥重要作用。 不然怎么知道合理不合理呢？
如果高层管理人员只是简单地规定“功能 X 需要由 Y 完成”，而没有很好地了解实际需要多长时间（有些事情实施起来比听起来要复杂得多），那么这是一个糟糕的情况事物。 然而，如果他们与开发人员合作来估计实际所需的工作量，并将其与公司的其他需求进行平衡，那么通常效果会很好。
I think it depends on how the schedules are created. The developer needs to have a significant role in coming up with the schedule. Otherwise how will you know if it's reasonable or not?
If someone in upper management simply dictates that "Feature X needs to be done by Y" without having any good insight in to how long it might actually take (some things are a lot more complicated to implement than they sound like) then that's a Bad Thing. However, if they work with the developers to estimate the amount of effort actually required and balance that with the rest of the company's needs, then it generally works out pretty well.
嗯，我对最后期限感到非常满意如果这个最后期限是通过深思熟虑的估算过程确定的，并考虑了经理和工程师的意见以及对什么的要求应在上述截止日期前交付的内容已明确定义。
Well, I'm quite happy with a deadline if that deadline has been determined through well thought-out estimate process with input from both managers and engineers and the requirements for what is supposed to be delivered on said deadline are well defined.
定期审查至关重要：
您必须有截止日期，但同样这些截止日期必须是现实且可衡量的。 移动规范会惹恼开发人员 - 这可能是不可避免的，但不要害怕移动东西（在讨论之后）。
截止日期和工作估算永远不会特别准确，但基本的项目管理技术应该意味着人们意识到错过了它们 - 以及为什么会发生这种情况。
Regular reviews are crucial:
You must have deadlines, but equally those deadlines must be realistic and measurable. Moving the specification around is going to annoy the developer - it might be unavoidable, but don't be afraid to move things (after discussions).
Deadlines and work estimates are never going to be particularly accurate, but so basic Project Management techniques should mean that people are aware of missing them - and why it happened.