PRD需求文档如何写？掌握它的底层逻辑你就会了

01 产品经理的事儿，怎能算抄

年前写了《需求文档：没有标准、只有沟通》这片关于需求文档的内容，但是说实话更多的是感受而非思考，这次主要是学习底层逻辑，通过底层逻辑真正的思考需求文档这东西；

需求文档是我们工作中接触最多，写的最多，花样最多的文档，没有之一。

为什么说没有之一，首先说说他的展现形态。有ppt版、word版（文档）、excel版、axuer版、墨刀版、幕布版等丰富的展现形式。其次内容上需求文档还要分c端、b端、g端，最后还有可能根据交付人不同而进行不同的调整。所以说需求文档是写的最多，花样最多的文档。

所以就在这样的前提下，写需求文档似乎就成了许多产品经理们老大难的问题。独自写需求文档时发现不了问题，一旦遇到要与其他人协同，需要交付给他们需求文档，这时心态立马就到“爆炸边缘”了。

各种问题都涌现，我的结构对不对？该这样写吗？需求文档该如何写？等等问题就出来了。

在这里插一句表扬，表扬咱们产品经理的优点，就是不懂就百度。所以每当大家遇见困难，都能自觉带着各自的疑问去百度，寻找解决方案。但我们又常因为百度出五花八门的答案，又一脸懵逼，最后只能懵懵的跟着这些“答案”抄“作业”把需求文档写完。

最后本以为写完就ok了，又发现这次写的需求文档又和上次的不一样。emmm….都是我写的为什么不一样？我是不是我查的姿势没对啊。

面对这样的情况我们只能是越查越头疼，于是乎，算了直接找个模版或者是别人的需求文档套一下，不一样就不一样吧。至此，我们走上了模版流产品经理，在这个流派中我们原则是，遇事不决，模版库学，模版不够，百度来凑。

我只想说，这样不对（很有天赋），这样是学不到东西的（你已经入门了）。哈哈，其实产品经理的职责就有解决问题，如果你能用这些方式解决了问题，这就是一个好方法，这是不容置疑的事。但是我们需要通过表层看他们的底层逻辑才行，这样我们才能升级。

02 透过需求文档的表层看他的底层

在大部分咱们搜索需求文档时，咱们得到的答案一般如下：

1. 传达产品开发需求（我不管，我就是要，按照我的逻辑可以搞定。）
2. 保证各部门沟通有理有据（这是谁的锅，别乱丢）
3. 产品质量控制有具体标准（小老弟你看，你当初自己确认没问题，你现在…..）
4. 便于交接工作（来，老弟我走后，这口锅你要拿稳了）
5. 等等（产品经理在外，要学会保护自己…）

这些内容其实我们只需要简单的搜一搜就都知道了。但却存在一个致命问题，那就是每次借鉴完毕后，过段时间就忘了，又不知道该如何学，又需要重新打开百度或是自己的模版库去借鉴。长此以往，对于我们来说，我们确实收获了快速解决问题的能力，但是却丢失了产品经理最重要的东西，探索，挖掘问题的思维和能力。不说本末倒置，但确实对我们不利。

因此，我们需要学会在现有答案中去挖掘答案深层次的底层逻辑，在了解事物底层逻辑之后，就会发现事物的变化都遵循着底层逻辑，例如：能量守恒，万有引力。面对底层逻辑，我们理解起来会存在一定的困难，但底层逻辑就好比一个公司的愿景，它将是这个公司前进方向和价值体现，只有我们需要不停的逼迫自己去思考，不停的杠自己，最终提炼出它的底层逻辑，那时咱们将会通向罗马。

用树来比喻，我们直视树时，眼里多数只关注这树的树叶，当我们刻意观察时，能看见树的树枝。如果我们聚焦目光再次观察，咱们会想到它的树干。到这里时大部分人就停下思考，说出树干上长树枝，树枝上长树叶，所以树干是影响树生在的原因。

但是我们都知道这不是真正准确的事实，树还有树根，我们还需要用工具挖开脚下的泥土，发现这棵树的树根，在才是真正的底层。

为什么树根是底层？，而树干不是？树干坏死了这个树也不没了吗？这里会忽视一个问题，树干枯萎了，不代表这个树没了，只要树根健全，那么这这颗树的树干就算枯萎了，也会枯树发芽的情况。如果树根坏死了，那么这颗树再怎么的高大，健壮，对于这颗树来说死亡是一定的事。

所以观察一棵树不要光看“树叶”、“树枝”、“树干”，我们还要去挖掘它的“树根”来看。

03 解决方案是客观存在的，不要随意主观使用

事物的发展是非线性的，都会经历一个个起伏，但事物发展也都遵循它的底层逻辑。就像一个树，就算这颗树长得如何奇怪，但树一定是向上生长的。如果你要质疑，说有些树是斜着或是横着生长的。我只想说，那是因为你看待这颗树的角度不对，如果你关注的是它离开地面的位置，就会发现他们始终是向上生长的。

