方案规划与方案监控.docx

1、方案规划与方案监控第3章 项目规划与项目监控项目规划（Project Planning）的目的是为项目的开发和管理工作制定合理的行动纲领（即项目计划），使所有人员按照该计划有条不紊地开展工作。为了避免词义混淆，这里把动词Planning译为规划，把名词Plan译为计划（或计划书）。项目监控（Project Monitoring and Control）的目的是通过周期性地跟踪项目计划的各种参数如进度、工作量、费用、资源、工作成果、风险等等，不断地了解项目的进展情况，以便当项目实际进展状况显著偏离计划时能够及时采取纠正措施。项目经理正式上任后最主要的管理工作就是项目规划和项目监控。如果没有规划就

2、不知道监控什么，反之如果只有规划而不去监控等于白规划。可见项目规划和项目监控是相辅相成、动态演化的两个过程域。最糟糕的下场是：经费用光了，进度远远落后了，人员累死了，还不知道什么时候能熬出头。本章探讨项目规划与项目监控的方法和规范，让广大项目经理都能学会。3.1 项目规划的概念 为什么要进行项目规划？ 我们生活在城市里，经常发现某些道路被反反复复地挖掘修理，给老百姓的生活添加了很多麻烦。这种现象只有两种解释：（1）市政管理者为了拉动GDP的增长，营造欣欣向荣的景象，就拿马路开刀；（2）管理者根本没有进行市政规划，第一次挖马路铺设煤气管道，第二次挖马路铺设电缆，第三次挖马路铺设光缆，如此折腾简直

3、劳民伤财。 软件项目规划的重点是对人员角色、任务进度、经费、设备资源、工作成果等等做出合适的安排，制定出一些计划（包括高层的和细节的），使大家按照计划行事，最终顺利地达到预定的目标。如果不对项目进行规划的话，一群人天马行空、各干各的，项目进展不到一半就混乱不堪了。 谁在什么时候进行项目规划？在立项管理过程域的项目筹备阶段（参见第二章），机构领导首先任命一位项目经理，之后机构领导协助项目经理筹备项目经费、人力资源、软件硬件资源等。如果必要的资金和资源已经到位，那么项目经理和核心成员即可组成一个项目规划小组，开始进行项目规划。有人疑问，在立项建议书中不是已经有了项目的开发计划了吗？为什么还要进行规

4、划呢？注意，立项建议书中的开发计划仅仅是一种设想而已，因为当时人们并不知道机构是否会采纳这个建议、也不知道领导支持的力度有多大。假设立项建议书中的计划需要10名开发人员和一百万元经费，但是当立项之后机构只能给予5名开发人员和50万元经费，那么原计划必须做出重大调整。项目规划产生的成果是什么？主要是一些计划书（plan），可分两类：一是全局的计划书（Overall Plan），这里称为项目计划；二是一些下属计划书（Subordinate Plan），例如配置管理计划、质量管理计划、阶段开发计划和测试计划等。下属计划书是对项目计划的补充，其内容不可与项目计划冲突。通常项目计划由项目经理负责制定，由

5、机构领导审批。而下属计划书一般由项目成员制定，由项目经理审批即可。项目规划的流程如图3-1所示。按计划执行制定项目计划审批项目计划项目计划变更控制项目估计图3-1项目规划流程图3.2 如何进行项目估计在制定项目计划之前，理应采用恰当的方法对重要的数据进行估计，否则计划就乱写了。一般地，项目估计的要素是软件规模、工作量和人力成本，如果这些要素估计得比较准确得话，那么后续制定的项目计划就比较合理。对于一些外包项目而言，项目估计得到的数据是双方讨价还价的依据。项目估计几乎不可能成为一门精确的科学，因为在项目刚开始时，人们对产品需求和技术的了解还比较肤浅，而项目实际能够拥有经费和资源很大程度上是靠项目

6、经理争取来的，不确定因素比较多。在这种情况下人们很难作出准确的估计。但是大家都认同：依据某种方法（规则）进行估计显然比瞎猜好得多。 常用的项目估计方法大体分为两类，第一类是数学模型，第二类是简单直观的“分解累计”方法；3.2.1 数学模型真的好用吗 采用数学模型这种方法是学术界热衷的，因为有数学公式的东西更显得有学术味道。这类方法适合于非常成熟的软件机构，该机构积累了丰富的历史数据，以至于能够归纳出数学模型来指导新项目的规划。典型的数学模型如 E = A + B(ev) C其中A,B,和C是由经验导出的常数，E是以“人月”为单位的工作量，ev是估算变量如代码行（LOC）或者功能点（FP）。例如

