缩短不在关键路径上的操作不会改变总时间
别名: 非关键路径 · 松弛时间 · 优化优先级 · 无效优化
概念解释
如果一个操作的完成时间短于关键路径允许的松弛时间（slack），即使把它压缩到零，任务结束时刻也不变。优化必须指向关键路径，或把该操作移出关键路径。这一条是"总时间由关键路径决定"这条道理最直接的推论，也是它对实践最有用的部分——理解关键路径本身是理论认识，知道哪些优化工作会白费力气，才是能直接改变团队怎么分配资源的实用结论。
机制
之所以会出现"优化了却没用"这种情况，根源在于并行任务里存在的富余时间：等待系统响应的这段时间里，用户如果能够同时完成手部移动、阅读提示或者展开子菜单，只要这几件事花的时间比系统响应本身更短，它们就是"藏"在等待时间里完成的，缩短这些活动本身，只是让富余时间变得更充裕，并不会让任务提前结束——因为决定结束时刻的从来不是这几个活动，而是那段更长的系统响应。真正能缩短总时间的优化只有三种：直接压缩零富余时间的活动本身（比如真正减少系统响应的耗时）、找到办法解除某个原本以为无法打破的依赖关系（把一个原本被认为必须串行的步骤证明其实可以并行）、或者重新设计整个流程结构。在动手优化之前，必须先老老实实算出每一个活动各自的富余时间和它对结束时刻的传导路径，否则很容易把力气花在一个看起来很显眼、实际上根本不影响结果的地方。
边界
不能因为某个活动不在关键路径上，就完全放弃优化它——非关键路径上的活动虽然不影响任务的完成时间，但它仍然可能影响用户感知到的流畅程度、实际发生的错误率，或者操作过程中的认知负荷，这几项都是独立于"完成时间"之外、同样值得关注的指标。真正需要划清的边界是目标：如果团队当前的目标就是"让任务更快完成"，那么投入资源去优化非关键路径上的活动，客观上就是在做无效功，这部分资源应该优先流向零富余时间的活动。另外，关键路径本身会随着用户实际采用的操作策略而变化，同一个活动在某种策略下是非关键的，换一种策略可能就变成了关键路径的一部分，因此每次判断"这个活动值不值得优化"之前，都需要先确认当前依据的是哪一种用户策略下的关键路径，而不是套用一次性算出来的旧结论。
怎么落地
- 在活动清单里明确列出每一项的持续时间和它对应的富余时间，把结果按有没有富余时间、富余时间还剩多少来排序。
- 优化顺序严格按零富余时间优先：先处理系统响应、必须阻塞的输入、无法省略的确认步骤和长距离的手部移动，这几类通常最容易出现在关键路径上。
- 对确认属于非关键路径的活动，只做成本很低的顺手改善，或者干脆想办法把它并行化、挪到后台去做，而不要投入大量资源去精细打磨。
- 验证办法：每次改动之后重新计算一遍关键路径，并且用真实测量去确认任务的结束时间是不是真的缩短了——如果优化了非关键活动却发现完成时间没有变化，这本身就是一次对模型判断的验证，说明当初的富余时间估算是准确的，而不是优化白做了。