从3-5年前直至现在，度量的概念在IT领域持续火爆。随着业务场景愈发熵增，产品线愈发复杂，大家都想做度量，也都在做度量，但度量的效果怎么样，往往因组织而异。
其实度量本身并不是一个新的概念，自工业革命以来，我们就不断在工业领域里面应用诸如燃尽图、甘特图和看板等度量工具，来帮助我们工业生产更具标准化、信息化和规模化。
然而在IT领域、在软件开发领域，如何更好地建设度量却变成了令业界头疼的命题。
今天，我将尝试以效能作为一个系统工程出发，围绕如何在一个组织里面去开展、去落地，以及获得我们所预期的效果，来谈一谈度量这件事情，希望给关注度量领域的诸位带来一定的参考价值。
以下内容整理自：嘉为科技DevOps产品负责人 彭一宽 于 嘉为蓝鲸2022研运一体创新峰会的精彩分享——《效能的持续度量、持续分析与持续落地》。欢迎感兴趣的读者关注公众号：嘉为蓝鲸，查看演讲回放和下载演讲PPT。
01 我们度量什么
过往，我们在软件工程内已经引入了很多在工业生产环境里面已经实践过的度量方法论，诸如项目管理、精益管理等。但就大部分企业的落地效果而言，软件开发领域的度量仍旧是个极具困难性的命题。
这是由于在IT行业里面想推动度量建设，就不可忽视IT领域本身的场景独特性和业务复杂性：
- 场景独特性是指，在IT软件研发的过程中，每一个人他所做的事情实际上都是非标的，难以被标准化的；
- 业务复杂性是指，即使都是做IT，或者都是做软件研发，不同的组织、不同的企业甚至不同的产品，它所面临的业务复杂性甚至是研发流程都会存在不同。
以上2点就导致了，即使我们把目光聚焦在一个组织内部，也会发现难以找到一份统一的、一致性的、标准化的度量指标、度量体系以及度量框架。
而时至今日，IT行业的建设重点，也逐渐从对研发效能的度量转移至对组织效能的度量，也就是从工程领域逐步演进至组织效能领域。
因此，以上想要说明的观点就是，在IT领域的度量，局部优化并不等于全局优化，发现的问题也并不代表提升效能的解决方案。
当我们一个组织想要去做度量，甚至引入度量的体系和方法论的时候，我们常常会面对一个误区就是：“我需要什么样的指标，来解决我的度量问题？”
这里其实是存在矛盾点的，因为每个度量指标，它通常只是关注了问题的一个细小领域，而局部的一个问题往往并不是效能改进需要去处理的最大问题。此外，即使通过引入一组指标并从指标上发现了问题，也不代表组织就能很好地解决效能改进问题。
因此当我们尝试去建设度量时，最先做的事情并不是去引入一组业界成熟的指标，然后尽快在组织内部推动落地。一旦这样做，结果往往会适得其反。
相反，我们应该以系统工程的角度、以全局的角度出发，去寻找合适自己组织的度量方案：
- 从全局定义目标，到每个细分目标领域、每个业务场景的问题拆解。
- 从通过度量指标体系发现问题，到对问题的根因分析。
- 从知道原因是什么，再到我们找到对应的解决方案，最后进行持续地落地。
展开来讲就是，对于在组织内部落地效能度量，可以先从定义组织级的目标，然后推演到具体业务场景里面可能存在的问题。
从发现问题，到有一组指标体系可以去支持分析出问题的根因，然后再通过专家体系、知识库，甚至是一些大数据的处理方式，可以知道出现的问题，最适合什么样的解决方案。
同时，在我们组织级的效能度量体系建立起来之后，在实际的运行过程中，我们还需要关注的是：从结果性指标发现的问题，如何落到纵向的每一个细分业务场景内，如何去定位到具体的问题。
02 度量，做报时人还是造钟人
报时人和造钟人，其实是一个相对的概念。这两种角色在任何一个组织内部，甚至在任何一个业务场景里面都是存在的。
报时人更多地是告诉我们出现了问题，但是造钟人在我们度量场景里面其实是更重要的。因为造钟人代表了我们的一套体系、一套方法论、一套规则。
在任何一个组织场景内落地的时候，报时人角色会告诉目标人群、度量消费者：“我们现在指标出问题了”、“我们问题点是什么”以及“我们应该怎么样去解决”。
但是在我们做到这一步之前，更重要的是需要去建立度量的造钟人体系，也就是要建立效能的组织级体系，这其中包括了方法论、指标体系、解决方案、后续一系列跟踪闭环措施以及对应关键角色。
只有当我们建立好这样一套完整的度量造钟人体系以后，我们的度量产品才能做好一个高效的、有用的、对大家能够起到效果的报时人角色。
现如今在业界，我们也已经能看到度量的很多指标集及指标。但无论这些指标来源于国内渠道还是国外研究机构，在做计划引入前，我们都需要思考这些指标、指标集，以及它们背后的计算逻辑、计算口径以及计算模型，是否真的适用于自身的业务场景。
在引入适合自身的指标体系后，度量体系建设的节奏、步骤以及推进方式，也都会极大地影响着度量的最终落地效果。
此外，对于一个想要去引入度量的组织来说，如果引入的指标落地困难，同时不能反映我们的具体问题，那即使引入了100个、甚至是1000个指标，很有可能都无法解决在效能提升和组织改进上遇到的难题。
相反，如果组织发现一个指标就能解决自身的问题，那说明，要么组织的业务场景太简单，暂时还不需要复杂的指标体系来作体系化的呈现，要么就是组织还没定义清楚度量需要去解决的问题。
所以，在我们聊指标之前，需要先清晰定义度量的目标，确定每个具体的细分场景里面需要去解决什么问题。
这也就是前面提及的：组织度量，不如先做造钟人，再做报时人。
03 效能度量的持续性vs持续性的效能度量
为什么要聊效能度量的持续性呢？
我们有些时候会希望效能度量体系落地之后，会有一个比较快的效果能够反映出组织内部现在急需解决的问题，同时有一套方法论可以很好地闭环解决问题。
但是在实际的经验和众多的效能落地的场景中，我们会发现，效能度量能够看到效果以及能够有持续地改进的闭环，实际上是需要一个比较长期的过程。
这个过程是多久呢？短的话，可能是1-2年；长的话，3-5年都有可能。这取决于我们业务的复杂度和组织架构的复杂度。
这里希望去说明的是，其实度量这件事情，在效能提升的整个闭环中，它可能只占到很小的一部分，可能是1/4，甚至可能是更少。
因为度量本质上是不解决问题的，它实际上只提供了发现问题的线索。
只有当度量帮我们发现了线索，然后我们经过分析确定它是问题，经过后续一系列最佳实践、一系列方法论的优化和落地，做到一个持续的闭环，组织才有可能真正地去做到效能的提升。
而提升组织级效能，才是去做效能提升这件事情的核心。
那现在我们来看效能度量，其实关注点已经从研发过程扩展到了整个组织的度量，甚至拓展到了组织的资源管理、人才管理和组织的商业成功，然后也会更多地去关注基础设施、算力、人力资源和协作等成本。
同时，我们也需要更多的专家经验和数据分析的能力结合，帮助组织从指标体系里面能够更快地定义出根因，通过后面的专家经验库和数据分析，为根因提供最有效的解决方案。
那如何持续性地建设效能度量呢？
在嘉为蓝鲸，我们希望通过一套产品化的方式，去帮企业解决度量建设的一系列问题，其中包括：
- 数据的聚合和治理
- 基于数据搭建多层模型
- 基于模型快速创建指标
- 将指标高效落地和实践
- 灵活地实现校准和调优
- 规范敏捷高效地建立指标体系
在嘉为蓝鲸的DevOps度量产品里面，我们将上面所提到的数据处理、数据模型、指标模型、指标的可视化素材、指标的体系化仪表展示、上层的产品化服务，以及一套帮助企业落地到具体业务场景解决实际问题的解决方案，有机整合形成一个完整的产品，帮助企业从最底层的数据治理，到最上面的解决方案呈现和落地，能够在产品内实现高效地处理和闭环，同时也能保证良好的用户体验。
嘉为的DevOps度量产品，从组织级的数据处理能力，到组织级的效能模型建立能力，到IT研发流程中各个不同业务场景、各种不同领域的指标模型，再到上层的指标展示，以及一些针对组织特性的复杂指标的开发能力，都有非常好的支持。
经过我们的实践，嘉为的DevOps度量产品可以着实有效地帮助组织建立一套有效的度量指标体系、度量模型体系，同时帮助用户高效地去定位根因和解决问题，对于服务我们组织级的效能提升可以起到一个极大的促进作用。
今后，嘉为蓝鲸也将持续发力，致力于通过多样化的服务以及全场景的解决方案，为企业打造最有效的、最高效的效能度量实践落地效果。
如果您的企业对DevOps平台建设、效能度量建设感兴趣，欢迎联系我们，我们将为您提供专业的产品试用和产品演示等服务。
查看回放及下载PPT请关注公众号：嘉为蓝鲸
