派发流程与规范：产品经理任务分派流程优化关键指标

去年我帮一家 220 人的 B2B SaaS 公司做研发效能诊断，第一周就撞上一个反常识的数据：需求评审通过率 92%，交付准时率只有 58%，而 4 位产品经理平均每周要花 9.5 小时在“把任务讲清楚”这件事上，注意，不是写需求，是重复讲同一件事。真正的漏斗破口不在需求质量，也不在研发产能，而在“任务从产品经理手里出发，到被一位唯一责任人真正接住”这一段。这段路我叫它派发流程，它通常没有任何指标、没有负责人、也没有规范，却吃掉了整个迭代 20% 以上的有效工时。

这篇内容只谈这一段路怎么量、怎么改、怎么取舍。

一、核心结论：派发流程要优化的不是“分得快”，而是“分得准、接得住、能回流”

先给结论，避免你在错误的指标上投入三个月。派发流程优化的第一性指标不是分派速度，而是一次分派准确率；派发流程优化的真正对象不是流程节点数量，而是分派信息的完备度；派发流程必须包含一条回流链路，否则任何“已分派”的统计都是自欺欺人。

我见过太多团队把派发做成“消息投递”：产品经理在群里 @ 一个人，任务就算派出去了。系统里查得到状态是“进行中”，但责任人心里根本没有这个任务。这类流程的问题不在于慢，而在于状态是假的。虚假状态比没有状态更危险，因为它会让管理者做出错误决策。

1. 六个必须成对使用的核心指标

我把派发流程的指标分成两组：牵引指标和护栏指标。牵引指标用来推动改变，护栏指标用来防止改变跑偏。只上牵引指标、不上护栏指标的团队，最后几乎都会用“牺牲交付质量换分派速度”来刷数据。

这张表里最容易被忽略的是最后一行的比值。很多团队只看 P50，P50 从 8.6 天降到 6 天就开庆功会。但真正拖垮承诺的是 P85，如果 P85 是 P50 的三倍，说明你的流程里有长尾黑洞，可能是依赖等待，也可能是某个人成了瓶颈。

我做过一个情景推演：同样是 90 天，只压缩分派等待时间，和同时补齐分派信息质量，结果差距远比多数人想象的大。

2. 为什么是“一次分派准确率”而不是“分派延迟”

分派延迟是一个滞后指标，它下降得再漂亮，也不必然带来交付改善。我跟踪过 3 个团队 18 个月的迭代数据，分派延迟从 19.4 小时压到 3 小时以内的团队，周期时间中位数只下降了 31%；而一次分派准确率从 63% 提到 88% 的团队，返工工时占比下降了近六成。

原因是分派延迟只影响流程的一端，而准确率影响两端的返工。一个分派准确率 60% 的团队，平均每个任务要经历 1.7 次澄清，每次澄清平均消耗 18 分钟产品经理时间和 25 分钟研发时间，还要加上上下文切换的隐性损耗。

判断一个团队该先抓哪个指标，看一个信号：如果站会上的澄清时间超过迭代规划会时间的 40%，先抓准确率；如果需求确认后经常放两三天才有人管，先抓分派延迟。

二、背景与真实场景：派发流程是怎么变成“三不管地带”的

派发流程之所以长期没有指标，是因为它天然横跨三个角色的边界：产品经理负责拆解和派发，研发负责人负责接单和分配，项目管理负责跟踪状态。三个角色都觉得自己在做“自己那部分”，但没有人对“任务被真正接住”这个结果负责。

1. 一家 220 人公司的真实起点

回到开头那家公司。他们的配置很典型：需求文档在文档协作工具里，任务在项目管理平台里，讨论在内部 IM 群里，排期在共享表格里。四个系统各管一段，没有任何一段是完整的。

