万字长文详解：PMO如何从0到1搭建研发效能体系（推荐收藏）

6 月 28 日， 我们的 DevData Talks 邀请到了来自妙盈科技的研发效能负责人兼 PMO 团队负责人姬俊鹏老师，线上分享《PMO 如何从0到1搭建研发效能体系》。他在直播中分享了妙盈科技搭建研发效能体系的过程、迈坑经历，以及他们在指标制定、迭代过程中总结的经验。在直播后半段，还为线上观众们答疑解惑，深度交流了在绩效管理、战略洞察与拆解、度量指标制定等方面的独到见解。

我是妙盈科技的 PMO 负责人姬俊鹏，今天分享的主题是作为PMO是如何从0到1搭建研发效能体系的，其实 PMO 来做研发效能是有不少短板的，随便举一个例子，比如我其实并不懂专门的技术，具体某一个专业它是如何工作的？会遇到什么样的问题，如何去度量它，很大程度上，我没有足够的说服力，所以这是我做研发效能体系遇到最大的一个障碍，后面我会着重分享从 PMO 的角度我是如何克服这些问题并帮助公司搭建研发效能体系的。

分享主要分四部分：

• 从 high level 的角度来谈一下我作为PMO的leader对提升研发效能的理解；

• 重点分享妙盈科技从 0 到 1 做研发体系的具体实践；

• 目前妙盈科技用到的一些比较有意思的度量指标，会展示一些图表；

• 总结与答疑

提升研发效能是在做什么？

首先大家可以和我一起思考，看到提升研发效能这几个字，你觉得它为什么会被提出来？比如你的领导找到你，提出我们需要提升这个研发效能。那从你的角度，你觉得这个出发点是什么？动机是什么？

从PMO 的角度我是这么思考的，我觉得提升研发效能的根本目标，实际上是为了实现公司的单位成本的收益最大化。换句话说就是我们一共就这么多员工，我想把这些资源投入到最有价值的事情，并且是以最高的效率去获得。这是我认为提升研发效的根本目标。

如果从这个出发点的话，怎么来定义这个研发效能呢？我想要单位成本收益最大化，那我们怎么来定义单位成本收益最大化？从我的角度认为可能有三方面比较重要，第一是我如何来定义收益？就是我工作 8 个小时，我做事件 A和做事件B，那事件A和事件 B到底谁的收益更大？

第二个是成本利用率，我到底花了多少资源在这件事情上，它在单位时间上的利用率是否足够高。第三个就是投入产出质量思考，缩短工期的话会有很高的质量风险，那我们该如何去应对这些质量风险？那针对这三块，我提出的这个思路就是收益最大化，这个提出的思路是对公司战略的洞察和分解。 

那我们的方法论是什么呢？

从 PMO 的角度，我挑了两个我认为非常关键的点，第一个是战略分析，第二个就是围绕项目的度量，因为PMO，我们来做研发效能的绩效，如何设计 KPI 其实是一个蛮大的挑战。就像我刚说的，我们对专业都不熟悉，那我们怎么来度量？其实在 PMP 的方法论当中有专门的一块，就是项目的度量。在实践当中我发现围绕项目做度量也是一个非常好的抓手。所以从 PMO 的角度，一方面是保持和公司战略同步，另一方面利用自己比较熟悉的领域提升研发效能。

妙盈研发体系搭建的挑战

（妙盈研发效能搭建过程）

过去两年我们是怎么做的？一开始要提升研发效能的时候，研发团队规模非常小，当时只有四五十人。公司的业务分为应用开发和数据开发，有数仓也有应用开发。如果单讲应用开发的话，其实人更少，那个时候可能只有一二十人。所以在这样一个组织体量下，如何做研发效能呢？盲目去照搬学习到的理论、成熟的理论框架可能会适得其反。所以当时我选择的策略是第一阶段先挑一个项目来做试点，然后围绕这个试点形成一个样板，如果这个样板它真的可行，那我们第二阶段将其推广至更多项目。

