委派怎么做？PMO制度设计：任务分派从0到1

去年我在一家约 300 人的软硬件企业做流程复盘，PMO 成立已经三个月，墙上贴着 12 页的《项目管理制度》，群里每天有 40 多条"这个谁跟一下"。我们随机抽了 30 个在办任务做穿透检查，结果是这样的：能说出明确验收人的只有 4 个，有明确交付日期的 13 个，有工时或工作量估算的 7 个，而"派出去之后有没有人正式回执"的，只有 2 个。也就是说，制度文件写得再厚，真正落到"谁做什么、谁验收、什么时候算完"这三个问题上，组织的实际水平还停留在口头阶段。

这件事让我彻底改变了对"委派"的理解。它不是一种沟通技巧，也不是管理者个人风格的体现，而是一套必须被设计出来的制度。PMO 从 0 到 1 的过程中，最容易被低估、又最决定成败的，恰恰就是任务分派这一环。下面我把自己踩过的坑、做过的改造、以及判断逻辑完整写出来，希望能帮你在自己的组织里少走一两年弯路。

一、先把结论摆出来：委派是制度设计，不是沟通技巧

如果你只想要一句话的答案，那就是：委派的对象不是"任务"，而是"责任包"。责任包里至少包含四样东西，可交付物、决策权边界、验收标准、以及回执与变更的通道。少了任何一样，这次分派在制度上都是不成立的。

1. 结论一：委派的最小单位是责任包，不是任务描述

绝大多数失败的委派，失败在起点。管理者说"你把这个需求跟一下"，这六个字里没有交付物、没有边界、没有完成定义。执行者只能靠猜，猜错了就是返工，猜对了也是运气。我在复盘里统计过，返工任务中有超过六成可以追溯到"最初的分派描述不完整"，而不是执行能力问题。

所以 PMO 在从 0 到 1 阶段要做的第一件事，不是建甘特图，而是定义"一个可被分派的任务长什么样"。这个定义要写成模板、做成字段、卡在系统入口，而不是停留在培训 PPT 里。

2. 结论二：PMO 的第一产出是分派规则，不是进度报表

很多新 PMO 上任后急着证明价值，第一周就开始出周报、做燃尽图。但报表只是结果的下游，如果分派规则本身是乱的，报表只是在给混乱拍照。我自己的经验是：PMO 前 90 天，至少 60% 的精力应该放在分派规则、责任矩阵和升级路径上，报表自动化反而是最容易补上的部分。

3. 结论三：没有回执的委派，等于没有委派

这是我踩过最深的坑。我们曾经用邮件做任务分派，发出 50 封，一周后统计"实际开始执行"的比例只有 38%。不是大家不配合，而是"收到"和"接受"是两件事。执行者可能不认同优先级、可能手上已经有冲突任务、可能觉得这不该由自己做。这些信息如果不在分派环节被逼出来，就会在交付环节爆炸。

因此我坚持一条规则：任务必须有显式的"接受/拒绝/协商"三个动作之一，才算完成分派。没有回执的任务，在系统里应该保持"待确认"状态，而不是直接进入"进行中"。

4. 结论四：工具的字段设计，决定制度能不能落地

制度写在文档里，靠自觉执行，衰减速度极快。我观察到的规律是：一项规则如果没有被固化进工具的必填字段或状态流转，三个月后的执行率通常掉到 30% 以下。能不能把"验收人""交付日期""工作量"设成必填，比写十条制度都管用。

二、从0到1的真实背景：PMO第一季度的任务分派为什么总失控

要理解委派为什么难，得先理解 PMO 从 0 到 1 时组织处在什么状态。它通常不是"白纸作画"，而是"旧秩序还没退场，新秩序还没建立"的过渡期。这个阶段的任务分派，天然是混乱的。

1. 阶段一：无制度期，靠人情和记忆分派

PMO 成立前，组织里的任务分派主要靠三样东西：领导记忆、部门熟人、会议现场指派。这套机制在小规模时是有效的，因为信息全在人脑里。但一旦跨过 100 人，人脑就成了瓶颈，不是记不住，而是记错了也无人察觉。

这个阶段的典型特征是：任务有归属但无记录，优先级有共识但无排序，进度有反馈但无口径。PMO 接手后第一件痛苦的事，是要把散落在大脑和群聊里的承诺"捞"回来变成可管理的对象。

2. 阶段二：制度空转期，规则有了但没人按规则做

