研发效能度量中心的底层逻辑

点击👆蓝字 关注我们

导语

度量中心是什么？企业为什么需要度量中心？开始之前都要想一想，先三思而后行（不要为了做而去做）。度量中心通常会面临的挑战有哪些？是跳下去填坑？还是避开坑？

1.为什么要建度量中心？

我们现在可以看到，软件已经成为很多企业运营的核心。我们认为，未来所有的公司都会转变为某种形式的科技公司（软件往往与人工智能密不可分）。可以想象，在未来，企业的业务与科技将会越来越紧密地融合。科技投入在企业中的比重将会不断增加，其成本也将成为企业运营中极为重要的一部分。这是一个不可避免的趋势。

过去，许多科技团队习惯于将自己视为一个成本中心，并认为自己已经尽力工作。当被问及管理情况和改进空间时，科技团队常常将技术视为神秘领域，难以管理，从而希望避免外部的干预。然而，对于首席信息官（CIO）或类似的科技领导者来说，这种状态已经越来越难以维持。

从数字化的角度来看，整个组织都在进行数字化转型，业务也在逐步数字化。如果仅有科技部门在推动数字化，而自身却不进行数字化转型，这种情况将变得难以解释。因此，科技部门需要在推动组织数字化的同时，自身也进行相应的数字化改进。

从管理会计的角度来看，我们认为研发的度量系统类似于科技团队的会计系统或财务系统。这些系统记录了团队在做什么、花了多少成本，以及这些成本是否合理。

之前有同学问我们度量中心是否只是科技部门的自我管理工具，对业务有什么好处？

我们认为，只有通过这样的系统，才能解释科技投入的去向，确认这些投入是否集中在组织最关注的领域，是否符合组织的战略发展方向。只有这样，我们才能将最宝贵的科技资源应用在最重要的领域，使资源发挥最大效用，从而支撑业务发展。

否则，很多时候大家可能在从事看似高大上的项目，但这些项目并没有真正帮助到业务，或者只是满足了领导的紧急需求，而这些需求并不是真正紧急。因此，我们认为度量中心的建设对于科技团队和研发项目的系统化管理非常重要。通过这种系统化的度量，我们才能确保科技力量得到最大程度的发挥，并有效支持业务的发展。

2.研发效能度量中心远远不止是看起来酷炫的大屏

我们现在看到在很多组织里面都有一块大屏。很多组织都会说：

“我们度量中心已经建好了，看我们那块大屏有数一直在跳，这我们的度量中心。”

这样的大屏，大概率它是从很多系统里面取很多数，把这些数放在大屏上看起来花花绿绿的，挺好看的。因为度量中心是整个金融科技中心对外输出的窗口，所以很多人在建度量中心的时候，首先考虑的是颜值（当然这也是需要的）。

但是真正当我们去看研发效能的时候，数能准吗？大家可能会说我们有总数，但是分到各个团队，数可能就没有了，或者就不太准了。或者是到了团队数，它是怎么构成的，大家说不知道。最终就会发现大家花了大量的时间，看上去很酷炫，在用的时候可能会发现初看挺有用的，再去细看的话，下一步到底应该如何去做，就会非常困难。

甚至有的连系统对接都没做，那个大屏的数是一帮“表哥表姐”，手工算了一些数，塞到大屏里面，再加一些动态效果，看起来好像数一直在动，但是实际上并没有真正跟企业的日常连起来。

很多业务部门里面有些大屏，可能他们的数据稍微质量好一点。但是在研发组织里面，反而灯下黑，自己的研发数据的质量，包括大屏，现在都处于初级阶段——可能有了，但是，数据还不能用。

度量中心也是这几年随着数字化转型的深入，各组织开始逐渐重视起来的。要不要建这件事儿，大家好像已经迈过那个坎儿了，要建设。但是要建成什么样？各家都有自己的理解。关键是建起来了以后，是不是真正能在整个组织里面推动用起来，真正能够落地，我们经常说的是，是不是接地气，是很值得研究的。很多企业的度量中心可能建了以后就成了摆设。