在这两个阶段有几个核心点，第一理解组织文化，最开始做研发效能的时候，更多应该思考我处在一个什么样的组织，这个组织的文化是什么样？我的资源有哪些？涉及到的相关人有哪些？比如说我的领导，我的项目团队相关的这些干系人，他们是什么样的人？性格是什么样的？擅长什么？不擅长什么？这些可能在这个阶段都需要详细分析和深入思考，进而来决定你做这个样板最终的方法。这样才能在最大的程度上保证样板是可以成功的。

第三个阶段推广样板项目实践，这个时候面临的挑战之一就是信任问题。你在别的项目成功的经验复用到新项目，别人为什么相信你？第四个阶段引入瀑布式开发，其实发现我们一开始123 阶段的时候，都是在做敏捷，样板项目也是敏捷，推广的时候是全员敏捷。随着公司的发展，研发团队在扩张，销售订单也在扩张。进而会发现单纯做敏捷的话是会遇到一些阻碍，所以我们在这个阶段引入了瀑布式开发，引入瀑布式开发其实对敏捷的环境和流程，都会形成冲击。所以这个阶段我们着重解决的问题就是敏捷和瀑布是怎么做兼容共存的，然后第五阶段形成指标框架，当我们规模到了一定体量之后，研发的规范流程都比较稳定，会有一套方法论的时候，那在这套方法论上我们如何去纵览所有细节的度量，形成我们所谓的指标框架，这一块也是比较有挑战的，需要兼容各个方向的业务，兼容各种研发的模型。然后思考如何创造一套指标框架。

第六阶段是面向端到端的度量，就是我们现在正在面临的一个阶段，在做度量的时候，发现其实度量“专业”是非常简单的，比如说度量前后端开发，或者度量测试专业，或者度量运维专业，度量产品设计这个其实非常简单，能找到很多现成的指标来做度量。但这不是我们的根本目的，如果我们过分的去度量个人的话，并不能从整个组织层面来提升研发效能，因为研发效能它并不是某个人导致的，也不是某个专业导致的，它一定是个组织的问题。所以既然是一个组织管理的问题，一定要有组织这个层面的全过程度量，也就是我们现在正在面临的端到端的度量。第六阶段就是我们妙盈科技正在做的事情，从面向专业向面向过程的一个转型。然后接下来我会详细的讲一下，这几个阶段分别做了什么事情。

拆解度量体系搭建全过程

PART.01

挑选一个试点项目

摆在我们面前的项目非常多，虽然团队只有不到20人，但实际上并发了 5、6 个项目，这5、6个项目应该怎么挑？经过分析，最终挑选了A 项目，以下是选择A项目的原因，供大家参考：

产品规划比较清晰、项目干系人少，资源独立。

创业公司有成熟稳健的产品，也有尝试性的，或者受客户影响比较大的产品。那对于我来讲，需要挑选一个规划相对清晰的项目，因为规划清晰，意味着其人员和发展预期都是比较清晰的。对于项目经理来讲就是确定性，我会希望能够找到一个最确定的项目来做过程改进。

资源独立，这个项目非常幸运的是一个独立的团队来做，如果是资源复用的情况比较多，一个人频繁切换在多个项目当中，你想去改进具体某个项目，都是有一定难度的，因为每个项目的方法论不一样。那我挑选 A项目其实就是因为它资源独立，一旦你养成了一个工作习惯，你可以一直这样保持下去。

项目干系人少，小项目的好处就是团队小，只有不到 10 个人有什么好处？可以做敏捷开发，人少就好沟通。我可以去深入的了解每一个人的性格，可以和所有的人比较顺利愉快的沟通。那这个对于推进这个改革思路是非常重要的。

公司战略上是一个重点项目，一旦是重点项目，公司是有资源倾斜的，那这个时候如果你lead这个项目比较容易争取争取资源。所以就是为什么挑重点项目，有人会觉得，重点项目是不是关注度比较高，可能会干系人比较多，层级比较 high level，改革反倒比较困难。其实不是的，如果是公司的重点项目，如果你有比较好的方法论，会更容易争取到资源。

PART.02

改进试点项目，形成样板

