PRD需求文档是（Product Requirement Document的缩写）它是向研发部门说明产品的具体功能和性能指标的说明性文档。主要用于产品设计和开发使用，因此阅读这份文档的人群绝大多数是设计与技术人员。但在实际工作中，很多产品经理都一昧追求所谓标准的需求文档，不去思考为什么这样写，写这些的意义是什么。本文作者从需求文档的目的出发，对其底层逻辑进行了深入分析探讨，希望能够给你带来一定的启发。
01 产品经理的事儿，怎能算抄
年前写了《需求文档：没有标准、只有沟通》这片关于需求文档的内容，但是说实话更多的是感受而非思考，这次主要是学习底层逻辑，通过底层逻辑真正的思考需求文档这东西；
需求文档是我们工作中接触最多，写的最多，花样最多的文档，没有之一。
为什么说没有之一，首先说说他的展现形态。有ppt版、word版（文档）、excel版、axuer版、墨刀版、幕布版等丰富的展现形式。其次内容上需求文档还要分c端、b端、g端，最后还有可能根据交付人不同而进行不同的调整。所以说需求文档是写的最多，花样最多的文档。
所以就在这样的前提下，写需求文档似乎就成了许多产品经理们老大难的问题。独自写需求文档时发现不了问题，一旦遇到要与其他人协同，需要交付给他们需求文档，这时心态立马就到“爆炸边缘”了。
各种问题都涌现，我的结构对不对？该这样写吗？需求文档该如何写？等等问题就出来了。
在这里插一句表扬，表扬咱们产品经理的优点，就是不懂就百度。所以每当大家遇见困难，都能自觉带着各自的疑问去百度，寻找解决方案。但我们又常因为百度出五花八门的答案，又一脸懵逼，最后只能懵懵逼逼的跟着这些“答案”抄“作业”把需求文档写完。
最后本以为写完就ok了，又发现这次写的需求文档又和上次的不一样。emmm….都是我写的为什么不一样？我是不是我查的姿势没对啊。
面对这样的情况我们只能是越查越头疼，于是乎，算了直接找个模版或者是别人的需求文档套一下，不一样就不一样吧。至此，我们走上了模版流产品经理，在这个流派中我们原则是，遇事不决，模版库学，模版不够，百度来凑。
我只想说，这样不对（很有天赋），这样是学不到东西的（你已经入门了）。哈哈，其实产品经理的职责就有解决问题，如果你能用这些方式解决了问题，这就是一个好方法，这是不容置疑的事。但是我们需要通过表层看他们的底层逻辑才行，这样我们才能升级。
02 透过需求文档的表层看他的底层
在大部分咱们搜索需求文档时，咱们得到的答案一般如下：
- 传达产品开发需求（我不管，我就是要，按照我的逻辑可以搞定。）
- 保证各部门沟通有理有据（这是谁的锅，别乱丢）
- 产品质量控制有具体标准（小老弟你看，你当初自己确认没问题，你现在…..）
- 便于交接工作（来，老弟我走后，这口锅你要拿稳了）
- 等等（产品经理在外，要学会保护自己…）
这些内容其实我们只需要简单的搜一搜就都知道了。但却存在一个致命问题，那就是每次借鉴完毕后，过段时间就忘了，又不知道该如何学，又需要重新打开百度或是自己的模版库去借鉴。长此以往，对于我们来说，我们确实收获了快速解决问题的能力，但是却丢失了产品经理最重要的东西，探索，挖掘问题的思维和能力。不说本末倒置，但确实对我们不利。
因此，我们需要学会在现有答案中去挖掘答案深层次的底层逻辑，在了解事物底层逻辑之后，就会发现事物的变化都遵循着底层逻辑，例如：能量守恒，万有引力。面对底层逻辑，我们理解起来会存在一定的困难，但底层逻辑就好比一个公司的愿景，它将是这个公司前进方向和价值体现，只有我们需要不停的逼迫自己去思考，不停的杠自己，最终提炼出它的底层逻辑，那时咱们将会通向罗马。
用树来比喻，我们直视树时，眼里多数只关注这树的树叶，当我们刻意观察时，能看见树的树枝。如果我们聚焦目光再次观察，咱们会想到它的树干。到这里时大部分人就停下思考，说出树干上长树枝，树枝上长树叶，所以树干是影响树生在的原因。
但是我们都知道这不是真正准确的事实，树还有树根，我们还需要用工具挖开脚下的泥土，发现这棵树的树根，在才是真正的底层。
为什么树根是底层？，而树干不是？树干坏死了这个树也不没了吗？这里会忽视一个问题，树干枯萎了，不代表这个树没了，只要树根健全，那么这这颗树的树干就算枯萎了，也会枯树发芽的情况。如果树根坏死了，那么这颗树再怎么的高大，健壮，对于这颗树来说死亡是一定的事。
所以观察一棵树不要光看“树叶”、“树枝”、“树干”，我们还要去挖掘它的“树根”来看。
03 解决方案是客观存在的，不要随意主观使用
事物的发展是非线性的，都会经历一个个起伏，但事物发展也都遵循它的底层逻辑。就像一个树，就算这颗树长得如何奇怪，但树一定是向上生长的。如果你要质疑，说有些树是斜着或是横着生长的。我只想说，那是因为你看待这颗树的角度不对，如果你关注的是它离开地面的位置，就会发现他们始终是向上生长的。
在很多写需求文档相关内容的文章中，多数文章都会提及让大家按照文章中的需求文档标准来写。让大家误以为跟着文章中的规范和标准来就没有问题，随即大家也就根据文章中的需求文档规范和标准来依葫芦画瓢了。至于为什么这样写？这样写的用处是什么？等问题就不去考虑，潜意识认为文章里的标准就是标准，跟着写就对了。
但是这样完全是误会大部分作者的想法，这类作者更多是想体现他们写需求文档的思路，希望大家可以相互探讨，寻求进步。而不是直接炒一炒就ok 的事情。
比如下面我提供的这个需求文档规范：
- 使用说明
- 修订记录
- 版本记录
- 版本说明
- 全局规范
- 功能列表
- 角色列表
- 权限列表
- 框架图
- 流程图
- 原型图
- 非功能需求
- 人员安排
- 特别说明
大家觉得如何？看着在这份需求文档规范，可能会有人觉得很细致，很好，想要直接使用，问有没有模版等。
但是我在这里提醒大家需要注意，有经验的产品经理是不会太过随意的使用其他人的需求文档。而是根据公司、项目、人员等配置来灵活的调整需求模块。
直接使用会存在很多弊端，如整个项目就三个人，还需要使用说明吗？这个产品就做个计算功能，以后再也不迭代的，需要修订、版本记录吗？这产品就一个页面，那需要角色和权限列表吗？
带入这样的场景会发现，似乎需求文档中很多模块都不需要。但是有时候就是只有2个人的产品也还需要复杂的需求文档，那么到底什么时候用什么样的需求文档到底依据的是什么？我想说是底层逻辑。
04 底层逻辑需要先找相同之处
大部分产品常说的底层逻辑指的是业务逻辑，数据逻辑等逻辑流程。而我想说的底层逻辑是事物各自遵循的规则。例如：万有引力、能量守恒等。因为这样我们看待问题的时候就可以更加的贴切本质，从思路上打开新的天窗。
借用刘润老师的话：底层逻辑就是揭开表面不同看到背后的相同，找到变化后没变的东西。在这层没找到共同之处，再往下挖掘。在这句话中揭露底层逻辑的一个本质之一。不同的表面都背后的相同。
带入需求文档中，我们可以看见每一个模块都是不同的，虽然他们都不相同，但他们遵循的底层逻辑一定是相同的。这时我们需要思考每个模块来找寻他们的不同之处和相似之处。
- 使用说明：需要我们准确说明该文档涉及的范围，做一定的范围指导（不是所有的东西我都管ok？)，说明能给谁看，不能给谁看（傻子们不要乱传出去），并且解释文档中一些专业名词，避免出现认知差异，还需要对文档中的一些名称进行定义说明，比如，名词：我去年买了个表；含义：去年我去买了一块手表；歧义：我去你xxx；
- 修订记录：告知查阅人每一次编辑负责人是谁，避免找不对人（那个傻子修改了我的原型？凭什么修改为的原型？脑子是不是有病），记录每次修改内容，方便回档，让每一次修改都变的有凭有据，更加的谨慎，而不是“我想…. 、我觉得…..”（嘴强王者）
- 版本记录：清晰让所有人了解当前线上版本和线下版本情况，了解每个版本的负责人是谁，针对版本问题可以统一的进行反馈（指定谁是这次的背锅侠）
- 版本说明：我们在什么情况下，遇见了什么问题，那我们这次用什么方法 解决了这个问题。帮助其他人快速了解版本情况。
- 全局规范：告知所有人我们遵循的规则是什么，要如何避免文档内容参差不齐而沟通困难。
- 功能列表：记录我们会涉及哪些平台，有什么样的模块和功能。对于一些功能我们有什么特别的要求和限制。以及最后我们大概的开发周期是多久。
- 角色列表：告知我们整个系统内涉及的角色有好多个，能不能创建角色？每个角色他们能做什么事情。
- 权限列表：枚举出我们系统中可以使用的权限有多少，可以让使用者快速了解哪些能做哪些不能做。
- 框架图：快速掌握产品的整体框架
- 流程图：展示各个细节上的业务逻辑以及数据逻辑，明确每个产品模块是如何运作或协同的。
- 原型图：将抽象的功能具现化，变成可视化页面，让大家了解我们做的产品是什么样子的。
- 非功能需求：清晰表述特别的要求，如性能要求（负载均衡、响应时间）、安全要求（防火墙、非对称加密）、复用要求（模块化低耦合高内聚）等。
- 人员安排：指明每个模块、每一个时期谁是负责人，当出现问题之后，可以及时联系干系人，提高效率。
- 特别说明：将产品中涉及风险和需要注意的地方进行表述，避免大家触及风险，造成不必要的损失。
呼，写了这么多，那么咱们思考下，他们的相同的地方是什么？似乎每个模块的使用场景中都存在两个或以上的角色，都是交代、说明一些事实 。这些事实，要么让你避免什么问题，要么是让你遵循规则或是指导你出现问题后应该及时找谁处理等。
从这些角度开来需求文档的底层逻辑看起来是沟通。用需求文档代替我们需要面对面沟通问题。使用需求文档减少我们沟通时间，提升了我们的效率（不用面对面去沟通，省下来的时间去做其他的工作）。
我们换个角度，现在我们大多数使用敏捷开发的方式进行产品开发，在敏捷开发中我们很少看到十分详细的需求文档，更多都是一个简单的原型就进行开发，甚至有时没有实体文档，就一句话、一个白板画就进行开发，并且还能够在短时间内完成上线。
面对这样的情况，不管是一句话还是就一个原型他们都是需求文档，但说需求文档的底层是沟通，就显得十分牵强，因为日常交流也是沟通啊，所以说一句话就是需求文档？这样的后果就是强行上升到哲学的问题，我们下面在继续思考。
我们再从其他方向入手，从它们的形态开始思考，为什么会存在那么多ppt、word、excel等形态的需求文档。他们的相同的地方是什么。和其他使用ppt、word、excel等工具的内容又有什么相同的地方？
根据这样的思路我发现其实他们都只是一种承载的工具而已，我们甚至可以用纸笔来写，用脑子来记。所以抛开这些工具，我们的目的只是在于记录。记录需求文档的使用说明，记录产品原型的样子，记录规范，记录负责人等等，所以需求文档的底层逻辑之一就是记录。
但是这里体现出一个问题。在敏捷开发中似乎也不存在记录啊，老板开头一句话我们就直接干、我们开发的时候也没有文档来记录，大家都是直接面对面沟通开发。在这些真实的场景下，需求文档的底层逻辑又不成立了。
我只想说对于这些只是形式上的记录，不能因为没有实体文档记录而说没有需求文档。但确实这样看来光一个记录并不能代表需求文档的底层逻辑，那么还需要另外的东西。
05 相同属性+不同差=底层逻辑（本质定义）
柏拉图有个小故事，柏拉图曾说人是二足无毛的动物。然后第欧根尼就带了一只拔光羽毛的鸡到讲学的地方，说：「这就是柏拉图的『人』」。同时亚里士多德说：「人是理性的动物」。在两位大佬的话我们可以发现，我们除了相同的属性，还需要一个他们不同的地方。
需求文档和其他用相似工具记录的内容来讲，他们的相似之处在于记录，用不用等形式记录内容，那他们不同之处是什么？是工作，需求文档是记录工作的内容？我看不是，工作中也有很多需要记录的问题，所以不是所有的文档叫需求文档。
记录需求，需求文档是记录需求的内容？我看也不觉得准确，因为除了需求，需求文档中还记录很多东西，如说明、限制、人员、修改记录等，最后再三思考，我暂时认为，需求文档的底层逻辑是（我下定义了）记录有歧义的内容（交流正确的内容）。
为什么？记录这个我们不再说了，这个是内容的底层逻辑，所有内容都需要我们进行记录（交流），不管是线上，线下还是脑子里面，都是需要我们记录（交流）的，这就是他们共同的属性。
那为什么是有歧义的内容了，是因为我将他们带入了日常开发的场景中，很多时候不是所有的内容都需要进行文档记录，我们可以采取口头沟通的形式就能达到效果，所以并不是全都需要文档记录。那么是在什么情况下才需要记录了？那就是预防事故（预防背锅）。
不管是文档说明，功能列表，原型样式还是业务逻辑，我们都会去记录、去做可视化的页面还有详细的标注，那是因为我们怕出现意外。这里的意外是指因为每个人认知不同，看待问题的方向不同，而造成大家按照自己的想法来进行工作。
例如短信验证码是多少问的问题，运营觉得4位简单，研发觉得8位安全，而产品经理觉得6位即可，即相对安全也方便快速记忆。像这样有歧义（需要确认）的地方我们将进行记录（交流），以便后续做的时候都按照这个来。
所以需求文档的底层逻辑上：记录有歧义的内容（交流正确的内容）
06 通过底层逻辑思考需求文档的表面
在知道需求文档的底层逻辑是记录有歧义的内容后，我们就可以很好的思考那些模块是我们需要的，那些是不需要的。
例如：大家都知道项目背景和需求背景，是不是我就可以暂时不写文档说明？咱们的团队很小只有几个人，是不是代表着我们需求文档只需要一个原型就可以？研发十分清楚系统觉得和边界，我们是不是就可以不要角色相关的信息，把时间拿出来用户讨论其他有歧义的功能？面对公司太坑，是不是我可以将文档私下记录，工作中全靠脑袋给研发输出，最后离职时没有文档交付而报复（虽然不对，但是也有这种情况）？
所以理解需求文档的底层逻辑后，面对丰富的需求文档模版我们是不是有了更好的选择？