这是最危险也最常见的阶段。制度发布了，模板下发了，但项目经理想的是"我这儿赶进度，填表太慢"，职能经理想的是"这任务本来就不是我的"。于是出现制度与实操双轨并行：会上按制度讲，会下按习惯干。

我见过最典型的一幕，是在一次双周例会上：项目经理口头指派了三个任务，PMO 负责人当场提醒"麻烦系统里建一下单"，对方回答"放心，我记得住"。三周后其中一个任务彻底没人做，追溯时双方各执一词，一个说"我说了"，另一个说"我以为你说的是下个迭代"。

3. 阶段三：收敛期，分派规则开始产生约束力

只有到了第三阶段，组织才会真正接受"不进系统不算任务"这条铁律。这个转折点通常由一个具体事件触发，一次客户投诉、一次合规审计、或者一次严重的交付事故。PMO 的高明之处，是在事故发生前把规则准备好，事故发生后第一时间把规则固化下来。这就是从 0 到 1 最重要的一次借力。

4. 任务分派的四个来源，决定了四套不同的规则

很多 PMO 把任务分派当成一件事来做，其实它至少有四个来源，每个来源的分派逻辑完全不同。

• 战略拆解来源：由年度目标层层分解而来，特点是优先级的刚性高、周期长，必须绑定 OKR 或经营指标。
• 客户与需求来源：来自销售、客户成功或产品需求池，特点是变化频繁，必须有变更通道而不只是分派通道。
• 故障与合规来源：线上故障、安全漏洞、审计整改，特点是时效性极强，需要"先派人后补流程"的例外机制。
• 跨部门协同来源：接口对接、联合交付、共享资源，特点是权责最容易模糊，必须有明确的单一责任人。

把这四类混在同一个分派流程里，是很多组织任务管理失控的根因。战略任务需要强确认、长周期跟踪；故障任务需要秒级响应；两者的 SLA 和验收标准不可能一样。

三、拆解七个常见误区：大多数委派失败，问题出在分派之前

我梳理过自己在多个组织里见过的委派失败案例，绝大多数不是执行环节掉链子，而是分派环节就已经埋了雷。这七个误区，你大概率能对上号。

1. 误区一：把委派当通知

最普遍的错误。管理者认为"我已经说过了"等于"委派完成了"。但从组织行为学角度看，单向信息传递不构成授权。真正的委派需要一个双向确认动作，执行者要有机会说"我理解的目标是什么、我需要的支持是什么、我什么时候能给你反馈"。

我的修正做法是：任何委派都要有一次"复述确认"。执行者用自己的话把交付物、验收标准和截止时间说一遍，管理者确认或纠正。这个动作在制度里只需 30 秒，却能消掉后面大量的返工。

2. 误区二：用人名代替角色

任务里写"张三负责接口联调"，看起来很明确，实际上很脆弱。张三请假、转岗、离职，这条任务的责任链就断了。更麻烦的是，用姓名委派会让组织无法统计"某角色当前负载"，也就没法做资源平衡。

正确做法是角色 + 具体人双层记录：角色字段回答"这件事该谁做"，人员字段回答"现在谁在做"。前者用于制度，后者用于执行。

3. 误区三：只派任务，不派权限

这是最隐蔽的坑。你让一个人负责一个跨部门接口，却没给他调动对方资源的任何权限，他只能靠人情推动。任务失败时你说他"推动力不够"，其实是你没给他"推动力"这个东西。

我在设计责任矩阵时，会强制要求写清三件事：这个人能决定什么、必须和谁协商、找谁升级。缺了升级路径的任务，几乎注定会卡死在某个部门边界上。

4. 误区四：颗粒度一刀切

有的 PMO 要求所有任务都拆到 8 小时以内，结果战略级任务被拆得支离破碎；有的完全不管颗粒度，结果一个任务挂在那里三个月没有任何进展可观测。

我的判断标准是按"可观测周期"来定颗粒度：一个任务的颗粒度，应该让它在不超过两个汇报周期内能产出一次可验证的进展。周会制的组织，颗粒度最好控制在 5 人日以内；月度回顾的组织，可以放宽到 15 人日。

5. 误区五：没有回执与逆向委派通道

任务只能往下压，不能往回退，这是制度设计上最大的缺陷。执行者如果发现任务不合理、资源不足、优先级冲突，他唯一的选项是"默默拖延"，而不是"正式协商"。不给拒绝权，组织就会得到无声的失败。

