任务分派如何做好协办？研发团队数据分析与操作步骤

去年下半年，我给一家 120 人规模的 SaaS 公司做研发效能审计。CTO 递给我的迭代报表看起来很漂亮：承诺完成率 68%，需求交付周期中位数 14 天。但当我把工单数据按「谁派给谁、谁接的单、谁验收的」重新聚合一遍之后，一个被所有管理看板掩盖的事实浮了出来，研发工程师每周平均有 9.4 小时花在别人派过来的协办任务上，而「协办工时」这个口径在这家公司的任何一张报表里都不存在。

更麻烦的是，这 9.4 小时里有 41% 是重复的、可以合并的，或者根本不应该由工程师来做。他们并不是协作效率低，而是没有一套把「协办」当作独立任务类型来管理的机制。这篇文章我会把这套机制拆开：先给结论，再复盘真实数据，然后拆误区、给判断逻辑、给可执行的操作步骤，最后讲清楚不同规模团队该怎么取舍。

一、先给结论：协办的瓶颈不在「沟通不够」，在分派结构

我前后复盘过 30 多个研发团队的协办流程，从 15 人的创业团队到 800 人的上市公司研发中台。有一条结论反复出现，而且和大多数管理者的直觉相反：协办做得好的团队，协办任务的数量反而更少。

这不是因为他们「协作意愿低」，而是因为过滤机制前移了，不该派的单在派之前就被拦掉，该派的单在派出去的时候就带齐了上下文、验收标准和预期工时。剩下真正需要协办的，执行效率自然高。

1. 四条我反复验证过的稳定规律

• 协同工具用得越花哨的团队，协办效率不一定越高。我见过用三个工具做自动化的团队，协办返工率反而比只用一张看板的团队高 9 个百分点，因为自动化只覆盖了「通知」，没覆盖「验收」。
• 协办任务的平均在途时间，通常是自驱任务的 2.3 倍。这个倍数在我统计过的样本里相当稳定，跨行业、跨技术栈差别不大。
• 粒度过粗的协办单，返工率是细粒度单的 3 倍以上。「帮忙看下支付模块的问题」这类单子，一次通过率通常不到 35%。
• 有明确验收标准的协办任务，一次通过率能到 80% 以上。这是全部变量里影响最大、改造成本最低的一个。

2. 一个反常识的判断：协办不是「帮忙」，是一类需要独立排队的任务

绝大多数团队的隐含假设是：协办任务是「优先级最高的临时任务」，谁被派到谁就插队做。这个假设在两三个人的团队里成立，在 50 人以上的团队里必然崩塌。

原因很简单：插队是有成本的，而且成本由被打断的人承担，不由派单的人承担。一个后端工程师被打断一次深度编码，恢复专注平均需要 11 到 23 分钟。如果一天被打断 4 次，光恢复成本就吃掉 1 到 1.5 小时，这部分损耗从来不会出现在任何工单系统里。

3. 协办治理的最小可行框架：结构层、容量层、反馈层

我把协办治理拆成三层。这三层不是并列的，是有依赖顺序的：结构层没做好，容量层怎么调都是瞎调；容量层没做好，反馈层拿到的数据全是噪音。

结构层解决的是「这个任务该不该派、派给谁、派出去的时候带什么信息」。它决定了协办任务的质量下限。

容量层解决的是「一个人同一时间最多背几个协办任务」。它决定了协办任务不会把主线工作挤垮。

反馈层解决的是「协办完之后，我们怎么知道做得好不好、下次要不要改」。它决定了这套机制会不会在三个月后自然腐化。

二、真实场景：一个 120 人研发团队的两周协办审计

先交代背景。这家公司做企业级 SaaS，120 人，其中研发序列 107 人：后端 42、前端 31、测试 24、运维 10。公司当时已经在用一套工单系统管理需求，所有工作项都在同一张看板上，按「优先级」排序。

CTO 找到我的触发点是：迭代承诺完成率连续三个季度在 65% 到 70% 之间徘徊，但团队访谈里没人觉得自己在偷懒，也没人觉得需求排得离谱。这种「大家都很忙、结果就是出不来」的状态，通常意味着有大量工时消耗在统计口径之外。

1. 我们是怎么取数的

取数方式分三块，缺一不可。只做其中任何一块，结论都会偏。

