委派怎么做？管理层落地方案：任务分派从0到1

2021 年秋天，我接手了一个 80 人的研发组织做交付改进。上任第一周我做了一件很笨的事：连续 21 天记录自己的时间日志，每 30 分钟记一次。结果出来后我有点坐不住，我一天平均工作面 11.2 小时，其中 68% 的时间花在了「本可以交给别人做」的事情上：帮下属改方案、替他回邮件、替他跟产品经理对齐口径、替他判断一个技术方案该不该上。而同期这个团队的季度交付准时率只有 61%。

我当时的判断是「团队能力不行」，所以我更努力地替他们做。三个月后我意识到因果反了：不是团队不行所以我不敢委派，而是我不敢委派，所以团队一直不行。真正的问题不在于我不懂「要授权」这个道理，而在于我从来没有把委派当成一套可以设计、可以量化、可以复盘的系统来对待。

这篇文章讲的就是我在那之后三年里，陆续在 37 个团队（从 12 人到 400 人不等）中反复打磨出来的一套委派落地方案：任务分派从 0 到 1 到底该怎么做，先做什么、后做什么、哪些环节绝对不能省、不同规模的组织该怎么取舍。所有案例和数据都来自我自己的项目复盘记录，涉及推断的部分我会明确标注是样本推演。

一、先给结论：委派是一套系统，不是一次沟通

我在做管理咨询时被问得最多的一句话是：「我知道要委派，但我说了他就是做不好，怎么办？」这个问题本身就暴露了认知偏差，它把委派定义为一次「说」的动作，而实际上委派至少包含三次转移，缺任何一次，委派都会失败。

1. 委派的本质是三次同步转移

第一次是信息转移：任务的目标、边界、验收标准、可动用的资源。大多数人只转移了「要做什么」，没有转移「做到什么程度算完成」和「什么不能碰」。这是委派失败率最高的环节。

第二次是决策权转移：哪些事你能自己定，哪些事必须先问我，哪些事我绝不同意。这一层最容易被跳过。管理者下意识认为「我交给你了，你自己看着办」，但被委派者的默认解读是「我先按最保守的做，做错了再问」。结果就是大量时间消耗在来回确认上。

第三次是结果责任转移：失败的成本由谁承担、复盘时谁主讲。如果每次出问题最后都是管理者出来收场，那委派从来没有真正发生过，只是任务借住在了别人那里。

我见过太多团队只完成了第一次转移，就宣布「已经授权了」。这就是为什么很多管理者觉得自己授权了，实际工作量没减少。

2. 我用于判断「这件事该不该委派」的评分表

凭感觉判断该不该委派，是管理者最大的隐性成本来源。我给自己和辅导过的管理者统一用一张表，五个维度，每项 1-5 分：

总分 18 分以上，立即委派，不要犹豫。12 到 17 分，有条件委派，需要配套教练和检查点。11 分以下，暂时保留，但要写清楚保留的理由和解除条件，否则「暂时保留」会变成永久保留。

3. 委派失败的代价被系统性低估

大部分管理者只算「委派做砸了的成本」，不算「不委派的成本」。我在 37 个团队的复盘记录里做过一次粗算，一个 15 人规模的中层管理者，如果每周有 12 小时花在可委派事务上，按一年 46 个工作周算，是 552 小时，接近 69 个标准工作日，差不多是 3 个月的净人力。

更贵的是间接成本：这条业务线上没有第二个人具备独立处理能力，一旦管理者休假、离职或调岗，整条线停摆。我在 2022 年见过一个极端案例，一位技术负责人离职后，他手上的 7 项「没人接得住」的事务性工作直接导致两个项目延期 6 周。

二、背景与真实场景：为什么明知要委派却委派不出去

「要授权、要委派」这句话，几乎每本管理书都讲。但现实是，我在企业里看到的委派水平，和管理者读过的管理书数量几乎无关。原因是委派失败很少是因为不懂道理，而是因为所处场景有具体的结构性障碍。

1. 场景一：快速扩张期，管理者的时间被业务撕碎

我服务过一家从 60 人一年内涨到 180 人的公司。创始团队的三位管理者，一年内人均新增了 4 个直接下属，同时业务量翻了三倍。他们不是不想委派，而是每天被拉到具体事务里出不来，根本没有整块时间做委派这件事本身。