挑选了项目 A之后，我会去分析一下这个项目存在的问题，思考基于这些问题如何提升研发效能，因为团队比较小，产品形态也比较初期，整个研发过程非常原始且粗糙的，比如没有好的项目管理工具，当时是有 JIRA 的，但使用频率并不高，也不是很完整的在使用JIRA，只是把它当成一个记事本，用看板来做流转。从我们现在这个角度来看，肯定是远远不够的。第二，当时这个团队是在做敏捷，由于没有项目经理，就是一种团队自发的敏捷，实际情况是敏捷过程是不够完整。举一些例子，比如说没有Retro，需求规划也不足。其实敏捷开发对于需求规划的要求很高，需要有稍微比较长久的需求规划，还有需求的颗粒度，这样做敏捷的时候才会比较容易。

最后一点就是需求变更比较多，这个可能有同学会问了，敏捷不就是适应这个需求变更？其实也不完全是，对于敏捷来讲，一个 Sprint 一旦开始，它的需求是不允许变更的。这个 Sprint 假设是两周，这两周要干什么，其实我们是不能变更的，所以这个项目燃尽图就是一条直线，这肯定就不是敏捷，那我们就先来解决这个问题，正巧我是 Scrum Master，所以就带 team 来做真正的敏捷，其中比较关键的一点就是spring backlog锁定的问题，那我们锁定的这个 spring backlog，然后保持一定的需求颗粒度，再做足需求规划，它的燃尽图就会非常漂亮。当你发现这个燃尽图非常漂亮的时候，你就会发现这个 team 还是非常敏捷且研发效能非常高的。当时也很有意思，我们在这个阶段就已经和思码逸在合作了。在思码逸的平台上我们能很明显看出来，敏捷程度不够和最终我们贯彻这个敏捷的时候，它在代码当量上其实是有比较显著差异。👉👉思码逸代码当量解读

（思码逸代码当量的定义）

所以第二个阶段要解决的问题是如何改进这个试点项目。其实有一些关键点我大概总结了一下。第一个解决了需求维护的问题，之前我们的 story 写的比较乱，通过对产品经理的培训，改进需求颗粒度与描述，这个动作在研发过程当中一定程度是方便开发同学来写代码。接下来就是我们做了完整的敏捷，我们的燃尽图也变得好看，这还远远没有结束，我们发现当产品上线之后，任务类型非常多。通过进一步的约定任务类型的操作规范，一定程度提升了沟通效率。还有规划规范站会强化 sprint这个概念。同时，增加 Rerto也是非常有用的点，我们当时 Sprint 是两周，每两周都会开一个复盘会，在复盘会上，尤其是对于敏捷开发来讲，复盘会上不光会讨论过去我们做了哪些可以改进的事，还会讨论人的交流，包括工具、对项目组成员外的一些人的沟通。针对这些点的改进，也能很大程度提高研发效能，因为它让整个敏捷团队更开心，最终我们在 team 形成了一个相对比较规范的敏捷实践。

PART.03

推广样板项目实战

当形成了这个敏捷实践之后，就思考如何来把它扩大范围落地。首先我们需要扩大项目的规模，比如我们之前只是 A项目，然后现在要 10 个项目全部上敏捷，这个时候你就会遇到我前面讲的信任问题，解决这个信任的问题有两个比较核心的点：第一个你是否能跟这些新试点团队顺畅沟通；第二个是你能否有充分依据来说服大家做敏捷。当时好在我们有思码逸这个平台，有一些度量数据。那个时候我们还没有度量框架，各种各样的指标其实都没有。我们就是比较简单，比如说代码缺陷或者是代码当量这样的指标，但是通过这样基础指标也是能看得出来，做敏捷和不做敏捷存在差距。这样就可以顺理成章说服大家去尝试一种新模式。在尝试的过程中，肯定都会持有怀疑的态度。那这个时候你需要做的就是保持跟大家沟通，消除他们的顾虑，彼此建立信任。同时在这个过程当中能够看到一些收益，通过它能反向激励大家推进实践。