稍微好一些的，知道看数了。但是，容易停留在看数据的表面，比如说时效波动或产能波动。但是数据波动的背后，为什么会有这样的变化？都还不能够去深入去了解。度量中心，度量的数据是能够去引导行为的，引导团队改善的。度量是否带来了哪些改变？所以度量中心能够下钻，能够分析是很重要的点。但是大多数企业的度量中心目前都做不到。

3.研发效能度量中心需要具备什么能力？

3.1度量中心建设要内含世界观——对象模型

我们认为好的度量中心，要有领域模型，要有它的世界观，也就是回答「组织应该怎么管」的问题。

现在很多度量中心不合格的，它没有抽象的世界观，没有灵魂，核心是不稳的，做不了数据的映射和编制。组织里面有哪些对象？对象之间有什么样的关系？建设度量中心，如果没有世界观，没有价值观，那做出来的东西就会流于表面。

很多组织都是我先建了个A系统，里面跑的叫需求；同时也在建B系统，里面跑的也叫需求。这两个需求是不一样的。但是，当时建的时候因为两边并行建的，叫需求，我也叫需求就这么着了。过一段时间，可能大家也就搞不清楚了。

可能因为当时时间紧，任务重，要安全合规，大家都是各建各的，在一定程度上保障安全合规的问题，在当时的那个时代也起到了作用。但是随着我们需要越来越快的去发现组织类有哪些问题，有的时候是需求外界变化很大，要能够支持动态的去规划调配资源。不是通过层层汇报达成，而是有系统能提供实时，准确的数据，来支撑企业做决策。那这时候，这些系统之间就要连通，那一旦连通的话，就会发现的名称跟我的名称不一样或者重复，怎么把这些数据快速连通的问题。

最后会发现所有的数据都有。但是一旦要快速的查数，就要等，要等待加工。加工完了之后，由于每个人理解跟想呈现的东西都会跟领导想要的东西会有一些差异，最终的话，会导致整个系统的得到的数据，第一，响应的不快，第二，响应的可能也不是管理者想要的，因为它全面性不够，要想看更多的维度？对不起，又要等几天。

我们认为建设度量中心建设的第一个难题是要把世界观建设起来，把管理模型做重新梳理。把对象模型能够定义出来，组织内达成共识。要做对应，这个系统的需求和那个系统的需求，这个系统的任务和那个系统的任务，到底是什么关系？

度量中心，它是对整个组织各方面流程以及各种管理行为模式的梳理，它是最终的因果呈现。所以我们在做这种领域整个模型的梳理的时候，它不是简简单单的工具上面的事情，它前面涉及到非常多的上下左右达成共识的。

举个小例子，譬如说我们在衡量研发的产能到底是什么样的时候，我们还在用什么功能点，还在用什么人天的时候，人家业务说我就看给我交付了多少个需求。这是很简单的对齐的模式。梳理领域模型的过程，是对整个组织的概念的大的澄清，是对企业管理行为的梳理。

所以，度量中心什么人来建？基本上我们做的度量中心项目都还是CIO、副行长牵头，都是一号工程。因为它不是简单的算几个数的问题。度量中心的建设是非常顶层设计的事，需要蛮多能量级别，要高层领导的推动，才能够凝聚这种共识。

3.2研发效能度量中心要具备价值观——内建指标体系

统一的领域模型，或者说管理信息架构让大家都术语一致，那有了术语一致之后，我们把系统里面的数据给汇集起来，就可以去做度量。度量到底会有哪些维度？框架又是什么？

ADAPT的多快好赞是一个可参考的核心框架。怎么才能达到多快好赞？我们又做了一些分类，人事流上面。从人上面怎么看，从事儿上面怎么看，从流上面怎么看。当然每个理念，也是结合了我们之前的一些精益思想、敏捷方法。

度量中心首先要有世界观。第二个，应该有支撑的度量体系——应该怎么样去衡量软件研发的效能。我们在用知微来做度量中心的时候，就是按照这样的框架来去支持。度量中心不是简单的加减乘除。多快好赞也好，精益的思想流动也好，这些都是一些如何能够获得更好的研发效能的原则，所以度量中心要有内置的一些指标的一些思想，而不是从零开始或者简单的加减乘除。

