前面我们花了两篇文章的篇幅，概括的论述了一下研发PMO从结构上应该如何分组，以及这些小组的协作关系。今天我们再来探讨一下这三个小组更细节的工作内容以及人员应该如何配置。

笔者认为，研发PMO就是为了提升研发团队整体效率而存在的，其工作可以渗透到研发领域的方方面面：只要是有助于提升研发团队效率的工作，就是PMO应该关注和参与的。

这好比你对着一个刚刚开下的棋局，棋盘上有广阔空间，大有可为。但要以一个什么样的顺序落子才更有效率，才能够逐步打开局面呢？

PMO的工作开展是不是也有类似围棋“金角银边草肚皮”的口诀可以参考呢？

今天我结合自己的经验和理解，跟大家好好聊聊。

PGG是攻城锤，PGG是破冰刀

笔者认为，一定要靠PGG小组这个“攻城锤”来打开整个PMO的工作局面，其工作重点有以下几个方面：

1. 承担重点项目（项目集）的交付任务

PMO一定要首先想方设法的拿到整个研发团队最为重要的项目（项目集）的交付任务。比如，互联网公司的APP发布项目，UI改版，系统稳定性项目（比如双活 - 非围棋术语^_^），某个硬件核心产品的研发项目等等。

说句大白话，如果在项目交付的表现上，PMO没有比一般BU的项目经理来得更高效，完成的更加漂亮，那又有什么资格对于“项目管理应该如何做”指手画脚？

如果要摆脱“PMO根本不了解实际情况，净整没用的”的刻板印象，PMO就必须要“亲自下场”，与其他项目经理一样，承担项目交付的压力--是骡子是马拉出来溜溜。

有的同学可能会担心，类似这些项目一定是非常困难的，一上来这么干，是不是风险有点大呀？

诚然，选择一个低重要性和低风险的项目作为试点项目是富有诱惑力的。因为如果事情进展不好，也没有多少损失。人们甚至都可能不会注意到这种低重要性项目的失败。

但你千万不要屈从于这种诱惑。相反，我们应该选择重要性高的项目，不重要的项目无法得到公司其他人必要的关注。另外，PMO角色的引入较之原来的研发模式，势必是会带来一点变化的。如果项目不重要，人们也许就不会配合做出相应的改变。

这就好比“抗美援朝”是新中国的立国之战一样，对于PMO来说，这也是一场具有战略意义“战役”。

我说一说，你听一听，那是在想~当~初~......

抗美援朝战役难不难？是真难！

一方携二战胜利之余威，本土设施基本完整，有着世界上最强大的生产力；一方建国伊始，经过14年抗日战争加上解放战争，国内满目疮痍，百废待兴；

一方“海陆空”三军齐备，拥有世界最先进的武器和最强大的后勤保障系统，连前线士兵喝的水都可以从日本空运；一方只有陆军，武器装备“万国造就”的五花八门：最初的防空装备只有24门日式老旧高炮，入朝伊始连冬衣都无法完全满足；

一方纠集了16国联军，时不时来个“核武器”威胁；一方朝鲜人民军在美军介入后基本打残，主要战力靠志愿军“一口炒面一口雪”输出，苏联支援个飞行员作战期间都只敢用中文交流怕引起更大争端......

在态势基本是一边倒的局面下，硬是靠我志愿军的钢铁意志和精妙战术、全国人民的同心同德，把美国为首的联军打上了谈判桌，从而标志着“西方侵略者几百年来，只要在东方一个海岸上架起几尊大炮，就可霸占一个国家的时代，一去不复返了”。并借由此，让中国军队的现代化程度有了质变，初步奠定了新中国工业化的基础，换来了几十年的和平发展空间。

同样，虽说PMO通常是能够拿到高层一定授权的，但“江湖地位”不是“给”出来的，是“打”出来的。所以，不管项目面临的挑战有多大，PMO也应该调用自己全部的力量，把这个“正名之战”打好，进而为其他的工作打开局面。

万一失败了怎么办？

