取消落地方案：项目经理开展任务执行的效率提升案例解析

2024年第一季度，我参与复盘了一家130人规模研发组织的季度交付项目。项目经理团队投入将近三周，产出四份合计89页的《落地方案》，经过两轮评审会并全部签字确认。项目结束后，我抽查了这批文档在企业云盘里的访问日志：89页里有61页的累计阅读次数是1，也就是作者上传时打开的那一次。

同一批项目里，真正被反复打开、被复制进任务系统、被打印出来贴在工位旁边的，只有方案最后那两页的任务清单和责任人分工表。这个反差逼着我们做了一个当时看起来挺冒险的决定，直接取消《落地方案》这个交付物本身。半年后，这个组织的需求交付周期缩短了约34%，而项目经理花在文档上的工时下降了六成以上。

这不是一个"反文档"的故事，也不是"把方案搬到看板上就万事大吉"的工具广告。我想讲清楚的是：当项目经理把精力从"写方案"转移到"拆任务、定验收、清障碍"上时，效率提升究竟从哪里来，边界在哪里，以及什么样的组织根本不该学这一招。

一、核心结论：取消的是文档形态，不是规划行为

先把结论摆在前面。我做了三年多项目管理体系改造，参与过制造业、金融科技、SaaS 三个行业共十一个项目的流程重构。关于"取消落地方案"这件事，我有四条判断，其中第一条最容易被误读。

1. 被取消的是"文档交付物"，不是"规划动作"

大多数项目经理听到"取消落地方案"，第一反应是"那我不做规划了？"。这是一个典型的偷换概念。落地方案在多数组织里承担两种功能：一种是思考载体，帮项目经理想清楚路径；另一种是交付凭证，证明"我认真规划过了"。

取消的只是后者。前者必须保留，而且要做得更细、更早、更贴近任务颗粒度。区别在于，思考的产物不再沉淀成一份 30 页的文档，而是转化成系统里可跟踪、可分配、可验收的任务卡片和验收口径。

我见过的失败改造，几乎都是把两件事一起砍掉了：既不发方案，也不做拆解，直接让团队"自己看着办"。结果三周后所有人都在等指令，进度比原来更差。

2. 效率提升的真正来源是"决策前置"，不是"少写字"

减少文档工时只是表象。真正带来效率提升的，是把原本藏在方案第 17 页的模糊判断，提前逼到台面上变成明确决策。

举个例子。落地方案里常见的一句话是"系统需在第二季度完成与财务模块的对接"。这句话写进文档没人会追问，因为它看起来完整。但当你把它拆成任务时，问题立刻暴露：对接哪几个字段？历史数据要不要迁移？接口谁提供？失败重试策略谁定？验收人是谁？

这五个问题只要有一个没有答案，任务就没法进入执行队列。于是项目经理被迫在项目启动后的第三天就把这些问题问清楚，而不是在第四周开发做到一半时才发现财务那边根本没排期。效率提升来自这里。

3. 能取消的前提是任务颗粒度足够细，且验收标准可判定

一个粗糙的落地方案，换成粗糙的任务列表，结果只会更糟。落地方案至少还有叙事逻辑，粗糙的任务列表连上下文都没有。

我给自己定的准入门槛是：单个人天在 0.5 到 5 之间的任务，占全部任务的比例必须超过 70%。低于这个比例，说明任务还停留在"模块级"，此时取消方案等于把风险从文档转移到了执行现场。

另一个硬指标是验收标准。每个任务的完成定义必须能被第三方独立判定，不能出现"优化了性能""完善了体验"这类表述。我在内部推行的规则是：验收标准里不允许出现形容词，只允许出现可观测的动作、数字或状态。

4. 项目经理的角色从"写方案的人"变成"拆任务和清障的人"

这是我认为最有价值的转变。过去项目经理的核心产出是文档，评价标准是"方案写得全不全、逻辑清不清楚"。取消落地方案后，产出变成三件事：拆解到可执行颗粒度的任务、每天更新的阻塞清单、每周更新一次的风险与决策记录。

这带来的直接变化是，项目经理的日程结构变了。以前启动阶段集中三周写方案，之后进入相对空闲的跟踪期；现在启动阶段压缩到三到五天，但整个项目周期里每天都有 60 到 90 分钟花在清障和确认上。总量没减少，分布更均匀，价值也更高。