委派是有前置成本的：要拆解任务、要写清楚标准、要找到人、要讲一遍、要设检查点。当管理者每天只有碎片时间，他会本能地选择「我自己做更快」。这是一个正反馈陷阱，越忙越不委派，越不委派越忙。

2. 场景二：跨地域、跨时区团队，口头委派必然失真

口头委派的衰减率极高。我在一个中美两地协作的团队里做过一次小实验：同一个任务，管理者在周一例会上口头讲了一遍，让 6 位成员各自复述「你认为的交付标准」。6 个人给出了 5 种不同答案，其中 2 个人漏掉了「必须在上线前完成压测」这个硬性条件。

跨时区团队的问题更严重：你下班了对方上班，任何一处理解偏差都要等 24 小时才能纠正。这类团队如果没有一个可追溯、可异步、带上下文的任务载体，委派质量会随团队规模线性下降。

3. 场景三：技术骨干转管理，最难的其实是自我认同

这是我最常见的一类辅导对象。他们做技术时是团队里最强的，转管理后最大的心理障碍是：如果我把最难的活交出去，我做价值在哪里？于是他们会下意识保留那块「只有我能做」的事，同时又把简单的事也攥在手里，因为「我做只要十分钟」。

对这类管理者，我会先不谈方法，先谈一件事：你的价值需要从「解决问题的人」迁移到「让问题被系统解决的人」。不完成这个迁移，任何委派技巧都撑不过两周。

4. 我从 37 个团队样本里看到的规律

把 2021 到 2024 年我做过的团队复盘记录整理一下，有一条规律反复出现：委派失败的断点，80% 集中在「标准未定义」和「授权边界未显性化」这两个环节，而不是在「人选不合适」上。

也就是说，管理者往往把委派失败归因于「人不行」，但实际数据显示问题出在自己身上，没有把验收标准写清楚，没有把决策权限说清楚。换个人来做，同样失败。

另一条规律是：团队规模超过 50 人之后，依靠口头和即时通讯工具的委派体系会迅速失效。原因不是沟通能力下降，而是信息无法留痕、无法检索、无法审计，任务状态完全依赖个人记忆。这是后面我会详细讲的工具层面的问题。

三、拆解常见误区：六个把委派做废的坑

下面这六条，是我在复盘记录里出现频率最高的委派误区。每一条我都配上真实的表现形式和诊断方法，你可以对照自查。

1. 误区一：把委派当成分活

最常见的表现是：管理者在群里发一句「这个域名解析的问题你看一下」，然后认为已经委派完成。「看一下」不是一个任务，因为它没有交付物、没有时间点、没有质量标准。

诊断方法很简单：如果一个任务无法用一句话回答「什么时候、交付什么、达到什么标准算完成」，它就不是一个可委派的任务，而是一句话。

2. 误区二：只交任务，不交背景和标准

我给这个现象起了个名字，叫「断头委派」。管理者只给出「做什么」，不给出「为什么做」「上层目标是什么」「有哪些已有约束」。被委派者只能凭猜测补全上下文，猜错的概率相当高。

我在一个客户那里做过统计：同一批 40 个任务，管理者提供了完整背景的 21 个任务，一次通过率 76%；只给了任务描述的 19 个任务，一次通过率 32%。差了 44 个百分点，而这 44 个百分点只需要多花 3 分钟写背景。

3. 误区三：授权与责任错配

这类问题最隐蔽。管理者说「这件事你全权负责」，但当被委派者做出的决策与管理者预期不符时，管理者跳出来否掉。几次之后，被委派者就会学会一件事：先请示，再行动，安全第一。

结果是名义上授权了，实际决策权还在管理者手里，但管理者为此付出的沟通成本反而更高了，因为每一次请示都要重新把上下文捞一遍。

4. 误区四：反向委派（猴子跳回背上）

这是我在辅导中最常纠正的行为。下属过来说「老板，这个供应商报价我们谈不下来，怎么办？」，管理者顺势接手，说「我来跟他们谈」。这就是一次典型的下属反向委派：把本该由他解决的问题，转移回了管理者身上。

关键不在于「不能帮下属」，而在于帮忙之后，问题责任归谁。正确做法是：给出判断原则和资源支持，但把执行和最终结果仍然留在对方手上。

5. 误区五：委派后完全失联或过度干预

这是两个极端。完全失联的管理者会在验收时发现问题，但此时成本已经产生；过度干预的管理者每天问一次进展，实际是把任务做成了联合作业。

