WBS工作分解结构

WBS（Work Breakdown Structure）说白了就是”把大事拆成小事”：从项目目标出发，一层层往下分解——版本目标拆成系统模块，模块拆成功能，功能拆成具体任务，直到每个任务能回答三个问题：谁做、做多久、做完的标准是什么。拆不到这个程度，排期就是空中楼阁；拆到了，进度跟踪、资源分配、风险识别才有了地基。

放到游戏研发里，WBS 的拆法通常混合两个维度：按职能拆（策划/程序/美术/测试的任务）和按内容拆（角色、关卡、系统各自的全链路任务）。拆解时最容易漏掉的是”接缝处”的工作——联调、接入、适配、验收，这些不属于任何单一职能的任务恰恰是延期高发区。

PM 视角

WBS 是 PM 的看家功夫，但实操里有几个分寸要拿捏：

第一，拆解粒度看阶段。近期任务拆到几天粒度的可执行任务，三个月后的任务拆到模块级就够了——研发的不确定性决定了远期细拆纯属浪费，反正要重拆。滚动式细化比一次拆到底实用得多。

第二，WBS 要和做事的人一起拆。PM 闭门造出来的任务清单，既不准（估不对工作量）也没人认账（不是我承诺的）。拉着各组骨干一起拆，拆的过程本身就是对齐认知、暴露遗漏的过程，这个过程比产出的表格更值钱。

第三，别把 WBS 当成拆完就完的静态文档。需求变了、方案改了，WBS 要跟着更新，否则两周后它就变成没人看的过期文件。检验标准很简单：团队日常讨论进度时用不用它——用，它就活着；不用，你做的就是形式主义。