在很多写需求文档相关内容的文章中，多数文章都会提及让大家按照文章中的需求文档标准来写。让大家误以为跟着文章中的规范和标准来就没有问题，随即大家也就根据文章中的需求文档规范和标准来依葫芦画瓢了。至于为什么这样写？这样写的用处是什么？等问题就不去考虑，潜意识认为文章里的标准就是标准，跟着写就对了。

但是这样完全是误会大部分作者的想法，这类作者更多是想体现他们写需求文档的思路，希望大家可以相互探讨，寻求进步。而不是直接炒一炒就ok 的事情。

比如下面我提供的这个需求文档规范：

1. 使用说明
2. 修订记录
3. 版本记录
4. 版本说明
5. 全局规范
6. 功能列表
7. 角色列表
8. 权限列表
9. 框架图
10. 流程图
11. 原型图
12. 非功能需求
13. 人员安排
14. 特别说明

大家觉得如何？看着在这份需求文档规范，可能会有人觉得很细致，很好，想要直接使用，问有没有模版等。

但是我在这里提醒大家需要注意，有经验的产品经理是不会太过随意的使用其他人的需求文档。而是根据公司、项目、人员等配置来灵活的调整需求模块。

直接使用会存在很多弊端，如整个项目就三个人，还需要使用说明吗？这个产品就做个计算功能，以后再也不迭代的，需要修订、版本记录吗？这产品就一个页面，那需要角色和权限列表吗？

带入这样的场景会发现，似乎需求文档中很多模块都不需要。但是有时候就是只有2个人的产品也还需要复杂的需求文档，那么到底什么时候用什么样的需求文档到底依据的是什么？我想说是底层逻辑。

04 底层逻辑需要先找相同之处

大部分产品常说的底层逻辑指的是业务逻辑，数据逻辑等逻辑流程。而我想说的底层逻辑是事物各自遵循的规则。例如：万有引力、能量守恒等。因为这样我们看待问题的时候就可以更加的贴切本质，从思路上打开新的天窗。

借用刘润老师的话：底层逻辑就是揭开表面不同看到背后的相同，找到变化后没变的东西。在这层没找到共同之处，再往下挖掘。在这句话中揭露底层逻辑的一个本质之一。不同的表面都背后的相同。

带入需求文档中，我们可以看见每一个模块都是不同的，虽然他们都不相同，但他们遵循的底层逻辑一定是相同的。这时我们需要思考每个模块来找寻他们的不同之处和相似之处。

1. 使用说明：需要我们准确说明该文档涉及的范围，做一定的范围指导（不是所有的东西我都管ok？)，说明能给谁看，不能给谁看（傻子们不要乱传出去），并且解释文档中一些专业名词，避免出现认知差异，还需要对文档中的一些名称进行定义说明，比如，名词：我去年买了个表；含义：去年我去买了一块手表；歧义：我去你xxx；
2. 修订记录：告知查阅人每一次编辑负责人是谁，避免找不对人（那个傻子修改了我的原型？凭什么修改为的原型？脑子是不是有病），记录每次修改内容，方便回档，让每一次修改都变的有凭有据，更加的谨慎，而不是“我想…. 、我觉得…..”（嘴强王者）
3. 版本记录：清晰让所有人了解当前线上版本和线下版本情况，了解每个版本的负责人是谁，针对版本问题可以统一的进行反馈（指定谁是这次的背锅侠）
4. 版本说明：我们在什么情况下，遇见了什么问题，那我们这次用什么方法 解决了这个问题。帮助其他人快速了解版本情况。
5. 全局规范：告知所有人我们遵循的规则是什么，要如何避免文档内容参差不齐而沟通困难。
6. 功能列表：记录我们会涉及哪些平台，有什么样的模块和功能。对于一些功能我们有什么特别的要求和限制。以及最后我们大概的开发周期是多久。
7. 角色列表：告知我们整个系统内涉及的角色有好多个，能不能创建角色？每个角色他们能做什么事情。
8. 权限列表：枚举出我们系统中可以使用的权限有多少，可以让使用者快速了解哪些能做哪些不能做。
9. 框架图：快速掌握产品的整体框架
10. 流程图：展示各个细节上的业务逻辑以及数据逻辑，明确每个产品模块是如何运作或协同的。
11. 原型图：将抽象的功能具现化，变成可视化页面，让大家了解我们做的产品是什么样子的。
12. 非功能需求：清晰表述特别的要求，如性能要求（负载均衡、响应时间）、安全要求（防火墙、非对称加密）、复用要求（模块化低耦合高内聚）等。
13. 人员安排：指明每个模块、每一个时期谁是负责人，当出现问题之后，可以及时联系干系人，提高效率。
14. 特别说明：将产品中涉及风险和需要注意的地方进行表述，避免大家触及风险，造成不必要的损失。

呼，写了这么多，那么咱们思考下，他们的相同的地方是什么？似乎每个模块的使用场景中都存在两个或以上的角色，都是交代、说明一些事实 。这些事实，要么让你避免什么问题，要么是让你遵循规则或是指导你出现问题后应该及时找谁处理等。

