AI 硬件产品需求文档（PRD）怎么写？.docxVIP

AI 硬件产品需求文档（PRD）模板 产品文档（PRD）包含哪些？ 如图，我将产品需求文档（PRD）分为三大类文档。 如果您对技术不是很了解，《硬件需求》和《软件需求》这两个文档可以裁剪掉。但是其他的一定要详细描述清楚。 我们开产品评审会议时，主要讲解《产品功能列表》《业务及功能流程》和《产品功能需求》。 这三个文档详细描述了，我们的产品需要哪些功能、产品涉及的相关业务方和流程、产品具体的功能/性能要求。 啰嗦一句，关于文档命名的事情，我发现很多同事不喜欢将文档命名，找起来好麻烦，也不方便管理。一定要养成规范命名的习惯。 我自己的命名方式：产品需求文档_XX 产品_V1.0.1包含文档属性、产品名称、版本、时间。 文档信息类 文档类别包含《文档信息》《项目规划》《change list》，分别描述项目的归属、整体计划、产品修订信息。 《文档信息》 这个表格表述的是整个项目的概况，方便一目了然的了解整个项目。特别是在公司项目很多的时候，这个概述很重要。 《项目计划》 这个表格表述的是项目预研以及研发设计的整体时间规划，公司项目少的话，可以不需要这个。一般我们做项目管理的时候有一个公司所有项目时间分配的汇总表。 《change list》 产品文档关于产品决策的每次变更均需要详细的记录在案，并发送到业务相关方。防止相关业务方开发出现信息错位，同时保证自己随时查阅相关产品状态。 当然，产品变更项目经理会出具会签的《变更申请表》，但是作为产品需要记录产品完整的研发路径。无论是作为产品回溯还是作为以后的经验参考都具备重要的意义。 产品需求类 《产品信息》 这份文档从全局表述了产品的形态、规格参数、包装等。产品信息全览，方便项目组成员快速了产品信息。 例如：硬件工程师看一眼就是知道，这个产品人机交互层面包含电源开关、什么类型以及几个功能按键、什么类型以及几个指示灯、是否有功能端口、是否有其他交互附件。根据规格参数选择什么样的传感器等元器件。 再例如：ID 工程师一看就明白外观上有哪些组件，以及产品 ID 概念。 所以，这份文档极大的方便项目组成员了解产品整体信息。 《硬件需求》 如果您对硬件不熟悉，可以不用出具这个文档，参与到硬件团队中，慢慢的就能学习到很多东西。待硬件工程师选型完成了，汇总到这个文档上就好。 这个文档的目的是规划产品各功能模块，产品经理在设计产品的时候，可以通过这个预估硬件成本。产品经理虽然出具这个文档，但最终还是要与硬件、系统部门工程师深入沟通最终确定这些关键元器件。 《软件需求》 这份文档是系统及系统应用、算法等软件按照模块的汇总。简明扼要的产品软件需求，并不像功能需求那么详细，做到逻辑性以及无遗漏即可。 《产品功能列表》 这份文档的目的是帮助我们梳理产品功能，与软件需求的区别是这份文档只包含功能，功能底层的支持软件不体现在这儿。 故此，您也可用思维导图来表达。 产品评估的时候会拿出来与研发团队评审，需要全面、无遗漏的描述产品功能需求。 产品测试时，可根据此文档总结开发时产品功能是否有遗漏。 《业务及功能流程图》 业务流程图是表达产品的业务流向。 功能流程图是表达产品功能关系/流向，信息流等。 我喜欢用 Axure 这个软件来做，我觉得很好用。其实用思维导图软件 Xmind 以及 office Visio 都可以。 《产品功能需求》 根据之前我们梳理过的《产品功能列表》《业务及功能流程图》制作《产品功能需求》。 包含功能描述，清晰无歧义的描述功能；功能的前置条件（触发机制）以及输出（例如执行某个动作或功能跳转）；并且详细描述功能的性能要求。 上图举例中，需求描述我做了很多裁剪。 我们在产品设计的时候，一定要反复的逻辑推演，将自己置于产品使用场景中反复推敲，确保功能能真正解决问题。这块很重要，很容易发生功能冲突等状况，所以逻辑思维能力、同理心都很重要。 想想我们自己在使用某个产品过程中，是不是抱怨这是什么傻 X 设计。原因就是，没做好前期设计或者没想到那个使用场景。 我有时候想不清楚的时候，我将这个《产品功能需求》打印出来，然后裁成一个个小纸片贴在墙上，然后用线连接起来，逐步分析。 类似电影上警察分析的那张地图。 在这些产品需求类别的文档中，《产品信息》《产品功能列表》《业务及功能流程图》《产品功能需求》非常重要，不能省略不写。工程师是根据这几份文档作为设计指导文件，不然没法开展工作。 互联网平台类 这类产品文档，网上很多，大家可以多搜索形成自己的方式。 我个人将这类文档做了裁剪，因为智能硬件产品 App 工具属性很重，我觉得相对比较好处理。 下面简单介绍我自己的方法。 《App 功能列表》 因为在做硬件产品的时候，已经将 App 融合进来考虑很久了，所以我直接就上了 App 的功能结构、页面结构、