度量面面观 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

 

在中国，要在项目里建立一个度量体系非常难。我观察到的情况是大部分项目都没有度量的概念。但是我们大部分的项目，尤其是关键的项目，总能完成。从此，我们可以说项目的完成不需要度量。另一方面，我们常常都会有一些定性的、有关项目绩效的概念。我们会认为这个项目做得好，哪个没有那么好。有一次，我跟一位所长谈话，他们的研究所，是过程做得非常表面的那种，他说，他们有些项目是世界一流的。我就问他，“你是如何判断项目是世界一流的？”他的回答都是一些泛泛之词。我就希望他可以说出一些明确的指标。但是他就是不能。

 

其实是否世界一流可以从多个方面衡量：比如生产力、目标的满足频率、技术含量等等。这些都可以用数据表达的。不用数据，没有量化的准则，很多时候，我们心中的印象严重偏离了现实都不知道。

 

所以说，度量的重要性和意义，不一定在于非度量不能完成任务，而是没有度量，我们就不可能正确地了解实际情况。就不能有效地提高与改进我们的项目效能。所以度量的使用在成熟的团队里是非常常见与普遍的。否则他们是很难发展成为成熟高效的团队的。

 

那么，为什么建立度量体系这么难呢？这里零散地罗列一些原因，希望有利于大家克服这些困难。

 

统计意识

 

建立度量体系需要有统计意识。因为不习惯度量所要求的统计概念，往往就会不合理地使用个别的数据。其实过程是在很多很多的因素和条件地下开展的，所以同等的技能，在不同的实施也会有不同的绩效。所以一个过程，实施了多次之后，他们的数据的整体，包括中间趋势，偏差幅度，才能有效地代表这个过程的效能。这个就是“过程的声音”，它代表了我们组织里的过程效能。

 

就是因为这个原因，我们不能使用个别的绩效来正确衡量个别的过程的绩效，更加不能拿过程数据来衡量个人，因为使用过程数据来衡量个人的话，就一定很难建立可靠的度量体系。因为没有人会提供对自己不利的数据和信息的。因为要得到有利的数据，要么数据就不真实，要么过程是被歪曲（做一些对满足目标无关的事情）的。

 

不知道要度量那些因素。

 

一般项目在开始使用度量时就要定义很多很多的度量要求，希望可以避免遗漏。这是费时失事的，因为数据的收集和管理，成本是不简单的。我们需要明确度量那些因素，不一定需要一大堆，但是需要度量能解决问题的因素。这个需要由领导开始。比如，领导希望知道自己的团队的响应性、生产力（效率）、以及工作质量么？这是理所当然的。可能它们之间有一定的比重和优先级，但一定不能离开这些。那么，领导就应该关注制定这三个因素的度量定义，并要求经常定期的收集与汇报，进行分析以利了解团队的效能。

 

平衡监控

 

很多时候，我们只关注了部分的度量。其实每一个过程或是组织单元，都有一组意义上相对独立，但实际上相互影响的因素。比如项目的效能，就有“周期、效率、产品质量”三个因素。这三个因素其实是最小的一组“直交”（orthogonal ）因素。如果我们只关注这个基本的因素集里面的个别因素的话，比如只关注周期，项目的效率和产品质量都会受影响。所以合理的度量使用，应该同时监控所有的基本因素（不要担心，也不会有太多），否则我们就没有平衡这些因素的能力。当然，项目的目标，可以对这些因素有不同的重视程度和优先级。

 

准确与一致的比较

 

一个经常听到的、让度量体系建立不了的原因，就是“不能收集到准确的数据”，或是“如果不是每一个数据都准确，就没有用”。如果我们要求每个数据都是准确的，这样一定很难，甚至不可能。但其实度量的定义明确，收集方法得到遵守，执行没有例外情况就可以了，不一定要每一个数据都验证清楚，这一定太费功夫了。

 

在数量达到大概50 个以上的一致数据，数据之间的偏差就会被中和掉。就是数据不是很一致，我们还是可以从收集到的数据说明一部分问题的。所以不需要要求每个数据都是准确的。

 

员工的态度

 

很多员工都觉得自己没有度量的责任。其实每一位员工都应该有理想，对自己有要求，这样才能进步。要对自己有要求，就得知道自己的效能。换句话说，就是自己要有度量自己效能的数据。如果团队有度量的需要，那么团队的成员就有责任收集所需的数据，提供过程的可视性，让改进提高创造条件。

 

另外一个借口就是“度量很难”。对于不习惯用数据说话的人，度量看起来有点难，因为还不清楚如何去思考度量的意义和用途。对这些同志，我可以提议归类法。归类法（taxonomy ）是一个简单有用的方法。总结以上的原因，度量难的原因，不出“目标不明确、度量技能、态度”这三个方面。大家就自己分析一下吧。

 

说到难，其实要得到度量的好处也不很难。但是要有几个基本的原则。

 

第一，一定要明确度量的目标和意义。

度量的意义在于提供一个反映实际的精确指标。所以我们的度量目标，就是提供我们过程效能的量化指标。比如项目的指标，开始时用三个就够了：周期、效率、质量；但是要一起监控。作为一位领导，要帮助团队提高，就需要监控所有的项目，看大家在一段时间之内的发展趋势，是否对头。也需要观察项目是否能够在关键因素之间找到最佳的平衡。这就提供了一个管理的依据，是持续改进的基础。

 

从项目组的角度，既然能够通过度量关键的因素，看到因素之间的关系，那就更能够有效处理这些因素。比如，以前单单关注进度。我们就会通过度量周期、效率、和质量，看到在什么条件底下缩短周期，对效率和质量有什么影响。不同时监控这三个因素，就不能了解他们之间的关系，就不能有效平衡项目的这几个关键因素。

 

这就好像是一个迪士尼的米老鼠气球一样，他有一个头，上面有两个大耳朵，一共是三个小球连在一起。如果你抓他的其中一个小球，其他两个就会膨胀，米老鼠就变形了。单单抓一个因素的管理理念造成的效果，就像米老鼠的气球一样变形，我称它做“气球效应”。摆脱了气球效应，我们才可以了解因素之间的关系，从而提高项目平衡这些因素的能力，达到最佳的效果。所以只有这样，才能有效地持续改进、提高。

 

领导明确了要求项目平衡这些因素之后，项目了解了因素之间的关系，就自然会要求有针对性的改善项目的个别活动或是过程单元。那么，项目立刻就面临一些问题，比如哪些活动对项目的目标影响最大？这个问题重要，因为我们要优先改进最关键的活动。另外一个问题就是，如何制订这些活动有效性的指标？我们需要用度量来回答这些问题。很多同志都说不明白如何制订度量目标。为这些问题找答案，就是我们的度量目标。

 

决定哪些活动影响最大的量化方法比较复杂，基本上是敏感性分析。开始的时候，大家不妨用定性的主观推测。6 sigma 黑带和SCAMPI 评估师一定会批评我。但是相信我，这样做不需要太多的经验，比较有效。只要大家答应在习惯度量的使用之后，一定要用量化的敏感分析就可以了。

 

在一般的软件项目里，要满足项目的进度目标，最关键的活动，可能就是通过各个里程碑的成功率，如客户接受方案之前的确认次数，版本构建的成功率，通过系统测试的版本数等等。次数越少，对进度越有利。项目就要度量这些次数。这样项目就制定了一些度量定义了。比如要满足项目的效率目标，影响最大的，可能就是每一个活动的效率，比如项目里所有的会议，需求收集、编码、测试等效率。可能影响效率的也包括各类活动的工作量和周期的分配。分派合理，就提高效率，如需求、编码、测试的比例，或是管理与开发的比例等等。这些活动的度量定义，有些是容易的，有些不那么容易。要知道，这些因素都是相关联的，一时未必可以理顺，所以还是主观地找一些关键的和可以度量的开始，就可以了。

 

让我举两个案例吧。第一个，要支持项目的效率目标，我们知道项目有些活动是直接关联到最终产品的，有些不是。那么，主观上，有关联的活动的比例越大越好。那么，我们可以制定哪些是关联强的，如需求、编码等等；哪些是关联弱的，如培训、会议、测试等等。我们就统计这两种活动的工作量。更简单一点，我们可以单单统计其中一种也可以。

 

第二个案例，就是找其中一个活动来度量，比如会议。有关会议的测量，同样可以是进度、效率和质量。会议的进度比较简单，就是开会的时间。但却不是最关键的。效率呢，就需要有一个会议的成就的度量。我提议用议程项或是决策项就可以了，反正会议是要来做决策解决问题的。会议的质量呢，就没有那么明确了。想一想，什么会议我们觉得是高质量的。可能是决策之前，考虑比较多的因素，可能是所有开会的人都发言，也可能是会议的决策没有被推翻。要有一个正确的会议质量度量比较复杂。我们就要判断是否值得。不值得可以压根儿不度量。一个变通的办法就是简化其中的因素，比如强调考虑过的因素是否充分，就不考虑决策的接受率或是实施率等等。这样当然有不准确的风险。我们不能因为不准确就不去度量，只要小心决定这个风险是可以承担就可以了。这样我们就可以制订会议的度量，如：参加人数、会议时间、议程或决策点、讨论的因素、与会人员的发言比例（有兴趣可以想一下如何定义这个度量）等等。

 

请留意，这些判断取舍，是按最能表达项目能否满足目标，衡量实际情况，考虑风险之后而作的，不是随意的，为个人、形势等其他与项目目标没有关系的原因而作的。这个非常重要。

 

第二，度量定义，最好能够是和过程相辅相成的。

 

数据的产生，最好可以理所当然地由过程产生。但不要过分依赖工具。基本因素离不开周期、规模、工作量、与质量。在这里，就谈一下这几个度量的一些简单定义。

 

周期

 

周期的定义，在乎始点和终点。如果我们希望使用度量来让自己的业绩好看一点，我们就会千方百计地把“始点”的定义延后，把“终点”的定义推前。这只是自己骗自己而已。反之，我们应该尽量地把试点定义为全部的开发活动。这就是项目已经具备资源以开展开发活动的时候开始。这些资源，未必是全部的资源，只要可以启动开发活动就可以了。项目的开发活动，包括开发产品需求，系统方案，实施，确认与验证，以及获取客户的接收。项目具备资源开展任何以上的部分活动，这个一般是制订产品需求，就是项目的“始点”。“终点”不应该时系统测试通过，因为这个定义有利益冲突。了解这点，“终点”就理所当然地是获得客户的接收了。

 

这样的定义，项目经理很有意见，因为现在的管理理念，项目经理未必有这个权力来处理好一头一尾的时间段。这就是误解了度量的用处。我们有一个用度量来评价人或是项目的心态。这是奥林匹克比赛的度量观。每一个独立的数据点都是全部的意义。这是不对的。同一个活动，不同的实施，就受到不同的氛围、条件限制。同一个活动的两个实施，不一定是可比的。这不符合过程的度量观。

 

过程的度量观是反映团队的效能。一个组织的效能，就是所有项目的效能的总和。就是说，所有项目的效能（其中包括项目经理和成员的技能）数据作为一个集，才能代表组织的文化氛围与过程能力。如果组织不能合理有效地处理资源的下达，获取客户的接收，那么度量的确应该反映团队不具备很好的效能这个现实。正确的管理理念，就是领导需要看见这个现实，从过程的角度，考虑如何提高改进，而不是追究责任！领导的责任，就是分析这个项目的效能数据集，从而找到改进的道路，帮助组织提高效能。

 

规模

 

软件项目，规模通常就是代码行。这是无可厚非的。也有使用功能点的。代码行是产品的规模。功能点才是项目的规模，因为这是项目需要实施的功能。功能点有两个问题：第一，它适合以人本交易（tansaction ）为主的系统，如财务等企业信息或是网上的C-B 和B-B 的系统。对其他通讯、自动化、遥控等系统不很适用。第二，这类方法有很多微调的要求，需要对方法以及应用领域有经验。对于一般团队需要一段比较长的学习时间。但是项目的规模，的确是应该依据需求，而不是依据产品来制定的。对于硬件项目，规模就更加复杂了。我们希望有一个简单的，可以用于大部分项目的规模定义，这就容易管理了。

 

我建议用产品需求来制定规模。本来每一条（或是一项）需求的粒度差异很大，使用需求项数量来度量规模很不一致。但我们可以利用一个简单的原理：如果粒度越小，需求项数量越多，差异就越小，就越可以代表项目规模。问题是，如何细化需求，如何决定细化的标准。我的建议是：每一个需求项，就是一个需要验证的独立因素。举一个例，一个这样的需求：

 

买一张星期三上午9:30 前，从上海到南京的头等×××头火车票

 

就可以有五到八个需求项：
  • 星期三上午9:30前（是两、三个因素？）
  • 上海到苏州（是两个因素？）
  • 头等
  • ×××头
  • 火车票

 

虽然需求项的粒度，还不能是绝对一致的，但是差异已经缩小到从统计的角度来说，可以是一致的程度了。这代表着开发产品需求的系统工程师，需要清楚每一个需要测试的因素。系统工程师的角色，本来就要求这个能力。这样的规模定义，是一个驱动提高需求质量水平的非常有用的理念。

 

不同领域或是产品，基于需求项的规模定义，可能是不可比较的。但是同一类产品的项目，是可以比较的。这样的规模定义，是简单的。从项目的任务角度看，是理所当然的，是容易判断与收集的。同时，还会让系统工程师提高水平，让测试人员的策划工作，非常方便。

 

工作量

 

工作量可以用于几个不同的目的。一个是反映某些任务的大小，另外一个目的是帮助策划将来的项目。工作量可以应用在不同的任务，比如会议的工作量，或是编码、测试等的工作量。会议的工作量比较明确，有多少人，会议进行了多久，就可以算出来会议的工作量。以后也可以用这个数据来策划将来的会议。但是我们不会想到会议里有些是有意义的发言，有些是风花雪月的闲谈（尤其是开始的时候），我们不会把这些时间段分的非常清楚吧。分的这么清楚有意义么？一定不容易，而且意义不大。但是我们编码的时候，就往往要求只记录真正编码的工作量。比如，一天之中，开了一个会，回了一些邮件的时间，要从编码的时间减除掉。这样的工作量，听起来是比较准确，但没有用。因为将来估算类似的任务的时候，我们还要知道一天的平均会议，回邮件等等的时间。这样非常麻烦，而且会引进不准确的因素。要解决这个问题，我们需要按照项目管理的原则，制定一个在组织氛围低下完成任务的工作量。我叫这个定义为“成本工作量”。

 

要定义有意义的工作量，项目首先需要按项目管理的原则制定“任务”。任务有很多层次，比如：开发一个模块是一个任务，主持一个会议也是一个任务。这两个任务是在不同的层次上面的。开发模块，是产品的组成部分。会议，可能是完成这个模块所需的，所以层次比较低。一个项目，最高层次的任务，应该是按产品的构建而制定的，就是说，是跟系统方案是一致的。这样的任务，才可以代表整个项目的范围。这个层次的任务，我把它称为“项目层任务”。会议、评审等等，就不是项目层任务。还是需要策划，但度量的方法不一样。有了这个概念，才能定义出有意义的工作量。

 

