成功项目管理的秘密.pdf

成功项目管理的秘密

摘自SDMagazine，KarlWiegers著，UMLChina.Shids译

模式小组-雷神整理

在最好的情况下，管理软件项目也是很困难的。不幸的是，许多新项目经理实质上没有

受到任何就职培训。这里有20个成功的管理经验供项目经理参考。

定义项目成功的标准2

识别项目的驱动、约束和自由程度2

定义产品发布标准2

沟通承诺2

写一个计划2

把任务分解成英寸大小的小圆石2

为通用的大任务开发计划工作表3

计划中，在质量控制活动后应该有修改工作3

为过程改进安排时间3

管理项目的风险3

根据工作计划而不是日历来作估计3

不要为人员安排超过他们80％的时间3

将培训时间放到计划中4

记录你的估算和你是如何达到估算的4

记录估算并且使用估算工具4

遵守学习曲线4

考虑意外缓冲4

记录实际情况与估算情况4

只有当任务100%完成时，才认为该任务完成5

公开、公正地跟踪项目状态5

定义项目成功的标准

在项目的开始，要保证风险承担者对于他们如何判断项目是否成功有统一的认识。经常，

满足一个预定义的进度安排是唯一明显的成功因素，但是肯定还有其他的因素存在，比如：

增加市场占有率，获得指定的销售量或销售额，取得特定用户满意程度，淘汰一个高维护需

求的遗留系统，取得一个特定的事务处理量并保证正确性。

识别项目的驱动、约束和自由程度

每个项目都需要平衡它的功能性，人员，预算，进度和质量目标。我们把以上五个项目

方面中的每一个方面，要么定义成一个约束，你必须在这个约束中进行操作，要么定义成与

项目成功对应的驱动，或者定义成通向成功的自由程度，你可以在一个规定的范围内调整。

相关的详细信息，请参照我的《创建一种软件工程文化》（CreatingaSoftwareEngineering

Culture）（DorsetHouse,1996）中的第二章。

定义产品发布标准

在项目早期，要决定用什么标准来确定产品是否准备好发布了。你可以把发布标准基于：

还存在有多少个高优先级的缺陷，性能度量，特定功能完全可操作，或其他方面表明项目已

经达到了它的目的。不管你选择了什么标准，都应该是可实现的、可测量的、文档化的，并

且与你的客户指的“质量”一致。

沟通承诺

尽管有承诺不可能事件的压力，从不作一个你知道你不能保证的承诺。和客户和管理人

员沟通哪些可以实际取得时，要有好的信誉。你的任何以前项目的数据会帮助你作说服的论

据，虽然这对于不讲道理的人来说没有任何真正的防御作用。

写一个计划

有些人认为，花时间写计划还不如花时间写代码，但是我不这么认为。困难的部分不是

写计划。困难的部分是作这个计划--思考，沟通，权衡，交流，提问并且倾听。你用来分析

解决问题需要花费的时间，会减少项目以后会带给你的意外。

把任务分解成英寸大小的小圆石

英寸大小的小圆石是缩小了的里程碑。把大任务分解成多个小任务，帮助你更加精确的

估计它们，暴露出在其他情况下你可能没有想到的工作活动，并且保证更加精确、细密的状

态跟踪。

为通用的大任务开发计划工作表

如果你的组经常承担某种特定的通用任务，如实现一个新的对象类，你需要为这些任务

开发一个活动检查列表和计划工作表。每个检查列表应该包括这个大任务可能需要的所有步

骤。这些检查列表和工作表将帮助小组成员确定和评估与他/她必须处理的大任务的每个实

例相关的工作量。

计划中，在质量控制活动后应该有修改工作

几乎所有的质量控制活动，如测试和技术评审，都会发现缺陷或其他提高的可能。你的

项目进度或工作细分结构，应该把每次质量控制活动后的修改，作为一个单独的任务包括进

去。如果你事实上不用作任何的修改，很好，你已经走在了本任务的计划前面。但是不要去

指望它。

为过程改进安排时间

你的小组成员已经淹没在他们当前的项目中，但是如果你想把你的组提升到一个更高的

软件工程能力水平，你就必须投资一些时间在过程改进上。从你的项目进度中留出一些时间，

因为软件项目活动应该包括做能够帮助你下一个项目更加成功的过程改进。不要把你项目成

员可以利用的时间100％的投入到项目任务中，然后惊讶于为什么他们在主动提高方面没有

任何进展。

管理项目的风险

如果你不去识别和控制风险，那么它们会控制你。在项目计划时花一些时间集体讨论可

能的风险因素，评估它们的潜在危害，并且决定你如何减轻或预防它们。要一个软件风险管

理的简要的指南，参见我的