4. 需求边界定义规则
适用场景
在机器人产品需求评审的早期阶段，当候选需求池已初步收敛但尚未进入详细设计时，需通过本规则对每条需求进行边界判定。适用场景包括：
- 项目立项前的需求筛选会
- 版本迭代的Backlog梳理会
- 跨部门（产品、研发、市场、供应链）联合评审会
前置条件
- 已形成《候选需求清单》，每条需求包含用户故事、预期价值、初步工作量估算。
- 已明确当前产品路线图（Roadmap）及战略优先级。
- 已掌握可调用的技术资源池（研发人力、算法成熟度、硬件平台）和预算上限。
- 已完成至少一轮市场验证（用户调研、竞品分析、可行性原型测试）。
操作步骤
核心流程：每轮评审按“战略对齐 → 技术约束 → 资源限制 → 市场验证标准”四维过滤，标记为“通过”、“需调整”或“拒绝”。
- 产品战略对齐：将需求与当前产品战略目标（如“抢占医疗消毒机器人市场”“降低BOM成本30%”）对照，不匹配的直接标记“拒绝”并记录原因。
- 技术约束检查：评估需求是否在当前技术栈内可实现，或是否存在已知未攻克的核心算法/硬件瓶颈。若存在高风险技术缺口，标记“需调整”并说明替代方案。
- 资源限制评估：按人天、预算、关键设备（如高精度电机、3D传感器样品）约束进行容量核算。超出可用资源部分标记“需调整”或“拒绝”，并给出资源追加建议。
- 市场验证标准：验证需求是否通过用户测试/小范围试制/MVP数据验证。未通过验证的需求禁止进入开发阶段，但可进入“待验证池”等待下一轮验证。
输入输出物
| 项目 | 输入物 | 输出物 |
|---|---|---|
| 产品战略对齐 | 产品路线图、战略目标卡片 | 战略对齐矩阵（通过/拒绝/调整） |
| 技术约束检查 | 技术栈文档、风险评估报告 | 技术约束清单（含风险等级） |
| 资源限制评估 | 人力容量表、预算表、关键物料库存 | 资源分配甘特图（更新版） |
| 市场验证标准 | 用户测试报告、竞品对比数据 | 验证决策表（通过/待验证/拒绝） |
责任边界
- 产品经理：主导战略对齐与市场验证判断，输出需求边界判断报告。
- 技术负责人（架构师/技术经理）：负责技术约束与资源限制评估，给出可行性结论。
- 项目经理/Scrum Master：协调评审会议，确保输入物准备齐全，记录会议决议。
- 决策委员会（CTO/产品VP）：对“需调整”项进行最终裁决，审批资源追加或需求变更。
记录材料
每次边界评审必须填写以下文档并归档：
《需求边界评审记录表（v4.x）》
├── 需求编号
├── 需求标题
├── 战略对齐结论（理由）
├── 技术约束结论（风险点）
├── 资源限制结论（缺口/余量）
├── 市场验证结论（数据来源）
├── 综合结论（通过/调整/拒绝）
├── 调整后方案描述（如有）
└── 评审日期 & 签字人异常处理
常见异常场景及应对：
| 异常场景 | 处理方式 |
|---|---|
| 战略目标冲突（两个需求均重要但方向相反） | 启动战略优先级投票，由产品VP一票裁决。 |
| 技术评估结论为“不可行”但市场认为必须做 | 标记为“需预研”，转入技术预研冲刺。 |
| 资源超限但拒绝降低范围 | 触发“范围-成本-时间”折中会议，必要时延迟版本。 |
| 市场验证数据不足（样本量小或矛盾） | 延长验证周期，需求状态设为“待验证”。 |
验收标准
- 每条候选需求均经过四维规则检查，并至少有一条明确的综合结论。
- 输出的《需求边界评审记录表》由产品经理、技术负责人、决策委员会三方签字。
- “通过”的需求进入需求池优先级排序；“调整”项需附上修正方案后才可重新提交；“拒绝”项需注明原因并归档备查。
- 整个评审流程在2个工作日内完成（从输入物准备到签字归档）。