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

　　本文将产品需求文档的逻辑归纳为：规范层、信息层、表现层三层，并逐一展开分析。与君分享，希望给大家的工作带来一些借鉴。
　　之前我们探讨了产品原型的内容，今天想和大家来聊一聊产品原型的“另一半”：产品需求文档。为什么说产品需求文档是产品原型的“另一半”呢？理由很简单，在产品的整个生命周期中，只要出现产品原型，一定会有需求文档相伴，可谓是夫唱妇随，相伴到永远。虽然他俩是天生的一对，但他俩的关系如何，却往往被产品经理主宰。产品经理做得好，一家人和和美美；做得不好，则很有可能妻离子散。
　　既然产品经理承担着如此重大的责任，那该如何写好产品需求文档呢？有没有规范统一的模板？通过几年的产品工作，我的体会是要写好产品需求文档，必须要弄清楚它背后的逻辑，至于是什么格式，只要能让别人看懂，基本上就可以了。
　　总体而言，我觉得产品需求文档的逻辑可以归纳为三层：规范层、信息层、表现层。接下来，我们就一一进行分析。
　　规范层
　　正如之前说产品原型必须服务于沟通一样，产品需求文档也必须服务于沟通。要做到这一点，我们需要在组织内部形成统一的文档规范。虽然我们说产品需求文档的格式不重要，但在同一组织内，产品需求文档的统一规范却是非常重要的，其最大的价值在于可以有效提高沟通效率。
　　举个很简单的例子，某公司有五位产品经理，如果每个产品经理的产品需求文档都是一种格式，那作为制作、开发、测试人员就必须熟悉五套格式，而且存在无法熟悉的风险。实际协作中，由于文档相互之间存在差异，难免会遗漏一些细节，发现的时候往往已经是测试阶段甚至是验收阶段了。反过来，如果这五位产品经理的产品需求文档，都是基于一种规范撰写的产品需求文档，那相关人员就只需要熟悉一套格式，效率就会大大提高。
　　具体该如何做呢？我觉得可以分三步走：第一步确定文档规范的制定者，由他撰写初版的产品需求文档规范；第二步以初版规范为样本，组织产品、制作、开发、测试等部门讨论，对初版进行修订，形成可执行的规范文档；第三步逐步推行文档规范，搜集问题，优化文档，进行版本管理。
　　信息层
　　有了规范层面的保障，我们就需要考虑信息层的问题了。在这个层面，我们需要解决两个问题：
　　1。如何确保信息的准确性
　　确保信息的准确性，就是要保证到达每个人那里的信息都是准确无误的。要做到这一点，产品经理首先要确保自己撰写的信息是准确并且统一的，其中统一是确保文档中所有涉及到的地方都必须进行了相应的修改，否则很容易产生歧义；其次进行有效的版本管理。关于版本管理，现在已经是非常成熟的管理方法了，有需要的朋友可以参阅相关专题的文章，这里就不做详细描述了。
　　2。如何提升信息的传递效率
　　信息只有真正传递给需要的人后，才会发挥应有的价值。对于如何提升信息的流转效率，我觉得有条件的团队可以使用项目管理工具。例如我们使用Confluence和jira进行项目管理，文档的任何修改，都会以邮件的方式发送给相关的人员，这样就最大限度上保证了信息传递的效率。
　　如果暂时无法使用管理工具的团队，我的建议是在做好版本管理的前提下，充分利用QQ、微信等工具，一般团队都会创建讨论组或群聊，把修改的内容即时发送到群里，也是一种提升信息传递效率的途径。
　　表现层
　　当我们做好了规范层和信息层的工作后，我们再来考虑产品需求文档具体怎么写，就会变得更容易，也更有效率。那一份产品需求文档，具体应该包括哪些内容呢？我觉得至少需要包含以下七个方面的内容。
　　1。用户角色
　　用户角色主要是指产品包含几种角色的用户，如何定义，相应的权限是什么，这些都需要描述清楚。
　　以视频网站为例，用户角色可以分成三大类：视频观看者、视频上传者、网站运营者。针对每一个大类，又可以进行细分，比如视频观看者，又分成游客、注册用户、VIP会员等。
　　在实际文档中，如果用户角色较多，建议可以使用表格的方式来呈现。例如下面的表格样式：
　　2。流程
　　流程主要是要阐述清楚产品的整体流程，一般都是以流程图来呈现。我把这个流程图归纳为三个哲学问题：我从哪里来、我在哪里、我到哪里去，当然也要让别人清晰地知道“我是谁”。
　　3。内容
　　内容主要是指网页中应该包括哪些元素，具体可以从列项、规格、状态三个方面来描述。首先我们可以先列出某个页面或板块都包含哪些内容，例如我们描述一个视频单元时会这样写：
　　视频单元：包含视频缩略图、播放按钮、标题、观看人数。
　　明晰了列项，接下来就要说明相关列项的规格，例如我们在说明搜索框的规格是会这样写：
　　搜索框：搜索框默认显示“请输入关键字搜索”，颜色为灰色；搜索框最多20个字，超出后无法继续输入，若是复制文本，超出部分自动截取；不输入任何内容，点击搜索按钮，则在新页面打开视频搜索页。
　　除了列项和规格，有些元素可能还会有若干个状态，也许描述清楚。是例如用户上传了一个视频，那它的状态就会从编辑状态转变为待审核状态。
　　4。功能
　　功能就是指具体能干什么了。要描述清楚这一部分，同样需要从过程、条件、元素三个方面入手。首先我们要说清楚这个功能是如何实现的；其次要描述清楚在实现这个功能的过程中，会有哪些限制条件，例如视频网站中有些视频资源是会员用户才能看；最后还需要明细功能所附带的元素，例如，用户要删除自己上传的视频，那就需要添加确认信息框，信息框上有哪些按钮，分别有什么作用，文字如何描述，都需要进行说明。
　　5。交互
　　交互主要是描述页面中所有的交互设计是如何实现的，包括用户行为、交互结果两个方面。例如视频上传按钮默认为橙色，鼠标划过时变为橙黄色，鼠标点下时变为橙红色；再或者搜索框默认显示灰色文字“请输入关键词”，获取焦点后，提示文字消失，输入的文字为黑色。
　　6。状态
　　状态主要是指元素状态的变化，这种变化主要来源于两个方面：页面操作、数据变化。页面操作就像我们上面举的例子，用户上传的视频，可以先保存，也可以直接提交审核，那这两种操作所产生的状态是不一样的，就需要列举出来；数据变化除了页面内部的操作引起的变化，还需要考虑其他页面的元素变化，而引起的数据变化，例如个人中心一般都有所看视频的进度，这个进度是根据前台看视频的进度同步更新的，这种变化关系就需要描述清楚。
　　这一块，需要我们在分析页面元素状态时，不仅要考虑页面内操作，还需要考虑与其他页面的相关性。
　　7。数据
　　数据主要是对页面相关的数据的描述，包括来源、规则、提示三部分。首先我们必须要弄清楚，数据是从哪里来的。这对开发人员至关重要，如果没有描述清楚，开发人员很有可能无法开始工作，或者更糟糕的是做完了发现数据来源错了；其次每一项数据的规则是什么，也需要描述清楚，例如注册页面，用户名的规则应该是什么；再次对于相关的提示包括哪些，这个提示可分为成功提示和错误提示。
　　结语
　　与产品原型一样，产品需求文档也是支撑产品经理与团队沟通的重要工具，而如何写好产品需求文档，仅仅了解一份产品需求文档应该包含哪些内容是远远不够的，还需要深刻理解它在团队内部是如何有效流转的。表现形式是逻辑过程的附属品，逻辑过程本身才是产品经理最应该具备的。