项目管理的成功秘密(翻译)

Secrets of Successful Project Management
November 1999
Managing software projects is difficult under the best circumstances. Unfortunately, many new project managers receive virtually no job training. Here are 20 tips for success.
项目管理的成功秘密
项目管理在最好的环境中也是困难的。不幸地，许多新的项目管理者没有接受过工作训练，这里是20条成功的技巧。
by Karl Wiegers
Define project success criteria.
At the beginning of the project, make sure the stakeholders share a common understanding of how they will determine whether this project is successful. Too often, meeting a predetermined schedule is the only apparent success factor, but there are certainly others. Some examples are increasing market share, reaching a specified sales volume or revenue, achieving specific customer satisfaction measures, retiring a high-maintenance legacy system, and achieving a particular transaction processing volume and correctness.
项目成功标准的定义
在一个项目的开始，确信每一个投资者是否都已经下定决心使项目获得成功。通常，通过会议研究出一个进度表是成功的要素，这样的确可行。一些增加市场份儿的例子，达到制定的销售量或收入、完成制定的消费满意度、系统维护和升级的费用、完成事务处理的细节和正确性。
Identify project drivers, constraints, and degrees of freedom.
Every project needs to balance its functionality, staffing, budget, schedule, and quality objectives. Define each of these five project dimensions as either a constraint within which you must operate, a driver aligned with project success, or a degree of freedom that you can adjust within some stated bounds to succeed. For more details about this, see Chapter 2 of my book Creating a Software Engineering Culture (Dorset House, 1996).
确定项目的执行者、约束机制、自由度。每一个项目都需要平衡项目的的功能、人员、预算、进度、品质目标。这里定义的五个元素中的每一个都会在项目中起作用。执行者使项目成功，你可以调整在一些范围内获得一定程度成功的自由。

