“5步”做好研发效能度量，打造DevOps研发管理闭环

Posted 2023-04-03 za-devops

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了“5步”做好研发效能度量，打造DevOps研发管理闭环相关的知识，希望对你有一定的参考价值。

效能度量，对于实施DevOps研发团队来说并不是一个陌生的话题。非常多的研发团队都想要通过效能度量提升研发团队的效率。关于软件研发效能度量，也有一些标准的框架，分为交付价值、交付效率、交付质量、交付成本、交付能力五个维度

研发效能度量的目标

研发效能度量的目标是为了帮助研发团队了解自身的工作效率和质量，及时发现问题并采取相应措施进行改进，以实现高效、高质量的产品交付，满足业务需求，实现业务价值。

识别瓶颈：通过度量研发过程中的关键指标，可以及时识别生产效率的瓶颈和短板，从而有针对性地对研发流程进行优化。

监控进度：研发效能度量可以帮助团队实时监控项目进度，发现问题和风险，并及时采取措施加以解决。

提高效率：通过度量工作量和工作效率，团队可以识别工作流程中的低效环节，并采取相应的措施进行优化，提高工作效率。

提高质量：通过度量产品质量和测试覆盖率等指标，可以发现产品质量问题，及时进行修复和改进，从而提高产品质量。

研发效能度量的思路和路径

那么如何进行研发团队的效能度量呢？那就围绕指标分为五大步骤展开。

确定指标：团队和企业管理者要根据项目需求和团队情况选择合适的指标进行度量。
设定目标：团队和企业管理者要共同设定目标，例如每个迭代的交付频率、产品质量指标等。
收集数据：团队和企业管理者要共同收集数据，例如每个迭代的缺陷数量、交付时间等。
分析数据：团队和企业管理者要对收集到的数据进行分析，找到问题和改进方向。
反馈和改进：团队和企业管理者要将分析结果反馈给团队成员，共同讨论改进方向并进行优化。

1、确定指标

行业内有结构化的指标体系，从需求、设计、开发、测试、发布、运维等不同的阶段，对应着不同的指标。但是需要提醒一点，搭建指标体系不是越全越好，而是要根据团队所处的不同阶段，遇到的不同问题，最主要的是想要通过指标解决哪些问题，然后进行指标的设计与体系的搭建。

效能度量可以采用多种指标，可以分为质量、效率、成本、客户满意度等方面。以下是众安常用的效能度量指标：

这些指标不是固定的，团队和企业管理者可以根据项目需求和团队情况选择合适的指标进行度量，同时也可以结合其他指标和方法进行分析和改进。

2、设定目标

设定目标一定要遵循SMART原则：

Specific（具体的）：目标应该是具体且明确的，能够清晰传达出想要达到的结果，避免模糊和含糊不清的描述。

Measurable（可衡量的）：目标应该是可衡量的，可以使用数据和指标进行可视化，跟踪进展情况，避免主观性和无法量化的目标设定。

Achievable（可达成的）：目标应该是可达成的，要考虑到实际情况和可用资源，确保目标是可实现的，并且具有挑战性和激励性。

Relevant（相关的）：目标应该是相关的，与业务需求和战略一致，能够对实现业务目标产生正面影响，避免无意义的目标设定。

Time-bound（有时间限制的）：目标应该是有时间限制的，要设定明确的截止日期和时间表，以确保目标得到及时实现和跟踪。

但是，设定目标之前，要对研发团队进行现状分析，比如：当前团队的需求平均交付周期是20天（需求从创建到上线），部门例会上研发负责人会经常被业务负责人挑战，20天太久，为什么提一个需求，需要做那么久。迫于压力，研发负责人做出承诺，要在几月份之前，将需求的平均交付周期从20天缩短到10天。这个承诺，就是为团队设定了一个明确的、有时间限制、具体可衡量的目标。

3、收集数据

收集数据有很多方法，可以通过一些工具获取指标需要的数据，也可以通过脚本直连数据库获取相应的数据。众安团队搭建效能度量驾驶舱时，通过集智BI工具拉取数据源的数据，然后经过加工处理后进行可视化配置。

4、分析数据

软件研发效能的提升是复杂的，受到诸多因素的影响，因素与结果之间存在相关关系而不是因果关系。即使我们发现两组数据之间有关联，也不意味着其中一组必然会导致另一组。例如，如果某个团队 “代码技术债率”指标很高，一般情况下代表着代码中存在的很多问题被暂时搁置，未来持续维护的成本和技术风险很大，那么从较长时间周期来看，很有可能 “交付周期”的指标会持续增长，即两组指标之间存在相关性。但这并不是必然的因果关系，虽然技术债很多，但很有可能因为人员能力、突击加班等其他因素暂时掩盖了问题，表面上冲抵了这种趋势。

