组织级PMO如何架构？（二）

在上篇中，我们通过与PMO比较相似的敏捷教练的职能入手分析，提出了PMO应该由PGG (Program Group) + EPG (Engineering Process Group) + SQA ( Software Quarlity Assurance)这三个工作小组组成，并明确PMO应该有负责“文化建设”的相关职能。

那么上述三个小组工作应该如何协同？

三驾马车更细节的主要工作内容是什么？人员应该如何配置？

为什么PMO还要负责“工程师文化”的建设？

今天我们围绕上述问题逐一来深入探讨一下！

进入正式内容之前，先歪个楼，跟大家分享一则笔者亲身经历的小故事，那是在想当初......

发布日“奇妙夜”

笔者14年加入了一家成熟的大型互联网公司的PMO工作。那时候PMO团队开始全面负责公司用户端APP发布的项目。

当时参与APP项目的研发团队有几百人之多，涉及30余个BU，每个BU有各自的研发测试及项目经理，PMO负责整体协调。

APP的大版本发布每一个月一次，每到接近发布日的那一周，所有项目组成员包括PMO在内，都会狠狠的加上几个大班。

尤其是发布日，凌晨下班几乎是家常便饭。如果你用“你见没见过凌晨4点这个城市的样子”的励志故事来灌我鸡汤，我一定会淡淡的回答：“见过。我还见过它5678点钟的样子” -- 就好像谁还没个“打工魂”似的。

参与过发布日加班的同学应该都清楚，虽然发布日的整个工作氛围虽然是紧张的，但也是热火朝天的，跌宕起伏的，程序员们的投入与干劲儿会让你不自觉的受到感染，有点像个大“Party”。

但总有一个疑问在我脑子里挥之不去：发布日之前不是已经在UAT（仿真）环境测试几天了么，为什么发布日当天还要那么晚呢？虽然凌晨下班挺励志的，但除了能感动自己之外，早点下班回家打几局野或者陪陪老婆孩子女朋友宠物猫之类的，它不香么？

带着这个问题，我开始了发布夜的“巡楼”的工作：到不同的BU团队去看他们如何工作，如何定位和解决问题，跟有空的研发测试闲聊，于是事情渐渐有了“端倪”：

A业务线测试：“你看看，我点击到这个下单页面APP就闪退，这是什么问题？昨天的包明明还是好的呀！”

A业务线研发：“不可能！代码都是一样的！我看看”......“那个，昨天产品说着急一个功能要上，我就改了一行代码，而且跟这个功能完全没关系呀！”

……

“以前的人代码太烂了，我改动一个不相关的地方就引起崩溃了，现在好了，你试试。”

......

A业务线测试：“这个问题好了，你提交代码吧。PMO，我们要重新打个发布包，告诉其他BU在新包上继续测试吧，不好意思.....”

我通知发布工程师重新打包，突然听到暗戳戳的“声音”(也许是幻听)：

业务线测试：“看看，A业务线果然要重新打包了吧，我就说我们发现的那个'白屏 '不着急上报，这样我们就可以搭车了......你代码提交了吧，不会引入新问题吧......”

W业务线研发：“啧啧......还是老哥你有经验......你打我脸呢，我就改了一行代码......”

1~2小时以后，......

“PMO，W业务线可能需要重新打包......”

看到这里，同学们是不是都发现症结所在了。其实原因很简单：因为30多个BU的新功能都要整合在一个APP里面，共用了代码仓库（这本身没什么，问题重点在后面），发布日却没有做代码冻结（Code Freeze）。

软件研发的一般规律是：BUG数量的收敛是随着代码改动量的收敛而收敛的。所以千万不要相信程序员“我只改一行代码，肯定不会有问题”的“拍胸脯”--只要是改动，就有引入新问题的可能。发布日代码都不Freeze，代码不断变动，新BUG自然会有，那还不是改到哪儿算哪儿，发布时间就只能一切随缘了。