3.3研发效能度量中心要自带数据治理能力

实际上企业的度量中心现在大多数都不是智能问题，现在最基本的准确问题都达不到，研发数据的质量是非常差。以现在的研发数据为基础，不论做什么特别高级的人工智能计算，最后也不会有什么好的结果，因为垃圾进垃圾出。

所以现在建设度量中心，第一步是做数据治理。让数据先达到基本可用的状态。那怎么让它基本可用，分而治之，先要把数据分到每个团队，让每个团队去看自己的数。就会发现数据不准。下一个问题，为什么不准。就像市场经济，把数据交给每个团队，让每个团队自己看到自己的数据。

我们设计知微（我们自己的度量中心工具）的时候，我们有T+1的能力，可以把一些数据算成指标存起来。但是，更重要的我们提供T+0的计算能力。数据呈现到小队，同时可以马上下钻。这也是知微重要的能力——永远可以下钻。假设现在有100个需求，你问哪100个？马上可以下钻看到是哪100个。这时候就很容易发现数据是不是脏的，可以及时更改。

T+0和T+1相差了几千倍。如果是T+0的，可能是秒级计算的，在做度量平台的时候，所有的实时指标都可以秒级计算。如果只有T+1的能力，去做度量中心，到最后的结果基本上就不会准。因为今天看着不准，等明天，又有人离职了，又有需求来了，又有什么，反正还是不准。一圈下来，一年都不会准。所以，在研发的度量中心建设中，需要具备T+0和下钻的能力来去实时的数据治理（当下钻的记录即为为源记录，更易于治理），这样才能够把数据做准。

通过底层的数据治理，最后在宏观层面产生更有价值的数据。这样的度量中心，对企业管理才有更有价值。

3.4度量中心要具备多维组织架构建模的能力

设计度量中心时需要对组织内的信息有清晰的认识，才能做好信息的映射。因为度量中心需要从不同的数据源中提取数据并汇总，这对组织架构也同样适用。企业内的细节和组织架构往往非常复杂，我们常常需要请求各个组织提供详细的架构图。然而，系统中的组织架构图并不总是与实际情况完全一致，因为组织架构经常发生变化，涉及多个部门、横向项目、兴趣组和委员会等多种形式。

因此，我们认为度量中心不仅需要具备对象的世界观，还需要具备组织的世界观。必须对企业内所有的组织及其在不同工具中的表现有整体的认识，这样才能将各个工具中的数据汇总并按照不同的组织维度进行整理。

整理完数据后，我们需要解决的一个关键问题是数据治理。通常，数据治理的责任落在某一个数据部门上，但这是无法单独完成的任务。数据治理必须发挥整个组织的力量。为此，我们需要将数据视为各个组织的共同责任，让每个组织都清楚自己的数据达标情况和数据量。

通过这种方法，每个组织都能承担起相应的责任，并且能够定期生成报告，显示哪些部门需要增加数据，哪些部门已经完成了数据清理，哪些部门可能落后。这样，我们才能持续保持组织的数据健康状态。组织的世界观确保数据的干净度。

在数据干净之后，这些数据还能传递改进的压力。例如，当数据被清理干净后，可以用来驱动组织的持续改进，显示各个组织在不同时间段的数据表现，帮助评估和提升整体绩效。

这就是我们所说的度量中心需要具备的组织架构建模能力，或者说具备组织的世界观。

4.度量中心的应用要点

4.1 主线是用于团队的自我改进，提升组织整体效能

度量中心的应用非常重要，但建立起来并不容易。一旦度量中心建成，它的影响力可能是巨大的。组织经常会认为这些工具不重要，但一旦度量中心建成，反而需要谨慎使用它。

度量中心可以提供强大的观察能力，这种能力本身就很有威力。通过度量中心进行横向对比，可以揭示很多问题。我们希望除了宏观的组织观察之外，更注重团队自身的对比和评估。

