加入收藏 | 设为首页 | 会员中心 | 我要投稿 源码门户网 (https://www.92codes.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 运营中心 > 建站资源 > 经验 > 正文

全面解析 | 如何做好输出「需求文档」这件「小事」?

发布时间:2017-07-06 04:04:15 所属栏目:经验 来源:woshipm
导读:副标题#e# Anyway,「方法只是思维层级里底层的事情」。 最近一直在思考「输出需求文档」这件「小事」,发现太多产品经理连需求都没办法完全表达清楚,在需求评审会上支支吾吾,被各种挑战,或者开发阶段中多次重复确认,疲于各种沟通。相信每个产品新人都有

与客户端逻辑不同的是,这部分更多是界面之间操作流程,辅助界面的交互说明(点击、加载、动画),几个注意点:

交互设计的本质是「让用户更快更便捷的使用服务或产品内容」始终考虑交互设计五个要素,媒介、场景、行为、目的、用户

#边缘场景

如果你完成了上面的主要逻辑场景,一般来说功能只完成了一半,甚至没有。边缘场景的梳理这部分是最容易遗漏的地方,一旦遗漏就会陷入各种沟通和反复中。总结了常见的边缘场景,写完原型说明必检查。

网络状况:移动、WIFI、断网、弱网最大限制:字符、数据、等待时长等等缺省状态(为零):输入/展示为零多场景:夜间、横屏、竖屏、不同渠道等等账号状态:未登录/已登陆、多设备登陆、状态切换不同步服务器异常处理(5)结构流程

#信息架构

当信息项特别多而复杂的时候有必要将信息架构列出来,按照界面、界面元素、信息项逐项拆解,目的是在测试同学在写用例时更方便查找。

全面解析 | 如何做好输出「需求文档」这件「小事」?

#业务流程

业务流程在技术同学开发时关注的部分,分为数据流程和用户流程两类流程。

1. 数据流程:数据交互逻辑,描述前端、客户端、服务端数据情况。

全面解析 | 如何做好输出「需求文档」这件「小事」?

2. 用户流程:用户交互流程,描述用户操作流程。

全面解析 | 如何做好输出「需求文档」这件「小事」?

全面解析 | 如何做好输出「需求文档」这件「小事」?(6)埋点说明

埋点的作用是为了功能上线后做分析调整,也是迭代的关键辅助,一定要做到「有功能必埋点」。埋点包括三个部分:事件ID、事件名称、统计口径、事件描述。

事件ID 事件唯一标识,一般使用英文表述意义,单词间使用下划线隔开,如 click_add_bookmark_folder事件名称:事件的中文名称。统计口径 指埋点类型,分别为计数事件、内容计数事件、计时事件、状态事件。计数事件:只计算次数的事件类型内容计数事件:除了计算次数,还有其他参数上传,参数一般用英文区分,如 from=下载来 源,package=下载包名, host=下载链接 host,此类型多用 于减少计数事件埋点和用于报表生成。计时事件:用于计算用户使用事件,多用于页面停留计算,进入页面开启计时 器,离开页面时停止计时器,并生成事件状态事件:用于上报开关状态情况,通常用 0,1 表述。

4. 事件描述:什么时候触发埋点

需要关键点是:

减少重复埋点,尽量使用内容计数方式埋点名称和参数尽量使用有意义的英文表示,别埋点AA或者BB埋点的目的是为了生成报表分析,先想好功能要分析什么部分,需要什么埋点,「以终为始」不容易漏掉埋点或者参数。做好版本管理,云同步或在线协同文档功能都是不错的选择善用前缀命名,拓展更强全面解析 | 如何做好输出「需求文档」这件「小事」?二、输出动作

需求文档只是整个流程中将思路文档化的过程,可见项目完整流程图,文档只是很小的一部分。本文先不讲需求跟进部分,仅仅「输出需求文档」就容易忽略前期和后期,导致需求流程不可控。

全面解析 | 如何做好输出「需求文档」这件「小事」?

(1)需求输出前

输出前做好两件事情分析和沟通,能在需求后续流程中更顺畅。

需求分析:想清楚为什么要做这个需求,可以从用户场景和反馈思考,可以从数据分析,可以从竞品中参考,但是一定要比任何人都要想得更多。沟通:提前将想法和需求参与人员沟通,比如开发、设计。让他们提前了解需求大概和评估可行性,这样能避免将需求评审会变成需求讨论会,团队一群人开一整天讨论会效率极低。

II.需求输出后将需求文档发出去之后就完事了吗?在需求跟进过程中,需求文档是需要维护。

1. 有疑点及时讨论(越早发现坑越少),讨论后必定要总结,总结必定文档化2. 做好需求历史版本管理,上面已经说过版本历史是非常好用的技巧,另外文件命名上也需要加上版本号和时间,变更时通知所有参与人(邮件或团队协助工具)

三、目的和原则

分享了「输出」和「需求文档」两件事情的心得,目的绝不是让大家下载模板,直接套用,而是参考的同时能理解PRD里每个部分的作用和方法,在实际积累中形成自己的PRD模板,关注需求内容本身而不是需求形式,提高思维效率。另外,想掌握一个方法,形成自己的方法论和认知必须经过具体到抽象,抽象再到具体的过程。

具体 -> 抽象:在探索中总结经验。比如我这份需求文档总结,也是从无开始不断迭代,最终总结了所有经验得到抽象的结果。抽象 -> 具体:结合实际运用。比如我理解了每个部分的意义,在每个项目时间和不同条件下输出不同的需求文档。

Anyway,「方法只是思维层级里底层的事情」。

四、最后需求文档以「梳理清楚需求思路,减少沟通成本」为目标,而不是写出漂亮的万字需求说明书,不写空话废话;需求文档不仅仅是个名词,更应该加「输出」这个动词,关注完整输出过程,能够使需求流程更加流畅;产品经理应该有自己的技能树,每次积累总结都能点亮一项技能,「需求文档」这件“小事”是最应该前期先点亮的技能。

附上axure原型文件,链接: https://pan.baidu.com/s/1o8K87Ui 密码: gtkx,仅供参考。

作者:WinsonL,微信公众号:WinsonL,魅族科技Flyme产品经理,成长焦虑人群的其中一员,用实例干货分享思考和经验。

文章作者系 @WinsonL 未经许可,禁止转载。

注:相关网站建设技巧阅读请移步到建站教程频道。

(编辑:源码门户网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读