7、基于代码行的数学模型有： Walston-Felix模型 E = 5.2(KLOC)0.91 Bailey-Basili模型 E = 5.5+0.73(KLOC)1.16 Boehm简单模型 E = 3.2(KLOC)1.05基于功能点的数学模型有： Albrecht模型 E = -13.39 + 0.0545 FP Kemerer 模型 E = 60.627.72810-8 FP3 Maston模型 E = 585.7 + 5.12 FP通用性更强的是 Barry Boehm 研制的COCOMO模型（构造性成本模型），分为初级、中级、高级3种形式。（参考Pressman99,p83-p86）

8、我从事软件开发十多年，从来没有采用数学模型进行项目估计，因为根本无法套用，所以我从来就不信这些公式。我公司的一些员工参加了CMM培训课，CMM讲师照本宣科地推荐了COCOMO模型，学员们如获至宝。有一天，某个同事打电话问我：“用COCOMO模型估计工作量时，我们公司的常数是多少？”我说不知道，我从来就没有用过。对方很吃惊地问：“你不是专家吗，怎么连那么著名的COCOMO模型都不会用呢？”我哭笑不得，只好对他说：“你顺便找些数据来计算，就当电脑算命好了。如果你算对了，将来大家都请你来算。”3.2.2 简单直观的估计方法我自己一直都采用简单直观的“分解累计”方法来估计产品规模、工作量和人力资源成本

9、。产品规模估计方法如下：（1）项目规划小组先分解产品的功能，制定“产品功能分解与规模估计表”（如表3-1所示）。产品的模块以及模块的主要功能是比较容易确定的，因为这是项目规划小组必须知道的最起码的功能需求。软件规模的度量单位主要有：代码行、对象个数、页面数等等。我通常用“对象个数”来度量。模块名称模块的主要功能新开发的软件规模（度量单位如对象个数）复用的软件规模（度量单位如对象个数）模块AA.1A.2A.3模块BB.1B.2B.3汇总表3-1 产品功能分解与规模估计表（2）规划小组各成员独立填写表3-1。（3）汇总每个成员的表格，进行对比分析。如果各人估计的差额小于20，则取平均值。如果差额大

10、于20，则转向第（2）步，让各成员重新估计产品的规模，直到各人估计的差额小于20为止。 第（3）步的目的是消除大的差异后取平均，总误差控制在20以内。如果所有的估计值同时偏大或者偏小，那么就将错就错了。因为在项目刚开始的时候，谁也不知道估计准确不准确，只要大家观点相似就行了。工作量估计方法如下：（1）首先确定工作量的度量单位，可以是“人小时”、“人天”、“人月”或“人年”。注意单位换算： 1人年 12人月 1人月 22人天 1人天 8 人小时（2）估算开发工作量。一般地可以把开发过程划分为需求开发、系统设计、实现、测试四个阶段，分别估计每个阶段的工作量，然后累计得出总的工作量，见表3-2。人均

11、生产率是指每个人每天完成的工作成果规模。假如在设计阶段，每人每天可以设计2个对象，若软件总共有100个对象，那么设计阶段的工作量就是50人天。依此类推。（3）估算管理工作量。除了开发之外，项目规划、项目监控、配置管理、质量管理等等也是很费时间的。一般地，项目的80以上的工作量用于开发，20以下的工作量用于管理。项目规划小组可以根据经验，给出一个比例系数，简便地估算管理的工作量。工作量的度量单位1人年 12人月，1人月 22人天，1人天 8 人小时开发工作量估算公式项目开发工作量 新开发的软件规模 / 人均生产率开发阶段人均生产率软件规模工作量需求开发系统设计实现测试开发工作量汇总管理工作量估算

12、公式项目管理工作量 开发工作量 * 比例系数项目管理的主要事务项目规划、项目监控、需求管理、配置管理、质量管理比例系数例如20管理工作量汇总表3-2 工作量估计表如果已经估算出项目的工作量，那么估算人力资源成本就比较容易。每人每年的成本显然高于年薪，因为每个人除了拿工资外，日常还要消耗公司资源，公司要额外支付各种保险金等。一般地，对于软件企业，每人每年的成本大约是其年薪的1.5至2.0倍（姑且称之为成本系数）。如果成本系数太高的话，表示该公司要么福利极好要么铺张浪费；反之如果系数太低的话（最低为1.0），表示该公司福利极低。举个简单的案例：如果乙方想承包甲方的项目，假设乙方估计该项目的工作量为