我想大可以学习一下当年我们国家领导人面对漂亮国时的大无畏革命精神：“输了，就当解放战争晚胜利了十年嘛”。

所以，万一不幸，没有拿到好的结果，对于PMO来说也不是世界末日。

首先，应该专业自信。如果集全部PMO之力都无法顺利完成的项目，那么其他项目经理人选也应该不会能做的更好，要相信事实自有公断；其次，好好总结。具体碰到了什么问题导致失败，如果是多数项目的普遍问题，那不正是PMO的工作方向吗？坏事变好事。

一句话，跟柯杰下，输了不丢人。下一次，卷土重来。

2. 建立和运转重点项目（项目集）相关流程

除了完成重要项目和项目集的交付任务之外，需要和EPG、SQA密切配合，建立重要项目（项目集）的流程。

首先，是有关于项目（项目集）管理的一些列规则的输出：如项目的重要等级如何划分？由什么角色批准重要项目立项/结项/终止？进入到立项/执行/完成/终止的标准是什么？如何来关注/推动相关项目的进行？等等。

其次但是尤为重要的是，将这些规则落地运转起来。

最常见的方式也没什么特别，就是定期“过堂会”：由研发团队的负责人（CTO）或者负责人参与的项目管理委员会成员来决策重点项目的立项、执行、完成或者终止。

纵使战略再宏大，终归是需要通过一系列项目去落地实现的，需要由研发团队的最高决策者参与相关项目的优先级排定，资源分配，项目重要决策等等。PMO是确保相关工作落地执行的关键角色。

Tips:

为了更加聚焦，PGG也可以将相关的项目包装成“项目集集合”的形式，分类进行，提升效率。

举些笔者曾经组织过的相关会议的例子：如与业务增长相关的"10X Program"（业务线技术Leader一并出席），与移动端用户体验相关的“Mobile Program”，与稳定性相关的“Stability Program”等等，研发团队的负责人每周都与项目Owner开“过堂会”，汇报项目进展，达成项目关键决策。

这个机制的建立和运转看似简单，其实不然。研发团队负责人能够通过这个机制，比较实时的掌握重要项目的进展，确保战略意图得以实施，不走样；PMO也可以通过这个机制，获得更强有力的支持，在与业务侧的项目经理协同时获得更大的推动力。

注：“开会”一直是项目经理的重要工作方法和基本功，对于PMO同样如此。大家讨厌的是没有决策效率低下的会，千万不要因噎废食。

3. 做好“项目管理”相关培训

蛤？我没看错吧？PGG为啥要做这个？

先声明一下，课件内容输出、课程组织可以由PMO其他角色代劳，但“讲”这个动作，笔者“墙裂”建议由PGG自己来。

客观上说，PGG负责具体的项目和项目集，是整个PMO团队离项目经理和项目成员距离最近的。于公于私由PGG来承担讲师任务比较合适。

于公：前文提到，PGG承担着把PMO的流程和工具落地的责任。无论是项目相关流程的介绍，还是对于优秀项目实践的提炼总结，包括相关工具的使用，PGG都责无旁贷（比如，Scrum的介绍，发布流程的讲解等等。）正因为PGG离项目经理和项目成员最近，也更容易用大家比较有共鸣的语汇或者案例来传达，达到更好的效果。

于私：这是提升个人影响力的好机会。以笔者的经验，大多时候，作为PMO，合作的项目经理或项目成员跟我主动说的第一句话是：“XX老师，我听过你的课......” ^_^ 有了这个基础，未来很多项目上的事情就会好办多了。

人员配置

看到这里，各位同学应该发现了，PGG简直就是个万金油，既要，也要，还要......

所以，毫无疑问，你应该把团队中项目经验最丰富，执行能力最强的同学放在这个小组，让他们冲锋陷阵，帮整个PMO打开工作局面。

EPG是发动机，EPG是推进器

PGG冲锋在前，那么承担PMO核心价值的输出的EPG小组，具体要做些什么呢？同样是三个方向。