1. 工单系统全量导出：导出连续 8 周、共 4,312 条工作项的创建时间、认领时间、首次状态变更时间、完成时间、重开次数、派单方与协办方 ID。
2. 工程师深度访谈：32 份，覆盖每个小组至少 3 人，重点问「你上一次帮别人做事，是怎么被通知的、花了多久、最后怎么算完成」。
3. 一周日历时间采样：随机抽取 24 名工程师，连续 5 个工作日按 30 分钟颗粒度记录时间归属，用来校正工单数据里「缺失的那部分工时」。

第三块是最容易被跳过的，也是最关键的。因为口头协办、即时通讯软件里的协办、走过去拍肩膀的协办，根本不会进工单系统。如果只看工单数据，你会得出「协办占比只有 6%」这种自欺欺人的结论。

2. 取数结果里三个最扎眼的数字

校正之后的数字是这样的：

第一个数字是 9.4 小时。这意味着一个工程师每周大约有四分之一的工作时间在做别人派来的事，而这些事从未进入任何排期。

第二个数字是 41%。我们把这 9.4 小时里的每一条协办任务拿给派单方和协办方双方复核，双方都同意「可以合并、可以延后、或者根本不需要工程师做」的比例是 41%。折算下来，这家公司每周有大约 410 人时，也就是约 51 人天的工作量本可以不发生。

第三个数字是返工率 27.4%。这在所有我统计过的团队里属于中位偏上，不算最差。但关键在于，这 27.4% 的返工工时，100% 是隐形的，它没有被重新排期，只是把协办方自己的任务往后挤。

3. 团队当时的真实反应

我把数据交回去的那次会议，最有意思的不是数字本身，而是反应。

一位后端组长说：「这些本来就是顺手的事，谁没帮过谁。」这句话几乎是所有团队的第一反应，它背后的隐含假设是，协办是人际关系的润滑剂，不该被流程化。

但当我把他组里一位工程师的日历投出来，那位工程师在周三一天之内被打断 6 次，当天自己的核心任务一行代码没写，他的表情变了。

这就是我想强调的判断：协办不是不能做，是不能不计量地做。不计量不等于不存在，只等于成本被隐性转移给了最不该承担的人。

三、拆解四个最常见、也最贵的误区

在给出判断逻辑之前，我先把四个反复出现的误区摊开。这四个误区我几乎在每个团队都能找到至少两个，而且它们造成的损耗是可以量化的。

1. 误区一：把协办当成「优先级最高的临时任务」

现象：协办任务不排期、不估时，谁被派到谁立刻做，做不完就加班。

为什么错：这个做法的隐含假设是「协办任务都很小」。但数据不支持这个假设，在我统计的样本里，协办任务实际耗时的第 75 分位是 4.2 小时，第 90 分位是 11 小时。也就是说，每十个协办任务里就有一个要吃掉超过一整天，而这一个在派单时通常被描述成「很快，麻烦看一下」。

怎么改：协办任务必须估时，且估时是派单方的责任，不是协办方的责任。没有估时的协办单，不允许进入协办队列。

2. 误区二：用同一张看板管理自驱任务和协办任务

现象：所有工作项按「优先级」排在一张看板上，协办任务和迭代需求混在一起。

为什么错：这两类任务的调度逻辑根本不同。自驱任务服从迭代节奏，可以提前几周规划；协办任务服从外部事件，天然是突发性的。把两者混在一起，结果只有一个：协办任务不断插队，迭代承诺不断延期，而每次延期的原因在报表上都显示为「优先级调整」。

怎么改：独立的协办泳道或协办队列，与迭代看板物理隔离，只在「个人容量」这一层做汇合。

3. 误区三：只考核响应速度，不考核返工

现象：管理者盯着「协办响应时长」，要求 4 小时内必须接单。

为什么错：这是一个典型的单指标优化陷阱。当响应速度成为唯一KPI，协办方的最优策略是「秒接单、然后放着」，响应时长好看了，实际启动等待反而更长。更糟的是，为了快，协办方会跳过确认环节直接动手，返工率随之上升。

怎么改：响应时长必须和「启动等待时长」「一次通过率」成组考核，三者缺一不可。这是我坚持的一条硬规则。

4. 误区四：让协办方自己决定什么时候做

现象：派单方把任务丢过来，说「你看着安排」。

为什么错：这个说法表面上是尊重，实际是把排期风险和沟通成本单方面转移给协办方。协办方既不知道派单方的真实截止时间，也不知道这个任务在上游链路里的位置，只能靠猜。猜错的后果由协办方承担。

怎么改：派单方必须给出「期望完成时间」和「最晚可接受时间」两个时间点，并说明超期的业务影响。协办方在承诺窗口内给出自己的排期，双方就此达成书面确认。