二、背景与真实场景：三份落地方案的真实命运

为了让讨论不飘在空中，我把三个场景摊开讲。它们来自同一家企业的三个不同季度，分别对应三种典型的落地方案使用方式。

1. 场景一：89页方案，61页只被打开过一次

这是文章开头提到的那份。结构完整得挑不出毛病：项目背景、目标、范围、里程碑、资源计划、风险登记册、沟通机制、验收标准，八个章节一个不缺。评审会上，业务方负责人说"写得很全面"，技术负责人说"方向没问题"。

问题出在评审会之后。我追踪了这份文档在项目周期内的访问记录：第1周有19人打开过，第2周降到6人，第3周只剩3人，第4周之后稳定在1到2人。而这1到2个人，主要是项目经理自己在更新和检查。

更有意思的是页面级数据。被反复打开的页面集中在三处：里程碑甘特图那一页、责任人分工表那一页、以及风险登记册里标红的四条。其余六十多页，包括我写得很用心的架构演进路径和分阶段价值论证，访问次数始终是1。

2. 场景二：方案评审通过 ≠ 任务可执行

第二个项目里，我们做了个对照实验。方案评审通过当天，我随机抽了 15 个开发人员，问他们三个问题：你下周要做什么？你要交付的东西凭什么算做完？卡住了找谁？

15个人里，能清楚回答第一个问题的有11个，能回答第二个的只有4个，能回答第三个的有9个。也就是说，方案通过了，但 73% 的人不知道自己交付物的验收口径。

这不是执行力问题，是信息转换断层。落地方案用的是管理层语言，任务执行用的是工程语言，中间缺一层翻译。过去这层翻译靠项目经理口头传达，人数一多就衰减得厉害。

3. 场景三：真正被反复读的，其实只有任务清单那两页

第三个项目里我换了个做法：不做全量方案，只做一份 6 页的执行说明书，其中 4 页是任务清单，明确到人、到天、到验收物。项目中期我统计了这份文档的访问数据，平均每人每周打开 2.7 次。

对比前两个项目，我发现一个规律：文档被阅读的频率，与它距离"我明天要做什么"的距离成反比。凡是能直接回答这个问题的内容，阅读率高；凡是回答"这个项目的战略意义"的内容，阅卷率趋近于零。

这个规律后来成了我判断文档该不该留的核心标准：如果一段内容不能改变任何人的下一步动作，它就不该出现在执行类文档里。

三、拆解五个常见误区

在我推动这个改造的过程中，遇到最多的不是技术阻力，而是认知阻力。以下五个误区，每一个我都亲身踩过或见过别人踩。

1. 误区一：把"取消落地方案"等同于"不规划"

最普遍的一个。团队听说不发方案了，第一反应是松一口气，然后开始凭感觉干活。三周后进度失控，大家回头说"还是得有方案"。

我的判断是，取消方案实际上让规划的要求变高了，而不是变低了。写方案时你可以用模糊语言掩盖没想清楚的地方，拆任务时你没法掩盖，任务卡片上不写清依赖关系，第二天就有人卡住来找你。

所以我在推行时有个硬性配套动作：取消方案文档的同时，必须建立任务拆解工作坊机制。启动会从"宣讲方案"变成"现场拆任务"，一屋子人坐两小时，把里程碑拆到周、把周任务拆到人。

2. 误区二：以为把文档搬进工具就自动提效

第二个误区是把管理问题当成工具问题。很多团队的做法是：把 Word 里的方案原封不动复制到项目管理工具里，变成一个巨大的需求文档节点，然后宣布改造完成。

结果毫无变化。因为问题的本质不是文档存在哪，而是信息结构是否匹配执行动作。一份按章节组织的方案，即便放进再先进的工具，它仍然是按章节组织的，执行者依然要在里面找"我该干什么"。

正确的做法是重组信息结构：按任务组织，每个任务自带责任人、时间、依赖、验收物、验收人。同一份信息，结构变了，可用性完全不同。

3. 误区三：考核指标仍然挂在"文档交付数量"上

这个误区最隐蔽，也最致命。我在一家企业做诊断时发现，项目经理的季度考核里有一条明确写着"按质按量完成项目落地方案编制"。这一条不改，前面所有改造都会反弹。

因为对项目经理来说，写一份 30 页的方案是可交付、可证明、可打分的，而拆解任务、清障是日常琐碎、难以量化的。考核指挥棒指向哪，精力就流向哪。

