项目规划与项目监控.docx
《项目规划与项目监控.docx》由会员分享，可在线阅读，更多相关《项目规划与项目监控.docx（18页珍藏版）》请在冰点文库上搜索。
项目规划与项目监控
TYYGROUPsystemofficeroom【TYYUA16H-TYY-TYYYUA8Q8-TYYUA162】
项目规划与项目监控
第3章项目规划与项目监控
项目规划（ProjectPlanning）的目的是为项目的开发和管理工作制定合理的行动纲领（即项目计划），使所有人员按照该计划有条不紊地开展工作。
为了避免词义混淆，这里把动词Planning译为规划，把名词Plan译为计划（或计划书）。
项目监控（ProjectMonitoringandControl）的目的是通过周期性地跟踪项目计划的各种参数如进度、工作量、费用、资源、工作成果、风险等等，不断地了解项目的进展情况，以便当项目实际进展状况显着偏离计划时能够及时采取纠正措施。
项目经理正式上任后最主要的管理工作就是项目规划和项目监控。
如果没有规划就不知道监控什么，反之如果只有规划而不去监控等于白规划。
可见项目规划和项目监控是相辅相成、动态演化的两个过程域。
最糟糕的下场是：
经费用光了，进度远远落后了，人员累死了，还不知道什么时候能熬出头。
本章探讨项目规划与项目监控的方法和规范，让广大项目经理都能学会。
项目规划的概念
为什么要进行项目规划？
我们生活在城市里，经常发现某些道路被反反复复地挖掘修理，给老百姓的生活添加了很多麻烦。
这种现象只有两种解释：
（1）市政管理者为了拉动GDP的增长，营造欣欣向荣的景象，就拿马路开刀；
（2）管理者根本没有进行市政规划，第一次挖马路铺设煤气管道，第二次挖马路铺设电缆，第三次挖马路铺设光缆，如此折腾简直劳民伤财。
软件项目规划的重点是对人员角色、任务进度、经费、设备资源、工作成果等等做出合适的安排，制定出一些计划（包括高层的和细节的），使大家按照计划行事，最终顺利地达到预定的目标。
如果不对项目进行规划的话，一群人天马行空、各干各的，项目进展不到一半就混乱不堪了。
谁在什么时候进行项目规划？
在立项管理过程域的项目筹备阶段（参见第二章），机构领导首先任命一位项目经理，之后机构领导协助项目经理筹备项目经费、人力资源、软件硬件资源等。
如果必要的资金和资源已经到位，那么项目经理和核心成员即可组成一个项目规划小组，开始进行项目规划。
有人疑问，在《立项建议书》中不是已经有了项目的开发计划了吗为什么还要进行规划呢
注意，《立项建议书》中的开发计划仅仅是一种设想而已，因为当时人们并不知道机构是否会采纳这个建议、也不知道领导支持的力度有多大。
假设《立项建议书》中的计划需要10名开发人员和一百万元经费，但是当立项之后机构只能给予5名开发人员和50万元经费，那么原计划必须做出重大调整。
项目规划产生的成果是什么？
主要是一些计划书（plan），可分两类：
一是全局的计划书（OverallPlan），这里称为《项目计划》；二是一些下属计划书（SubordinatePlan），例如配置管理计划、质量管理计划、阶段开发计划和测试计划等。
下属计划书是对《项目计划》的补充，其内容不可与《项目计划》冲突。
通常《项目计划》由项目经理负责制定，由机构领导审批。
而下属计划书一般由项目成员制定，由项目经理审批即可。
项目规划的流程如图3-1所示。
图3-1项目规划流程图
如何进行项目估计
在制定项目计划之前，理应采用恰当的方法对重要的数据进行估计，否则计划就乱写了。
一般地，项目估计的要素是软件规模、工作量和人力成本，如果这些要素估计得比较准确得话，那么后续制定的项目计划就比较合理。
对于一些外包项目而言，项目估计得到的数据是双方讨价还价的依据。
项目估计几乎不可能成为一门精确的科学，因为在项目刚开始时，人们对产品需求和技术的了解还比较肤浅，而项目实际能够拥有经费和资源很大程度上是靠项目经理争取来的，不确定因素比较多。
在这种情况下人们很难作出准确的估计。
但是大家都认同：
依据某种方法（规则）进行估计显然比瞎猜好得多。
常用的项目估计方法大体分为两类，第一类是数学模型，第二类是简单直观的“分解－累计”方法；
数学模型真的好用吗
采用数学模型这种方法是学术界热衷的，因为有数学公式的东西更显得有学术味道。
这类方法适合于非常成熟的软件机构，该机构积累了丰富的历史数据，以至于能够归纳出数学模型来指导新项目的规划。
典型的数学模型如
E=A+B×（ev）C
其中A,B,和C是由经验导出的常数，E是以“人月”为单位的工作量，ev是估算变量如代码行（LOC）或者功能点（FP）。
例如基于代码行的数学模型有：
Walston-Felix模型E=×（KLOC）
Bailey-Basili模型E=+×（KLOC）
Boehm简单模型E=×（KLOC）
基于功能点的数学模型有：
Albrecht模型E=+FP
Kemerer模型E=××10-8FP3
Maston模型E=+FP
通用性更强的是BarryBoehm研制的COCOMO模型（构造性成本模型），分为初级、中级、高级3种形式。
（参考[Pressman99,p83-p86]）
我从事软件开发十多年，从来没有采用数学模型进行项目估计，因为根本无法套用，所以我从来就不信这些公式。
我公司的一些员工参加了CMM培训课，CMM讲师照本宣科地推荐了COCOMO模型，学员们如获至宝。
有一天，某个同事打电话问我：
“用COCOMO模型估计工作量时，我们公司的常数是多少？
”
我说不知道，我从来就没有用过。
对方很吃惊地问：
“你不是专家吗，怎么连那么着名的COCOMO模型都不会用呢？
”
我哭笑不得，只好对他说：
“你顺便找些数据来计算，就当电脑算命好了。
如果你算对了，将来大家都请你来算。
”
简单直观的估计方法
我自己一直都采用简单直观的“分解－累计”方法来估计产品规模、工作量和人力资源成本。
产品规模估计方法如下：
（1）项目规划小组先分解产品的功能，制定“产品功能分解与规模估计表”（如表3-1所示）。
产品的模块以及模块的主要功能是比较容易确定的，因为这是项目规划小组必须知道的最起码的功能需求。
软件规模的度量单位主要有：
代码行、对象个数、页面数等等。
我通常用“对象个数”来度量。
模块名称
模块的主要功能
新开发的软件规模
（度量单位如对象个数）
复用的软件规模
（度量单位如对象个数）
模块A
模块B
汇总
表3-1产品功能分解与规模估计表
（2）规划小组各成员独立填写表3-1。
（3）汇总每个成员的表格，进行对比分析。
如果各人估计的差额小于20％，则取平均值。
如果差额大于20％，则转向第
（2）步，让各成员重新估计产品的规模，直到各人估计的差额小于20％为止。
第（3）步的目的是消除大的差异后取平均，总误差控制在20％以内。
如果所有的估计值同时偏大或者偏小，那么就将错就错了。
因为在项目刚开始的时候，谁也不知道估计准确不准确，只要大家观点相似就行了。
工作量估计方法如下：
（1）首先确定工作量的度量单位，可以是“人小时”、“人天”、“人月”或“人年”。
注意单位换算：
1人年＝12人月
1人月≈22人天
1人天＝8人小时
（2）估算开发工作量。
一般地可以把开发过程划分为需求开发、系统设计、实现、测试四个阶段，分别估计每个阶段的工作量，然后累计得出总的工作量，见表3-2。
人均生产率是指每个人每天完成的工作成果规模。
假如在设计阶段，每人每天可以设计2个对象，若软件总共有100个对象，那么设计阶段的工作量就是50人天。
依此类推。
（3）估算管理工作量。
除了开发之外，项目规划、项目监控、配置管理、质量管理等等也是很费时间的。
一般地，项目的80％以上的工作量用于开发，20％以下的工作量用于管理。
项目规划小组可以根据经验，给出一个比例系数，简便地估算管理的工作量。
工作量的度量单位
1人年＝12人月，1人月≈22人天，1人天＝8人小时
开发工作量估算公式
项目开发工作量≈新开发的软件规模/人均生产率
开发阶段
人均生产率
软件规模
工作量
需求开发
系统设计
实现
测试
…
开发工作量汇总
管理工作量估算公式
项目管理工作量≈开发工作量*比例系数
项目管理的主要事务
项目规划、项目监控、需求管理、配置管理、质量管理…
比例系数
例如20％
管理工作量汇总
表3-2工作量估计表
如果已经估算出项目的工作量，那么估算人力资源成本就比较容易。
每人每年的成本显然高于年薪，因为每个人除了拿工资外，日常还要消耗公司资源，公司要额外支付各种保险金等。
一般地，对于软件企业，每人每年的成本大约是其年薪的至倍（姑且称之为成本系数）。
如果成本系数太高的话，表示该公司要么福利极好要么铺张浪费；反之如果系数太低的话（最低为），表示该公司福利极低。
举个简单的案例：
如果乙方想承包甲方的项目，假设乙方估计该项目的工作量为10人年，乙方人员的平均年薪为8万元，成本系数为。
请问乙方的人力资源报价如何（
设备成本、差旅费等等另外计算）
乙方的人力资源报价应该是10×8×＝160万元吗？
不对，如果这样报价的话，乙方的老板只好喝西北风了。
报价必须考虑利润，假设双方可以接受的利润率为20％，那么乙方报价应该是160×＝192万元。
乙方应该把报价的详细清单（不是最终结果）给甲方看，表明这个报价是合理的，而不是狮子开大口。
甲方要检查这个报价清单，尽可能把里头的“水分”挤出来。
双方必然有个讨价还价的过程，如果想说服对方，一定要拿出经得起推敲的数据来，以理服人。
否则双方尽是胡侃，最后在酒桌上解决，这是比较低俗的商业谈判（也算得上是国粹了），不值得大家效仿。
本节介绍的项目估计方法既可以用在立项建议过程域中，也可以用在项目规划过程域中。
在某种情况下，任何的项目估计方法都没有实际价值，那就是：
（1）项目的人员已经被上级领导限定死了，再多的活也是那几个人干；
（2）除了办公计算机和工资外，这个项目没有其它经费，项目经理只有干活的权利没有用钱的权利；
（3）项目的结束日期早就被领导和客户指定了，不管合理不合理，反正时间一到就要交付软件。
如果人员、资金、时间都已经被毫无道理地指定了，你进行科学地估计还有啥用？
这样的项目在国内并不少见，如果你碰上了，那么就自认倒霉吧。
制定项目计划
在进行项目估计之后，项目规划小组即可进一步制定《项目计划》，模板见表3-3。
《项目计划》的重点内容是：
目标与范围；
过程定义；
人力资源计划；
软硬件资源计划；
财务计划；
任务进度计划；
下属计划。
项目计划
0.文档介绍
文档目的
文档范围
读者对象
参考文档
术语与缩写解释
1.项目介绍
项目范围
提示：
（1）用简练的语言说明本项目“是什么”，“什么用途”。
（2）说明本产品“适用的领域”和“不适用的领域”；（3）说明本产品“应当包含的内容”和“不包含的内容”。
项目的目标
提示：
给出清晰的、可以验证的目标。
2.项目过程定义
过程模型
提示：
描述、绘制本项目的过程模型,可以裁剪SPP模型。
采用的方法与工具
提示：
说明过程模型中将采用的方法与工具。
例如采用RationalRose进行面向对象分析与设计，采用VisualSourceSafe进行配置管理，采用MicrosoftOffice2000制作文档。
3.人力资源计划
人员
角色
职责
项目经理
质量管理员
…
4.软硬件资源计划
软件、硬件名称
级别
主要配置
获取方式
用途
关键
普通
5.财务计划
费用类别
开支项、用途
金额
时间
6.任务进度计划
提示：
制定详细的任务表，并绘制Gantt图（插入此处或作为附件）。
任务名称
工作人员
工作时间
工作成果
7.下属计划
提示：
下属计划（SubordinatePlan）是对《项目计划》的补充。
《项目计划》需要机构领导的审批，但下属计划一般只需要项目经理（或其它负责人）审批即可。
计划名称
负责人
预计产生时间
配置管理计划
质量管理计划
阶段开发计划
测试计划
…
表3-3《项目计划》的参考模板
项目计划审批
项目计划的审批流程非常简单：
第一步，项目经理把《项目计划》递交给机构的领导。
第二步，机构领导根据“检查表”（见表3-4）认真审阅该《项目计划》，如果没有异议，那么就签字批准；如果有不同意之处，就和项目经理沟通，并请项目经理及时修改。
第三步，机构领导签字批准之后，该《项目计划》就成为“正式文件”，所有的项目成员都必须按照该计划执行。
如果以后要修改《项目计划》的话，必须准照变更控制流程来修改。
如果是合同项目，那么要请客户和机构领导共同审批文件。
项目计划检查表
结论
项目的目标明确吗可以验证吗
项目的范围清楚吗？
对项目的规模和复杂性的估计可信吗？
对项目的工作量估计可信吗
对项目的成本估计可信吗？
项目的过程控制方案合理吗？
项目所有角色的职责清楚吗人员安排合理吗
项目所需的软件硬件资源合理吗
项目财务计划合理吗？
任务分配合理吗进度合理吗
……
审批结论
[]批准该计划
[]不批准
意见
机构领导签字
表3-4项目计划检查表
需要指出的是，如果机构领导不认真审阅《项目计划》而例行公事地签字批准的话，那么项目计划的审批流程一点意义都没有。
我见过不少雷同的场景，秘书把一叠文件摆在领导的桌面上，领导上班时，一边无聊地翻阅文件一边签字，体会着当领导的快乐与烦恼。
软件机构的领导通常都是稿软件出身的，按理说他比普通项目经理更加清楚如何进行项目规划，所以如果领导不用他的智慧审批《项目计划》的话，那么领导就是个摆设，对规范化管理没有促进作用。
项目计划变更控制
在人们刚开始制定《项目计划》的时候，由于对项目本身缺乏深入的理解，第一个版本的《项目计划》有可能比较粗略甚至不切实际。
在项目执行过程中如果发现《项目计划》与实际情况有比较大的偏差，应当及时更新《项目计划》。
所以《项目计划》不是一成不变的，它将随着项目的进展而逐步完善。
项目计划变更控制的目的是：
（1）修改原《项目计划》中不合理的内容，产生新的《项目计划》；
（2）按照指定的流程修改《项目计划》，防止发生混乱。
一般地，若下列情况发生，应当变更《项目计划》：
进度偏差超过了容许的误差，如20％；
费用偏差超过了容许的误差，如20％；
项目过程模型发生了显着的变化；
用户需求发生了重大的变化；
发生了不可抗拒的变化，例如公司裁员、机构调整、产品发展战略调整等。
项目计划变更控制的流程如下：
第一步，项目经理向机构领导提交变更申请书（格式自由），该申请书应当说明：
变更原因；变更的内容；此变更对项目造成的影响。
第二步，机构领导审批该申请书。
如果领导不同意变更，那么项目按照原计划执行；如果同意变更，那么转向第三步。
第三步，项目经理制定新的《项目计划》，并提交给机构领导。
第四步，机构领导审批新的《项目计划》。
为了提高效率，第一步和第三步可以合并一起，由项目经理执行。
同理第二步和第四步也可以合并一起，由机构领导执行。
如果是合同项目，那么要请客户和机构领导共同审批文件。
如何有效地监控项目
为什么要进行项目监控
制定项目计划之后，为什么要进行项目监控？
因为执行计划的是人而不是机器，每个人做事都可能与计划有偏差，何况一群人呢。
再者，环境也会发生变化。
项目监控至少有以下几个好处：
（1）避免原本合理的计划在实施过程时落空；
（2）避免“执迷不悟”地按照不合理的计划行事；
（3）将监控过程产生的数据保存起来，为机构持续的过程改进提供有价值的数据。
项目监控的基本原理是：
将项目实际情况与项目计划进行对比，如果发现某些因素的偏差非常大（超过了容许的误差），那么及时分析原因，给出纠正措施。
项目经理不要企图对所有的项目事务进行监管，否则要管的事情实在太多了，最终什么都没有管好。
一般地，项目监控的重点是：
任务进度；
项目费用；
人员业绩；
软硬件资源；
项目风险；
项目经理将监控的结果写在周期性的项目进展报告里面，供上级领导和项目成员们了解项目状况。
任务进度监控
任务进度监控的要点是：
（1）记录某任务的实际开始时间和实际结束时间；
（2）在检查的那一天，判断该任务的状态是“提前、延迟还是正常”；
（3）记录实际产生的工作成果；
项目经理使用合适的软件工具，很容易地绘制出“Gantt对比图”，如图3-2所示。
对于那些进度被延迟的任务，项目经理应当和责任人交流，分析原因。
如果是原计划太乐观了，那么适当修改原计划；如果是人员工作不得力，那么要求责任人加班追赶进度。
图3-2Gantt对比图（实际示例将从Future软件中截取）
项目费用监控
费用监控的目的是将项目的实际花费控制在预算之内。
项目经理首先要记录所有的开支项，如表3-5所示。
如果公司已经使用比较好的财务软件，那么这些财务数据已经保存在数据库内。
费用类别
主要开支项、用途
金额
时间
设备
差旅
…
表3-5项目费用记录
对于大部分软件项目而言，项目经理只需要懂得一点点财务知识就行了。
对财务数据进行简单的处理，就能获得比较有用的监控信息：
（1）绘制饼形图，看看各个费用类别之间的比例是否合理，如图3-3所示；
（2）绘制柱状对比图，看看每种费用类别是否超支，如图3-4所示。
图3-3饼形图（实际示例将从Future软件中截取）
图3-4柱状对比图（实际示例将从Future软件中截取）
人员业绩记录
许多公司都在年终进行业绩考评，领导往往只记住下属的最后一个月表现，淡忘了他们在以前的功和过。
所以传统的年终考核有很大的弊端。
项目经理要在平时记录项目成员的业绩，否则在项目结束后就没有公正考核成员业绩的证据。
可以用Word或者Excel制作表格，如表3-6所示。
注意业绩表是个比较敏感的东西，项目经理要注意措词，避免挫伤那些业绩不佳的人员的自尊心和积极性。
日期
人员
业绩描述
奖励措施
2003-3-26
伊拉克农民
用步枪打下美军直升机
奖励100公斤粮食
…
表3-6人员业绩记录
软硬件资源监控
十几年前，计算机是非常昂贵的设备，人们把它当宝贝似的看管起来，现在很少有人再这样做了。
这里所谓的资源监控是指对“关键资源”的监控，监控的目的就是确保关键资源安全有效，并且提高其利用率。
软硬件资源监控表如表3-7所示。
例如用作服务器的计算机是关键硬件资源，项目经理要清楚这台服务器能否有效地支持应用。
如果服务器的速度和内存太低了，项目经理就要设法提高服务器的配置。
反之如果应用是轻量级的，那么没有必要购买高档的服务器。
例如用于配置管理的ClearCase是关键软件资源，ClearCase的每个License很贵。
如果项目拥有的License不够用，那么需要扩充；如果License足够多，利用率不高，那么应该把License分给其它项目用。
级别
资源名称
配置、用途、获取方式
有效性、利用率
关键
PC服务器
IntelP2CPU，256M内存
CPU太低，内存太少
关键
ClearCase
15个License
每人一个License太浪费
普通
办公计算机
15台
恰好够用
表3-7软硬件资源监控表
风险管理
所有可能危害项目的因素都称为风险。
被刻画为风险的事件最终可能发生也可能不发生。
人们对待风险有两种态度。
一种是被动态度，可比作“救火模式”。
另一种是主动态度，可比作“防火模式”。
风险管理属于“防火模式”，目的是在风险产生危害之前识别它们，从而有计划地消除或削弱风险。
为了便于量化管理，我们给风险定义3个参数：
风险严重性：
指风险对项目造成的危害程度，例如可以划分为5个等级：
5－很严重，4－比较严重，3－中等，2－比较低，1－很低。
风险可能性：
指风险发生的几率，可以用百分比表示。
风险系数：
是风险严重性和风险可能性的乘积。
简单的风险管理表格如表3-8所示。
对风险管理更加深入的论述请参考《CMMI3级软件过程改进方法与规范》一书。
风险编号
严重性
可能性
风险系数
风险描述
解决措施
结果
RISK001
5－很严重
40%
技术骨干不瞒现状想跳槽
提高他的薪资
跳槽了
RISK002
4－比较严重
60%
客户又要变更需求了
和客户谈判稳住他
客户让步了
…
表3-8风险管理表
项目进展报告
项目经理应当定期（例如每2周一次）撰写项目进展报告，通报给上级领导和所有项目成员。
进展报告的格式可以自由制定（参见表3-9），关键是要总结出实质性的内容，让人们清楚地知道项目的真实状况，而不是记流水帐。
许多人把项目进展报告写在email里，虽然起草和发送比较方便，但是容易丢失历史信息（如果email删除了报告也就丢失了）。
最好是把项目进展报告保存在数据库里，人们可以使用浏览器来访问，那么任何人在任何时间都可以了解项目进展状况和历史信息。
项目名称
报告日期
项目编号
报告批次
第N份
项目经理
项目所处阶段
项目进展状况
计划
实际情况
任务与进度
工作成果
费用
人力资源
软硬件资源
工作汇报
问题与对策
表3-9项目进展报告
小结
如果企业没有项目估计方面的历史数据，就不可能归纳出有效的数学模型，那么就采用简单直观的“分解－累计”方法好了。
不要企图寻找世界上最先进的数学模型来进行项目估计，那无疑于电脑算命。
项目规划和项目监控是动态演进的过程域，如果项目经理不懂得规范化管理的话，那么极有可能陷入无穷多的琐碎事务之中。
本章论述的方法规范比较简单，易于操作，适用于大部分中小型的软件项目。
升级会员 