13、10人年，乙方人员的平均年薪为8万元，成本系数为2.0。请问乙方的人力资源报价如何？（设备成本、差旅费等等另外计算）乙方的人力资源报价应该是 1082.0160万元吗？不对，如果这样报价的话，乙方的老板只好喝西北风了。报价必须考虑利润，假设双方可以接受的利润率为20，那么乙方报价应该是1601.2192万元。乙方应该把报价的详细清单（不是最终结果）给甲方看，表明这个报价是合理的，而不是狮子开大口。甲方要检查这个报价清单，尽可能把里头的“水分”挤出来。双方必然有个讨价还价的过程，如果想说服对方，一定要拿出经得起推敲的数据来，以理服人。否则双方尽是胡侃，最后在酒桌上解决，这是比较低俗的商业谈判（也

14、算得上是国粹了），不值得大家效仿。本节介绍的项目估计方法既可以用在立项建议过程域中，也可以用在项目规划过程域中。在某种情况下，任何的项目估计方法都没有实际价值，那就是：（1）项目的人员已经被上级领导限定死了，再多的活也是那几个人干；（2）除了办公计算机和工资外，这个项目没有其它经费，项目经理只有干活的权利没有用钱的权利；（3）项目的结束日期早就被领导和客户指定了，不管合理不合理，反正时间一到就要交付软件。如果人员、资金、时间都已经被毫无道理地指定了，你进行科学地估计还有啥用？这样的项目在国内并不少见，如果你碰上了，那么就自认倒霉吧。3.3 制定项目计划在进行项目估计之后，项目规划小组即可进一步

15、制定项目计划，模板见表3-3。项目计划的重点内容是： 目标与范围； 过程定义； 人力资源计划； 软硬件资源计划； 财务计划； 任务进度计划； 下属计划。项目计划0. 文档介绍 0.1文档目的 0.2文档范围 0.3读者对象 0.4参考文档 0.5术语与缩写解释 1. 项目介绍 1.1 项目范围提示：（1）用简练的语言说明本项目“是什么”，“什么用途”。（2）说明本产品“适用的领域”和“不适用的领域”；（3）说明本产品“应当包含的内容”和“不包含的内容”。1.2 项目的目标提示：给出清晰的、可以验证的目标。2. 项目过程定义2.1 过程模型提示：描述、绘制本项目的过程模型,可以裁剪SPP模型。2

16、.2 采用的方法与工具提示：说明过程模型中将采用的方法与工具。例如采用Rational Rose进行面向对象分析与设计，采用Visual SourceSafe进行配置管理，采用Microsoft Office 2000制作文档。3. 人力资源计划 人员角色职责项目经理质量管理员4. 软硬件资源计划 软件、硬件名称级别主要配置获取方式用途关键普通5. 财务计划费用类别开支项、用途金额时间6. 任务进度计划提示：制定详细的任务表，并绘制Gantt 图（插入此处或作为附件）。任务名称工作人员工作时间工作成果7. 下属计划提示：下属计划（Subordinate Plan）是对项目计划的补充。项目计划需

17、要机构领导的审批，但下属计划一般只需要项目经理（或其它负责人）审批即可。计划名称负责人预计产生时间配置管理计划质量管理计划阶段开发计划测试计划表3-3 项目计划的参考模板3.4 项目计划审批项目计划的审批流程非常简单：第一步，项目经理把项目计划递交给机构的领导。第二步，机构领导根据“检查表”（见表3-4）认真审阅该项目计划，如果没有异议，那么就签字批准；如果有不同意之处，就和项目经理沟通，并请项目经理及时修改。第三步，机构领导签字批准之后，该项目计划就成为“正式文件”，所有的项目成员都必须按照该计划执行。如果以后要修改项目计划的话，必须准照变更控制流程来修改。如果是合同项目，那么要请客户和机构

