写了一年的需求文档,我想告诉你……
本文作者写了大概一年的需求文档,对需求文档也有了不同于一开始的认识,也积累了一些经验,在此分享给大家。
到目前为止,大概写了一年的需求文档。
整个过程从零开始,通过自己的探索(反复练习与参考资料),也算能产出一份比较满意的需求文档,接下来需求文档的作用说起。
需求文档的作用
1. 帮助产品经理梳理功能逻辑,构建产品的框架
很多人会认为需求文档是给开发同学与设计同学看的,目的是让他们更好地理解需求。但经过一年的实践,越发觉得产品同学才是需求文档最大的受益者。
写需求文档过程,也是构思产品的过程。需求文档中包含『产品结构图』与『逻辑流程图』,产品结构图展示的是产品的具体模块与功能,而逻辑流程图则说明了功能的具体步骤。将他们写清楚后,产品的骨架也搭建了起来。
另外,在画产品原型、补充产品逻辑的过程中,能够帮助产品同学理清产品的细节,确保产品在最初的设计上尽可能的完善与流畅,最大限度避免了后续出错的可能。
2. 辅助产品同学阐述产品需求
在进行需求评审的时候,需求文档是辅助产品同学阐述产品需求的重要支撑,类似于演讲的PPT。很多时候单靠口头描述,很难说清产品的具体细节与逻辑,如果结合着产品原型图,则会事半功倍。
十分建议将产品逻辑背后的『理由/产品解释』写到需求文档中,例如弹窗的『确定』与『取消』按钮,突出『确定』按钮的原因是想让用户完成期待的操作;添加『功能结果页』的原因是为了增加广告的展示频次等。
这样做有两个好处:一是能让产品同学在设计功能的过程中,不断的自我质疑,减少功能逻辑潜在的缺陷;二是能让别人更好理解需求本身,增加沟通的流畅性。
3. 减少沟通成本
需求文档对于设计与开发的同学来说,更像是一份参考文档或者需求词典。在他们困惑的时候,能够通过翻阅需求文档,解决疑惑点,从而省去了询问的过程。这就要求产品同学在编写需求文档的时候,要尽可能细致。
一份需求文档,除了原型图外,还应该写清楚『开发注意事项』与『设计注意事项』。开发注意事项包含页面间的跳转逻辑,每个组件的操作响应,操作之间的避让逻辑等;而设计的注意事项应该包含页面组件的表现优先级,组件的不同状态等。
另外,如果牵扯到广告变现,还要将广告的请求时机,展示时机说清楚。
在产品实现正式开始之前,产品同学一定要对开发同学与设计同学说清楚原型图中的每个要点,确保他们对于需求的理解和自己达成一致。这样在推进产品落地的过程中,才能充分发挥需求文档参考作用。
4. 产品存档
处于维护期的老产品,如果没有相关的文档,对于刚接手的人,简直是一个灾难。因为一款产品从发布到成熟,期间经历过各种坑,缺少对应的文档的解释,很多功能逻辑都无法理解,可能需要重新趟一次浑水,才能将老产品彻底的掌握。这个过程本身是痛苦的,成本也是巨大的。
但是,如果有比较完备的参考文档,接手过程就会顺利很多。另外,在遇到产品问题的时候,也能够通过翻阅备份文档,快速定位问题,极大提高了工作效率。
5. 需求文档构成元素介绍
1)逻辑流程图
- 将产品目标拆解实现步骤,将相关的步骤聚合为产品模块,每个模块之间低耦合,高聚类;
- 模块内使用流程图将具体的逻辑串联起来,每个模块内的逻辑流程基本上都可以从头到尾执行完毕,少有交错的情况;
- 如果有重复出现的逻辑流程,要使用子流程进行概括,并且在主流程中使用子流程进行替换;
2)原型图
- 画清楚页面的组件布局以及文案信息;
- 各个组件的展示优先级,通过组件的大小、颜色的深浅表现出来;
- 页面/组件的不同状态展示(选中状态);
- 页面之间的跳转逻辑(使用跳转);
- 每个组件的操作响应(使用简单的流程线);
- 广告的展示位置。
3)开发注意事项
- 控件的操作响应;
- 页面间的跳转逻辑;
- 状态更改的时机与条件;
- 广告的请求、展示逻辑。
4)设计注意事项
- 组件的优先级说明;
- 组件自身在各种场景下的变化。
5)产品解释
- 说清楚页面/组件要实现的产品目的
小结
虽然写出一份完整的需求文档,看起来要花很长的时间。但实际纯粹输出文档的时间并不多,大概一到两天的时间。真正耗费时间的是产品框架的搭建与逻辑的梳理,而这一块对于任何产品都是必不可少的。
需求文档如果做得比较完善,节省出的沟通成本是巨大的。在实践的过程中,一份完整的需求文档,加上充足的前期沟通,大致能节省后期70%的沟通成本。省下来的沟通成本所带来的是成倍的效率,因为沟通前后的精力转移成本是非常巨大的。
当然,需求文档的详略主要取决于团队成员对于项目的理解。
如果项目本身就很小,每个人对于项目都有着较深的理解,需求文档只需要简单的概述需求本身;对于比较大型的、复杂的产品,需求文档则越完善越好。
#专栏作家#
MING,个人公众号:MING的大航海,知乎专栏:产品见知录,人人都是产品经理专栏作家。一只专注于个人成长的产品汪,沉迷『方法论』,只分享值得收藏的『硬干货』!
本文原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自 Unsplash,基于CC0协议。
原型和逻辑不应该交互设计做吗?
看公司,小公司基本上都是产品一人搞定,大公司的话会分工会比较清楚,但是无论如何,一个合格的(初级)产品经理都需要对原型有熟练的掌握(以上为个人观点)
需求文档跟原型放在一起写感觉会好很多 对应功能旁边就是文档说明
有一个示例模板吗
才看到回复,请阅读我之后写的文章,也可以关注公众号『MING的大航海』
开发不细看PRD,就喜欢问。这问题怎么解决?
需求文档写完之后,要带着『开发』与『设计』认真的过一遍,把里面的细节都讲清楚,如果开发的后续的过程中提问,如果是之前漏掉的细节,那你需要认真跟他说,并把漏掉的不全到需求文档中,如果他问的问题之前说过,那直接让他看文档(过程要注意沟通技巧)
如果你觉得你的prd写的很完整 阅读性也比较高 ,那他下次问你你可以委婉的告诉他prd里面写了 请他看!
对的。文档还是要写,叫不叫“PRD”不重要,管用就好,有利于工作提升就好。别为了写文档而写文档就好。
握爪
感谢作者的分享,顺带问一下作者平时写需求文档是用word,axure还是用其它工具
原型与说明用Axure,流程图用processon
好的,感谢指点