说到珠三角，有两种不同的观点：有人认为珠三角很关键，能体现产品方案和设计思路；也有人认为珠三角没用，价值不大。笔者认为，应结合公司、业务、产品等进行珠三角定制。最大化它的价值。

一、写作缘由

PRD，原型可以说是产品经理工作中最常见、频率最高的可交付成果。但是在最近和很多同事的交流中发现，很多产品人员和开发人员对需求文档都是一种轻蔑和轻蔑的态度，产品经理对需求文档敷衍了事，甚至连开发都不看一眼。此外，还有一些无处不在的评论鼓吹“一个好的产品经理，肯定和写文档、画原型不一样”，“写文档就是搬砖”，这让珠三角更加尴尬。

然而，事实并非如此。

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

至于团队合作，随着分工越来越细化，员工流动性越来越大，需求文档变成了联系产品、开发、测试和新老员工的沟通工具。

对于像公司或企业这样的抽象实体，需求文档是其业务发展和变化的沉淀.

如上所述，需求文档的价值是存在的，但是我们也应该看到，围绕着目标或第一原则，需求文档可能只是交付产品或用户价值的工具。我们应该真正根据公司、业务、产品的具体情况来定制“需求文档”，而不是机械地直接照搬。

以下是基于我个人不到一年的产品工作和珠三角写作经验。相信随着经验的不断积累，新的认知会不断涌现。到那时，通过比较，我也能感受到自己的成长。我也欢迎大家在这里和我讨论。

00-1010

二、重新定义需求文档

需求文档的用户主要包括产品经理、开发和测试。对于产品经理来说，使用和编写需求文档应该会有所帮助：

细化产品方案输出文本版产品实现方案，帮助整理思路，发现不足，促进沟通进行内外沟通展示。对于开发和测试，需求文档应该帮助他们理解业务、功能和成功标准，以便更好地开发和测试。

因此，编写PRD的过程可以看作是一个整理产品思路、细化产品方案、细化技术方案的迭代过程，最终的PRD可以作为产品的蓝图、实施方案和沟通工具。

1. 面向人群与写作目标

以下总结了几个我认为在珠三角写作中很重要的思维模式：

(1)客观思维

首先，顶层思维应该是“目标思维”。通过思考以下问题找到写作目标：这份文件是给谁的？他们想看什么信息？他们会怎么看？为了更好地帮助读者，我应该写什么形式和内容？

我写作的共同目标可能是这样的：

通过需求文档整理出整个产品设计思路，并简要传达给项目成员。通过需求文档，将产品方案细化为解决方案的文本版本，应该覆盖所有的开发细节，这样开发就可以快速开始，而不需要和我多次沟通确认。需求文档应该有一个好的组织结构，以便将来可以添加新的文档。遵循敏捷和迭代的原则，需求文档也应该是敏捷和迭代的。需求文档应被记录并及时通知变更。(2)基本逻辑思维

文档的每个组成模块都应该有合理的逻辑关系，而不是在文档中无序的展开。

比如，我们可以先描述和演示用户的需求；然后简要描述选择什么样的产品方案或商业模式来解决需求；然后列出实现商业模式需要铺设的产品功能点；此外，通过功能流程图，功能点被进一步细化为页面路径和页面元素。最后，必须有页面元素的详细描述。

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

(3)讲大义。

被语言文字所慑服，作为一种沟通工具，很容易造成歧义，很难准确地把自己的想法和想法传达给别人。要求在文字表达上要力求简洁、清晰、不含糊。试着从读者的角度来审视自己的文本表达。相信你会发现很多问题。

(4)产品思维

我个人认为，PRD的写作过程就是产品思路的梳理和记录。这个产品理念可能没有唯一正确的答案。我个人的想法可以总结如下：

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

(2)由内而外，主要用于现有功能的优化，基本遵循“可用-好用-好用”的迭代原则。

因此，在实际工作中，我的写作思路一般遵循上述原则。对于新功能，我一般按照目标-大纲方案-详细方案来写。对于功能优化，结合现有的使用场景和痛点，提出优化方案。

(5)技术思维

对产品的思考侧重于分析决策，为用户或业务提出解决方案，而技术主要考虑如何实现这个解决方案，以及这个解决方案对现有技术框架的影响有多大。

事实上，一个好的解决方案不仅要考虑用户或企业，还要考虑技术实现。技术方案的实施将决定项目的资源和成本，技术方案的质量将直接决定用户的体验，甚至有时技术实施可以带动业务和用户需求的变化。

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

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

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

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

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

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

在我sldlb的认知中，产品经理应该尽量去定义一套足够详尽的解决方案，而开发人员、设计人员只需根据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协议