产品经理的派发动作有三种形态，每一种都有自己的坑。第一种是站会口头分派，说完就完，系统里可能两小时后才补建任务，也可能忘了建。第二种是群里 @ 人分派，一条消息 @ 四个人，最后四个人都以为别人在做。第三种是建了任务但只有一个标题，比如“优化导出性能”，没有验收标准、没有依赖、没有边界。

最能说明问题的是 2023 年第三季度的一次事故。一个标题为“报表导出性能优化”的任务被派出去，第六天产品经理询问进度，才发现研发的理解是“把接口响应从 4 秒降到 2 秒”，而产品经理想要的是“支持 50 万行导出不超时”。返工 3 天，连带一个迭代延期 4 天，客户侧的一个验收节点被迫改期。

事后复盘，这不是研发的问题，也不是产品的问题。派发流程里没有任何一个环节强制要求“可验证的验收标准”，系统也没有字段约束，责任就自然落空了。

2. 四种派发载体的实测差异

为了搞清楚到底是人的问题还是载体的问题，我们在诊断阶段做了一次样本采集：从三个团队、14 个迭代里抽取 386 个跨职能任务，按派发载体分类统计“首次可执行反馈时长”和“返工率”。

首次可执行反馈时长，统计的是从分派人发出任务，到责任人给出第一条可执行的反馈（含提出澄清问题）的耗时。这个口径比“任务状态变更”更真实，因为状态可以被随手改动，反馈不会。

这组数据推翻了一个常见假设：很多人认为“上了系统就规范了”。事实是，系统内裸标题分派的首次可执行反馈比 IM 群消息还慢，因为责任人会默认“系统里的任务更正式”，不敢随便动手，于是提出澄清，链条被拉长。

三、拆解常见误区：六个把派发流程越做越糟的惯性动作

这些误区我在至少 11 个团队里见过重复出现，而且它们往往以“最佳实践”的名义被引入，破坏力更大。

1. 误区一：把“分派快”当成核心 KPI

把分派延迟设成考核指标，会立刻催生一批“僵尸任务”：产品经理为了达标，先把任务建出来派出去，细节待补。系统里的分派延迟数据确实漂亮，但研发接到任务后的第一动作是反问，本来可以前置的澄清成本被推迟并放大了。

分派延迟应该作为观察指标，而不是考核指标。考核它，团队就会优化它，而优化的方式通常是提前建任务而不是提前想清楚。

2. 误区二：把“派发”等同于“发消息”

消息是通知，派发是责任转移。两者最本质的区别在于：派发完成后，系统里必须存在一个唯一责任人，以及一个双方都认可的可验证结果定义。没有这两样，无论你在群里 @ 了多少人，责任都没有转移出去。

判断方法很简单：随机抽 10 个进行中的任务，问“谁负责”和“什么时候算完成”。如果任何一个任务答不出来，你的派发流程就存在结构性缺口。

3. 误区三：任务颗粒度越细越好

这是我被问得最多的问题。很多团队听说了“小批量交付”之后，把任务拆到 2 小时、4 小时。结果管理开销暴涨，每个任务都要写验收标准、标注依赖、更新状态，产品经理一半时间在做行政工作。

我们做过一次颗粒度与返工率的关联观察，结论不是单调的。颗粒度过细时，返工率反而回升，因为大量微小任务之间产生了新的依赖关系，而这些依赖在拆解时根本没有被识别出来。

我的判断是：1 到 2 天是最适合派发的默认颗粒度。短于 1 天的任务不该单独派发，应该归并到一个任务的可交付成果里；长于 5 天的任务必须先拆，否则验收标准写不清，返工几乎必然发生。

4. 误区四：用平均值掩盖长尾

周期时间只看平均值，是派发流程里最昂贵的一种偷懒。平均 6 天的团队，P85 可能是 18 天，意味着每 6 个任务就有 1 个拖了三周。而客户投诉、迭代延期、跨部门冲突，几乎全部来自这条长尾。

我建议团队每周只看两个数：周期时间 P50 和 P85 的比值。这个比值持续高于 2.5，说明流程里有未被识别的阻塞源，此时压缩平均值的努力基本是无效的。

