2. Reach维度定义：用户触达范围、硬件需求影响面、计算公式、量化示例

适用场景

• 需要对硬件需求进行量化排序时，尤其是涉及多用户、多设备、高频使用的场景。
• 团队需要统一“用户影响程度”的度量口径，避免主观判断。
• 需求池中有大量相似 Hardware Change Request (HCR)，需要快速筛选高影响项。

前置条件

• 已完成需求功能描述和初步的硬件变更影响分析。
• 已获取或可估算目标用户群体规模（如出货量、活跃设备数、历史客诉数据）。
• 已确定需求触发的频率类型（一次性/周期性/持续型）。
• 团队已就“影响面”的定义达成共识（如每个用户受影响的设备数、交互次数、工时等）。

操作步骤

1. 步骤1：确定用户触达范围（U）
   统计该硬件需求在生命周期内直接影响的用户数量。例如：出货量中的终端用户数、目标机型存量用户数。
2. 步骤2：确定硬件需求影响面（I）
   评估每位受影响用户平均涉及多少设备、多少交互行为或多少工时。例如：升级充电接口 → 每位用户有 2 台设备需适配；增加散热孔 → 每用户每天影响 1 次使用。
3. 步骤3：确定触发频率因子（F）
   定义需求被用户触发的频率（每天/每周/每月/一次性）。例如：日常功能 → 每天 1 次；OTA 升级 → 仅 1 次。
4. 步骤4：计算 Reach 值
   使用公式 Reach = U × I × F，得到无量纲分数，用于后续 RICE 综合排序。
5. 步骤5：记录量化依据
   在需求卡片中注明 U、I、F 的来源和估算方法，便于复核。

输入输出物

责任边界

• 硬件产品经理（HPM）：负责提供 U 值（用户群范围）和 I 值（影响面系数），并解释估算逻辑。
• 系统工程师（SE）：负责核实 I 值中涉及的技术影响范围（如引脚改动、散热仿真）。
• 项目经理（PM）：负责定义 F 值（频率因子）并组织跨职能对齐。
• 质量/测试代表：提供历史客诉数据作为 U 值的参考基线。

记录材料

异常处理

• 用户范围无法精确统计：使用保守估计（取下限），并在备注中标注“估算中位数/范围”。
• 影响面 I 存在争议：组织专家评审会，若仍无法统一则采用“最大可能值 × 0.7 折扣系数”作为暂定值。
• 频率因子 F 跨多种场景：按主要使用场景取加权平均值，并在记录材料中分解说明。
• 遗漏特殊用户群（如研发样机、演示机）：统一在 U 值中排除不计，避免膨胀。

验收标准

• 每个被排序的需求都有明确的 Reach 值，且 U、I、F 三项数据均可在步骤记录中追溯。
• Reach 计算表已至少通过 1 位跨角色复核（SE 或 PM 签字/审批）。
• 所有估算假设（如用户基数、频率）都在备注中说明，无未记录的主观判断。
• 量化示例可复现：任意读者按照步骤和公式代入不同数字，能得到一致的 Reach 分数。

Reach = U × I × F