从 PMO 的视角，看如何从 0 到 1 搭建研发效能体系？_pmo+研发中心

项目的端到端交付会经历多个环节，从需求、开发、测试、集成、上线，到后续的运维、数据反馈。如果说有一个角色能对所有环节的情况胸有成竹，那可能就是 PMO 了。
我们在上一篇文章中聊到了测试工程师为什么要关注研发效能。这次关注研发效能的小逸同学对妙盈的PMO 负责人兼研发效能负责人姬俊鹏，进行了一次访谈。本期看点如下：

• PMO 应该如何择己所长推动研发效能提升？
• 如何从 0 到 1 建立研发度量体系？
• 怎样解决推行研发效能过程中遇到的矛盾？
• 怎样看待指标的波动与优化？

PMO 为什么会关注研发效能？

小逸：可能还有些人对妙盈这家公司比较陌生，请先介绍一下妙盈和您自己。
姬俊鹏：妙盈科技是亚洲领先的可持续发展技术服务商，用人工智能解决金融机构、企业、政府和个人面临的可持续发展、气候变化、碳中和社会责任方面的挑战。我们为 ESG（Environmental，Social，Governance）和碳减排（Decarbonization）整个生态产业链各个环节提供解决方案。由于我们处于一个年轻的赛道，所以对于我们来讲，不管是在研发效能还是在企业管理方面，都会遇到一些比较新的机遇和挑战。
我是妙盈的 PMO 负责人姬俊鹏，此前从事的大部分工作都是与项目管理相关的，目前主要负责妙盈的研发项目管理和过程改进。

小逸：您在妙盈是负责从 0 到 1 建立研发效能体系的。为什么研发效能体系建设的重任会放到 PMO 团队身上？PMO 在推动研发效能提升方面，有哪些优势？
姬俊鹏：PMO 是一个组织，这个组织在市面上的解释很多，有的公司是一个项目经理团队相当于项目经理的集合、有的公司是做高层级项目管理（项目集及项目组合）、有的公司是做制度流程及审计。定位不一样则体现的价值不一样吧。妙盈的 PMO 会更关注工程师，主要是负责工程师团队的项目管理及过程改进。从过去的研发效能提升来看，我们做了不少的事情。
为什么 PMO 会关注研发效能？首先是得益于 CTO 的在公司技术发展上的战略要求，我们认为度量是非常有意义的。其次我们认为提升研发能效需要有有效的载体和抓手，项目可能是一个不错的选择。而且我们考虑到，PMO 这个组织处于一个相对中立的位置，也是比较容易通观全局的部门，所以研发效能的任务就落在了 PMO 组织上。
但从另一方面，PMO 一般并不懂具体研发岗位上的技术细节，在量化和研发效能提升时对各个专业自身的管理依赖会比较大。这对整个组织的文化和团队协作有比较高的要求。

小逸：从 PMO 的视角来看，在负责整个研发效能项目时，您最开始重点要做的事情是什么？
姬俊鹏：讲到从 0 到 1 建立研发效能体系，如果单说指标框架，其实网上可以找到很多，近些年已经有很多最佳实践，比前些年要容易找到参考。不过到具体公司落地场景和实践中，我们会面临很多更实际的困难。比如在妙盈初期做研发效能时，首先遇到的问题是如何收集数据以及先量化哪些工作等比较基础的问题。这个问题给不同的角色的人，可能思路各异。由于我是 PMO 负责管理项目，所以我第一反应就是以项目管理工具为核心，制定量化方法。例如我们现在用 JIRA，我们可以在里面看到需求管理、任务管理、测试管理、CI/CD 等环节的所有数据。
当然，作为 PMO 是这样的策略，如果换成别的专业来做，肯定也有其他行之有效的方法，并没有哪个是最好的。我认为最关键的是你要明白研发效能在你的公司战略中的定位，最终的目标是什么，然后从自身专业出发，找到一套适合公司战略，又能发挥你专业所长的方法论。

从 0 到 1 建立研发效能体系