18、领导共同审批文件。 项目计划检查表结论项目的目标明确吗？可以验证吗？项目的范围清楚吗？对项目的规模和复杂性的估计可信吗？对项目的工作量估计可信吗？ 对项目的成本估计可信吗？项目的过程控制方案合理吗？项目所有角色的职责清楚吗？人员安排合理吗？项目所需的软件硬件资源合理吗？ 项目财务计划合理吗？任务分配合理吗？进度合理吗？审批结论 批准该计划 不批准意见机构领导签字表3-4 项目计划检查表 需要指出的是，如果机构领导不认真审阅项目计划而例行公事地签字批准的话，那么项目计划的审批流程一点意义都没有。我见过不少雷同的场景，秘书把一叠文件摆在领导的桌面上，领导上班时，一边无聊地翻阅文件一边签字，体会着当

19、领导的快乐与烦恼。 软件机构的领导通常都是稿软件出身的，按理说他比普通项目经理更加清楚如何进行项目规划，所以如果领导不用他的智慧审批项目计划的话，那么领导就是个摆设，对规范化管理没有促进作用。3.5 项目计划变更控制在人们刚开始制定项目计划的时候，由于对项目本身缺乏深入的理解，第一个版本的项目计划有可能比较粗略甚至不切实际。在项目执行过程中如果发现项目计划与实际情况有比较大的偏差，应当及时更新项目计划。所以项目计划不是一成不变的，它将随着项目的进展而逐步完善。项目计划变更控制的目的是：（1）修改原项目计划中不合理的内容，产生新的项目计划；（2）按照指定的流程修改项目计划，防止发生混乱。一般地，

20、若下列情况发生，应当变更项目计划： 进度偏差超过了容许的误差，如20； 费用偏差超过了容许的误差，如20； 项目过程模型发生了显著的变化； 用户需求发生了重大的变化； 发生了不可抗拒的变化，例如公司裁员、机构调整、产品发展战略调整等。项目计划变更控制的流程如下：第一步，项目经理向机构领导提交变更申请书（格式自由），该申请书应当说明：变更原因；变更的内容；此变更对项目造成的影响。第二步，机构领导审批该申请书。如果领导不同意变更，那么项目按照原计划执行；如果同意变更，那么转向第三步。第三步，项目经理制定新的项目计划，并提交给机构领导。第四步，机构领导审批新的项目计划。为了提高效率，第一步和第三步可

21、以合并一起，由项目经理执行。同理第二步和第四步也可以合并一起，由机构领导执行。如果是合同项目，那么要请客户和机构领导共同审批文件。3.6 如何有效地监控项目3.6.1 为什么要进行项目监控 制定项目计划之后，为什么要进行项目监控？ 因为执行计划的是人而不是机器，每个人做事都可能与计划有偏差，何况一群人呢。再者，环境也会发生变化。项目监控至少有以下几个好处：（1）避免原本合理的计划在实施过程时落空；（2）避免“执迷不悟”地按照不合理的计划行事； （3）将监控过程产生的数据保存起来，为机构持续的过程改进提供有价值的数据。 项目监控的基本原理是：将项目实际情况与项目计划进行对比，如果发现某些因素的偏

22、差非常大（超过了容许的误差），那么及时分析原因，给出纠正措施。项目经理不要企图对所有的项目事务进行监管，否则要管的事情实在太多了，最终什么都没有管好。一般地，项目监控的重点是： 任务进度； 项目费用； 人员业绩； 软硬件资源； 项目风险；项目经理将监控的结果写在周期性的项目进展报告里面，供上级领导和项目成员们了解项目状况。3.6.2 任务进度监控 任务进度监控的要点是：（1）记录某任务的实际开始时间和实际结束时间；（2）在检查的那一天，判断该任务的状态是“提前、延迟还是正常”；（3）记录实际产生的工作成果； 项目经理使用合适的软件工具，很容易地绘制出“Gantt对比图”，如图3-2所示。对于那

23、些进度被延迟的任务，项目经理应当和责任人交流，分析原因。如果是原计划太乐观了，那么适当修改原计划；如果是人员工作不得力，那么要求责任人加班追赶进度。图3-2 Gantt 对比图（实际示例将从Future软件中截取）3.6.3 项目费用监控 费用监控的目的是将项目的实际花费控制在预算之内。项目经理首先要记录所有的开支项，如表3-5所示。如果公司已经使用比较好的财务软件，那么这些财务数据已经保存在数据库内。费用类别主要开支项、用途金额时间设备差旅表3-5 项目费用记录对于大部分软件项目而言，项目经理只需要懂得一点点财务知识就行了。对财务数据进行简单的处理，就能获得比较有用的监控信息：（1）绘制饼形