另外，我们落地敏捷框架，对于整个 team 的工作氛围也有提升，让大家之间关系更好，沟通更顺畅。人和人的这个距离拉近了，这些都是收益，把这些收益通过潜移默化的方式传递给项目组成员，让他们觉得我们做这个事情的确改观很多的事情。这就是一个滚雪球的过程，当越来越多的人去认可你的这个工作思路，越来越多人愿意去相信你，愿意去支持你工作的时候，这个改革工作才会越来越顺。在推广的这个过程当中，我们一方面是做了这个项目规模的扩大，另一方面也通过不断的兼容不同的项目组，其实也在扩充我们整个方法论，比如增加了很多新的任务类型，就是下面我展示的这些任务类型，典型敏捷框架里的一些任务类型。

PART.04

引入瀑布式开发

这个阶段我们面临了一些新的市场情况和项目情况，导致我们不得不引入瀑布式开发。我相信应该很多同学也都做过思考，敏捷开发它到底适用在什么样的场景，是不是所有的项目都可以做敏捷，这个问题我经常能够听到。其实我也是 Devdata talks 的忠实的听众，只要我有时间都会去关注这个直播，也听到了很多同行朋友们来讲到敏捷开发。一旦讲到敏捷开发，一定就会有人问，敏捷是否可以适配所有的项目情况。至少从我的实践就是或者我们妙盈实践当中，我们觉得敏捷开发并没有办法适应所有的项目情况。尤其是当我们做了更多国内用户之后，我们发现在国内市场环境下，如果想做真敏捷，其实还是有很大阻力的，这当中有一个比较核心的问题就是如何解决端到端交付的问题。因为敏捷开发其实它能覆盖的 scope 还是比较有限的，它向前最多延展到PO（产品设计），然后向后最多延展到DevOps。但我们如果是做 ToB 的，假设是定制化的项目，前后需要更宽的纬度，那这个时候就会发现敏捷开发在方法论上的一些瓶颈，这就导致我们不得不引入瀑布式开发。可一旦引入瀑布式开发，我们就面临一个比较大的困难，就是敏捷与瀑布的兼容问题，即项目无法又做瀑布又做敏捷。根据过往实践，我觉得可能你只能选择其一。

那做瀑布开发的时候就是很传统的 PMP 的方法论了，我们要有 WBS（工作分解结构），我们在 Jira 中也引入了一些插件来解决WBS 的问题。随着瀑布式开发和敏捷开发并行，项目体量越来越大，项目数量越来越多的时候，又会遇到一些新的问题，比如说如何拉齐这些过程。假设我有 30 个项目同时在做，有的在做瀑布，有的在做敏捷，有的是做SaaS，有的是做 ToB 交付定制化交付、私有化部署，那我们怎么来拉齐过程和方法论呢？通过实践我发现 JIRA 当中有一个比较好的抓手，就是Epic 这个任务类型。用过 JIRA 的同学比较了解 Epic 任务类型，Epic 是敏捷的概念，比如针对大需求，会把所有项目的需求全部变成Epic，对于瀑布式开发来讲，假设有 50 个Epic，那每一个 Epic 下都有 story 还有subtask，这样一种任务类型的结构就是咱们传统意义上的WBS，同时 Epic 其实也是敏捷开发的Epic。所以它就成为了衔接瀑布式开发和敏捷开发一个很重要的抓手。

第二步从 PMO 的角度，随着项目数量越来越多，肯定会涉及到项目集管理，不可能铺那么多项目经理去管这些项目，会有一些项目集的概念出来，那这个时候就演化出我们需要中心化管理这些Epic。这个是我们做项目集管理的一个很重要的基础，把所有项目的 Epic 全部中心化，放到一个 JIRA 项目里面来，然后其他所有项目都是来引用这个项目的Epic，通过这样的方式就从 PMO 的角度可以从上往下形成一个项目结构，这样也方便我们来做又有瀑布式开发，又有敏捷开发的项目情况。