小逸：我们从个人视角转到企业的视角。您可以讲讲为什么妙盈会关注研发效能吗？
姬俊鹏：妙盈关注研发效能得益于公司研发管理的战略考虑。因为我们的研发是一个很大的团队，其中有非常多的专业。当我们面向客户交付的时候，交付的结果是比较容易被观察到的，但是交付的过程、各专业的情况通常比较难被观测。所以研发的可被观测、可被量化，是作为研发效能改进的一个前提。
比如，前些年我们的重点工作是提高项目质量，因为那段时间我们注意到线上事故的频率很高，而且经常出现严重的事故。那我们应该从哪些方面着手改进呢？妙盈的思路就是先要将这个场景量化。第一步是量化当前现状，通过使用项目管理工具，记录所有的事故，获取基础数据、分析获得对它的洞察力。这个过程使我们能够识别根本的问题。通过解决这些核心问题，我们便可以改变现状。同时，这些变化的积极影响将一定程度上反映在我们的测量系统中，形成一个正向的循环。通过对各种业务场景进行量化，获得洞察力，并实施根本性的变革，我们建立了一个持续改进的正向循环。我们的确从这套方法论中受益，所以我们才会这么关注研发度量和效能提升。

小逸：那么从 0 到 1 建设研发效能体系的过程中，如何在最开始确立指标？期间遇到过什么样的问题？
姬俊鹏：首先我们想到的就是“量化指标”的数据从哪里获取。还是拿刚才说的项目质量的例子，最开始的时候，我们没有统一的项目管理工具，那我们首先就是找一个平台将每天的事务管理起来，由于当时研发大概只有几十人，所以没有必要建立太复杂的机制。我们就想着先将这些事件都记录下来，形成统一的工作习惯。比如发生一次线上事故，我们会先看行业内有哪些最佳实践，然后仿照着对这次事故进行响应、复盘，最后提交事故报告。这整个过程都会被记录下来，统一的工具帮助我们逐步形成了一套流程机制。与此同时，数据就沉淀在了工具里。
有了这些数据积累后，我们就会开始分析，比如我们可以按季度拉取数据，从中我们就可以看出：

• 该季度发生了多少线上事故
• 这些事故的根本原因是什么
• 事故的责任人、部门是哪些
• 处理事故所用时长

我们最初做这样的研发效能度量后，发现当时绝大部分问题都是由于基础设施不够完善和不稳定引起的。有了这样的洞察，我们就能针对性地做出改进。如此经过半年多的持续改进，几轮正向的循环，妙盈整体线上 SLA 得到了很大改善。

小逸：你们是如何来制定指标的？从需求、开发、测试、运维，不同研发环节，都用了哪些指标？
姬俊鹏：提到指标的模型，行业中各家做法肯定各有千秋，我只谈我们自己的做法。由于我是 PMO 的角色，所以我会持续思考我们的研发模型是什么。我们在最初的时候研发团队比较小，所有项目均采用敏捷开发模型。后来随着业务规模和复杂性扩大，部分外部项目采用了瀑布式开发模型。这个时候，研发在不同模型下的量化指标是不一样的。比如大家讲到敏捷开发，第一时间想到的就是燃尽图，但放到瀑布模型下，燃尽图就没有什么意义了。所以根据模型的不同，我们的量化指标也会不断丰富和调整。
目前最新的情况，无论项目是敏捷还是瀑布，我们都尝试在贴合DevOps的框架。
DevOps 有几个域，从 Plan 阶段开始，我们就会进行量化，比如需求设计周期、需求评审情况等，会从 Plan 阶段开始尝试在整个生命周期下对需求做量化。
在Coding 阶段，思码逸就是我们非常核心的量化工具，其中最关键的就是代码当量、代码缺陷指标。
在 CI（持续集成） 阶段，我们会统计 CI 的时长、成功率，然后在 CI 上增加一些质量门禁。在有了质量门禁之后，CI 的通过率就可以得到量化了。
在测试阶段，会有缺陷密度、bug 类型、bug 严重程度、测试用例执行次数等这些量化指标。
在 Ops 环节中，会有针对Service Desk、线上事故、事件响应时间的度量，我们管这些叫 Ops Tickets，也是我们重点的量化的方向之一。
除此之外，SaaS线上监控的三大指标，包括success_rate, latency_p95, error_count，这些都会被量化。同时，我们也会监控各集群的资源利用率等指标。