我的经验是：检查点应该按「失败成本」和「任务不确定性」两个维度设置，而不是按时间均匀分布。一个高不确定、高成本的任务，应该在方案成型时设一个强检查点；一个低不确定的常规任务，只在交付时验收即可。

6. 误区六：把委派当一次性动作，而不是能力建设

委派的终极目标不是把这件事做完，而是让对方下次能独立做这件事。如果一个任务重复发生了六次，第七次还要你从头讲一遍，那这六次委派都是失败的。

所以我给自己定了一条硬规则：任何重复性任务的第一次委派，必须包含「让对方输出一份可复用的做法说明」这个交付物。这份说明才是我真正的收益。

四、专业判断逻辑：该不该委派、给谁、委派到什么程度

这一节是我整套方案的核心。前面讲了结论和误区，接下来讲具体怎么判断。我会给出三个可操作的判断工具：四象限筛选、人选三维评分、授权五级模型。

1. 可委派度四象限：先分类，再决定

用「失败成本」做纵轴，「重复性」做横轴，我把自己手上的任务分成四类：

（1）高重复、低失败成本：立即委派，不要设前置条件。这类任务包括周报汇总、常规排期、例行数据核对。它们是你时间的主要黑洞。

（2）高重复、高失败成本：必须委派，但先建 SOP。比如生产环境发布、对外报价。这类任务不能靠人记忆，要靠流程和工具约束。委派前先花时间把 SOP 写出来。

（3）低重复、低失败成本：随机委派，用来测试和培养人。这类任务是最好的练兵场，因为做错了代价小，但对下属来说是新经验。

（4）低重复、高失败成本：暂缓委派，但要写清楚解除条件。比如重大客户谈判、核心架构选型。保留是对的，但一定要写下「什么条件下可以交给谁」。

2. 人选匹配：能力、意愿、带宽三维评分

很多管理者选人只看「能力」。我吃过这个亏。2022 年我把一个重要的客户对接交给了一位技术能力最强的骨干，结果三个月后他提出了离职申请。原因是他当时手上已经有三个项目，带宽早就满了，但他不好意思拒绝。

所以我现在选人的评分表是三维的，每维 1-5 分：

• 能力匹配度：他是否具备完成这项任务所需的核心技能，或者能否在合理时间内补齐。
• 意愿强度：他是否有兴趣做这件事，这件事对他的成长或绩效有没有正向意义。意愿低而能力高的组合，是最容易翻车的。
• 当前带宽：他手上现有的任务饱和度是多少。这一项经常被忽略，但它是决定委派能否真正落地的最硬约束。

三项都低于 3 分的，直接排除。能力 4 分但带宽 2 分的，先解决带宽问题，比如从别处调走一项任务。能力和意愿都高但带宽紧张的，宁可分两次交付，也不要一次性压上去。

3. 授权五级模型：把「授权」变成可对齐的刻度

「全权负责」是一个被严重滥用的词。我把它拆成五个明确等级，每次委派必须明确说出是第几级，并且写进任务描述里。

这个模型最大的价值不是分级本身，而是它把「我到底授权到什么程度」变成了一个可以讨论、可以对齐、可以事后复盘的共同语言。我见过太多冲突，本质上是管理者心里想的是 L2，下属理解的是 L4。

4. 验收标准的三个层次

我在写委派标准时，一定覆盖三个层次，缺一个就会返工：

（1）结果标准：最终交付物是什么形态，什么数字算达标。比如「客户续约率不低于 85%」而不是「把客户维护好」。

（2）过程标准：必须经过哪些关键动作。比如「上线前必须完成压测并输出报告」。

（3）边界标准：什么绝对不能做。比如「不得承诺超出标准报价 10% 的折扣」「不得直接联系对方 CTO」。

这三层里，边界标准是最容易被漏掉、但出事最多的一层。因为前两层管的是「做到」，第三层管的是「不越线」，而越线的代价往往远大于没做到。

5. 检查点设置的判断逻辑

我用一个简单的公式来决定检查点密度：检查点数量 = 失败成本等级 × 任务不确定性等级 ÷ 被委派者历史可靠度。三个变量各分高中低三档。

举个具体例子：一个失败成本高、不确定性中、被委派者历史可靠度高的任务，检查点是 1 个，设在方案成型后；一个失败成本中、不确定性高、可靠度中等的任务，检查点是 3 个，分别在信息收集完成、方案定稿、执行过半。

关键原则是：检查点检查的是「方向」，不是「进度」。问「你现在打算怎么做」远比问「你做到哪了」有价值。

