软件项目绩效管理，让项目团队绩效量化可视化

（一）项目绩效管理：软件项目团队的绩效量化

最近看了一本书《团队软件过程》。
本来是想研究下这个过程的原理之类的内容，后来被其中的一些度量指标吸引了。
合上这本书，我觉得对于我来说，收获最大的就是了解到原来除了我们耳熟能详的缺陷率，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...那么度量的结果肯定不准了。

写在最后
前些天还和群里的小伙伴讨论软件团队的绩效评估问题。
其实我觉得《团队软件过程》中有一句话说的很在理：
团队度量不应该以是否实现了目标为标准，而应该以设定目标的意愿以及为此所做出的努力程度来评价团队。
小婧是一名行走在实践路上的资深业务分析师。


（二）项目绩效考核

随着公司CMMI3级认证的落成，公司已经起步朝着服务外包的方向发展，相应的一些绩效制度也势在必做:下午参加EPG例会其中除了一些流程和项目文档模块的完善和更改之外，就是关于项目方面的绩效如何做。总监提议项目毛利的10%做为提成，再大家讨论后落定对于一个软件项目最大的成本就是人力成本，故他同意项目提成提高到为项目毛利的15%。而其中项目经理领取其中的45%、UI5%。剩下的50%分给测试人员和开发人员。其中出现分歧的是总结建议用千行bug率来考核开发人员和测试人员的绩效。

首先是规定一个达到千行bug率的标准做为测试人员和开发的均值，测试人员测出的bug率在这个均值之上则惩罚开发人员、奖励测试人员的绩效，相反则惩罚测试人员、奖励开发人员，而如果客户发现问题，则需测试人员负责，即扣出测试人员的奖励。我做为测试人员深刻知道，软件的质量不是考测试人员一个人或一个测试团队单方面来维护，质量贯穿于整个开发过程的所有人员，总监的着这种必须测试人员对软件质量负责的态度，我必须驳回，大家共同的责任我一个小女子无法承担也不可能承担，而且这样的话只会激发测试人员和开发人员的矛盾，但我深知在一个项目中测试人员需要开发人员的密切配合的，本来平时的工作就不太好做，加上这种绩效的话，估计我以后的测试工作要想很顺利简直太难了。在其他成员人的帮助和我自己的辩护下，最终确定客户发现的bug又整个项目来分担，即在项目毛利的15%中按点下调，而测试人员和开发人员的话是按剩余的50%平分，对此，我不是很满意，对于小一点的项目人少没有问题，而对于大一点的项目，开发人员和测试人员的比例相差太大了，貌似总监觉得测试人员的地位应该低于开发人员，貌似我觉得测试人员对于整个项目的掌控和质量的跟踪很突出。


（三）软件开发人员怎么做绩效考评

第一：考核指标的设计必须关注到考核什么（指标来源）？、怎么考（指标的描述或计算公司）？、目标是什么？考核结果谁来确认（考核的评分和评估）？、如何算分（该项指标的最终完成情况，如何核算分数）？以上关键部门都设计和约定好了，然后在把这些指标合并到一张表里面，由考核者确认权重，构成一个考核周期的“考核任务书”，最终考核者与被考核者沟通确认后，签字执行，以上部分就是绩效计划的制定；
第二：绩效执行期间，需要有老板或者技术带头人对核心的开发指标进行监控，比如双鱼熊熊讲到一个“错误率”，如果错误率在运行期间非常高，那么我们的及时带头人就需要对此进行分析，然后给出解决方案，以挑战该项工作朝着目标期望迈进；
第三：到了考核期末，比如如果是月度考核的话，下月初5号由我们人力部的同事去获取每项指标的考核数据然后核算得分，在这个过程中可能不同指标可能需要不同的人员进行评分，具体这个过程中的责任可以参考我在中人论坛中发的“绩效操作流程中责任方的界定”；
第四：考核者（开发人员的直接上级）针对开发人员的每项指标的完成情况以及评分者针对指标的评估（存在的问题），首先对开发人员进行正式的面谈，针对上一绩效周期中存在的问题分析原因，提出下一步改善建议（包括员工注意事项、员工需要培训的计划、甚至是员工是否需要换岗等），针对开发人员普遍存在的问题，考核者与所有开发人员需要召开绩效考核分析，探讨解决思路；
第五：根据每位开发人员的绩效得分，核算绩效工资；具体方案较多；