1. 输出重点项目（项目集）相关流程

PMO是项目管理办公室，归根结底还是要以项目为本。所以EPG首先要做的，应该是项目和项目集相关流程的整理和输出。

这是需要与PGG密切配合的，借鉴PGG丰富的项目经验，充分讨论，明确与项目和项目集全生命周期相关所有流程的细节内容，支持PGG可以很好的落地重点项目（项目集）流程的建立和运转。

2. 引入高效的研发流程系统

为什么把引入高效的研发流程系统放在EPG工作这么重要的位置？其原因有二：

第一，研发流程只有内置于高效的系统之中，才能够固化。

通常意义上来说，系统或工具只能帮助你提升“重复工作”的效率，如果你做一千次同样的事情，一千个人或者同一个人每次都有不同的做法，系统是爱莫能助的。

笔者认为，在中大型组织中，流程的真正建立，只能通过系统来固化，别无他法。否则流程最终会沦为墙上的一纸空文。

那如何把握好流程建设和引入系统的节奏呢？

对于PMO来说，一个永远都适用原则就是“抓大放小”。研发流程千千万，我们抓住重要的东西，只有提纲挈领，才能做到纲举目张。

因此，笔者建议，我们可以从重要流程的局部入手，“流程建设”结合“系统引入”同步进行。

怎么理解？大家应该还记得上篇文章里“发布奇妙夜”的小故事吧？我们再拿它来举例。

话说我推行了发布日Code Freeze后，基本做到了最终发布时间可控，其实并没有真正的提升团队效率。

于是我又开始研究APP发布过程的其他瓶颈环节，其中有一个明显可以提升的点进入了我的视线。

当时APP集成测试阶段一个工作日的大致流程是这样的，上班后由发布工程师到公司后打出测试包，然后先由基础框架部门做一些测试（主要涵盖通用功能比如用户账户，积分，常用信息设置等基础信息，以及APP首屏框架和基础组件有无重大异常），如果一切正常后，再通知其他各BU取最新的包开始分业务线测试。

这个过程正常情况会持续1~2个钟头，如果测试出来有问题，那需要先把问题解决，需要的时间就更久了。

所以一般工作节奏是在基础框架部门的同学测试完成之前，其他业务线只能处于等待状态，一般下午开始才能开始工作。如果碰到有问题，那就更热闹了，沟通群里时不时都是“催更”的询问，效率极低，解决问题的同学也压力山大。

于是把可用的包打出来及时分发出去成了一个明显的瓶颈。这也是基础框架部门的一个痛点。

我让他们测试的同学花了点时间把打包及最主要的一些测试点自动化（主要看首页是否会Crash(崩溃)，一二级页面是否会白屏），先微调了一下工作方法：集成测试阶段凌晨开始打包并完成相关测试，确保上班的第一时间可以看到包含最新代码的测试包是否正常。

这样至少可以节约之前手动打包的等待时间，各业务线上午就可以开始测试工作了，即便有问题也能更早的发现去解决。后续等相关机制跑顺了之后，又增加打包的频率，每隔2个小时自动打一个测试包。包的数量自然多了，如何确保各业务线拿到他们想要的包而不造成混乱，又成了一个新的难题。

于是我跟基础框架部门的同事合作，开发了一个简单的测试包发布的小工具：就一个页面，上面就是一个个打包记录，包括：打包时间，提交记录(Commit ID)，自动测试结果(PASS/FAIL)，测试包下载链接（含测试包版本号）等简单信息。

各业务线可以各取所需，下载自己需要的包做测试。

注：页面太丑就不放图了。再次证明了自己干不好前端开发 ：（

看到这里，大家应该都明白了我是在干嘛了吧？其实就是引入持续集成(CI)，把各业务线获取测试包的方式从“推”（Push）的方式改成了“拉”（Pull）的方式，从而大大提升了灵活度：