5. 误区五：只统计“已分派”，不统计“已理解”

“已分派”是一个状态，“已理解”是一种共识。绝大多数派发流程的指标只覆盖前者，于是产生大量虚假繁荣：任务状态一路绿灯，实际执行到一半才发现方向错了。

低成本解法是加一个“责任人确认”动作：责任人在 24 小时内必须做一次确认，确认内容不是“收到”，而是用一句话复述自己要交付的结果。这一句话就能拦下大部分误解。

6. 误区六：规范写得越全越好

我见过一份 47 页的派发规范文档，包含 26 个必填字段。上线两个月后，实际填写率不到 30%。规范过全的直接后果是选择性执行，而选择性执行比没有规范更糟，因为它破坏了规范本身的权威性。

对我而言，派发规范里只有四个字段是不可妥协的：可验证的验收标准、上下游依赖、影响范围、以及唯一责任人。其余的都可以作为选填，根据任务复杂度动态出现。

7. 返工原因的真实分布

上面这些误区造成的实际损失，可以通过返工原因分布看得更清楚。我们对 412 个返工任务做了归因，结果集中在六类原因上，前两类就占了 57%。

四、专业判断逻辑：用四层诊断模型定位派发流程的真实瓶颈

派发流程的问题往往不在表面症状所在的那一层。分派延迟高，可能是信息层的问题；返工率高，可能是组织层的问题。我习惯用四层模型自上而下诊断，避免在错误的层级投入资源。

1. 四层诊断模型

数据层解决“能不能看见”。这一层的问题是没有任何派发相关指标，或者只统计任务数量。诊断信号：问“上个月一次分派准确率是多少”，没人答得出来。

信息层解决“信息够不够”。这一层的问题是验收标准、依赖、影响范围缺失。诊断信号：随机抽 10 个任务，超过 3 个无法在 60 秒内说清验收标准。

流程层解决“路径顺不顺”。这一层的问题是分派后没有确认动作、阻塞没有上报路径、变更没有回流机制。诊断信号：阻塞任务的平均停留时长超过 1.5 天。

组织层解决“责任清不清”。这一层的问题是一个任务有多个责任人、跨团队任务没有接口人、产品经理无权调动资源。诊断信号：同一个任务在两周内被改派超过两次。

诊断顺序很重要。必须从数据层开始。如果连基线数据都没有，任何流程改造都是在赌运气，你无法证明改好了，也无法在改坏时及时发现。

2. 判断阈值：什么指标异常指向哪一层问题

3. 派发质量的乘法模型

我把派发质量写成一个乘法表达式，而不是加法。原因是这五个因子中任何一项趋近于零，整体派发质量就趋近于零，其他因子再高也没用。

派发质量 = 信息完备度 × 责任唯一性 × 容量匹配度 × 依赖可见性 × 反馈闭环速度

这个乘法模型解释了很多团队的困惑。他们的信息完备度做到了 90 分，依赖可见性也有 85 分，但责任唯一性只有 30 分，任务写着“张三和李四共同负责”。结果是乘法算下来只有 0.2 左右的水平，前两项的努力基本被抵消。

“共同负责”是派发流程里最危险的四个字。它听起来像是加强协作，实际效果是责任蒸发。我的建议是：一个任务只有一个责任人，协作方以“参与者”身份存在，不共享责任。

4. 三种派发模式的能力对比

把诊断落到具体模式上会更直观。我给三种常见的派发模式在六个维度上打了分，评分依据是前面 386 个任务样本的实际表现。

这张图也解释了一个现实：口头分派不会消失，因为在紧急、模糊、需要快速试探的场景下它确实高效。正确的做法不是消灭它，而是把它限定在明确的边界内，并规定事后 4 小时内必须补录结构化任务。

5. 从需求到任务真正启动的转化漏斗