但从研发效能分析的角度来看，我们仍然可以从历史数据中分析相关性，然后通过实验的方式进行探索，找到能够切实驱动效能提升的因素进行持续干预。比如，想提升线上质量、降低缺陷密度，经验告诉我们应该去加强单元测试的覆盖、完善 Code Review 机制、做好自动化测试案例的补充。但是，这真的有效么？我们通过数据来看，很可能没有任何效果！并不是说这些实践不该做，而是可能做的不到位。也许只是为了指标好看，编写缺少断言的单元测试、找熟人走过场分分钟通过的代码评审，覆盖一些非热点代码来硬凑测试覆盖率目标等等。所以，我们需要实验思维，要不断检视、反思、检讨所采用的实践，哪些实践的确有效，哪些实践效果不大，哪些实践方向正确，但因执行不到位所以效果才不及预期。我们要通过实验找到那些真正有用的改进活动及其与结果之间的相关性关系，有的放矢采取行动才会更有效率和有效果。

5、反馈和改进

效能度量不能止步于数据本身。研发管理者紧盯数据，可能导致自上而下的面子工程或教条主义，效果适得其反。

研发管理者要通过度量大盘的指标数据进行下探分析，首先对数据进行多视角的分析与解读，获取有效洞察；进而结合其他关联指标和调查方法，追问根因，定位效能瓶颈和优化机会；最终将这些洞见落地为明确、可执行、可验证的改进方案，规范研发过程、建立起良好的研发文化。

效能改进不能靠阶段性冲刺。要达到有效且可持续的效能改进，需要将度量和改进的实践融入日常研发流程，持续追踪，持续改进。

效能度量是研发效能管理闭环的关键一环。在基于数据解读制定改进方案后，需要持续度量观察效能趋势，对改进后的指标数据进一步分析解读，对改进方案的有效性做出快速反馈。若改进推进一段时间后，继续提升效果不明显，边际效应降低，这一机制也有助于团队快速判断，及时将资源投入下一个改进项。

关于反馈和改进，最推荐的是回顾会+PDCA模型。这个组合也是众安团队在工作中使用最多的。

总结

在数字化时代的大背景下，信息技术是驱动企业发展的关键，依托于DevOps提升研发效能已经成为企业的核心竞争力。坚持数据驱动，通过正确的效能度量方法，可以让研发效能可量化、可分析、可改进、可提升。

研发效能负责人/研发效能1号位｜DevOps负责人

想要做好业务，老板们除了要梳理好公司级别的业务目标，公司的组织架构，还要搭个有产出的班子，也就是找负责人、建团队，让组织架构充实起来。搭班子最重要的就是把负责人找到，就是团队1号位的人。本文主要讲团队负责人的主要作用，怎么才能找到，不同背景的优劣势，以及各方面的要求。

研发效能团队1号位

「火车跑得快，全靠车头带」。团队1号位的能力，基本上决定了这个团队的上限。所以我们在邀请1号位的时候要格外严格筛选。他除了要负责与其他部门协调、资源和预算管理、绩效考核等管理职责，作为领域专家还要胜任以下专业能力：

有大局观，有能力：能站在公司和团队的角度，根据公司战略和业务诉求，制定业务发展的长期规划和短期目标。分清轻重缓急，解决做什么的问题。
有打法：有能力规划出能达到目的地的可行的路径。解决怎么做的问题
能打仗打胜仗：业务素质过硬，能打仗且打胜仗，即按照规划目标达到目的地的能力。我自己能做。
带团队带队员：带领团队、激发团队推动业务发展，培养团队成员。我也可以带团队做。

好像没有对比就体现不出业务能力的差距，当然也看不到伤害，那就举几个1号位曾经提的问题：

- 为啥要有制品库？去掉制品库，都放到 svn 统一存多好。- nexus干嘛的？让研发自己去下载 jar包，我们就不用维护 nexus了，也就又少一事- 项目版本为啥是三位数？构建的包为啥四位版本号？能否统一用时间戳？ - 一站式研发管理平台为啥要管源代码？项目管理和源码要拆分到两个系统- 不要搞 jar包的稳定版本，线上都发快照- 你给我一些输入，我计划下团队这个季度的OKR- 为啥公司里既有 svn 还有 gitlab？为啥xx公司都用 svn 就没事？- 公司半年总结，你总结下团队半年都做了啥，我开会时用

缺少领域把控能力，团队1号位容易变成「上下两级」的传话筒。