我的建议是把考核项换成三组：任务拆解覆盖率（有多少任务具备完整验收口径）、阻塞平均清障时长、里程碑按期达成率。这三项都可以从系统数据里直接取，不需要人工填报。

4. 误区四：任务颗粒度不做改造，取消方案只会更乱

这是我见过最惨的一类失败。方案取消了，任务也建了，但每个任务都是"完成用户模块开发"这种级别。三个月后项目延期，回溯时发现没有任何一个节点能提前暴露风险。

颗粒度不够的直接后果是风险暴露延迟。一个 20 人天的任务，只有到第 15 天你才可能发现它要延期；一个 2 人天的任务，第 2 天就能发现。两者对项目的可挽救程度完全不同。

5. 误区五：忽略干系人的心理安全感与合规诉求

最后一个误区和人有关。方案在不少组织里承担着"心理安全垫"的功能：出了事，有方案可以回溯"我们当初是这么约定的"。取消方案，等于撤掉了这层垫子，一部分资深成员会本能抵触。

在受监管行业，这个问题更严肃。审计方可能明确要求提供项目立项与实施方案文档。这种情况下不能硬取消，而应该做形态替换：把《落地方案》替换为《项目执行基线》，内容从叙述式改为结构化条目式，保留留痕能力，去掉冗长论证。

四、专业判断逻辑：什么项目可以取消落地方案

不是所有项目都适合取消。我用四个维度做判断，每个维度都有明确的判据和红线。

1. 维度一：不确定性类型，可分解还是需探索

第一问：这个项目的工作内容能不能在启动时被合理分解？

如果项目本质是"已知路径的规模执行"，比如数据迁移、系统对接、流程上线、合规改造，那么它可以被分解，适合取消方案、直接拆任务。

如果项目本质是"未知路径的探索"，比如新产品概念验证、算法效果调优、用户体验重构，那么前期强行拆任务反而有害，因为你拆出来的任务是假的。这类项目应该保留探索性文档，但形态要改成假设清单 + 验证计划，把"我们要做什么"换成"我们要验证什么"。

2. 维度二：干系人数量与决策链长度

第二问：这个项目要做多少个跨部门决策？决策链有多长？

我的经验阈值是：涉及三个以上部门、且每个决策需要两级以上审批的项目，不建议完全取消方案。不是因为它需要文档，而是因为它需要一个跨部门共识的锚点。

但锚点不一定是 30 页方案。可以是一页纸的决策记录，只记录"决定了什么、谁决定的、什么时候决定的、影响哪些任务"。文档量下降 90%，共识功能保留。

3. 维度三：合规、审计与验收留痕要求

第三问：这个项目未来是否需要向外部或上级提供过程证据？

金融、医疗、军工、公共服务类项目，通常有明确的留痕要求。这种情况下我会明确说：不要取消，做形态替换。把叙述式方案改成结构化基线，把"为什么"的论证压缩到附录，把"做什么"的条目直接映射到系统任务。

关键判断是：审计要的是可追溯，不是篇幅。很多组织误以为审计需要长文档，实际上是审计方需要能快速定位"这条要求对应哪个任务、谁负责、什么状态"。结构化数据在这一点上比文档更有优势。

4. 维度四：任务可逆性与失败成本

第四问：如果某个任务做错了，纠正成本有多大？

我在实际判断中会区分三类：可逆任务（改回来成本低于一天）、半可逆任务（需要一到三天返工）、不可逆任务（涉及数据删改、外部发布、资金支付）。

对不可逆任务，我会保留单独的评审机制，但不通过一份总方案来承载，而是通过每个关键任务独立的前置检查清单。这样风险控制更精准，也不会为了让 5% 的高风险任务得到保护，而让 95% 的普通任务一起背负文档包袱。

5. 四象限判断法与准入清单

把四个维度综合起来，我通常用一个二维象限做快速判断：横轴是"工作可分解程度"，纵轴是"合规留痕要求强度"。

左上（可分解、低留痕）：直接取消方案，全面任务化，这是收益最大的象限。

右上（可分解、高留痕）：形态替换，保留结构化基线，去掉叙述性论证。

左下（需探索、低留痕）：取消方案，改为假设清单与验证计划，按双周迭代重规划。