从这些角度开来需求文档的底层逻辑看起来是沟通。用需求文档代替我们需要面对面沟通问题。使用需求文档减少我们沟通时间，提升了我们的效率（不用面对面去沟通，省下来的时间去做其他的工作）。

我们换个角度，现在我们大多数使用敏捷开发的方式进行产品开发，在敏捷开发中我们很少看到十分详细的需求文档，更多都是一个简单的原型就进行开发，甚至有时没有实体文档，就一句话、一个白板画就进行开发，并且还能够在短时间内完成上线。

面对这样的情况，不管是一句话还是就一个原型他们都是需求文档，但说需求文档的底层是沟通，就显得十分牵强，因为日常交流也是沟通啊，所以说一句话就是需求文档？这样的后果就是强行上升到哲学的问题，我们下面在继续思考。

我们再从其他方向入手，从它们的形态开始思考，为什么会存在那么多ppt、word、excel等形态的需求文档。他们的相同的地方是什么。和其他使用ppt、word、excel等工具的内容又有什么相同的地方？

根据这样的思路我发现其实他们都只是一种承载的工具而已，我们甚至可以用纸笔来写，用脑子来记。所以抛开这些工具，我们的目的只是在于记录。记录需求文档的使用说明，记录产品原型的样子，记录规范，记录负责人等等，所以需求文档的底层逻辑之一就是记录。

但是这里体现出一个问题。在敏捷开发中似乎也不存在记录啊，老板开头一句话我们就直接干、我们开发的时候也没有文档来记录，大家都是直接面对面沟通开发。在这些真实的场景下，需求文档的底层逻辑又不成立了。

我只想说对于这些只是形式上的记录，不能因为没有实体文档记录而说没有需求文档。但确实这样看来光一个记录并不能代表需求文档的底层逻辑，那么还需要另外的东西。

05 相同属性+不同差=底层逻辑（本质定义）

柏拉图有个小故事，柏拉图曾说人是二足无毛的动物。然后第欧根尼就带了一只拔光羽毛的鸡到讲学的地方，说：「这就是柏拉图的『人』」。同时亚里士多德说：「人是理性的动物」。在两位大佬的话我们可以发现，我们除了相同的属性，还需要一个他们不同的地方。

需求文档和其他用相似工具记录的内容来讲，他们的相似之处在于记录，用不用等形式记录内容，那他们不同之处是什么？是工作，需求文档是记录工作的内容？我看不是，工作中也有很多需要记录的问题，所以不是所有的文档叫需求文档。

记录需求，需求文档是记录需求的内容？我看也不觉得准确，因为除了需求，需求文档中还记录很多东西，如说明、限制、人员、修改记录等，最后再三思考，我暂时认为，需求文档的底层逻辑是（我下定义了）记录有歧义的内容（交流正确的内容）。

为什么？记录这个我们不再说了，这个是内容的底层逻辑，所有内容都需要我们进行记录（交流），不管是线上，线下还是脑子里面，都是需要我们记录（交流）的，这就是他们共同的属性。

那为什么是有歧义的内容了，是因为我将他们带入了日常开发的场景中，很多时候不是所有的内容都需要进行文档记录，我们可以采取口头沟通的形式就能达到效果，所以并不是全都需要文档记录。那么是在什么情况下才需要记录了？那就是预防事故（预防背锅）。

不管是文档说明，功能列表，原型样式还是业务逻辑，我们都会去记录、去做可视化的页面还有详细的标注，那是因为我们怕出现意外。这里的意外是指因为每个人认知不同，看待问题的方向不同，而造成大家按照自己的想法来进行工作。

例如短信验证码是多少问的问题，运营觉得4位简单，研发觉得8位安全，而产品经理觉得6位即可，即相对安全也方便快速记忆。像这样有歧义（需要确认）的地方我们将进行记录（交流），以便后续做的时候都按照这个来。

所以需求文档的底层逻辑上：记录有歧义的内容（交流正确的内容）

06 通过底层逻辑思考需求文档的表面

在知道需求文档的底层逻辑是记录有歧义的内容后，我们就可以很好的思考那些模块是我们需要的，那些是不需要的。

例如：大家都知道项目背景和需求背景，是不是我就可以暂时不写文档说明？咱们的团队很小只有几个人，是不是代表着我们需求文档只需要一个原型就可以？研发十分清楚系统觉得和边界，我们是不是就可以不要角色相关的信息，把时间拿出来用户讨论其他有歧义的功能？面对公司太坑，是不是我可以将文档私下记录，工作中全靠脑袋给研发输出，最后离职时没有文档交付而报复（虽然不对，但是也有这种情况）？

所以理解需求文档的底层逻辑后，面对丰富的需求文档模版我们是不是有了更好的选择？

作者：wcof，在努力做产品不做产品经理的人；微信公众号：Wcof（ID：wcofPM）

本文作者 @Wcof

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！