团队自我对比的方式是指，我们希望团队能够更多地进行年度内部对比。例如，今年的指标可以是定量的变化，但也可能受到其他因素的影响，如今年是否承担了大项目，或团队中是否有大量新人等。这些因素并不完全可以量化，因此我们需要结合定性和定量的方法来评估团队。

有了定量数据，团队更有动力去改进，这对团队来说是一个积极的激励因素。但我们必须非常小心，因为这种激励也可能带来一些负面影响。有时，领导在使用这些数据时，可能会带来压力或负面反馈。

因此，度量中心建成后，我们需要特别注意如何使用这个工具，以确保它真正为组织和团队带来正面的效果，而不是引发新的问题。

4.2个人层面，观察异常数据

对个人层面的度量，我们的观点如下：虽然度量可以细化到个人，但我们认为观察的最小单位应是小队。对于个人的观察，我们认为主要是进行宏观的统计，而不是具体评价个人的好坏。

在一个小队内部，我们建议更多地使用定性判断，因为很难明确区分是开发人员的问题还是需求方面的问题，许多因素无法完全量化。从统计角度来看，我们可以观察个人的表现，但这种观察的主要目的是从宏观层面了解组织情况，而不是评价小队里谁做得好或不好。

参考谷歌的管理方法论，谷歌认为前5%的人才贡献了大部分价值。这些顶尖人才必须得到保护和重视，同时需要帮助表现最差的5%的人提升。因此，观察个人的主要目的应该是识别这两个极端的群体：顶尖人才和需要帮助的人员。

从我们以往的经验来看，通过统计数据，这两部分群体通常是非常明显的。因此，我们应该利用度量中心，从统计上识别并观察这些关键群体，以便更好地管理和发展组织中的人才，而不是用于对每个人进行具体的评价。这样可以更有效地发挥组织的整体力量，找到并支持两端的团队。

5.研发效能度量中心建设的成功要素

度量中心是X光机，它会把这么多年研发组织积累的各种不合理、各种系统建设各种各样的问题，全都显现出来，它是能够发现问题的。但是要建设好，也要有心理准备迎接一系列的挑战。

5.1高层的决心至关重要，要有长期、系统的准备

度量中心的建设是一项「一号位工程」，需要高层管理者的决心和耐心。

一些科技的领导可能本身是研发出身的，会认为研发本身是创造性的工作，不应该有过多的干扰，因此对于度量、对数据的关心度是不太够的。高层不关心，其他人对这件事就不会刻意去追求，数据就很难去被关注到。数据不被关注，就不会准，那就会导致恶性循环。所以高层决心是很重要的一点。

领导要有相应的准备，第一，这是系统工程，这是需要长期建设的，不要指望快速见效。一开始更多的是发现组织里的不合理的问题。应该把发现问题当成收获。而不能期待数据马上可以出来、马上可以很准。

积小胜为大胜，某指标出来了，某几个指标出来了，就不错。建设需要有耐心。类似还旧账这样的过程。但是，如果旧账不还，那账会越滚越多。所以，度量中心的建设，还是应该尽快去做，尽快启动。这样才能发现问题才能不断改进。

5.2数据要来源于真实的协同过程

同时，度量中心一定要注意数据从何而来？对于执行层的人来说，度量出来的这些1数据一定要去考虑它是如何产生的。是研发过程中必不可少的活动而产生的，而不是被要求、额外做出来的。数据都是基于协同产生的数据，那样数据才会真实可靠，这是大的方向。

人、事、流，中间会嵌留着各种活动。

比如说流——需求端到端流动过程中，人在上面的一些协同，那基于什么协同，是需求。那需求是不是随便流的，肯定不是的。整条价值流贯穿的是不同的职能角色。过程的交付标准是什么，就决定了要展开什么样的活动，最终才能推动需求往下流。所以要定义一些关键节点的流动。基于关键节点之间的流动所产生的数才有价值。能够去解决什么问题，或者说帮助团队发现什么问题。