右下（需探索、高留痕）：保留轻量方案，但把方案绑定到阶段评审节点，每阶段重写一次。

另外我有一份准入清单，四项全过才允许完全取消：一、任务颗粒度达标率超过 70%；二、每个任务有具名验收人；三、项目管理工具能记录变更历史；四、项目经理每周至少有四天在做拆解和清障而不是写材料。

五、案例与数据观察：一个120人组织的六个月改造

下面这个案例是我实际参与推动的，数据来自项目管理系统的导出记录和项目周报归档，时间跨度为六个月。之所以能拿到比较扎实的数据，一个重要原因是这个组织在改造同期完成了项目管理工具的替换，所有过程数据得以被结构化留存。

1. 案例背景

这家企业是一家做工业软件的科技公司，研发与交付人员合计约 120 人，同时并行 6 到 8 个客户交付项目，平均项目周期 10 到 14 周。改造前的核心痛点是：项目方案写得越来越厚，但交付延误率居高不下，项目经理普遍反映"时间都花在写材料上"。

改造前的基线数据是：需求平均交付周期 42 天，项目经理文档工时约 96 人时/月，任务一次通过率 61%，返工率 23%，阻塞平均清障时长 2.8 天，方案评审会议总时长平均 6 小时/项目。

2. 改造动作：把落地方案拆成三层任务契约

我们没有简单粗暴地"不发方案"，而是把原方案的内容重新分配到三个层级，每一层都有明确的字数上限和结构要求。

第一层是里程碑契约，每个里程碑只写四件事：目标、验收口径、最晚完成时间、责任人。全项目不超过一页。这一层替代了原方案的目标与范围章节。

第二层是任务契约，运行在项目管理工具里，每个任务必须填满五个字段：输入、输出、验收人、前置依赖、预估工时。这一层替代了原方案的里程碑计划和资源计划章节。

第三层是决策契约，记录"为什么这么定"以及被否决的替代方案，每条不超过 200 字，按决策日期倒序排列。这一层替代了原方案里最冗长、也最少被阅读的论证章节。

任务契约的字段结构我固化成了模板，直接配置在工具的任务类型里，避免每个人自由发挥：

task_contract:
task_id: DLV-2024-0317

title: 财务模块历史数据迁移脚本开发

input:

财务系统导出模板 v2.3

字段映射表（已由财务方确认）

output:

可执行迁移脚本（含回滚脚本）

迁移结果校验报告（含异常记录明细）

acceptance:

criteria: 10万条样本数据迁移后，关键字段一致率 ≥ 99.99%

verifier: 财务系统负责人 张工

evidence: 校验报告 + 系统截图

dependency:

测试环境数据库账号开通（负责人：运维 李工）

estimate: 3 人天

reversible: false # 涉及数据写入，需前置检查

这套结构最大的价值在于，它把"验收人"和"可逆性"变成了必填项。过去这两个信息在方案里通常没有，导致验收时扯皮、出错时无法回滚。

3. 六个月的指标变化

改造满六个月后，我们做了一次完整数据对比。变化最明显的不是文档工时，而是阻塞平均清障时长从 2.8 天降到 0.9 天。原因不复杂：任务拆细之后，卡点暴露得更早、更具体，项目经理能在当天就介入，而不是等周会才发现。

需求交付周期从 42 天降到 27.7 天，降幅约 34%。任务一次通过率从 61% 提升到 82%，返工率从 23% 降到 11%。这两项改善主要来自验收口径的明确，执行者提交前就知道会被怎么检查。

文档工时从 96 人时/月降到 34 人时/月，降幅约 64.6%。方案评审会议总时长从 6 小时降到 1.5 小时。值得注意的是，文档工时的下降并没有归零，剩下的 34 人时主要花在决策契约的记录上，这部分我们刻意保留。

4. 踩过的四个坑

这个过程并不顺利，我记录下四个真实的坑，供参考。

第一个坑是工具选错了。最开始我们用的是一款轻量协作工具，任务字段无法自定义必填项，验收人和可逆性这两个字段永远填不齐。三个月后被迫换工具，白白浪费了两个月的改造窗口。

第二个坑是任务拆解工作坊开成了批斗会。第一次工作坊我让每个模块负责人现场拆任务，结果变成了互相质疑工作量。后来改成先由项目经理预拆到 60% 完成度，工作坊只做补充和确认，效率才起来。

