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