四、专业判断逻辑：协办能力的三层模型

拆完误区，讲我实际使用的判断框架。我不会用「协作文化」「团队氛围」这类词来评估协办，因为它们不可测量、不可干预。我用的是三层模型，每一层都有对应的可观测指标。

1. 结构层：任务分派的粒度与责任边界

结构层要回答三个问题，缺一个都会导致后面两层失效。

• 这个任务为什么必须由这个人做？如果答案是「因为只有他熟」，那这就是个知识集中度风险，不是协办需求，应该被转成知识沉淀任务。
• 产出物的验收标准是什么？必须是可判定的，比如「接口返回体新增三个字段并通过联调」「测试环境这条用例稳定通过 5 次」，而不是「看下有没有问题」。
• 协办方需要投入多少时间？派单方给的估时，允许有偏差，但不允许空缺。

我的经验判断是：一个协办任务如果在 10 分钟内无法写清上面三条，那它大概率不该被派出去，而应该先由派单方自己做一轮排查。这一步过滤，通常能砍掉 30% 到 40% 的协办量。

2. 容量层：协办预算与在制品上限

容量层是我认为被严重低估的一层。大多数团队管住了需求在制品，却没管住协办在制品。

协办预算的意思是：每个角色每周有固定的协办工时额度，超出部分需要走升级流程。这个额度不需要精确，但必须存在。我给的建议起步值是按角色差异化设定：后端 12%、前端 12%、测试 15%、运维 30%。注意运维的数字，运维的支持性工作是岗位属性，不该被当成异常。

在制品上限（WIP Limit）的意思是：一个人同一时间未完成的协办任务，最多 N 个。这个 N 我通常建议从 3 开始。为什么是 3？因为当 WIP 超过 3 时，协办方会开始出现「都在做、都没做完」的状态，而每多一个并行任务，上下文切换损耗呈非线性上升。

3. 反馈层：验收与返工归因

反馈层的核心动作只有一个：每一次返工都要归因，而且归因到具体类别，不是归因到人。我用的归因类别是四类：

1. 需求描述不清，派单方的责任。
2. 验收标准缺失，派单方的责任。
3. 技术判断偏差，协办方的责任。
4. 环境或依赖阻塞，流程的责任，通常指向环境稳定性或依赖治理。

按这四类归因跑一个月，你就能看出问题的真实分布。在我服务过的团队里，前两类（派单方责任）通常占到返工总量的 55% 到 65%。这个结论会改变整个团队对「协办做得不好」的归因方向。

4. 三层之间的关系：不是并列，是依赖

我要特别强调依赖关系，因为很多团队会跳过结构层直接做容量层，结果就是「给了一堆描述不清的任务设了上限，协办方反而更困惑」。

正确的顺序是：先用结构层把任务质量拉起来，再用容量层做保护，最后用反馈层做持续校准。倒过来做，多半会失败。

五、研发团队的数据分析：该看哪几个指标，怎么算

讲完判断逻辑，落到具体指标。我不建议一上来就上十个指标，会淹没重点。下面五个是我认为的最小必要集合，每个都有明确口径。

1. 五个核心协办指标的定义与口径

注意「协办工时占比」这一行我写了「<5% 也异常」。这不是笔误。如果一个团队统计出来的协办占比低于 5%，几乎可以断定统计口径漏了。在真实的研发组织里，完全不产生协办是不可能的，低于 5% 通常意味着大量协办走的是即时通讯和口头，根本没进系统。

2. 一个可直接落地的计算示例

下面这段 SQL 是我在多个项目里用过的模板，稍作字段名调整即可套用。它的关键设计是：把「接单」和「首次状态变更」当作两个独立时间点。很多团队只记录创建和完成，这样就永远看不到「接了单但不动手」这段最长的等待。

WITH assign AS (
SELECT

t.id,

t.assignee_id,

t.reporter_id,

t.created_at,

t.accepted_at, — 协办方点「接单」的时间

t.started_at, — 首次状态变更的时间

t.done_at,

t.reopen_count,

t.estimate_hours

FROM work_item t
WHERE t.type = '协作'                             -- 与自驱任务物理隔离的类型
AND t.created_at >= DATE_TRUNC('week', CURRENT_DATE) - INTERVAL '8 weeks'
)