所以我在任何分派制度里都会保留三个动作：接受、协商、退回。退回必须写明理由，而且退回不计入负面考核，否则没人敢用。

6. 误区六：把责任矩阵当成填表游戏

很多团队做了 RACI 表，做完就锁进文件夹。表格只有在两个场景里才有价值：一是出现争议时能快速定位责任，二是新成员加入时能快速理解边界。如果这两件事都没发生，那张表就是形式主义。

7. 误区七：一上来就全公司推

从 0 到 1 阶段最忌讳全面铺开。我的建议永远是：先选一个 30-60 人的样板项目群做实，跑满两个完整迭代，再推广。样板的价值不只是验证流程，更是产出可复制的模板和一批"用过并且认可"的内部支持者。

四、专业判断逻辑：任务分派的三层设计与五个自检问题

说完误区，进入我实际在用的设计方法。我把它总结成三层结构：权责层、颗粒层、闭环层。这三层缺一层，制度就会在某个环节漏水。

1. 第一层：权责层，把责任矩阵从名词变成动词

传统 RACI 的问题是它只描述静态角色。我在实践中会加一个 V（Verifier，验收人），因为"负责执行"和"判定合格"必须是两个不同的人，否则自律就会替代验收。这套 A-R-C-I-V 的用法是：

这张表的价值在于：它把"谁负责"这个模糊问题，拆成了五个可以被系统字段固化的确定性答案。当一个任务在系统里没有 A 或没有 V 时，它就应该被标记为"不合规任务"，不允许进入执行状态。

2. 第二层：颗粒层，用三个维度定义任务粒度

我判断颗粒度是否合适，看三个维度：可交付物是否具体、工期是否可估算、依赖是否已识别。三者全满足，就可以派；缺一个，就要继续拆或补信息。

举个具体例子。"完成用户中心重构"这个任务，三个维度全不满足，没有具体交付物、无法估算、依赖未识别。而"完成用户中心登录接口的鉴权模块改造，含单元测试覆盖率达 80%，预计 5 人日，依赖统一身份服务 SDK v2.3 发布"就是可派发的。

颗粒度过粗的真正代价，不是执行慢，而是问题发现得太晚。一个 60 人日的任务，如果方向错了，你最早也要在 20 人日之后才能发现，那时沉没成本已经很大了。

3. 第三层：闭环层，回执、变更、升级三件事

闭环层是制度的保险丝。它由三个机制组成：

1. 回执机制：任务发出后必须在约定时限内（我通常设 24 小时）明确接受、协商或退回。
2. 变更机制：交付日期、范围、验收标准的任何变动，都必须走变更记录，不允许口头修改。
3. 升级机制：任务阻塞超过约定时限（通常 2 个工作日）自动升级到上一层责任人，升级不需要执行者申请。

第三点是我认为最被低估的。升级应该是自动的、制度化的，而不是靠执行者鼓起勇气去"告状"。如果升级需要个人承担人际风险，那这个机制在实际中就不会被使用。

4. 五个自检问题：判断一个任务能不能派出去

在按下"分派"按钮之前，我会过一遍这五个问题。任何一题答不上来，就说明信息还不够。

• 这个任务的可交付物能不能被第三方客观判断为"已完成"？
• 这个任务有没有唯一的最终责任人，而不是一个小组？
• 这个任务有没有独立的验收人和写定的验收标准？
• 这个任务的前置依赖是否已经确认可用，还是"假设会有"？
• 执行者手上是否已有与之冲突的任务，优先级是否已经排定？

第五个问题最容易被忽略。很多任务的失败不是没人做，而是被排在了第二位，然后永远做不完。分派时必须同步做优先级仲裁，否则就是在制造隐性逾期。

5. 代码化：把分派模板固化下来

制度要落地，最好能变成结构化数据。下面是我在一个研发组织里实际用过的任务分派模板，用 YAML 描述，可以直接映射成管理工具的自定义字段。

task_delegation:
task_id: PROJ-1042

title: "用户中心登录鉴权模块改造"

source_type: "客户需求" # 战略拆解 / 客户需求 / 故障合规 / 跨部门协同

deliverable: "鉴权模块代码 + 单元测试 + 接口文档"

acceptance_criteria:

"单元测试覆盖率 >= 80%"

"通过安全组渗透测试，无高危漏洞"

"接口文档在内部 Wiki 发布并评审通过"

accountable: "user-center@pmo-role" # 唯一最终责任人（角色）

