关于产品需求文档（PRD），我在转行初期也经历过一段纠结光阴。不知道怎么写比较好，也曾在格式、文档软件这些表面的东西上纠结。
经由几个月与研发磨合，终于明白，保持一个朴素的目标清晰的传达产品观点、产品需求就好。
以是，我们用 word、Excel 或者咱们企业内部的协作软件都可以。
我个人喜好用 Excel ，一个 Excel 文件包含多个事情簿，这样方便管理/查看。由于研发工程师、市场、运营等部门他们都会用这个软件。
当然也可以用其他软件，比如 Axure 等，文件分享未便利其他部门打开文件；像 Axure 可以分享链接，但是未便利保存以及打开速率较慢或者有些浏览器根本就打不开。
如果您公司有协同软件那挺好，直接可以在上面编辑、权限管理等；如果没有协同软件，我们作为产品人须要考虑所有利用者的触点，方便团队所有人利用。
以上，只是想说工具不主要，主要的是准确的传达产品需求。
产品文档（PRD）包含哪些？
如图，我将产品需求文档（PRD）分为三大类文档。
如果您对技能不是很理解，《硬件需求》和《软件需求》这两个文档可以裁剪掉。但是其他的一定要详细描述清楚。
我们开产品评审会议时，紧张讲解《产品功能列表》《业务及功能流程》和《产品功能需求》。
这三个文档详细描述了，我们的产品须要哪些功能、产品涉及的干系业务方和流程、产品详细的功能/性能哀求。
啰嗦一句，关于文档命名的事情，我创造很多同事不喜好将文档命名，找起来好麻烦，也未便利管理。一定要养成规范命名的习气。
我自己的命名办法：产品需求文档_XX 产品_V1.0.1_20191210，包含文档属性、产品名称、版本、韶光。
文档信息类
文档种别包含《文档信息》《项目方案》《change list》，分别描述项目的归属、整体操持、产品修订信息。
《文档信息》
这个表格表述的是全体项目的概况，方便一览无余的理解全体项目。特殊是在公司项目很多的时候，这个概述很主要。
《项目操持》
这个表格表述的是项目预研以及研发设计的整体韶光方案，公司项目少的话，可以不须要这个。一样平常我们做项目管理的时候有一个公司所有项目韶光分配的汇总表。
《change list》
产品文档关于产品决策的每次变更均须要详细的记录在案，并发送到业务干系方。防止干系业务方开拓涌现信息错位，同时担保自己随时查阅干系产品状态。
当然，产品变更项目经理会出具会签的《变更申请表》，但是作为产品须要记录产品完全的研发路径。无论是作为产品回溯还是作为往后的履历参考都具备主要的意义。
产品需求类《产品信息》
这份文档从全局表述了产品的形态、规格参数、包装等。产品信息全览，方便项目组成员快速了产品信息。
例如：硬件工程师看一眼便是知道，这个产品人机交互层面包含电源开关、什么类型以及几个功能按键、什么类型以及几个指示灯、是否有功能端口、是否有其他交互附件。根据规格参数选择什么样的传感器等元器件。
再例如：ID 工程师一看就明白外不雅观上有哪些组件，以及产品 ID 观点。
以是，这份文档极大的方便项目组成员理解产品整体信息。
《硬件需求》
如果您对硬件不熟习，可以不用出具这个文档，参与到硬件团队中，逐步的就能学习到很多东西。待硬件工程师选型完成了，汇总到这个文档上就好。
这个文档的目的是方案产品各功能模块，产品经理在设计产品的时候，可以通过这个预估硬件本钱。产品经理虽然出具这个文档，但终极还是要与硬件、系统部门工程师深入沟通终极确定这些关键元器件。
《软件需求》
这份文档是系统及系统运用、算法等软件按照模块的汇总。简明扼要的产品软件需求，并不像功能需求那么详细，做到逻辑性以及无遗漏即可。
《产品功能列表》
这份文档的目的是帮助我们梳理产品功能，与软件需求的差异是这份文档只包含功能，功能底层的支持软件不表示在这儿。
故此，您也可用思维导图来表达。
产品评估的时候会拿出来与研发团队评审，须要全面、无遗漏的描述产品功能需求。
产品测试时，可根据此文档总结开拓时产品功能是否有遗漏。
《业务及功能流程图》
业务流程图是表达产品的业务流向。
功能流程图是表达产品功能关系/流向，信息流等。
我喜好用 Axure 这个软件来做，我以为很好用。其实用思维导图软件 Xmind 以及 office Visio 都可以。
《产品功能需求》
根据之前我们梳理过的《产品功能列表》《业务及功能流程图》制作《产品功能需求》。
包含功能描述，清晰无歧义的描述功能；功能的前置条件（触发机制）以及输出（例如实行某个动作或功能跳转）；并且详细描述功能的性能哀求。
上图举例中，需求描述我做了很多裁剪。
我们在产品设计的时候，一定要反复的逻辑推演，将自己置于产品利用场景中反复考虑，确保功能能真正办理问题。这块很主要，很随意马虎发生功能冲突等状况，以是逻辑思维能力、同理心都很主要。
想想我们自己在利用某个产品过程中，是不是抱怨这是什么傻 X 设计。缘故原由便是，没做好前期设计或者没想到那个利用场景。
我有时候想不清楚的时候，我将这个《产品功能需求》打印出来，然后裁成一个个小纸片贴在墙上，然后用线连接起来，逐步剖析。
类似电影上警察剖析的那张舆图。
在这些产品需求类别的文档中，《产品信息》《产品功能列表》《业务及功能流程图》《产品功能需求》非常主要，不能省略不写。工程师是根据这几份文档作为设计辅导文件，不然没法开展事情。
互联网平台类
这类产品文档，网上很多，大家可以多搜索形本钱身的办法。
我个人将这类文档做了裁剪，由于智能硬件产品 App 工具属性很重，我以为相比拟较好处理。
下面大略先容我自己的方法。
《App 功能列表》
由于在做硬件产品的时候，已经将 App 领悟进来考虑良久了，以是我直接就上了 App 的功能构造、页面构造、信息构造等，然后用原型图做补充。
《云平台》
这个须要我们根据产品属性来考虑，比如云端须要转发、云储存、音视频通讯、设备管理等功能需求；并且须要我们具备一点儿技能知识。不然不知道云端详细该怎么处理。
如果想学习这块儿知识，从我们的后台管理须要哪些功能入手进行反推，可能学习起来随意马虎点。
小结
产品需求文档（PRD）格式可以千变万化，唯一不变的是将产品目标清晰的传达给项目组的的每一位成员。
作为产品经理设计产品的时候，用构造化思维将产品拆解成各个模块，然后用逻辑思维去编织关系。
例如，我们在剖析产品需求的时候，通过思维导图逐步的罗列功能，然后根据功能需求反推硬件需求以及 ID 上有什么交互组件。
一步步从上到下，从整体到局部，再深入细化，末了收敛验证。
作者：Arvinzhou，微旗子暗记：zf519678391；"大众年夜众号：AI 硬件产品官（ID：AIPM001）欢迎关注我，期待与您互换
本文由 @AI 产品不雅观 原创发布于大家都是产品经理，未经容许，禁止转载
题图来自 Unsplash，基于 CC0 协议