代码更新比较频繁的业务线可以第一时间快速的拿到自己希望验证的包，更新不那么频繁的业务线也可以根据自己的节奏，不用动不动就被要求用新包来测。同时，如果基础框架有什么问题，解决的同学也可以更从容的解决问题，因为有相近可用的包可以供其他业务线使用，不至于Block大家的工作而成为“众矢之的”。

在这个小工具被广泛接受之后，我们在此基础上又针对发布日的需要做了一些功能升级：比如发布日凌晨开始把代码仓库Lock起来，发布日打包请求通过页面操作通知相关Leader及权限获取，发布日打包记录发布等等。

我们通过这种方式把之前通过线下要求的流程搬到线上，并把许多信息公开化、透明化，收到了非常好的效果。

后续PMO和运维工具的团队密切配合，进一步增加了许多功能和用户体验的优化（对我来说，最重要的是把我设计的非常Ugly的UI给换了^_^），逐步形成了后续公司的MCD(Mobile Continuous Delivery)平台，在APP开发侧把CI乃至CD的开发流程纳入到了这个平台当中，通过改变团队工作方式真正提升了研发团队的效能。

虽然大部分的产品功能都是我离开后发生的，但看着现在那么专业的系统功能，再回想一下它是从我自己用python写的一个简单的网页起步的，作为第一任“产品经理”，与有荣焉！

这个故事告一段落。

我想对于EPG来说，也可以多多借鉴“敏捷”的思想，不要一上来就大而全，小而美才更好发力。从细节的痛点入手，把流程建设和系统引入这两手都抓起来，交替进行，最终让流程真正落地。

第二，引入系统的目的是为了进行数据分析，以数据驱动流程优化，有的放矢。

引入系统是为了固化流程。固化不是僵化，固化的根本目的还是为了优化。

引入系统的另一大好处是可以将流程执行过程的数据沉淀下来，进一步分析，以数据驱动的方式优化流程，同时通过后续的数据变化验证“疗效”。

还是拿上边的发布的流程做例子，之前发布日的发布完成时间和打包次数都是通过PMO人工记录的，费时费力不说，往往还不及时。通过引入系统，由系统去记录相关信息，甚至其他的一些更精准的时间也可以纳入分析的范围（比如打包时间，基础框架自动化测试时间，各业务线发布时间等等）。通过系统的方式把线下的流程线上化，为我们评价和优化流程建立了一个相对公正客观的基线。

这部分工作建议和SQA做有效联动，互为输出输入：系统记录的相关数据可以供SQA做度量使用，SQA需要什么样的数据也可以通过相关系统提前埋点做收集。

3. 学习和内化业界先进经验

学习：

如果说PGG是PMO部门对内的“雷达”的话，那么EPG就是PMO部门对外的雷达。

EPG一定要去多了解和学习业界的先进经验以及行业发展趋势，新的技术、新的工作方法、新的工具一定会带来工作效率上的提升。只有多去了解前沿的信息，才能不故步自封，不断进步。

始终需要牢记的是，EPG一小步，团队一大步，因为团队的规模效应，看似一点点流程效率的提升被放大后，最终给团队带来的效率的提升是相当惊人的。

内化：

对于EPG来说，一定要多一点“拿来主义”，少一点“本本主义”。外部的先进经验固然要了解和学习，但更重要的是要把合适的部分内化成自己的东西。

比如大家都学过PMBOK，这是我们项目管理从业者的红宝书。但我想不会有一家公司和一个项目经理完完全全，一字不差地按照PMBOK里的内容来做管理项目。

面对市面上众多优秀的方法论和最佳实践，如果不懂得取舍，肯定会步履维艰，甚至寸步难行。所以笔者一贯认为，衡量PMO或者EPG部门的功力的就看两个字：“裁剪”。

综上，唯有EPG真正做到了不断学习和内化，才能让EPG真正成为整个研发团队的多级发动机，有不断提升的方向和可能。

人员配置

EPG的同学应该具备比较丰富的研发经验（最好是研发出身），善于学习，同时需要具备较好的产品思维。

因为EPG不单单需要设计流程，同时需要选择适合的系统和完善系统，从用户的角度去思考如何通过运营好系统来运营好流程。

