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

版权声明

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

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部