产品需求文档的三层逻辑:规范层、信息层、表现层

14 评论 41480 浏览 413 收藏 11 分钟

本文将产品需求文档的逻辑归纳为:规范层、信息层、表现层三层,并逐一展开分析。与君分享,希望给大家的工作带来一些借鉴。

之前我们探讨了产品原型的内容,今天想和大家来聊一聊产品原型的“另一半”:产品需求文档。为什么说产品需求文档是产品原型的“另一半”呢?理由很简单,在产品的整个生命周期中,只要出现产品原型,一定会有需求文档相伴,可谓是夫唱妇随,相伴到永远。虽然他俩是天生的一对,但他俩的关系如何,却往往被产品经理主宰。产品经理做得好,一家人和和美美;做得不好,则很有可能妻离子散。

既然产品经理承担着如此重大的责任,那该如何写好产品需求文档呢?有没有规范统一的模板?通过几年的产品工作,我的体会是要写好产品需求文档,必须要弄清楚它背后的逻辑,至于是什么格式,只要能让别人看懂,基本上就可以了。

总体而言,我觉得产品需求文档的逻辑可以归纳为三层:规范层、信息层、表现层。接下来,我们就一一进行分析。

规范层

正如之前说产品原型必须服务于沟通一样,产品需求文档也必须服务于沟通。要做到这一点,我们需要在组织内部形成统一的文档规范。虽然我们说产品需求文档的格式不重要,但在同一组织内,产品需求文档的统一规范却是非常重要的,其最大的价值在于可以有效提高沟通效率。

举个很简单的例子,某公司有五位产品经理,如果每个产品经理的产品需求文档都是一种格式,那作为制作、开发、测试人员就必须熟悉五套格式,而且存在无法熟悉的风险。实际协作中,由于文档相互之间存在差异,难免会遗漏一些细节,发现的时候往往已经是测试阶段甚至是验收阶段了。反过来,如果这五位产品经理的产品需求文档,都是基于一种规范撰写的产品需求文档,那相关人员就只需要熟悉一套格式,效率就会大大提高。

具体该如何做呢?我觉得可以分三步走:第一步确定文档规范的制定者,由他撰写初版的产品需求文档规范;第二步以初版规范为样本,组织产品、制作、开发、测试等部门讨论,对初版进行修订,形成可执行的规范文档;第三步逐步推行文档规范,搜集问题,优化文档,进行版本管理。

信息层

有了规范层面的保障,我们就需要考虑信息层的问题了。在这个层面,我们需要解决两个问题:

1.如何确保信息的准确性

确保信息的准确性,就是要保证到达每个人那里的信息都是准确无误的。要做到这一点,产品经理首先要确保自己撰写的信息是准确并且统一的,其中统一是确保文档中所有涉及到的地方都必须进行了相应的修改,否则很容易产生歧义;其次进行有效的版本管理。关于版本管理,现在已经是非常成熟的管理方法了,有需要的朋友可以参阅相关专题的文章,这里就不做详细描述了。

2.如何提升信息的传递效率

信息只有真正传递给需要的人后,才会发挥应有的价值。对于如何提升信息的流转效率,我觉得有条件的团队可以使用项目管理工具。例如我们使用Confluence和jira进行项目管理,文档的任何修改,都会以邮件的方式发送给相关的人员,这样就最大限度上保证了信息传递的效率。

如果暂时无法使用管理工具的团队,我的建议是在做好版本管理的前提下,充分利用QQ、微信等工具,一般团队都会创建讨论组或群聊,把修改的内容即时发送到群里,也是一种提升信息传递效率的途径。

表现层

当我们做好了规范层和信息层的工作后,我们再来考虑产品需求文档具体怎么写,就会变得更容易,也更有效率。那一份产品需求文档,具体应该包括哪些内容呢?我觉得至少需要包含以下七个方面的内容。

1.用户角色

用户角色主要是指产品包含几种角色的用户,如何定义,相应的权限是什么,这些都需要描述清楚。

以视频网站为例,用户角色可以分成三大类:视频观看者、视频上传者、网站运营者。针对每一个大类,又可以进行细分,比如视频观看者,又分成游客、注册用户、VIP会员等。

在实际文档中,如果用户角色较多,建议可以使用表格的方式来呈现。例如下面的表格样式:

2.流程

流程主要是要阐述清楚产品的整体流程,一般都是以流程图来呈现。我把这个流程图归纳为三个哲学问题:我从哪里来、我在哪里、我到哪里去,当然也要让别人清晰地知道“我是谁”。