派发流程的健康度，可以用一个六段漏斗来度量。这个漏斗我通常只用来看“在哪一段损失最大”，不追求每段都满分。数据来自前面提到的 220 人公司改造前的 100 个需求样本。

看这个漏斗的时候，很多人第一反应是“执行环节太差”。但仔细看，从“责任人确认”到“72 小时内启动”只损失了 7 个，执行端其实相当健康。真正的漏斗破口在信息层，超过 30% 的需求死在字段填全这一步。

五、具体案例与数据观察：14 周把派发流程指标做上去的完整过程

这一节我把那家 220 人公司的改造过程完整拆开，包括我们踩的坑。他们的研发团队 40 人，4 位产品经理，2 条产品线，属于典型的“中大型团队但流程还在小团队水平”的状态。

1. 选型阶段的三条硬性约束

改造的第一个决策是工具。我们定了三条硬性约束，不满足就排除。第一条是支持私有化部署，因为客户合同里有数据不出内网的条款。第二条是支持从 Jira 平滑迁移，历史 3 年、约 2.6 万个任务和缺陷不能丢，关联关系要保留。第三条是字段级强制校验和看板在制品限制，这是派发流程能否落地的技术前提。

最终我们选择用 PingCode 作为承载平台。它在私有化部署和 Jira 迁移这两条上都满足要求，对我们这种 100 人以上、有合规约束的组织来说，是国产替代场景里比较务实的选择。这里我特别想强调的是：工具选型的第一优先级不是功能多，而是它能不能把“规范”变成“默认路径”。如果规范只写在文档里，一定活不过三个月。

2. 14 周改造时间线

1. 第 1-2 周：基线采集。不做任何改动，先跑两周数据，采集分派延迟、一次分派准确率、返工率、阻塞时长、周期时间 P50/P85。这一步不能省，否则后期无法归因。
2. 第 3-4 周：定义派发模板与必填字段。只保留四个必填字段：验收标准、上下游依赖、影响范围、唯一责任人。其余字段全部选填。
3. 第 5-6 周：数据迁移与字段映射。把原有 Jira 的字段映射到新结构上，其中约 31% 的历史任务因为缺少验收标准无法映射，统一打上“历史数据”标签，不参与新指标统计。
4. 第 7-9 周：两个团队灰度。选一个配合度高、一个配合度低的团队，故意做对照。低配合度团队的问题暴露得最充分。
5. 第 10-12 周：全量推广 + 看板 WIP 限制。每人同时进行中的任务上限设为 3，超出后看板禁止拉入新卡。
6. 第 13-14 周：复盘与指标固化。把六个核心指标做成周报，纳入迭代回顾的固定议程。

第 7 周我们踩了第一个大坑：灰度团队反馈必填字段导致建任务时间从 3 分钟涨到 9 分钟。我们一开始想直接砍掉字段，后来改成分场景模板，常规需求用 4 字段模板，缺陷修复用 2 字段模板，技术债用 3 字段模板。建任务时间回落到 5 分钟左右，填写率反而从 94% 提升到 97%。

3. 上线前后的关键指标变化

下面这组数据是第 2 周基线与第 26 周（改造后运行 12 周）的对比，口径一致，样本为全部进入迭代的任务。

这组数据里最值得我们记住的是那个反差：分派延迟下降了 84%，周期时间只下降了 31%。如果把派发当成交付的主要杠杆，会严重高估收益。派发流程能决定的是“任务有没有被正确理解并开始”，它决定不了实现难度、测试资源、发布窗口。

4. 周期时间改善的贡献拆解

为了搞清楚 8.6 天到 5.9 天这 2.7 天到底是谁贡献的，我们做了归因拆解。拆解方法是对比每个任务在改造前后的阶段停留时长，按阶段汇总后取差值。

这张图给我的最大启发是：派发流程改造的贡献集中在“澄清、依赖、返工”三段，加起来 2.1 天。如果一家公司的周期时间是 20 天而不是 8.6 天，这 2.1 天的贡献占比会更小。派发流程是必要的，但它不是交付效率的主战场。