Define product release criteria.
Early in the project, decide what criteria will determine whether or not the product is ready for release. You might base release criteria on the number of high-priority defects still open, performance measurements, specific functionality being fully operational, or other indicators that the project has met its goals. Whatever criteria you choose should be realistic, measurable, documented, and aligned with what “quality” means to your customers.
产品版本定义标准
项目的初期，什么标准决定产品是否将要发布？你可以使用依次升高的数字作为发布的标准、性能度量、明确的功能被充分的运用或者指定的其他目标。无论怎样你必须有现实的、可测量的、文档化的标准和对客户的质量承诺。
Negotiate commitments.
Despite pressure to promise the impossible, never make a commitment you know you can’t keep. Engage in good-faith negotiations with customers and managers about what is realistically achievable. Any data you have from previous projects will help you make persuasive arguments, although there is no real defense against unreasonable people.
磋商许诺
不要因为压力而做出许诺，永远不要作出你知道不可能做到的许诺。同客户和经理协商出一个实际可以完成的好的保证。任何以前项目的数据都可以帮助你做出具有说服力的论据，如果你没有遇见坚决反对、不讲道理的人。
Write a plan.
Some people believe the time spent writing a plan could be better spent writing code, but I don’t agree. The hard part isn’t writing the plan. The hard part is actually doing the planning-thinking, negotiating, balancing, talking, asking, and listening. The time you spend analyzing what it will take to solve the problem will reduce the number of surprises you have to cope with later in the project.
写一个计划
一些人相信用尽时间写计划可能比用尽时间写代码要好，但我不这么认为。最困难的部分不是写计划。最困难的部分是实际的去做计划：思考、谈判、平衡、讨论、询问以及倾听。这时你花费时间分析什么能够解决问题，减少项目今后可能出现的突发事件的数量。
Decompose tasks to inch-pebble granularity.
Inch-pebbles are miniature milestones. Breaking large tasks into multiple small tasks helps you estimate them more accurately, reveals work activities you might not have thought of otherwise, and permits more accurate, fine-grained status tracking.
分解任务到最小单元（每一个小圆石的粒度）
小圆石是微型的里程碑，分解大的任务到若干小任务可以帮助你更加正确的作出估价---你也许不能通过别的方式解释工作行为
Develop planning work sheets for common large tasks.
If your team frequently undertakes certain common tasks, such as implementing a new object class, develop activity checklists and planning worksheets for these tasks. Each checklist should include all of the steps the large task might need. These checklists and worksheets will help each team member identify and estimate the effort associated with each instance of the large task he or she must tackle.
为大的任务编制开发计划
假如你的小组常常承担一些确定的任务，例如执行一个新的项目种类，需要为这些任务设计行动检查列表和编制工作表。每一个检查列表需要包括这个大项目的所有需要的步骤。这些检查列表和工作表将帮助每一个小组成员识别和评估对这个大任务中他或她需要解决的相关工作。
Plan to do rework after a quality control activity.
Almost all quality control activities, such as testing and technical reviews, find defects or other improvement opportunities. Your project schedule or work breakdown structure should include rework as a discrete task after every quality control activity. If you don’t actually have to do any rework, great; you’re ahead of schedule on that task. But don’t count on it.
按照计划改写质量控制工作
几乎所有的质量控制工作，例如象测试和技术评论，发现缺点或改进机会。在质量控制过程完成后对你的项目进度表或工作的细目分类结构需要做出新的改写。假如你竟然不用做出任何的改写，了不起，你已经在进度表前面了，但是不要指望这些。
Plan time for process improvement.
Your team members are already swamped with their current project assignments, but if you want the group to rise to a higher plane of software engineering capability, you’ll have to invest some time in process improvement. Set aside some time from your project schedule, because software project activities should include making process changes that will help your next project be even more successful. Don’t allocate 100% of your team members’ available time to project tasks and then wonder why they don’t make any progress on the improvement initiatives.
安排时间对方法作出改进
你的小组成员是已经淹没在他们当前的项目分配中了，但是假如你想让小组的软件工程能力上升到更高的层次，你将不得不投入一些时间用于改进方法。从你的项目进度表中设置其他一些时间，因为软件项目行为应该包括一些变动，这将帮助你在下一个项目中获得成功。不要分配100%的时间让你的项目成员投入在项目任务中，否则你会惊讶为什么他们没有任何主动的改进。
Manage project risks.
If you don’t identify and control risks, they will control you. Spend some time during project planning to brainstorm possible risk factors, evaluate their potential threat, and decide how you can mitigate or prevent them. For a concise tutorial on software risk management, see my article “Know Your Enemy: Software Risk Management” (Oct. 1998).
控制项目风险
假如你没有识别和控制项目风险，它们将控制你！在项目计划编制中花费一些时间用于集体讨论可能的风险要素。评估风险的潜在威胁，决定你将如何减轻和预防风险。对项目风险有一个简明的指南，看我的著作“Know Your Enemy: Software Risk Management”。
Estimate based on effort, not calendar time.
People generally provide estimates in units of calendar time, but I prefer to estimate the amount of effort (in labor hours) associated with a task, then translate the effort into a calendar-time estimate. This translation is based on estimates of how many effective hours I can spend on project tasks per day, any interruptions or emergency fix requests I might get, meetings, and all the other places into which time disappears.
评估基于成就而不是时间
人们通常的评估是单位时间，但是我更喜欢的评估方法是在一个任务中结合劳动时间的成就数量，然后转换这些成就到时间评估。这些转换是基于我每天用于项目任务中的有效时间的评估，我可能会遇到任何的中断或突然事件的请求， 会议或是其他一些事情都会让我的时间消逝。
Don’t schedule people for more than 80% of their time.
Tracking the average weekly hours that your team members actually spend working on their project assignments is a real eye-opener. The task-switching overhead associated with the many activities we are all asked to do reduces our effectiveness significantly. Don’t assume that just because someone spends 10 hours per week on a particular activity, he or she can do four of them at once; you’ll be lucky if he or she can handle three.
不要让时间表占用他人80%以上的时间
跟踪你的小组上成员每周实际的可以看见的花费在他们的项目任务中的平均工作时间。值得注目地上面的行为相互关系的转换也会减少我们的效力，不要假定刚好某人在细节行为上每周刚好花费10小时，她或他一次能做四个同样的事情，如果他们处理3个你就是幸运的了。
Build training time into the schedule.
Determine how much time your team members typically spend on training activities annually, and subtract that from the time available for them to be assigned to project tasks. You probably already subtract out average values for vacation time, sick time, and other assignments; treat training time the same way.
在时间表中加入训练时间
决定你的成员一年在行为训练上花费多少时间，减去他们在项目任务中的有效时间，你可能已经减去了平均休假时间、生病时间和其他一些，作为训练时间是一样的。
Record estimates and how you derived them.
When you prepare estimates for your work, write them down and document how you arrived at each one. Understanding the assumptions and approaches used to create an estimate will make them easier to defend and adjust when necessary, and it will help you improve your estimation process.
记录评估和你如何获得它们
当你准备评估你的工作，对每个人都记录和文档化。必须明白用于创建一个评估的设想和方法必须比较容易定义和调整，同时它能够帮助你改进你的评估过程。
Record estimates and use estimation tools.
Many commercial tools are available to help you estimate entire projects. With their large databases of actual project experience, these tools can give you a spectrum of possible schedule and staff allocation options. They’ll also help you stay out of the “impossible region,” combinations of product size, team size, and schedule where no known project has been successful. A good tool to try is Estimate Pro from the Software Productivity Centre (www.spc.ca).
报告评估和评估工具
许多商业工具可以帮助你评估整个项目。在他们数据库项目的实际体验中，这些工具可以使你建立可行的进度表和工作人员分配选择。他们对不知道可否成功的项目可以结合产品大小、人员数量和进度表帮助你脱离“不可能的区域”。一个好的试用工具可在www.spc.ca获得。