随着引入瀑布式开发，就有了更大的空间，可以向前和向后做穿透。向前就有售前的工作，有需求沟通的工作，有产品设计的工作，这些是敏捷无法 cover 的部分。向后有：实施，有现场交付，有实施，有售后运维。所以在第四个阶段，通过我们不得不引入瀑布式开发，然后又不得不去总结如何去兼容敏捷开发和瀑布式开发，做了一些就是比较大的过程改进。

PART.05

形成指标框架

其实经历第四个阶段，大家就能很明显发现我们项目非常多，其实妙盈的 PMO 团队还是蛮小的，管了很多的研发项目，这个时候感觉时机也成熟了，我们既有瀑布式开发，也有敏捷开发，有 SaaS 又有私有化，看起来好像是兼容了市面上能想到的所有项目类型，那这个时候一旦你有一个方法论，能够兼容所有项目类型的时候，我们就真的到了非常成熟的机会去做度量了。当然这不代表我们之前没有做度量，其实敏捷的时候我们就做度量，我们有当量，有燃尽图，有 story point 这些其实都是度量，包括有 bug 的数量、缺陷、密度这些其实都有做度量，但它不是一个全组织的度量，直到第五个阶段时候，我们就发现这是一个非常好的机会，因为我们有一个兼容所有项目的方法论，我们可以去做整个组织级别的度量。这个阶段就会变得非常有意思。我们快速的抽样每一个专业的指标，不管你是做敏捷还是做瀑布，那你专业是跑不掉的。我们 focus 在研发，研发有前端、后端、测试、DevOps。

针对这些专业，其实不管你是做敏捷还是做瀑布，你干的活是一样的。那对这个专业的度量也是比较成熟且现成的。我们第一步就是快速上现成的指标，这个阶段我们做了大量的报表，甚至有点泛滥，我们去遍历市面上所有的方法论，去找大家通用的指标，能度量的全度量。

然后这时你会发现这么多的指标到底什么是关键指标？因为那个时候其实是非常痛的，我们有大量的数据，我们都不知道应该看什么，完全没有重点。那这个时候我就会问自己一个问题，假设一个专业只有一个指标，那我们应该选什么指标？通过对这个问题的回答，就我们形成了下面这张表格。

（妙盈指标体系）

也是当下妙盈正在使用的专业KPI。我就不一一介绍了，这里边有一些名词可能不是很通用的，比如说代码当量，这个是思码逸平台为我们提供的一个指标，因为我们长期和思码逸合作，如果是老听众的话，应该对这个指标比较熟悉的，我这里也不过多赘述。这个是我们一个非常关键的指标，大家可以看到在前后端开发这个专业当中。代码当量成了它唯一的工作量指标，这个等会我会解释，我先把这个现象说出来，还有比如说SR， SR 是我们内部定义的一个名词，其实是运维的ticket。项目交付之后还会有一些运维工作，运维的 ticket 更多我们考量的是响应效率和速度，所以会着重的关注它的处理时长。

通过这张表大家你一定会发现一个问题，真的就这么片面吗？大家也会问我这个问题就真的这么片面吗？然后我会说的确挺片面的，但这就是我们必须要做的事情，我们一定要去找到一些非常关键的指标，如果你接受了这种片面，然后你再来看这张表的话，你会发现这些指标的确蛮关键，其实就足够。但我们怎么去优化绩效考核流程，比如说我们绩效考核定成KPI，对于前后端开发来说，这其实是无效的，而且降低研发效能。所以一方面我们会降低指标类的权重，即使是做指标度量，所有指标加起来，这个分数在绩效考核的比例是非常低的，这是一方面。它背后的意义就是度量我们得承认它一定是有效的，包括它的数据展示出来，就是有人高有人低，那它一定是有意义的，你要接受这种意义。但同时我们又不能过分去强调这种度量，每一个人的工作环境都是不一样，每一个项目的情况也是不一样的，所以我们不能过分的去强调这个生硬的指标。

