内容简介:正如我们做出来的产品都希望受用户欢迎,开发和测试是需求文档的用户,产品经理也应该重视他们的想法和要求才能写得令人满意。“写需求文档”说专业点是把用户(或运营、客服等)的需求转化成技术部门的话语,因此了解技术术语是产品经理的基本素质。要做到需求文档受欢迎,了解术语是不够的。虽然不可能写得像开发人员写设计文档的一样专业,但产品经理如果能运用技术人员的思维多做些考虑,就能减少评审过程的反复沟通,那必然能收到大量好评。技术人员的思维同样是被工作环境和内容训练形成的,编程语言、架构设计、测试方法是最主要的因素。其中
正如我们做出来的产品都希望受用户欢迎,开发和测试是需求文档的用户,产品经理也应该重视他们的想法和要求才能写得令人满意。
“写需求文档”说专业点是把用户(或运营、客服等)的需求转化成技术部门的话语,因此了解技术术语是产品经理的基本素质。要做到需求文档受欢迎,了解术语是不够的。虽然不可能写得像开发人员写设计文档的一样专业,但产品经理如果能运用技术人员的思维多做些考虑,就能减少评审过程的反复沟通,那必然能收到大量好评。
技术人员的思维同样是被工作环境和内容训练形成的,编程语言、架构设计、测试方法是最主要的因素。其中,开发人员会有这些思维:
- 组件与模块。
- 流程与联系。
- 条件与时机。
- 类型与精度。
测试也会有独特的思维:
- 极端。
- 因果。
- 场景:一系列的组合条件。
另外,用户体验思维中的“层次分明、重点突出”,也非常有助于优化需求文档的视觉效果以提高阅读效率。
我们以每种思维作为章节来回答本文的问题。
开发思维:组件与模块
我们写文章都不是从头到尾就一段话的,会分段落、章节,这样能帮助做到条理清晰。代码的本质也是“文章”,组件和模块就像是段落和章节,他们会对应一个功能、界面或规则。为此,需求本身也应有拆分:产品有结构,功能有细分,界面分区块等。
产品结构图就像文章的目录,在做新项目的时候应该附上。它不仅帮助产品经理自己梳理子需求,也让整个项目组都清晰知道产品的构成,对开发、测试、UI设计师后续的工作都有指导作用。现在多数人会用思维导图来画,原因就是它的最大作用是理顺思路。
功能细分可以用“评论”功能来举例,它可分为:
- 前置的登录注册等条件
- 界面上评论区的功能(比如@他人,回复某楼层,引用回复,表情输入等)
- 提交前的限制条件校验(比如字数、特殊字符)
- 提交评论的过程
- 评论的内容检验(比如涉黄、敏感信息)
- 评论后的展示(比如引用回复、互相@)
- 用户信息里的评论信息更新
如何做需求拆解是没有固定模式的,跟业务有紧密关系,一般的两个思路是流程和规则。
下图是界面分区块的示例(示例的意思是在原型和文档上这样命名,这不是原型图)
分区块并进行命名的好处:
- 利于文档描述,减少说明字数,加速阅读
- 利于沟通。大家只要说一个名字,就知道是说哪个部分,不用对着界面说。如果整个产品每个区域的名字是唯一的,那么报bug的时候可能连操作路径和截图都不需要了。
- 一般来说,开发写代码时也会用这些命名的(翻译成英语),他们会很感激产品经理帮他们想好了名字。
开发思维:流程与联系
需求是一个整体,拆分后的各部分必然仍有联系,他们的协作步骤即是流程。产品的交互设计在代码流程上是大致对应的,所以如果产品经理能把流程描述详尽的话,开发的工作差不多等于把这堆“中文”用编程语言翻译一遍而已。
如果流程足够复杂,就需要用图来表达。画图是描述复杂事物的基本技巧,不仅仅是需求文档的写作要求了,这里不展开讲。那么怎么才算复杂呢?一般简单的判断是:以最长的步骤路径为基准,如果超过30%的步骤有分支就应该画流程图。例如如果有7个步骤,有3个步骤是“是非选择”或“循环指向”,那就该画;只有2个步骤有分支就不用画,用文字说明白。延伸地讲,如果分支太多,需求本身可能就有问题了,应该从交互设计上去简化它,不应该给用户这么多可选择的东西而造成困扰。
一个实际的文字描述步骤例子:
- 进入“我”页面
- 是否已登录,是则继续,否则进入“登录”流程
- 点击“评论”区,进入评论页
- 如果评论数为空,显示占位图,否则显示评论列表
- 点击评论列表中的一条,进入帖子详情页,并且页面自动滚动到那条评论的位置
- 用户点右上角的“关闭”,跳回第4步,否则按“帖子详情页”的流程继续
在上面的例子里,我们也看到,流程之间会产生联系。一个流程中的某些步骤可以关联到另一个流程。这些流程之间的联系,在开发设计中会体现为“模块间的依赖或调用关系”。作为产品经理无需理解前面双引号内词语的技术意义,但有一个很典型的场景能帮助大家认识它的作用:开发解决了一个bug后导致了别的bug;更经典的是,开发抱怨说这是因为产品的新需求没考虑到对原有功能的影响。
无论最终是否开发的责任,产品经理也应该去梳理各个需求之间的联系,包括界面、交互、功能的相互影响。最好是文档中有独立的章节列出需求间的关联。这不仅是帮助开发测试做好设计,也是为自己检查疏漏。拿一个普遍的需求“登录”来举例,产品经理应该列一下所有“不登录就不能访问的页面”。以后改动登录功能的时候,自己也可以一下子看清所有的影响范围。这个习惯最能防止“状态多层次级联”(如A影响B,B影响C)的情况下考虑不周。
开发思维:条件与时机
计算机是不会执行没描述过的操作的,即使是火热的人工智能,也是要经过训练才知道什么条件做什么操作。所以开发需要在代码中精确描述:
- 流程的入口场景,即这种“可能性”的触发时机。
- 流程内每个步骤的执行条件。
不同的条件会导致不同的结果,这对用户使用有重大影响,所以一定把所有的条件和可能性都列出来。一般来说,产品经理最大的疏漏是没考虑异常情况。其实无论过程怎样,最终反映在界面上只有4种结果:
- 加载中
- 数据正常,正常显示
- 无数据,数据为空
- 出错,包括超时
产品经理把这4种结果的界面都定义清楚,就能覆盖所有中间过程的情况。当然,最好还是能把中间过程的可能性都考虑周全,并针对不同的状况有更精细化的结果展示。
开发思维:类型与精度
这是编程语言(更确切来说是CPU计算原理)带来的思维。我们不去深究计算机知识,只需知道对我们的影响:要用数据来描述一个事物以便计算机能理解。这些数据分两大类型:数字与文本。其中数字还有这些考虑:
- 整数还是浮点数,即是否带有小数部分
- 浮点数保留多少位小数部分
- 是否可能是负数
- 最大绝对值是多少(数字越大,可能会需要更多内存和计算时间。做适当限制有利于提高性能)
这个思维(或者说限制)会影响所有需要用户输入交互的地方。如果原型图上不能明显看出以上的信息,产品经理应该有意识地在文档中补充。
测试思维:极端
极端的情况下容易出bug,这是最基本的测试思路。如果界面上有一个输入框,以下几个测试用例肯定会有:
- 输入非常多的字符,看是否允许、是否合理显示
- 输入不应该允许的数值,比如超出最大最小值,看能否允许、能否继续下一步
- 输入不应该允许的文本类型,比如身份证号栏填入中文,看是否允许、能否继续下一步
下面几种测试手段,都会用到极端的思维:
- 最低配置的设备上能否流畅运行
- 在设备资源紧张(例如内存不足)的时候,程序还能否正常工作
- 在最老旧的系统、浏览器版本上能否正常运行
- 非常频繁地进行操作,程序还能否正常响应
依据这个思维,产品经理应该把这些东西都定义清楚:
- 可交互界面的输入类型与范围
- 目标运行环境的最低配置
- 兼容性:系统版本、浏览器品牌与版本
- 需要支撑多少用户同时在线、多少同时发生的流量
- 要能应对什么程度的故障
测试思维:因果
开发思维中“条件与时机”注重的是“前提”,测试还会做反向思考和补充。除了关心“什么条件导致了这个结果”,还要思考“这个条件会导致哪些结果”,这也是开发写代码容易疏忽的。两个典型的问题是:登录后可以做什么,界面上有哪些变化。这种思维在所有岗位都是适用的,也很容易理解,对产品经理的意义就不细说了。
测试人员不仅用它来评审需求,找bug时要考虑是什么操作、事项、需求导致了bug以及这些东西的关联关系、影响范围等,从而进一步发现更多问题。
而且作为需求的实现者,技术人员都会有这个问题:为什么要这样做,做成了会有什么结果。产品经理是有责任回答这个问题的。其中,“为什么要这样做”要心里有数,在需求评审时被问到就要能回答。不能靠想,要有根据:
- 用户调研
- 统计数据分析
- 市场调查
- 竞品分析
- 成功经验
还有“做成了的结果”应该把它以“目标”为第一章标题写到需求文档的前面。目标示例:
- 解决用户购物流程中的不便
- 给占比有27%的喜欢xxx用户增加一种选择,可以对xxx进行操作
- 转化率至少有12%
- 提升月活跃度10%(或到30%)
- 提高广告月收入至300万
产品经理做需求时,应该先想好这些目标,需求是围绕这些目标来制定的。大家理解这个目标后,还能帮助产品经理想出更多更好的方案来达成。
测试思维:场景
“场景”在本文中意为多个条件共同作用的情况。下表表示的是两个条件(行为、身份)下的结果(权限)。
行为-身份-权限表 | 游客 | 普通会员 | VIP会员 |
---|---|---|---|
购物 | 不可以 | 可以 | 可以 |
看视频 | 可以 | 可以 | 可以 |
评论中发表情 | 不可以 | 不可以 | 可以 |
设想增加一个情况:已绑定微信的会员可以查看“朋友积分榜”。这就需要一个“行为-身份-微信绑定-权限表”。如果有更多条件,就不是一个表格能说明的了。合格的测试人员会把这些条件的所有交叉情况都测一遍,甚至在需求评审后就要做用例设计,把需求文档没覆盖的情况立刻指出来。
场景的本质是条件的排列组合,可以用数学公式计算出有多少可能性。产品经理不应该把这些情况推托给技术人员去想,因为最极端的情况是可能会发现某些场景无解,以致要推翻整个需求。到评审完才发现这些问题就晚了,耽误了太多人的时间。
当场景过于复杂,除了要说清楚规则外,还应该写出示例来帮助理解。
用户体验思维:层次分明、重点突出
产品经理或设计师做网页设计时通常会有这些原则:
- 方便从上到下阅读,页面不会产生横向滚动条。
- 描述一个宏观事物的图不会跨越两屏才看完整
- 层次分明:标题比正文的颜色更深、字号更大、字形更粗。
- 段落内部的重点词句(一般是超链接)要使用更显眼的颜色,字形可以使用粗体、斜体、下划线等。
无论需求文档是写Word还是用Axure导出网页给技术同事看,以上原则都是适用的:帮助提升阅读效率。
还有一个问题是表格的运用。表格能让人一下看到哪里有填东西哪里是空白,但并不方便人仔细阅读所有的内容。什么时候用表格或列表,这里总结两个简单规则:
- 表格除表头外至少有3行3列,否则用列表。
- 如果表格写不出精确的表头来,也就是每行是不同意义的,用列表。
最后就是,写需求用Word还是Axure或两者结合,都无所谓,关键是要把事项描述清楚并且方便查阅。
思维应用
上述思维的运用,最终是为了提高需求的完善程度,避免需求本身有bug。产品经理要去学习技术知识的话,应该是要总结出更多的思维,而不是真的要会写代码。以下按照界面和交互来总结一下技术思维的关注点。
界面组件上的应用:
- 文本框
- 过长如何显示:换行、显示省略号
- 如果换行和省略号都不要,就要确定文案最大字数
- 数字保留多少位小数,四舍五入还是去尾或进1
- 数字的显示格式,例如加逗号或加单位
- 时间的显示格式,例如是否显示分秒,日期间用中文还是横线连接
- 输入框
- 默认值
- 占位符
- 按下回车的行为
- 自动补全的规则
- 可输入类型:纯数字、文本(中文、外文、特殊字符),是否密码
- 输入限制:文本长度、小数位数、取值范围、最大最小值、是否必填
- 选择框
- 默认状态
- 单选还是多选
- 下拉列表
- 默认值
- 实际值与显示值的对应关系:例如界面上显示100+,实际值是135
- 按钮:点击后的行为
- 弹框
- 位置:屏幕中间或中下
- 显隐动画:时长、方式
- 表格
- 排序规则
- 开关
- 默认状态
- 轮播
- 是否自动换页,间隔时间
- 是否显示分页器(“点点”或页码),是否可点击分页器来换页
- 是否可循环
- 是否显示进度条
- 是否增加每页边距,边距是多少
- 图片
- 缩放规则,例如固定宽度、高度随原比例
- 层级:谁可以遮盖谁
交互上的应用:
- 点击:反馈形式(例如变色)
- 手势(例如右滑后退)
- 距离
- 速度
- 方向
- 界面切换
- 动效:时长
- 窗口、屏幕改变大小(横竖屏切换)的布局规则
- 已输入的数据是否保留
- 关联关系。例如选中后会立刻改变其它控件的状态
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
图解TCP/IP : 第5版
[日]竹下隆史、[日]村山公保、[日]荒井透、[日]苅田幸雄 / 乌尼日其其格 / 人民邮电出版社 / 2013-7-1 / 69.00元
这是一本图文并茂的网络管理技术书籍,旨在让广大读者理解TCP/IP的基本知识、掌握TCP/IP的基本技能。 书中讲解了网络基础知识、TCP/IP基础知识、数据链路、IP协议、IP协议相关技术、TCP与UDP、路由协议、应用协议、网络安全等内容,引导读者了解和掌握TCP/IP,营造一个安全的、使用放心的网络环境。 本书适合计算机网络的开发、管理人员阅读,也可作为大专院校相关专业的教学参考......一起来看看 《图解TCP/IP : 第5版》 这本书的介绍吧!