PRD！全都是PRD！
桃子啊嘿约 4 分钟时光真是匆匆流过啊...
距离上一周更文的时间 已经过去一周 。当然，由于入职公司统一周三入职，所以我并没有上班一周~
今天是我实习上班的第三天 (๑•̀ㅂ•́)و✧ 总结一下这三天做的事情，就是三个字母： PRD ！所谓PRD，度娘给出的解释如下：
通俗来讲，PRD就是在产品向开发、测试、UI、UE传递需求时对于口头沟通的一份文字补充。
可能的使用场景是这样的：需求已经由研发总监下发排期给各位开发小哥哥小姐姐，小哥哥大致知道要干嘛，也参与过需求评审会议。
但素，人的理解力和记忆力是有限的啦~于是乎，当他在写代码的过程中忽然对某一个需求的逻辑感到迷惑时，他就会打开产品写的PRD，来看看需求的具体逻辑到底是什么样子的。
如果这个小哥哥看了PRD文档依然觉得“ 这啥需求，不知所云 ”，他就会call产品经理进行再次的沟通和反馈。OH MY GOD~产品经理又别想准时下班了。
在工作之前，我看了很多产品相关的书籍，我大致是知道PRD是什么，内容应该写什么。
但 理论终归只是理论 ，在老大把第一个需求摆到我面前，让我形成PRD文档时，我还是十分心慌。怎么用词才规范不可笑？ 这个需求的一级模块、二级模块到底是什么？ 功能描述里到底应该写那些内容？虽然只是一个很小的需求，我仍然花费了接近 3个小时 的时间来描述这个需求。 在这个“抓耳捞腮”的过程中我就在想： 为什么理解起来那么简单的功能用文字描述出来就觉得哪哪都不对劲呢？
我十分忐忑的把我憋了3个小时的成果发给老大。
老大回复： 写的不错哈，继续保持。
结果我一点进文档发现，满屏黄色标记，都是老大的标注...
感谢上苍赐予我一个温柔滴老大~
因为不能涉及公司隐私，所以不能给大家看具体的PRD文档，但是可以给大家看一下我前两天的学习笔记~
直到今天下班时间点，我已经写过7个需求的PRD文档了。
虽然相对有经验的产品经理还十分不够， 但是还是有一些体会的~人是一个不断学习和成长的动态个体，所以我知道未来我必然也会有更多的收获，甚至可能觉得过去的某个观点过于幼稚。
但即使如此，我还是想把真实的体会分享给大家，作为大家学习的参考。
第一，PRD作为沟通的桥梁性文件，确实在产品研发中举足轻重； 第二，虽然PRD的内容很多，但其实最为核心的仍然是对于需求的描述和管理，能够把需求用文字的方式叙述清楚，是最重要的； 第三，想要写好一份PRD，主要有以下几点： 首先产品经理需要对自己所撰写需求的产品模块和业务逻辑有着清楚的了解； 其次需要产品经理有一定的文字撰写能力，写出来的文字要易于理解； 最后也是最重要的，是逻辑思维能力， 许多功能很多的产品的需求逻辑可能是很复杂的，想要讲清楚就必拥有逻辑思维能力。关于逻辑思维能力，之前也有小可爱专门问过我如何去培养，正好我这两天在看赖京露的《产品之旅 产品经理的方法论与实战进阶》，里面提到了逻辑思维培养的 MECE原则 。
这个概念第一次提出是在麦肯锡的一位资深咨询顾问巴巴拉所撰写的《金字塔原理》一书里，感兴趣的同学可以去看一下。
这个原则主要的核心观点是：
任何事情都可以归纳出一个中心论点，而此中心论点可由三至七个论据支持，这些一级论据本身也可以是一个论点，被二级的三至七个论据支持，如此延伸，状如金字塔。 也就是说，我们可以将任何的问题拆分成金字塔状，拆分时的核心要义在于相互独立，完全穷尽。
具体来说，当我们撰写PRD文档时，
我们首先要问自己： 我是不是以金字塔结构把所有的可能都考虑到了？例如需求设计中的各种异常情况（登陆与否？是否有权限？没网怎么办？） 在确定考虑完所有情况之后， 我们又需要问自己： 这些因素都互相独立吗？是否可以去除一部分而系统或产品不受影响？多使用这种方式去思考可以很好的锻炼我们的思维能力并且输出一份质量更高的PRD文档。
路漫漫其修远兮，吾将参透PRD~下周见！
．<{=．．．．（嘎~嘎~嘎~） 最后，因为微信公众平台总是不开通留言功能（哼╭(╯^╰)╮），为了方便我们更好的共同学习和进步，俺今天建了一个QQ群，有兴趣的童鞋扫码进入哈乖 <(￣︶￣)>