SELECT
DATE_TRUNC('week', created_at)                                          AS 周次,
assignee_id                                                             AS 协办方,
COUNT(*)                                                                AS 协办任务数,
ROUND(SUM(estimate_hours), 1)                                           AS 承诺协办工时,
ROUND(AVG(EXTRACT(EPOCH FROM (accepted_at - created_at)) / 3600), 1)     AS 认领响应时长_小时,
ROUND(AVG(EXTRACT(EPOCH FROM (started_at  - accepted_at)) / 3600), 1)     AS 启动等待时长_小时,
ROUND(AVG(EXTRACT(EPOCH FROM (done_at    - created_at)) / 3600), 1)       AS 全链路在途时长_小时,
ROUND(SUM(CASE WHEN reopen_count > 0 THEN 1 ELSE 0 END)::numeric
/ COUNT(*), 3)                                                    AS 协办返工率
FROM assign
GROUP BY 1, 2
ORDER BY 1, 8 DESC;

这段查询跑出来的结果，通常第一眼就会让人吃惊：全链路在途时长和承诺协办工时之间的比例，往往在 5 倍到 12 倍之间。也就是说，一个承诺 2 小时的协办任务，可能在整个链路里挂了 20 小时。这中间的时间不是协办方在干活，而是在排队。

3. 指标之间的相互制衡，比单个指标更重要

单独看任何一个指标都会被误导，我列三组必须成对看的组合。

• 认领响应时长 ↓ 与 启动等待时长 ↑：典型的「秒接单然后放着」，说明响应速度考核被玩坏了。
• 协办工时占比 ↓ 与 一次通过率 ↓：说明协办方在压缩投入、敷衍交付，不是效率提升。
• 协办任务数 ↓ 与 迭代准时率 ↑：这才是真正健康的信号，说明过滤机制起作用了。

4. 帕累托分析：协办需求到底从哪来

在上面那家公司的数据里，我做过一次协办需求来源的帕累托分析，结论非常有代表性：前四个来源吃掉了 72% 的协办量。

这个分析的意义在于：如果协办量集中在少数几个来源，你根本不需要优化整个协办流程，只要把那几个来源掐掉，总量就下来了。这比「提升全员协作意识」有效得多。

六、以 PingCode 为例：从任务分派到协办闭环的七个操作步骤

讲完方法论，落到工具落地上。这里我以 PingCode 为例来说明具体操作步骤，原因是它的工作项模型对「协办」这类任务类型有原生支持，且面向中大型研发组织设计，PingCode 主要服务中大型企业及 100 人以上组织，这个规模恰好是协办问题最突出的区间。

1. 为什么这个场景更适合中大型研发组织

20 人的团队用一张看板加几次站会就能把协办管住，因为所有人的上下文都在脑子里。但组织一旦超过 100 人，问题会同时从三个方向恶化：

• 跨部门协办出现：产品、运营、售前、客户成功都会向研发派单，来源分散。
• 知识集中度上升：「只有他熟」的情况变多，协办从协作退化成依赖。
• 统计口径失真：人一多，口头协办的比例上升，管理层看到的数据和真实情况差距拉大。

这三个问题都不是「加强沟通」能解决的，必须靠工作项类型、独立队列、字段约束和度量看板来强制。下面是我实际用过的七个步骤。

2. 操作步骤

（1）建立独立的「协作」工作项类型

不要复用需求或缺陷类型。新建一个「协作」类型，与迭代看板物理隔离。这一步是整个方案的地基，因为它让协办任务可以被单独统计、单独设限、单独度量，不会污染迭代数据。

（2）给协作类型配置必填字段约束

至少强制四个字段：验收标准（多行文本，必填）、派单方预估工时（数值，必填）、期望完成时间（日期，必填）、最晚可接受时间（日期，必填）。没有这四个字段，工单创建按钮就应该是不可点的。这比任何流程宣贯都有效。

（3）在个人视图里设置协办队列与 WIP 上限

为每个协办方建立独立的「我的协办」视图，并设置在制品上限为 3。达到上限后，新协办任务进入「待接收」池而不直接进入个人队列。这一步的关键是让「接不下」成为一件可以公开说的事，而不是靠个人硬扛后的沉默延期。

（4）把接单与开始做成两个独立状态

这一步直接决定了你能不能度量「启动等待时长」。状态流转设计为：待接收 → 已接单 → 进行中 → 待验收 → 已完成。其中「已接单」是协办方承诺排期的动作，「进行中」是真正开始动手。两个时间点分开记录，指标才有意义。

（5）验收环节强制填写结果与归因

