Depends on whether developers set deadlines on each modification request, or whether these are set for them by management.
In the latter case, unless all your developers are sitting and playing Halo 3 all day, a missed deadline is often an indication of a mistake on the side of management or the team leads. So firing everyone wouldn't solve the problem. It might make sense to introduce better indicators into your software process so you could see that the deadline would be missed long before it happens.
If your developers do give time estimates, then I would be very careful about rewarding and penalizing developers for meeting deadlines or missing them. The result of doing this could be that they would adjust their "fudge factor" in time estimation. They would give themselves too much extra time (to reap the rewards), which messes things up if they are good at estimation. Your goal should be to get them to give good and reliable estimates, not to change the way they work to meet these estimates.
It depends on if the deadline was possible in the first place, maybe it was a fault with the planning and estimation of how long it would have taken. Make sure you know why the deadline was missed before deciding punishment
First of all, there are external deadlines and internal deadlines, and they should be different.
What happens with an internal deadline is the frequency of activity increases as the deadline approaches, reaches a peak at the deadline, and then falls off as the deadline recedes. So plan the external deadline to follow the internal deadline by a couple weeks at least.
Then, make sure the deadlines are realistic. Partly you do that by involving the developers in setting them, and in deciding what will be accomplished.
Finally, I've mostly been a developer, but once when I took a stab at management, I would never want to take the latest-and-greatest version into a conference or presentation. I would want to take a version that was at least a few weeks old and that I knew where the problems were and that I could be sure would not contain unpleasant surprises.
In his wonderful book about project management - "Deadline" - Tom DeMarco tells us a story, about project manager from a western-world is managing a project in some fictional post-communist eastern European wild country (wild is a really good term, because the citizens are a bit.. uncivilized). One day PM discovers, that something went wrong, some part of his project dramatically missed the unrealistic schedule. Previous PM established penalty for missing deadline simply by hanging responsible person on a butcher’s hook, but as schedules were unrealistic, one man already missed deadline. So the story tells us about a day, when western-style PM is presented with a responsible person, and he should send him to be hanged on butcher’s hook. PM, as most people do, is terrified of vision of sentencing someone to cruel death simply because some was never able to finish his project in time. And – by all means – hanging this poor man does not advance the project. Since this is a fiction novel about project management, and not about tortures, our hero cancels the penalty. But there is some big issue behind this story about hanging someone: if you set a deadline, and establish some kind of penalty for missing this deadline, the day will come, you will probably have to actually punish someone. And will you do it? No matter what the punishment will be: hanging, bonus loss, firing, breaking the deal or some fee – you may have to punish someone. Will this penalty do some good to your project? You have to answer it by yourself. So: do not establish a penalty for missing the deadline, you will not want to execute…
Once you've reached the point at which people have blown the deadline, you have to ask yourself (A) what the natural consequences of that are and (B) how you can best complete the task and maintain some kind of movement towards the business objectives (even if you're not running a business).
Explicitly penalizing people for blowing the deadline is unlikely to help unless they believe that they've earned it. This will not happen if the deadline was unrealistic, if there were elements of the team that were the primary points of failure, if there were serious problems with requirements, or if the majority of the team involved believes that the above factors are true.
In one case I was on a team that blew a deadline on a small deliverable by over three months - and the original deliverable due date was three months from start! We misunderstood the requirements, didn't sufficiently talk to the customer, and underestimated the time involved. Management was not at all interested in assigning blame. This was partially because it would have been counterproductive to finishing the deliverable, partially because none of us were "problem employees", and partially because management knew that we were all highly-motivated to fix the problem and satisfy the customer. So we got it done, the customer was as happy as could be expected, and we moved on with our lives, with some valuable lessons on how to avoid the situation in the future.
So far in my career I haven't seen any real penalties for missing a deadline (and I've missed plenty). I imagine it's different for companies building software or games to be sold in stores where the company has made promises to the public.
But in the custom software development realm, it's so hard to accurately estimate how long a project is going to take. And often times this fact is reluctantly accepted by companies everywhere.
While I have never seen any disciplinary action or firings I have seen lots of "mandatory" overtime and peer pressure to work longer hours.
I almost got fired as a manager for telling the team that reported to me NOT to come in on weekends and work late. I know those things are detrimental to the project and to morale.
Generally the "punishment" is in the form of making people feel guilty or anxious, but I am sure there are places that do more "official" things.
The world is full of idiots. Management is no exception.
I think the question it self demonstrates a misunderstanding of the role of management and project management.
There is, unfortunately, a common perception in the minds of many with the word Manager in their title that management means putting the heal to/kicking the butts of lazy workers. It fits with those that believe in Parkinson's Law as well.
It's not. It's about making it possible for works to do their jobs - be it being the communication channel between them and some other part of the organisation, getting them resources, or running interference (moving the furniture out of the way).
To wit, the PM should already know the project/task is going to miss it's deadline. They should be asking questions, and know what's going on. They have the power to either cut tasks or increase/rebalance the resources to get the job done (or say to the sponsor, if you don't give the resources, it ain't getting done on time). And as such, the penalty goes to the PM, whether it is nothing, tongue lashing, demotion, or termination.
Sometimes the delay is unavoidable. This is why we build in contingency time. Sometimes, it's a known risk; and so long as you have a backup plan - you are OK.
As for the responses, you have four parameters: Scope, Time, Money, and Quality
Scope - you can cut to make the deadline.
Time - is fixed. You might be able to get your staff pull a week or two at 60hrs, but your productivity will begin to suffer after that. And it also costs more money if you are paying them fairly.
Money - You can buy pieces from someone else to speed up the process. You could even hire more people, if the work is disjointed enough that you don't have to have a lot of communication with the existing staff - see Brook's Law
Quality - Idealistic fools claim you can never skimp on quality. But you can. You don't have add bugs (one form of anti-quality); but you can put less quality in. Do you code your function so it can handle unlimited length strings, or is 100 characters good enough for this version? Do you make it easy for the next upgrade to bolt on a new module, or do you weld it shut and worry about adding a plug-in module when you do the next version.
Not doing these things aggressively enough (when required) will surely lead you to a failure.
It's certainly not a cut-and-dry answer. Here are some things which I weigh and things I do/encourage in order to make sure things get done on time.
1.) Set priorities properly. Projects will always have various degrees of completion. It's not a binary "done"/"not done" switch. If the highest priority things are done first, it's easier to swallow. Ideally, you should quickly get to the point where it works, but it doesn't do everything we need it to do and it doesn't look pretty. Once there, it can be released if it absolutely needs to.
2.) I've found that the best way to handle it is to make the releases as small as possible. This makes the estimates more accurate. If your boss or "the market" dictates that your estimate is unacceptable, consider assigning more developers to this task if possible. Sometimes a task can't really be divided up easily, or there's only one person familiar with the code. If it's not a high priority just tell the powers that be that it's going to take longer. Setting reasonable goals and managing expectations is key.
3.) As for motivation, rewards, and punishment... there are many doctors who have written entire books on these subjects. In my experience, giving programmers something which is challenging and letting them have some freedom to do it their way is a good start. Listening is something managers need to do well in order to succeed. If the developer is seasoned, you should be able to just explain the problem and let the developer come up with the solution. If their solution isn't as good as what you had in mind, you can suggest it and go from there. Just dictating how to do something, even for new programmers, is seldom effective. Making the developers think about things will help them be able to solve problems on their own. This is related to delegating, as that only works if the developers can do the work on their own.
4.) Reduce turnover by paying people well if they're doing well. It usually costs much more to find good people. It takes time to get familiar with a large code base and the hiring process can also help avoid spending time on people who can't cut the mustard.
5.) Ask (don't demand) if a developer can stay late/work weekends. Only do this when it's something very critical (for example a security flaw which gives user access to data they ought not be able to access; a new law/regulation passes which you must comply; etc.). If they say no, don't hold it against them. It's likely not their fault that things didn't get done; and even if it is, it's reasonable that they made plans for time when they aren't expected to be at work. If they are willing to come in, make sure they know your sincere appreciation. Compensate them well for helping out when they aren't obligated to, buying lunch doesn't cost much and it's a very nice gesture. Don't make a habit of expecting people to work late/weekends unless it's part of their contact/agreement (or if they like doing so).
6.) Understand why things are running behind schedule. Did you promise something which wasn't possible (given the people available, quality expected and time allotted)? Did some other project come up and take up resources and the deadline wasn't adjusted? Was the code just harder to do than expected? Giving time estimates is difficult. You need to plan everything out, have experience and know how long each developer will take for the task. Compensate for unexpected problems which will likely arise and give the programmer a sooner deadline than your boss or the client. It's always OK to be done early. And if you're almost always done early or on time, that one time that you missed your deadline will be more understandable if you have an explanation of some sort.
7.) Remember, it usually boils down to time, quality and money. You can generally pick any two, but the third one will need to balance the equation. So if it needs to be done quickly and on a shoestring budget, you can expect the quality to suffer. If you need it done quickly and of high quality, expect to pay a lot of money, and so on.
8.) I'd say the #1 thing which works for me is listening. If your too busy barking orders then you might not even know about problems with the company. Now just because a developer says "the code sucks, the design is terrible and we need to re-write everything if we want to get anything done in a timely manner" doesn't mean that it'll happen. But if you hear comments like that and explain that we can't afford to do this or we'll get killed in the marketplace, it'd be way too expensive. And ask what can be done to make sure things don't get much/any worse. Ask if there's a way we can clean it up over time. Can we just (re-)write one class and build new stuff based on that? Can we slowly migrate to a new design one feature/segment/module at a time? You understand where they are coming from and vice versa, you can probably solve at least some of the issues. Just remember that compromising works both ways.
9.) Negative re-enforcement seems to result in higher turnover, which is costly. Having a bunch of people who aren't familiar with your code doesn't help deadlines either. Money is one motivator, but I've quit a higher paying job to go to one where I'm happier before, and I know I'm not alone there. Free food when the team does a good job isn't really that expensive. I'm not too keen on group activities since they're either cutting into an employees time, or taking away from work time. It works sometimes, but cutting into an employees personal time so they can hang out with co-workers instead of being with their friends isn't that great of a reward. Having everyone stop working is also expensive... so it just depends on the company size, culture, etc.
Hopefully that helps answer your question. The other answers in this thread are also good suggestions... design plays a big part in how quickly code will be written.
Once a project is late, there is not much 'management' (good, bad, well meaning or malicious) can do, that will not result in the project being even later
... the only exception possibly being the removal/avoidance of exterior distractions.
If the deadline came from someone other than the person performing the work, review the situation to determine the cause of the overrun. In these cases, it is often related to incomplete requirements, scope creep, poor management, etc. No punishment should be given for missing a deadline that the person never provided in the first place.
If the deadline was provided or agreed upon by the individual performing the work, then that person needs to explain the factors that led to the delay. In addition, this person should be reminded to notify their supervisor, project manager, or other responsible party as soon as they are aware that a deadline may be missed. This information should not come to light after the deadline has passed. If this occurs repeatedly, your company's disciplinary process should be followed. This may involve write-ups, suspensions, or termination.
People tend to take real ownership of deadlines when they are the ones setting them. When deadlines are placed on them without their input, deadlines tend to become meaningless to the person performing the work.
Your question is inherently flawed: it assumes that punishment is the best way to manage people. In general, that people don't respond well to punishment or threats of punishment; it brings out the worst behaviors, make the motivation external, and distracts from internal motivation. Rewards and bribes (threats of reward) are the other side of the same coin, and do no better.
These forces are built in to work for hire, however, so you'll never get the best creative work out of your programmers, but you don't have to make it worse by punishing them when they miss a deadline.
Instead, meditate on the creative process, the chaos of multiple people doing creative work, and what tools are effective in managing chaos.
To manage any chaotic system, do lots of measurement and be ready to change course quickly. In the case of programming:
Take the smallest steps possible. Don't "break the task in to small steps", as you'll waste a lot time planning steps that won't work out like you planned. Chaos, remember?
Pick the smallest steps that deliver the most value.
after a short period, reevaluate your plan based on what you've learned
deliver working software to actual, real customers as soon as possible, so they can tell you what you should really be doing.
You may recognize this as the thinking behind SCRUM.
The deadline was missed because someone didn't do their job.
The deadline was unrealistic.
Rather than thinking in terms of penalties, I would suggest doing a post-mortem to determine what went wrong and finding ways to improve the next deadline estimate.
You ask "what should the penalty be...". It would appear you are asking from the perspective of "inside the company".
In real life, the penalties are often swift and severe - loss of business, lawsuits, bad reputation in the industry. These are the REAL penalties imposed by clients who were promised something by a certain date that was not fulfilled.
Internally, you can often do whatever you like. But once you start involving paying clients, then managing those clients becomes a critical part of the overall job.
Penalties such as I described can often be avoided (or lessened) by "on top" communication with the client. If the client wants something added (so-called feature creep), then this should immediately be answered with the impact these changes will have on the project (costs more, delivered later, whatever). The client should be encouraged to triage all such requests against their deadlines and projected costs (i.e. let the client manage feature creep, not you).
If other things change the delivery time, then as soon as you know there will be slippage, you must inform the client. If done early, clients are remarkably willing to work with you. But if you don't say anything until it's too late, they are less likely to forgive... especially should they discover you knew a significant time earlier and didn't tell them.
I've seen executives leave a company shortly after some deadlines were missed. This changed everything but didn't necessarily make things better or worse. I've seen some contractual obligations like clawbacks as a way to penalize someone for missing a deadline that I'm not sure how well they work.
When one completely changes what a project is supposed to do midway through the alloted time for the project that tends to cause the initial trajectory to no longer be valid and thus the project will fail because it likely will not meet the initial deadlines within budgets. Replanning the project into short increments of at most a few months is a response that I believe is a logical direction to take a project to get good results as a lot of project may have to accomodate changing requirements which can easily change deadlines, head count or time worked.
This is not really a programming question, but more of the management question.
Missed deadlines are rarely developer's fault. As a developer you should try your best to do as good work as you can, but in the end everyone is capable of only so much. If developers put in honest effort and despite this the deadline was missed, it means that the deadline was unrealistic to begin with.
Dealing with deadlines is responsibility of managers. There are different approaches but none of them include "penalizing" developers for doing their job. An important thing to understand here is the so-called project management triangle. What it means is that software project can be good (i.e. meeting requirements, good quality), fast (meeting deadlines) and cheap (headcounts, tools). The trouble is that only 2 out of these 3 properties can be chosen.
So if management want something good and fast - it is not going to be cheap.
If management want something good and cheap - it won't be fast.
And finally if management want cheap and fast - guess what, it won't be any good.
So the correct response to missed deadline depends on the chosen scenario. Good and fast requires adding some extra help, better tools, investment in above-average developers and more.
Good and cheap by definition assumes that deadlines are going to be missed (Blizzard, makers of World Of Warcraft are good example of this approach)
And finally cheap and fast usually means cutting features and releasing with bugs.
The main goal of project management is to plan how an application is going to be built, in time. You should not start your project development if you don't have a schedule showing what you're going to be doing every single day the project will last.
This way, you can detect that you're going to be late, as long as you follow the project's evolution on a regular (weekly if not daily) basis. And the earlier you know it, the sooner you can act accordingly.
You usually have two options :
Catch up (by hiring additionnal workers, working more, or removing features).
Tell your customer that something went wrong (even better : what went wrong) and you're gonna need more time.
For the second option, I'm not meaning there won't ever be penalties. But from my personal experience, as long as the customer is informed in advance and offered solutions (preferably three : give more money for additional workers/remove features to save some time/accept the project being late), they'll be open to negociation. Which is always better than conflicts :)
Perhaps the better question is if deadlines are meaningful in the face of inaccurate estimates? Businesses do a lousy job of estimating software--that is a fact. Both management and developers play a part in this and neither one seems willing to own-up to their responsibility in this problem.
But to answer your specific questions:
1.What actions have you seen applied as 'penalty' for missed deadline, and which of these eventually resulted in more-good-code?
The 'penalty' I've seen for missed deadlines for managers and developers range from nothing, to promotion, to simple transfer. The most severe penalties I've personally witnessed was a manager "transferred" to a less important project and for the business-unit to lose a financial bonus.
The only time I have ever seen someone fired over a missed deadline was when the employee was already going to be fired--the deadline gave the business a legal reason to fire the employee.
2.What project-management responses caused the project to fail outright?
This is a whole separate discussion on its own... but there is some inherent bias in this question--project management is at fault.
The three top things I have personally seen PM's do that sabotage a project are (in order of severity):
Ignore data/recommendations/warnings from their technical staff.
Ask for estimates early in the development process. This results in estimates with an error-bar of 10x (it'll take one month, give or take ten months).
Reject/modify/demand software estimates so that they fit an arbitrary budget and schedule. This is not to say Developers should ignore business demands--but rather the business demands need to be set equally by Developers and non-Developers.
3.What responses restored working order and resulted in code that could be maintained afterward?
I have yet to see a functional software development organization. So the fix is usually a lot of blood, sweat, and tears from a couple of heroic developers working with a highly-capable PM who knows how to defend against politics within the company (i.e. deflect BS from their staff).
4.What responses resulted in more-bad-code?
Yelling. Cursing. Insults. (Sadly, this still happens in some workplaces)
More "project management"--either by way of people, meetings, status reports.
Getting software estimates earlier in the process so "we can plan better." Estimates need to come later when your staff has more data and a better understanding of the problem.
Coddling the developers (it's not your fault, the manager screwed up).
Coddling the project managers (it's not your fault, the developers screwed up).
Adding additional, unqualified staff to the project.
I got fired for missing a deadline, I was 98% finished with the product, external forces and deadlines that are that firm don't allow software to be developed properly. Even I can admit I wrote some poor code under the circumstances, but I also wrote some good maintainable code as well. No consideration was given for feature creep, infact no technical specifications were detailed upfront and adaptation of functionality was required as limited and buggy versions of the software became available for managements review. I could have communicated better, but when I did communicate it was emphasized that deadlines are non-negotiable.
Two obvious questions come to mind when a deadline was missed:
Was the deadline feasible?
Did external factors impact performance?
Obviously, if someone presents you with a deadline that doesn't make sense then there shouldn't be any penalty for missing the deadline. Also, if someone misses a deadline because they were called up for jury duty that also shouldn't be held against them as well.
In the event those questions don't apply then the next thing to do is to figure out what went wrong. If you based your estimate for how long something would take, and thus the deadline, on the developers estimation of how long it would take them to write the code then perhaps they were too optimistic in their responses.
Deadlines are part of a fundamentally wrong idea about how to do software development. People new to, or outside of, the software development industry do not understand this:
Software is done when it is done, no sooner and no later.
If a developer has a task and a week to do it, and it looks like it will take more than a week, nothing can be done to change that. No matter how much harder the developer works, no matter how many people are added to the task, it will still take as long as it takes (in fact adding people usually makes it take longer).
Instead, read up on the agile development process. Software should be developed iteratively, and each iteration should be based on the results of the previous iteration, not on external requirements imposed.
Edit based on the extensive comments below:
I would never argue that developers cannot be held to some kind of delivery expectation. My point is in response to the specific hypothesis which the asker posed - that the nature of software development in business is somehow analogous to schoolwork, or any other kind of work for that matter. I contend that it absolutely is not. "Deadline" implies much more than a simple delivery date. It is a fixed point by which a fixed amount of work must be completed. Software simply does not work that way. I wrote a few more paragraphs explaining why, but honestly if you don't already believe that, nothing I say is going to convince you.
If you are working on a software project and it is clear you will not be able to reach your deadline, what can you do to rectify that? The answer is well-known by now: practically nothing. You can't add more people. You can't "work faster". It's just not going to get done on time. You tell the stakeholders, everyone adjusts, and keep working (or not). What, then, did the original date mean?
Anyone who claims software development is analogous to bridge-building or homework or that impending deadlines can still be met if the developers would just get their shit together and work their asses off, are deeply confused about their own profession.
Your first reaction should not be what to do in response to the missed deadline, but to analyse why you missed the deadline. The response to missing the deadline would then follow naturally from that as a consequence of the reason.
For instance, if everyone involved didn't do their job, fire them.
But if they did their job, and more, then why was it still missed? Too much other activities done by the same people? Too big a scope for the deadline (ie. unrealistic deadline). Or ... etc.
The top reason for missing a deadline in my experience is that people aren't allowed to work 100% on the project at hand, and thus any estimates you might have, although accurate on their own, aren't really useful at all. That, plus unrealistic estimates and deadlines.
Developers should never be penalized for Management's mistakes.
It's like a parent punishing a child because the parent had a bad day.
Reasoning:
Deadlines are a fact of life. People want to know how long something will take. The best we can do is estimate/guess. It is the role of management to try to figure this magical, never correct guess. When they create a deadline, they need to use the right tools (experience, ASKING FOR HELP FROM DEVELOPERS, lawyers, hr, etc)
However....
The penalty for missing a deadline should not fall back on the workers. It is the management's fault for missing deadlines. They should have said no, should have scaled back the project or should have motivated the workers better.
In a construction crew, if you piss of the workers, you start a fight. In my company, if we miss deadlines, the management gets in trouble. Not the workers. It's the manager's job to control the project and what is done. The workers are only doing what they can. The manager's are in charge of assigning roles and tasks.
I'm not saying the quality of workers isn't a factor, but the management should KNOW that! It doesn't take a genius to know that a project isn't well thought through or nicely controlled. Ask anybody if their manager has any idea what's going on and you'll find the problem.
We stopped missing as many deadlines when the managers realized it was their fault for setting/agreeing to the deadlines.
</rant>
Re: The questions:
1.What actions have you seen applied as 'penalty' for missed deadline, and which of these actually made things 'better'?
Manager has less responsibility. This person does not get promoted or publicly thanked. Most likely this person will be moved to a "less-critical' project.
2.What project-management responses caused the project to fail outright, and what responses restored working order and resulted in code that could be maintained afterward?
feature creep: manager keeps adding more stuff in the list. <- fight this off with a List of tasks ordered by priority. When you add things to the list, compare their priority with the things around it. Make new things harder to be set as "top priority."
too many bugs in the code: Manager need to require tests (atleast critical) and automation. Builds need to be standard and automatic. Real users need to see the code before it is "finished."
un-readable code: Institute peer code reviews. If someone has dirty code, ask someone to "help" them with a project.
If you have the salesman problem, where the salesman promises features that doesn't exist/work: Management needs to step in and explain the problem to that salesman. Also, not giving that salesman public affirmation for a job well done sometimes helps this.
Rather than a penalty, how about realistic estimates and rewarding on-time releases?
Inspired by the comments to my response
Maybe the question should be "How do I make realistic estimates?" For me, I use FogBugzestimation history and completion date plots. These give me data points of how long I estimated a task to take and how long it actually took. This has helped guide me to give realistic release dates in the long-run (it didn't happen overnight). I find estimating timelines to be an interative process: I
发布评论
评论（30）
死亡。 干净简单。
Death. Clean and simple.
取决于开发人员是否为每个修改请求设定了最后期限，或者这些是否由管理层为其设定。
在后一种情况下，除非所有开发人员都整天坐着玩 Halo 3，否则错过最后期限通常表明管理层或团队领导犯了错误。 所以解雇所有人并不能解决问题。 在软件流程中引入更好的指标可能是有意义的，这样您就可以在截止日期发生之前就看到它会被错过。
如果您的开发人员确实给出了时间估计，那么我会非常谨慎地奖励和惩罚按时完成或错过最后期限的开发人员。 这样做的结果可能是他们会调整时间估计中的“模糊因素”。 他们会给自己太多的额外时间（以获得回报），如果他们善于估计，就会把事情搞砸。 您的目标应该是让他们提供良好且可靠的估计，而不是改变他们的工作方式来满足这些估计。
Depends on whether developers set deadlines on each modification request, or whether these are set for them by management.
In the latter case, unless all your developers are sitting and playing Halo 3 all day, a missed deadline is often an indication of a mistake on the side of management or the team leads. So firing everyone wouldn't solve the problem. It might make sense to introduce better indicators into your software process so you could see that the deadline would be missed long before it happens.
If your developers do give time estimates, then I would be very careful about rewarding and penalizing developers for meeting deadlines or missing them. The result of doing this could be that they would adjust their "fudge factor" in time estimation. They would give themselves too much extra time (to reap the rewards), which messes things up if they are good at estimation. Your goal should be to get them to give good and reliable estimates, not to change the way they work to meet these estimates.
这首先取决于最后期限是否可能，也许是计划和估计需要多长时间的错误。 在决定惩罚之前，确保您知道为什么错过了最后期限
It depends on if the deadline was possible in the first place, maybe it was a fault with the planning and estimation of how long it would have taken. Make sure you know why the deadline was missed before deciding punishment
哦，伙计……
首先，有外部截止日期和内部截止日期，而且它们应该是不同的。
内部截止日期会发生的情况是，活动频率随着截止日期的临近而增加，在截止日期时达到峰值，然后随着截止日期的临近而下降。 因此，计划外部截止日期至少比内部截止日期晚几周。
然后，确保最后期限是现实的。 在某种程度上，你可以通过让开发人员参与设置它们并决定要完成什么来做到这一点。
最后，我主要是一名开发人员，但一旦我尝试进行管理，我就永远不想将最新最好的版本带到会议或演示中。 我希望采用至少几周前的版本，并且我知道问题出在哪里，并且我可以确定不会包含令人不快的意外情况。
Oh, man...
First of all, there are external deadlines and internal deadlines, and they should be different.
What happens with an internal deadline is the frequency of activity increases as the deadline approaches, reaches a peak at the deadline, and then falls off as the deadline recedes. So plan the external deadline to follow the internal deadline by a couple weeks at least.
Then, make sure the deadlines are realistic. Partly you do that by involving the developers in setting them, and in deciding what will be accomplished.
Finally, I've mostly been a developer, but once when I took a stab at management, I would never want to take the latest-and-greatest version into a conference or presentation. I would want to take a version that was at least a few weeks old and that I knew where the problems were and that I could be sure would not contain unpleasant surprises.
在他关于项目管理的精彩书中 - “截止日期” - Tom DeMarco 告诉我们故事，关于来自西方世界的项目经理正在某个虚构的后共产主义东欧荒野国家管理一个项目（荒野是一个非常好的术语，因为公民有点..不文明）。
有一天，PM 发现出了问题，他的项目的某些部分严重错过了不切实际的时间表。 前任总理对错过最后期限的处罚只是将负责人挂在屠夫的钩子上，但由于时间表不切实际，一名男子已经错过了最后期限。
所以这个故事告诉我们有一天，当西式总理出现一个负责人时，他应该把他送上屠夫的钩子。 和大多数人一样，总理害怕仅仅因为某人无法及时完成他的项目而判处某人残酷的死刑。 而且——无论如何——绞死这个可怜的人并不能推进这个项目。 由于这是一本关于项目管理的小说，而不是关于酷刑的小说，因此我们的英雄取消了惩罚。
但这个关于绞死某人的故事背后有一个大问题：如果你设定一个最后期限，并为错过这个最后期限制定某种惩罚措施，那么这一天就会到来，你可能不得不真正惩罚某人。 你会这么做吗？ 无论惩罚是什么：绞刑、损失奖金、解雇、破坏交易或一些费用——你可能必须惩罚某人。 这个惩罚会对你的项目有好处吗？ 你必须自己回答。
所以：不要对错过最后期限进行惩罚，你不会想执行......
In his wonderful book about project management - "Deadline" - Tom DeMarco tells us a story, about project manager from a western-world is managing a project in some fictional post-communist eastern European wild country (wild is a really good term, because the citizens are a bit.. uncivilized).
One day PM discovers, that something went wrong, some part of his project dramatically missed the unrealistic schedule. Previous PM established penalty for missing deadline simply by hanging responsible person on a butcher’s hook, but as schedules were unrealistic, one man already missed deadline.
So the story tells us about a day, when western-style PM is presented with a responsible person, and he should send him to be hanged on butcher’s hook. PM, as most people do, is terrified of vision of sentencing someone to cruel death simply because some was never able to finish his project in time. And – by all means – hanging this poor man does not advance the project. Since this is a fiction novel about project management, and not about tortures, our hero cancels the penalty.
But there is some big issue behind this story about hanging someone: if you set a deadline, and establish some kind of penalty for missing this deadline, the day will come, you will probably have to actually punish someone. And will you do it? No matter what the punishment will be: hanging, bonus loss, firing, breaking the deal or some fee – you may have to punish someone. Will this penalty do some good to your project? You have to answer it by yourself.
So: do not establish a penalty for missing the deadline, you will not want to execute…
正如其他人提到的，在谈论处罚之前，先从“我们如何确定这些最后期限是否现实”开始？
或者正如我的老板曾经说过的，“当您给我们一个可行的计划时，我们将很乐意制定一个计划”。
我仍然认为这应该印在 T 恤上。
As others have mentioned, before talking about penalties, start with "how do we determine whether these deadlines are realistic"?
Or as my boss once said, "We'll be happy to work a plan when you give us a plan that works".
I still think that should be on a t-shirt.
一旦你到达了人们已经超过最后期限的地步，你必须问自己（A）这样做的自然后果是什么以及（B）你如何才能最好地完成任务并保持某种业务进展目标（即使您不经营企业）。
明确惩罚那些逾期的人不太可能有帮助，除非他们相信自己已经赢得了这个机会。 如果截止日期不切实际，如果团队中的某些元素是主要失败点，如果需求存在严重问题，或者大多数相关团队都认为上述因素是正确的，那么这种情况就不会发生。
在一个案例中，我所在的团队将一项小型交付成果的截止日期推迟了三个多月，而原来的交付成果截止日期是从开始算起的三个月！ 我们误解了需求，没有与客户充分交谈，并且低估了所需的时间。 管理层对指责根本不感兴趣。 部分原因是这会对完成可交付成果产生反作用，部分原因是我们都不是“问题员工”，部分原因是管理层知道我们都非常积极地解决问题并满足客户。 所以我们完成了，客户非常满意，我们继续我们的生活，并获得了一些关于如何避免将来出现这种情况的宝贵经验教训。
Once you've reached the point at which people have blown the deadline, you have to ask yourself (A) what the natural consequences of that are and (B) how you can best complete the task and maintain some kind of movement towards the business objectives (even if you're not running a business).
Explicitly penalizing people for blowing the deadline is unlikely to help unless they believe that they've earned it. This will not happen if the deadline was unrealistic, if there were elements of the team that were the primary points of failure, if there were serious problems with requirements, or if the majority of the team involved believes that the above factors are true.
In one case I was on a team that blew a deadline on a small deliverable by over three months - and the original deliverable due date was three months from start! We misunderstood the requirements, didn't sufficiently talk to the customer, and underestimated the time involved. Management was not at all interested in assigning blame. This was partially because it would have been counterproductive to finishing the deliverable, partially because none of us were "problem employees", and partially because management knew that we were all highly-motivated to fix the problem and satisfy the customer. So we got it done, the customer was as happy as could be expected, and we moved on with our lives, with some valuable lessons on how to avoid the situation in the future.
到目前为止，在我的职业生涯中，我还没有看到因错过最后期限而受到任何真正的惩罚（而且我已经错过了很多）。 我想，对于开发软件或游戏并在公司向公众做出承诺的商店中销售的公司来说，情况是不同的。
但在定制软件开发领域，很难准确估计项目需要多长时间。 很多时候，世界各地的公司都不愿意接受这一事实。
So far in my career I haven't seen any real penalties for missing a deadline (and I've missed plenty). I imagine it's different for companies building software or games to be sold in stores where the company has made promises to the public.
But in the custom software development realm, it's so hard to accurately estimate how long a project is going to take. And often times this fact is reluctantly accepted by companies everywhere.
没有惩罚。 “截止日期”和估计一直是并将继续是软件开发中最困难和最具挑战性的部分之一。
就这个问题对开发商进行处罚是荒谬的。
No penalty. "Deadlines" and estimating have been and continue to be one of the hardest and most challenging parts of software development.
It is ridiculous to impose penalties on developers for this issue.
虽然我从未见过任何纪律处分或解雇，但我见过很多“强制性”加班和同事压力要求延长工作时间。
作为一名经理，我差点被解雇，因为我告诉向我汇报的团队不要在周末上班并工作到很晚。 我知道这些事情对项目和士气都是有害的。
一般来说，“惩罚”的形式是让人感到内疚或焦虑，但我确信有些地方会做更多“官方”的事情。
世界上充满了白痴。 管理也不例外。
While I have never seen any disciplinary action or firings I have seen lots of "mandatory" overtime and peer pressure to work longer hours.
I almost got fired as a manager for telling the team that reported to me NOT to come in on weekends and work late. I know those things are detrimental to the project and to morale.
Generally the "punishment" is in the form of making people feel guilty or anxious, but I am sure there are places that do more "official" things.
The world is full of idiots. Management is no exception.
我认为这个问题本身就表明了对管理和项目管理作用的误解。
不幸的是，在许多头衔中带有“经理”一词的人的心中有一个普遍的看法，即管理意味着治愈/踢掉懒惰的工人。 它也适合那些相信帕金森定律的人。
它不是。 这是为了让工作人员能够完成自己的工作——无论是作为他们与组织其他部分之间的沟通渠道，为他们提供资源，还是进行干扰（将家具移开）。
也就是说，PM 应该已经知道项目/任务将错过最后期限。 他们应该提出问题，并知道发生了什么。 他们有权削减任务或增加/重新平衡资源来完成工作（或者对发起人说，如果你不提供资源，就无法按时完成）。 因此，首相将受到惩罚，无论是无事、斥责、降职还是解雇。
有时延迟是不可避免的。 这就是我们在应急时间内进行建设的原因。 有时，这是已知的风险；有时，这是已知的风险。 只要您有备用计划 - 就可以了。
至于回复，您有四个参数：范围、时间、金钱和质量
如果没有足够积极地做这些事情（在需要时）肯定会导致你失败。
I think the question it self demonstrates a misunderstanding of the role of management and project management.
There is, unfortunately, a common perception in the minds of many with the word Manager in their title that management means putting the heal to/kicking the butts of lazy workers. It fits with those that believe in Parkinson's Law as well.
It's not. It's about making it possible for works to do their jobs - be it being the communication channel between them and some other part of the organisation, getting them resources, or running interference (moving the furniture out of the way).
To wit, the PM should already know the project/task is going to miss it's deadline. They should be asking questions, and know what's going on. They have the power to either cut tasks or increase/rebalance the resources to get the job done (or say to the sponsor, if you don't give the resources, it ain't getting done on time). And as such, the penalty goes to the PM, whether it is nothing, tongue lashing, demotion, or termination.
Sometimes the delay is unavoidable. This is why we build in contingency time. Sometimes, it's a known risk; and so long as you have a backup plan - you are OK.
As for the responses, you have four parameters: Scope, Time, Money, and Quality
Not doing these things aggressively enough (when required) will surely lead you to a failure.
这当然不是一个现成的答案。 以下是我权衡的一些事情以及我做/鼓励的事情，以确保事情按时完成。
1.) 正确设置优先级。 项目总是会有不同程度的完成。 它不是一个二元的“完成”/“未完成”开关。 如果最优先的事情先做，就更容易接受。 理想情况下，您应该很快就能达到它的工作效果，但它并不能完成我们需要它完成的所有事情，而且看起来也不漂亮。 一旦到达那里，如果确实需要，就可以将其释放。
2.) 我发现处理这个问题的最佳方法是使版本尽可能小。 这使得估计更加准确。 如果您的老板或“市场”认为您的估计不可接受，请考虑在可能的情况下分配更多开发人员来执行此任务。 有时一项任务确实无法轻易划分，或者只有一个人熟悉代码。 如果这不是一个高优先级，就告诉权力机构，这将需要更长的时间。 设定合理的目标和管理期望是关键。
3.) 至于动机、奖励和惩罚……有很多医生写过关于这些主题的整本书。 根据我的经验，给程序员一些具有挑战性的东西并让他们有一定的自由来按照自己的方式去做是一个好的开始。 管理者需要做好倾听才能取得成功。 如果开发人员经验丰富，您应该能够只解释问题并让开发人员提出解决方案。 如果他们的解决方案不如您的想法，您可以提出建议并从那里开始。 即使对于新程序员来说，仅仅规定如何做某事也很少有效。 让开发人员思考问题将有助于他们自己解决问题。 这与委派相关，因为只有当开发人员可以自己完成工作时，这才有效。
4.) 如果员工表现良好，则向他们支付高薪，以减少人员流动。 寻找优秀人才通常需要花费更多成本。 熟悉大型代码库需要时间，招聘流程也可以帮助避免将时间花在无法胜任的人身上。
5.) 询问（不要强求）开发人员是否可以加班/周末工作。 仅当事情非常关键时才执行此操作（例如，安全缺陷使用户可以访问他们不应该访问的数据；您必须遵守的新法律/法规通过；等等）。 如果他们拒绝，不要反对他们。 事情没有完成可能不是他们的错；而是他们的错。 即使是这样，他们为不应该上班的时间制定计划也是合理的。 如果他们愿意进来，请确保他们知道您真诚的谢意。 当他们没有义务帮忙时，要好好补偿他们，买午餐并不需要花多少钱，而且这是一个非常好的姿态。 不要养成期望人们加班/周末加班的习惯，除非这是他们的联系/协议的一部分（或者如果他们喜欢这样做）。
6.) 了解为什么事情落后于计划。 你是否承诺过一些不可能实现的事情（考虑到可用的人员、预期的质量和分配的时间）？ 是否有其他项目出现并占用了资源并且截止日期没有调整？ 代码是否比预期更难实现？ 估计时间很困难。 您需要计划好一切，拥有经验并知道每个开发人员将花费多长时间来完成任务。 对可能出现的意外问题进行补偿，并为程序员提供比老板或客户更早的截止日期。 早点完成总是可以的。 如果你几乎总是提前或准时完成任务，那么如果你有某种解释，那么你错过最后期限的那一次就会更容易理解。
7.) 请记住，这通常归结为时间、质量和金钱。 通常您可以选择任意两个，但第三个需要平衡等式。 因此，如果需要在预算有限的情况下快速完成，质量可能会受到影响。 如果您需要快速且高质量地完成，则需要支付大量资金，等等。
8.) 我想说对我有用的第一件事就是倾听。 如果你太忙于发号施令，那么你可能甚至不知道公司的问题。 现在，仅仅因为开发人员说“代码很糟糕，设计很糟糕，如果我们想及时完成任何事情，我们需要重新编写所有内容”并不意味着它会发生。 但如果你听到这样的评论并解释说我们负担不起这样做，否则我们会在市场上被杀，那就太昂贵了。 并询问可以采取哪些措施来确保事情不会变得更糟。 询问是否有办法可以随着时间的推移将其清理干净。 我们可以只（重新）编写一个类并基于该类构建新的东西吗？ 我们可以一次慢慢地迁移到一个功能/部分/模块的新设计吗？ 你了解它们从何而来，反之亦然，你可能至少可以解决一些问题。 请记住，妥协是双向的。
9.) 消极的强化似乎会导致更高的人员流动，而这是代价高昂的。 拥有一群不熟悉你的代码的人也无助于按时完成任务。 金钱是一个动力，但我已经辞掉了一份高薪工作，去了一个我以前更快乐的工作，而且我知道我并不孤单。 当团队表现出色时，免费食物并不是那么昂贵。 我不太热衷于集体活动，因为它们要么占用员工时间，要么占用工作时间。 有时这确实有效，但削减员工的个人时间，让他们可以与同事一起出去玩，而不是与朋友在一起，这并不是一个很好的奖励。 让每个人都停止工作也是昂贵的……所以这取决于公司规模、文化等。
希望这有助于回答你的问题。 该线程中的其他答案也是很好的建议......设计在代码编写速度方面发挥着重要作用。
It's certainly not a cut-and-dry answer. Here are some things which I weigh and things I do/encourage in order to make sure things get done on time.
1.) Set priorities properly. Projects will always have various degrees of completion. It's not a binary "done"/"not done" switch. If the highest priority things are done first, it's easier to swallow. Ideally, you should quickly get to the point where it works, but it doesn't do everything we need it to do and it doesn't look pretty. Once there, it can be released if it absolutely needs to.
2.) I've found that the best way to handle it is to make the releases as small as possible. This makes the estimates more accurate. If your boss or "the market" dictates that your estimate is unacceptable, consider assigning more developers to this task if possible. Sometimes a task can't really be divided up easily, or there's only one person familiar with the code. If it's not a high priority just tell the powers that be that it's going to take longer. Setting reasonable goals and managing expectations is key.
3.) As for motivation, rewards, and punishment... there are many doctors who have written entire books on these subjects. In my experience, giving programmers something which is challenging and letting them have some freedom to do it their way is a good start. Listening is something managers need to do well in order to succeed. If the developer is seasoned, you should be able to just explain the problem and let the developer come up with the solution. If their solution isn't as good as what you had in mind, you can suggest it and go from there. Just dictating how to do something, even for new programmers, is seldom effective. Making the developers think about things will help them be able to solve problems on their own. This is related to delegating, as that only works if the developers can do the work on their own.
4.) Reduce turnover by paying people well if they're doing well. It usually costs much more to find good people. It takes time to get familiar with a large code base and the hiring process can also help avoid spending time on people who can't cut the mustard.
5.) Ask (don't demand) if a developer can stay late/work weekends. Only do this when it's something very critical (for example a security flaw which gives user access to data they ought not be able to access; a new law/regulation passes which you must comply; etc.). If they say no, don't hold it against them. It's likely not their fault that things didn't get done; and even if it is, it's reasonable that they made plans for time when they aren't expected to be at work. If they are willing to come in, make sure they know your sincere appreciation. Compensate them well for helping out when they aren't obligated to, buying lunch doesn't cost much and it's a very nice gesture. Don't make a habit of expecting people to work late/weekends unless it's part of their contact/agreement (or if they like doing so).
6.) Understand why things are running behind schedule. Did you promise something which wasn't possible (given the people available, quality expected and time allotted)? Did some other project come up and take up resources and the deadline wasn't adjusted? Was the code just harder to do than expected? Giving time estimates is difficult. You need to plan everything out, have experience and know how long each developer will take for the task. Compensate for unexpected problems which will likely arise and give the programmer a sooner deadline than your boss or the client. It's always OK to be done early. And if you're almost always done early or on time, that one time that you missed your deadline will be more understandable if you have an explanation of some sort.
7.) Remember, it usually boils down to time, quality and money. You can generally pick any two, but the third one will need to balance the equation. So if it needs to be done quickly and on a shoestring budget, you can expect the quality to suffer. If you need it done quickly and of high quality, expect to pay a lot of money, and so on.
8.) I'd say the #1 thing which works for me is listening. If your too busy barking orders then you might not even know about problems with the company. Now just because a developer says "the code sucks, the design is terrible and we need to re-write everything if we want to get anything done in a timely manner" doesn't mean that it'll happen. But if you hear comments like that and explain that we can't afford to do this or we'll get killed in the marketplace, it'd be way too expensive. And ask what can be done to make sure things don't get much/any worse. Ask if there's a way we can clean it up over time. Can we just (re-)write one class and build new stuff based on that? Can we slowly migrate to a new design one feature/segment/module at a time? You understand where they are coming from and vice versa, you can probably solve at least some of the issues. Just remember that compromising works both ways.
9.) Negative re-enforcement seems to result in higher turnover, which is costly. Having a bunch of people who aren't familiar with your code doesn't help deadlines either. Money is one motivator, but I've quit a higher paying job to go to one where I'm happier before, and I know I'm not alone there. Free food when the team does a good job isn't really that expensive. I'm not too keen on group activities since they're either cutting into an employees time, or taking away from work time. It works sometimes, but cutting into an employees personal time so they can hang out with co-workers instead of being with their friends isn't that great of a reward. Having everyone stop working is also expensive... so it just depends on the company size, culture, etc.
Hopefully that helps answer your question. The other answers in this thread are also good suggestions... design plays a big part in how quickly code will be written.
一旦项目延迟，就没有太多的“管理”（好的、坏的、善意的或恶意的）可以做，这不会导致项目甚至更晚
......唯一的例外可能是移除/避免外部干扰。
Once a project is late, there is not much 'management' (good, bad, well meaning or malicious) can do, that will not result in the project being even later
... the only exception possibly being the removal/avoidance of exterior distractions.
如果您错过了最后期限，请修正您的估计。
If you're missing your deadlines, fix your estimates.
从公司发展的角度来看...
如果截止日期是由执行工作的人员以外的其他人指定的，请检查情况以确定超支的原因。 在这些情况下，通常与需求不完整、范围蔓延、管理不善等有关。不应因为错过了最初从未提供的最后期限而受到惩罚。
如果截止日期是由执行工作的个人提供或同意的，那么该人需要解释导致延迟的因素。 此外，应提醒此人一旦意识到可能会错过最后期限，请立即通知其主管、项目经理或其他责任方。 该信息不应在截止日期过后曝光。 如果这种情况反复发生，则应遵循贵公司的纪律处分程序。 这可能涉及追加、暂停或终止。
当人们自己设定最后期限时，他们往往会真正掌握最后期限。 当在没有他们的参与的情况下给他们设定最后期限时，最后期限对于执行工作的人来说往往变得毫无意义。
Taken from a corporate development standpoint...
If the deadline came from someone other than the person performing the work, review the situation to determine the cause of the overrun. In these cases, it is often related to incomplete requirements, scope creep, poor management, etc. No punishment should be given for missing a deadline that the person never provided in the first place.
If the deadline was provided or agreed upon by the individual performing the work, then that person needs to explain the factors that led to the delay. In addition, this person should be reminded to notify their supervisor, project manager, or other responsible party as soon as they are aware that a deadline may be missed. This information should not come to light after the deadline has passed. If this occurs repeatedly, your company's disciplinary process should be followed. This may involve write-ups, suspensions, or termination.
People tend to take real ownership of deadlines when they are the ones setting them. When deadlines are placed on them without their input, deadlines tend to become meaningless to the person performing the work.
你的问题本质上是有缺陷的：它假设惩罚是管理人员的最佳方式。 一般来说，人们对惩罚或惩罚威胁反应不佳； 它会带来最糟糕的行为，使动机变得外在，并分散内部动机的注意力。 奖励和贿赂（奖励威胁）是同一枚硬币的另一面，而且效果并没有更好。
然而，这些力量是为雇佣工作而生的，所以你永远不会从你的程序员那里得到最好的创造性工作，但你不必在他们错过最后期限时惩罚他们，让情况变得更糟。
相反，请思考创意过程、多人进行创意工作的混乱，以及哪些工具可以有效管理混乱。
要管理任何混乱的系统，请进行大量测量并准备好快速改变方向。 就编程而言：
采取尽可能最小的步骤。 不要“将任务分解为小步骤”，因为您会浪费大量时间来计划不会按计划进行的步骤。 混乱，还记得吗？
选择能够提供最大价值的最小步骤。
不久之后，根据您学到的知识重新评估您的计划
向实际的客户交付工作软件，以便他们可以告诉您您应该真正做什么。
您可能会认为这是 SCRUM 背后的思想。
Your question is inherently flawed: it assumes that punishment is the best way to manage people. In general, that people don't respond well to punishment or threats of punishment; it brings out the worst behaviors, make the motivation external, and distracts from internal motivation. Rewards and bribes (threats of reward) are the other side of the same coin, and do no better.
These forces are built in to work for hire, however, so you'll never get the best creative work out of your programmers, but you don't have to make it worse by punishing them when they miss a deadline.
Instead, meditate on the creative process, the chaos of multiple people doing creative work, and what tools are effective in managing chaos.
To manage any chaotic system, do lots of measurement and be ready to change course quickly. In the case of programming:
Take the smallest steps possible. Don't "break the task in to small steps", as you'll waste a lot time planning steps that won't work out like you planned. Chaos, remember?
Pick the smallest steps that deliver the most value.
after a short period, reevaluate your plan based on what you've learned
deliver working software to actual, real customers as soon as possible, so they can tell you what you should really be doing.
You may recognize this as the thinking behind SCRUM.
鞭打
Flogging
有两种可能性：
我建议不要考虑处罚，而是进行事后分析，以确定出了什么问题，并找到改进下一个截止日期估计的方法。
There are two possibilities:
Rather than thinking in terms of penalties, I would suggest doing a post-mortem to determine what went wrong and finding ways to improve the next deadline estimate.
你问“惩罚应该是什么......”。 看来你是从“公司内部”的角度来问的。
在现实生活中，处罚往往是迅速而严厉的——业务损失、诉讼、行业声誉不佳。 这些是对未在特定日期之前兑现承诺的客户所施加的真正处罚。
在内部，你常常可以做任何你喜欢做的事情。 但一旦你开始涉及付费客户，那么管理这些客户就成为整个工作的关键部分。
通过与客户的“顶层”沟通，通常可以避免（或减轻）我所描述的惩罚。 如果客户想要添加一些东西（所谓的功能蔓延），那么应该立即回答这些变化将对项目产生的影响（成本更高，稍后交付，等等）。 应鼓励客户根据截止日期和预计成本对所有此类请求进行分类（即让客户管理功能蔓延，而不是您）。
如果其他事情改变了交货时间，那么一旦您知道会有延误，您必须立即通知客户。 如果尽早完成，客户会非常愿意与您合作。 但如果你什么都不说，直到为时已晚，他们就不太可能原谅……尤其是如果他们发现你很早就知道但没有告诉他们。
干杯，
-理查德
You ask "what should the penalty be...". It would appear you are asking from the perspective of "inside the company".
In real life, the penalties are often swift and severe - loss of business, lawsuits, bad reputation in the industry. These are the REAL penalties imposed by clients who were promised something by a certain date that was not fulfilled.
Internally, you can often do whatever you like. But once you start involving paying clients, then managing those clients becomes a critical part of the overall job.
Penalties such as I described can often be avoided (or lessened) by "on top" communication with the client. If the client wants something added (so-called feature creep), then this should immediately be answered with the impact these changes will have on the project (costs more, delivered later, whatever). The client should be encouraged to triage all such requests against their deadlines and projected costs (i.e. let the client manage feature creep, not you).
If other things change the delivery time, then as soon as you know there will be slippage, you must inform the client. If done early, clients are remarkably willing to work with you. But if you don't say anything until it's too late, they are less likely to forgive... especially should they discover you knew a significant time earlier and didn't tell them.
Cheers,
-Richard
我见过高管在错过一些最后期限后不久就离开公司。 这改变了一切，但并不一定会让事情变得更好或更糟。 我见过一些合同义务，例如回拨，作为惩罚某人错过最后期限的一种方式，但我不确定它们的效果如何。
当一个项目在分配的时间中途完全改变项目应该做的事情时，往往会导致最初的轨迹不再有效，因此项目将失败，因为它可能无法在规定的时间内满足最初的截止日期预算。 将项目重新规划为最多几个月的短期增量是一种回应，我认为这是使项目获得良好结果的逻辑方向，因为许多项目可能必须适应不断变化的需求，这些需求很容易改变最后期限、人员数量或
I've seen executives leave a company shortly after some deadlines were missed. This changed everything but didn't necessarily make things better or worse. I've seen some contractual obligations like clawbacks as a way to penalize someone for missing a deadline that I'm not sure how well they work.
When one completely changes what a project is supposed to do midway through the alloted time for the project that tends to cause the initial trajectory to no longer be valid and thus the project will fail because it likely will not meet the initial deadlines within budgets. Replanning the project into short increments of at most a few months is a response that I believe is a logical direction to take a project to get good results as a lot of project may have to accomodate changing requirements which can easily change deadlines, head count or time worked.
如果不顾开发人员及其领导的所有建议而设定不切实际的短开发时间框架，应该受到什么惩罚？
巧合的是，这种情况几乎与开发团队错过发布日期一样频繁发生。
What should the penalty be for setting an unrealistically short development timeframe against all of the advice of the developers and their leads?
Coincidentally, this seems to happen almost as often as development teams missing ship dates.
这实际上不是一个编程问题，而更多的是管理问题。
错过最后期限很少是开发商的错。 作为一名开发人员，你应该尽力做好工作，但最终每个人的能力都是有限的。 如果开发人员付出了诚实的努力，尽管如此，还是错过了最后期限，这意味着最后期限从一开始就是不现实的。
处理最后期限是管理者的责任。 有不同的方法，但没有一种方法包括“惩罚”开发人员的工作。 这里需要理解的重要一点是所谓的项目管理三角形。 这意味着软件项目可以是好的（即满足要求、良好的质量）、快速的（满足最后期限）和便宜的（人员数量、工具）。 问题是这 3 个属性中只能选择 2 个。
因此，如果管理层想要一些又好又快的东西，那么它的价格就不会便宜。
如果管理层想要一些又好又便宜的东西——那不会很快。
最后，如果管理层想要便宜和快速——你猜怎么着，那不会有任何好处。
因此，对错过最后期限的正确反应取决于所选择的场景。 又好又快需要添加一些额外的帮助、更好的工具、对高于平均水平的开发人员的投资等等。
又好又便宜的定义就意味着会错过最后期限（暴雪、《魔兽世界》的制造商就是这种方法的好例子）
最后，便宜和快速通常意味着削减功能并发布带有错误的版本。
This is not really a programming question, but more of the management question.
Missed deadlines are rarely developer's fault. As a developer you should try your best to do as good work as you can, but in the end everyone is capable of only so much. If developers put in honest effort and despite this the deadline was missed, it means that the deadline was unrealistic to begin with.
Dealing with deadlines is responsibility of managers. There are different approaches but none of them include "penalizing" developers for doing their job. An important thing to understand here is the so-called project management triangle. What it means is that software project can be good (i.e. meeting requirements, good quality), fast (meeting deadlines) and cheap (headcounts, tools). The trouble is that only 2 out of these 3 properties can be chosen.
So if management want something good and fast - it is not going to be cheap.
If management want something good and cheap - it won't be fast.
And finally if management want cheap and fast - guess what, it won't be any good.
So the correct response to missed deadline depends on the chosen scenario. Good and fast requires adding some extra help, better tools, investment in above-average developers and more.
Good and cheap by definition assumes that deadlines are going to be missed (Blizzard, makers of World Of Warcraft are good example of this approach)
And finally cheap and fast usually means cutting features and releasing with bugs.
项目管理的主要目标是及时规划如何构建应用程序。 如果您没有一个时间表来显示项目将持续的每一天要做什么，您就不应该开始项目开发。
这样，只要您定期（每周，如果不是每天）跟踪项目的进展，您就可以检测到自己将要迟到。 您知道得越早，就能越早采取相应行动。
您通常有两种选择：
对于第二种选择，我并不是说永远不会有惩罚。 但从我个人的经验来看，只要提前告知客户并提供解决方案（最好是三个：为额外的工人提供更多的钱/删除功能以节省一些时间/接受迟到的项目），他们就会愿意谈判。 这总是比冲突更好:)
The main goal of project management is to plan how an application is going to be built, in time. You should not start your project development if you don't have a schedule showing what you're going to be doing every single day the project will last.
This way, you can detect that you're going to be late, as long as you follow the project's evolution on a regular (weekly if not daily) basis. And the earlier you know it, the sooner you can act accordingly.
You usually have two options :
For the second option, I'm not meaning there won't ever be penalties. But from my personal experience, as long as the customer is informed in advance and offered solutions (preferably three : give more money for additional workers/remove features to save some time/accept the project being late), they'll be open to negociation. Which is always better than conflicts :)
也许更好的问题是，面对不准确的估计，最后期限是否有意义？ 企业评估软件的工作很糟糕 ——这是事实。 管理层和开发人员都参与其中，但似乎谁都不愿意承认自己在这个问题上的责任。
但要回答您的具体问题：
我见过的经理和开发人员因错过最后期限而受到的“惩罚”范围很广，从无罚金到升职，再到简单的调动。 我亲眼目睹的最严厉的处罚是经理被“调动”到不太重要的项目，并且业务部门失去了财务奖金。
我唯一一次看到有人因错过最后期限而被解雇，是在该员工已经要被解雇的情况下——最后期限给了企业解雇该员工的合法理由。
这是一个完全独立的讨论……但是这个问题存在一些固有的偏见——项目管理有问题。
我个人见过的 PM 破坏项目的最重要的三件事是（按严重程度排序）：
我还没有见过一个功能齐全的软件开发组织。 因此，解决方案通常需要几位英勇的开发人员与一位能力很强的 PM 一起工作，付出大量的血、汗和泪水，PM 知道如何抵御公司内部的政治（即转移员工的胡言乱语）。
Perhaps the better question is if deadlines are meaningful in the face of inaccurate estimates? Businesses do a lousy job of estimating software--that is a fact. Both management and developers play a part in this and neither one seems willing to own-up to their responsibility in this problem.
But to answer your specific questions:
The 'penalty' I've seen for missed deadlines for managers and developers range from nothing, to promotion, to simple transfer. The most severe penalties I've personally witnessed was a manager "transferred" to a less important project and for the business-unit to lose a financial bonus.
The only time I have ever seen someone fired over a missed deadline was when the employee was already going to be fired--the deadline gave the business a legal reason to fire the employee.
This is a whole separate discussion on its own... but there is some inherent bias in this question--project management is at fault.
The three top things I have personally seen PM's do that sabotage a project are (in order of severity):
I have yet to see a functional software development organization. So the fix is usually a lot of blood, sweat, and tears from a couple of heroic developers working with a highly-capable PM who knows how to defend against politics within the company (i.e. deflect BS from their staff).
我因为错过最后期限而被解雇，我的产品已经完成了 98%，外部力量和最后期限是该公司不允许软件正确开发的。 即使我承认我在这种情况下写了一些糟糕的代码，但我也写了一些好的可维护的代码。 没有考虑功能蔓延，事实上，没有预先详细说明技术规范，并且需要对功能进行调整，因为软件的有限版本和有缺陷的版本可供管理层审查。 我本来可以更好地沟通，但当我沟通时，有人强调最后期限是不容协商的。
I got fired for missing a deadline, I was 98% finished with the product, external forces and deadlines that are that firm don't allow software to be developed properly. Even I can admit I wrote some poor code under the circumstances, but I also wrote some good maintainable code as well. No consideration was given for feature creep, infact no technical specifications were detailed upfront and adaptation of functionality was required as limited and buggy versions of the software became available for managements review. I could have communicated better, but when I did communicate it was emphasized that deadlines are non-negotiable.
当错过最后期限时，我会想到两个明显的问题：
显然，如果有人给你提供了一个没有意义的截止日期，那么不应该因为错过截止日期而受到任何惩罚。 此外，如果有人因为被征召担任陪审员而错过了最后期限，也不应该对他们不利。
如果这些问题不适用，那么接下来要做的就是找出问题所在。 如果您根据开发人员对编写代码所需时间的估计来估计某件事需要多长时间以及最终期限，那么他们的反应可能过于乐观。
Two obvious questions come to mind when a deadline was missed:
Obviously, if someone presents you with a deadline that doesn't make sense then there shouldn't be any penalty for missing the deadline. Also, if someone misses a deadline because they were called up for jury duty that also shouldn't be held against them as well.
In the event those questions don't apply then the next thing to do is to figure out what went wrong. If you based your estimate for how long something would take, and thus the deadline, on the developers estimation of how long it would take them to write the code then perhaps they were too optimistic in their responses.
截止日期是关于如何进行软件开发的根本错误想法的一部分。 软件开发行业的新手或非软件开发行业的人不明白这一点：
软件完成后就完成了，不早不晚。
如果开发人员有一项任务，需要一周的时间来完成它，而且看起来需要一个多星期的时间，没有什么可以改变这一点。 无论开发人员多么努力，无论任务中添加了多少人，它仍然会花费很长时间（事实上，添加人员通常会导致花费更长的时间）。
相反，请阅读敏捷开发流程。 软件应该迭代开发，并且每次迭代都应该基于前一次迭代的结果，而不是基于外部强加的需求。
根据下面的广泛评论进行编辑：
我永远不会争辩说开发人员不能坚持某种交付期望。 我的观点是为了回应提问者提出的特定假设 - 商业软件开发的本质在某种程度上类似于学校作业或任何其他类型的工作。 我认为绝对不是。 “最后期限”不仅仅意味着一个简单的交付日期。 这是必须完成固定工作量的固定点。 软件根本就不是这样工作的。 我又写了几段解释原因，但老实说，如果您还不相信这一点，那么我所说的一切都无法说服您。
如果您正在开发一个软件项目，并且很明显您将无法在截止日期前完成，您可以采取什么措施来纠正这个问题？ 答案现在已经众所周知：几乎什么也没有。 您无法添加更多人。 你无法“更快地工作”。 它只是不会按时完成。 你告诉利益相关者，每个人都会调整，并继续工作（或不工作）。 那么，原来的日期是什么意思呢？
任何声称软件开发类似于架桥或家庭作业的人，或者声称如果开发人员齐心协力、拼命工作，仍然可以满足即将到来的最后期限的人，他们对自己的职业深感困惑。
Deadlines are part of a fundamentally wrong idea about how to do software development. People new to, or outside of, the software development industry do not understand this:
Software is done when it is done, no sooner and no later.
If a developer has a task and a week to do it, and it looks like it will take more than a week, nothing can be done to change that. No matter how much harder the developer works, no matter how many people are added to the task, it will still take as long as it takes (in fact adding people usually makes it take longer).
Instead, read up on the agile development process. Software should be developed iteratively, and each iteration should be based on the results of the previous iteration, not on external requirements imposed.
Edit based on the extensive comments below:
I would never argue that developers cannot be held to some kind of delivery expectation. My point is in response to the specific hypothesis which the asker posed - that the nature of software development in business is somehow analogous to schoolwork, or any other kind of work for that matter. I contend that it absolutely is not. "Deadline" implies much more than a simple delivery date. It is a fixed point by which a fixed amount of work must be completed. Software simply does not work that way. I wrote a few more paragraphs explaining why, but honestly if you don't already believe that, nothing I say is going to convince you.
If you are working on a software project and it is clear you will not be able to reach your deadline, what can you do to rectify that? The answer is well-known by now: practically nothing. You can't add more people. You can't "work faster". It's just not going to get done on time. You tell the stakeholders, everyone adjusts, and keep working (or not). What, then, did the original date mean?
Anyone who claims software development is analogous to bridge-building or homework or that impending deadlines can still be met if the developers would just get their shit together and work their asses off, are deeply confused about their own profession.
你的第一反应不应该是针对错过的最后期限做什么，而是分析为什么你错过了最后期限。 对于错过最后期限的反应将自然而然地随之而来，作为原因的结果。
例如，如果所有相关人员都没有做好自己的工作，那就解雇他们。
但如果他们完成了自己的工作，甚至更多，那为什么仍然没有完成呢？ 同一个人做了太多其他活动？ 截止日期范围太大（即不切实际的截止日期）。 或者……等等。
根据我的经验，错过最后期限的首要原因是人们不允许 100% 地完成手头的项目，因此您可能拥有的任何估计，尽管其本身是准确的，但并不准确真的很有用。 再加上不切实际的估计和截止日期。
Your first reaction should not be what to do in response to the missed deadline, but to analyse why you missed the deadline. The response to missing the deadline would then follow naturally from that as a consequence of the reason.
For instance, if everyone involved didn't do their job, fire them.
But if they did their job, and more, then why was it still missed? Too much other activities done by the same people? Too big a scope for the deadline (ie. unrealistic deadline). Or ... etc.
The top reason for missing a deadline in my experience is that people aren't allowed to work 100% on the project at hand, and thus any estimates you might have, although accurate on their own, aren't really useful at all. That, plus unrealistic estimates and deadlines.
开发人员永远不应该因为管理层的错误而受到惩罚。
这就像父母惩罚孩子，因为父母度过了糟糕的一天。
推理：
最后期限是生活中的一个事实。 人们想知道某件事需要多长时间。 我们能做的最好的就是估计/猜测。 管理层的职责就是尝试找出这种神奇的、永远不正确的猜测。 当他们设定截止日期时，他们需要使用正确的工具（经验、向开发人员、律师、人力资源等寻求帮助）
但是......
错过最后期限不应该让工人承担责任。 错过最后期限是管理层的错。 他们应该拒绝，应该缩减项目规模，或者应该更好地激励工人。
在建筑队，如果你惹恼了工人，就会引发争吵。 在我的公司，如果我们错过最后期限，管理层就会遇到麻烦。 不是工人。 经理的工作是控制项目和所做的事情。 工人们只是做他们能做的。 经理负责分配角色和任务。
我并不是说工人的素质不是一个因素，但管理层应该知道这一点！ 不需要天才就能知道一个项目没有经过深思熟虑或没有得到很好的控制。 询问任何人他们的经理是否知道发生了什么，你就会发现问题所在。
当经理们意识到设定/同意最后期限是他们的错时，我们就不再错过那么多的最后期限。
回复：问题：
1.您认为哪些措施是对错过最后期限的“惩罚”，哪些措施实际上使事情变得“更好”？
2.哪些项目管理响应导致项目彻底失败，哪些响应恢复了工作秩序并产生了随后可以维护的代码？
Developers should never be penalized for Management's mistakes.
It's like a parent punishing a child because the parent had a bad day.
Reasoning:
Deadlines are a fact of life. People want to know how long something will take. The best we can do is estimate/guess. It is the role of management to try to figure this magical, never correct guess. When they create a deadline, they need to use the right tools (experience, ASKING FOR HELP FROM DEVELOPERS, lawyers, hr, etc)
However....
The penalty for missing a deadline should not fall back on the workers. It is the management's fault for missing deadlines. They should have said no, should have scaled back the project or should have motivated the workers better.
In a construction crew, if you piss of the workers, you start a fight. In my company, if we miss deadlines, the management gets in trouble. Not the workers. It's the manager's job to control the project and what is done. The workers are only doing what they can. The manager's are in charge of assigning roles and tasks.
I'm not saying the quality of workers isn't a factor, but the management should KNOW that! It doesn't take a genius to know that a project isn't well thought through or nicely controlled. Ask anybody if their manager has any idea what's going on and you'll find the problem.
We stopped missing as many deadlines when the managers realized it was their fault for setting/agreeing to the deadlines.
Re: The questions:
1.What actions have you seen applied as 'penalty' for missed deadline, and which of these actually made things 'better'?
2.What project-management responses caused the project to fail outright, and what responses restored working order and resulted in code that could be maintained afterward?
与其惩罚，不如现实的估计和按时发布的奖励怎么样？
受到对我的回复的评论的启发
也许问题应该是“我如何做出切合实际的估计？” 对我来说，我使用 FogBugz 估计历史记录 和 完成日期 绘图。 这些为我提供了我估计任务需要多长时间以及实际需要多长时间的数据点。 这有助于指导我给出现实的长期发布日期（这不是一夜之间发生的）。 我发现估算时间表是一个交互式过程：我
Rather than a penalty, how about realistic estimates and rewarding on-time releases?
Inspired by the comments to my response
Maybe the question should be "How do I make realistic estimates?" For me, I use FogBugz estimation history and completion date plots. These give me data points of how long I estimated a task to take and how long it actually took. This has helped guide me to give realistic release dates in the long-run (it didn't happen overnight). I find estimating timelines to be an interative process: I