B4.13.2Critical Path设计

总时间由关键路径决定,而不是各操作时间之和

别名: 关键路径 · 并行总时 · 依赖关系 · 三类依赖

概念解释

在并行模型中,任务总时是最长依赖链的长度,即关键路径(critical path):从开始到结束,每个活动的开始依赖前一活动完成。并行分支的时间不叠加,只有决定结束时刻的链路计入总时。这一条紧接在"熟练操作中感知、认知与运动资源可以并行占用"之后:上一条说明了并行为什么会发生,这一条说明并行发生之后,总时间到底该怎么算——不是把所有活动的时间加起来,而是只看那条真正卡住结束时刻的链条。

机制

要画出关键路径,第一步是分清活动之间到底是哪一种依赖关系,因为不同依赖类型决定了两条活动能不能并行:数据依赖指下一步需要用到上一步产生的结果,比如必须先看到搜索结果才能点击某一项,这种依赖天然是串行的;资源依赖指两个活动要争用同一个处理器,比如手不能同时移向键盘和鼠标、视觉焦点不能同时看两个地方,这种依赖也强制串行;外部依赖指活动要等待系统响应这类不由用户控制的因素。只有当两条活动之间既没有数据依赖、也不争用同一资源时,它们才能真正并行。关键路径就是把所有这些依赖关系连起来后,从任务开始到结束最长的那条链——链条上的每一次延迟都会原样传导到最终结束时刻,而不在这条链上的活动,无论花多长时间,只要没有超过链条留给它的富余时间(slack),就完全不影响任务什么时候结束。

边界

关键路径本身是根据依赖图推算出来的结果,如果依赖图画错了——比如把两个实际上互相独立的活动误判成有资源冲突,或者漏掉了一个真实存在的数据依赖——算出来的关键路径就会是错的,这不是模型的问题,而是建模输入本身的问题,必须靠对任务足够细致的观察去核实每一条依赖是否真实存在。用户的操作策略一旦改变,关键路径也会跟着改变:同一个任务,如果用户从"先看完整个列表再决定点哪个"换成"看到第一个大致符合的就点",原本的数据依赖关系可能被打破,关键路径也要重新画。系统重试、网络波动和任务中途被打断,同样会临时改变原本的依赖结构,这些都提醒不能把某一次画出的关键路径当成固定不变的真理,理论上推算出的并行关系也必须用熟练用户的真实数据去验证,不能停留在纸面推演。

怎么落地

  • 为高频任务画出完整的活动依赖图,把每一对活动之间到底是数据依赖、资源依赖还是外部依赖标注清楚,不要笼统地写"有关系"。
  • 根据依赖图计算出关键路径,同时算出每条非关键分支各自还有多少富余时间(slack),把结果按有没有富余时间排序。
  • 把可以后台处理的系统响应、可以提前进行的预加载和提示信息,尽量移出关键路径,让它们变成有富余时间的非关键活动。
  • 验证办法:用带时间戳的操作日志去验证模型推算出的关键路径是不是真的对应实际的结束时刻——如果日志显示的实际结束时间和模型预测的关键路径长度对不上,说明依赖图本身有遗漏或者判断错误,需要回头修正,而不是怀疑关键路径这个概念本身。

延伸

  • 同组B4.13.1 熟练操作中感知、认知与运动资源可以并行占用 · B4.13.3 缩短不在关键路径上的操作不会改变总时间 · B4.13.4 模型只对高度熟练的操作成立,新手的行为不是并行的 · B4.13.5 关键路径分析能解释为什么减少了步骤却没有变快
  • 相邻B4.04 GOMS · I1 状态时间与响应
  • 站内检索critical path · dependency graph · parallel task time · resource contention

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/B4.13.2