24、图，看看各个费用类别之间的比例是否合理，如图3-3所示；（2）绘制柱状对比图，看看每种费用类别是否超支，如图3-4所示。图3-3 饼形图（实际示例将从Future软件中截取）图3-4 柱状对比图（实际示例将从Future软件中截取）3.6.4 人员业绩记录 许多公司都在年终进行业绩考评，领导往往只记住下属的最后一个月表现，淡忘了他们在以前的功和过。所以传统的年终考核有很大的弊端。项目经理要在平时记录项目成员的业绩，否则在项目结束后就没有公正考核成员业绩的证据。可以用Word或者Excel制作表格，如表3-6所示。注意业绩表是个比较敏感的东西，项目经理要注意措词，避免挫伤那些业绩不佳的人员的自尊

25、心和积极性。日期人员业绩描述奖励措施2003-3-26伊拉克农民用步枪打下美军直升机奖励100公斤粮食表3-6 人员业绩记录3.6.5 软硬件资源监控 十几年前，计算机是非常昂贵的设备，人们把它当宝贝似的看管起来，现在很少有人再这样做了。这里所谓的资源监控是指对“关键资源”的监控，监控的目的就是确保关键资源安全有效，并且提高其利用率。软硬件资源监控表如表3-7所示。例如用作服务器的计算机是关键硬件资源，项目经理要清楚这台服务器能否有效地支持应用。如果服务器的速度和内存太低了，项目经理就要设法提高服务器的配置。反之如果应用是轻量级的，那么没有必要购买高档的服务器。例如用于配置管理的ClearCa

26、se是关键软件资源，ClearCase的每个License很贵。如果项目拥有的License不够用，那么需要扩充；如果License足够多，利用率不高，那么应该把License分给其它项目用。级别资源名称配置、用途、获取方式有效性、利用率关键PC 服务器Intel P2 CPU，256M内存CPU太低，内存太少关键ClearCase15个License每人一个License太浪费普通办公计算机15台恰好够用表3-7 软硬件资源监控表3.6.6 风险管理所有可能危害项目的因素都称为风险。被刻画为风险的事件最终可能发生也可能不发生。人们对待风险有两种态度。一种是被动态度，可比作“救火模式”。另一种

27、是主动态度，可比作“防火模式”。风险管理属于“防火模式”，目的是在风险产生危害之前识别它们，从而有计划地消除或削弱风险。为了便于量化管理，我们给风险定义3个参数： 风险严重性：指风险对项目造成的危害程度，例如可以划分为5个等级：5很严重，4比较严重，3中等，2比较低，1很低。 风险可能性：指风险发生的几率，可以用百分比表示。 风险系数：是风险严重性和风险可能性的乘积。简单的风险管理表格如表3-8所示。对风险管理更加深入的论述请参考CMMI3级软件过程改进方法与规范一书。风险编号严重性可能性风险系数风险描述解决措施结果RISK0015很严重40%2.0技术骨干不瞒现状想跳槽提高他的薪资跳槽了RI

28、SK0024比较严重60%2.4客户又要变更需求了和客户谈判稳住他客户让步了表3-8 风险管理表3.6.7 项目进展报告项目经理应当定期（例如每2周一次）撰写项目进展报告，通报给上级领导和所有项目成员。进展报告的格式可以自由制定（参见表3-9），关键是要总结出实质性的内容，让人们清楚地知道项目的真实状况，而不是记流水帐。许多人把项目进展报告写在email里，虽然起草和发送比较方便，但是容易丢失历史信息（如果email删除了报告也就丢失了）。最好是把项目进展报告保存在数据库里，人们可以使用浏览器来访问，那么任何人在任何时间都可以了解项目进展状况和历史信息。项目名称报告日期项目编号报告批次第N份项目经理项目所处阶段项目进展状况计划实际情况任务与进度工作成果费用人力资源软硬件资源工作汇报问题与对策表3-9 项目进展报告3.7 小结如果企业没有项目估计方面的历史数据，就不可能归纳出有效的数学模型，那么就采用简单直观的“分解累计”方法好了。不要企图寻找世界上最先进的数学模型来进行项目估计，那无疑于电脑算命。项目规划和项目监控是动态演进的过程域，如果项目经理不懂得规范化管理的话，那么极有可能陷入无穷多的琐碎事务之中。本章论述的方法规范比较简单，易于操作，适用于大部分中小型的软件项目。