第二点就是我们要给 leader 充分解释权。这个在思码逸的访谈中，从 PMO 的视角，看如何从 0 到 1 搭建研发效能体系？其实我也着重强调过，因为指标是冰冷的，如果这个指标我表现的不好，你要给我充分的话语权。很多情况我们发现一个指标不好，并不一定是某一个人的问题，而是组织管理的问题，或者说它是有客观原因的，比如这个项目本身就不好做，或者这个项目需求变化很大，各种各样的原因，所以需要给 leader 充分的解释权去解释这个指标它为什么表现好，为什么表现的不好。所以在这样一种比较包容，互相理解的环境下，我们目前在推行KPI 指标的时候还是不错的，没有遇到非常大的阻力，大家也都是纷纷表示能理解。团队的氛围也还是不错的。

PART.06

从面向专业向面向过程转型

第六阶段就是我刚才提到的妙盈研发度量正处于转型阶段，我们发现不能过分强调个人的指标，或者某一个专业的指标。我们在做端到端交付的时候，首先会发现结果并不一定是由个人产生的，而一定是一个组织共同努力的一个结果；其次，单一 专业的指标表现并不一定完全是该专业的个人产生的，举一个例子，比如一个story就是一个开发任务，我们指定了一个具体的开发人员，并设置了 due date，当 delay 出现时，你会发现并不一定是这个专业它自己本身的原因，但 delay 已成为既定事实，在这种情况下，我们还要去过分的追求 delay 的比例吗？或者是把 delay 比例的数据每隔两周提出来，然后 Challenge一个专业个人，你觉得这个有意义吗？它实际上就变得好像没有什么意义了，所以这个时候我们就会发现，我们需要度量专业，但我们更多的精力应该去度量这个过程。那度量过程我们就会遇到一个问题，我既有敏捷，又有瀑布，然后又有SaaS，又有私有化交付，怎么来度量这个过程？它的开发模型都不一样，我用燃尽图，就是度量敏捷，燃尽图不可能去度量瀑布，这时我们前期完成的兼容各个项目类型的方法论就显得尤为重要了。因为我们前期形成了这个比较完整的方法论，通过演进迭代，我发现了一个度量方法，不管是瀑布还是敏捷，是私有化还是SaaS，都可以当 DevOps 来看待，就可以对过程进行度量了。下面这张表就是我们目前基于这个 DevOps 的模型应用的度量。

（妙盈DevOps 模型应用）

这就是我们妙盈在过去两年的时间经历的全过程。在这个时间线上我们的研发体量也在变大，从最开始应用开发的一二十个人，到现在我们应用开发已经有将近 100 人。公司的业务也在迅速扩张，刚开始我们可能聚焦于某一个方向，现在我们聚焦于全产业链的各个方向，这个时候遇到项目情况也在变化。随着这些情况的变化，最终是形成了目前的度量框架。

我快速总结一下，今天分享的内容其实从 PMO 角度的解读，大家可以很明显的看到里边贯穿了非常多的项目管理的思路，对技术的洞察是比较有限的，我今天讲的这个方法论还是非常偏项目管理的。这其实是我对提升研发效能从PMO 角度的一个解读。然后复盘一下整个妙盈的实践：先通过一个试点项目，通过试点样板项目的推广形成一个研发体系，然后再针对研发体系去做效能度量。现行的框架我们是分成了组织及项目级，还有团队及个人这三个层次。

总结

如果让 PMO 来做研发度量的话，我觉得项目是一个非常不错的抓手。但不同的专业来做研发度量，你的抓手一定是不一样的，所以项目并不是唯一的抓手。项目研发效能包含度量，但远不止度量，感性的认知其实更重要。我想要提醒大家的是，一旦你做研发效能的度量，有可能会陷入一个怪圈，你会 push 自己去创造很多新的指标，然后 push 自己去抽样，从指标海中去抽样一些比较关键的指标。但是不管你怎么去做指标分析，感性的认知是非常重要的。简单来讲就是一个项目的效能高不高，你在这个项目待两天你就知道了。所以我们在做度量的同时，一定要去鼓励自己去做感性的认知。

最后就是一句话送给大家，道阻且长，妙盈的研发效能做到今天远不是终点，它还有很长的路要走，而且未来的路是什么样的，其实我们都不知道，但我觉得谋事在人，没有不变的真理，变革永远在路上。