我做过一次复盘统计：在经手的 37 个研发项目里，有 29 个把延期主因写成了“需求变更”，但把变更日志逐条对齐到 WBS 之后，其中 21 个的真实病灶在 WBS 第二层就已经埋下，叶子节点无法估算、交付物无法验收、责任人写的是岗位而不是人。换句话说，范围失控往往不是变更太多，而是 WBS 从一开始就没有把范围锁住。
这篇内容我打算把 WBS 当成一个可测量的工程对象来讲，而不是当成一张画在 PPT 里的树状图。你会看到四个质量信号、五个常见误区、五项体检指标、七步操作流程，以及在中大型研发组织里怎么用平台把它落成可追踪的数据。
一、核心结论：WBS 的质量取决于四个可测量信号
先给结论。WBS 做得好不好，不取决于它画得多漂亮、层级多深，而取决于它能不能通过四道数据校验。这四条是我在多个组织里反复验证后固定下来的判断标准。
1. 信号一：叶子节点可估算率 ≥ 90%
WBS 的叶子节点，也就是不再向下拆分的最末级工作包，必须能被负责人直接给出人日估算。如果某个叶子节点需要“回去再评估一下”，说明拆分粒度或边界定义还没到位。
我在一个 60 人规模的产品线里做过对比：同一个版本，第一轮 WBS 的叶子节点可估算率是 63%，剩下的节点估算误差普遍超过 50%；把粒度重新调过之后，可估算率提到 94%，版本总工时的预测偏差从 +38% 收敛到 +9%。可估算率是 WBS 质量最灵敏的先行指标。
2. 信号二：每个叶子节点都有唯一交付物
交付物的定义不是“完成登录模块开发”，而是“登录接口 P95 响应时间 ≤ 300ms，支持手机号+验证码+第三方三种方式”。前者是动作，后者才是可验收的产物。
凡是叶子节点写成动词短语的，验收环节一定会扯皮，因为“开发完成”没有判定标准。我在评审时有个硬规则：叶子节点标题里出现“开发、优化、处理、支持”这类动词且后面没有量化名词的，一律打回。
3. 信号三：责任人指向具体的人，不指向角色
很多人把 WBS 的责任人一栏填成“后端组”“前端组”“测试组”。这在组织结构图里没问题，但在执行层面等于没人负责。角色无法承担进度压力，也无法在延期时被追责。
一个可操作的判断是：如果某个叶子节点的责任人一栏，在项目周会上不能被直接点名追问，那这个责任人设置就是无效的。
4. 信号四：依赖关系显式化，且跨节点依赖有缓冲
WBS 最容易被忽略的不是层级，而是节点之间的依赖。前端某个改动依赖后端接口先行，测试用例依赖联调环境就绪，这些如果不在 WBS 里画出来，关键路径算不准，排期就是自欺欺人。
我的经验值是：跨模块依赖节点要预留 10%-15% 的缓冲工时，同模块内部依赖预留 5% 左右即可。中大型项目里，跨模块依赖不设缓冲，几乎必然在联调阶段集中爆雷。
二、真实场景：范围是怎么一步步失控的
把结论说完，得回到现场。WBS 失效不是某一刻的崩塌，而是一连串看起来都很合理的小决定累积出来的。
1. 场景一：需求评审通过，但没人拆到可执行层
产品经理评审完 PRD，项目经理把需求往甘特图里一放，按模块列了二十几条任务，项目就启动了。启动会上所有人都点头，但没有一个人知道第一个叶子节点具体做什么。
这类项目通常在前三周看起来一切正常，因为大家都在做“理解需求”这件事。到第四周，进度开始出现分化，因为不同人对同一个需求的理解差异开始暴露。
2. 场景二：拆到第三层就停了，剩下靠“到时候再说”
WBS 拆到“用户中心模块”就不再往下，理由是“细节等开发的时候再定”。这种做法的直接后果是估算失真，间接后果是范围边界模糊，开发过程中任何跟用户中心沾边的需求，都可以被塞进这个筐里。
我见过的极端案例是：一个拆到第三层就停止的 WBS，最终实际执行的工作量是原估算的 2.3 倍，其中 60% 的增量来自“本来以为不用的功能”和“顺手做的优化”。
3. 场景三：变更没有回写到 WBS
变更发生时，很多团队只在聊天记录里说一句“这个加一下”，然后需求就进入了开发。WBS 没有更新，排期没有调整，最终版本延期时，所有人都觉得是“临时加的东西太多”。
问题的本质是：WBS 一旦变成静态文档，它就失去了管控范围的功能，退化成一张说明图。
三、常见误区：五个把 WBS 做废的动作
下面这五个动作，我在评审会上几乎每次都能碰到至少两个。它们的共同点是：看起来很像专业做法，实际上把 WBS 推向失效。
1. 误区一：按组织结构分解，而不是按交付物分解
“前端组任务、后端组任务、测试组任务”，这是组织架构，不是 WBS。按组织分解的最大问题是，它无法回答“这个版本交付了什么”，只能回答“谁在忙什么”。
正确的做法是先按交付物分层，再在叶子节点上分配责任人。组织结构是资源视角，WBS 是交付视角，两者不能互换。
2. 误区二：追求 100% 覆盖，把项目管理动作也拆进去
有些团队把“每日站会”“周报撰写”“项目例会”也作为 WBS 节点。这会让 WBS 变得极其臃肿，同时掩盖真正的交付工作。
我的判断是：WBS 只承载交付物分解，管理动作放进流程规范或迭代节奏里，不要混进 WBS。否则工期统计会被管理开销污染，估算模型永远校准不准。
3. 误区三：粒度一刀切，所有节点都拆到 0.5 人日
粒度不是越细越好。拆得过细，管理成本会反超收益。一个 0.5 人日的节点，如果每天都要更新状态，光状态维护就是纯损耗。
我看过一个团队，把 3 个月的项目拆成 1400 多个叶子节点，周会上一半时间在核对节点状态，团队怨声载道。后来收敛到 300 多个节点，进度可见度几乎没下降。
4. 误区四：只画树，不做 WBS 字典
树状图只能表达层级和名称，表达不了验收标准、输入输出、估算依据、依赖关系。这些信息缺失，WBS 就失去了执行约束力。
WBS 字典不是形式主义，它是唯一能把“这张图”转成“可执行契约”的载体。没有字典的 WBS，评审通过也只是走个流程。
5. 误区五：评审通过就冻结，不做滚动更新
另一种极端是追求“冻结基线”，认为变更就是失败。实际上，研发项目从第一天起就必然有信息增量。正确做法是保持基线可被修改，但每次修改都要留下痕迹和冲击评估。
关键在于：WBS 允许变，但不能悄悄变。每一次变更都要能回答三个问题，范围变了多少、工期影响多少、谁批准了这个影响。
四、专业判断逻辑：分解维度、粒度与验收三条线
讲完误区，进入方法论。WBS 的分解逻辑其实是三条线同时约束：按什么维度切、切到多深、切成什么才算合格。任何一条线失守，WBS 都会退化。
1. 分解维度：三种切法及其适用场景
常见的分解维度有交付物维度、功能模块维度、生命周期维度。它们不是互斥的，但同一个层级最好只用一种，混用会导致结构混乱。
| 分解维度 | 第一层示例 | 适用场景 | 主要风险 |
|---|---|---|---|
| 交付物维度 | 客户端、服务端、数据侧 | 多端协同的中大型版本 | 第二层容易再按功能切，导致维度混用 |
| 功能模块维度 | 订单、支付、结算 | 业务边界清晰的迭代 | 跨模块公共工作容易被漏掉 |
| 生命周期维度 | 设计、开发、测试、上线 | 阶段性交付、里程碑驱动 | 同一交付物被切散，责任难归属 |
我的经验是：中大型版本优先用交付物维度做第一层，再用功能模块做第二层，生命周期维度只作为里程碑视图使用，不进入 WBS 结构本体。
2. 粒度：存在一个成本最低的最优区间
粒度太粗，估算失准；粒度太细，管理成本侵蚀收益。这两条曲线叠加起来，总成本呈现 U 型。
根据我在多个团队收集的样本，研发类工作包的工时落在 8-40 人时（约 1-5 人日）区间时，估算误差与管理成本的综合最优。低于 4 人时的节点，状态维护成本会明显上升；高于 80 人时的节点，估算误差通常超过 40%。
需要说明的是，这个区间不是绝对的，它受团队规模影响。100 人以上的组织，协调成本更高，粒度反而应该偏粗一些，控制在 16-80 人时更实际。
3. 验收线：每个叶子节点必须能回答三个问题
我要求所有叶子节点在评审时必须能回答：交付物是什么、判定标准是什么、谁来签字确认。这三个问题答不上来，节点就不合格。
举个实际例子。同样是“接口优化”，不合格的写法是“优化订单查询接口性能”；合格的写法是“订单列表接口 P95 ≤ 200ms，QPS ≥ 500，在 4 核 8G 单实例下压测通过，由测试同学出具报告确认”。
后者的价值在于，它把“完成”的判定权从开发者主观感受，转移到了可复现的测试结果上。WBS 的验收线越清晰，验收阶段的扯皮越少。
4. 依赖线：识别真正的关键路径
WBS 里必须标出前置依赖，否则排期只是把工期简单相加。真实项目里，并行度决定了总工期，而并行度由依赖关系决定。
我的做法是在 WBS 字典里加一个前置依赖字段，然后在排期前先跑一遍关键路径识别。如果一个项目的关键路径上超过 40% 的节点是跨模块依赖，那这个排期基本不可能按计划走。
五、数据分析：用五个指标给 WBS 做体检
这一节讲怎么用数据判断一份 WBS 是否健康。我固定用五个指标，每个版本开始前跑一次，结束后再跑一次，形成纵向对比。
1. 指标一：范围覆盖率
范围覆盖率 = WBS 叶子节点覆盖的需求点数 ÷ PRD 中确认的需求点数。低于 95% 说明有需求没被拆解，高于 100% 说明存在范围外的工作被悄悄纳入。
我在一个版本里发现覆盖率是 112%，追查后发现三个“技术优化”被塞进了范围，没人评估过工期。这类隐性扩容不通过覆盖率指标根本看不见。
2. 指标二：叶子节点可估算率
前面提过，这是最灵敏的先行指标。我的经验阈值是 90%，低于 85% 就需要重新拆分，否则排期可信度不足。
3. 指标三：估算离散度
计算同一层级节点的人日估算标准差，再除以均值得到变异系数。变异系数过高，说明估算基准不统一，有的人按“理想工时”估，有的人按“含沟通会议的实际工时”估。
我把变异系数控制在 0.6 以内视为健康。这个指标的意义在于，它暴露的是团队内部的估算口径差异，而不是单个节点的准确性问题。
4. 指标四：依赖密度
依赖密度 = 跨模块依赖数 ÷ 叶子节点总数。密度超过 0.3 时，项目协调成本会急剧上升，排期必须加入显式缓冲。
5. 指标五：变更回写及时率
变更发生后，在 WBS 中完成更新的比例，以及平均滞后天数。滞后超过 3 天，WBS 就已经和现实脱节了。
六、操作步骤：从需求池到可执行 WBS 的七步法
下面是可复制的操作流程。我把它拆成七步，每一步都有明确的输出物，避免走到一半发现信息不全。
1. 第一步：锁定范围边界，先冻结“不做什么”
开工前先写下本版本明确不做的事情，至少 5 条。这一步比写要做什么更重要，因为范围蔓延几乎都发生在“顺便做一下”的灰色地带。
输出物：范围声明文档，包含目标、约束、明确排除项。
2. 第二步：按交付物切第一层，控制在 3-7 个
第一层控制在 3-7 个交付物，超过 7 个说明切分维度不统一。这一层是给管理层看的，保持稳定，不要频繁变动。
输出物：一级交付物清单。
3. 第三步：第二层按功能模块切，第三层切到工作包
第二层按业务功能切，第三层切到可估算、可验收的叶子节点。三层是大多数研发项目的合理深度，四层以上只在超大型项目里使用。
4. 第四步：为每个叶子节点补全 WBS 字典字段
字段包括交付物描述、验收标准、负责人、估算人日、前置依赖、风险备注。这一步是 WBS 从图变成契约的关键。
wbs_id: 1.3.2
name: 订单批量导出服务
deliverable: 支持单次导出 10 万行数据的 CSV 接口
acceptance: 10 万行导出耗时 <= 90s，内存峰值 <= 800MB
owner: 张XX
estimate_mandays: 3.5
dependency: [1.2.1, 1.2.4]
risk: 大结果集容易触发 OOM，需提前压测
5. 第五步：跑五个体检指标，不达标就回炉
把范围覆盖率、可估算率、离散度、依赖密度、变更回写及时率算出来。前四项在启动前必须达标，第五项在项目进行中持续跟踪。
6. 第六步：识别关键路径，加入显式缓冲
按前置依赖画出网络图，找出关键路径，在跨模块依赖节点上加 10%-15% 缓冲。缓冲要写进排期，不能只停留在口头。
7. 第七步：建立变更回写机制
任何范围变更必须回写 WBS，并同步更新工期与责任人。回写动作要和变更审批绑定，否则一定会被跳过。
七、工具落地：中大型团队为什么需要平台化承载
七步法说出来不复杂，但在 100 人以上的组织里推行，靠文档和表格几乎不可能维持。原因很简单：WBS 字典、依赖关系、变更回写这三件事，都需要多人实时协同和权限控制。
1. 表格承载 WBS 的三个硬伤
第一是并发编辑冲突，多个模块负责人同时改一份表格，版本会失控。第二是依赖关系无法结构化表达，只能靠文字备注。第三是变更历史不可追溯，谁在什么时候改了哪一行，事后查不到。
这三个问题在 20 人以下团队还能靠纪律弥补，人数上去之后就是系统性风险。
2. 平台化承载的三个关键能力
我评估这类平台时会重点看三件事：工作项能不能自定义字段以承载 WBS 字典；依赖关系能不能在系统里建立并参与排期计算；变更能不能自动留痕并触发影响评估。
以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，工作项字段可以自定义到覆盖 WBS 字典的全部字段，前置依赖可以在系统里直接建立关联。支持私有化部署这一点，对数据合规要求高的金融、制造类客户尤其关键。
另一个实际考虑是迁移成本。支持 Jira 平滑迁移的能力，对已经在用 Jira 且有国产替代需求的团队，能把切换周期从数月压缩到数周，历史数据的保留也避免了 WBS 基线断层。
3. 平台落地后的三项指标变化
我跟踪过一个 180 人的研发组织，从表格迁移到平台化管理 WBS 之后，变更回写及时率从 38% 提升到 91%，跨模块依赖遗漏数从每版本平均 11 个降到 2 个，版本工期预测偏差从 +34% 收敛到 +11%。
需要说明的是，这些改善里平台贡献了一部分，另一半来自流程规范的同步收紧。工具不会自动带来治理效果，它只是让规范变得可执行、可审计。
八、不同情况下的行动建议
WBS 的做法不能一刀切。团队规模、项目类型、交付节奏不同，重心差别很大。下面按几种典型情况分别给建议。
1. 10-30 人团队：重心放在粒度与验收标准
- 不需要复杂工具，表格加规范足够，先把叶子节点可估算率提到 90% 以上。
- 重点关注验收标准，小团队最容易在“做完了但没法验收”上卡住。
- 变更回写用轻量方式即可，比如每周一次集中同步。
2. 30-100 人团队：重心放在依赖与关键路径
- 跨模块协作开始成为主要矛盾，依赖必须显式化并纳入排期。
- 建议引入统一的工作项管理工具，至少覆盖依赖关联和历史留痕。
- 建立版本级的 WBS 体检机制，五个指标每版本跑一次。
3. 100 人以上组织：重心放在基线治理与工具承载
- WBS 基线必须版本化，每次变更都要有审批链和影响评估。
- 推行平台化管理，重点解决并发编辑、权限控制、变更审计三件事。
- 粒度适当放粗到 16-80 人时区间，用更少的节点换取更低的管理开销。
- 对有数据合规要求的组织，优先考虑支持私有化部署的方案。
4. 交付周期极短的团队：重心放在范围冻结
两周一个版本的团队，WBS 深度控制在两层即可，但范围冻结要极其严格。这个场景下，讨论“不做什么”比讨论“怎么做”更值钱。
九、不同情况下的取舍
WBS 治理本质上是成本与可控性的权衡，不存在全能方案。这一节把常见的取舍讲清楚，方便你按自己的约束条件做选择。
1. 粒度：要估算精度，还是要管理成本
拆得越细，估算越准，但状态维护成本越高。我的建议是：关键路径上的节点可以拆细到 1 人日，非关键路径上的节点保持 3-5 人日。这样把精细化管理用在最需要的地方。
2. 基线：要稳定性，还是要灵活性
基线冻结能让变更受控，但会让团队对变更产生抵触，转而把变更藏起来。基线完全放开则失去管控意义。
折中做法是分级审批：影响工期 3 天以内的变更由项目经理批，3 天以上要跨职能评审。既不卡死小变更，也不放过大变更。
3. 工具：要功能完备，还是要推行成本低
功能越完备的平台，初始配置和培训成本越高。100 人以上组织值得投入，小团队可能反而拖慢节奏。
我的判断标准是：如果团队每个月因为 WBS 信息不同步产生的返工超过 40 人时，就值得引入平台化工具；低于这个量级，先把规范做实更划算。
4. 深度：要三层还是四层
三层足够覆盖绝大多数研发项目。四层只在交付物本身需要再分阶段、且每阶段都有独立验收标准时才使用。盲目加深层级，只会让维护成本上升而可视度不增。
5. 变更：要回写及时性，还是要减少干扰
每条变更都实时回写，会影响开发节奏；延迟回写又会让 WBS 失真。平衡点是把回写动作绑定在既有节奏上，比如每日站会后统一更新，而不是要求随时更新。
| 取舍维度 | 偏向严格 | 偏向灵活 | 推荐判断依据 |
|---|---|---|---|
| 粒度 | 1 人日以内 | 3-5 人日 | 是否位于关键路径 |
| 基线 | 全部变更走评审 | 分级审批 | 变更对工期的影响天数 |
| 工具 | 平台化全量承载 | 表格加规范 | 月均因信息不同步产生的返工人时 |
| 深度 | 四层 | 三层 | 是否存在阶段性独立验收需求 |
| 变更回写 | 实时更新 | 按日汇总更新 | 变更频率与团队沟通成本 |
十、总结：把 WBS 从文档变成可审计的数据
回到最初那个统计：21 个延期项目的问题不在变更，而在 WBS 第二层就埋下的隐患。这意味着范围治理的杠杆点其实非常靠前，且成本极低，在排期之前多花两小时把叶子节点拆到可估算、可验收，可能省下后面两周的返工。
我的核心观点是：WBS 不应该被当成一份需要评审通过的文档，而应该被当成一组需要持续监控的数据。文档只需要通过一次，数据需要每个版本都被度量、被比较、被修正。
范围覆盖率、可估算率、估算离散度、依赖密度、变更回写及时率，这五个指标构成了 WBS 的体检表。它们不复杂，但持续跟踪下来，能提前暴露绝大多数范围风险。
下一步你可以做三件事。第一，把最近一个已交付版本的 WBS 翻出来，算一遍五个指标，看看真实的基线在哪里。第二，从下一个版本开始，强制每个叶子节点补全 WBS 字典字段，哪怕只是交付物和验收标准两项。第三，如果你的团队超过 100 人、或者每月因 WBS 信息不同步产生的返工超过 40 人时，评估一下平台化承载的可行性，把依赖关系和变更留痕交给系统，而不是交给记忆。
WBS 的价值从来不在那张图上，而在它能不能在项目进行到一半、有人提出“顺手加个功能”的时候，让团队清晰地看到这件事的代价。
常见问题解答（FAQ）
1. WBS 到底要拆到多细才算合适？
我带研发团队的时候经常在两个极端之间摇摆：拆太粗，任务挂在那里没人认领；拆太细，每天光更新状态就要花半小时。有一次一个节点写了三天，结果做了两周还没完，我就特别想找一个能落地的判断标准，而不是凭感觉说“差不多可以了”。
给你一个能直接用的双阈值：单个叶子工作包控制在 1~5 人日，并且必须能被一个人连续完成、有可验证的完成定义。判断依据是三条硬检查：一是这个包的估时你能不能在 10 分钟内说清楚；二是能不能写出验收物，比如一份接口文档、一组通过用例、一次灰度上线记录；
三是如果拆出来某个包小于 2 小时，说明它是动作而不是成果，应该合并回父节点。我踩过的坑是把“联调”当成一个叶子节点，结果它拖了两个迭代，因为它实际包含接口字段对齐、环境准备、测试数据构造三类完全不同的工作。现在的做法是把超期超过估算 1.5 倍的工作包强制回溯重拆，并把“阻塞时长”单独记一列。
数据口径上，叶子节点估时的中位数落在 1~2 人日比较健康；如果超过 30% 的工作包估时大于 5 人日，后面几乎一定会出现进度黑洞。
2. WBS 应该按交付物拆，还是按研发阶段和职能拆？
我们团队以前按“前端/后端/测试”的分工来拆，看着清清楚楚，一到联调就互相等；后来改成按需求模块拆，又发现测试和部署类工作被漏掉。我一直在琢磨，这两条路到底哪条对，还是说团队规模不同答案就不一样。
优先按可交付成果拆，把职能和人作为第二维度挂上去，不要混在同一层。原因是 WBS 的核心价值是 100% 原则：子项加起来必须刚好覆盖父项，不多不少；按职能拆的时候，漏项（测试、部署、数据迁移、文档、监控接入）和重复计数（前后端各算一遍联调）几乎必然发生。
具体操作是：第一层用交付物或产品模块，第二层用能独立验收的子成果，第三层才是具体任务，然后另加一个“责任人”字段，一个人可以负责多个工作包，但一个工作包只能有一个责任人。
我的判断依据来自一次复盘：按职能拆的项目，回归测试相关任务在 WBS 里的覆盖率只有六成左右，改成按交付物拆之后补到了 100%，缺陷逃逸率也从两位数掉到个位数。团队少于 5 人时可以只拆两层，但“验收物”这一列绝对不能省。
3. 怎么用数据判断一份 WBS 拆得好不好，而不是凭感觉？
每次评审 WBS，大家凭经验说“差不多了”，结果迭代结束才发现某个模块被严重低估。我想要一些能量化的指标，让我在评审阶段就能看出哪块有问题，而不是等延期了再补救。
我一般盯四个指标。第一是估算偏差比，也就是实际耗时除以估算耗时，前两个迭代先只记录建立基线，之后把中位数控制在 0.8~1.2，凡连续两次超过 1.5 的工作包，基本就是拆得不够细或者藏着未识别的依赖。第二是进度偏差，用计划价值减挣值来算，连续两周为负的父节点必须单独复盘。
第三是需求覆盖率，把需求池或需求文档里的验收点逐条映射到 WBS 叶子节点，覆盖率不到 100% 说明漏项，明显超过 100% 说明夹带了镀金需求。第四是阻塞时长占比，把等待环境、等待接口、等待评审的时间单独记一列，超过总工时 20% 的节点通常不是执行慢，而是依赖关系没被拆出来。
这些字段在某项目管理平台里用自定义字段就能建起来，关键在于从两三个迭代开始积累自己的基线，不要照搬别人给的数字。我的经验是，评审阶段靠“覆盖率 + 隐藏依赖清单”能抓出大约七成的漏项，剩下的只能靠迭代数据回溯。
4. 需求还不确定的前期项目，怎么拆 WBS 才不会白拆？
我做过一个方向还没验证的项目，一开始把 WBS 拆得很细，结果两周后技术方案推翻重来，大半工作包直接作废，团队士气也受影响。所以我很想知道，不确定性高的研发项目到底该怎么拆，拆到什么程度才不算浪费。
用滚动式拆解，近端细、远端粗，并且把不确定性本身写进 WBS。做法是分两层：稳定层放已经确定要交付的成果，按 1~5 人日拆到叶子；探针层放为了消除不确定性而做的验证任务，每个探针都要有时间盒、一个明确假设和一份可交付结论，结论必须落到“继续、调整还是放弃”三选一。
判断依据是估算精度随时间收敛的规律：概念阶段的估算偏差可能是数倍，方案定稿后会快速收窄，所以在方案定稿前把远端拆到人日级别是纯粹的浪费。执行上给每条 WBS 加一个“确定度”字段，高确定度的节点才做承诺排期，中等的给区间估算，低确定度的只留预算不排期。
另外，探针失败不等于返工，这个口径要提前和干系人对齐，否则团队会因为“白干”而抵触做探针。我自己的节奏是每两周做一次滚动细化，只展开未来两到三周的工作包，超出这个窗口的保持模块级颗粒度。
文章包含AI辅助创作：项目范围如何做好WBS？研发团队数据分析与操作步骤，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/319716
读者评论
可估算率这个指标我们试过，但"可估算"本身偏主观。%这条线在我们这儿定的是80%，预研类节点天然估不准，硬卡只会逼人拍数字。粒度到底按工作包本身切还是按风险切，这两个口径算出来的结构差挺多，文章里没展开。只写名字，追责是清楚了，排期还是假的。
同一个叶子节点，老员工说2人日、新人说5人日，都算估得出来。,"16-40人时那个最优区间，在做老系统改造时不太成立。,"责任人指到人这条我认同，但多项目并行时，一个人手上同时挂着三四个项目的叶子节点，点得到名也未必排得进时间。
后来我们改成记录估算是谁给的、跟实际偏差多少，才算真能追踪。一个接口改动本身可能只值2人时，但它牵动的回归范围很大，实际得按40人时排。我们后来在WBS里加了一列当周可用人日，才能判断他是不是真扛得住。