移动版

主页 > 热点资讯 >

案例复盘:浅析数据统计APP的制作思路

案例复盘:浅析数据统计APP的制作思路

无论是C端还是公司内部用户,都可能会有数据统计的需求。我个人认为,单从产品层面上看,数据类的需求其实并非需要特殊的思路去解决,仍然和其他解决需求时的方法一致。唯一区别在于内容交互、布局方面,数据内容与其他图文内容的不同,大多体现在突出数据的查阅体验。

去年时做了一个公司内部数据统计的APP项目,整个项目前端并不复杂(但在后端几乎把整个电商部门的后台数据倒腾了个遍),这次给大家分享的整个项目中产品层面的一些经历、复盘总结。

用户的场景、需求

用户群角色

首先思考的是我接手的这个项目是面向哪些群体的,在需求讨论会上,我见到了各个业务部门的人,从职位角度归纳了一下,大体上可以分为:销售部(总部&地方)、B端客户部(总部&地方)、总部领导、地方分总等角色。为何从这个角度予以区分呢?是因为两点:1、公司内部一般而言职位相同,对数据的需要就会非常相近。2、公司后台中普遍使用的是这种角色区分维度,容易和后台底层接轨。

然后,不同的角色,意味着对数据的需求、权限是不同的。

用户群的需求

需求采集:由于是公司内部人使用,所以采集这类数据需求的方式就是比较简单直接,开会、私下邮件、当面讨论,即可确定下具体的数据需求项了。遇到大家不一致的地方,会把不一致的人员拉上来,开会进行讨论、辩证的分析:哪些数据是有意义的,有必要的,哪些是不需要的,可以初版不做,后期讨论的。

需求采集其实就是确定需求范围,比较类似于“体验五要素”中的“范围层”。

需求分析:其实在采集的过程中,多多少少能够感觉到需求方对数据项的重视程度了。再加上格外的需求分析这个阶段:对所需的数据进行重要程度分析、实现难度分析(也会和技术进行讨论),经过这一系列的分析,基本上心中大体有数了。哪些高频重要的、哪些低频次要的,哪些简单可做、哪些复杂延后……

需求决断:需求分析的结果一定是需求的判断、抉择,这也是分析的目的、意义。判断、抉择异常重要,它关系着后续产品经理跟进项目的整个大局。决断的结果,就几乎定下了后续产品经理需要多大的精力、成本去跟进项目的进展,项目周期多长,是否能满足领导的上线需求。所以,产品经理不妨也站在自己的角度上,该砍的需求,要毫不留情;该做的需求,要有心理准备;该豁出去时,要豁出去(顶着压力,短时间内加班加点完成项目)。

需求管理:数据这类需求,非常需要对其进行有条理的维护、管理,最好详细的列一个表格,记录数据的类别、逻辑含义、重要程度,面向角色,调取来源。这样的好处在于,以后数据出现问题,可以很好的翻箱检查,也可以在此基础上进行优化、迭代版本。例如:我个人的这次项目中最终确定下来的需求包括:楼盘项目数据、客源数据、财务相关数据。

案例复盘:浅析数据统计APP的制作思路

案例复盘:浅析数据统计APP的制作思路

系统层面的考虑

1、为了灵活配置数据指标,需要权限系统予以支持。可以将该功能纳入后台统一的权限管理系统中,不需要多余的开发。

2、由于大家需求不同,所以在权限中全部列出全部的需求数据项,然后业务人员为每一个角色进行勾选。

这样做的好处就是大大的提高了为角色配置数据指标的灵活度,另外就是减少了产品、研发的维护成本,勾选权限的任务交给业务部门来做。

功能流程、页面结构

整个需求阶段走完后,那么就是页面的流程、结构了。这个阶段强调的是把决断后的需求内容转化成一个可视化的流程、架构。这个阶段非常类似“体验五要素”中的“结构层”,但我个人的描述要比这个“结构层”更实用一些,更具有实践性(王婆卖瓜,自卖自夸 :-D)。

在这里,我想自问自答一下:为什么要把功能流程和页面结构放在一起思考?其实我个人理解,流程和页面是密不可分的。如果仅仅是脑中构思,一般而言可能是一个形象化的构思过程:把功能的入口放在哪里?先操作什么再操作什么?这样便捷度如何?整体流程乱不乱?页面跳转的多不多等等。功能流程必定会和页面结构息息相关。两者分开的话,容易思路不完整;综合考虑这两点,会更灵活、更快捷、全面。

重要思路过程: