1

设想一下您是一位经济学教授，并回到1995年。有人问到：“现在有一个可以看到未来15年的水晶球，我想测验你的预测能力，这里有2个百科全书，请你猜下哪本会在15年后成功？第一个百科来自微软（当时微软已经是很有名的公司，出了windows95），微软正在筹备Encarta 百科全书，邀请很多专家、高薪经理来监控整个项目，确保成本和时间，打算成功后把百科全书刻在光盘在线上推广。 第二个百科不是由公司推出的，它会有很多千万个不同的作者，但他们只是志愿者，这些人也没有什么激励，而且每个贡献者不会收到一分钱，这些人每周可能会花几十分钟来做这件事，但百科全书可以线上用、免费用、任何人都可以用。 请问教授，你觉得15年后哪个百科全书会更成功？“

你可以想象在1995年，每个正常人都会觉得第一种全书会成功，选第二种是可笑，但事实证明，在2009年底，微软经过了16年的投资，最终宣告 Encarta项目失败，而第二种(Wikipedia) 则成为全世界最大最受欢迎的百科全书。

2001年，十七位敏捷大师在盐湖城， 因为都觉得应对不了需求不断变化的现状，不满当时的软件行业发展模式，发表了敏捷宣言 (Manifesto for Agile Software Development) ，开始了软件敏捷潮流。

市场高速变化，不仅仅局限于软件开发。

例如在90年代，当音乐CD还是很流行的时候，有人开始在网上提供音乐下载，CD生产商把他们告上法庭，并且赢了官司，但是最终大部分的CD的生产商还是要告别市场，因网上下载是大潮流，CD已经慢慢被淘汰。所以官司赢了，但是总的战争是输了。

边界（Borders）本来在90年代也是一家很牛的卖书商店，生意很不错，当时开始有人在网上购书，但是公司老板觉得卖书才是主业，他就把电子商务(e-commerce)业务外判给亚马逊。结果大家都知道了，传统的卖书行业很难生存，边界（Borders）最终破产，但亚马逊成为全球电子商务巨人。

前面“创新4中”中提到，被 Jim Collins 选出的十一家优秀企业，有2家 Circuit City 和 Fannie Mae分别在2008、2009年宣布破产，他们的主管应该都很优秀，但是仍然破产，说明企业要抓住潮流，赶上对的车子，要不就会反应不过来，最终失败。

大陆很多企业家都预测2019年会不容易，公司如何面对市场快速变化的挑战，持续不断提升？

度量是其中一个帮助企业的方法，但我接触很多IT企业与开发团队都不理解度量与分析，让我先分享度量的一些常见问题或需要注意的地方：

2「后视镜开车」

戴明博士在他的演讲里提出了美国很多企业都是用后视镜开车，很多我们公司企业度量的都是以往的数据，对后面是否有帮助公司达到目标没有什么帮助，在这快速变化的年代，这更重要，所以企业的主要度量必须具备两个特性：

A）前瞻性指标 (Leading Indicators) 可以帮助我们判断是否可以达到预计的效果

B）可以转化为一些具体改进行动，简单来说就是一些可控因素 (Controllable factors)

识别有前瞻性指标没有那么容易，有时候觉得跟常理违背。

例如在传统的百科全书年代，有谁会想到他的前瞻性指标是多少人能上互联网？

因为传统百科全书的老板没有把自己想成是一个在线的信息提供者，没有想到多少在线的用户和他的业绩有关系，所以业务断送在维基百科上。

你可以想象当时百科全书还是主要监控一些已经过去而且无法控制的指标，比如百科全书的销售额，尤其是在这个快速变更的市场环境中，当公司发现销售额一直往下跌，已经太晚，转变不了大趋势。

同样道理，我们如果只是关注每个季度的收入，盈利是否达标，对整个未来的业务是没有什么帮助，因为过去已经过去，业务经理也不能做什么来改变它。 当那些管理者的注意力都是放在一些已经过去的指标的时候，整个企业很容易经常处于“救火”的状态，当他们已经是到达那种状态的时候，这些经理无论多优秀，能做的都有限，这种情况下，他要快速响应，很多时候会变成反效果。例如前面所说CD行业的市场变化，因为当时管理者都没有意识到网上下载的大趋势，反而把目光精力投在如何用法律防止网上下载，来保护他们传统的业务模式。 假如传统公司早点把目光放在观察一些领先的指标或者预计的指标，观察到市场的基本变化，他就可以在他CD销售的量大幅下滑前反应，也可以更早深入研究、比较更多不同的战略，有机会可以挽救这个倒闭的结局。 如果较早观测到大趋势，可能会有足够的财力能力来适应，这样的话，我们现在看到的网上下载音乐的主要供应商可能还是那些传统的CD公司，而不是苹果的 iTune 和 iMusic 。

度量并非越多越好，应该越简单越少才有针对性和影响力，比如记得我们前面讲过有个研究哪些企业表现最好，在这些企业里都有个特点，他们的领袖都会心里有个清楚的数字，来代表这个企业的近况和情况，比如有个例子，有家叫 Walgreen’s的零售商，本来只是度量每个零售店的盈利是多少，但是发现这个对整个企业的分析/提升没有什么帮助，就转成度量每个客户的盈利。这种他就变成后面就有比较多的分析，把客户进行分类，对不同的客户群进行不同的推广，整个企业就是针对这一个系数不断提升整个企业也有方向了。

我们在公司选择一些主要的指标的时候，也应该想，在众多基数里，最多选4个，否则就可能缺乏针对性。

1997年，当乔布斯刚回到苹果时，苹果有很多问题要解决，市场的领先度很弱，但乔布斯其中一个很优秀的能力 ——他知道专注的重要性。

他回公司以后，做了一个产品的回顾，发现苹果当时乱七八糟，没有任何针对性，比如很多产品有不同版本、不同型号等等，乔布斯就问苹果的员工，为什么要多这么多不同的产品版本？

原来是前任的领导为了挽救苹果的市场地位，发行了大量不同版本的苹果产品。 乔布斯做了一个策略：减少产品而不是增加产品。

他在白板画了4个框，纵向的2列一个消费者 (Consumer)，一个是专业使用者 (Pro)，横向两行其中一个是台式机(Desktop)，一个笔记本电脑(Portable)，他告诉团队，专注做4个优秀的产品，每个框一个，其中做4个优秀的产品就让苹果整个市场地位快速回升。

3「研发的度量」

前几天有个杭州客户转发了一个关于交付、研发效能度量的一个分享，初看内容是挺好: 

有分解、具体定义，比如从响应速度分解成交付周期，开发周期；比如交付质量分解成单位时间线上缺陷，线上问题解决时长等；

还有其他指标 —— 如：发布能力、交付吞吐量等等。再进行很多分解，总共有10个度量，举了些例子，说如何利用这些度量帮企业不断提升，说这些度量如何跟上面的商业目标关联。

Picture : 研发效能的度量

开始的时候，有一个标题叫“要简单”，但是当一些非开发的人看他那些度量时，可能并非如作者所想象的简单。

我会问：这些多的指标，可不可以再简化和综合？

因为有些指标之间有关联性，比如需求响应周期可能跟持续发布、交付吞吐率或质量有关，之间并非完全独立。

可以体现上面提到控制不要超过4个指标，最终成为一两个最主要的指标。比如可以主要看总的交付周期+质量，这会更简单容易让高层理解。

这些指标必须帮助经理预计他的最终结果，好像度量这些已经得效果，没有一些可控因素，都是以结果为主。

上面的例子，我们如何可以增加一些可控因素的度量，而不是后视镜的度量？

我们在做CMMI过程改进度量与分析，通常会建议，利用一个：

G- Goal 目标 

Q-question 问题 

M - Metrics 度量 

的思路来把度量项关联到目标，以上面的实例，比如其中要关注交付软件的质量，我们就会问，有哪些因素会影响质量？

比如是否和写编码的能力有关？没有按照最佳实践，还是使用了一些陈旧的代码方式，导致代码有问题，如果这样的话，我们除了度量缺陷外，还要度量一下有多少代码的陈旧语句，或者克隆的(copy and paste) 比例。因为我们相信如果代码中，这些出现越少的话，代码质量应较好。

你可以想象，我们不仅仅度量缺陷数，也度量代码本身的一些特性，对当事人来讲，比如编码人员来讲就会有意义，他会开始注意写代码的方式，避免不应该的陈旧语句，最终提高质量，而不是说你的代码质量不好，他也不知道如何完善，这就是一个前面说的可以控制，有前瞻的度量的例子。如果我们一直度量那些代码本身有不足，也很有把握可以预测质量有一些问题，不要等到测试才被发现。

例如，我们帮一些企业完善敏捷开发项目，做度量时候，我们倾向于简单，比如进度偏差、代码生产效率，缺陷质量3个系数为主，除了度量这些，我们也会度量代码本身，比如有多少陈旧语句，有多少拷贝的数量，这些就是我们说的可控因素，我们知道如果编码写的不好，当然质量或进度都会受影响，我们咨询的项目也是如此，本来比较有延误，缺陷也较多，每个周期，但是后面提高了编码的方式，整个效果就出来。

4「项目间的可比性」

数据本身的正确性也很重要。 戴明博士在美国演讲时就举了一个例子： 有一次他发现几位统计专家在做数据分析，而且马上会有初步分析报告，便询问了他们关于这项目的背景，他发现他是认识那些提供数据的项目组员，很清楚了解项目数据的来源都不可靠，于是便告诉这些专家不要浪费时间。

上面故事的经验教训：做任何度量数据分析前，都需要确保数据可靠。

本周和一家成都的软件开发公司做差距分析，管理者说最关心项目的进度偏差。 后面我们与项目经理交流，发现项目的进度偏差都是单靠项目经理填报，没有使用任何项目管理工具，导致绝大部分项目的最终进度偏差都是零 （因项目的进度基线一直在调整）。

后记：

数据本身的正确性也很重要。

戴明博士在美国演讲时就举了一个例子： 有一次他发现几位统计专家在做数据分析，而且马上会有初步分析报告，便询问了他们关于这项目的背景，他发现他是认识那些提供数据的项目组员，很清楚了解项目数据的来源都不可靠，于是便告诉这些专家不要浪费时间。

上面故事的经验教训：做任何度量数据分析前，都需要确保数据可靠。

本周和一家成都的软件开发公司做差距分析，管理者说最关心项目的进度偏差。 后面我们与项目经理交流，发现项目的进度偏差都是单靠项目经理填报，没有使用任何项目管理工具，导致绝大部分项目的最终进度偏差都是零 （因项目的进度基线一直在调整）。