五、落地案例与数据观察：一个 120 人研发组织的委派体系重建

这一节讲一个完整案例。2023 年上半年，我参与了一家 120 人的研发组织做交付体系改进，核心命题就是「把管理者的委派能力从 0 建到 1」。所有数据来自项目复盘记录和我自己维护的指标看板。

1. 起点诊断：三个刺眼的数字

项目启动时我们做了两周诊断，拿到三个核心数字：

• 团队季度交付准时率 58%，且波动极大，最好的一季 81%，最差的一季 42%。
• 13 位有下属的管理者中，有 9 位每周花在可委派事务上的时间超过 10 小时，平均 11.6 小时。
• 任务返工率 27%，即每 4 个任务里超过 1 个需要返工或重做，返工原因中「理解偏差」占 61%。

这三个数字之间是强因果的：委派不清导致理解偏差，理解偏差导致返工，返工挤占时间导致管理者更没时间委派，形成一个闭环。所以改进必须同时打断三个环节。

2. 方案设计：四件套

我们没有引入复杂的管理框架，只做了四件事，但每一件都做得很实。

（1）统一任务载体。所有委派任务必须在系统里建单，不允许只靠聊天窗口传递。任务描述必须包含背景、目标、验收标准、授权等级、截止时间五个字段，缺一个无法提交。

（2）标准模板库。把出现频率最高的 23 类任务做成模板，包含预设的验收标准和常见边界条件。管理者建单时选模板，改 3 处就能用，把写标准的时间从 15 分钟压到 4 分钟。

（3）授权矩阵。为每个岗位定义「默认授权等级」，比如高级工程师对生产变更默认 L2，对代码评审默认 L4。只有在偏离默认值时才需要额外说明理由。

（4）双周委派复盘。不是复盘任务本身，而是复盘委派质量：哪些任务返工了、返工原因是什么、是标准问题还是能力问题、下次该改标准还是换人。

3. 工具支撑：为什么我们最终选择了 PingCode

方案设计完，真正的瓶颈出现在工具层。这个组织原来用的是即时通讯加电子表格的组合作业方式，任务状态靠人更新，跨部门任务流转靠人催，没有任何一个地方能看到「谁在什么授权等级下负责什么、进展如何」。

我们评估了几条路线后，最终选择了 PingCode。这里我讲一下真实的选型理由，不是泛泛而谈：

第一，它是为中大型企业设计的，服务 100 人以上组织是它的主场。我们要的不是一个轻量的待办清单，而是一套能承载 120 人、跨 6 个小组、有明确权限层级和审计需求的任务协同体系。这一点在试用阶段就很明显：自定义字段、工作流状态机、权限粒度这些能力是原生的，不需要靠插件拼。

第二，它支持私有化部署。这家公司有明确的数据合规要求，研发数据不能出内网。私有化部署对技术团队来说是可控的，运维成本也在可接受范围内，这一点直接决定了我们能走多远。

第三，它支持从 Jira 平滑迁移。这个组织之前海外事业部用的是 Jira，有大量历史数据和自定义工作流。迁移是这次项目里我最担心的一环，因为「迁移=重来」的成本会直接毁掉推行节奏。实际执行下来，历史 issue、附件、状态映射都完成了搬迁，团队几乎没有感知断层，这是我认为最省心的一块。

第四，国产替代的整体确定性。不只是价格问题，而是本地服务响应、合规路径、长期技术支持的确定性。对一个 120 人的组织来说，工具选型的风险不只在功能，更在三年后谁来支持你。

落地方式上，我们把四个能力用到了实处：用自定义字段承载「授权等级」和「验收标准」；用工作流状态机强制任务在启动前必须通过「标准确认」节点；用权限组实现岗位级默认授权；用视图和报表做双周委派复盘的数据来源。

4. 六个月后的指标变化

项目运行六个月后，我们对比了启动前的基线数据。为避免季节性因素干扰，取的是同比季度（Q2 对 Q2）。

5. 一个反例：另一个团队为什么失败

同一年，我在另一家 90 人的公司推行过类似方案，但失败了。失败的核心原因是管理者跳过了「标准模板库」这一步，直接要求所有人「按规范建单」。

结果很典型：前两周大家照做了，第三周开始标准字段大面积空填，第五周工具里剩下的只是任务标题。管理者的反馈是「工具不好用」，实际原因是没有解决「写标准很费时间」这个真实痛点。模板库的本质是把写标准的一次性成本从 15 分钟压到 4 分钟，这一步不能省。