3.内容

内容主要是指网页中应该包括哪些元素,具体可以从列项、规格、状态三个方面来描述。首先我们可以先列出某个页面或板块都包含哪些内容,例如我们描述一个视频单元时会这样写:

视频单元:包含视频缩略图、播放按钮、标题、观看人数。

明晰了列项,接下来就要说明相关列项的规格,例如我们在说明搜索框的规格是会这样写:

搜索框:搜索框默认显示“请输入关键字搜索”,颜色为灰色;搜索框最多20个字,超出后无法继续输入,若是复制文本,超出部分自动截取;不输入任何内容,点击搜索按钮,则在新页面打开视频搜索页。

除了列项和规格,有些元素可能还会有若干个状态,也许描述清楚。是例如用户上传了一个视频,那它的状态就会从编辑状态转变为待审核状态。

4.功能

功能就是指具体能干什么了。要描述清楚这一部分,同样需要从过程、条件、元素三个方面入手。首先我们要说清楚这个功能是如何实现的;其次要描述清楚在实现这个功能的过程中,会有哪些限制条件,例如视频网站中有些视频资源是会员用户才能看;最后还需要明细功能所附带的元素,例如,用户要删除自己上传的视频,那就需要添加确认信息框,信息框上有哪些按钮,分别有什么作用,文字如何描述,都需要进行说明。

5.交互

交互主要是描述页面中所有的交互设计是如何实现的,包括用户行为、交互结果两个方面。例如视频上传按钮默认为橙色,鼠标划过时变为橙黄色,鼠标点下时变为橙红色;再或者搜索框默认显示灰色文字“请输入关键词”,获取焦点后,提示文字消失,输入的文字为黑色。

6.状态

状态主要是指元素状态的变化,这种变化主要来源于两个方面:页面操作、数据变化。页面操作就像我们上面举的例子,用户上传的视频,可以先保存,也可以直接提交审核,那这两种操作所产生的状态是不一样的,就需要列举出来;数据变化除了页面内部的操作引起的变化,还需要考虑其他页面的元素变化,而引起的数据变化,例如个人中心一般都有所看视频的进度,这个进度是根据前台看视频的进度同步更新的,这种变化关系就需要描述清楚。

这一块,需要我们在分析页面元素状态时,不仅要考虑页面内操作,还需要考虑与其他页面的相关性。

7.数据

数据主要是对页面相关的数据的描述,包括来源、规则、提示三部分。首先我们必须要弄清楚,数据是从哪里来的。这对开发人员至关重要,如果没有描述清楚,开发人员很有可能无法开始工作,或者更糟糕的是做完了发现数据来源错了;其次每一项数据的规则是什么,也需要描述清楚,例如注册页面,用户名的规则应该是什么;再次对于相关的提示包括哪些,这个提示可分为成功提示和错误提示。

结语

与产品原型一样,产品需求文档也是支撑产品经理与团队沟通的重要工具,而如何写好产品需求文档,仅仅了解一份产品需求文档应该包含哪些内容是远远不够的,还需要深刻理解它在团队内部是如何有效流转的。表现形式是逻辑过程的附属品,逻辑过程本身才是产品经理最应该具备的。

 

本文由 @E木笔记 原创发布于人人都是产品经理。未经许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 很好,可不可以给一篇完整的文档学习

    来自香港 回复
  2. 帮助很大,感谢分享

    来自上海 回复
  3. 作者辛苦啦,收获良多!!!

    来自江苏 回复
  4. 产品小白,表示对于表现层的3、4点提到的,内容(列项、规格、状态)和功能(过程、条件、元素),理解的比较差,不能更好地代入使用情景中。希望有相关的文章有这方面的解释 😯

    来自广东 回复
  5. 期待更好的文章

    来自北京 回复
  6. 😡 希望看到比较完整的文档……零零散散的感觉

    来自江苏 回复
    1. 这篇文章理论的部分更多一些

      来自北京 回复
    2. 恩恩,想看实践内容,会出吗 😳

      来自江苏 回复
    3. 这个可以有 😳 不过需要策划一年,内容单薄都通不过审核 ❗

      来自北京 回复
    4. 我是想写策划一下的 😥

      来自北京 回复
    5. 😥 加油

      来自江苏 回复
    6. 加油

      来自北京 回复
  7. 赞 🙄

    来自陕西 回复