Q4.07.1hierarchical task decomposition设计研究
层级分解揭示子任务与前置条件
别名: 层级任务分析 · 子任务分解 · 前置条件
概念解释
「完成报销」看起来像一步。拆开才看见：先凑齐票据、票据要在系统允许的日期内、项目代码必须已经存在、没有代码就得先找财务开。层级分解（hierarchical task analysis）把一个目标拆成子任务，并写出某子任务能够开始前所必须为真的条件。没写前置条件的分解，只是一份步骤清单，会把「做不到」误记成「不会做」。
机制
人在熟练时把前置条件压缩成感觉：文件夹里「应该」已经有发票。失败往往不是按错按钮，而是条件从未成立——发票在别人邮箱里、项目还没立项。层级结构把「为了什么」留在上层，把「靠哪些更小的成就」放在下层，于是可以单独检查某一层是否具备。前置条件是层与层之间的闸：闸没开，下层再熟练也进不去。把闸画出来，才能区分缺技能、缺权限、缺材料和缺时机。
怎么研究
对一次真实完成（含失败）做目标—子任务树，并在每个节点标注开始前必须为真的状态。用观察核对：失败者卡在动作还是卡在未满足的条件。比较「只列步骤」与「步骤+前置」对同一失败的归因。因变量包括未写出却实际起作用的条件数、以及条件不满足时操作者是否仍被判定为出错。
边界
一次性、高度即兴的创造性工作，硬拆会得到虚假的稳定树；更适合事后叙述而非规范分解。团队任务的前置条件可能分布在不同人身上，树要标清条件的持有者，否则会画成一个人的技能问题。自动化把某些子任务收走后，表面上的树变浅，前置却可能变得更苛刻（必须在线、必须有账号），分解不能只跟着可见动作变少而缩短。
怎么落地
- 每个上层目标至少拆出子任务，并给每个子任务写「开始前必须已经怎样」。
- 现场跟做时，把停顿先记成「条件？」再记成「不会」；能指出缺的材料、权限或时机，就不要写成操作错误。
- 设计评审拿出树，问新方案消灭的是动作还是条件；只少了点击、条件原样，报销仍完成不了。
- 用一次失败案例走树：走到第一个未满足的前置即停止，把那一闸列为问题，而不是把整棵树标红。