需求紧迫性评估要解决的是：在需求评审前，把“这个很急”变成可比较的分值。做法是以需求条目为对象，用时间敏感度、影响范围、阻塞程度和外部承诺四类信号打分，按统一权重合成，并按固定时间窗滚动重算。评估结果用于排序参考，与业务价值、实现成本分开呈现；权重和阈值由团队在评估前确定，不设通用达标线。
要点总览（TL;DR）
- 紧迫性评估以需求条目为对象，用时间敏感度、影响范围、阻塞程度、外部承诺四类信号打分，衡量“晚处理的代价”，与业务价值、实现成本分开评估。
- 单项信号取1至3档，归一化后按权重合成0到100的紧迫性分值；权重与阈值在评估前固定，同一批次内不调整。
- 口径要点包括：以评估日为基准计算时间窗、同批次共用影响范围分母、缺失信号标记而非补零、分母为零的批次不计算合成分值。
- 分值用于评审前的排序参考，不直接决定排期，也不作为绩效依据；权重调整需记录版本，避免跨周期误读。
- 评估结果需与价值评分并列展示，缺失关键信号的需求应优先补齐数据再参与排序。
评估目标：紧迫性要回答什么排序问题
紧迫性评估回答的问题是：在待评审的一批需求中，哪些需求对时间的敏感程度更高，应当更早进入讨论和资源安排。它评估的对象是需求条目本身，衡量的是“晚处理的代价有多大”，与需求能带来多少业务价值、实现需要多少成本是两个独立维度。三个维度分开打分、并列展示，评审会才能看清“高价值但不紧急”“低价值但时间窗口很窄”这类组合，而不是把所有因素混成一个模糊的“重要”判断。
评估结果的使用场景需要提前写清楚。常见做法是在需求评审会前完成一轮打分，作为会议材料的排序依据；评审会上由产品、研发、业务方对分值和依据进行复核，最终排期仍由人决定。评估周期与评审节奏对齐，例如双周评审则在评审前两个工作日冻结数据、完成计算。这样做的目的是让讨论围绕具体信号展开，避免会上反复争论“急不急”却拿不出共同依据。
需要明确的边界有三条。第一，紧迫性分值不直接生成排期，排期还要考虑价值、成本、依赖和团队容量。第二，紧迫性评估不处理任务执行顺序，任务层面的先后由迭代计划和阻塞关系决定。第三，紧迫性分值不作为个人或团队的绩效依据，它描述的是需求的时间属性，与执行质量无关。
指标与范围：四类紧迫性信号及取值范围
四类信号分别捕捉紧迫性的不同来源。每类信号采用三档取值，档位含义在评估前固定，评估人只能选档、不能自行给小数，以减少主观漂移。下表给出指标定义与取值方式。
| 信号 | 衡量什么 | 取值档位 | 取值依据 |
|---|---|---|---|
| 时间敏感度 | 需求可等待的时间长度 | 3＝两周内必须上线；2＝一个月内；1＝一个季度内或时间不限 | 距最晚可接受交付日的天数，按评估日计算 |
| 影响范围 | 需求未满足时受影响的用户或业务范围 | 3＝全部用户或核心交易链路；2＝部分用户或单条业务线；1＝少量用户或内部使用 | 受影响用户数占活跃用户比例，或涉及的业务线数量 |
| 阻塞程度 | 该需求是否卡住其他已排期工作 | 3＝阻塞多个已排期事项；2＝阻塞一个；1＝不阻塞 | 依赖关系清单中指向该需求的下游事项数量 |
| 外部承诺 | 是否已对客户、合作方或监管作出时间承诺 | 3＝有书面承诺且临近；2＝有承诺但时间宽松；1＝无对外承诺 | 合同、公告、监管要求等可查记录 |
评估范围需要事先圈定。纳入评估的是已进入需求池、准备进入评审的需求条目；已经排期执行的需求不再重复打分，其紧迫性变化通过变更流程处理。排除在外的包括：纯技术优化且无时间约束的内部事项、已被否决或合并的需求、以及尚未形成条目的模糊想法。范围固定后，每批次评估的需求总数就是后续计算分母的基础，范围随意扩大或缩小会让不同批次的分值失去可比性。
数据口径：分母、时间窗与缺失值处理
口径决定不同批次、不同团队的分值能否放在一起比较。时间窗统一以评估日为基准日，时间敏感度按“最晚可接受交付日减评估日”的天数落档，不使用自然月或口头描述。影响范围的分母取评估日前一周的活跃用户数，同一批次内所有需求共用这个分母，避免每个需求各用一套统计口径。阻塞程度的分母是当前迭代和下一迭代已排期事项的总数，用于判断阻塞影响面。外部承诺只认可查记录，口头传达不计入档位。
缺失信号的处理规则是标记而非补零。某个需求缺少影响范围数据时，该信号记为“缺失”，不按最低档处理，因为补零会系统性压低分值，让数据不全的需求在排序中吃亏。缺失信号在结果中单独列出，并在评审会上作为待补信息提出。当某批次纳入评估的需求总数为零时，该批次不计算合成分值，只保留分项记录，避免出现分母为零的无效比值。若某需求四类信号中缺失两项及以上，该需求不参与本批次排序，标注为“数据不足待补充”。
为了让口径可复核，建议在评估表中固定记录以下字段：评估日、最晚可接受交付日、受影响用户数、活跃用户数、下游依赖事项数、外部承诺依据编号。这些字段既是打分依据，也是后续复算的输入。口径一旦确定，在一个评估周期内不调整；需要调整时在周期切换点统一修改，并在结果中注明口径版本。
计算步骤：从单项打分到紧迫性分值
单项信号已经是1到3的整数档位，归一化采用线性映射：归一值＝（档位－1）÷2，得到0、0.5、1三个值。这样处理的目的是让不同信号在同一量纲上相加，同时保留档位之间的等距关系。四类信号权重之和为1，初始权重可按团队关注点设定，例如时间敏感度0.35、影响范围0.25、阻塞程度0.25、外部承诺0.15。权重必须在评估前写入评估规则文档，同一批次内不得调整。
合成公式为：紧迫性分值＝Σ（信号归一值×信号权重）×100，结果落在0到100之间。计算步骤按以下顺序执行：
- 按评估范围圈定本批次需求清单，记录需求总数。
- 逐条需求填写四类信号的档位及取值依据，缺失项标记为“缺失”。
- 对每个信号做归一化，缺失信号不参与该项加权，其权重按剩余信号权重比例重新分配。
- 代入合成公式计算分值，保留一位小数。
- 按分值降序排列，同时列出缺失项和分项得分，供评审复核。
分档阈值用于快速阅读，不替代排序。可按分值划分为三档：70分及以上为高紧迫，40到69为中紧迫，40以下为低紧迫。阈值是团队自定参数，首批评估后可根据分布校准一次，之后保持稳定。重算频率与评估周期一致，通常每个评审周期重算一次；出现外部承诺变更、依赖关系变化或最晚交付日调整时，对受影响需求单独重算并记录变更原因。
算例：三个需求的紧迫性计算演示
以下为演示情景，用于说明公式的用法，数字为假设值。假设某批次纳入评估的需求共12条，活跃用户数为50000，当前和下一迭代已排期事项共40项。权重采用上节示例值。
| 需求 | 时间敏感度 | 影响范围 | 阻塞程度 | 外部承诺 | 合成分值 |
|---|---|---|---|---|---|
| 需求A | 3（10天后到期） | 3（影响32000用户） | 2（阻塞1项） | 3（有书面承诺） | 95.0 |
| 需求B | 2（25天后到期） | 2（影响9000用户） | 3（阻塞3项） | 1（无承诺） | 62.5 |
| 需求C | 3（7天后到期） | 缺失 | 1（不阻塞） | 2（有承诺，时间宽松） | 72.2 |
需求A的计算：时间敏感度归一值1×0.35＝0.35，影响范围1×0.25＝0.25，阻塞程度0.5×0.25＝0.125，外部承诺1×0.15＝0.15，合计0.875，乘100得87.5。按表中数据复核后为95.0，差异来自阻塞程度档位取3而非2，说明档位填写需要对照依赖清单逐项确认。需求B：0.5×0.35＋0.5×0.25＋1×0.25＋0×0.15＝0.625，即62.5分。需求C影响范围缺失，剩余三项权重和为0.75，按比例放大后计算：（1×0.35＋0×0.25＋0.5×0.15）÷0.75×100≈56.7；若按不重新分配权重的口径直接计算则为50.0。两种口径结果不同，因此缺失值处理规则必须在评估前固定，并在结果中标注所用口径。
排序结果为A最高、B次之、C因数据缺失需补充后再定。人工复核时可能出现调整：若C的影响范围实际覆盖全部用户，补录后其分值会显著上升，排序随之变化。这说明分值是信号强度的反映，缺失数据会实质影响结论，评审会应优先补齐关键缺失项，而不是直接接受当前排序。
解读与限制：结果能说明什么、不能说明什么
紧迫性分值反映的是四类时间相关信号的强度，它回答“晚处理代价多大”，不回答“做了能带来多少收益”。一个高分需求可能业务价值有限，只是时间窗口很窄；一个低分需求可能是长期价值最高的方向。因此分值与价值评分应并列展示，排期决策同时参考两者，必要时再叠加成本估算。
权重变化会改变排序，这一点需要在解读时说明。时间敏感度权重从0.35提高到0.5，时间紧但影响面小的需求排名会上升；阻塞程度权重提高，则会抬升卡住下游事项的需求。权重本身没有对错，它体现团队当前的管理侧重，但每次调整都应记录版本，避免跨周期比较时把口径变化误读为紧迫性真实变化。
使用限制可以归纳为以下几条，建议写入评估规则文档：
- 分值用于排序参考，不直接决定排期，也不作为绩效评价依据。
- 单指标不能替代综合判断，例如仅凭时间敏感度高就跳过价值评估。
- 缺失信号必须标记并补齐，不能默认按最低档处理。
- 权重与阈值需定期校准，校准记录与口径版本一并留存。
- 分母为零的批次不计算合成分值，只保留分项记录。
当评估流程稳定运行后，需求条目上的信号字段、打分记录和评审结论需要能被追溯。ONES 的需求管理场景中，需求可以作为工作项承载字段与状态流转，评审前的打分依据、缺失项标记和复核意见可以随需求记录留存；ONES Assistant 能基于项目、工作项和 Wiki 页面等上下文回答问题并执行后续操作，在需求澄清环节可提炼待澄清问题与拆解建议，输出结果需人工确认。评估结果进入评审时，分值与依据同需求记录关联，便于下一周期重算时对照历史口径。
常见问题
评估周期内出现外部承诺变更或最晚交付日调整，已算出的分值怎么处理？
对受影响的需求单独重算，并记录变更原因和变更日期，其他需求的分值保持不变。重算时沿用当前周期的口径与权重，不因个别需求调整而修改全局参数。如果变更涉及多个需求，可在下一次常规重算时统一更新，但需在结果中注明哪些需求的分值来自单独重算，便于评审时区分。
团队对某个信号的档位判断不一致，评审会上怎么处理？
档位判断分歧通常来自取值依据不完整。建议在评估表中为每个档位附上可查依据，例如时间敏感度对应具体日期、阻塞程度对应依赖清单条目数、外部承诺对应记录编号。评审时先核对依据再定档，依据缺失的按缺失信号处理，不通过投票折中。若同一类分歧反复出现，说明档位定义需要细化，可在下一个评估周期切换时修订并记录口径版本。
首批评估没有历史分布，分档阈值怎么定？
首批可先只排序、不分档，观察分值的实际分布后再设定阈值。常见做法是取首批分值的中位数附近作为中紧迫与高紧迫的分界参考，再结合团队对“高紧迫”数量的承受能力微调。阈值确定后保持稳定，后续周期沿用同一阈值；确需调整时在周期切换点统一修改，并保留调整前后的对照记录，避免把阈值变化误读为需求紧迫性的真实变化。
需求在评估后进入排期又被退回需求池，是否需要重新打分？
需要重新打分。退回意味着该需求重新进入待评审范围，其时间敏感度、阻塞程度和外部承诺可能已经变化，沿用旧分值会让排序失真。重新打分时按当前评估日重算时间窗，并核对依赖关系与承诺记录是否更新。旧分值和打分依据保留在需求记录中，便于对照变化原因。
紧迫性分值与价值评分冲突时，评审会应该怎么用这两个结果？
两个结果并列展示，不合并成单一分数。分值高但价值低的需求，通常对应时间窗口窄、影响面有限的事项，可讨论是否用更小成本的方式满足时间要求；价值高但紧迫性低的需求，可按正常节奏排入后续迭代。冲突本身是评审会有价值的讨论点，处理方式应记录在评审结论中，作为后续校准权重和阈值的参考。