成本工作量，就是一个项目成员完成他的项目任务所需的“在勤时间”。在勤时间，就是他上班的时间。那么，一个项目成员在他开始一个项目任务的时间，到这个任务完成的时间，他的上班时间，就是这个任务的工作量。其中包括会议的，评审自己与他人工作的，回邮件的，甚至上厕所的，自己胡思乱想的时间。如果同时处理多个任务，就要制定原则，把时间分配到各个任务上去。这个定义，工作量的收集不用员工操心，考勤的信息就可以了，是非常简单的，也是与项目的操作相配合的，收集数据的额外干扰就减到最少了。这个定义不是唯一的。我们可以定义成本工作量为“在职时间”。这就包括了请病假、接收培训、出差之类的时间。各有好处。大家自己研究一下，自己决定。

 

项目的总工作量，就是所有项目层任务的工作量，加上管理与支持的工作量。要监控项目里的各种调控，就需要有比较精确的度量，我们是不能从考勤信息拿到，是需要特别度量的。我称它为“度量工作量”。比如项目的会议所占的比例，就是所有会议的工作量之和，对比整个项目的成本工作量。那么，我们就需要有精确的会议工作量。这个我们从会议纪要里可以算出来。评审占的比例也是如此。另外一个案例就是返工量。这个不是项目层任务。所以我们要精确地算出来。一个方法就是用变更控制系统。如果变更控制系统是规范的，每一次每一位员工处理变更请求单里的要求所用的实际工作量填上去，那么，返工量就是这些变更控制系统里的工作量之和。

 

质量

 

真正的质量指标，应该是独立于项目的，是由项目之外传递过来的，例如：现场故障数、故障间隔（MTBF ）、客户满意度等等。在成熟的团队，度量真正被利用来管理项目，那么项目过程之中的缺陷数，跟实际的产品质量还是有一定的关系的。

 

定义缺陷的时候，需要考虑失效与缺陷的分别。我们通过测试或是现场发现失效。缺陷是产品里面造成失效或是不能满足需求的原因。我们需要分别他们，是因为每一个失效里，可能有一个或是多个缺陷。所以数量就不同了。在项目里，缺陷的定义可以是基于失效的，也可以是基于缺陷的。最终还是需要能够建立项目里的质量特征（无论是建立在失效或是缺陷之上），与产品的现场表现关联起来的。

 

与产品质量关联的项目质量特征，包括两方面：项目里的缺陷密度与发现缺陷的阶段分布。所以质量的指标，在统计缺陷数的同时，也要统计在不同阶段的缺陷发现分布。

 

所有这些数据，都应该可以在变更控制系统里拿到，它们的收集，还是比较理所当然，不会让项目受到太大的干扰的。

 

第三，知道如何分析，才开始收集。

 

要看图，不能只看表格

 

在收集数据之前，需要清楚如何分析收集到的数据，并且如何使用分析的结果。从上面的讨论，我们知道要掌握过程效能，就要看一整堆的数据，看它们的中间趋势，与标准偏差。也要看时间上的趋势和分布。所有这些，都要通过图来表达。表格是不能充分表达这些特征的。分析的方法之一，就是要看图，不能单看表。度量的实际应用，每一个人都照着自己的目标来制定度量的需要，在实践中积累度量的经验，提高度量的能力。

 

不用过程数据评价个人

 

有一件事，再要强调一下。过程数据不要用来评价个人。除了会破坏度量体系，歪曲过程之外，也会造成不同领域之间的壁垒，妨碍团队的共同目标。从另一个方面看，我们提到，项目有一个最小的因素集，并且要监控集里的所有因素，否则我们得不到最佳的平衡。对项目来说，集里有三个因素。在个人方面，这个集里的因素就多的要命。技能、态度、性格、喜爱、沟通、人缘、等等，每一个都对员工在项目的价值又非常重要的影响。这个也是为什么不应把过程数据用于评价个人的原因之一，因为我们永远都不清楚这样做的效应是否正确，是否有利。