第三个坑是决策契约被当成追责材料。有成员发现决策记录里写了"某方案被否决"，担心以后被拿来问责，于是开始写得含糊。我们后来明确了一条规则：决策契约只记录技术判断依据，不记录人名，并且不对个人绩效产生任何影响。

第四个坑是改造节奏太急。第一个月我们试图让全部 8 个项目同时切换，结果项目经理集体过载。第二个月改成先切 2 个试点项目，跑通后再以每月 2 个的节奏铺开。

5. 工具侧的支撑：为什么这件事需要合适的平台

前面提到第一个坑是工具选错。这件事让我对项目管理平台的能力边界有了比较具体的认识。取消落地方案的前提，是所有过程信息都能被结构化记录，并且能被审计和回溯，这恰恰是文档最容易做到、而轻量工具最容易做不到的地方。

后来这家企业换成了 PingCode。选它的理由比较务实，不是因为它功能最多，而是三个硬条件都满足。

第一是支持私有化部署。这家企业做工业软件，客户对代码和数据存放位置有明确要求，SaaS 方案直接出局。私有化部署是一条不可协商的红线，很多看起来功能更花哨的工具在这条线上直接淘汰。

第二是支持从 Jira 平滑迁移。这家企业原来的项目管理工具是 Jira，积累了四年的历史任务和缺陷数据，迁移不能断档。迁移过程中字段映射、工作流映射、历史附件保留这三块最容易出问题，我们在正式切换前做了一轮全量试迁移，把字段对不上的地方提前解决。

第三是任务类型的字段可以自定义并设置为必填，这正好对应我们前面说的"验收人和可逆性必须填"的要求。这一点看起来很小，但在实际推行中，能不能把管理规则固化进工具，决定了规则能不能活过三个月。

另外值得一提的是，这家企业的规模刚好落在 PingCode 主要服务的中大型企业及 100 人以上组织这个区间。人数再少一些的团队，用这类平台可能是过度配置；人数再多、项目并行度再高一些的组织，才会真正需要它更强的跨项目视图和权限体系。这也让我在给其他团队建议时更谨慎，工具选型永远要匹配组织规模，而不是反过来。

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

同样是取消落地方案，不同规模、不同行业的组织，起步动作差别很大。我按四类情况给出具体建议。

1. 20 人以内的小团队：不要搞流程，直接改会议

小团队最大的风险是流程负担。我见过 12 人的团队照搬大厂模板，结果每周花 4 小时在各种评审上，产出反而下降。

这类团队我建议的动作只有三个：把启动会从"讲方案"改成"现场拆任务"；把周报改成任务系统里的状态更新；把方案文档压缩到一页纸，只保留里程碑、责任人、验收口径三列。

不需要上重型项目管理平台，一个支持自定义任务字段的轻量工具就够。关键是养成"任务必须有验收人"的习惯，这个习惯的价值远大于工具本身。

2. 100 人以上的中大型组织：先改考核，再改工具，最后改文档

这个规模的组织，改造顺序非常关键。我踩过的教训是：如果先改文档，项目经理会一边发精简任务，一边私下继续写完整方案交差，因为你考核的还是方案。

正确的顺序是三步。第一步改考核指标，把"方案编制完成率"换成"任务验收口径完整率"和"里程碑按期达成率"。第二步选型并落地项目管理平台，重点验证私有化部署能力、历史数据迁移路径、任务字段自定义能力。第三步才是取消方案文档，并在取消的同时上线任务契约模板。

顺序反了，改造通常撑不过一个季度。

3. 强合规行业：不做减法，做形态替换

银行、保险、医疗、军工类组织，我不建议取消留痕，只建议改形态。

具体做法是：把《落地方案》替换为《项目执行基线》，结构从叙述式改为条目式，每一条都能映射到系统里的一个任务编号。审计时，从条文可以直接跳到任务状态和变更历史，可追溯性比传统文档更强。

同时保留一份不超过 3 页的《关键决策说明》，只记录不可逆决策和重大范围变更，作为审计访谈的辅助材料。

4. 正在做工具迁移的组织：把流程改造和迁移合并做

如果你恰好在做 Jira 或其他国外工具向国产平台的迁移，这是一个绝佳的窗口期。因为迁移本身就要求重新梳理字段和工作流，此时顺带把任务契约模板一起设计进去，边际成本几乎为零。

