欢迎光临
我们一直在努力

如何更好的去分解功能点:产品经理的日常

如何更好的去分解功能点:产品经理的日常

在日常工作中,都会接触到一个个的需求,通过需求分析。我们通过建立一套解决方案去满足需求的实现。再去细化的话,就是将这套解决方案拆分为一个个的功能点。在这里,我们要讨论的就是对功能点进行分解,更好的去将其表述出来。

为了把功能点尽可能的表述清除,其实很多PM都会有自己的一套思维方式,下面,我对自己的思维方式进行的总结。首先,在确定了功能点后,我就会从最顶层的界面层出发, 然后是用户操作层,接着是数据层,这样由浅到深的去将一个功能点逐步的拆解。

下面,我会罗列出自己在撰写功能点的时候,对功能点说明进行遍历的问题:

首先是界面层:

说到界面层,最基本的就是先想到控件类型,这里展开一个题外话,就是很多人都会去问产品需不需要懂技术,其实,这个问题,用最基本的控件概念来回答的话,就是:在App端或者是 Web端的产品,每个控件其实都会一个技术术语,如TextView、Webview,在进行设计的时候,能够对实现所需的控件有一定的概念的话,到达这种程度的话,其实就挺OK的了。毕竟,懂技术,更多是可以在进行方案的设计时,判断其可行性及预见实现出来后的具体效果。

嗯,我们再把话题扯回来,在决定使用的控件类型后,界面会涉及到的就是控件尺寸、形状、字体大小、颜色、文案(视乎控件类型有所不同)、响应动画(这个里面包含动效这个大boss,这里就不展开说明了)、位置(功能点处于产品的什么模块、什么位置)、引导文案(即引导用户更好的完成操作的,包括新手引导,也可以归类到引导文案中)、限制条件(例如手机号码输入框只能输入数字)。

然后就是,用户操作层,即用户是怎样对当前的界面进行操作,及操作的反馈有哪些:

1、进行操作的用户有哪些?这个的话,前台不会有很大的区分,基本都是大众用户(当然,电商类会有买家和卖家的区分)。对于后台类产品来说,这个维度更多是用来思考 有哪些角色,对该功能点是否有访问及操作的权限。

2、操作的对象是什么?比如设计注册表单时,里面的输入框就是操作的对象。

3、怎样对 对象进行操作?这里可以细分为操作方式、操作行为。操作方式是指点击、双击or Sth Else、这个就比较简单,就是操作方式的说明。但是,对于处于可触摸屏幕的产品 来说,就会有思考的点就是,手势操作及日常操作的取舍。操作行为的话,举例来说,就是该对象是可点击的,则用户是正常的去点击一下,还是不断的不点奔溃不罢休~最经典的例子就是 Web端对按钮不断的重复点击这种用户行为~

3、操作的反馈是哪些?在这点上,主要是正常流程及异常流程下的不同反馈,反馈的产生形式各种各样,比如弹窗、警示语、页面切换等等,这里就不穷举了,具体问题具体分析即可。

4、操作是否可逆? 最常用的可逆操作就是后台的管理功能,冻结账号or解冻账号

5、操作对功能点对应模块的影响?在这里,我们策划的是功能点,在保证功能点的逻辑齐全外,也要考虑到该功能的操作对当前模块的其他功能点是否有影响~

6、操作对功能点对应模块及其他模块之间的影响? 比如策划电商产品的支付功能时,用户完成支付后,用户中心的站内信模块,会通知用户支付结果。

7、操作对功能点对不同版本之间的影响? 这点的话,更多是成熟类的产品才会存在的问题。最经典的场景就是,上线新功能代替旧功能时,旧版本的处理问题,这个可以去查看具体的数据,进行取舍来解决。

最后,就是产品比较底层的数据层了,这里我们会区分两种维度去梳理,后台从前台获取的信息,系统会如何去处理。然后就是前台从后台读取的数据,系统会对数据进行怎样的处理:

A、从前台获取的信息

1、获取的维度分两种:用户输入、前台上报,如果是用户输入的方式,就要思考这些数据是否进行存储?例如,历史输入数据的存储,如果是要存储的话,存储的方式是什么?另一方面,前台上报的方式,更多是行为数据及运营数据的统计

2、数据的传输,就要去思考这些数据是不是敏感数据,是否需要进行加密处理?具体的传输方式是即时传输、定时传输还是分段传输呢?这个就需要PM和技术大大去商量了

3、数据的存储,这个会分两种:本地存储、后台存储,本地存储的话,最多的场景就是输入历史的本地存储,后台存储的话,就不展开说明了~

B、前台读取的数据

1、要显示的数据,读取的来源在哪里?是数据库,还是其他模块传递过来的数据?

2、如果是需要进行数据的传输,这些数据是不是敏感数据,是否需要进行加密处理?

3、数据是否需要缓存,这个也是和技术大大商量即可~

4、读取的数据是否需要显示?如果是需要显示,是直接显示即可,还是要通过处理才去显示?比如某些敏感信息在前台进行显示时,一般会进行字符串转换之后,才进行显示。如果是读取的数据不需要显示,那是需要传递到什么地方吗?

写到这里,就从界面、操作、数据这三种维度来对应说明了思考的思路。其实,文章一路写下来,更多是响应了一句话:产品在理需求的时候,更多是从最顶层出发,逐渐向底层去分析,而开发大大更多是,从底层开始构造,根据需求文档,一步步的往顶层去实现。

这次主要从产品最基本的功能点入手,说明了如何去拆解

作者:Yoic,产品汪,偶尔写写总结,温故而知新。个人微信:303909359

赞(0)
未经允许不得转载:电商之家 » 如何更好的去分解功能点:产品经理的日常

登录

找回密码

注册