发现了症结所在，于是想解决方案。

团队一贯都是这么玩，一下子让他们改变习惯“硬着陆”，提前把代码仓库Lock起来，恐怕操作性不高。一开始的要求是这样的：

发布日下午5点准时打发布包，这之后的任何一次打包请求都需要提交相应的代码修改记录（commit id）

打包请求邮件要抄送所在BU的技术Leader。

因为到了发布日的晚上还有大的BUG，无论如何不是一件好事，所以除非是不得不修的BUG，发布日重新打包的次数少了很多。

另外，虽然我没有把代码仓库Lock起来，但是我会仔细查看有没有与BUG无关的代码进入，又杜绝了有业务线发现了问题也不及时上报，等着“搭车”的现象。

那么这种“药方”有用么？团队一开始将信将疑。于是我开始全员公示每一次发布完成的时间以及代码改动记录。团队很容易发现，发布夜Code改动越少，发布完成越早，于是就更加愿意遵守流程要求，发布日代码能不改就不改。看来大家都想早点下班嘛。

效果是立竿见影的。仅仅做了这个小调整，发布完成时间就有了明显的提前，基本能够在晚上11点前完成发布。发布日当天下班的小目标达成！

| 注：行文至此仅仅描述了PMO如何解决“发布完成时间不可控”这个问题的简单过程，并未从真正意义上提升项目团队效率。PMO当时对发布提出的愿景是“发布日天黑前下班”，后续还做了其他一些努力，此处先按下不表。

当时APP项目团队还有一个做的挺好的事情：会针对每一个大版本设计一个纪念徽章，参与项目的每个人发一个留作纪念。

PMO接手后持续并加强了这个传统。我们每月找专门的设计师设计有主题的系列徽章（如星座系列，传统节日系列等）提升质感，广受欢迎，甚至很多非APP项目团队的同学都来打听怎么能拿到纪念徽章。

我们会刻意的做好“保密”工作，让新的徽章在发布夜与项目组见面：按完成发布测试先后顺序领徽章，最先完成的BU可以多发10%。

于是到PMO领纪念徽章成了和发布夜的烧烤一样重要的仪式，大家乐此不疲......

发布日奇妙夜的小故事告一段落，接下来我们进入正题。

PMO三叉戟

为啥要先聊这个小故事呢？大家有没有发现，如果套用PMO三个小组的分工，我在“奇妙夜”小故事中一人分饰三角，同时扮演了PMO中PGG，EPG，SQA的角色？

怎么理解这三者之间的关系呢？

笔者认为，PMO的三个小组的关系比较像文章封面的“海神叉”：

PGG是PMO的箭头，EPG和SQA一左一右，互为辅助

PGG承担PMO的箭头职责

用大白话来说，一些重大的项目或者项目集，PMO一定要能够“吃的下”。

无论你使用的是什么方法论，说一千道一万，如果PMO在项目交付的表现上如果没有比一般BU的项目经理来的更高效，完成的更加漂亮，PMO有什么资格对于“项目管理应该如何做”指手画脚？

打铁还需自身硬，PGG必须承担PMO“尖兵”的作用。

另外，PGG在高质量完成项目的同时，还需要有能发现问题的“眼睛”。

重大的项目/项目集一定是涉及面非常广的，在这些项目执行过程中有哪些部分是项目经理/组织的痛点，有哪些部分是重复、低效甚至容易产生浪费的，PGG可以通过这些项目的实施掌握到最新的一线信息，成为PMO的“雷达”，避免PMO脱离一线。

PGG将这些问题带回PMO，形成解决方案后，在后续项目工作中加以落地实施，检验效果，将PMO的解决方案输出落地，形成推动问题改善的闭环。

发布日“奇妙夜”卡司，小G：

如果我不去巡楼，是无法发现发布夜总是拖到很晚的真正原因的，更不用说能提出行之有效的改善方案了。差点禁了发布夜大家的烧烤！

