项目绩效目标制订与如何度量项目的真实绩效？ 

（一）项目绩效评价
项目绩效评价是指对项目决策、准备、实施、竣工和运营过程中某一阶段或全过程进行评价的活动。项目绩效评价应符合国家法律、法规及有关部门制定的强制性标准；遵循独立、客观、科学、公正的原则；建立畅通、快捷的信息管理和反馈机制。

项目绩效目标怎么写？

项目绩效目标一般包括长期目标和年度目标。
长期目标：概括描述项目整个计划期内的总体产出和效果。长期绩效指标是对项目长期绩效目标的细化和量化
年度目标：概括描述项目在本年度所计划达到的产出和效果。年度绩效指标是对项目年度绩效目标的细化和量化。
长期绩效指标是对项目长期绩效目标的细化和量化，一般包括：产出指标和效益指标。
产出指标：反映项目单位根据既定目标计划完成的产品和服务情况。可进一步细分为：数量指标，反映项目单位计划完成的产品或服务数量；质量指标，反映项目单位计划提供产品或服务达到的标准、水平和效果；时效指标，反映项目单位计划提供产品或服务的及时程度和效率情况；成本指标，反映项目单位计划提供产品或服务所需成本，分单位成本和总成本等。
效益指标：反映与既定绩效目标相关的、项目支出预期结果的实现程度和影响，包括经济效益指标、社会效益指标、生态效益指标、可持续影响指标及社会公众或服务对象满意度指标等。


（二）软件项目团队的绩效量化


本来是想研究下这个过程的原理之类的内容，后来被其中的一些度量指标吸引了。

合上这本书，我觉得对于我来说，收获最大的就是了解到原来除了我们耳熟能详的缺陷率，Reopen率等等外，还有那么多的可以使用的度量指标。

在讲这些指标之前，我想先说一下《团队软件过程》到底介绍了一种什么过程。

TSPi

为研究生或高年级本科生的团队软件工程课程而设计的框架。
指导学生一步步的完成团队软件项目课程，并教会你如何在团队协作环境中应用成熟的软件工程和软件过程。
我不禁有些感慨，现在的学校都已经开始做这种实操的练习了。

其实这样挺好的，让学生亲身经历整个项目过程以及各种角色，会有更多的体会。

研究了下TSPi是TSP的简化版本，专门为了培训和软件工程而定制的。

麻雀虽小，五脏俱全。

TSPi在过程中通过周期性的迭代的方式开展工作，每个周期包含完整的计划、设计、开发、测试、总结。

但是因为选择的策略不同，可以是在瀑布的大过程中嵌套小周期迭代，也可以纯迭代。

我觉得这也是TSPi与敏捷过程的一个不同之处。

另外一个不同之处在于，TSPi很强调度量和评估。

不仅要在每个周期进行度量和评估，还要对包括角色、质量、规模等等方面进行评估。

所以在TSPi中给了很多的量表，很有CMMI的意思。

书中提到了很多度量的指标，我这里摘取其中几个我觉得比较有意思，也比较实用的分享给大家。

概要比率

这个指标包含了三个子指标，主要用于度量团队的贡献情况。

LOC/小时：度量了团队的总体生效率

每小时写多少行代码，这个指标非常常见。

复用百分比：当前产品中复用以前产品的LOC比例

在TSPi中很强调代码复用，甚至提到“在设计初期就对复用部分进行设计”。

复用率高，表示被复用的代码的质量等各方面的绩效不错，也间接的说明了在这个周期内的产出质量有一定的保证。

新增可复用百分比：新增的代码中可以作为未来周期及项目的复用代码的比例

我们不仅要在开发的时候尽量复用之前稳定的代码，还需要创造一些可以被复用的代码。

这些代码不仅在本项目中可以复用，还可以被复用到其他项目中去。

缺陷数/KLOC

千行代码缺陷数，这是一个重要的质量指标。

这个指标没什么好说的，主要是作者在这个指标后面的一句话，引起了我的思考

如果单元测试有很多缺陷，单元测试后遗留的缺陷也会很多。

也就是说，如果单元测试发现很多的缺陷，那就意味着有点先天不足的意思。

就算后期再怎么修补，也无法摆脱先天不足的劣势。

而在每个周期里面对这个指标进行评估，就大致可以知道在后面的阶段中的质量情况。

如果构建和集成测试的缺陷数/KLOC<0.5，系统测试的缺陷数/KLOC<0.2，那么一般不会有用户使用缺陷。

一个周期内的阶段时间

TSPi强调在一个周期内要把所有任务重复一遍，它也给出了各个阶段任务的大致时间比例，可以作为参考。

如果评审时间达标，其实会对质量有一点的改善作用。

即会避免在单元测试的时候发现过多的缺陷，进而避免先天不足的情况发生。

详细设计时间>编码时间
详细设计评审时间>详细设计时间50%
需求评审>需求分析时间25%
规模度量

对于项目规模的度量，我们一般会使用模块、LOC、敏捷中的点数进行度量。
而作者提出了一种度量方式，挺有意思的：需求规格说明书SRS，PRD。

