产品的prd文档是什么（产品需求文档后）

讲到PRD，有两种不同的意见：有的人认为PRD十分关键，能够体现出产品方案、设计思路；而有的人则认为PRD无用，价值小。对此笔者认为：我们应该结合公司、业务、产品等去自定义PRD，发挥它的最大价值。

一、写作缘由

PRD、原型可以说是产品经理工作中最常见、最高频的交付物了。但是最近与许多同事的交流中却发现，很多产品人员、开发人员都对需求文档抱有一种轻视、鄙夷的态度，产品经理对于需求文档敷衍了事，开发更是看都不看。加之一些不知从何处来的言论鼓吹，“一个好的产品经理绝对不等同于写文档、画原型”“写文档就是搬砖”，PRD更加成为了一个尴尬的存在。

然而事实并非如此。

对于产品经理个人而言，需求文档是产品方案、设计思路、实现思路的综合体现和结果输出，不管是使用可交互原型、手绘原型还是文字描述，产品经理总是需要这样一个载体来表达自己的思维结晶。

对于团队配合而言，随着分工越来越细化以及员工流动性的增加，需求文档转而担负起了联络产品、开发、测试以及新老员工的沟通工具。

对于公司或者业务这个抽象实体而言，需求文档是其业务发展、变革的沉淀……

上面讲到需求文档存在的价值，不过我们也应该看到，围绕着目标或者第一性，需求文档可能只是交付产品或用户价值的工具，我们确实应当结合公司、业务、产品的具体情况去自定义“需求文档”，而不是直接生搬硬套。

下文所述，是基于我个人不到一年的产品工作以及PRD写作经验。我相信随着经验的不断积累，还会不断生发出新的认知来，届时通过比较，我也能感知到自己的成长，在这里也欢迎大家与我共同探讨。

二、重新定义需求文档

1. 面向人群与写作目标

需求文档的使用人群主要包括产品经理、开发、测试。对于产品产品经理而言，使用并撰写需求文档应当可以帮助：

1. 细化产品方案
2. 输出文字版的产品实现方案
3. 帮助整理思路、发现不足、促进沟通
4. 用于对内对外的沟通展示

对于开发和测试而言，需求文档应当可以帮助其了解业务、功能、成功标准，从而更好的进行开发和测试。

因而写作PRD的过程，可以视为一个梳理产品思路、细化产品方案、细化技术方案的迭代的过程，而最终的PRD可以作为产品的蓝图、实施方案以及沟通工具。

2. 写作思维

下面总结了在PRD写作中我认为比较重要的几种思维模型：

（1）目标思维

首先最顶层的思维应当是“目标思维”，通过思考这些问题找到写作目标：这份文档给谁看？他们想看哪些信息？他们会以何种方式看？我应该以什么样的形式、内容来写才能更好的帮助读者？

我写作的常见目标可能是这样的：

1. 通过需求文档梳理整个产品设计思路，并简要的传达给项目成员。
2. 通过需求文档，将产品方案细化为文字版的解决方案，这个文字版方案应当涵盖所有开发细节，以便开发可以快速展开工作而无需多次找我沟通确认。
3. 需求文档应该有良好的组织结构，便于以后加入新的文档。
4. 跟随敏捷与迭代的原则，需求文档也应是敏捷并且不断迭代的。
5. 需求文档应当及时记录和告知变更。

（2）基本的逻辑思维

产品文档的各个组成模块，应当具备合理的逻辑关系，而不是杂乱地铺在文档里。

例如，可以首先描写和论证用户需求；然后简要叙述为了解决需求，选择了怎样的产品方案或业务模型；随后列出为了实现业务模型需要铺设的产品功能点；进一步的，通过功能流程图，将功能点进一步细化为一个个页面路径和页面元素；最后还要有对于页面元素的详细描述。

可以看到，这样的需求文档是逻辑清晰、有说服力的，出现问题也很容易定位到具体环节。

（3）微言大义

对语言文字有所敬畏，语言文字作为沟通工具，是非常容易造成歧义的，要想准确地将自己的思路想法传达给别人是一件非常难的事情。需求文档在文字表达上应该力求简洁、清晰、无歧义，多试着以读者的角度去审视自己的文字表达，相信你会发现很多问题。

（4）产品思维

我个人将PRD的写作过程看作对产品思路的梳理和记录。这个产品思路或许并没有唯一正确答案，我个人的思路可以概括为：

（1）自上而下，基本遵循目标-概要性产品解决方案–详细解决方案（对于常见的2C互联网产品，这个详细解决方案可能包括从功能结构到页面视觉的一系列工作）

（2）由内而外，主要用于对现有功能的优化，基本遵循可用-易用-好用的迭代原则。

因而实际工作中，我的写作思路一般也遵循上述原则，对于新功能通常按照目标-概要方案-详细方案去写；对于功能优化，结合现有使用场景和痛点，去提出优化方案。

（5）技术思维

产品思维比较偏重于分析决策和提出面向用户或商业的解决方案，而技术主要考虑如何去实现这个解决方案，以及这个解决方案对既有技术框架的影响有多大。

实际上，一个好的解决方案绝不仅仅只考虑用户或商业，技术实现也是必须考量的要素。技术将解决方案落实并决定项目的资源和成本，技术方案的好坏也会直接决定用户的使用体验，甚至有些时候技术实现可以驱动商业和用户需求的变革。

产品经理缺失技术思维，就会很容易将自己没完成的任务无意识的甩锅给开发，实际工作中开发经常跑来找产品沟通需求细节也是源于此。

以一个简单的例子来说明：