派单方在验收时，必须选择「一次通过」或「退回重做」，退回时必须选择归因类别（描述不清／标准缺失／技术偏差／环境阻塞）。这个动作每次只多花 10 秒，但一个月后你就能拿到非常清晰的返工分布。

（6）建立协办度量看板

看板至少包含五个卡片：协办工时占比（按人、按周）、启动等待时长趋势、协办一次通过率、返工归因分布、协办来源帕累托。前四个用于管理，第五个用于治理。

（7）设置自动化提醒但不要滥用

只配三条自动化规则：接单后 24 小时未进入「进行中」提醒协办方；超过最晚可接受时间前 8 小时提醒派单方和协办方；验收退回后自动创建归因记录。多一条都会变成噪音，而噪音会让人关掉通知，这是很多团队自动化失败的真实原因。

3. 数据观察：上线前后八周对比

上面这家 120 人公司按这七个步骤落地之后，八周的数据变化是这样的。注意我把「协办工时占比可解释率」也放进去了，这一项从「无口径」变成 96%，是全部变化里最有价值的一项，因为它意味着隐性成本被显性化了。

4. 私有化部署与迁移场景下的注意事项

我在服务中大型企业时，遇到最多的一类额外需求是部署形态和数据迁移。这两件事如果不在方案设计阶段考虑，会在落地三个月后变成大麻烦。

第一，私有化部署对协办治理有实质影响，不只是合规问题。因为协办度量涉及跨部门的工时数据，如果这些数据在多个系统之间割裂，帕累托分析和归因分布就跑不出来。把工作项、度量看板、自动化规则放在同一个可私有化部署的体系内，能省掉大量数据对齐成本。PingCode 支持私有化部署，这一点对金融、制造、政企这类数据不出内网的团队是硬约束。

第二，如果团队原本在使用 Jira，迁移时最容易丢掉的是历史状态时间戳。「接单时间」「首次启动时间」这些字段如果在迁移中被压平，你新体系上线后的前三个月是拿不到趋势数据的。PingCode 支持 Jira 平滑迁移，这一点对于需要在国产替代过程中保持度量连续性的团队很重要，这也是它被视为国产替代主要选项之一的原因。

第三，迁移不要一次性全量切。我的建议是先切一个 100 人左右的部门，跑满两个完整迭代，确认协办度量口径无偏差后再推全量。协办数据对口径极其敏感，全量切换后发现问题，回溯成本很高。

七、不同情况下的行动建议

方法论讲完了，但直接照搬一定失败。下面的建议按团队规模分层，因为协办问题的性质在规模上会发生质变。

1. 团队 20 人以下：不要上流程，只需要一个约定

这个规模下，我强烈建议不要建协办队列、不要设 WIP 上限、不要做度量看板。理由很简单：20 人以下的团队，人与人之间的上下文是共享的，流程成本会大于收益。

你只需要一个约定：任何协办请求，必须说明「要什么」和「什么时候要」，并且必须在书面渠道（工单或群聊消息，不能是口头）提出。就这一条，能解决这个规模下 80% 的协办问题。

唯一值得投入的是知识集中度治理。如果某个人的名字在协办请求里反复出现，那不是流程问题，是知识风险，应该安排知识沉淀而不是给他设 WIP。

2. 团队 20-100 人：建协办队列，开始度量

这是协办问题开始显性化的区间。行动建议按优先级排：

1. 先做结构层：协作任务独立类型 + 验收标准必填 + 派单方估时必填。这三条能拿到 60% 的收益。
2. 再做容量层：按角色设协办工时预算，WIP 上限从 5 开始，跑两周后收紧到 3。
3. 最后做反馈层：四类返工归因，月度复盘一次，只讲分布不讲人。
4. 度量只上三个指标起步：启动等待时长、一次通过率、协办工时占比。不要一开始就上十个。

这个规模下最常见的失败模式是「一次全上」。十个指标 + 五条自动化规则 + 强制每日更新，结果两周后所有人开始绕过系统。我的经验是每两周只加一个新机制，让团队有时间消化。

3. 团队 100 人以上：协办治理是组织问题，不是工具问题

到了这个规模，协办问题会分化成两类，处理方式完全不同。

第一类是跨部门协办。产品、运营、售前向研发派单，这类协办的关键不是效率，是预算制。我建议给每个非研发部门分配固定的月度研发支持额度，用完了就要走升级流程。这个做法看起来强硬，但实际效果远好于「提升跨部门协作意识」。