比如需要比较用JIRA更好还是Teambition更合适？Redmine怎么样？如何确保大家真正把系统用起来？如果需要针对成熟系统做二次开发，怎么和对应的开发人员对接提需求？等等。

注：目前中大型组织越来越重视研发工具的自主开发，一般都有“研发效能”的团队，EPG应该跟这些团队做好对接。另外，如果EPG能够自己管理相关工具的开发技术资源那是更好，所以有研发背景和经验就格外重要了。

因为EPG负责整个PMO的核心价值输出，所以作为PMO Leader应该特别关注这个部门的工作。

SQA是定盘星，SQA是风向标

提到SQA，有同学容易把QA和QC混为一谈，认为QA就是QC团队中的“表“哥“，”表”姐：天天不测试，定期出个表......那真是把SQA这个角色看的太低了。

SQA应该是研发团队的定盘星，建立研发效能监控的基准；应该是研发团队的风向标，告诉我们是顺风顺水，还是碰到点小瓶颈......

那么SQA具体应该做些什么工作呢？我们来看看。

1. 输出项目效能信息

首当其冲，还是应当服务于项目。SQA应当与PGG，EPG密切配合，共同整理输出与项目效能相关的一切信息，包括但不限于：

项目资源地图：项目规划/已经投入的人力情况全貌及细分，对应项目重要级别的人力分布情况等

项目进展地图：项目的进展/风险情况全貌及细分，阶段分布，项目完成率等

......

一切目的是为了让团队从宏观的角度，准确掌握人力资源使用的全貌，项目进展的全貌，特别是重点项目/项目集的相关信息，方便做决策。

2. 建立合理的研发效能度量体系

SQA还有一个非常有挑战的事情，就是建立合理的研发效能度量体系。

这是一个非常有技术含量的活儿，因为研发的特殊性，大家都应该明白度量研发的工作是一件多困难的事情，我就不列举网上众多“老板”定的KPI被研发“玩儿坏”的例子了。

那么SQA如何能避免把“技术活儿”干成“体力活儿”呢？给大家两点建议。

首先，聚焦“北极星”指标

研发的整个过程比较复杂，可以度量的地方很多，很容易产生“海量指标”。但我们应该选取其中的“北极星”指标重点关注。

所谓的“北极星”指标，特指“无需解释”的，“结果性”指标。

举个例子，需求的交付周期。是指从明确的需求想法提出到发布上线的总时间。非常容易理解，也不会有什么歧义。一个需求从发布到上线包括很多个步骤，但我只看最终的结果，就是指结果性指标。这个指标与人员的关系也不大，哪怕只有1个研发，也是可衡量的。

聚焦的意思是，SQA对外输出的就是这些“北极星”指标。对内，则需要以这些“北极星”指标去做牵引，通过专业的分析“北极星”指标背后的各种过程性指标，发现可能的研发瓶颈，并做出风险提示。

其次，重度量，轻评价，看趋势

度量的目的是为了更好的管理，做出改善，所以SQA的角色在建立研发效能度量体系的大的原则之一应该注意重度量，轻评价。

比如，一个需求从提出到对外发布需要3个月，好还是不好？可能不同的团队会得出不同的结论：如果是互联网公司的软件研发团队，似乎是慢了一点，但对于一个与硬件研发团队来说似乎又是比较合理的；对于一个成熟的团队可能成绩不大理想，对于一个刚刚处于磨合阶段的团队可能并非无法接受......

所以SQA集中精力做好度量就好，评价的事情交给“真正听得到炮火”的人去做。对于研发效能来说，应该是上到CTO，下到小组长都会非常关注的事。如果他觉得需要进一步的分析或者有必要采取一些改善的动作，准备好其他的信息，沏好茶，他会来找你的。^_^

再有，我们需要关注趋势。轻评价，不是不评价：相同的衡量周期内指标是在逐渐提升呢，还是有所下降？这是非常客观和可比较的。大家可以类比一下敏捷团队的Velocity：不同的团队的Velocity可能不具备横向比较的参考性，但同一团队的Velocity的变化是很可以说明问题的。

