组织提升转型中的度量 | IDCF
来源：CIO Talk作者：常红平关注本公众号回复“研发效能”可获取常红平老师《互联网研发效能方法工具落地金融行业的实践经验》回放地址~本文重点聊聊如何度量转型进程，持续改进。不会面面俱到地涉及到度量的各个维度，只专注于组织转型过程中的度量。
一、度量是什么
度量是收集反馈的一种方法。因此度量结束后，人们可以根据度量结果了解现状、预测未来趋势、决策下一步工作计划、或实施相应管理行为。度量是一个量化的过程。比如我们描述测试覆盖率时，说它高或低是根据经验来定性，说它是80%还是20%是定量。确定这个测试覆盖率的计算公式并得出具体数值的过程就是量化过程。量化过程有时需要根据某个度量标准（量化模型）来完成。例如我们在量化缺陷严重度时，可以根据业务影响范围来确定一个量化标准。各个组织使用的量化标准可以不同，但同一个组织内的量化标准需要统一。这样组织内各团队在看到表示缺陷严重度的数字时，他们的理解是保持一致的。将度量的指标量化后可以方便比较和分析。但是，虽然量化后的数字看上去更科学、更准确了，注意实际上很多量化标准本身也是一种尝试——它是否能真正反映事物的本质还有待验证，而且针对同一事物采用不同的量化标准也可能会产生截然不同的量化结果。如果不澄清量化标准而只看量化结果，甚至可能会因为对量化结果的误读而造成决策失误。比如看似简单的测试覆盖率，使用不同的量化标准，如按照代码行数计算或是测试用例数计算，可能会得出完全不同的度量结果。即使使用同一个标准，如果在量化过程中有上下文信息需要考虑的话，度量结果仍会带有一定主观性。例如我们在估算需求复杂度、评估团队成熟度时，对上下文或者量化标准的理解的不同也会造成度量结果的不同。因此，度量结果是会有误差的。我们在根据度量结果做决策前必须要认清这一点。即便如此，度量仍然是管理工作中非常重要的工具。管理大师德鲁克曾说：无度量，不管理。例如管理者可能要求度量指标必须达到某个目标，比如每人每天至少搬砖1000块儿；或者根据度量结果决策或决定某种管理行为，比如根据搬砖数量决定奖金数量。度量之后的决策和管理行为实际已经超出了度量工作本身的范畴。但是很多时候正是这些行为触发了度量工作，决定了度量的目的，所以我们还是要把它们放在一起谈。
二、度量的目的
禅宗有言：“以手指月，指并非月”。意思是说，有人用手指出月亮的方向，你就应该顺着手指去找月亮。假如把这个手指当成是月亮，那么你就不但迷失了月亮，也迷失了手指。
例如，CMMI认证等级可以在一定程度上反映一个组织的项目管理能力。但自从招投标中CMMI等级成为一个卖点甚至硬性要求后，CMMI等级这个度量结果就从一个参照物就慢慢变成了很多组织的目标。于是很多团队为了达到特定的CMMI等级，在评估过程中掺入了很多水分。结果就是他们的CMMI成熟度等级大幅提升了，但团队实际能力并没有太大变化。度量标准不能被生搬硬套、团队也不能削足适履去满足标准。在上述例子中，团队应该选取适合自己的度量体系，通过价值驱动去提升相应能力，观察团队能力所体现出的成熟度，再制定进一步的能力提升计划，如此迭代。三、度量的原则
1）度量体系中指标应是多维度的创新型工作（比如编码）的复杂度和不确定性相比标准化的工作（比如搬砖）高很多。面对如此复杂的工作，单一的KPI是不可能照顾到管理的方方面面的。对于单一的KPI，无论管理者想要什么度量结果，团队一定会想方设法满足他/她，因此管理者一定可以获得这个满意的结果，所谓“度量什么就得到什么”。所以单一的KPI会造成团队只关注这个被度量的指标，而忽略其它重要的工作。只有多维度的度量才可以让人们在复杂环境中持续动态地权衡和改进。举个例子。我们都希望缩短新功能发布周期，这也是很多组织进行敏捷转型的目的之一。但如果只度量发布速度，就有可能牺牲质量，妥协业务范围甚至业务价值。因此在敏捷项目管理中，传统的范围、时间、成本的铁三角应该被替换成下图敏捷三角。把发布时间、项目范围，和项目成本当作可以动态调整的约束关系，在客户价值和软件质量必须保证的情况下，度量所有五个要素的指标，并依据度量结果及时调整约束关系。
2）制定度量体系时要考虑ROI度量是有成本的。这个成本包括度量指标的收集、分析、和制定相应的改进计划。度量成本不应超过其引发的持续提升所带来的价值。否则，就需要调整度量指标、提升度量效率，或者降低度量频率。当然持续提升的有效性也可能需要提高，但持续提升超出了度量的讨论范畴。一个组织采用的度量指标体系要根据组织转型的不同阶段和不同特点进行动态调整，或在业界标准的基础上进行裁剪或定制。提升效率最好的方法是自动化。在技术允许的情况下，除度量数据的自动收集外，还应该尽量做到自动分析度量结果、自动触发改进动作，以提高度量的效率并降低度量的成本。当然并不是所有指标都可以做到自动化度量。那就要综合考虑对此项指标度量的ROI，根据ROI确定合适的度量频率。3）条件允许的情况下，尽量缩短度量周期度量的目的既然是提供反馈，那么反馈周期当然越短越好。因此在保证ROI最大化的情况下，应尽量将度量的周期缩短。如果能做到全自动化，度量甚至可以是实时的。当然有些指标的数据收集是有周期限制或滞后性的，但也要在可行范围内尽量缩短度量周期。4）针对团队的度量应面向团队成长，而非横向比较既然度量应该是多维度的，团队之间就很难就多个维度进行横向比较。如果为了横向比较把度量维度减少，就不可避免会产生上述“度量什么就得到什么”的问题。这不但会造成团队工作重心偏差，而且会造成团队间的不公平的、非良性的竞争，从而影响整个组织文化。我们应该把基于团队的度量和基于团队所负责的业务的度量分开。对业务指标可以横向比较，但对团队不要。有人可能会问如果用最本质的指标“价值”作为横向比较是否可以。答案依然是否。价值是一个典型的业务指标。再高效的团队如果工作在一个错误的业务方向上，也不可能有很好的价值产出。波士顿矩阵法经常被用来帮助公司优化业务组合，以保证现金流平衡。其中，业务的价值作为一个重要的指标，帮助管理者决定对各项业务进行持续投资、维持、或放弃的战略规划。但即使在波士顿矩阵法中，价值也并非唯一的指标。如决策时只关注当前价值，很可能会忽略明日之星，从而扼杀组织的创新和长期发展。
团队的价值并不能完全通过他们所产出的业务价值衡量。业务价值的高低除了受所负责团队的影响外，还受太多其它因素影响。因此对团队的度量应该避免使用价值，而应专注于能力和发布速率，通过提升团队能力和发布速率来提升他们交付业务价值的能力。但是对于一个团队随着时间的发展在多个维度上的纵向比较是非常重要的。通过纵向比较我们可以了解这个团队的成长性。尤其是对于转型中的组织，我们不应太苛求团队在初始阶段的成熟度，而应关注他们的成长速度，并激励成长最快的团队。无论团队的起点如何，那些快速迭代和成长的团队会很快成为高效团队。5）度量用于管理工作行为，胜于管理工作产出现代科学管理之父泰勒曾经做过三个著名的实验。实验证明，对于体力工作者，管理他们工作行为比管理他们的工作产出更有效。比如管理搬运工使用什么样的铁锹，每一锹铲起多重的矿石，可以有效地帮助工人提升整体工作效率。此时再加上一定的激励机制，如超过某一标准后，对额外的搬运量予以奖励，会显著提升工人的产出。但如只是单纯靠激励机制而不辅以工作行为方法的培训，大部分工人因为工作不得法，无论如何都无法完成工作目标，也就丧失了追求目标的积极性。知识工作者的管理比体力工作者的管理要复杂得多。因此，虽然对于团队的工作行为和产出都需要度量，但应管理团队行为方面的指标，并观察团队在产出方面指标的变化，然后根据产出指标的变化，调整对团队工作行为的管理，如此循环迭代。比如通过对团队用户故事和Scrum的实践执行度的度量、管理和提升、促进团队的在一个迭代周期内用户故事完成度的提升；通过对团队自动化程度的度量、管理和提升，促进团队的发布速度的提升等等。6）度量结果是绩效考评的输入之一，但不是全部度量的目的既然是反馈，我们就必须保证反馈数据的真实性。如果把度量结果和绩效评估强关联的话，团队或个人为了让度量结果好看，就有动力修饰度量结果而造成数据失真。因为创新型工作管理的复杂度和动态性，并不是所有工作都可以被精确度量的，更不用说精确地制定各种度量指标在绩效评估中所占的比重了。如果将度量结果与绩效评估强相关的话，即使使用了多维度的度量，也只会落到传统KPI式管理的陷阱中，造成团队只关注被考评的度量指标，而忽略其它指标；或者造成度量指标被局部优化、甚至被注水。这对团队文化和组织利益都是极大的伤害。举个例子。大家知道OKR（Objectives，Key Results）方法对目标的可度量性要求是非常苛刻的。但在OKR方法中，目标达成度和绩效评定、奖金分配不是挂钩的。因此团队会更关注目标达成，而不是患得患失目标达成对绩效的影响。也因为这个优点，很多公司在使用OKR代替传统KPI后，企业内部的合作文化得到了极大改善。7）对度量结果整体优化，胜于局部优化我们知道整体优化是敏捷或精益的原则之一。虽然我们对整体和局部都会进行度量，但对度量结果的管理或持续改进上，毫无疑问应该整体大于局部，即跨团队大于单个团队，团队大于个人。例如要提升团队的发布速率的话，针对一个部落或业务领域团队的度量和提升，比针对部落中每个小分队的度量和提升更有效。同理，针对团队的度量和提升也比针对个人的更有效。8）度量结果不只是为管理者服务，而是所有人在敏捷的自组织文化中，持续改进并不只是管理者的任务，而是团队所有成员的责任。因此度量工作也不应该只被管理者关心，而是所有人都要了解它、关心它、改进它。四、度量指标的分类
前面提到了工作行为和产出类指标。工作行为还可以细分为技能类行为和价值观类行为。产出还可以细分为产出(output)和成果（outcome），我们追求用最小的产出(output)来产生最大的成果（outcome）。简单起见，我们用搬砖工作举例，请自行对应到自己的研发团队。
- 技能行为指标：每批搬砖个数、搬砖姿势符合度、搬砖流程符合度
- 价值观行为指标：与工友合作度、诚信
- 产出指标：搬砖总数量、单位时间搬砖数量、砖块损坏比例、砖块摆放整齐度
- 成果指标：大厦竣工、客户满意度、对项目工程款贡献度
五、组织转型中的度量指标
在组织架构维度，可以度量组织扁平度、全功能团队构建度等。显然这些指标对个人无效。这些指标的度量方法非常容易标准化，也可以很好地管理和约束。在敏捷维度，业界有大量的指标可以参考。有些指标适合团队自组织地使用，以帮助更好地执行项目，但不适合做管理或约束。例如团队速率、吞吐量等。虽然在团队本身稳定的情况下，随着团队成熟度的提升，它们也会自然地提升，包括数量上的提升和稳定性的提高。但它们与团队成熟度无关，只对使用它们的团队有意义。有一些行为类指标可以帮助规范团队行为，比如用户故事书写规范程度、Scrum流程符合度等等。这类指标需要使用量化模型进行评估。它们对敏捷初级团队有一定借鉴指导意义，可以在转型初期帮助提升团队成熟度，但在后期对团队用处不大。还有一些产出类指标组合起来可以反映团队的成熟度。比如评估DevOps成熟度时业界普遍使用部署频率、变更前置时间、平均故障恢复时间、变更失败率四个指标（也可以加上系统可用性）。敏捷维度的指标同样对个人无效。在文化维度，可以使用的指标包括员工满意度、敬业度、价值观符合度、业务准则合规度等。在度量文化所反映出的行为时，也需要使用一些量化模型，因此要特别注意使用科学的方法避免偏见，同时根据ROI控制度量频度以免产生过度度量。在技能能力维度，对于个人或团队，可以度量的有：硬技能，如技术、敏捷、业务专业水平等；软技能，如影响力、领导力等；提升技能的行为，如学习意愿、培训和研讨会参与度等。对于组织，还可以度量组织为员工技能提升创造的环境，如导师制度执行有效性、团队技能提升制度等。在技术转型维度，可以度量现代化技术的应用度、团队所负责项目或产品的内、外部质量，包括缺陷率、技术债等等。技术转型的度量是针对项目或产品的，因此对个人不适用。
六、度量能力的构建
1）构建初始度量体系，保证度量指标的正确性在这个阶段，团队可以先采用业界通用或教练建议的度量指标。先把这个初始度量体系建立起来，并澄清指标的含义、采集方法、并保证指标数据的正确性。在此阶段，管理者必须先行明确各度量指标的含义，具备对度量结果进行分析的能力、和根据结果进行持续改进的能力。但因为团队成熟度尚且不高，除领导者外可能很多员工并不清楚度量指标的含义，也不知如何使用它们。他们看到管理者关心这些指标、可能会误认为度量都是给管理者看的，再加上担心度量结果跟绩效考核有关，有可能会造成度量结果中掺有水分。因此，作为管理者，还要跟团队澄清度量的目的、原则，具备判断度量结果真伪、保证度量结果正确性的能力。在这个阶段，这些给定的度量指标有可能不全部都适用于团队的特定情况，数据收集效率不高，度量结果可能也不好看。但只要能具备了基本的度量体系，并保证度量数据的正确性，这个阶段的目标就算达成了。2）提升度量效率和度量工作价值在这个阶段、团队会尽量将度量数据收集工作自动化、度量结果可视化，从而大幅提升度量的效率。除管理者外，更多的团队成员开始思考度量的目的，理解度量指标的含义、和度量结果反映出的问题。因此度量结果在这个阶段不只是正确的，同时开始变得对更多团队成员有意义。在此阶段，度量工作的价值开始被认真考虑。团队开始反思初始度量体系中的指标是否都对自己有意义。对于确实意义不大的指标，开始大胆质疑，并考虑把它们从自己的度量体系中剔除。随着度量效率的提升，度量的频率、ROI也在提升。随着不适用的度量指标逐步被剔除、整个度量工作会给组织转型和提升带来更大的价值。但在这个阶段团队还没有能力解决一些特殊情况或疑难杂症。3）全面地利用度量持续改进在这个阶段，团队中所有人都对各种度量指标有了清晰的理解、并能根据度量结果提出持续改进的建议。更重要的是，团队也具备了自组织地制定适合团队的度量体系的能力。每个团队成员都非常清楚、度量结果不止是给管理者看的，同时也是给自己看的。团队有强烈的意愿利用度量进行持续提升。此时如果观察团队的产出类指标，会很惊喜地发现，虽然没有硬性地去要求它们的提升，这些指标却都随着团队成熟度的提升而自然地提升了。到了这一阶段，整个组织的转型也就成功了。
七、结束语
作为反馈机制，度量在转型过程中必须贯穿始终，但是度量能力本身的构建也需要分阶段进行，它依赖于组织的转型进程，并要与组织的能力、文化相匹配。本文与组织转型系列文章的前两篇一起，系统性地介绍了传统研发组织如何转型，以打造高效团队，迎接企业数字化转型的挑战。转型之路从来都不是一帆风顺的，但固步自封只会被时代加速淘汰。希望本系列文章能给各位在转型之路上积极探索的管理者一些启发。若有未尽之处，欢迎留言讨论。转型之路没有终点。我们一起努力。
作者：常红平IT职场老兵，在做过除用户体验设计师外的所有软件研发团队中的角色后，于10年前开始专注于管理。爱技术、爱敏捷、爱读书、爱分享。现在IBM CIO中国实验室作为IBM全球软件和云服务销售系统负责人，领导IBM年交易量数百亿美金的核心系统的研发和运维工作。近年来，他还带领跨国团队成功实施了一系列敏捷转型、技术革新、和组织文化转型。拓展阅读：通过组织转型打造高效研发团队的三个步骤 | IDCF
从一线经理到全球副总裁 — 小中大型团队的组织架构设计原则 | IDCF
通过组织转型打造高效研发团队的五个维度 | IDCF
FDCC - Fundamental DevOps Capability Certification【基础认证-⽩腰带】，限时免认证费，回复“FDCC”即可申请。
评论