技术层面，用户在登录注册后，可以本地缓存账号信息，从而下次访问应用时无需手动进行登录操作。如果产品经理不懂这个缓存技术，在PRD中就会缺失相应描述，开发人员无法明确是否要做这样一个自动登录的功能，就只能拍脑袋决定了。

再举一个登录注册相关的例子：

网站登录注册需要考虑是否限制用户多账号登录的问题，网站运行在浏览器上，浏览器在缓存用户信息的时候是按域存储的；如果网站允许多账号登录，在不加以设计的情况下，这些同时登录的账号会出现数据混乱的情况。因而必须在产品设计之初就从需求上定义是否需要多账号登录，进而才能由开发给出一个完善的多账号数据存储或请求方案。

现实工作中，产品经理可能无法达到技术人员的水平，解决之道可以是自己多学习、和技术多去沟通产品方案；还可以通过制定设计&开发规范，让产品、设计、技术可以协同工作(类似于ant design，定义了一套常用的设计开发规范，产品设计和开发都可以基于共同规范去开展，而不用重复造轮子)。

在我最初的认知中，产品经理应该尽量去定义一套足够详尽的解决方案，而开发人员、设计人员只需根据PRD去进行自己的工作。

在对设计、开发有了一定的了解后，我认为，单靠产品经理一人之力去输出详尽的解决方案是不太可能的（除非产品经理既懂得产品设计、又懂得技术、还懂得交互设计和视觉设计等）。一个真正优秀的产品方案应该由产品人员、开发人员、设计人员、测试人员通力合作，这些人员不是上下游关系、规划与执行关系，而是一种能力互补的关系，这些人员的才能共同造就一个优秀的产品。

另一方面，在不断的配合中，产品、设计、开发应该尝试去将常用功能封装成一个设计&开发框架，在以后的工作中可以直接沿用或改动现有框架，提高工作与沟通效率。

三、PRD结构

下面简要介绍我个人常常使用的PRD的基本结构：

1. 需求

也是产品方案要达到的目标，需求可能是用户需求（即以用户价值为导向），也可能是业务需求（即以商业价值为导向），后面的产品方案细节，最终都是为了达到这一目标。

在PRD中阐述项目的目标，有助于激发团队成员的动机，从而在目标上达成一致。

2. 设计模型

面向需求或目标，提出解决方案或设计模型，可以以泳道图、流程图等可视化的方式或者文字表达的方式描述主要的业务逻辑、产品架构。

3. 功能列表

根据设计模型，将用户需求、业务需求转换为大大小小的产品功能模块或非功能性要求，阐述这些模块间的业务关联、数据关联，对于功能进行优先级分析和版本规划。

4. 功能流程

针对每一个功能模块，围绕着功能目标，设计功能流程。如围绕着用户账号登录这一目标，设计登录注册的流程。这里要注意：

根据功能模块的特性，使用不同种类的流程图，比如泳道图、时序图、状态图。

突出主流程、弱化分支流程、以文字表达异常流程，将三者区隔开来。

（产品设计应当优先考虑引导用户走向主流程，次之考虑对于用户的分支行为作出一定约束，最后还要考虑整个环境系统可能出现的异常。对于用户、设计人员、开发人员而言，这三者的作用和优先级都是不同的）。

5. 页面设计与页面元素

页面设计是对功能流程的进一步细化，许多的页面元素串联起来，引导用户走完整个功能流程并达成目标。根据功能流程图，考虑以最少的页面和最清晰有效的页面布局实现功能。

6. 页面详细说明

对于页面之间的逻辑和每一个页面元素进行必要的说明。

页面元素包括信息和控件等，在说明信息时，需要对信息的展示效果、信息来源、信息的计算规则、信息的刷新规则等进行说明；对于控件，以输入性控件为例，对控件类型、控件样式、控件交互、输入限制、输入校验等属性进行说明。

个人觉得，页面详细说明是开发和测试最终要参考的部分，也是产品经理最容易有遗漏的地方，因为这里会涉及很多细节；对于这里的写作也是争议最多的，是否要写得足够详尽？我只能说，对此要具体情况具体分析，如果团队已经有了成熟的配合模式和规范，这里自然可以简化；但是我想每个产品经理都应该具备写一份详尽文档的能力。

那么怎样才能避免遗漏细节呢？

我个人觉得，还是要有技术思维。换位思考如果你是开发，你需要知道哪些必要因素才能开工。

对此，个人认为最快的学习途径不是看别人怎么写需求文档，而是读一些技术的书，真正明白当一个开发在写代码时是在做什么。

以网页表单为例，前端需要通过html和CSS来定义表单的结构和样式，通过javascript执行一些输入限制和校验，通过AJAX和服务端通信，发送POST请求将用户输入的一些字段信息上报；服务端需要编写程序对请求进行处理并在处理完成后发送响应给前端。

因而从前端的角度出发，PRD里应当包含页面控件样式的描述、控件交互的描述、输入限制的描述、数据上报的描述等；从后端的角度出发，PRD里应该包含有数据上报的描述。

7. 全局说明

一些各个页面都有的功能点、交互模式、设计样式，或者一些通用的异常控制，可以放在全局说明里。

四、总结

在PM的日常工作中，对于PRD有了一些认知上的升级，在这里进行了初步总结。主要讲述了：

（1）PRD写作的目的和价值

（2）PRD写作中应该具备的思维模式

（3）PRD的常见结构

此文虽以PRD为主要话题，但实质上重在对产品经理逻辑与理性思维的体察。诚如很多大佬说的，产品经理需要有一秒内变为白痴的能力；但个人认为，除了直觉与感性，良好的逻辑思维与理性亦是产品人必不可少的。

本文由 @lemon 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

,