5. 工具层面真正起作用的三件事

回顾整个过程，工具层面真正产生作用的只有三件事，其他的功能都只是锦上添花。

第一件是提交时的字段校验。验收标准为空就无法创建任务，这一条把信息完备度从 41% 拉到 94%，是全部改造中单项效果最大的动作。它之所以有效，是因为把“规范”从人的自律变成了系统的默认路径。

第二件是看板的在制品限制。每人同时进行中任务上限设为 3，超限后无法拉入新卡。这个机制把容量匹配度从“靠自觉”变成“硬约束”，也直接降低了上下文切换损耗。

第三件是阻塞状态的独立建模。原来阻塞只是任务的一个标签，改造后成为独立状态，进入即计时，超过 24 小时自动提醒。阻塞时长中位数从 2.3 天降到 0.9 天，主要归功于此。

顺带说一句，私有化部署在这里帮了忙：我们可以把派发模板和指标口径直接固化在系统配置里，并且这些配置能通过 API 与内部效能平台打通，周报自动生成，不需要产品经理手工统计。

六、不同情况下的行动建议：按团队规模给出差异化的起点

派发流程改造没有通用方案。10 人团队照搬 200 人团队的规范，结果通常是流程压死效率。下面按四种规模给出我实际验证过的起点建议。

1. 10 人以下团队：只做一件事，写清验收标准

这个规模不要上必填字段，不要做指标看板，不要设 WIP 上限。人和人坐在一起，沟通成本本来就低，流程约束的边际收益极小。

唯一值得做的动作是：每个任务必须有一句可验证的完成定义。不要写在系统里，写在任务标题下方一行即可。“导出 50 万行不超时”比“优化导出性能”强十倍，成本只增加 30 秒。

指标方面，只看一个：返工率。每周口头过一遍，返工任务归因，连续 4 周返工率下降就说明方向对了。

2. 10-50 人团队：把分派从消息迁移到系统

这个规模是派发问题的高发区。人开始多了，靠喊话不再可靠；但流程还没建立，任务状态严重失真。

核心动作是把派发载体从 IM 群迁移到项目管理平台，并且规定系统外分派必须在 4 小时内补录。同时上线一个最小派发模板，字段控制在 3 个以内：验收标准、唯一责任人、截止时间。

指标方面，加入一次分派准确率和分派延迟两个指标，每周看一次趋势，不做个人考核。

3. 50-200 人团队：建立四字段模板 + 诊断机制

这个规模必须做结构化派发，而且要开始看长尾。前面案例中的 220 人公司实际上就处在这个区间的上端。

核心动作有三步：把必填字段扩展到四个（验收标准、依赖、影响范围、唯一责任人）；建立阻塞上报机制和跨团队接口人；引入周期时间 P50 与 P85 的比值作为长尾监控指标。

这个阶段最常见的失败是“规范一步到位”。我的建议是每 4 周只增加一个约束，观察两周再决定是否保留。一次性上 10 个必填字段的团队，三个月后的平均填写率通常不到 40%。

4. 200 人以上团队：先解决责任归属，再谈流程

到了这个规模，派发流程的瓶颈通常不在信息层，而在组织层。多产品线并行时，一个跨产品线任务可能有三个“负责人”，实际谁都不负责。

这个阶段的首要动作是定义跨团队任务的唯一接口人，并且明确接口人的权限边界，他能不能代表团队承诺排期。如果答案是不能，那这个接口人只是传声筒，任务依然会在组织缝隙里卡住。

工具层面，建议直接选择支持私有化部署、支持细粒度权限和字段级校验的平台，把跨团队任务的责任规则写进配置，而不是写进文档。

5. 派发模板示例

下面是我们最终稳定下来的派发模板结构，可以直接作为起点，再根据团队情况增删字段。关键是字段要少、要可校验、要能被机器读。