通过文本页数，编号段落或者Shall语句进行规模度量。
我觉得这个指标对于BA和需求的小伙伴来说要求比较高。
因为毕竟现在80%以上的SRS等文档并没有进行规范化、格式化。

编写的粒度、范围、结构等等都没有进行规范化。

比如同样的一个功能，我写的粗了就只有2页，写的细了可能会有8页。
再比如，我们在写需求的时候并没有建立结构需求语句。
所谓结构需求语句，耳熟能详的就是敏捷里面的AS... I want to... so that...
而这边并不是写一句话的user story那么简单。

为了度量规模，需要写的是更详细的规格。
比如，Admin shall add new users by import excel.
统计整个SRS中出现了多少shall语句，就可以度量规模。
但是，前提是，你的语句写的足够规范。

如果我一时脑抽，写了个 want, need, should, will, can, is able to...那么度量的结果肯定不准了。

写在最后

前些天还和群里的小伙伴讨论软件团队的绩效评估问题。

其实我觉得《团队软件过程》中有一句话说的很在理：

团队度量不应该以是否实现了目标为标准，而应该以设定目标的意愿以及为此所做出的努力程度来评价团队。

小婧是一名行走在实践路上的资深业务分析师。



（三）如何度量项目的真实绩效？ 

挣值管理是一种把范围、进度和成本绩效整合起来考察的方法，就是要在既定的范围之下来追求进度和成本绩效的综合最优。它可以避免单独测量进度或成本绩效的弊端。

在项目管理中，没有任何一种技术可以像挣值方法这样，提供如此出色的成本测量和估算，并能够测量进度和范围。

01 进度滞后，成本超支
某项目的状态如图1，对于给定绩效审查日期，项目预计要完成50000美元价值的工作（PV），在50美元/小时的完全劳动力费率下，相当于1000小时的工作。这里完全劳动力费率是指直接支付给工作人员的报酬加管理费，是项目工作的实际成本。

经审查，实际完成的工作量（EV）只是应完成工作量的80%，即40000美元；而实际成本（AC）为60000美元。
如何度量项目的真实绩效？ 

图1 进度滞后、成本超支的项目
该项目已完成工作的实际成本（AC）为60000美元，这可能是因为工作人员以50美元/小时的完全劳动力费率做了1200小时，或者以60美元/小时的完全劳动力费率做了1000小时。其实际偏差是一种综合性偏差，但不论以上哪种情况发生，都意味着实际支付的成本超过了原预算费用。

1.审查项目状况
SV=EV-PV=-10000美元，CV=EV-AC=-20000美元。即项目进度滞后、成本超支。
将PV曲线和40000美元的交叉点画一条垂直线到时间轴，可以得到项目的工期延误时间。
将成本偏差和进度偏差对比发现，在绩效审查时间点，项目团队用60000美元的实际成本完成了价值40000美元的实际工作，这-20000美元的偏差，一方面是10000美元的预算（PV）超支，另外10000美元是进度滞后造成的。
对于项目而言，项目进度落后、成本超支，这是非常糟糕的情况。进度落后或者成本超支就已经够糟的了，现在这两者同时不幸地发生了。

2.是什么引起的偏差?
一般而言，我们并不能十分确定地知道确切原因，但是最可能的原因有以下几点：
(1)估算错误；

(2)实际工作较预期困难得多；

(3)出现了一些不可预见的问题，使得工作需要更长时间、更多成本；
(4)所使用的资源（如人员）缺乏效率。

3.如何应对?
进度落后、成本超支即已发生，该如何应对呢？见图2，如果项目按照现在的这种趋势发展下去，将会导致一定程度的项目延期和成本超支。


如何度量项目的真实绩效？


图2 进度滞后、成本超支项目的应对和预测

现在有４种可能性：

(1)如果项目延期是不可接受的，可以考虑缩小项目范围（降低项目质量是不可接受的，这也是国内项目常见的问题），按期完成，即使超支部分费用。如果该解决方案被所有利益相关方接受，可以继续执行项目并缩小项目范围完成。

(2)如果项目超支是不可接受的，如按照现在的绩效下去只能缩小项目范围达成人们最低程度的满意，这可能是降低项目等级，当然必须要被所有人接受并不得降低项目质量。

(3)如果项目既不能推迟完工，也不得缩小项目范围，就只有加快工作进度，使得EV曲线快速上升，以便在要求的日期到达完成点。这会产生赶工成本，导致项目完工成本上升。

(4)也许有人会问有没有既不增加成本又不延长完工时间的办法？回答是：项目进行到15%后，滞后或者超支，项目的完工情况一般也将滞后或超支——一旦发生成本超支，就不可能再恢复正常！美国国防部的700多个大型项目的数据证实这一点。人们通常对较远的事情不会做那么多的准备工作；项目后期的计划通常比前期更模糊，更容易产生漏洞，这样项目后期出现成本超支的可能性也就更大。

02 进度超前，成本符合
如图3，对于给定绩效审查日期，实际完成的工作量（EV）为60000美元，而实际成本（AC）为60000美元，预算的计划成本为（PV）50000美元。

如何度量项目的真实绩效？

