“不专业的产品经理,你连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,如果产品形态是小程序可以去看微信小程序开发文档等等, 这样能够了解框架/平台的更新日志,这种信息了解的越多,对技术理解越深入,这样不管是写文档还是和开发沟通都会有很大帮助,同时这也是洞察力的一种表现。因为部分新能力更希望是你来提醒开发,这样开发更有积极性来响应,而不是平台更新了某个功能你毫不知情,反过来开发来提醒你,就显得非常被动。
7.切勿硬生生套用模板
经常会有一些读者加微信后问是否有PRD模板,模板只是面上的东西,对于新人来说,模板只能给自己提供一个思路,而不是全部套用,毕竟合适自己的才是最好的,所以最好的模板内容模块应该是内部多次实操后总结出来的。
加老D私人微信,朋友圈更多精彩
你有在看么