一、需求文档的反思

        学习底层逻辑，通过底层逻辑真正的思考需求文档这东西；

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

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

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

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

        很多时候，当我们遇到不懂的，都喜欢去百度寻求答案，但是通常百度给出的答案都是五花八门的，无法区分好坏，甚至都无法判断是否是自己真正需要的。这时候，我们往往都只能选择一个通用的需求模板，照着抄把需求文档写完。长久以往，我们会发现每次写的需求文档总是跟上次的不一样，面对这样的情况我们只能是越查越头疼，于是乎，算了直接找个模版或者是别人的需求文档套一下，不一样就不一样吧。至此，我们走上了模版流产品经理，在这个流派中我们原则是，遇事不决，模版库学，模版不够，百度来凑。

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

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

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

        传达产品开发需求、保证各部门沟通有理有据、产品质量控制有具体标准、便于交接工作、等等

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

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

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

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

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

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

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

        使用说明、修订记录、版本记录、版本说明、全局规范、功能列表、角色列表、权限列表、框架图、流程图、原型图、非功能需求人员安排特别说明大家觉得如何？看着在这份需求文档规范，可能会有人觉得很细致，很好，想要直接使用，问有没有模版等。

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

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

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

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

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

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

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

       1、使用说明：需要我们准确说明该文档涉及的范围，做一定的范围指导，并且解释文档中一些专业名词，避免出现认知差异，还需要对文档中的一些名称进行定义说明；

       2、修订记录：告知查阅人每一次编辑负责人是谁，避免找不对人，记录每次修改内容，方便回档，让每一次修改都变的有凭有据，更加的谨慎，而不是“我想…. 、我觉得…..”；

        3、版本记录：清晰让所有人了解当前线上版本和线下版本情况，了解每个版本的负责人是谁，针对版本问题可以统一的进行反馈

        4、版本说明：我们在什么情况下，遇见了什么问题，那我们这次用什么方法 解决了这个问题。帮助其他人快速了解版本情况。/

        5、全局规范：告知所有人我们遵循的规则是什么，要如何避免文档内容参差不齐而沟通困难。

        6、功能列表：记录我们会涉及哪些平台，有什么样的模块和功能。对于一些功能我们有什么特别的要求和限制。以及最后我们大概的开发周期是多久。/6角色列表：告知我们整个系统内涉及的角色有好多个，能不能创建角色？每个角色他们能做什么事情。

        7、权限列表：枚举出我们系统中可以使用的权限有多少，可以让使用者快速了解哪些能做哪些不能做。

        8、框架图：快速掌握产品的整体框架流程图：展示各个细节上的业务逻辑以及数据逻辑，明确每个产品模块是如何运作或协同的。

        9、原型图：将抽象的功能具现化，变成可视化页面，让大家了解我们做的产品是什么样子的。

        10、非功能需求：清晰表述特别的要求，如性能要求（负载均衡、响应时间）、安全要求（防火墙、非对称加密）、复用要求（模块化低耦合高内聚）等。

        11、人员安排：指明每个模块、每一个时期谁是负责人，当出现问题之后，可以及时联系干系人，提高效率。

        12、特别说明：将产品中涉及风险和需要注意的地方进行表述，避免大家触及风险，造成不必要的损失。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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