在产研的世界里，情书（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们的一篇“芳心”。
本文由 @吴天 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
爱盈利-运营小咖秀(www.aiyingli.com) 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容；是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台；
想了解更多移动互联网干货知识，请关注微信公众号运营小咖秀（ID: yunyingshow）