responsible: ["zhangsan", "lisi"] # 实际执行人

verifier: "security-group" # 独立验收人

consulted: ["identity-service-team"]

informed: ["product-owner", "qa-lead"]

estimated_effort: "5 person-day"

due_date: "2025-04-18"

priority: "P1"

dependencies:

"identity-sdk >= v2.3"

escalation:

after_blocked_days: 2

escalate_to: "pmo-director"

receipt:

deadline_hours: 24

allowed_actions: ["accept", "negotiate", "reject"]

这份模板最关键的不是格式，而是它把"责任"变成了可校验的字段。系统可以在提交时直接校验：没有 verifier 不允许提交，没有 acceptance_criteria 不允许提交，due_date 早于依赖交付时间时给出警告。

6. 用管理平台把三层结构变成硬约束

纸面制度最大的问题是靠自觉，而靠自觉的规则衰减得太快。我在 200 人以上规模的组织里，普遍会建议把委派规则固化到项目管理平台的字段和流转规则中。

以 PingCode 这类面向中大型企业的研发管理平台为例，它主要服务 100 人以上组织，能够把工作项类型、自定义字段、状态流转和自动化规则组合起来，形成对分派行为的硬约束。比如把"验收人"设为必填字段，把"待确认 → 进行中"的状态流转绑定到回执动作，把阻塞超过 48 小时的工作项自动打标并通知上一层责任人。

对有多地研发中心或涉密要求的组织，PingCode 支持私有化部署，这一点在金融、制造、能源类客户里往往是硬门槛。如果组织原来用的是 Jira，PingCode 支持 Jira 平滑迁移，历史工作项、字段映射和看板结构可以整体搬过来，这也是很多团队在国产替代选型时优先考虑它的原因之一。

我要强调的是：工具不会自动带来好制度。先想清楚 A-R-C-I-V 和回执规则，再去找工具承载它，顺序反了就会变成"用一套复杂工具跑一套混乱流程"。

五、案例与数据观察：一家200人研发组织的分派改造

下面这个案例来自我深度参与的一次改造，组织规模约 200 人，三条产品线，两个研发中心。我把它完整写出来，包括改造前后的对照和几个反直觉的发现。

1. 改造前的状态：表格、邮件和会议三套系统并存

这家组织的任务分派当时有三条路径。研发内部用自建表格管理，跨部门协作用邮件，紧急事项在周会上口头指派。结果就是没有任何一个地方能看到完整的任务全貌。

我们做基线测量时发现几个数字：任务从发起到执行者确认接受，平均耗时 2.8 天；周会上用于"对齐谁在做什么"的时间占到会议总时长的一半；PMO 每周花在手工汇总任务状态上的时间约 16 人时。

2. 改造动作：先定规则，再上系统

我们没有一上来就换工具，而是先花了三周做三件事：定义责任矩阵、写定分派模板、明确回执与升级规则。这三件事全部由 PMO 和三位项目经理共同完成，没有请外部顾问。

规则定完后，才开始选平台承载。选型时的硬性要求有四条：必须支持自定义工作项类型和责任字段；必须支持状态流转的强约束；必须支持私有化部署以满足其中一个客户的合规要求；必须能把原来 Jira 上的历史工作项和看板结构迁过来。

最终选择 PingCode 落地，主要原因就是这四条能同时满足。迁移过程中，历史工作项、字段映射和看板结构整体搬迁，没有出现需要人工重建数据的情况。

3. 改造后的数据对照

上线满三个月后，我们做了一次完整对照。以下为样本推演数据，口径为该组织真实测量的内部指标，仅代表这一个案例，不代表行业普遍水平。

4. 三个反直觉的发现

第一个发现是：确认时长下降得比返工率快得多。回执机制上线一个月，确认时长就降到 0.6 天，但返工率直到第三个月才降到 9%。原因是执行者需要时间学会写清验收标准，这个能力提升比制度上线慢得多。

第二个发现是：升级机制上线后，升级事件的数量先增后减。前两个月升级数暴涨，因为积压的阻塞问题被集中暴露出来；第三个月之后逐月下降，因为大家知道"拖到最后也会被升级"，反而更愿意提前协商。

第三个发现是：颗粒度变细后，项目经理的初期工作量反而增加了。以前一个粗任务派出去就完事，现在要拆成三到五个细任务并逐个填写字段。前六周项目经理普遍抱怨"更麻烦了"，直到他们发现自己的周会时间和救火时间大幅下降，态度才转变。这个阵痛期必须提前告知，否则制度会在推行初期被推翻。