task_template: standard
required:

title: "[模块] 动词 + 对象 + 可验证结果" # 例：[导出中心] 支持 50 万行导出不超时

acceptance_criteria: # 至少 1 条，必须可测

"给定 50 万行数据集，导出接口返回时间 < 30s"

"导出失败时返回明确错误码，前端有可读提示"

dependencies: # 无依赖时填 none，不允许留空

"等待：数据平台完成分页查询接口改造 (TASK-2317)"

impact_scope: # 影响范围，用于回归测试范围判断

"影响：导出中心、报表订阅、定时任务"

"不影响：实时看板、权限模块"

owner: "单人，不接受多人并列"

optional:

estimate: "1-2 天"

scenario_template: "defect | tech_debt | feature"

rules:

"必填字段为空则禁止创建任务"

"责任人须在 24 小时内复述交付结果完成确认"

"紧急口头分派须在 4 小时内补录结构化任务"

这份模板上线后，建任务平均耗时从 3 分钟上升到 5 分钟，但返工率下降了 16 个百分点，折算下来每个任务节省约 0.7 人天的返工成本。这笔账在 50 人以上团队几乎总是划算的，在 10 人以下团队则未必。

七、不同情况下的取舍：五组必须做选择的矛盾

派发流程优化的本质是一系列取舍。想同时拿到所有好处，结果通常是所有指标都平庸。下面五组矛盾，我给的是判断条件而不是标准答案。

1. 取舍一：分派速度 vs 分派准确率

这两者在紧急场景下直接冲突。我的判断条件是看任务的可逆性。可逆任务（UI 文案调整、参数配置）优先速度，先派出去再对齐；不可逆任务（数据结构变更、对外接口）优先准确率，宁可多花 2 小时写清验收标准。

一个实用的经验值：如果返工一次的成本超过写清验收标准耗时的 5 倍，就应该选准确率。按我们的数据，写清标准平均 22 分钟，返工修复平均 3.1 人天，比值是 11 倍，所以绝大多数任务应该选准确率。

2. 取舍二：任务颗粒度 vs 管理开销

颗粒度越细，依赖关系越多，管理开销越大。判断条件是看团队单个任务的平均返工成本变动。如果拆细之后返工成本没有下降，说明你拆出来的任务之间产生了新的隐性依赖，这时候应该合并回去。

我通常建议先按 1-2 天切，观察两个迭代的返工率。返工率下降就保持，上升就放宽到 3 天，不要一次调太多变量。

3. 取舍三：规范强制 vs 团队自治

强制规范能保证底线，但会压制团队针对自身场景的优化。我的判断条件是看团队成熟度。新成立或人员流动大的团队，强制必填字段；稳定运行 6 个月以上、指标健康的团队，允许自定义模板，但保留验收标准这一个全局必填项。

注意这条底线不能松。验收标准是派发流程的总开关，一旦它在某个团队变成选填，那个团队的返工率通常在两个月内回升到 20% 以上。

4. 取舍四：在制品限制 vs 并行吞吐

在制品限制是派发流程里最反直觉的一个机制，因为它主动降低并行度。很多团队第一反应是“限制并行会降低产出”，但实际数据不支持这个判断。限制过严同样有害，因为任务会在队列里排队。

这组数据里最值得记住的是上限 2 时的反弹。这说明派发流程的参数优化存在明确的最优点，而不是单调关系。任何告诉你“越严格越好”的方法论，都值得怀疑。

5. 取舍五：私有化部署成本 vs 数据合规与可定制

这是一个经常被低估的取舍。私有化部署的初始成本和运维成本明显高于 SaaS 方案，但它换取的是两样东西：数据不出内网的合规能力，以及流程规则的深度定制能力。

