PMO职责说明要落到可执行层面，一张职责分工表比一段文字描述更实用。本文提供可直接复制填写的空白表，逐列说明职责域、主责角色、输入输出、决策权限和考核依据的填写口径，标出必填与选填字段，并给出一份覆盖多个职责域的完整填写示例，最后说明职责变化时如何调整和维护这张表。
要点总览（TL;DR）
- PMO职责说明用一张职责分工表落地：按职责域列出条目，写明主责角色、协作角色、输入、输出、决策权限和考核依据。
- 最小可用填写集为序号、职责域、职责条目、主责角色、输出五项；协作角色、输入、决策权限建议填写，考核依据和备注可后续补齐。
- 每条职责只设一个主责角色，决策权限用“可决定／需上报／仅建议”三档标注，与项目投资决策区分开。
- 职责变化时按新增、修改、删除、移交记录变更，建议每半年复核一次，由PMO负责人发起。
- 职责条目与变更记录可在ONES文档与工作项管理中承载，ONES Performance的效能数据可作为考核依据的参考来源。
可复制空白模板：PMO职责分工表
下表可直接复制到文档或表格工具中填写。表头固定，行数按职责条目增减。填写前先确认三项信息：本组织的PMO定位（支持型、控制型或混合型）、参与职责分工的角色清单（含角色名称与所属部门）、以及本表的使用范围（覆盖全部项目还是特定项目群）。这三项决定了后续每一列能填什么。
| 序号 | 职责域 | 职责条目 | 主责角色 | 协作角色 | 输入 | 输出 | 决策权限 | 考核依据 | 备注 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | |||||||||
| 2 | |||||||||
| 3 | |||||||||
| 4 | |||||||||
| 5 | |||||||||
| 6 | |||||||||
| 7 | |||||||||
| 8 |
职责域一列可参考以下分类展开，按组织实际情况取舍或合并：项目立项与启动管理、计划与进度跟踪、资源协调与调配、质量与评审管理、风险与问题管理、变更管理、项目文档与知识管理、项目收尾与复盘、PMO自身能力建设与流程改进。分类的作用是让职责条目成组出现，便于检查是否有遗漏或重叠。
字段说明：每一列填什么、怎么判断填对了
字段填写质量决定这张表能否真正用于分工和考核。下表逐列给出含义、填写口径和常见错误。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 职责域 | 职责所属的管理领域分组 | 使用组织内已达成共识的分类名称，同一职责域下的条目连续排列 | 分类过细导致每行一个域；或分类名称各人叫法不一 |
| 职责条目 | 一条具体、可执行的管理职责 | 以动词开头，写清对象和动作，一条只讲一件事，能判断是否完成 | 写成部门职能口号；一条里塞进多个动作，无法界定完成标准 |
| 主责角色 | 对该职责结果负最终责任的角色 | 每条职责只填一个角色，填角色名而非人名；角色名与组织岗位对应 | 填两个主责导致推诿；直接填个人姓名，人员变动后表格失效 |
| 协作角色 | 参与配合、提供输入或共同执行的角色 | 可填多个，用顿号分隔；只列实际需要配合的角色 | 把所有相关部门都列上，协作关系失去意义 |
| 输入 | 履行该职责前需要获得的信息、文档或数据 | 写具体交付物名称或数据来源，如“项目立项申请”“迭代计划” | 写“相关信息”“必要资料”这类无法核对的表述 |
| 输出 | 职责履行后产生的交付物、记录或状态变化 | 写可被他人接收和检查的产物，如“项目周报”“风险登记表更新” | 把动作过程当输出，如“进行跟踪”“开展评审” |
| 决策权限 | 该职责中PMO可自主决定、需上报或仅提供建议的事项 | 用“可决定／需上报／仅建议”三档标注，并写明决定或上报的对象 | 与项目投资决策混淆；整列统一写“负责”而无法区分权限边界 |
| 考核依据 | 判断该职责是否履行到位的衡量口径 | 写可观察的指标、检查点或评审结论，如“周报按时提交率”“评审问题关闭率” | 直接照抄输出字段；写“完成情况良好”这类无法衡量的判断 |
| 备注 | 补充说明、例外情形或待确认事项 | 简短记录，涉及待定内容时标注责任人和确认时间 | 把大段背景说明塞进备注，影响表格可读性 |
两组字段容易混淆。主责与协作的区分标准是结果责任：主责角色对这条职责的最终结果负责，协作角色对其中某个环节负责。输出与考核依据的区分标准是对象不同：输出是职责做完后留下的东西，考核依据是拿什么判断做得好不好。同一条职责的输出可以同时作为考核依据的一部分，但考核依据通常还需要时间、质量或覆盖面的口径。
必填与选填：哪些字段不能空
最小可用填写集是序号、职责域、职责条目、主责角色、输出五项。这五项齐全，表格就能用于基本的分工确认。其余字段按管理成熟度逐步补齐。
| 字段 | 填写要求 | 理由或适用情形 |
|---|---|---|
| 序号 | 必填 | 便于引用、变更记录和讨论时定位条目 |
| 职责域 | 必填 | 支撑分类检查和覆盖度判断 |
| 职责条目 | 必填 | 表格的核心内容 |
| 主责角色 | 必填 | 没有主责的职责条目无法执行 |
| 输出 | 必填 | 是判断职责是否发生的直接依据 |
| 协作角色 | 建议填写 | 跨部门协作多的职责必须填；单一角色独立完成的职责可留空 |
| 输入 | 建议填写 | 依赖上游交付物的职责应填；输入不明确的条目可先留空并在备注标注待确认 |
| 决策权限 | 建议填写 | 涉及审批、上报或跨项目协调的职责必须填；纯执行类职责可留空 |
| 考核依据 | 选填 | 纳入考核周期的职责填写；首版职责说明可先不填，待运行一个周期后补充 |
| 备注 | 选填 | 有例外情形、待定事项或历史背景时填写 |
字段留空时按以下规则处理：必填字段不得留空，确实无法确定的，在备注中写明待确认事项、确认责任人和计划确认时间；建议填写字段留空视为“本条目暂不涉及”，不需要额外说明；选填字段留空表示尚未纳入考核或无需补充，后续复核时再评估是否补齐。任何留空都不应影响其他字段的填写完整性。
填写示例：一份完整的PMO职责说明
以下示例为演示情景，角色名称和指标口径按一般研发组织设定，实际使用时替换为本组织的角色与口径。
| 序号 | 职责域 | 职责条目 | 主责角色 | 协作角色 | 输入 | 输出 | 决策权限 | 考核依据 | 备注 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 项目立项与启动管理 | 组织项目立项评审，汇总评审意见并形成立项结论 | PMO项目经理 | 业务负责人、技术负责人、财务接口人 | 立项申请、可行性说明、资源预估 | 立项评审纪要、立项结论 | 仅建议：评审意见供决策层参考，立项由决策层批准 | 立项评审按期组织率、评审纪要归档率 | 紧急立项走简化流程，事后补评审 |
| 2 | 计划与进度跟踪 | 收集各项目周报，汇总进度偏差并提示风险 | PMO项目专员 | 各项目经理 | 项目周报、里程碑计划 | 项目进度汇总表、偏差提示清单 | 可决定：偏差提示的发布范围与频次 | 周报收集完整率、偏差提示的响应率 | — |
| 3 | 风险与问题管理 | 维护项目风险登记表，跟踪高风险事项的应对进展 | PMO风险协调人 | 项目经理、技术负责人 | 风险上报记录、应对计划 | 风险登记表更新、高风险事项跟踪记录 | 需上报：高风险等级判定与升级由项目管理委员会确认 | 高风险事项按期关闭率 | 风险等级标准见配套管理规范 |
| 4 | 变更管理 | 受理项目范围与计划变更申请，组织影响评估 | PMO项目经理 | 项目经理、需求负责人、测试负责人 | 变更申请单、影响分析材料 | 变更评估结论、变更记录 | 可决定：一般变更的评估安排；需上报：影响里程碑的变更 | 变更评估按时完成率、变更记录完整率 | — |
| 5 | 项目收尾与复盘 | 组织项目复盘会，整理经验教训并归档 | PMO项目专员 | 项目经理、核心成员 | 项目结项材料、过程数据 | 复盘纪要、经验教训库条目 | 可决定：复盘形式与参与范围 | 复盘会按期召开率、经验条目入库数量 | — |
| 6 | PMO自身能力建设与流程改进 | 根据复盘结论修订项目管理流程模板 | PMO负责人 | 质量接口人、项目经理代表 | 复盘结论、流程执行反馈 | 流程模板修订版、修订说明 | 可决定：模板文字性修订；需上报：流程节点增减 | 修订按期发布率、模板使用反馈 | 每年至少复核一次 |
这份示例的填写取舍有几处值得说明。第1条把立项决策权明确划给决策层，PMO只保留组织评审和建议的权限，避免职责说明与实际授权不符。第3条的高风险升级写成需上报，是因为风险等级判定通常涉及多个项目之间的资源权衡，超出单个PMO角色的权限。第2条和第5条的考核依据选择了可统计的比率类口径，便于按周期检查。第6条把流程修订拆成可决定与需上报两档，文字性修订由PMO自主完成，涉及流程节点变化的修订需要更高层级确认。备注列只保留例外情形和引用说明，不写背景故事。
职责说明落地后，条目和变更记录需要有稳定的承载位置。ONES 的文档与工作项管理可以承载职责条目、版本记录和评审流转；在考核依据的执行环节，ONES Performance 提供效能管理实践体系，支持对系统内产生的研发数据进行多维度分析，其页面列出的适用场景包括 PMO 多项目管理，可作为职责履行情况的参考数据来源，具体指标配置需按实际系统核验。
调整与维护：职责变化时怎么改这张表
职责分工表在首次发布后需要持续维护，否则会与实际分工脱节。以下情形出现时应触发调整：组织架构调整导致角色归属变化；某项职责从PMO移交给其他部门，或从其他部门转入PMO；新增职责域，例如组织开始推行新的质量体系或度量机制；项目模式变化，例如从单项目为主转为项目群管理；以及定期复核中发现条目与实际执行长期不一致。
版本与变更记录建议在表格之外单独维护一张记录表，包含以下字段：变更编号、变更日期、涉及条目序号、变更类型（新增／修改／删除／移交）、变更内容摘要、变更原因、提出人、确认人、生效日期。每次调整后更新表格版本号，旧版本保留归档，便于追溯某条职责在特定时间点的归属。
定期复核建议每半年一次，由PMO负责人发起，邀请主要协作角色的代表参加，重点检查三类问题：主责角色是否仍然准确、输出物是否仍在实际产生、考核依据是否仍可统计。复核结论形成简要记录，无变化时也留痕。责任人方面，PMO负责人对表格整体有效性负责，各职责域的主责角色对本域条目的准确性负责。复核节奏可按组织变化频率调整，变化频繁的阶段可缩短为每季度一次。
常见问题
PMO职责说明和岗位说明书有什么区别，能不能互相替代？
两者关注的对象不同。岗位说明书描述某个岗位的任职要求、汇报关系和能力条件，以人为对象；PMO职责说明描述管理职责本身由谁主责、需要什么输入、产出什么、有多大权限，以职责为对象。同一职责在组织调整后可能换人承担，职责条目本身仍然成立。
实际使用时可以互相引用：职责分工表的主责角色对应到岗位说明书中的岗位名称，岗位说明书则引用职责条目作为工作内容依据。用岗位说明书替代职责分工表，容易在跨部门协作和权限边界上留下空白。
小型组织只有一两个人做PMO工作，这张表还要填这么细吗？
可以简化，但不要省掉主责角色和输出两列。人少的时候，主责角色一列可能反复出现同一个角色名，这本身是有用信息，说明职责集中度较高，需要关注单点风险。输出一列帮助确认每项职责是否真的在发生。
协作角色、输入、决策权限可以先只填跨部门或涉及审批的条目，纯内部执行的条目留空。考核依据在首版可以整体不填，运行一个周期后再补充。表格行数也可以按实际职责条目裁剪，不必凑满模板给出的行数。
决策权限一列怎么和公司的审批制度对齐？
建议先拿到现行的授权或审批制度，把其中与PMO相关的审批事项逐条对照到职责条目上，再填决策权限。填写时写明三档中的哪一档，以及决定或上报的对象，例如“需上报：影响里程碑的变更，由项目管理委员会确认”。
如果制度中没有明确规定的灰色地带，不要凭感觉填“可决定”，在备注中标注待确认事项、确认责任人和计划确认时间，等制度明确后再更新。这一列填错的代价比留空大，因为它会直接造成授权争议。
职责条目写多细才算合适，会不会越写越多？
判断标准是能否界定完成。一条职责应该能用一句话说清做什么、对什么对象做、做完留下什么，其他人看了能判断是否完成。达到这个程度就够了，再往下拆会变成操作步骤，不适合放在职责说明里。
控制数量的方法是按职责域分组检查：同一职责域下条目明显多于其他域时，看看是否有条目其实属于操作层面，可以合并；某个职责域只有一条且与其他域重叠时，考虑合并职责域。首版条目偏多比偏少好，运行一轮后按实际执行情况合并。
表格发布后没人按它执行，怎么让它真正起作用？
常见原因是表格没有进入实际工作流。可以让职责条目与具体的会议、评审节点和交付物挂钩，例如立项评审的召集人对应到某条职责的主责角色，周报汇总对应到另一条。这样表格描述的就是实际在发生的事，而不是一份独立文档。
另一个做法是把考核依据中可统计的口径纳入定期检查，用数据反映职责履行情况。ONES Performance 提供效能管理实践体系，支持对系统内产生的研发数据进行多维度分析，其页面列出的适用场景包括 PMO 多项目管理，可作为职责履行情况的参考数据来源，具体指标配置需按实际系统核验。复核时发现条目与实际长期不一致的，按变更流程修订，而不是让表格停留在纸面。