5. 这个案例不能直接照搬的部分

有一点必须说清楚：这个案例成立的前提是组织已经跨过 100 人、有多产品线、且存在跨地域协作。如果你的组织只有 40 人、单产品线、大家坐在一个开放区，那么这套重制度的成本会高于收益。制度密度应该与协作复杂度匹配，而不是与行业最佳实践匹配。

六、不同情况下的行动建议：按组织规模和项目类型分档

我见过太多 PMO 直接照搬大厂制度文档，结果把自己拖死。委派制度的复杂度，应该随组织规模和项目类型阶梯式增长，而不是一次到位。

1. 50 人以下：不要做制度，做约定

这个规模下，信息传播靠面对面就够了。你需要的不是流程文档，而是三条口头约定并落到一个共享看板上：任务必须写清交付物和截止日期；谁做谁验收要分开；卡住了当天说。

如果这时候强推复杂流程和字段必填，结果一定是形式主义填表，反而降低效率。

2. 50-200 人：建立最小可用的分派制度

这是制度开始产生价值的临界区间。你需要的第一批东西是：统一的任务入口、固定的责任字段（A/R/V 三个就够）、24 小时回执规则、以及一份简版升级路径。

工具上，这个规模开始需要真正的项目管理平台而不是电子表格，因为跨团队可视化和历史追溯靠表格已经撑不住了。

3. 200-1000 人：必须做责任矩阵和分派模板

到这个规模，靠默契已经不可能。你需要正式的责任矩阵、分级的分派模板（战略类/需求类/故障类）、明确的服务等级约定，以及一套可配置的管理平台。

这个阶段也是国产替代替换海外工具的高发区间。以 PingCode 为例，它主要面向中大型企业，支持私有化部署和 Jira 平滑迁移，对 200 人以上、有合规要求或多地协作的组织比较适配。选型时我建议重点验证三件事：自定义字段能否承载你的责任矩阵、状态流转能否强制回执、历史数据能否无痛搬迁。

4. 1000 人以上或多业务单元：制度分层，不追求统一

这个规模下追求"一套制度管全公司"是灾难。正确做法是：集团层定义底线规则（必填字段、回执时限、升级原则），各业务单元在底线之上自建细分流程。

我在这个规模的组织里通常只强推三件事：统一任务入口、统一责任字段口径、统一升级触发规则。其余全部下放，让各 BU 自己决定颗粒度和评审节奏。

5. 按项目类型调整：研发型、交付型、运维型差异明显

• 研发型项目：颗粒度可稍粗（5-10 人日），重点在验收标准和技术依赖，评审周期配合迭代节奏。
• 交付型项目：颗粒度要细（1-3 人日），重点在里程碑和客户可感知的交付节点，变更必须走正式记录。
• 运维与故障类：不追求细分，重点在响应时限和事后复盘，允许"先处理、后补单"，但补单时限要硬性规定。

七、不同情况下的取舍：制度化、灵活性与工具约束力

制度设计从来不是"越多越好"，而是一组取舍。我把最常被问到的四组取舍写下来，每一组都给出我的判断依据。

1. 取舍一：强制度 vs 灵活性

强制度的代价是响应速度下降，灵活性的代价是责任模糊。我的判断依据是任务的可逆性：可逆的任务（走错了能回头）优先给灵活性，不可逆的任务（客户承诺、合规整改、生产变更）优先给强制度。

具体做法是把任务分成两条通道：标准通道走完整流程，快速通道走简化流程但要求事后 24 小时内补全信息。两条通道并行，比一条通道反复妥协要干净得多。

2. 取舍二：集中分派 vs 分散分派

集中分派（PMO 统一指派）的好处是全局视角，坏处是容易脱离一线实际。分散分派（各团队自行指派）的好处是贴近实际，坏处是优先级各行其是。

我的做法是规则集中、执行分散：PMO 定义分派标准、责任字段口径和升级路径，具体派给谁由各团队负责人决定。只有跨部门冲突和资源争夺才上升到 PMO 仲裁。这样既保留了全局一致性，又避免 PMO 变成派单中心。

3. 取舍三：工具强约束 vs 弱约束

强约束（必填字段、强状态流转）能保证数据质量，但会增加操作摩擦，尤其在制度还没被认可时容易引发抵触。弱约束上手快，但数据质量会在两三个月内快速衰减。

