0直播比分网·AI 硬件产品需求文档(PRD)怎么写?

2020-01-11 13:55:52 阅读量:4608

0直播比分网·AI 硬件产品需求文档(PRD)怎么写?

0直播比分网,prd你可能写过很多,那么,针对ai硬件产品的prd有什么不一样吗?

关于产品需求文档(prd),我在转行初期也经历过一段纠结时光。不知道怎么写比较好,也曾在格式、文档软件这些表面的东西上纠结。

经过几个月与研发磨合,终于明白,保持一个朴素的目标清晰的传达产品概念、产品需求就好。

所以,我们用 word、excel 或者咱们企业内部的协作软件都可以。

我个人喜欢用 excel ,一个 excel 文件包含多个工作簿,这样方便管理/查看。因为研发工程师、市场、运营等部门他们都会用这个软件。

当然也可以用其他软件,比如 axure 等,文件分享不方便其他部门打开文件;像 axure 可以分享链接,但是不方便保存以及打开速度较慢或者有些浏览器根本就打不开。

如果您公司有协同软件那挺好,直接可以在上面编辑、权限管理等;如果没有协同软件,我们作为产品人需要考虑所有使用者的触点,方便团队所有人使用。

以上,只是想说工具不重要,重要的是准确的传达产品需求。

如图,我将产品需求文档(prd)分为三大类文档。

如果您对技术不是很了解,《硬件需求》和《软件需求》这两个文档可以裁剪掉。但是其他的一定要详细描述清楚。

我们开产品评审会议时,主要讲解《产品功能列表》《业务及功能流程》和《产品功能需求》。

这三个文档详细描述了,我们的产品需要哪些功能、产品涉及的相关业务方和流程、产品具体的功能/性能要求。

啰嗦一句,关于文档命名的事情,我发现很多同事不喜欢将文档命名,找起来好麻烦,也不方便管理。一定要养成规范命名的习惯。

我自己的命名方式:产品需求文档_xx 产品_v1.0.1_20191210,包含文档属性、产品名称、版本、时间。

文档类别包含《文档信息》《项目规划》《change list》,分别描述项目的归属、整体计划、产品修订信息。

这个表格表述的是整个项目的概况,方便一目了然的了解整个项目。特别是在公司项目很多的时候,这个概述很重要。

这个表格表述的是项目预研以及研发设计的整体时间规划,公司项目少的话,可以不需要这个。一般我们做项目管理的时候有一个公司所有项目时间分配的汇总表。

产品文档关于产品决策的每次变更均需要详细的记录在案,并发送到业务相关方。防止相关业务方开发出现信息错位,同时保证自己随时查阅相关产品状态。

当然,产品变更项目经理会出具会签的《变更申请表》,但是作为产品需要记录产品完整的研发路径。无论是作为产品回溯还是作为以后的经验参考都具备重要的意义。

这份文档从全局表述了产品的形态、规格参数、包装等。产品信息全览,方便项目组成员快速了产品信息。

例如:硬件工程师看一眼就是知道,这个产品人机交互层面包含电源开关、什么类型以及几个功能按键、什么类型以及几个指示灯、是否有功能端口、是否有其他交互附件。根据规格参数选择什么样的传感器等元器件。

再例如:id 工程师一看就明白外观上有哪些组件,以及产品 id 概念。

所以,这份文档极大的方便项目组成员了解产品整体信息。

如果您对硬件不熟悉,可以不用出具这个文档,参与到硬件团队中,慢慢的就能学习到很多东西。待硬件工程师选型完成了,汇总到这个文档上就好。

这个文档的目的是规划产品各功能模块,产品经理在设计产品的时候,可以通过这个预估硬件成本。产品经理虽然出具这个文档,但最终还是要与硬件、系统部门工程师深入沟通最终确定这些关键元器件。

这份文档是系统及系统应用、算法等软件按照模块的汇总。简明扼要的产品软件需求,并不像功能需求那么详细,做到逻辑性以及无遗漏即可。

这份文档的目的是帮助我们梳理产品功能,与软件需求的区别是这份文档只包含功能,功能底层的支持软件不体现在这儿。

故此,您也可用思维导图来表达。

产品评估的时候会拿出来与研发团队评审,需要全面、无遗漏的描述产品功能需求。

产品测试时,可根据此文档总结开发时产品功能是否有遗漏。

业务流程图是表达产品的业务流向。

功能流程图是表达产品功能关系/流向,信息流等。

我喜欢用 axure 这个软件来做,我觉得很好用。其实用思维导图软件 xmind 以及 office visio 都可以。

根据之前我们梳理过的《产品功能列表》《业务及功能流程图》制作《产品功能需求》。

包含功能描述,清晰无歧义的描述功能;功能的前置条件(触发机制)以及输出(例如执行某个动作或功能跳转);并且详细描述功能的性能要求。

上图举例中,需求描述我做了很多裁剪。

我们在产品设计的时候,一定要反复的逻辑推演,将自己置于产品使用场景中反复推敲,确保功能能真正解决问题。这块很重要,很容易发生功能冲突等状况,所以逻辑思维能力、同理心都很重要。

想想我们自己在使用某个产品过程中,是不是抱怨这是什么傻 x 设计。原因就是,没做好前期设计或者没想到那个使用场景。

我有时候想不清楚的时候,我将这个《产品功能需求》打印出来,然后裁成一个个小纸片贴在墙上,然后用线连接起来,逐步分析。

类似电影上警察分析的那张地图。

在这些产品需求类别的文档中,《产品信息》《产品功能列表》《业务及功能流程图》《产品功能需求》非常重要,不能省略不写。工程师是根据这几份文档作为设计指导文件,不然没法开展工作。

这类产品文档,网上很多,大家可以多搜索形成自己的方式。

我个人将这类文档做了裁剪,因为智能硬件产品 app 工具属性很重,我觉得相对比较好处理。

下面简单介绍我自己的方法。

因为在做硬件产品的时候,已经将 app 融合进来考虑很久了,所以我直接就上了 app 的功能结构、页面结构、信息结构等,然后用原型图做补充。

这个需要我们根据产品属性来考虑,比如云端需要消息转发、云储存、音视频通讯、设备管理等功能需求;并且需要我们具备一点儿技术知识。不然不知道云端具体该怎么处理。

如果想学习这块儿知识,从我们的后台管理需要哪些功能入手进行反推,可能学习起来容易点。

产品需求文档(prd)格式可以千变万化,唯一不变的是将产品目标清晰的传达给项目组的的每一位成员。

作为产品经理设计产品的时候,用结构化思维将产品拆解成各个模块,然后用逻辑思维去编织关系。

例如,我们在分析产品需求的时候,通过思维导图慢慢的罗列功能,然后根据功能需求反推硬件需求以及 id 上有什么交互组件。

一步步从上到下,从整体到局部,再深入细化,最后收敛验证。

作者:arvinzhou,微信号:zf519678391;公众号:ai 硬件产品官(id:aipm001)欢迎关注我,期待与您交流

本文由 @ai 产品观 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 unsplash,基于 cc0 协议