三个步骤，教你写出高质量的硬件产品需求文档
纵观整个硬件产品的开发过程，核心问题其实只有三个：
- 满足客户需求；
- 提供具有竞争力的解决方案；
- 降低和控制风险。
产品经理要提供有竞争力的解决方案，就必须创新，去做别人没有做过的事，去突破认知边界并探索未知。由于创新的高度不确定性，产品经理永远无法看清每一件事，也无法预先得到所有答案，导致新产品开发过程中存在巨大风险。
根据美国产品开发管理协会PDMA的统计，每年上市的新产品中，有超过75%的新产品是失败的。如果再加上在企业内部就已经失败的新产品数量，比例将高达95%。
说到新产品失败，我们自然而然会想到中小企业，它们普遍存在资源短缺、品牌乏力、研发不强等问题，新产品失败的风险自然比较高。
然而，事实上，大企业的新产品失败也屡见不鲜。比如，谷歌的智能眼镜、亚马逊的手机、百度的渡鸦音箱，都是全球知名的新产品失败案例。
高质量的产品需求文档，是硬件产品成功的关键
产品需求文档 (PRD)，英文名是“Product Requirement Document”，是硬件产品由概念阶段进入设计阶段的第一个重要文档，其作用是将客户需求转化成开发团队能够理解的产品功能、性能、指标和参数，将前期市场调研和需求洞察所发现的市场机会进行锁定，落地到具体的产品定义。
产品需求文档通常由产品经理制定，由开发团队参与并提供输入，是综合了客户需求、业务需求、市场竞争、国家标准、行业标准、供应链能力和企业最佳实践，所形成的一份开发文档，是后续开展产品设计、测试验证、物料采购、生产制造、订单交付等活动的重要依据。产品需求文档质量的好坏，直接影响硬件产品开发能否顺利完成，并成功上市。
高质量的硬件产品需求文档的制定过程，通常需要经过三个关键步骤：
- 明确客户需求；
- 将客户需求转化为产品需求；
- 产品需求评审。
步骤一：明确客户需求
无需求不产品，产品始于客户需求，终于客户满意。
关于硬件产品需求的来源，请阅读我的文章：无需求不产品，产品需求从哪里来
在制定产品需求文档前，首先必须清楚地了解产品的预期用途，产品需要做什么，谁将使用它，需要如何使用，需要在什么环境条件下使用，以及目标市场由于法规、语言和消费者行为不同对产品的不同需求等等。
优秀的产品经理，不仅仅关注终端用户的需求，还会关注整个产品生命周期中与产品产生接触的所有利益相关方的需求，包括公司老板、开发团队、供应商、仓储运输、销售代理、售后维修等等，他们都会对产品有自己的利益诉求。
所有的利益相关方一起，就构成了完整的客户地图；所有利益相关方的诉求一起，就形成了完整的客户需求。
步骤二：将客户需求转化为产品需求
客户需求明确后，下一步就是将这些客户需求转化为产品需求。这是一个对客户需求进行分析和筛选的过程，通常需要综合考虑客户需求、业务需求、产品战略和市场竞争，对各种需求进行优先级排序。
那些被选择在这个产品上实现的需求，就是当前的产品需求。产品经理需要将这些产品需求翻译和转化成产品团队容易理解的产品功能、性能、指标和参数等等。
通常，硬件产品需求包括如下内容：
1. 物理特性
- 产品由哪些零部件或模块组成，用什么传感器、什么芯片、什么电池、什么外部接口，它们之间是怎么连接、交互和工作的。
- 产品的外观、风格、尺寸、重量、材质、颜色、表面处理等有什么要求。
- 产品的外观设计有没有创新点，使用的材料和工艺有没有新突破？
2. 功能要求
- 产品为客户提供什么功能，其中哪些是核心功能，哪些是辅助功能；哪些是使用功能，哪些是美观功能。
- 这些功能是如何开始和停止的，工作逻辑和流程是什么，逻辑状态有哪些变化，使用条件和环境是什么？
- 除了基本功能外，有哪些功能是竞争对手不具备的，有哪些功能是优于竞争对手的？有没有超出用户期待的创新功能？
3. 性能要求
- 产品完成既定功能需要达到什么程度，需要满足什么性能参数或技术指标？
- 产品的易用性、美观性、安全性、可靠性、可维护性、经济性有什么要求，怎么评价和衡量？
- 产品的设计寿命是多长，保质期是多久？
- 有没有哪些性能指标优于竞争对手，需要在产品开发过程中重点关注和实现？
4. 交互要求
- 用户如何与产品交互，是通过按键交互、还是语音交互、或者视觉交互？
- 用户界面上有什么，需要采集、传递、显示什么信息和数据？
- 信息和数据的采集、存储、处理和显示，在速度、数量、质量、安全方面有什么要求？
- 访问和控制权限怎么设置？
5. 环境条件
- 产品将在什么环境条件下使用？
- 正常的使用温度、湿度、海拔高度是什么？
- 正常的运输、存储和安装条件是什么？
- 是在室内使用、还是在室外使用？
- 防水、防尘、耐候性有什么要求？
- 耐冲击、振动、跌落有什么要求？
- 抗电磁干扰、通信方面有什么要求？
6. 标准和测试要求
- 产品需要遵守哪些法规和标准，需要获得哪些认证证书？
- 需要进行哪些测试，测试要求是什么，验收标准是什么？
- 产品的功能、性能怎么验证？
- 可靠性、安全性怎么验证？
- 老化测试、寿命验证怎么做？
- 产品有哪些品质关键点，需要在产品开发过程中重点关注和实现？
7. 生产制造要求
- 产品的哪些零部件和模块需要外购，验收标准是什么？
- 产能方面有什么要求？
- 关键元器件的供货，有没有备用供应商？
- 有没有卡脖子的生产技术和设备？
8. 包装和运输要求
- 产品需要如何运输和存储？包装和运输的测试要求是什么？
- 产品有没有包含诸如锂电池、化学品之类的危险品，需要进行运输安全鉴定或者运输防护？
- 产品需要哪些标签、警告和认证标志？
- 需要哪些用户文档、使用说明书、安装指南等。
步骤三：产品需求评审
将客户需求转化成产品需求后，就可以组织团队对产品需求进行评审。评审通过后，就可以将产品需求确定下来，形成产品需求文档。
一般的说，需求评审需要对需求的如下特性进行评估：
1. 明确性
需求应该简洁、精确、易于理解，且只有一种解读方式。需求不应该含糊不清、或过于笼统，以致出现多重解读、甚至不正确的解读。那些大量使用模糊性形容词的需求，比如用户友好、高效、及时、容易、可靠、尽量等等，都不是好的需求定义，需要进行量化。
比如：
- 不好的需求：正常工作时，空气净化器的噪音应该尽量小，以免影响用户体验。
- 好的需求：正常工作时，空气净化器的噪音必须符合《GB/T 18801-2015空气净化器》的要求，目标争取控制在55dB以内，优于竞争对手的60dB。
2. 正确性
必须准确捕捉、深刻洞察客户和关键利益相关方的需求和期望，并将需求洞察准确的转化成硬件产品的功能、特性，以及性能指标。产品需求的确定是一个反复的过程，需要通过与客户和关键利益相关方反复讨论、假设和验证，确保需求的正确性。
比如：
- 不好的需求：一匹更快的马。
- 好的需求：福特汽车。
3. 完整性
需求必须陈述完整、没有遗漏，以免导致误解或不理解。当一项需求没有明确适用条件时，常常会出现完整性问题。
比如：
- 不好的需求：台灯光源中心的发光照度必须大于1500lx；
- 好的需求：将台灯以正常工作位置放置在水平桌面上，投射在水平桌面上的、光源中心的发光照度必须大于1500lx。
4. 可验证性
所有的产品需求都必须通过客观的分析、检查、测试进行验证，并且能够制定相应的测试计划和验收标准。那些当前无法进行验证、或者验证成本超出项目预算范围的需求，当前都不是好需求。
如果无法验证的需求是个性需求、或短期需求，建议取消该项需求。如果无法验证的需求，是未来看好的长期需求，建议纳入下一代的产品规划中。
5. 定义“是什么”，而不是“如何做”
产品需求应该描述用户和利益相关方的需要，将产品必须做什么、或者具备什么特性，描述清楚即可。切不可过多关注如何实现需求，过多描述具体解决方案。
这样不仅剥夺了开发人员选择最佳解决方案的自由，而且还可能因为技术背景的欠缺导致解决方案不能充分满足客户需求。
比如：
- 不好的需求：产品有一个红外传感器，能够探测当前环境是否有人出入。
- 好的需求：产品能够探测当前环境是否有人出入。
6. 一致性
产品需求与任何其它需求都不冲突，且该需求的描述和术语，在整个产品开发过程中、以及产品开发各个阶段的文档中，都是一致的。
当一项需求的实现，禁止了另一项需求的实现，两项需求不能同时存在时，就会出现需求冲突和不一致。
对这种相互冲突或不一致的需求，需要进行综合权衡，根据优先级重新定义。
比如：
可穿戴电子产品总是希望功能丰富、轻巧、电池使用时间长，而这三项需求是互相冲突的：
- 功能丰富往往会消耗电力，需要更大、更重的电池，产品体积和重量都会相应加大；
- 轻巧则要求产品功能尽量少、使用更小更轻的电池；
- 而电池则由于技术限制，能量密度有限，必须加大体积和重量才能提供更多电力，才能提供更长的使用时间。
产品经理必须在相互冲突的需求中找到平衡点，将要求明确在产品需求文档中。
7. 可追溯性
每项需求都应该被记录和唯一标识，每次需求变更都需要进行评审和记录，以便在整个产品生命周期中对需求进行追踪和管理。
作者
邓小亮，微信公众号：产品人生。工学硕士，资深产品人，近二十年产品开发及管理经验，
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