小逸：你们对指标的产生波动是如何看待的？当你们从指标波动中发现问题后，如何推进后续优化？
姬俊鹏：肯定会有波动和变化。首先，我们有一个关键指标看板，每周都在周会上 review 一遍。我们在不同时期的关注点和侧重点会不太一样。如果有些指标的波动在当时来看是良性的，那我们就不会过多关注它。
例如在最开始的时候，我们的重点是质量的提升，那么我们每周周会会着重围绕线上事故事故响应、Root cause 做讨论，以及刚提到的 Ops 的各类指标。我们甚至还会直接打开具体的平台去看前后端的报错。
现在，我们团队更关注的是需求整体的研发效率，比如需求的健康程度、代码效率、需求响应速度等。

小逸：您刚刚提到在 Coding 环节引入了思码逸平台。那么引入后，帮您在研发效能提升方面解决了哪些问题？
姬俊鹏：其实最开始引入思码逸平台的时候，我们内部还没有研发的度量体系。这也是得益于 CTO 前瞻的判断。
很多公司都会在 Coding 阶段遇到代码该如何度量的问题。有些公司不用思码逸，那么解决这个问题的手段就很有限。他们可能就会通过计算代码行数来解决。但其实写代码的人都知道，用代码行数来度量存在很多漏洞。所以我认为思码逸做了一件很有意义的事情，让大家不用去看代码行数，通过代码当量比计算代码行数要相对更有说服力一些。同时我们还会采用思码逸平台提供的代码缺陷、测试覆盖等指标，从多个维度来评价开发提交的代码。
反观过去我们的度量历史，思码逸就是我们研发能效体系的一个树根，基于思码逸平台生长出了很多非常关键的指标。

小逸：内部来看，高层、管理者、开发者，从上到下怎么看待研发效能提升这件事？大家在此期间投入的精力如何？有哪些角色关注、参与了研发效能的提升，大家是如何分工的？
姬俊鹏：的确是不同层面的人，看待研发效能的观点很不一样。从我的观察来讲，首先我认为高层其实是非常重视这件事的，公司的运转效率始终是一个重要话题。对于研发 Lead 来讲，他们是衔接高层战略和普通员工管理的重要环节，从团队管理的角度，他们知道研发效能是非常重要的，但是另一方面也不希望这些机械化的指标影响团队的整体氛围。在妙盈，我们的研发 Lead 都很清楚，研发度量是一个管理工具，而如何使用工具，则是见仁见智。如果能利用好这个工具，其实对团队文化、团队效率、人才建设都会有正面的帮助。
从工程师层面来讲，肯定不希望有人天天来“度量”自己，会觉得压力很大。所以更多情况下，我们希望让开发同学能了解到公司实际在面临什么情况，我们开发的这个 feature 的市场背景、能给公司带来什么样的收益，从而让开发的同学能从日常工作中得到一些认同感和成就感。进一步，也可以让开发的同学理解，提升研发效能是为了让公司在市场中跑得更快更好，这才是最终的目的。

小逸：那么从业务流程、项目流程的层面来看，推进研发效能体系的时候会遇到哪些问题？你们是如何解决的？
姬俊鹏：遇到的状况还是挺多的。举几个例子吧。比如在我们推行代码当量这个指标的时候，工程师会认为它无法充分表达开发的所有工作内容，比如他们除了写代码，还需要写文档、改 bug，这些工作量是代码当量这个指标无法完全表达的。所以在做量化指标的同时，我们也会给 Leader 更多的解释权，把客观指标与主观评价结合来看。
还有比如任务延期这个指标。一个事情 delay 了，但它可能不是由于个人问题，可能是协作、客观因素等导致的。还有一些类似的指标，比如事故责任，在做事故归因的复盘时，责任人就会认为事故不是单个人的问题，很多人都有责任。
所以在遇到这些矛盾的时候，作为 PMO，我们会坚持两个基本原则：
1、坚持自己的中立性。不能偏袒任何一方，否则就会面临信用破产的问题。反过来讲，当你的中立性被大家广泛认可之后，在后续协调冲突中，解决事情的效率会越来越高。
2、维护好大家对指标的解释权。当你做了指标量化后，指标的解读在不少场景会有失控的风险。比如一个 report，技术 Lead 看过之后，认为没问题，但另一个观察者，他可能会不理解其中一些指标的异常和波动背后复杂的原因。那么这个时候对指标的解释就变得非常重要。所以我们会尽全力维护大家对指标的解释权利。即便说指标出现了异常，但你始终有机会去表达为什么出现这个异常，让各环节都能有得到充分的沟通，而不是只看表面的数字。我们量化的最终目的还是为了发现组织内部的问题、提升组织整体的管理水平，而不是为了量化而量化。

