昨天（6月24日）的主题是 IPD 集成产品开发流程，最后一次的预告是"硬件产品PRD撰写规范"。今日按计划轮换到 PRD 主题。
📚 智能硬件PM学习日报 | 2026年06月25日（周四）
🎯 今日主题：硬件产品需求文档（PRD）撰写规范——让研发团队"看得懂、用得上"（约15分钟）
【概念解释】
PRD（Product Requirements Document，产品需求文档）是产品经理与研发团队之间的"契约"。对于智能硬件产品而言，PRD的复杂度远高于纯软件产品——因为它需要同时定义硬件规格、结构设计、软件功能、交互逻辑、测试标准等多个维度的需求。
昨天我们学了 IPD 流程，PRD 正是 IPD 计划阶段（Plan Phase） 的核心交付物，是连接"概念阶段的市场洞察"与"开发阶段的技术实现"的关键桥梁。一份好的 PRD 能直接决定项目能否顺利通过 PDCP（计划决策检查点）。
【为什么硬件PRD特别难写？】
| 维度 | 软件PRD | 硬件PRD |
|---|---|---|
| 变更成本 | 改代码重新发布即可 | 改PCB→重新打样→重新测试→可能改模具 |
| 涉及学科 | 前端+后端+UI/UX | 结构+电气+射频+热设计+嵌入式+外观 |
| 周期影响 | 改动可能只影响1-2个Sprint | 一次变更可能导致项目延期2-4周 |
| 验证方式 | 自动化测试+灰度发布 | 开模验证→DVT→可靠性测试→认证 |
核心教训：硬件PRD写不清楚，后面每一个环节都会为此买单。
【硬件PRD的完整结构模板】
以下是智能硬件PRD的标准章节结构，适用于无人机、智能家居、可穿戴设备等品类：
硬件产品PRD结构
├── 1. 文档概述（版本控制、修订记录）
├── 2. 产品概述（定位、目标用户、使用场景）
├── 3. 产品规格表（硬件参数矩阵）
├── 4. 功能需求（分模块描述）
│ ├── 4.1 硬件功能需求
│ ├── 4.2 结构/外观需求
│ ├── 4.3 软件/固件功能需求
│ └── 4.4 交互/体验需求
├── 5. 非功能需求（性能、可靠性、安全、认证）
├── 6. 接口定义（硬件接口、通信协议）
├── 7. 约束条件（成本目标、功耗、尺寸、重量）
├── 8. 验收标准（测试用例概要）
├── 9. 风险与待定项
└── 10. 附录（参考图片、竞品数据、术语表）
【各章节撰写要点与实例】
1. 文档概述——别小看版本控制
文档编号：PRD-CP-2026-003
产品名称：XX智能机场Pro
版本：V2.1
状态：评审中
修订记录：
V1.0 2026-05-10 初稿
V1.1 2026-05-18 根据PDT评审意见修订
V2.0 2026-06-01 硬件规格重大调整
V2.1 2026-06-20 补充认证需求
⚠️ PM常犯错误：不维护版本记录，研发拿到的PRD不知道是第几版，开发到一半才发现规格已变。
2. 产品概述——用"5W1H"框架讲清楚
- What：这是一款什么产品？（一句话定义）
- Who：目标用户是谁？（用户画像，不是"所有人"）
- Why：用户为什么要买？（核心痛点）
- Where：在什么场景下使用？（室内/室外/极端环境）
- When：计划什么时候上市？（商业窗口期）
- How：用户怎么使用？（核心使用流程）
🔍 无人机机场案例：
What：面向电力巡检场景的自动机场，支持无人机自动起降、充电、数据回传
Who：电力公司运维部门，有3人以上的无人机作业团队
Why：解决人工到现场操控无人机效率低、受天气/距离限制的问题
Where：户外架空线路沿线，需IP55防护等级，工作温度-20°C~55°C
When：2026年Q4上市，抢占年底电力行业预算窗口
How：远程一键起飞→自动巡航→AI识别缺陷→自动返航充电→数据上传
3. 产品规格表——研发的"菜谱"
这是硬件PRD中最核心的部分。建议用参数矩阵格式：
┌─────────────────┬──────────────┬──────────────┬──────────────┐
│ 参数类别 │ 参数项 │ 目标值 │ 约束/备注 │
├─────────────────┼──────────────┼──────────────┼──────────────┤
│ 基本参数 │ 外形尺寸 │ ≤800×800×600mm│ 含防雨罩 │
│ │ 重量 │ ≤45kg │ 含电池模组 │
│ │ 防护等级 │ IP55 │ 强制要求 │
├─────────────────┼──────────────┼──────────────┼──────────────┤
│ 充电系统 │ 充电功率 │ ≥600W │ 快充模式 │
│ │ 充电时间 │ ≤40min(20→90%)│ 标准温度下 │
│ │ 充电接口 │ 弹簧针式 │ 支持盲插 │
├─────────────────┼──────────────┼──────────────┼──────────────┤
│ 环境适应 │ 工作温度 │ -20°C~55°C │ 含温控系统 │
│ │ 抗风能力 │ ≥6级风 │ 关门状态 │
│ │ 海拔适应 │ ≤4000m │ 高原版本 │
├─────────────────┼──────────────┼──────────────┼──────────────┤
│ 通信系统 │ 网络连接 │ 4G+5G+WiFi6 │ 双卡双待 │
│ │ 远程管理 │ 平台对接 │ API标准接口 │
├─────────────────┼──────────────┼──────────────┼──────────────┤
│ 成本目标 │ BOM成本 │ ≤1.2万元 │ 不含无人机 │
│ │ 目标售价 │ 3.5-4万元 │ 经销商价格 │
└─────────────────┴──────────────┴──────────────┴──────────────┘
⚠️ PM常犯错误：只写"目标值"不写"约束条件"。比如写"充电时间≤40min"但没说温度条件，研发在-20°C环境下达不到，双方扯皮。
4. 功能需求——分模块、分优先级
建议用 MoSCoW 方法 标注优先级：
- Must have（必须有）：没有就不能上市
- Should have（应该有）：重要但可延期
- Could have（可以有）：锦上添花
- Won't have（本期不做）：明确排除
🔍 示例——机场盖板开合功能：
功能ID：FUNC-003
功能名称：机场盖板自动开合
优先级：Must have
描述：机场接收到无人机起飞指令后，盖板自动打开；
无人机降落后，盖板自动关闭，防护雨雪灰尘。
触发条件：起飞指令/降落完成信号
执行时间：开合时间≤8秒
异常处理：
- 开合超时→重试1次→报警并通知运维
- 传感器检测到障碍物→停止动作→报警
- 手动模式→APP可远程操控开合
关联需求：FUNC-001（无人机对接）、NFUNC-005（IP55防护）
5. 非功能需求——硬件PM容易忽略的部分
可靠性要求：
- 设计寿命：≥5年（基于每天开合2次计算）
- MTBF：≥10000小时
- 盖板开合次数：≥5000次（无故障）
安全要求：
- 电气安全：符合GB 4943.1
- 防雷等级：≥10kA（户外安装场景）
- 紧急停止：物理断电按钮
认证要求：
- 3C认证（国内）、CE（欧洲）、FCC（北美）
- 型号核准（无线电发射设备）
- 环保认证（RoHS/REACH）
电磁兼容（EMC）：
- 辐射发射：符合GB 9254 Class B
- 抗扰度：符合GB/T 17626 等级3
6. 接口定义——硬件PRD的独特章节
机械接口：
- 无人机对接口：适配DJI M30T/M350 RTK
- 安装接口：4×M12地脚螺栓，孔距600×600mm
- 走线孔：底部3个，直径≥25mm
电气接口：
- 供电输入：AC 220V±15%，50Hz
- 备用电源：48V/10Ah锂电池，续航≥4小时
- 充电输出：定制弹针接口，支持600W
通信接口：
- 网口：RJ45千兆以太网
- 串口：RS485（传感器扩展）
- 无线：4G/5G蜂窝 + WiFi6 + 蓝牙5.0
- API：RESTful，JSON格式，文档另附
【硬件PRD撰写的7条黄金法则】
法则1：写"做什么"，不写"怎么做"
PRD是需求文档，不是设计文档。你应该写"盖板开合时间≤8秒"，而不是"用XX电机配合YY减速箱"。具体方案留给研发团队决策。
法则2：每个需求都要可测试
如果你写的需求无法被测试验证，那它就不是有效需求。"系统要稳定"→ ❌ 不可测试；"连续运行72小时无崩溃"→ ✅ 可测试。
法则3：用数据说话，不用形容词
"体积要小"→ ❌；"外形尺寸≤800×800×600mm"→ ✅
"充电要快"→ ❌；"20%→90%充电时间≤40分钟（25°C环境）"→ ✅
法则4：标注需求来源
每条需求最好注明来源：用户调研/竞品分析/法规要求/销售反馈。这在需求评审时能帮你捍卫需求的合理性。
法则5：区分"需求"和"方案"
"需要支持RTK定位"→ 这是需求
"使用千寻位置的RTK服务"→ 这是方案
PM定义需求，技术方案由研发团队决定（除非你有充分理由约束方案）。
法则6：画流程图比写文字有效
状态机图、时序图、用例图，一张图胜过三页文字。硬件产品尤其需要状态机图——设备在不同状态（待机、工作、充电、故障、OTA升级）之间的转换逻辑。
法则7：PRD是活文档，要持续迭代
PRD不是写完就扔给研发的。在开发过程中，需求会因技术限制、市场变化而调整。关键是要走正式的变更流程（ECN），而不是口头通知。
【智能硬件PRD vs 软件PRD的特殊章节】
| 特殊章节 | 内容 | 为什么重要 |
|---|---|---|
| BOM成本预算 | 目标成本、关键器件选型约束 | 硬件成本一旦定型极难压缩 |
| DFM要求 | 可制造性约束、装配工艺要求 | 避免"设计很美好，工厂做不出" |
| 模具需求 | 开模件清单、模具预算、模具周期 | 模具费用高、周期长，需提前规划 |
| 认证需求清单 | 3C/CE/FCC/UL等 | 影响产品上市时间，需提前启动 |
| 包装运输要求 | 包装方案、跌落测试标准、物流方式 | 大件硬件的物流成本和损坏率 |
| 环保合规 | RoHS/REACH/WEEE/碳足迹 | 出口产品强制要求 |
💡 知识速览（5个知识点，每个1-2分钟）
① 需求评审的"三方会审"机制
硬件PRD评审至少需要三方参与：研发（技术可行性）、供应链/采购（成本可行性）、品质（质量可行性）。只和研发对齐需求是不够的——研发说"能做"，采购说"这个芯片买不到"，品质说"这个测试标准过不了"，项目照样卡住。建议在正式PDT评审前，先分别与三方做预沟通。
② PRD中的"需求追溯矩阵"（RTM）
RTM（Requirements Traceability Matrix）是将每条需求与其来源（市场洞察/用户反馈/法规）、设计实现、测试用例一一对应。它的价值在于：当需求变更时，你能快速评估影响范围——"改了这个参数，哪些设计要改、哪些测试要重做？"。1.5年经验的PM可能觉得麻烦，但当项目复杂度上来后，RTM会救你的命。
③ "需求冻结"节点的把控
在IPD流程中，需求应该在计划阶段（Plan Phase）结束、PDCP通过后基本冻结。之后的需求变更需要走ECN流程。但实际操作中，"需求永远在变"是常态。PM要学会区分"真需求变更"（市场环境变了）和"伪需求变更"（一开始没想清楚）。前者要及时响应，后者要坚决抵制。
④ FMEA在PRD中的应用
FMEA（Failure Mode and Effects Analysis，失效模式与影响分析）不仅是品质工具，PM也应该在写PRD时提前思考：这个功能可能怎么失效？失效后对用户的影响有多大？比如无人机机场盖板打不开→无人机无法降落→电量耗尽坠机。这种高严重度的功能，PRD中必须写明冗余设计和应急方案。
⑤ 用户故事 vs 硬件需求的融合写法
传统硬件PRD偏重规格参数，但容易忽略用户视角。建议在每个功能模块开头先写一段用户故事（User Story）："作为一名电力巡检员，我希望在办公室就能远程启动无人机巡线，这样我不用驱车2小时到现场"，然后再列出具体的技术需求。这样研发团队不仅知道"做什么"，还知道"为什么做"，有助于做出更好的技术决策。
📌 今日金句
"PRD的质量决定产品的下限，PRD的迭代速度决定产品的上限。一份写得清楚的PRD，能帮团队省掉50%的返工成本。"
🎓 今日练习
- 实战练习：挑你当前负责的一个硬件产品功能，用今天讲的模板结构重写一遍PRD对应章节，对比你之前的版本，看看哪些地方可以改进
- 自查清单：检查你现有PRD中的每条需求——是否满足"可测试、有数据、标来源"三个条件？把不满足的补上
- 延伸阅读：推荐《人人都是产品经理》（苏杰著）中关于需求文档的章节；进阶可看《产品需求管理：IPD需求管理》
📅 明日预告：硬件BOM成本管理——从元器件选型到成本优化的全流程实战