第二章 原型选择前置条件梳理：技术成熟度评估、用户需求优先级、资源约束

适用场景

• 团队启动新硬件项目，准备从概念阶段进入第一个可交互原型制作前。
• 现有原型迭代到第 N 轮，需要决策是否升级核心模块或换方案时。
• 跨部门（硬件、软件、产品、供应链）首次对齐 MVP 范围，需统一评估口径。

前置条件

操作步骤

1. Step 1：技术成熟度评估
   • 梳理候选方案清单（主控、无线芯片、传感器、执行器），每个方案至少检索 1 份官方参考设计或 NDA 技术手册。
   • 制作 TRL 自评表（1~3 级：原理验证/实验室/功能样片），低于 3 级的方案强制标记为风险项。
2. Step 2：用户需求优先级映射
   • 从产品 PRD 中提取 Top‑10 功能/场景，使用 Kano 问卷（内部 5 人+外部 5 人）完成分类。
   • 将 Must‑be 需求标记为 P0（必选），Performance 为 P1（优先争取），Attractive 为 P2（看资源余量）。
3. Step 3：资源约束量化
   • 将预算拆解为：单板 BOM ≤ X 元，开模/打样 ≤ Y 元，测试认证 ≤ Z 元。
   • 时间约束按 T0+6 周、T0+12 周、T0+18 周设置里程碑门禁。
   • 人力约束：硬件工程师 ≤ 2 人，嵌入式 ≤ 1 人，且不能 100% 全职。
4. Step 4：冲突决策与降级路径
   • 若技术成熟度低但需求 P0 → 优先选技术更成熟的替代方案，必要时削 P0 需求范围。
   • 若资源不足覆盖所有 P0+P1 → 主动砍到只剩 P0，并记录溢出需求档案。
   • 形成《原型选择前置条件确认表》，由技术负责人、产品经理、项目经理三方会签。

输入输出物

责任边界

记录材料

• 归档件：《技术成熟度评估表》《Kano 分类与映射表》《资源约束量化清单》《前置条件确认表》—— PDF 签章版，存入项目共享盘 /tag v1.0 文件夹。
• 过程件：问卷原始数据（匿名化）、冲突讨论纪要、降级决策邮件截图。保留至 MVP 终验后销毁。
• 模板：使用附件《硬件 MVP 前置条件工作簿.xlsx》，包含已预设公式的 TRL 评分卡和 Kano 计算表。

异常处理

验收标准

• 《前置条件确认表》中所有字段完整填写，无空白项。
• TRL 自评项中，所有选定方案最低 TRL ≥ 3（如有例外须另附论证文档）。
• 用户需求优先级已按 Kano 分类明确标注，且 P0 总数 ≤ 5 项。
• 资源约束清单红线已逐项对比，并有项目经理数字签名确认。
• 三方会签在 T0+3 个工作日内完成，存档路径可追溯。