第4章：需求边界定义规则

适用场景

在机器人产品需求评审的早期阶段，当候选需求池已初步收敛但尚未进入详细设计时，需通过本规则对每条需求进行边界判定。适用场景包括：

• 项目立项前的需求筛选会
• 版本迭代的Backlog梳理会
• 跨部门（产品、研发、市场、供应链）联合评审会

前置条件

1. 已形成《候选需求清单》，每条需求包含用户故事、预期价值、初步工作量估算。
2. 已明确当前产品路线图（Roadmap）及战略优先级。
3. 已掌握可调用的技术资源池（研发人力、算法成熟度、硬件平台）和预算上限。
4. 已完成至少一轮市场验证（用户调研、竞品分析、可行性原型测试）。

操作步骤

1. 产品战略对齐：将需求与当前产品战略目标（如“抢占医疗消毒机器人市场”“降低BOM成本30%”）对照，不匹配的直接标记“拒绝”并记录原因。
2. 技术约束检查：评估需求是否在当前技术栈内可实现，或是否存在已知未攻克的核心算法/硬件瓶颈。若存在高风险技术缺口，标记“需调整”并说明替代方案。
3. 资源限制评估：按人天、预算、关键设备（如高精度电机、3D传感器样品）约束进行容量核算。超出可用资源部分标记“需调整”或“拒绝”，并给出资源追加建议。
4. 市场验证标准：验证需求是否通过用户测试/小范围试制/MVP数据验证。未通过验证的需求禁止进入开发阶段，但可进入“待验证池”等待下一轮验证。

输入输出物

项目	输入物	输出物
产品战略对齐	产品路线图、战略目标卡片	战略对齐矩阵（通过/拒绝/调整）
技术约束检查	技术栈文档、风险评估报告	技术约束清单（含风险等级）
资源限制评估	人力容量表、预算表、关键物料库存	资源分配甘特图（更新版）
市场验证标准	用户测试报告、竞品对比数据	验证决策表（通过/待验证/拒绝）

责任边界

• 产品经理：主导战略对齐与市场验证判断，输出需求边界判断报告。
• 技术负责人（架构师/技术经理）：负责技术约束与资源限制评估，给出可行性结论。
• 项目经理/Scrum Master：协调评审会议，确保输入物准备齐全，记录会议决议。
• 决策委员会（CTO/产品VP）：对“需调整”项进行最终裁决，审批资源追加或需求变更。

记录材料

每次边界评审必须填写以下文档并归档：

《需求边界评审记录表（v4.x）》
├── 需求编号
├── 需求标题
├── 战略对齐结论（理由）
├── 技术约束结论（风险点）
├── 资源限制结论（缺口/余量）
├── 市场验证结论（数据来源）
├── 综合结论（通过/调整/拒绝）
├── 调整后方案描述（如有）
└── 评审日期 & 签字人

异常处理

异常场景	处理方式
战略目标冲突（两个需求均重要但方向相反）	启动战略优先级投票，由产品VP一票裁决。
技术评估结论为“不可行”但市场认为必须做	标记为“需预研”，转入技术预研冲刺。
资源超限但拒绝降低范围	触发“范围-成本-时间”折中会议，必要时延迟版本。
市场验证数据不足（样本量小或矛盾）	延长验证周期，需求状态设为“待验证”。

验收标准

1. 每条候选需求均经过四维规则检查，并至少有一条明确的综合结论。
2. 输出的《需求边界评审记录表》由产品经理、技术负责人、决策委员会三方签字。
3. “通过”的需求进入需求池优先级排序；“调整”项需附上修正方案后才可重新提交；“拒绝”项需注明原因并归档备查。
4. 整个评审流程在2个工作日内完成（从输入物准备到签字归档）。