图3进度超前、成本符合的项目
1.审查项目状况
SV=EV-PV=10000美元，CV=EV-AC=0美元。
对于项目而言，项目进度提前、成本符合。

2.是什么引起的偏差?
一般而言，最可能的原因是：投入了更多的人力，但劳动费率不变。现在问题是，项目经理哪里来的这么多资源？在资源共享环境下，有两种可能性：

其他项目遇到了麻烦，给了项目多余的人；

项目经理把资源抢到了项目中来。比如，建筑项目上有这种情况发生：进度计划中已经考虑了天气对进度的延误，如果一直是好天气，人员就可以在原预计不能工作的时间内继续工作，而劳动费率不变。

3.如何应对？
也许有人会说：项目进度提前、成本符合，情况很好，所以不应采取任何行动。我们要说的是，也许真的应该让项目慢下来。

理由是，进度提前制造出来的某样可交付成果如果不能及时移交用户，很可能就需要支付储存费用；另一方面，项目提前完成可能会导致项目人员届时无事可做，可能造成不可避免的后续工作效率低下。

另外一个不得不考虑的原因是现金流。项目进度超前，资金能否以相应的速度注入是一个问题，如不能就必须将项目减速。对于大型项目这是一个必须考虑的问题。

03 进度滞后，成本符合

如图4，对于给定绩效审查日期，实际完成的工作量（EV）为40000美元，而实际成本（AC）为40000美元，预算的计划成本为（PV）50000美元。
如何度量项目的真实绩效？

图4进度滞后、成本符合的项目
1.  审查项目状况
SV=EV-PV=-10000美元，CV=EV-AC=0美元。
对于项目而言，项目进度滞后、成本符合。
2.是什么引起的偏差?
一般而言，最可能的原因是：劳动力预算费率正确、人员短缺导致完工工作量不足（也许这正是另一个项目超前的受害者）。

3.  如何应对？
由于项目进度滞后是由于劳动力短缺造成的，这属于矩阵组织的常见情形，资源短缺也是矩阵组织的最重要冲突。作为项目经理也许需要采用招募等方法进行进度压缩。

04 进度超前，成本节省

如图5，对于给定绩效审查日期，实际完成的工作量（EV）为60000美元，而实际成本（AC）为40000美元，预算的计划成本为（PV）50000美元。

1.  审查项目状况
SV=EV-PV=10000美元，CV=EV-AC=20000美元。
对于项目而言，项目进度提前、成本节省。

如何度量项目的真实绩效？

图5进度超前、成本节省的项目
2.是什么引起的偏差?
进度提前、成本节省，乍看起来，项目进展太好了。但我们还是要问是什么导致了偏差。对于这种情况，有如下可能：

实际的劳动费率比预期的要低得多，或者人员效率比预期要高很多；
项目遇到的幸运点，原先预计费很大劲才能解决的困难，实际上很容易地解决了；
项目经理为提高安全，夸大了困难，注入水分，粗暴地对待估算工作。


3.如何应对？
对于第一种原因，这种偏差存在的时间不会太久，也许你的效率很高的团队成员会选择逃离组织，换言之这种情况的概率十分低。

对于第二种原因，好像是卫星排成了一条线——中了“六合彩”大奖、无数年才能发生一次的事情被你碰到了，你相信自己会有这么幸运？

对于第三种原因，项目经理增加了估计的安全性。对项目而言进度提前、成本节省，这是可以接受的，毕竟按照这种情形下去项目将比时间提前并成本节省地完成。
但是，情况是否如此，真的非常难说。

首先，项目经理真的会把节省的资金归还公司吗？现实中，他会想办法花掉多余的资金，不论是为项目镀金还是举办一个大型聚会！因为他知道，如果真的归还公司，下一个项目的预算将被削减。

其次，如果项目经理如实地归还公司，这种情况好吗？答案仍然是否定的，因为组织已经失去了用这些资金创造更多利润的机会（机会成本真的不幸地发生了），事实上我们讨论的情景一正是如此。

4.  对进度超前、成本节省项目的进一步讨论
如果一个进度滞后、成本超支的项目A和一个进度超前、成本节省的项目B在组织内的两个项目同时发生了，而这两个项目恰是同一个项目经理负责。这位项目经理把项目A短缺的资金分摊到项目B上，这样一来，两个项目都能按目标完成。
也许，每个人都认为这是一个十分高明的项目管理方法！

其实，这就是所谓的“交叉负担”。如果你为美国军方做项目，他们一旦发现将送你进牢房！因为你对实际已完成的工作撒了谎，你的项目A的绩效报告上的工作量大于实际工作量，而项目B的绩效报告上的工作量小于实际工作量——这导致两个项目的绩效报告均不准确。

交叉负担等于把两个项目的数据弄乱，项目结束时的数据失去了参考意义，对未来项目失去了帮助。更糟糕的是，如果使用这些信息进行决策将导致错误。
处理这种情况的恰当方式是，进行正大光明的资金转移，遵照正式的变更控制程序处理。
虽然，尚没有具体数据，但国内“交叉负担”现象较为普遍地存在。这也是档案室里的数据常被人诟病的原因之一吧。