我的建议是分阶段：第一个迭代用弱约束暖场，第二个迭代把关键字段改为警告，第三个迭代再改为必填。给组织一个适应窗口，比一上线就全面锁死更容易活下来。

4. 取舍四：私有化部署 vs SaaS

这个取舍在 200 人以上、涉及客户数据或行业合规的组织里几乎必问。私有化部署的优势是数据可控、可深度定制、满足审计要求；代价是运维成本、升级节奏慢于 SaaS。

SaaS 的优势是开箱即用、持续迭代；代价是数据出境和定制空间受限。我的判断标准很简单：如果客户合同或所在行业监管明确要求数据不出内网，就直接排除 SaaS，不要在这上面浪费评估时间。

5. 一个常被忽略的取舍：制度的可解释性 vs 完备性

我见过很多制度文档，条款写得非常完备，但没人能讲清楚为什么这么规定。结果是遇到边界情况时，大家只能死抠字面。好的委派制度应该能用三句话解释清楚核心逻辑：责任到人、验收独立、阻塞自动升级。完备性可以靠附录慢慢补，可解释性必须在第一版就具备。

八、从30天到90天：把委派制度真正跑起来

最后给一份可执行的路线图。这套节奏我在三个不同规模的组织里调整使用过，核心逻辑是：先小范围验证，再固化工具，最后扩大范围。

1. 第一个 30 天：定义与试点

1. 选一个 30-60 人的样板项目群，不要全公司铺开。
2. 和项目经理一起定义责任矩阵（A/R/V 三个字段先跑起来，C/I 可以后补）。
3. 写出一页纸的分派模板，包含交付物、验收标准、工作量、截止日期、依赖。
4. 定下回执规则：24 小时未回执自动提醒，48 小时未回执通知上一层。
5. 用现有工具先跑一遍，看看哪些字段是空的，哪些规则会被绕过。

这个阶段的目标不是效率提升，而是暴露信息缺口。你会发现大量任务的依赖是拍脑袋写的，验收标准是事后补的，这正是最有价值的发现。

2. 第二个 30 天：固化与硬化

1. 把验证过的字段和流程搬到管理平台，设置必要的校验规则。
2. 先启用警告而非强制必填，给团队两周适应期。
3. 建立每周一次的分派质量抽查，随机抽 10 个任务检查责任字段完整性。
4. 把抽查结果做成看板，公开透明，但不点名考核。
5. 收集抱怨，尤其是项目经理的抱怨，从中识别哪些规则设计得不合理。

这一步的关键是不要急着把制度变成考核。一旦与绩效挂钩，大家会开始应付数据而不是改善协作，数据质量反而下降。

3. 第三到第六个 30 天：扩展与优化

1. 把样板项目群的模板复制到相邻团队，每个团队允许做 20% 的本地化调整。
2. 把关键字段从警告升级为必填，同时提供便捷的批量填写方式降低摩擦。
3. 启用自动升级规则，观察两个月的升级事件曲线是否呈现先增后减。
4. 每季度回顾一次责任矩阵，清理已经不再使用的字段，避免制度膨胀。

4. 一份可以贴到墙上的检查清单

如果你只想拿走一样东西，就拿走这份清单。每次分派任务前过一遍，能消掉大部分后续麻烦。

• 交付物能被第三方客观判定为完成吗？
• 有没有唯一的最终责任人？
• 验收人是不是独立于执行者？
• 验收标准是不是在分派时就写定了？
• 前置依赖是不是已经确认可用？
• 执行者现有的任务优先级是否已仲裁？
• 回执时限和升级路径是否已明确？
• 变更时走什么通道，是否已经说清？

5. 最后一句判断

回到最开始那个抽样结果：30 个任务里只有 4 个说得清验收标准。这不是执行力问题，而是设计问题。委派的本质，是在任务开始之前就把"什么叫做完"这件事谈清楚。PMO 从 0 到 1 阶段最该做的，不是催进度、不是出报表，而是把这件事变成组织的默认动作。

下一步你可以做一件很小的事：挑出你手上正在跑的 10 个任务，逐个检查是否有明确的责任人、独立验收人和写定的验收标准。如果通过率低于 50%，那你不需要新的制度文档，你需要的是先把分派模板用起来，然后找一个 30 人的样板团队，花四周时间把它跑通。

制度不是写出来的，是跑出来的。先跑起来，再谈完善。