注：研发效能度量体系是一个宏大而复杂的话题，篇幅所限，此处仅提供最核心的工作思路，后续我们有机会起个专题做深入的探讨。

通常，SQA还有一部分工作是跟进研发团队改进项（如线上故障的短期改进措施等），我把这些统统归为研发效能的范畴，故此处不做赘述。

3. 自动化！自动化！自动化！

从SQA开展工作的第一天，就需要把三个字放在脑子里。任何数据指标，任何报表，看看是不是能够通过自动的方式实现。

原因有三：

首先，“天下武功，唯快不破”。如果一个数据和报表对我有意义的话，我自然希望能够想看的时候就能够看到，方便我更及时的做调整和干预。这样的需求唯有自动化才能够满足。

其次，自动生成的数据具有更好的公开透明性，也可以去倒逼SQA提升选择指标的质量和数据质量。要不光给各位看官解释指标含义就够你喝一壶的。

最后，SQA本身也是工程师啊，工程师存在的价值不就是把重复性的劳动由系统和工具实现么？把宝贵的时间放在更有价值的事情上去，也是提升SQA角色“含金量”的内在需求，否则就真成“表哥表姐”了。

人员配置

SQA的同学应该具备比较丰富的体系化的理论知识，有比较丰富的研发经验。

人数上则应尽量精简，贵精不贵多。

小结

笔者根据自己的多年实践，把PMO三个工作小组最重要的事项分别作了一个详细的介绍。虽然所列举的 9 件事（如下表）不能覆盖所有PMO工作的所有内容，但我认为，如果真能把这些事情做扎实，并在小组间形成有效联动，研发PMO基本上就可以运转起来了。

我们最后来稍微汇总一下。

当务之急

显而易见，这一列三个小组做的其实是一件事情。

所以我一再强调这就是PMO的“立国之战”，需要调动所有的力量把这一仗打好：不仅要把项目交付完成好，同时也要在流程上和项目数据度量上做一个示范和摸底，为后续PMO的工作打开局面。

重中之重

项目是有明确起始时间的，只能作为短期目标。PMO作为长期关注组织效能的团队，目光不能仅限于此。相应的，也应该有中长期的工作方向，这也是PMO工作最为核心的部分：

PGG的这部分工作是PMO工作最有效的抓手：通过具体项目实践发现组织效能瓶颈，输出给EPG，同时接收EPG的解决方案并在后续项目中落地；

EPG提供解决效能问题的解决方案，并通过高效的系统工具加以固化，通过PGG的实施带动相关方案推广，并运用SQA的度量体系来验证结果；

SQA同时给EPG和PGG提供有效的度量数据支持，通过数据化的方式来呈现组织效能全貌，发现瓶颈和问题；

这三个角色三位一体，互为支撑，有效联动，将推动组织效能持续健康的提升。

厚积薄发

这部分工作内容看似简单，但往往被忽视。如果从PMO建立的第一天开始就有意识的积累，将为未来PMO各角色的工作提供非常大便利和支持，更好的服务于PMO的核心工作，是需要长期坚持，持续投入的重要事项。

以上，就是我认为PMO的工作开展应该遵守的“定式”，希望能给各位PMO同仁提供参考！

一家之言，贻笑大方，也欢迎各位PMO大佬斧正！

（未完待续......）

下“棋”预告

不重视文化建设的PMO没有灵魂。

讲完了PMO的三叉戟，我们千万别忘了我们还需要将这个三叉戟安放在一个坚实的“握柄”上，才能真正形成战斗力。

那么PMO应该如何参与和开展“工程师文化建设”的具体工作呢？

我们将在“如何架构研发PMO? - 完结篇”中探讨，敬请期待！

文末，放一张我家“小魔王”围棋比赛的成绩单。借此也预祝各位同学都能在PMO的工作实战中与团队一起打怪升级，共同进步！^_^