04-产品需求文档PRD标准化三端项目统一撰写规范与交付模板为什么PRD要标准化上一篇讲了需求全生命周期管理但需求管理流程再好产物文档本身不规范执行也会走样。PRDProduct Requirements Document产品需求文档就是需求管理的核心交付物——它是产品、研发、测试三方对做什么的共同契约。无人售货柜项目有三端如果每端各写各的PRD、各用各的格式问题会马上暴露后端PRD写了接口字段固件没看到对不上小程序PRD描述了交互但没写异常态开发自由发挥测试拿到的验收标准跟开发理解的不一样扯皮所以PRD必须统一结构、统一模板、统一交付标准。PRD文档标准化结构一份合格的PRD包含以下6个核心模块缺一不可1. 背景与目标## 1. 背景与目标 ### 背景 - 业务背景为什么现在做这个功能 - 用户痛点当前存在什么问题 - 数据支撑如果有数据列出来 ### 目标 - 业务目标可量化的业务指标如退款到账时间从24h降至1min - 技术目标技术层面要达成的效果 - 非目标明确说明这版不做什么边界很重要这一段的价值在于让所有人先对齐为什么做再讨论怎么做。很多项目返工是因为开发到一半才发现产品要的跟自己理解的不是一个东西。2. 功能描述## 2. 功能描述 ### 2.1 功能概述 一句话概括这个功能做什么。 ### 2.2 用户角色 | 角色 | 说明 | |------|------| | 消费者 | 扫码购物用户 | | 柜长 | 管理售货柜的运营人员 | | 运营 | 平台运营方 | ### 2.3 核心流程 用流程图或时序图描述主流程标注三端交互节点。 ### 2.4 功能详述 | 编号 | 功能点 | 优先级 | 描述 | |------|--------|--------|------| | F1 | 扫码开门 | P0 | 用户扫码后授权开门 | | F2 | 实时退款 | P1 | 退款1分钟内到账 |功能详述要写到**“另一个没参与讨论的开发也能看懂”**的颗粒度不能默认上下文。3. 接口定义这是三端PRD最容易出问题的地方。接口定义模块要明确## 3. 接口定义 ### 3.1 接口清单 | 接口ID | 接口名称 | 调用方→提供方 | 协议 | |--------|---------|---------------|------| | API-001 | 开门授权 | 小程序→后端 | HTTPS | | API-002 | 下发开门指令 | 后端→固件 | MQTT | | API-003 | 柜门状态上报 | 固件→后端 | MQTT | ### 3.2 接口详情 #### API-001 开门授权 - 请求方式POST /api/v1/door/authorize - 请求参数 | 字段 | 类型 | 必填 | 说明 | |------|------|------|------| | deviceId | String | 是 | 柜机ID | | userId | String | 是 | 用户ID | | qrcode | String | 是 | 扫码内容 | - 响应参数 | 字段 | 类型 | 说明 | |------|------|------| | code | Int | 0成功其他见错误码表 | | message | String | 提示信息 | | data.doorToken | String | 开门令牌传给固件 | - 错误码 | code | 含义 | 处理建议 | |------|------|---------| | 1001 | 柜机离线 | 提示用户换一台 | | 1002 | 二维码过期 | 提示重新扫码 |接口定义的核心要求字段名、类型、必填、含义四要素齐全。小团队不用搞正式API网关但Swagger或YApi必须有PRD里的接口定义跟代码里的保持同步。4. 交互规范UI/UX## 4. 交互规范 ### 4.1 页面流转 扫码页 → 授权中loading页 → 开门成功页 → 购物页 → 关门结算页 ### 4.2 状态说明 | 状态 | 展示 | 触发条件 | |------|------|---------| | 授权中 | 转圈loading正在开门 | 点击扫码后 | | 开门成功 | 绿色勾请取走商品 | 收到固件开门成功上报 | | 开门超时 | 橙色提示开门失败请重试 | 5秒未收到响应 | | 柜机离线 | 灰色提示该柜机维护中 | 后端返回1001 |交互规范的价值在于把异常态也写清楚。90%的体验事故是因为开发只做了正常流程异常态自由发挥。5. 验收标准## 5. 验收标准 ### 5.1 功能验收 | 编号 | 验收项 | 验收条件 | |------|--------|---------| | A1 | 扫码开门 | 正常扫码3秒内柜门打开 | | A2 | 离线柜机 | 扫码后展示维护提示不白屏 | | A3 | 开门超时 | 5秒未响应展示重试入口 | ### 5.2 性能验收 | 指标 | 目标值 | |------|--------| | 开门响应P50 | 2秒 | | 开门响应P95 | 3秒 | | 退款到账时间 | 1分钟 | ### 5.3 兼容性 - 小程序微信基础库2.10.4 - 固件RK3399 Android 7.0 - 后端JDK8 SpringBoot 2.7验收标准要可测试。写体验流畅这种没法验收写P502秒可以测。6. 异常处理## 6. 异常处理 | 异常场景 | 后端处理 | 固件处理 | 小程序处理 | |---------|---------|---------|-----------| | 断网 | 心跳超时标记柜机离线 | 本地缓存开门记录恢复后上报 | 展示网络异常重试 | | 断电 | 未收到状态上报标记离线 | 来电后自检上报状态 | 无感知 | | 支付失败 | 回滚订单 | 不开门 | 展示支付失败原因 | | 固件崩溃 | 5分钟无心跳告警 | 看门狗重启 | 提示柜机维护中 |异常处理模块是三端协同的保险丝。每个异常场景三端都要写清楚自己的处理逻辑联调时逐项验证。三端PRD差异处理无人售货柜三端虽然共用一份PRD但各端关注重点不同差异部分要单独标注后端PRD重点接口定义完整字段、错误码、幂等性要求数据模型核心实体ER图、关键字段业务逻辑状态机、定时任务、消息队列非功能需求并发量、响应时间、可用性安卓工控固件PRD重点硬件交互继电器驱动、传感器读取、串口通信离线策略断网时的本地缓存与恢复逻辑固件升级OTA方案、回滚机制、版本兼容性能约束内存占用、启动时间、功耗微信小程序PRD重点交互流程页面流转、状态切换、loading态微信能力扫码、支付、订阅消息、授权登录兼容性基础库版本、机型适配异常兜底网络异常、接口超时、白屏处理一份PRD里三端差异部分用章节标注区分### 2.4.1 后端逻辑 后端相关描述 ### 2.4.2 固件逻辑 固件相关描述 ### 2.4.3 小程序交互 小程序相关描述这样三端开发各取所需但共享同一份文档不会有信息断层。PRD模板与交付规范模板骨架# [需求编号] 功能名称 PRD ## 文档信息 | 项目 | 内容 | |------|------| | 需求ID | REQ-2026-XXXX | | 版本 | v1.0 | | 作者 | XXX | | 评审日期 | 2026-XX-XX | | 基线版本 | Baseline-2026SXX | ## 1. 背景与目标 ## 2. 功能描述 ## 3. 接口定义 ## 4. 交互规范 ## 5. 验收标准 ## 6. 异常处理 ## 7. 附录原型图、流程图、变更记录交付规范规范项要求文档格式Markdown统一飞书文档或Git仓库管理版本管理PRD纳入Git版本库变更走Commit记录交付时机迭代规划前完成初稿评审通过后纳入基线存放位置统一目录按迭代归档三端共享一份PRD三端共用差异用章节标注PRD评审通过标准PRD评审不是走形式有硬性通过标准评审Checklist□ 1. 背景目标背景清晰目标可量化非目标边界明确 □ 2. 功能描述功能点颗粒度合适优先级标注清楚 □ 3. 接口定义字段四要素齐全名称/类型/必填/含义错误码完整 □ 4. 交互规范正常流程异常流程都有描述状态机完整 □ 5. 验收标准每项可测试、可量化 □ 6. 异常处理三端异常处理逻辑各有描述覆盖断网/断电/支付失败/固件崩溃 □ 7. 三端差异后端/固件/小程序各自关注点已分章节标注 □ 8. 附录有流程图或时序图有原型截图 □ 9. 变更记录初始版本无变更记录后续变更每条有记录评审参与方与职责角色评审重点产品经理功能完整性、业务逻辑、优先级合理性后端负责人接口可行性、数据模型、性能约束嵌入式负责人硬件可行性、离线策略、固件升级方案前端负责人交互可行性、微信能力限制、兼容性测试负责人验收标准可测性、异常场景覆盖度通过判定全部通过PRD纳入基线进入开发3条以内不通过修改后产品经理确认即可无需重新评审4条以上不通过修改后重新组织评审这套标准看似严格实际执行起来一份PRD评审30分钟内能搞定。核心不是文档写多厚而是该有的信息不能缺。小结PRD标准化的核心价值三端信息同源一份文档各取所需消除信息断层验收有据可依开发、测试、产品对做完了的判断一致异常提前暴露联调前就把三端异常处理对齐减少联调返工变更可追溯PRD入Git改了什么、谁改的、什么时候改的一目了然CMMI3不是要求你写多厚的文档而是要求关键信息不缺失、关键流程不断链。PRD就是这条链上最关键的一环——它把需求管理前几步的成果固化成一份可执行、可验收、可追溯的契约。小微企业把这四篇做到位——CMMI3核心认知、痛点识别、需求管理流程、PRD标准化——轻量CMMI3的地基就打好了。后续的配置管理、质量保证、度量分析都是在这套地基上往上盖楼。