如何用写情书的思路写

　　在产研的世界里，情书（PRD）一定是写给RD的。
　　还是在五彩城工作的时候，一个炎热的下午，PM小潘来找我吐苦。大致就是PRD被研发喷了，上我这儿讨几颗＂灵丹妙药＂。
　　因为私下都很熟，我也就开门见山的问道：＂你不是有女朋友吗？＂。
　　＂对啊，咋了？＂，他一脸呆萌的望着我回道。
　　＂跟我我聊聊，你追妹子的过程吧~＂
　　此处省略一万字……
　　＂你是说把RD当成女朋友？＂
　　＂准确的说，是用你写情书的思路和态度，去写PRD！只要把几个关键的问题想清楚了，写个好点的PRD也就不是啥难事儿。＂
　　1. 情书到底是写给谁的
　　在产研的世界里，情书（PRD）一定是写给RD的。
　　一次和老板开方案沟通会，某个PM滔滔不绝的讲着自己的PRD交互如何友好，却被老板喷到＂这次会议只讨论战略层和内容层面，表现层面的事情你们产品团队内部自己搞定！＂，于是乎这位仁兄就弄了个烧鸡大窝脖，甚是尴尬。
　　还有一次，我手下的一个产品负责了一个非常复杂的项目，为了避免上线前业务反水就去和业务过方案。不可否认，该同学非常认真，连字段表结构设计都给业务讲了一遍，得到的是业务同学的一脸懵逼和不屑。
　　老板对方向和资源分配负责，员工对战略落地质量负责。方案质量应该通过产品内审会来搞定，老板会从结果追责，但不会过多介入过程。所以别再拿你的PRD给老板扣字了。他不会看的，也不应该看（ps.抽查监控除外）。
　　业务同学都是目标导向，老板定了目标，玩儿命的去冲锋。他们使用工具，但不会关心工具的产生原理。＂你进屋开灯后，会思考灯光发亮的原理吗？＂所以别再拿工程术语鄙视业务同学的智商了，那只能暴露你的情商。他不会看，也不应该看。
　　以上例子并未覆盖全部类型的同事，但要知道，众口难调，没有聚焦，无法取舍。如果我们不清楚到底是写给谁看，就没办法做出取舍。有的妹子喜欢幽默一点的表达方式、有的喜欢文艺点的、有的喜欢简单直接，有的喜欢委婉含蓄。
　　天知道，她到底好哪口儿？
　　所以必须承认一个事实，情书的接收对象只有RD（那个目标明确，ID唯一且清晰的姑娘）。
　　对老板、业务不友好是可以接受的，甚至是必然的。
　　2. 具体该怎么写
　　用你的情商设计模块，用你的智商撰写方案。
　　面试的时候经常会听到应聘者这样炫耀：
　　我交互方案质量非常好，高保真的。
　　我这个方案用的是xx大公司模板，非常严谨。
　　我跟研发沟通的时候，经常用术语，这样才证明我够专业，避免被他们小看了。
　　＂我以为＂＂我觉得＂是这个世界上比较可怕的思维，有点以个人为中心自负的味道。在家自嗨还行，在外追妹子就差点事儿。
　　残酷的现实如下，玻璃心请关闭此文。
　　高保真的方案既浪费你的时间，又浪费RD的时间，鬼才知道你这个页面还有那个地方可以跳转。
　　大公司的PRD成熟严谨是没错，可就一个敏捷需求你给我整一堆略，也是醉了，半天也找不到你到底要让我做啥。
　　专业术语体现自己牛逼这没错，但总是说超出研发认知范围外术语，就有点欺负人了（光理解MVP就够对方解释一阵子了）。
　　不要在为了做而做，还是回归初心，安静的听听人家姑娘的心声，也许她就想喝碗小米粥呢~
　　一般来讲，如果把RD这类妹子确实都比较简单，爱好不外乎如下：
　　（1）简单直接
　　但凡有点工作经验的都知道，研发的排期永远都是非常紧张的。虽然他们会评估工期的时候给自己留一些弹性时间，但那时留给意外情况的，不是给理解你方案的。
　　为此，请简单明了的描述你的需求。不要出现＂可能＂、＂大概＂、＂我觉得＂这类令人抓狂的字眼儿。
　　记住，老板、PM0和你催的那么紧，她没功夫看你写的废话。
　　（2）逻辑清晰
　　RD就像是翻译，将你的PRD语言翻译成工程语言。
　　为此在这个过程中，为此一个好的PM在撰写PRD的时候就应该是像在写代码。逻辑无非条件、顺序和循环。交代清楚事件的触发条件，降级方案和极端情况。
　　记住，你让她翻译的越轻松，她就越喜欢你。
　　（3）内容完整
　　他想要的你给了，他没想的你也给了，制造超预期的体验。
　　一般来讲完整的PRD需要包含的模块：
　　背景；
　　预期目标；
　　版本说明；
　　业务逻辑（流程图&storyboard）；
　　功能说明；
　　风控；
　　埋点；
　　UI （此处不做展开说明）；
　　参考资料。
　　记住，你越体贴，她就越喜欢你~
　　（4）充分尊重
　　工程的不确定性与方案的复杂程度呈正相关，为此如果你很兴奋的启动一个这类重点工程的话，请早些和相关的RD进行沟通。
　　条件允许的情况下，可以融入他们的产品方案建议，利用参与感提升主动性。
　　想想看，如果准备开发的PRD中有她自己贡献的一部分智慧结晶，内心回事多么的骄傲。
　　人毕竟不是机器，都希望自己是在输出价值，而不是在做重复的劳动。
　　为此，方案里一定要体现对方投入时间后会给业务带来多么大的价值（当然前期沟通需求的时候，才是最好表达的时机。方案里体现是再一次强调当前工程的意义）。
　　记住，每个RD的声音都值得尊重，能在PRD中体现出来就尽量体现。
　　另外，每个人都不想浪费时间，当你的方案明显属于意淫的时候，对方会感觉自己可能在实现一坨垃圾，在浪费时间。
　　所以能在PRD参考资料模块中，体现自己的决策依据（有源设计）是一个不错的习惯，对双方的时间都是一种尊重。
　　（5）表达友好
　　一般PRD就三种模式，这个公司要是没有强制规定的话，就根据方案内容来选择。
　　storyboard模式：
　　这种用axure/sketch作图加标注的PRD,适合界面比较多，逻辑比较简单的方案。
　　优点是比较直观，有几个页面以及页面之间的关系通过连接线一目了然的就能够识别。
　　缺点，设计页面过多或逻辑较复杂的情况下，阅读体验和效率就会差一些，另外文档的检索效率也会差很多。（可以通过分类目录来解决）
　　xib模式：
　　用axure/sketch话storyboard（不展示业务逻辑规则），再用相截图加文字写到word或wiki里面，具体说明规则逻辑。
　　纯代码模式：
　　截图加说明在word/wiki按照一定逻辑层级展开，适用于逻辑比较复杂含有一定的前端交互（数量比较少）。用好标题导航工具，逻辑也能展示的很清楚。
　　（3）也许上面都是错的
　　我们必须承认，唯一不变的就是变化本身。
　　时代在变，世界也在变（学徒里的川普都当上总统了），我们赖以生存的互联网也在变，以上的内容都具有一定的局限性和时效性。
　　经验总是靠不住的，唯一不变的是真理。＂以用户为中心做设计＂为用户创造价值，才会获得相应的回馈，这就是真理。
　　所以忘记那些专家，忘记那些模板，回到你的＂梦中情人＂身边，静静的倾听她们的心声。写一篇＂贴心的＂清楚，必然会赢得RD们的一篇＂芳心＂。