第二类是研发内部协办。这类要继续用前面的三层模型，但需要一个额外的动作：按领域设「协办责任人」而不是随机派单。让同一领域的协办请求集中到固定的人，会显著降低上下文切换成本，代价是知识集中度上升，需要用轮换机制对冲。

八、不同情况下的取舍

最后讲取舍。前面所有建议都有代价，我把最需要决策的三组取舍摊开讲。

1. 强流程 vs 弱流程：什么时候该忍

强流程的收益是可度量和可预测，成本是灵活性下降和一定程度的逆选择，工程师会倾向于把难判断的事推给流程，而不是自己拍板。

我的判断标准是看协办任务的重复度。如果同一个来源的协办重复出现三次以上，就该强流程；如果是低频、每次都不一样的协办，强流程只会制造额外负担，应该走快速通道，事后补录。

这里有个容易被忽略的取舍：快速通道必须存在，而且必须被允许事后补录。如果所有协办都必须先建单再动手，紧急问题会被流程阻塞，团队会开始整体绕过系统，那时候你连数据都没有了。

2. 自建 vs 采购：什么时候该买

我见过不少团队尝试用开源工具加自研脚本拼一套协办度量。三个人的团队这么做没问题，100 人以上的团队我要提醒几个隐性成本：

• 状态时间戳的完整性。自研方案经常只记录创建和完成，中间状态靠日志解析，一旦日志轮转或格式调整，历史数据就断了。
• 跨部门权限模型。协办度量天然涉及跨部门数据可见性，自研方案在这个环节的返工概率极高。
• 私有化与合规。如果数据不能出内网，就要评估自研方案在内网环境下的可维护性。

反过来，如果团队的协办场景高度特殊（比如硬件研发的跨专业协作），标准工具的工作项模型确实套不上，那自研或深度定制是合理的。这种时候我会建议先采购、再定制，而不是从零自建，把标准能力当底座，把差异化部分做在上面。

3. 考核协办方 vs 考核派单方：只能选一个先做

这是一个我认为最需要明确立场的问题。我的判断是：在协办质量还没起来的阶段，只能先考核派单方，不能考核协办方。

原因是数据分布。前面提到，返工总量中派单方责任通常占 55% 到 65%。如果你在这个阶段去考核协办方的响应速度和完成率，结果只有两个：协办方开始趋于保守、能推就推，或者开始敷衍交付、只求验收通过。两种结果都会让数据变得更差，而不是更好。

正确的顺序是：先用「协作任务描述完整率」「验收标准填写率」这类派单方指标把任务质量拉起来，等一次通过率稳定在 80% 以上，再引入协办方维度的效率指标。这个顺序反过来做，我见过很多次失败。

九、总结：协办的本质，是让容量被看见

回到最开始那家公司的例子。八周之后，他们的协办工时占比从 21.7% 降到了 13.4%，但我想说的不是这个数字，而是一个更根本的变化：团队终于能说出「我这周做不了」这句话，而且这句话是被系统支持的，不是靠个人硬扛。

这是我对协办治理最核心的观点：协办的难点从来不是沟通技巧，也不是工具选型，而是让一个人的真实容量被组织看见。在看不见容量的组织里，协办会无限扩张，直到有人崩溃或者离职，然后问题换个地方重新出现。

所以我给协办治理定的目标不是「消灭协办」，也不是「让协办效率最大化」，而是把协办的损耗控制在一个可持续区间内，并且让这个区间是可见的、可讨论的、可调整的。在这个前提下，剩下的都只是操作问题。

如果你现在就要动手，我的建议是按下面的顺序推进，不要跳步：

1. 本周：做一次工时采样。随机抽 20 个人，连续三天按 30 分钟颗粒度记录时间归属。不要用系统的数据，因为系统数据大概率漏了 70% 的协办。
2. 下周：把采样结果和工单数据做交叉比对，算出你的真实协办工时占比。如果低于 5%，先怀疑口径，不要怀疑结论。
3. 第三周：只做一件事，给协作任务加上「验收标准」和「派单方估时」两个必填字段。别做其他的。
4. 第四周：跑一次返工归因，看看四类责任分布在哪个区间。这个分布会告诉你后面该往哪个方向投入。
5. 第六周：在结构层稳定之后，再引入 WIP 上限和协办度量看板。此时你拿到的数据才是有意义的。

整个过程大概需要一个半月，投入不超过 20 人天。相比每周被隐性消耗掉的 400 多个人时，这是我认为研发管理里性价比最高的一次投入之一。