“不专业的产品经理，你连ta需求文档都读不下去”，这是近期很有共鸣的一句话，产品需求文档算得上是产品经理的半个大脑，因为产品需求文档是前期所有工作的结果，那一份可读性高的需求文档到底有哪些共性？
首先先了解我们大脑是怎么理解文字或一段话的，我们遇到事情需要去理解时就会将得到的信息往已知的模型上靠，一旦如果我们大脑有类似模型，理解起来就很容易。如果沒找到类似的模型，理解就很困难。
1.声明名词，帮助阅读者建立已知模型为什么提到Toast大家知道是提示对话框，因为Toast已经被多次教育大脑已经“定义”"好了，大脑能直接解析并获得信息，但如果需求文档中经常出现的或者陌生的词，就可以在文档开头定义清楚，这样一来就能让阅读者清晰明白，这个常出现或者陌生的词到底是什么意思。有点类似于纸质书里面的注释，避免理解误差，达成共识。
2.用开发熟悉的语言来写文档网上经常会有人问，开发喜欢看怎样的需求文档，用户开发熟悉的语言来写，即一些逻辑描述和开发平时常接触描述一致，如开头所提到，往开发已知的信息模型上靠，比如一个列表的排序规则，我们想描述时间越近排在越前的时候，通常会这么写“XXX按动态更新时间从大到小排序”，最好的应该这么描述是“按更新时间倒序”，“倒序/升序/降序”应该已经存在每个开发人员的已知信息模型中，理解起来更容易。
除了排序外比较常见的还有时间单位，可以用yyyy-MM-dd hh:MM:ss即年月日时分秒来代替，相比文字描述研发对字母代码更熟悉。
3.结构化图文搭配如果一个页面需求比较复杂且是纯文字描述性的文字，一大坨一大坨堆在一起别说开发人员，就算是你接手了离职同事的文档，相信你也看不不下去，能用图来描述的情况下就不要用文字，图+文字搭配可读性会更高，一图胜千言，因为实际开发时，开发需要考虑后续逻辑变化，如果只有纯描述性的文字，开发可能还得猜后续逻辑变化，但如果有流程图/泳道图搭配文字描述，那结果就完全不一样了。
4.善用表格如果一个需求涉及“一对多”或者“多对多”的时候，比如根据“不同用户等级给予不同的文案提示”，用表格把“等级和对应提示文案”装起来，真的会有一目十行的效果。我们得感谢有“表格”这种东西存在，因为如果没有表格，我们可能得多喝5L水和开发面对面沟通，估计后续还得在微信上敲5000个字。
5.巧用公式公式是最常见的逻辑处理之一，涉及到一些加减乘除的计算逻辑，尽可能公式化来描述需求，这样能简化开发的理解和思考。比如我们在描述积分变化情况时，通常喜欢用纯描述性的文字来写文档，“点击签到按钮用户积分加1，点击抽奖按钮用户积分-20”
如果把纯描述性文字转换成公式化变成以下这样
“点击签到按钮 用户积分 = 总积分 + 1”
“点击兑换按钮 用户积分 = 总积分 - 20 ”
是不是更加直观更符合开发语言。
但是记得不要“得寸进尺”，如果觉得自己一定开发基础，还想进一步提高开发人员阅读效率，是不是可以写成“伪代码”直接给开发照猫画虎。个人不建议这么做，因为不同开发语言写法都不一样，你理解的语言在开发角度可能不容易理解，我以前就犯过一个错误，web端的弹窗alert，在Android端得用alertDialog安卓开发才容易理解，不然还得理解你这个alert才能转化自己的思路，并且需求文档阅读人员里面还包含了测试人员，就算开发理解了，测试不一定会理解。
一些能被复用的产品模块，尽可能保持同样的写法，如果描述的画风不一样，开发有可能给你做出不一样的东西，当然上面所提到的内容，均建立在逻辑没有硬伤的前提下。
6.持续进步可以去看一下部分框架和平台的开发文档，比如web端常见的Ant Design，Element，如果产品形态是小程序可以去看微信小程序开发文档等等， 这样能够了解框架/平台的更新日志，这种信息了解的越多，对技术理解越深入，这样不管是写文档还是和开发沟通都会有很大帮助，同时这也是洞察力的一种表现。因为部分新能力更希望是你来提醒开发，这样开发更有积极性来响应，而不是平台更新了某个功能你毫不知情，反过来开发来提醒你，就显得非常被动。
切勿硬生生套用模板
经常会有一些读者加微信后会问“园长，你有PRD模板吗”，模板只是面上的东西，对于新人来说，模板只能给自己提供一个思路，而不是全部套用，毕竟合适自己的才是最好的，所以最好的模板内容模块应该是内部多次实操后总结出来的。
-END-
以上就是好的产品需求文档拥有6个共性一剪芳华剧情介绍的全部内容了，希望大家喜欢。