1. 为什么需要 PMO从一次失控的多项目并行说起先讲一段我自己的经历。几年前我负责一条产品线的项目交付当时公司同时跑着二十多个项目我印象最深的一次月度经营会上六个项目经理每人讲了一版进度有的按周报口径报有的按里程碑报有的干脆报“一切正常”。结果一核对实际交付物三个项目已经延了一期迭代还有一个项目的关键资源跟另一个项目撞了车两边负责人当着高管的面吵了起来。会议从上午十点开到了下午两点半全程没有形成任何一条可执行的结论。会后老板把我叫住说了一句话你去找个方法让下次开会的时候我们不用靠嘴来确认项目到底有没有问题。这就是 PMO 在我所在组织里诞生的直接原因。往后几年我陆续在几家公司参与搭建和运营 PMO从两三个人的小团队到支持上百人研发组织的中型 PMO踩过不少坑也总结出一套相对完整的职能认知。这篇内容我就是想把这些拆开讲清楚——PMO 到底是什么、它该管哪些事、不该管哪些事、落地的时候最容易死在哪里。需要先说明一点PMO 这个角色在国内很多公司里是“被需要但说不清”的状态。它不像研发、销售、财务那样职能边界天然清楚老板安排一个 PMO 负责人往往只说一句“把项目管起来”至于管哪些、怎么管、跟项目经理什么关系全得靠自己摸索。所以这篇文章适合几类人读正在搭 PMO 的组织管理者、已经做了 PMO 但对职能边界困惑的从业者、还有那些被 PMO“管着”但不知道对方到底在干嘛的项目经理。看完你会对 PMO 的运作逻辑有一个整体图景也能直接拿里面的框架去对照自己所在组织的现状。2. PMO 的底层定位不是管人的部门而是管规则和信息的枢纽2.1 PMO 与企业里其他管理角色的核心区别很多人天然把 PMO 理解为“项目管理的管理部门”于是觉得 PMO 就是来管项目经理的。这个理解偏差是很多组织把 PMO 做废的根源。我用一个类比来解释 PMO 的实际定位——机场塔台。塔台不驾驶任何一架飞机不决定飞机是空客还是波音也不负责给飞机加油和检修。塔台做的事情是建立统一的起降规则掌握每架飞机的位置和状态在出现冲突时给出优先级和调度指令。机组人员可以自己决定飞行高度层吗大部分时候可以但在拥挤的空域里必须服从塔台的统一协调否则就是事故。PMO 在企业里就是这个塔台。项目经理是机长负责具体某一架飞机能不能安全落地PMO 不替机长驾驶但它要保证空域里有规则、雷达里看得见、冲突时有人仲裁。一个 PMO 如果管到了项目经理的日常任务分配、技术方案评审、成员绩效打分它就越位了反过来一个 PMO 如果只帮项目经理收集周报、整理会议纪要它就把自己降格成了行政秘书。这里有一个非常重要的判断标准PMO 的产出应该体现在“体系”上而不是“事务”上。体系是可持续运转的规则、流程、数据、决策机制事务是一次性的支持、代办、救火。PMO 可以做事务但只能作为一种过渡不能成为常态。凡是半年后还需要 PMO 手工去催项目经理交周报的组织PMO 一定没有建立起真正的流程权威。2.2 PMO 的三个价值锚点统一、透明、赋能把 PMO 的职能全部拆开之前先记住三个词后面所有具体工作都是这三个词的展开。统一统一语言、统一流程、统一标准。这个价值容易被低估但恰恰是 PMO 最基础也最先见效的部分。我在一家公司刚接手 PMO 时各项目组对于“项目延期”的定义有好几种有的是比计划晚一天就算延期有的是晚一周才算有的是要到里程碑节点才确认延期。结果就是同一个项目项目经理跟管理层说的完全不是一回事。PMO 上线后做的第一件事不是引入什么酷炫的工具而是拉齐口径——所有项目统一以迭代版本为节奏单位延期超过三天必须进入风险清单超过一周自动触发升级。光这一个口径的统一就让月度经营会议的讨论质量上了一个台阶。透明让项目数据对相关方可见、可用、可信。PMO 手里最值钱的资产就是项目全景数据进度、成本、资源、风险、依赖。透明不是把数据贴出来给大家看而是让每个人在做决策的时候看到的都是同一套事实。项目经理决定要不要申请加人研发主管决定要不要调整资源分配高管决定要不要砍掉一个项目——如果这些决策基于的数据不一致那组织必然内耗。赋能通过方法论、工具、培训、复盘机制让项目经理和团队更有能力把项目做好。这一点很多 PMO 会忽略。PMO 如果只做监控和考核在团队眼里就是一个“找麻烦”的部门但如果能在监控之余提供培训和工具支持团队就会从抗拒变成需要。我在实践中发现三个价值锚点最好按顺序推进先统一再透明后赋能。跳过前两步直接做赋能大部分内容都会被团队当成“增加负担”推不动。3. 职能全景拆解PMO 到底做哪些事3.1 用一张表看 PMO 的职能域PMO 的职能可以拆成七个核心域。我先用一张表做总览后面再逐个展开讲。这张表也是我在内部培训时经常用的框架基本上覆盖了一个 PMO 在当前组织里能承担的全部职责范围。职能域核心产出物典型活动治理与组合管理项目清单、优先级排序、立项/结项决议主持立项评审、定期项目组合审视、资源约束下的取舍流程与方法论项目管理规范、阶段模板、评审门禁设计流程、维护模板库、培训推广、流程审计资源统筹资源日历、跨项目资源视图、冲突仲裁方案收集资源负载、组织优先级仲裁会、推动瓶颈资源释放监控与报告项目健康度仪表盘、周报/月报、风险清单收集进度数据、分析偏差、输出管理驾驶舱风险与问题管理风险登记册、升级机制、问题清单组织风险评审、处理跨项目依赖风险、升级重大阻碍复盘与知识管理复盘报告、经验库、常见问题手册组织里程碑复盘、结项复盘、提炼最佳实践人员与能力建设项目经理能力模型、培训计划、导师制方案组织项目管理培训、建设项目经理社区、开展教练辅导这七个域不是所有 PMO 都必须一开始就全覆盖。一个组织不同的发展阶段PMO 的职能重心完全不同。但把全景图摆出来有个好处——你知道自己现在做了哪些、哪些是后置的可以规划演进路线。3.2 治理与组合管理决定“做什么项目”这是 PMO 权力含金量最高的一个职能也是最容易被做得形同虚设的一个。治理的意思不是做行政审批而是参与回答“公司有限的资源应该投入到哪些项目上”。很多公司上项目的方式取决于两样东西老板拍脑袋、销售拿到的订单。结果就是项目数量远超组织实际产能每个人都在同时做三四个项目每个项目都延期每个项目的重要程度都一样。这时候 PMO 要做的第一件事是建立立项评审机制——一个项目要进入正式项目清单必须通过价值评估和资源可行性评估。我参与过的一套项目优先级评估办法使用三维打分战略价值与公司战略对齐程度、财务回报预期收益与成本比、风险水平技术风险、交付风险、依赖风险。每个项目按三维打分后落入不同区格高价值低风险的项目优先分配资源低价值高风险的项目直接不立项或暂缓。这个机制不是说 PMO 要代替老板做决策而是给决策方提供结构化的输入——拍板还是老板拍但 PMO 确保拍板时看见的是全貌。还有一个容易被忽略的动作定期做项目组合的减法。项目组合管理不只是选新项目还要定期审视存量项目砍掉那些已经没有价值或者严重偏离目标的项目。很多组织的 PMO 只做加法项目清单越来越长实际上 PMO 最重要的决策支持之一就是量化一个项目应该被终止。做减法的依据同样来自数据目标达成率、变更频繁度、资源消耗率持续恶化且没有好转趋势的项目就应该果断启动终止评审。3.3 流程与方法论把“个人打法”变成“组织能力”流程和方法论是 PMO 最容易交差也最容易翻车的职能。容易交差是因为业务部门一提“我们需要流程”PMO 就可以甩出一套几十个模板的文档包容易翻车是因为这套文档根本不会有人用。流程设计的核心原则是增加流程价值而不是增加流程负担。一个流程只有让使用者感受到收益才会被主动遵守。收益可能是更少的返工、更早的风险暴露、更顺畅的跨部门协作。如果一套流程只有约束没有收益执行率必然趋近于零。我的经验是先梳理现状再设计流程而且设计时要回答三个问题第一这个流程环节有没有人需要它的输出第二这个环节产生什么实际价值第三去掉它会不会出大问题以项目立项流程为例合理的轻量设计是四步项目负责人提交一页纸的立项申请包含目标、范围、资源估算、风险初判、PMO 做资源可行性初审、组合评审会集中评议、发布立项决议。很多组织把立项流程做成十几页的 PPT 加两轮评审加一轮高管特批项目还没启动精力已经消耗了一半。方法论建设也遵循同样的思路。我从来不建议 PMO 一上来就全员推广某个完整的项目管理方法论比如 PRINCE2 或完整的敏捷框架。方法是用来适配场景的不是用来敬仰的。PMO 要做的是建立一个“方法集市”把轻量瀑布、敏捷迭代、混合模式都变成可选装配让项目团队根据项目特征选取组合PMO 提供支撑和兜底而不是强制全家桶。3.4 资源统筹解决“人总是不够用”的伪命题资源问题在每一家快速成长的公司里都存在而且大家都觉得是“人不够”。实际情况往往不是绝对数量不足而是资源的分配和调度失效。举一个真实的例子一家公司有三位高级前端五个项目都需要他们。每个项目经理都把自己的项目定义为最高优先级都向部门负责人要这三位前端的时间。部门负责人只能按照“谁催得紧给谁”的原则分配结果五个项目通通延期三位前端还因为频繁切换上下文而严重疲惫。PMO 在资源统筹这个职能上要做三件事。第一建立跨项目的资源视图能看到每个人目前挂在哪些项目上、负载率是多少第二建立资源仲裁机制当两个以上项目争抢同一个瓶颈资源时由 PMO 组织优先级仲裁裁决依据是项目组合层面的优先级而不是谁的嗓门大第三维护一份关键资源清单盘点组织里哪些角色、哪些人是瓶颈提前规划招聘、外包、培养的应对策略。这套机制落地之后项目经理反而会觉得 PMO 有价值因为以前靠“抢人”的丛林法则现在有了规则。当然PMO 在这里面的角色要拿捏好它决定资源调度的规则但具体某个人的工作安排仍然由项目负责人和职能负责人共同确认PMO 不越俎代庖。3.5 监控、度量与报告PMO 的话语权靠数据支撑PMO 在企业里最尴尬的位置是有责任没权力老板希望它管好项目但项目经理不听它的。打破这种局面的唯一路径就是数据——当 PMO 能拿出准确、及时、有洞察的项目数据时它的意见就自然有了分量。监控体系的设计有几个关键点。指标的选取要以决策为导向。绝大多数 PMO 汇报的指标都是进度偏差、成本偏差、需求变更次数这一类传统指标。但高阶的 PMO 会围绕“管理层真正关心的三个问题”设计指标公司的战略目标在项目上有没有体现哪些项目正在风险之中资源是否被投入到正确的事情上指标宁可少而锐不能多而泛。一堆没人看的指标比没有指标更糟糕。数据采集要尽量自动化和无感化。这是很多 PMO 翻车的地方。我曾见过一个组织上线的项目管理系统需要项目助理每周手动填报几十个字段结果数据质量很差没人信。后来我们把数据源直接接到研发管理平台、财务系统和 OA 系统PMO 只负责做清洗和规则定义填报负担大幅下降数据可信度反而上来了。监控的输出必须指向行动。每个监控周期结束PMO 要能回答三个问题哪些项目要重点关注要关注的具体风险是什么建议由谁在什么时间内做出什么决策如果监控报告只是罗列“三个项目进度正常、两个项目延期”没有后续行动建议管理层看两眼就扔了PMO 的价值感就无从谈起。3.6 风险、问题与变更管理PMO 的“守门员”角色项目风险管理制度设计得再漂亮如果只停留在“每个项目填一张风险登记表”那跟没有差不多。PMO 在风险上真正有价值的动作是两件事跨项目风险拉通和风险升级机制。跨项目风险拉通解决的是单项目看不见的问题。比如两个项目各自跟同一个第三方供应商合作供应商产能有限单个项目的风险清单上都看不到问题但是在 PMO 的跨项目视图里就能发现这是一个潜在瓶颈。这就是 PMO 作为“雷达”的价值。风险升级机制解决的是“发现问题没人拍板”的问题。我在设计升级机制时把风险分成三个等级L1 风险在项目团队内部即可消化每周在项目例会上同步即可L2 风险需要 PMO 协调或跨项目协作必须在 48 小时内上报到 PMOL3 风险影响战略目标或重大客户交付需要管理层决策PMO 须在当天升级并组织专项会议。等级不是以风险金额一刀切而是“影响范围 失控可能性”的二维判断。这个机制特别重要的一个设计原则是升级不是追责而是寻求决策。如果项目团队预期升级会挨骂风险就会被压在底下直到爆雷。变更管理同样是 PMO 的守门职能。范围蔓延是项目延期的第一大杀手。我见过太多项目需求方临时加一个“小功能”项目经理碍于关系不好意思拒绝结果三个“小功能”下来一个迭代的容量超了百分之五十。PMO 的角色就是当“不说人情话的守门员”任何范围变更必须走正式评估流程评估对工期、成本、质量的影响由项目发起人或变更控制委员会决策。流程本身很简单难的是 PMO 愿意站出来说“不”并且能拿到高层的授权来支撑这个“不”。3.7 复盘与知识管理把项目经验变成组织资产绝大多数公司的项目复盘就是走形式结项了开个会项目经理做一份 PPT说几个成功点和不足然后大家鼓掌散会下个项目继续踩同样的坑。PMO 在复盘上要做的是把复盘变成有产出的机制而不是一项任务。我自己坚持的复盘方法有三种里程碑复盘、结项复盘、专项复盘。里程碑复盘在项目关键节点做聚焦纠偏比如迭代交付后两周内复盘“这一迭代我们做对了什么、做错了什么、下个迭代改什么”产出是一份不超过一页的行动清单。结项复盘聚焦提炼分四个维度目标达成情况、过程效率、团队协作、客户反馈产出是经验卡片和可复用清单。专项复盘是在发生重大事故或重大成功后随时启动的比如“某项目上线事故复盘”要纪律严明地做根因分析产出是行动项和责任人。知识管理的载体不需要复杂一个轻量的经验库就够了。我使用过最简单的模式是在项目管理工具里建一个“复盘知识库”列表每条经验打上标签包括阶段、业务线、角色。新项目启动时PMO 可以按项目特征推送相关的历史经验。这个动作看起来不起眼但对新项目经理尤其有帮助——他们不用从零开始摸索组织里的隐性规则。4. 职能落地的现实阻力PMO 最容易踩死的五个坑4.1 坑一PMO 被当成“行政秘书处”这是最常见的退化路径。很多 PMO 成立的时候信誓旦旦要“提升组织级项目管理能力”结果两个月后就在做这些事催周报、汇总 PPT、安排会议、记录纪要。PMO 变成了一个高级行政岗位。我记得在一家互联网公司见过一个 PMO团队五个人每周的工作就是找各个项目经理收周报然后帮老板做一份加了项目状态标注的 PPT。项目要延期了PMO 知道为什么延期不知道。需要什么资源能恢复不知道。高层收到的信息仍然不完整只是多了一层传声筒。为什么会这样因为做规则设计、做数据分析、做资源统筹这些工作需要 PMO 既懂业务又懂项目还需要组织授权早期做起来又慢又容易碰壁。相比之下收周报、整理文档这些事情马上就能干也不会得罪人。但越是这样PMO 在组织里的定位就越固化最后变成老板眼里的“鸡肋”。破法只有一个从需求侧反推工作。跟管理层深聊一次搞清楚他们做项目决策时最痛的是什么然后集中火力解决这一个问题。哪怕只是帮管理层解决“下一季度的资源投入优先级”这一个问题都比做一百页周报汇总有价值。4.2 坑二PMO 与项目经理的权责边界模糊PMO 和项目经理之间如果没有清晰的边界就会发生两种内耗一是重复管理PMO 对项目的干预越来越深项目经理觉得被架空二是互相推诿项目出了问题PMO 说“我们只提供方法执行是项目经理的事”项目经理说“PMO 要求我们这么做才出问题的”。我的经验是用一个“三清单”把边界划清楚PMO 必须审批的事项清单、PMO 只需知悉的事项清单、PMO 不参与的事项清单。必须审批的事情包括项目立项、结项、重大变更成本或进度影响超过 20%、风险升级。只需知悉的包括项目周报、常规迭代计划、人员请假/调整、项目内部风险管理。PMO 不参与的事项包括技术方案选型、代码实现细节、团队内部日常管理、具体人员绩效评定。这份清单不是 PMO 单方面定的而是跟项目经理代表、职能负责人包括高管一起共创经过正式发布。边界不是一成不变的尤其在项目出现重大健康度问题的时候PMO 要有“干预权”——进入项目组做诊断、推动专项改进、甚至建议更换项目经理。但干预权必须是例外机制而非常态授权要有明确的启动条件不能变成 PMO 随时想插手就能插手。4.3 坑三数据收集变成团队额外负担PMO 上线监控体系团队最反感的就是“又要填表了”。一旦 PMO 的数据收集动作被团队感知为负担数据质量就会下降而数据质量下降又会倒逼 PMO 加强检查形成恶性循环。我踩过这个坑。早期我们设计了一个项目健康度自评表要求项目经理每周填十二个字段包括需求变更数、缺陷数、团队士气、干系人满意度这些很难量化的东西。结果填了三周项目经理就开始糊弄士气永远打八分满意度永远正常数据完全失真整个仪表盘成了摆设。后来我们做了调整核心是四句话能系统取数的不人工填写能自动计算的不手动评估填了就要用用了就要反馈。系统自动能取的进度偏差、需求变更数、缺陷量这些直接从工具里拉“团队士气”这种主观指标改成一个月评一次作为参考维度而不是考核维度每次看板更新后 PMO 要有反馈动作——比如风险清单更新后的 24 小时内必须有人跟进让项目经理知道填出去的数据产生了影响。这样数据填报就从“为 PMO 打工”变成了“为自己的项目暴露问题”动力完全不同。4.4 坑四流程设计过于理想化流程和方法论推不下去很多时候不是因为团队抗拒流程而是流程本身就设计得不合理。PMO 最容易犯的毛病是坐在办公室里把流程画得完美闭环完全没考虑组织的实际情况。我记得一个典型的案例PMO 设计了详细的变更管理流程要求任何变更必须经过三轮审批包括项目发起人、职能负责人、PMO。流程发布后实际执行率不到三分之一因为大多数变更是小变更——文案调整、UI 细节、字段样式走三轮审批反而拉长了交付周期。团队干脆在小范围变通PMO 发现了只能睁一只眼闭一只眼规则的权威性就没了。设计流程的时候一定要做“场景测试”把流程草案拿给一线项目经理看请他们指出哪些环节是负担、哪些环节是冗余、哪些环节会卡住。然后按“多数场景最大化顺畅、例外场景用例外通道”的原则调整。小变更做备案制而不是审批制大变更才走重流程。流程发布后还要设置一个“容错观察期”三个月内不做强制审计只收集反馈、快速迭代流程本身。4.5 坑五汇报线设计与授权不匹配PMO 的职能能否落地很大程度上取决于它在组织结构里的位置。我见过不合理的设置PMO 挂在总裁办下面做行政支持老板的意思是“先试行一段”结果 PMO 推动任何流程改革都需要求人办事也见过放在研发部门下面做内部质量管理的结果跨部门的项目完全推不动因为其他部门不认这个“研发部门的 PMO”。合理的设计通常是PMO 应该有独立于具体业务部门的组织位置并且直接向有项目组合决策权的高管汇报。这样它才能扮演跨部门规则的制定者和仲裁者。PMO 的汇报对象如果是分管副总裁或 CEO而不是某个业务部门的负责人推动立项目、资源仲裁、跨部门协调时才有底气。但要注意汇报线高不等于权力无限大。PMO 拿到高层的授权之后更要谨慎使用不能动不动就“老板说的”“高管要求”。真正有效的做法是把规则说清楚、把数据摆出来让业务部门自己得出结论而不是靠职位压人。PMO 最怕的是变成“狐假虎威”的角色——看起来有高层背书实际上离了背书啥也推不动。5. 从职能到体系PMO 建设的三个阶段与成功判断5.1 阶段一建立秩序快速见效PMO 成立的前六个月目标不是做全套职能而是建立最基本的秩序让相关方感知到 PMO 的存在价值。这个阶段我建议只做三件事。第一件统一项目清单。把全公司所有在跑的项目收拢到一个清单里每一个项目都有明确的项目经理、业务负责人、关键里程碑、整体状态没有“隐形项目”。这个动作听起来简单但经常要花两个月才能做完因为很多业务部门对“把项目纳入统一管理”是有抵触的。第二件统一汇报口径。所有项目用同一套模板、同一个节奏汇报进度和风险消灭“信息神话”。第三件统一立项和结项两个关键节点的流程。不用所有流程都上只抓这两个节点因为这两个节点最容易产生混乱和无序增长。阶段一的成功标志很简单管理层能在一个小时的项目评审会里把项目组合的整体状况看明白项目经理知道找谁去解决跨项目的问题。只要能达到这两点PMO 就算站住脚了。5.2 阶段二形成数据资产支撑决策六个月到一年半这个阶段PMO 的核心任务是把经验变成数据把数据变成洞察。这个阶段要推进三件事建立项目度量指标体系形成月度项目健康度评审机制初步建成资源池视图。度量体系从最刚需的三类开始进度类进度偏差、里程碑达成率、资源类负载率、瓶颈资源饱和度、变更类需求变更率、范围蔓延指数。不要一开始就上二十个指标每周在仪表盘上能看到这三个维度就已经比大多数组织强了。月度健康度评审是这个阶段的标志性机制。每个月 PMO 组织一次项目组合层面的评审会每个项目用红黄绿三色标注健康度红色项目由项目经理专项汇报PMO 提供数据支撑和问题预警。这个会议是 PMO 从“幕后的信息整理者”走向“前台的决策支撑者”的关键一跃。而健康度评审结束之后PMO 要主动把红色项目的资源问题、依赖问题推送到对应的职能负责人面前而不是等着项目经理自己想办法。5.3 阶段三驱动组织级改进一年半到两年之后PMO 如果还在做跟阶段二一样的事情那就说明它在原地踏步。阶段三的核心目标是从“发现项目的问题”走向“改进组织的问题”。组织级的问题通常不是单个项目能解决的比如新项目立项的时候总是缺少充分的价值论证比如跨部门的依赖协调成本太高比如关键角色能力跟不上扩张速度。这些问题反复出现在多个项目里PMO 就有责任把它们提炼出来推动组织层面做专项改进。这个阶段 PMO 会涉及一些前瞻性的工作建立项目成功率的预测模型基于历史数据判断哪些项目大概率延期推动研发效能度量定位交付瓶颈是在需求、开发还是测试环节搭建项目管理人才培养体系让更多的项目经理达到组织需要的成熟度。这些动作已经远超“管项目”的范畴而是真正的组织能力建设。5.4 怎么判断 PMO 做得好不好很多组织评估 PMO 用的是“流程覆盖率”“模板数量”“培训次数”这些都是投入指标不是产出指标。投入多不等于成果好。我总结了一套评估 PMO 价值的产出指标按优先级拍下来见表维度关键问题具体指标决策质量管理层做项目决策更容易还是更难了从立项到决策的平均周期、项目优先级调整的响应速度交付表现项目按时交付率、目标达成率有没有提升关键里程碑按时达成率、项目商业目标达成率资源效率组织资源是否被投入到正确的地方关键资源负载率、低价值项目的终止数量协作成本跨部门协调是否更加顺畅升级到管理层的重复性问题数量、跨项目冲突解决时长团队体验项目经理和团队觉得 PMO 是帮手还是负担项目经理满意度调研、流程执行自愿率还有一个最粗暴但很有效的判断方式如果半年后 PMO 突然撤销组织会不会明显感觉到项目管理的混乱会说明你有价值不会说明你做的事还没进入关键路径。有一次我在公司内部做 PMO 年度复盘时用了这个问题开场沉默了几秒钟之后研发总监说了一句“那肯定乱”——那是我觉得 PMO 做得最有成就感的时刻。6. 关于 PMO 的几点个人体会做了几年 PMO一个越来越强烈的感受是PMO 这个角色的核心能力不在项目管理本身而在翻译能力。把业务语言翻译成项目语言把项目数据翻译成管理语言把一线团队的痛点翻译成组织层面的改进项。做 PMO 的如果只会讲专业术语说不过业务如果只会迎合高管支持不到团队如果只会埋头做数据做出来没人信。只有三种语言都通的人才能把 PMO 从“二线部门”做到组织离不开的枢纽位。另外想给正在搭 PMO 或者刚接手 PMO 的朋友一个建议不要一上来就追求“职能齐全”。从我自己的经历看那种老板一挥手就要求“把 PMO 七大职能全部建起来、半年出效果”的最后几乎都半途而废。PMO 的职能是长出来的不是设计出来的。先找到组织里面最痛的那个点解决它建立信任然后解决第二个痛点不断扩展。职能的丰满度是随着组织对 PMO 信任度的提升而增长的。如果你现在所在的组织已经开始讨论要不要建 PMO可以把这篇文章里的职能地图作为讨论框架先拉齐认知再动手。如果你们已经有 PMO但总觉得它不温不火建议对照第五部分评估一下它到底卡在哪个阶段——大概率不是人不行而是定位或者授权出了问题趁早调整比硬扛着强。