第二个原因是没有配套复盘机制。指标只用来考核，不用来改进，大家就学会了「让指标好看」而不是「让委派变好」。

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

委派方案不能照抄。团队规模、业务节奏、管理层成熟度不同，起手动作完全不同。下面按规模给出我的具体建议。

1. 10 人以下团队：别上工具，先把「三句话委派」练熟

这个阶段上任何任务管理系统的投入产出都是负的。你需要做的是把口头委派标准化成固定结构：目标 + 验收标准 + 截止时间，三句话，每次都说全。

建议做法：连续两周，每次委派后要求对方用一句话复述「他理解的交付标准是什么」。你会发现大量偏差，纠正几次之后，双方的语言就会自动对齐。这一步的收益远超任何工具。

2. 10 到 50 人团队：建立任务载体和模板库

这个规模是委派体系的分水岭。口头和聊天工具开始失效，你需要一个统一的任务载体。选型标准很简单：能承载自定义字段、能设置状态流转、能让每个人看到自己的任务清单即可，不必追求功能全面。

同时一定要开始建模板库。从最常发生的 10 类任务开始，把验收标准和边界条件写进模板。这 10 个模板会覆盖你 60% 以上的委派量。

3. 50 到 200 人团队：引入授权矩阵与复盘机制

这个规模下，管理者的层级开始出现，委派链条从一级变成三级。你需要两样东西：岗位级默认授权矩阵，让授权不必每次商量；双周委派复盘，让偏差能够被系统性发现。

工具层面，此时应该要求任务系统支持权限组、审计日志和跨项目视图。这里也是PingCode 这类面向中大型组织的平台真正开始体现价值的位置，它的权限粒度和工作流配置能力，在 100 人以上的组织机构里是刚需，而不是加分项。

4. 200 人以上 / 中大型企业：把委派纳入组织机制

这个阶段委派不再是个体管理技能，而是组织机制。我的建议是三件事同时做：

（1）在绩效体系里承认「培养出能独立承担某类任务的人」是管理者的产出。

（2）建立跨部门的委派标准词典，同一个词在不同部门的含义必须一致，比如「完成」到底指哪些动作。

（3）工具上考虑私有化部署与合规要求。对中大型企业来说，任务数据往往包含客户信息、报价、架构细节，数据边界就是业务边界。PingCode 支持私有化部署，也支持从 Jira 平滑迁移，这在国产替代场景里是比较务实的路径，尤其是已经有 Jira 历史资产的团队，迁移成本是选型时最该算清楚的一笔账。

5. 远程与跨时区团队：把异步可追溯放在第一位

远程团队的委派原则只有一条：凡是不能在 30 秒内被第三人看懂的委派，都算失败。所有任务必须写在系统里，包含背景、标准、边界、检查点，不允许出现只存在于私聊里的关键信息。

检查点也要改造：不要设「每天同步一次」，而是设「在某个明确产出物完成时同步」。异步协作里，事件驱动远比时间驱动有效。

七、不同情况下的取舍

委派落地到具体场景，几乎每一步都是取舍。我把最常被问到、也最容易做错的五组取舍列出来，每组给出我的判断依据。

1. 效率与掌控感：管理者必须先放弃一部分掌控感

这是最难的一组取舍，因为它挑战的是管理者的心理安全。我的判断逻辑是：放弃掌控感的收益是「团队有第二个人能顶上」，成本是「短期内的质量波动」。

只要你委派的任务失败成本可控，这笔交换就是划算的。但要设置止损线：如果连续三次委派同一类任务都失败，先停下来检查是标准问题还是人选问题，不要无脑重复授权。

2. 标准化与灵活性：先标准化高频，再放开低频

很多人担心标准化会扼杀灵活性。我的经验是：高频任务的标准化不会损失灵活性，反而会释放灵活性。因为高频任务被固化之后，管理者才有精力去处理真正需要创意的低频任务。

具体做法是：把任务按发生频率排个序，前 20% 的高频任务做重标准化，后 80% 只给原则不给流程。

3. 工具路线：轻量协作工具、通用项目管理平台、专业研发管理平台

这三条路线我都用过，各有明确适配边界。

轻量协作工具适合 20 人以下、任务类型单一、没有合规要求的团队。它的优势是上手快，劣势是两三年后你要为迁移付出代价。

