PMO组织如何架构及角色分工（一）

PMO是对应于中大型组织如何协同、达成企业长期目标的解决方案。其核心职责是提升组织效率，避免浪费。

“打铁还需自身硬”。PMO要解决大型组织协作的问题，团队自身首先应该是高效合理的。

非常自然的，“PMO自身如何架构是合理的，应该具有怎样的角色分工？”这个问题就非常自然的摆到我们面前了。

今天我们就这个问题来做个探讨。

对“PMO”的“迷思”

笔者是研发出身，做了很久的敏捷教练再转型做PMO的，PMO的实际工作时间并不是那么长。

加入到创业公司之后，有幸可以参与到PMO团队从0到1的搭建过程，对于PMO的建设才有了更多直观的体会。

一开始，笔者认为自己一直从事的“敏捷项目管理”工作与“传统项目经理”还是有一定区别的，因为敏捷教练的工作不仅仅限于“项目交付”。

所以，哪怕最开始团队只有我一个人“光杆司令”的时候，我也没有把自己的组织命名为“项目管理部”，而取了PMO这个名字。但实话实说，一开始对于PMO的定位，我的思考也并不是那么全面的。

后续随着研发团队的扩大，PMO团队本身也需要更合理的分工，对于这个问题的解法也变得紧迫起来。

另辟蹊径

之前在探讨“PMO与敏捷是否可以兼容”这个问题的时候提到，其实PMO与敏捷的工作方向从根本上一致的。所以我自然想到，能不能另辟蹊径，从敏捷教练(Scrum Master)的职责入手与PMO做个类比，看看是否能找到我们想要的答案。

我们拿Scrum来举例，Scrum Master的核心职责描述是：确保团队正确的执行Scrum 流程，Do everything can help team suceed！

负责流程这一点是非常清晰的，还有别的么？当然。

我们说Scrum Master的工作落脚点是收获“卓越的敏捷团队”，重点在“人”，并不对Scrum团队的按时交付负责，但一支总是跳票、无法按时交付的团队毫无疑问不能称之为“卓越的团队”，所以Scrum Master一定也需要关注Sprint的成功率在一个合理的范围内。

换句话说，虽然我们不追求Sprint的成功率达到100%，但也需要将成功率维持在一个合理的高位区间。

再有，一支“卓越”的敏捷团队一定是要不断提升的。正所谓“没有最好，只有更好”，这也是Scrum为什么要做Retrospetive的原因之一。

那么，Scrum Master应该怎样引导团队发现我们是做的更好还是更糟了呢？

摆事实，讲道理。一定是通过Scrum相关的过程及结果数据来“用事实说话”。

Scrum Master或者说敏捷教练的主要工作是：负责敏捷流程落地、确保团队高质量交付、通过数据驱动改善。

呼之欲出

笔者一贯认为敏捷教练是一个微型的“PMO”。在我们了解了敏捷教练的主要工作之后，先把场景切换到中大型研发团队中，再把敏捷教练的职责做个角色拆分，PMO应该如何架构的答案的就呼之欲出了。

先揭晓答案。

无论称谓如何，一个研发PMO应该由以下三个工作小组构成：PGG + EPG + SQA

我们逐一的来解释一下这三个小组的具体含义。

PGG

Program Group 翻译为：项目集小组

主要职责是承担研发领域重要的项目或者项目集经理，达成重点项目或者项目集的按时交付；

重要研发流程落地实施。

EPG

Engineering Process Group 翻译为：工程流程小组或者过程改进小组。

主要职责是提供所有研发团队必须遵守的流程和规范，并不断改善研发流程、提升研发效能。

与敏捷教练类似，EPG在这个大的前提下，同时负责提供与流程相关的工具和系统。

SQA

Software Quality Assurance 翻译为：软件质量保证小组

主要职责是通过量化的数据来呈现研发的全过程，对于研发过程的效率做出客观独立的评价；

对于发现的问题，跟踪整改情况。

注：SQA并非测试（Quarlity Control）。测试侧重于软件质量的，SQA侧重于研发流程。

以上是PMO与敏捷教练类比的结论，下面我们再从另外一个角度来理解一下PMO这三个小组的作用。

我们一再强调，“PMO核心职责是提升组织效率，避免浪费”。

那对于一个组织来说，浪费发生概率最高、低效执行伤害最大的部分是哪里？

毫无疑问，是优先级较高的重点项目或项目集。因为这些项目/项目集要么投入巨大，要么战具有很高的战略意义，低效的执行甚至失败，会造成巨大的投入成本/机会成本的浪费。

所以，重点项目和项目集的管理，肯定是需要PMO重点关注的领域之一，PGG的角色是必不可少的。

其次，重点项目和项目集的实施都是有时间阶段的。如何确保这种类型的项目/项目集持续的高效交付，在重点项目中的一些最佳实践和经验教训如何运用到其他项目当中去从而提升组织的整体效率？

显而易见，需要有合理的流程提炼能力，强大的工具支撑。EPG的作用就不容忽视了。

最后，如何科学的评价项目/项目集的实施效果，如何评价研发团队的流程是否合理、执行是否高效，研发团队效能是否得到持续优化，一定不能凭感觉。

那么通过数据方式来评价项目/项目集实施结果、还原研发流程，发现瓶颈问题，及时做出改善。SQA的设定亦是顺理成章的了。

我们从PMO核心职责也能推导出上述“PMO三驾马车”的结论。

最后，除了PGG、EPG、SQA三驾马车之外，还有一个重要的工作PMO不容忽视，那就是“文化建设”。

还是先看敏捷。几乎所有的敏捷方法在落地的时候，都会毫无例外的提及：所有的工作的开展都离不开敏捷文化的支撑，并且此类工作是贯穿和融入到整个敏捷开发活动中去的。

所以，敏捷文化建设也是敏捷教练/Scrum Master的工作重心之一。

同样的，对于研发团队的PMO，我的观点是，PMO也需要具备帮助研发团队建立“工程师文化”的职能。

总结一下，我们通过与PMO职能比较相似的敏捷教练的职能入手分析，得出了我们今天的结论，合理的PMO架构应该包括以下几个工作小组：

PGG (Program Group)，

EPG (Engineering Process Group)，

SQA ( Software Quarlity Assurance)，

以及负责“文化建设”的相关职能。

那么上述三驾马车更细节的工作内容是什么？

三个小组工作应该如何协同？各自的工作重心是什么？

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

这些问题我们会放在下次的内容里逐一展开讨论，一定让大家通通透透，明明白白！