建度量中心的时候，要站在业务驱动的视角，多方共同的协作，才能实现各方的管理的诉求，才能够保证的度量中心建好。而不是简单从这里抽个数，那里抽个数过来。

5.3度量中心不是简单的工具建设，妄图一蹴而就不现实

有很多组织可能建度量中心就简单到市面上找一找，哪家公司提供这样的工具，可能就三五个月就建起来了，那建起来了之后就会发现，不一定好用，或者说建出来了之后，大家觉得并没有什么帮助。

大家往往把度量中心和工具建设简单划等号，这是很危险的事情。它是组织里面的世界观，是统一组织思想的过程。如果不把思想统一了，建不出来度量中心。即使建出来。到时候最后也是一个漂亮的大屏放在那，大家都不用，因为大家并不认同上面的数据，并不认同数据采集过程的做法。

度量中心它建设不单是工具的问题，它背后涉及到管理行为、组织发展、人性假说这些都是会揉在里面的，但是一般我们最后呈现的时候，不会涉及到这么复杂的东西。但在背后，它本质上是说企业在做管理的时候不是简单的一刀切。

首先对于领导来说，不能认为上了度量中心，就把下面所有的事情能完完全全统一做管理。那对于下面的团队也别觉得有度量中心以后，所有东西就一定会通过数据完全体现了。整个研发领域是复杂的。所以在建设度量中心的时候，对于某些指标来说，需要分级分类来进行思考。

6.度量中心如何持续健康运行？

度量中心建成后，要在组织内持续健康地运行，需具备几个关键要素。我们认为主要有三个方面：

首先，数据质量的提升是前提条件。假设通过之前的努力，数据质量已经得到显著改善，我们需要将数据度量纳入现有的管理流程。这意味着我们在管理和决策过程中，开始使用这些数据来判断健康程度，并引导大家的行为。关键在于使用数据。各层级的领导和员工需要具备数据的读取和使用能力。因此，培养数据文化至关重要，让整个组织学会用数据说话和沟通。

其次，数据文化的形成是一个渐进的过程。为了促进这一文化，我们可以寻求外部专家的帮助，以加速这一过程。数据文化不仅仅是技术问题，还涉及到观念和行为的转变，使整个组织在数据驱动的环境中茁壮成长。

最后，针对不同领导的特长，我们可以采用项目行会的做法。不是所有领导都具备强大的数据分析能力，因此，我们希望在领导团队中引入数据分析专家，作为领导的“参谋”。这些数据参谋可以帮助领导进行数据分析，制定计划和策略。例如，领导决策要攻下某个“山头”，具体的作战计划则由参谋来制定。这种机制能够确保度量中心或数据驱动的改进在组织中健康运行。

通过上述三点——提升数据质量并纳入管理流程、培养数据文化以及引入数据参谋机制，我们相信度量中心可以在组织中持续健康地发挥作用。

小结

度量中心研发的效能的度量中心相当于科技团队的财务系统。

科技团队自己本身，至少目前在大多数企业中都被视为成本中心。团队干了这些活，钱花到哪儿去了？哪个团队做得好，哪个团队做得不好？它不是直接的收钱，但是一直在产生“成本”。只不过，原来因为在扩张期我们无所谓，需要1000人，就给1000人，需要1500给1500。没有人算成本。度量中心现在的作用就相当于最后跟CIO算账的时候要去弄明白，人用去哪了？在为谁服务？服务得怎么样？

从现在数字化的角度来讲，度量中心是研发团队的数字化管理的支撑。科技团队总在帮业务做数字化转型，那自己研发的数字化转型在哪里？度量中心相当于是从经济成本、运行效率上去度量，组织到底做的怎么样。

文末彩蛋

关于度量中心的建设，每位嘉宾给出了自己的精辟洞见：

CC：言之有数。

Adam：度量中心是研发团队的财务系统，早建设，早受益。

泽荣：只有被看到，数据才能准。

小龙：度量中心在建设的时候一定要注意要业务驱动，共同建设。

END

感谢本文观点贡献者

吴穹、熊小龙、程萃、陈泽荣

点分享

点收藏

点在看

点点赞