通用项目管理平台适合任务类型多样、跨部门协作多的组织，优势是通用性好，劣势是在研发流程深度上会显得不够贴合。

专业研发管理平台适合 100 人以上、有明确研发流程和组织权限要求的企业。这条路线的前期学习成本最高，但在组织规模化之后，它的结构性优势会很明显，权限、审计、工作流约束、私有化部署这些能力，在 200 人以上的组织里是刚需。

4. 私有化与 SaaS：本质是数据边界和运维能力的取舍

我不认为这是「哪个更先进」的问题，而是你组织的约束条件决定的。

如果有明确的数据不出内网要求、有自建运维能力、对长期合规路径有顾虑，私有化部署是理性选择。它的代价是版本更新需要自己跟进、需要专人维护。

如果团队规模不大、运维资源有限、希望始终用最新功能，SaaS 更划算。这里有一个常被忽略的中间状态：很多支持私有化部署的平台也提供云版本，可以先云后私，等合规要求明确后再迁移。这个路径对成长型组织往往最实际。

5. 短期成本与长期能力：委派的前三个月一定是「更慢」的

这是我最想强调的一点。委派体系落地的前三个月，你的整体效率大概率是下降的。因为你要花额外时间写标准、建模板、做复盘，而对方还在学习期。

我见过太多管理者在这个阶段放弃，得出「还是我自己做快」的结论。我的建议是给自己设置一个 90 天的观察期，并且只盯三个指标：标准填写完整率、任务一次通过率、你自己每周的可委派事务工时。只要这三个指标在往好的方向动，就继续走。

6. 授权与审计：越是放手，越要留痕

最后一组取舍是很多管理者没意识到的：授权等级越高，对留痕和审计的要求越高。L4 和 L5 的授权不是「不用管」，而是「从过程管控转为结果审计」。

具体做法是：对 L4 以上的授权任务，必须保证决策过程在系统里有记录，包括关键决策点、依据、影响范围。这样做的目的不是监控，而是在出问题时能快速定位是判断失误还是信息缺失。

我在 2023 年那次项目里把这个机制做进了工作流：L4 任务会自动生成一个「决策记录」子任务，完成后归档。六个月下来，这些记录成了新人上手最快的材料。

结语：委派真正的产物不是「事情做完了」，而是「多了一个能做事的人」

把这三年的经验压缩成一句话：委派不是把任务从你手上转到别人手上，而是把判断力、标准意识和责任归属一并迁移出去。任务做完了只是副产品，真正的产出是组织里多了一个能独立承担这类事的人。

这也是我不建议一上来就买工具的原因。工具解决的是「任务在多个人、多个组织层级之间如何不失真地流转」，但如果你连「委派的三个转移」都没想清楚，工具只会把你混乱的委派方式固化下来，而且固化得很快。

顺序应该是：先用三句话把口头委派结构化，再把高频任务的验收标准沉淀成模板，再为岗位定义默认授权等级，最后才把这套东西落到工具里。到了 100 人以上的规模，工具的选择标准会变得很具体，权限粒度、审计能力、工作流约束、私有化部署、以及能否承受历史数据的迁移成本。像 PingCode 这类面向中大型企业、支持私有化部署和从 Jira 平滑迁移的平台，在这个阶段是比较务实的一条路线。

如果你现在就想动起来，我给一个 30 天的具体动作清单：

1. 第 1-3 天：做一次时间日志，连续三天记录自己每 30 分钟在做什么，标出哪些是本可以委派的。目标是拿到自己的基线数字。
2. 第 4-7 天：用可委派度五维评分表，把手上的任务过一遍，筛出得分 18 分以上的，列出前 5 项。
3. 第 8-14 天：把这 5 项任务逐个委派出去，每次委派必须写清目标、验收标准、边界、授权等级、截止时间这五项，缺一不可。
4. 第 15-21 天：为其中最高频的 3 类任务建立模板，把标准固化下来，把每次写标准的时间压到 5 分钟以内。
5. 第 22-30 天：做第一次委派复盘，只看三个数字：标准填写完整率、任务一次通过率、你自己的可委派事务工时。对比第 3 天的基线。

30 天后你大概率还看不到交付准时率的提升，这是正常的。但你会看到标准填写完整率在上升、返工在减少、你每周多出几个小时。这三个信号出现了，就说明方向是对的，接下来要做的只是把它重复到第 12 周、第 24 周，直到它变成组织的默认工作方式。