Respect the learning curve.
If you’re trying new processes, tools, or technologies for the first time on this project, recognize that you will pay a price in terms of a short-term productivity loss. Don’t expect to get the fabulous benefits of new software engineering approaches on the first try, and build extra time into the schedule to account for the inevitable learning curve.
注意学习曲线
如果你在一个项目中的一次试用一个新方法、一套工具集或一种技术，记住你将为短期内生产力的损失付出代价。不要期待第一次就能够从这个新的软件工程学方法中获得神话般的好处，建立特别的时间到进度表中说明不可避免的学习曲线。
Plan contingency buffers.
Things never go precisely as you plan on a project, so your budget and schedule should include some contingency buffers at the end of major phases to accommodate the unforeseen. Unfortunately, your manager or customer may view these buffers as padding, rather than the sensible acknowledgement of reality that they are. Point to unpleasant surprises on previous projects as a rationale for your foresight.
计划可能的缓冲区
事情绝不会和你如同你的项目计划一般，所以你的预算和进度应该给无法预料的目标包括一些对意外事件的缓冲，不幸的，你的经理和客户也许会视这些缓冲为填料，他们更承认可明确判断的事实，而对你基于前一个项目的基本原理作出的深谋远虑表现出讨厌的吃惊。
Record actuals and estimates.
If you don’t record the actual effort or time spent on each task and compare them to your estimates, you’ll never improve your estimating approach. Your estimates will forever remain guesses.
记录下事实和评估
如果你不对每一个任务记录下实际成果和时间开销以对他们做出评估，你将永远无法改进你的评估方法。你的评估将永远保持猜想。
Count tasks as complete only when they’re 100% complete.
One benefit of using inch-pebbles for task planning is that you can classify each small task as either done or not done, which is more realistic than trying to estimate what percent of a large task is complete at any time. Don’t let people “round up” their task completion status; use explicit criteria to tell whether a step truly is completed.
只有当他们100%完成时才算任务完成
任务计划使用inch-pebbles的一个益处是你可以分类每一个小任务是完成了还是没有做完，这比试图评估一个大任务完成的百分数要更加现实。不要假设人们“围捕”他们任务的完成状态。使用清楚的标准说明一步是否真实的完成。
Track project status openly and honestly.
Create a climate in which team members feel safe reporting project status accurately. Strive to run the project from a foundation of accurate, data-based facts, rather than from the misleading optimism that sometimes arises from fear of reporting bad news. Use project status information to take corrective actions when necessary and to celebrate when you can.
真诚地和公开的跟踪项目的状态
制造一种每个项目组成员都可以安全的报告项目精确进度的风气，以正确的基础、数据事实为基础努力的运作项目胜于令人迷惑的乐观有时发生令人担心的坏消息的报告。使用项目状态信息纠正行为在你必然的和值得庆祝的时候。
These tips won’t guarantee success, but they will help you get a solid handle on your project and ensure that you’re doing all you can to make it succeed in a crazy world.
这些提示并不能保证项目的成功，但是它们是帮助你的项目管理在这个疯狂的世界里获得成功的一个实在的方法
Copyright 1999 Software Development magazine. All rights reserved.

翻译：摇来摇去 2000.02.07

这篇文章一直帮助我做好每一个项目。

当时看这篇文章的时候，我正为项目进度的迟缓，大家状态的萎靡发愁。身为项目经理，如何提高士气，尽快结束项目的开发工作，已经摆在了我的面前。
看过这篇文章后，很快，我就把项目进度落实到每一天，编写项目进度计划，每天进行一次考核。在短时间内，就能见到很大的效果。我认为项目计划很容易做出来，主要的焦点是项目计划的落实。再烂的计划，只要他能严格的执行到底，就是好计划，而且随着大家工作积极性的提高，每个月的计划，做得越来越好。以至于后来，都不再需要我一个人一个人讨论着，为他们编写计划，他们自己就能写出很好的计划。
不能小看这些小小的改变，他让我们做了1年的工作，在短短的半年之内，就得到圆满的结束。

现在，我依然提倡使用落实到每天的项目计划展开工作。只不过，现在的计划更加容易得到落实，不像当初，为了落实计划，强制的进行考核，扣工资，降级别，手段比较强硬。

已经过去了很多年了，现在重新看这段走过的路，心情仿佛回到了2000年，眼前是大伙工作时生龙活虎的景象。

太怀念那段时光了。