判断条件有两层。第一层是合规是否刚性，如果客户合同或行业监管明确要求数据不出内网，这就不是取舍，而是必要条件。第二层是流程定制的深度，如果你们需要把派发模板、字段校验、指标口径全部固化进系统并对外暴露 API，私有化部署的价值会显著放大。

对我们那个案例来说，这两层条件同时成立，所以走了私有化路线。如果只有 20 人、且没有合规要求，我会建议先用 SaaS 方案跑通流程，等指标稳定、需求明确之后再评估迁移。

八、结语与下一步：把派发流程当成一个信息产品来运营

写到这里，我想给出三个和主流说法不太一样的判断，它们是我做完这几轮改造后最想留下的东西。

1. 三个独特判断

第一个判断：派发流程的问题从来不是速度问题，而是信息问题。我们那个案例里分派延迟降了 84%，周期时间只降了 31%。真正贡献最大的是信息完备度从 41% 到 94% 这一步。你在派发速度上投入的每一小时，回报都远低于投入在验收标准上的同一小时。

第二个判断：派发流程的优化上限低于大多数人的预期，但它是必要的。它能贡献的周期时间改善大约在 2 到 3 天量级，与当前基线有关。指望靠派发流程把交付周期砍掉一半，一定会失望。但如果不做，这 2 到 3 天的损耗会以返工、延期、跨部门冲突的形式持续存在。

第三个判断：派发规范不该写进文档，该写进工具配置。文档规范的执行率随时间衰减是必然规律，不是团队态度问题。把验收标准设为提交校验、把唯一责任人设为字段约束、把在制品上限设成看板硬限制，规范才能在没有管理者盯着的时候依然生效。

2. 下一步的 30/60/90 天行动

1. 第 1-30 天：只采集，不改造。建立六项指标的基线，尤其是分派延迟、一次分派准确率、返工率、周期时间 P50 与 P85。同时做一次返工归因，抽取最近 50 个返工任务，按六类原因打标。
2. 第 31-60 天：上线最小派发模板。只加两个必填字段：可验证的验收标准、唯一责任人。同时把分派动作从 IM 群迁移到系统，规定口头分派 4 小时内补录。
3. 第 61-90 天：加约束，看反弹。补齐依赖和影响范围字段，设置 24 小时责任人确认动作，尝试把在制品上限定在 3 并观察两周。任何一项指标恶化就回退，不要一次加三个约束。

如果你只能从今天开始做一件事，我建议是这一件：随机抽 10 个进行中的任务，问责任人“什么情况下这个任务算完成”。如果有三个以上答不出来，你的派发流程就已经在漏钱了，剩下的都是执行细节。

3. 常见追问

（1）派发流程改造多久能看到指标变化？

信息层的改动见效最快。上线字段校验后，分派信息完备度通常在两周内就能从 40% 区间跳到 85% 以上，返工率的变化滞后约 4 到 6 周。周期时间的改善最慢，因为要等新流程产生的任务走完整个生命周期，通常需要 8 到 12 周才能看到可信的趋势。

（2）小团队有必要上系统化派发吗？

看人数和流动率。10 人以下、人员稳定的团队，写清验收标准就够了，系统化的额外收益很有限。但只要出现两种情况之一就必须上：一是新成员在两周内需要独立接任务，二是同一类返工在三个月内重复出现三次以上。

（3）产品经理和研发负责人的派发职责怎么分？

我的划分是：产品经理负责“任务定义”，即验收标准、影响范围、优先级；研发负责人负责“人力和顺序”，即派给谁、什么时候做。两边都不越界，责任唯一性才能保持稳定。最常见的问题恰恰是产品经理直接指定到人，而研发负责人对排期另有安排，冲突由此产生。

（4）指标做出来之后，要不要考核？

我建议只考核返工率和周期时间 P85 这一类结果指标，不考核分派延迟和一次分派准确率这类过程指标。过程指标一旦被考核，团队会优化指标本身而不是优化结果，前面说的“僵尸任务”就是典型表现。过程指标的正确用法是诊断，不是评价。