案例分享：曾经听说过一位研发效能团队负责人，他之前从未做过研发效能工作，上级领导每次要求什么就都记下来，接着和团队下面每个人去聊。每个人聊过之后，开会讨论，然后会上让大家发言，发言时开始质疑每个人的看法。拿到结果和上级去汇报。

- 为啥是每个人？因为自己不懂，对团队下面的人又都不放心，每个人都问一遍，答案可以互相印证下。

- 为啥是开会质疑？告诉你们我懂的，别忽悠我。

- 为啥质疑团队成员后经常被怼？因为团队成员告诉他的答案是有上下文的，有侧重点考虑的。他质疑的时候往往抛弃了这些。

- 开完会，拿着团队的方案和上级领导去交差，问到细节又不懂，开会回来怼团队。

- 为啥不带着团队下面的人去开会？带着你们开会显得我多没本事。另外那是我们领导级别的会咋可能让你们去。

- 每次要把团队内的文档给领导看时，都会复制出来一个只有自己修改记录的新文档

经过几轮这样的沟通之后，下面人的脑袋都开裂了。

通常来说，作为业务1号位，要有随时可以做-2 层人员工作的能力。如果研发效能团队1号位对这个领域没有足够的认知，团队规模越大，1号位对业务的发展、对团队的发展带来的阻碍甚至是伤害也就越大。所以说业务能力是最重要的。业务1号位必须是这个领域的专家。

团队1号位的背景

领域专家非常少，找到真能独当一面的领域专家比较难，尤其是有过一线实际「操盘」经验的1号位。这个时候我们就要考虑招什么样的人来带领这个团队了，甚至来搭建这个团队。虽然都是领域专家，但是领域专家的背景也可能不同。不同背景的人可能有不同的侧重

做上层业务的可能对基础设施建设不感兴趣，毕竟这块业务投入高时间长效果慢。我看到很多之前做业务的人来做基础设施建设这块，没多久就又做业务去了。
传统运维背景的人对底层基础设施建设会比较注重，但是对业务体感低。这种情况我也见到过，对效能这块没想法，也不感兴趣；
QA背景的人，可能更关注质量，但对支持产研工作本身的平台建设和实践可能关注少
做后台开发的人会好些，但是有可能对效能不感兴趣转去做公司主营业务，另外就是把研发效能当作只是开发一个工具来看待，会做出一堆东西，但是工具不好用，用户不想用，对公司帮助有限，平台还不想改。我亲生的，怎么有可能错。
长期做管理的人可能远离一线，实操不行。

总之，我们要好好衡量，我们现在最需要补充的是哪方面的能力，而候选人的强项是哪些。如果员工和公司能同时成长，互相成就那就再好不过，如果不能，那么互相暂时拥有也挺好。员工对公司再好，公司也会开人；公司对员工再好，员工也要跳槽。单相思，始终是一种病态，最好还是互相奔赴，即便离开也互不赊欠。

团队1号位更要注重软素质

不同阶段的公司1号位的要求也许不同，但该具备的软素质始终都是要有的，比如正直、诚实、勤奋、上进、基本职场共识、自驱、靠谱

曾经遇到这样一个案例，我们有一个需求，团队评估了下大概2周左右能完成，交给一个小伙伴来做。结果这个小伙伴前前后后做了3个月没有完成。

团队初创时期，业务还不确定，风险很高，对人的要求也是最高的，但最重要的是包括人品在内的基本素质。前期招进来的每一个人都是公司春天种下去的希望的种子。每个人都是独当一面的，如果基本素质不过关，给公司带来的风险和危害也是最大。大家都尽量没有短板，能独当一面又能互相补位。

自驱也很重要。团队1号位刚进来，一片空白，百废待兴，很多时候都要自己去规划要做什么，做到什么程度，怎么做，谁来做，什么时候要有什么产出。如果团队1号位没点自驱力，那这个团队难以很快建立起来，业务也很难开展。

软素质对于每个团队成员都很重要，尤其是团队1号位就更重要了。

哪里找到这样的1 号位

打入这个圈子，找到这个圈子最好的人聊一下。没错，我们就有一个这样的「研发效能DevOps」的圈子，关注文末，猛戳我们的公众号。

本文总结

团队1号位要找到你能找到最好的那个人，基本素质要硬，人品素质硬，业务素质更要硬。既要也要又要到典型，没办法，团队1号位真的很重要。没有人品，待得越久危害越大；没有业务素质，一开始都待不下去或者只能「圆滑地」混下去，慢慢地容易把团队和业务带着向下走，甚至带没了，这样的案例太多了。