组织内PMO职能通常包括：卓越中心（CoE），总部和地区/部门级别的战略投资组合决策支持，项目集和项目层面的规划、监控和收益实现，如以下PMO的功能架构图示意：
本文试图讨论的是，这些PMO的功能如何吸取敏捷精益的思想，推进企业的业务敏捷化、以及重塑典型行为，从而将敏捷精益融合为企业文化价值观的一部分，以产生持续和深远的影响。
1. CoE（赋能团队）
这几个问题适合自检：
-
是否提供敏捷开发流程的培训，帮助在传统方法上工作的团队快速掌握敏捷开发的理论框架和应用技能？
-
是否有敏捷教练的能力，可以影响管理层和深入团队，帮助新使用敏捷开发方式的团队提高转型成功的可能性？
-
何时该用瀑布，何时推荐使用Scrum，何时又更适合看板，PMO有没有提供指导，来帮助项目发起人和项目经理进行适合的选择？
-
在选择了敏捷开发流程的情况下，有没有一个快速启动的支持？比如帮助团队在JIRA上搭建项目和分配角色，做好Sprint计划模版和燃尽图报告模版等。
2. 投资组合管理（做正确的事）
在这个层面上，面对的利益相关人是公司和部门的高级管理人员，需要制定重大的投资决定：某个项目可能带来的回报有多丰厚，投资回报率如何，风险又如何？PMO需要收集和整理支持的数据和信息，帮助管理层做出明智的决定。
一般情况下，投资组合评审可能月度或者季度举办。PMO可以有意识地将举办评审的节拍与采用敏捷迭代的项目步调对齐。这样可以收集比较明确的交付成果进度和成本报告。针对敏捷开发项目的特点，需要帮助决策委员会更好地理解，在敏捷项目的早期，资源和成本并非花在制定详细的计划和产品设计上，而是快速验证某些技术或者产品设计的构想，从而尽可能在项目早期降低风险。
在项目和项目集识别、澄清和优先级排序管理方面，可以吸收“产品待办列表”和“用户故事”的概念。在组织中应该只有一份涌现的、排序的列表，并且列表中的条目需要以用户价值为中心的方式描述其预期的收益，以及明确接受标准。
在跨项目集和跨项目的资源管理方面，则可以吸收看板方法中“限制在制品”的概念，为了保证工作和用户价值的流动、减轻瓶颈阻碍，需要限制同时进行的项目，并且针对瓶颈资源采取措施（如设置前置缓冲区、解除干扰），确保和提高瓶颈资源的利用率。
3. 项目集管理
在组织跨团队的项目集技术实施和协作的领域，有多个规模化的敏捷实施框架可以实施，比如Scrum@Scale，LeSS，SAFe等。PMO应收集多方意见，根据组织文化偏好和团队的实际情况选择规模化框架。PMO人员可以提供这些规模化框架的引导和教练，甚至担任其中的角色。比如LeSS框架中的大型和巨型敏捷组织中的产品负责人需要助手帮助其管理跨团队的依赖项和沟通协调工作，PMO人员可以自如地处理这样的任务。
跨团队的技术交流和工作中培训，可以参照敏捷开发中“旅行者”的概念，即临时的团队成员来一边填补技能空缺，一边做知识转移，完成后再离开。
由于项目集管理需要关注交付物的产出和收益，即各个项目交付的新产品和新能力需要能够顺利融入组织的常规运营，考虑精益思想中尽量减少对最终用户无用的中间产品，传统的Train-The-Trainer活动这个环节可以考虑直接令开发团队提供资源进行培训和大规模实施的支持活动。
此外，关于PMO本身的建设，可以直接采用敏捷方式来迭代增量交付。PMO的负责人可以担任PO的角色，负责职能发展路线图，团队则以自组织的形式共同制定迭代目标和迭代待办列表。言传不如身教，PMO采用Scrum来做自身建设这一行为本身对于组织行为和文化的影响将是显著和深远的。
值得注意的是，PMO在推进组织进行敏捷转型的过程中，应不断检视：我们是为了敏捷而敏捷，还是真正收获了敏捷许诺的好处呢？组织应对市场变化而调整战略投资的方向，更加灵活和有准备了吗？项目的交付是否有稳定可预测的步调？团队成员是否更加有向心力，彼此之间更加开放、诚实，大家勇敢地分享问题不足，并且共同投入行动去改进呢？
相对而言，一些“反模式”则是我们落在敏捷的反面的警告，提示我们需要采取措施做出改变。举例来说，散乱、重复的信息平台、重新发明/过度外包提示我们组织内部的透明度不足。不受监管的老板的宠物项目，或是孤儿项目没有人知道也没有人关心，我们需要将其纳入唯一的组织集待办列表，暴露出来，与其它项目一起比较，决定是否应该继续投入资源。
小结：
PMO的敏捷精益支持包含对外和对内两个维度，在CoE、项目组合管理、项目集管理以及自身建设方面都有相关的工作。作为PMO的从业人员，分享了我的一些想法，也希望可以得到大家的反馈，共同探讨。
——作者：Suzzi Su
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/295420.html