小逸：在经过这些年推动团队提升研发效能，在不同层面看取得的成效如何？
姬俊鹏：之前妙盈的研发团队比较小，那时候的确也很高效，但不是规模化的方式。现在我们的研发规模变大了，也有了比较成熟的分工结构、制度流程、度量体系、专门的报告平台，在平台上有大量的度量报表，不同报表面向不同的受众。我们完成了从小团队到规模化的转变，在转变过程中我们保持了项目质量稳定、效能持续维持在高于行业中位水平。
质量方面，我们不断提升代码质量指标的表现，比如单测覆盖、缺陷密度。线上高等级事故以前经常出现，现在已经变得非常罕见。与此同时还新增了不少质量措施，比如更复杂的静态扫描、自动化测试、各类安全测试及安全体系。
在改进质量的同时我们保持了高代码效率，周人均当量持续保持在 1500 左右。
这其中度量和基于度量的改进发挥了很重要的作用。现在回头看是很有成就感的事情。当然不同的阶段我们会面临不同的挑战，所以我们会持续迭代我们的研发管理体系以适应最新的战略要求，变革永远在路上。

拥抱 AI 带来的颠覆性变化

小逸：目前你们怎么看待 AI 工具带来的影响？
姬俊鹏：我们还处于积极尝试的阶段。我们坚信 AI 会给以后的研发带来颠覆性的变化，所以我们所有的部门都在不同的层面进行探索。

小逸：目前行业中有些团队在利用 ChatGPT 处理一些研发上的小工作。您和团队成员是否有在用？如果使用了，都是在什么样的场景上？
姬俊鹏：我们在积极地研究 ChatGPT，并且很多部门都在尝试使用它做一些工作。比如市场部会用 ChatGPT 去做一些初期的调研。当然，我们还是会对其数据可信度保持怀疑。在得到它的回答之后，再去做一次调研。实际上，ChatGPT确实提高了效率。
第二个有意思的应用点就是制度优化。比如让它评审我们的通用密码管理制度。这个制度就是规定了公司中各种密码场景的密码要求。我们会先写下来，然后让 ChatGPT 来 review，发现其中的漏洞。然后我们再根据ChatGPT提供的建议，结合公司实际情况来调整管理制度。在这方面它还是比较擅长的，可以节约一些我们寻找专家咨询的成本。
第三个在用 AI 的地方就是 Coding。我们在积极尝试各种工具，包括 ChatGPT、Cursor、Copilot 等。对于前后端工程师来讲，可能还没有完全用起来。但是对于我们一些非开发专业的人，比如我，就会利用这些工具写 Python 脚本、SQL 语句等来提升工作效率。还有就是利用它做 code review。我们可能考虑，在 CI 方面去集成一些 AI 工具。
同时我们也发现其在需求设计、单元测试、测试用例设计方面也有应用的场景，我们还在探索。
除此之外我们在云服务运维及内部工具层面也在用ChatGPT来做一些 troubleshooting 的尝试。

小结

从 0 到 1 建设研发效能体系并非易事，但不同的角色来负责这件事，都可以从自身擅长的领域找到一个根，慢慢生长出一套良性可持续改进的研发效能体系。就好像 PMO ，从擅长的项目管理本身出发，以项目的交付、质量等维度开始建立量化指标，逐步完善。在推行研发效能的过程中，会遇到很多问题。我们也可以参考他的两条原则，保持中立，以及维护团队对指标的解释权，可以在很大程度上更顺利地推进研发效能体系的建设。

———————

思码逸一站式研发效能度量分析平台，致力于帮助研发团队解决研发效率、代码质量和人才发展三大痛点，提升研发效率与软件工程质量。更多详情，可访问官网。