我的建议是在迁移设计阶段就确定三件事：任务类型有哪些、哪些字段必填、验收证据以什么形式挂载。这三件事确定了，迁移完成后流程也就落地了，不需要二次改造。

顺序上，先做一轮全量试迁移验证字段映射，再并行跑一到两周双系统，确认数据一致后再正式切换。这个节奏比一刀切稳妥得多。

七、不同情况下的取舍

取消落地方案不是一个纯赚的决定，它有一组明确的代价。我把四组取舍摊开讲，方便你判断自己能不能承担。

1. 速度 vs 可追溯性

取消方案后，决策的书面痕迹会显著减少。任务系统记录的是"做了什么、什么状态"，但不太记录"当初为什么选这条路"。三个月后如果有人问"为什么当时不用另一个方案"，你可能答不上来。

我的处理方式是设一条红线：只对不可逆决策和范围变更强制记录决策契约，其余一律不记。这样既保住了最关键的可追溯性，又避免决策记录膨胀成新的方案文档。

2. 团队自主性 vs 组织一致性

任务化之后，各团队会自然演化出不同的任务粒度、不同的字段填法、不同的验收习惯。这在短期内提升效率，长期会造成跨团队协作时的对齐成本。

我的取舍是：字段结构统一，粒度标准放宽。也就是说，字段名和必填规则全组织一致，但任务颗粒度允许团队在 0.5 到 5 人天的区间内自行决定。这样既保留了执行灵活性，又不至于让数据无法汇总。

3. 工具投入 vs 管理成本

支持私有化部署、支持历史数据迁移的项目管理平台，采购和运维成本明显高于轻量协作工具。这笔钱要不要花，取决于两件事：你的数据是否有存放位置约束，以及你的历史数据是否值得迁移。

如果两个答案都是否，轻量工具完全够用，没必要为用不上的能力付费。如果其中任何一个是肯定的，那么省下的这笔钱未来会以更高的迁移成本和更长的改造周期还回去。

4. 短期阵痛 vs 长期收益

最后这组取舍最真实。改造的前六到八周，几乎所有的体感都是变差了：项目经理要学新的拆解方法，团队要适应每日更新状态，管理层的汇报材料变薄了，很多人会怀疑这件事到底对不对。

我们的数据是第 9 周开始出现正向信号，第 12 周开始明显改善。所以我的建议是：如果决定做，就要在启动时明确告知管理层，前两个月不要看指标，只看任务契约完整率这一个过程指标。用一个过程指标熬过阵痛期，比反复解释为什么指标变差要有效得多。

这张表里最后一行是我最想强调的。我见过至少三个改造项目死在了第八周，不是方法错了，而是没有提前和管理层约定"这两个月指标会难看"。管理预期的成本，往往比改造本身的成本更高。

写在最后：把"我写过了"换成"我们做成了"

回到最开始那个问题：为什么一份 89 页的方案，只有两页被反复打开？

我的答案是，落地方案的真正读者不是执行者，而是审批者。它存在的意义是获得批准，而不是指导执行。一旦你意识到这一点，就会明白为什么"把方案写得更清楚"永远解决不了执行效率问题，因为它从一开始就不是写给执行者看的。

取消落地方案的本质，是承认规划的价值在于转化成动作，而不在于转化成篇幅。这个判断在我参与改造的十一个项目里都成立，唯一不同的是转化的具体形态。

如果你打算尝试，我建议的下一步很具体，不要一上来就推翻现有流程：

1. 先做一次现状测量。抽一个正在进行的项目，统计它的落地方案有多少条目最终转化成了带验收标准的任务。这个数字通常会让你惊讶，它也是最有说服力的改造依据。
2. 选一个可分解程度高、合规压力小的项目做试点，不要选最重要的项目，也不要选最烂的项目。
3. 在试点里只做一件事：把方案里的每一条要求，逐条转化成带验收人和依赖关系的任务卡片，其余一切照旧。
4. 跑满六周后对比三个数据：需求交付周期、阻塞平均清障时长、任务一次通过率。如果三项里有两项改善，再考虑扩展。
5. 如果决定扩展到 100 人以上的组织，先动考核指标，再动工具，最后才动文档。

整个过程中最难的不是方法，是忍住不写那份看起来很完整、实际上没人读的方案。做到这一点，效率提升自然会发生。