所以我说，PGG是攻城锤，PGG是破冰刀。

EPG负责PMO的核心价值输出

EPG负责PMO的核心价EPG则根据PGG发现的这些重要瓶颈问题做整理和提炼，对普遍性的问题有针对性的优化现有流程和提供相应的工具，逐一解决这些痛点问题。值输出

| 注：当然EPG也可以通过调研、深度参与项目自己观察，但如果没有PGG这个“躬身入局”的抓手，工作起来就没那么自然了，甚至于陷入被动和盲目。

犹为重要的是，这些优化的输出不是停留在纸面上，是通过PGG在实施过程以及后续项目中加以验证和推广。

EPG的输出质量如何接地气？问PGG。

这么说吧，EPG给出的方案如果连同属于一个PMO部门的PGG同学都无法认同或者很难落地的话，相信一定是方案本身出了问题，也就不用期望其他项目经理能接受；

反之，如果在重大项目/项目集能落地并取得很好的效果，那么其他的项目自然会有更多的意愿和动力来配合这些改善流程的实施，在更多的项目中来使用EPG推荐的相关流程和工具，扩大影响，进而提升整个组织效能。

发布日“奇妙夜”卡司，小E：

PMO一小步，团队一大步，能让团队在发布夜早点下班，“窝”骄傲！

所以我说，EPG是发动机，EPG是推进器。

SQA是研发效能的评价者

那如何评估研发团队项目执行的是否高效呢？就需要有专门的SQA部门，通过一些结果和过程数据的收集和呈现，来评价项目/组织效能的执行情况，用数据和事实说话。

重要的是，通过数据驱动来评价和迭代改善的方向。避免PMO及对研发流程有建议的角色（你懂的）“闭门造车”，瞎指挥。

发布日“奇妙夜”卡司，小Q：

公开，公平，公正！我们不看广告，看疗效！

所以我说，SQA是定盘星，SQA是风向标。

说完了三个小组的关系，还有一个不容忽视的部分：PMO还需要有负责“文化建设”的意识和职能。因为：

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

这个部分说虚也虚，说实也很实。今天我们先务个虚。

设计流程的时候有没有文化？本着“万无一失”的态度和抱着“快速试错，及时调整”的思路所设计出来的流程肯定完全不同的；

项目执行的时候有没有文化？本着“巡抚大人，好大的官威”的态度和抱着“团结一切可以团结的力量，把事儿做好”的思路给人的感受必然是天差地别的；

评价结果的时候有没有文化？本着“粉饰太平，你好我好大家好”的态度和抱着“实事求是，用数据说话”思路所得出的结论肯定是天差地别的......

可以说，文化建设贯穿了PMO三个小组工作的全过程。

仍拿发布日奇妙夜这个小故事举例，稍微“上纲上线”一点，PMO至少树立了“公开透明，用事实说话”的做事风格；传递了以“早点下班为荣，挨到凌晨为耻”的理念；引导项目团队以科学的方式不断优化工作模式，提升效率，提升各方的满意度。

总结一下：

通过上面的讨论，大家可以了解到PMO三个小组各自的职能特点和定位：

PGG重执行；EPG重设计；SQA重审查；三个小组互为补充，可以形成一个PDCA的闭环，让组织效率持续提升。

PMO作为一个横向部门，与众多参项目成员协作，天然的也是一个团队组织文化的承载者和传播者。

如笔者常说的，唯有正确的文化土壤才能让敏捷落地开花一样，唯有给予文化建设足够的重视，才能够让PMO三个小组力出一孔，让三叉戟“安放”在一个坚实的“握柄”上，让PMO成为研发团队的“神兵利器”。

下篇预告

（三）篇我们重点探讨了PMO三个工作小组应该如何协同。（四）篇我们将深入讨论一下PMO三个小组更细节的工作内容以及人员配置，敬请期待！