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

　　作者根据自身的经验，描述了自己制作一款产品的主要过程，从中总结了一些经验方法与大家分享。
　　无论是C端还是公司内部用户，都可能会有数据统计的需求。我个人认为，单从产品层面上看，数据类的需求其实并非需要特殊的思路去解决，仍然和其他解决需求时的方法一致。唯一区别在于内容交互、布局方面，数据内容与其他图文内容的不同，大多体现在突出数据的查阅体验。
　　去年时做了一个公司内部数据统计的APP项目，整个项目前端并不复杂（但在后端几乎把整个电商部门的后台数据倒腾了个遍），这次给大家分享的整个项目中产品层面的一些经历、复盘总结。
　　用户的场景、需求
　　用户群角色
　　首先思考的是我接手的这个项目是面向哪些群体的，在需求讨论会上，我见到了各个业务部门的人，从职位角度归纳了一下，大体上可以分为：销售部（总部&地方）、B端客户部（总部&地方）、总部领导、地方分总等角色。为何从这个角度予以区分呢？是因为两点：1、公司内部一般而言职位相同，对数据的需要就会非常相近。2、公司后台中普遍使用的是这种角色区分维度，容易和后台底层接轨。
　　然后，不同的角色，意味着对数据的需求、权限是不同的。
　　用户群的需求
　　需求采集：由于是公司内部人使用，所以采集这类数据需求的方式就是比较简单直接，开会、私下邮件、当面讨论，即可确定下具体的数据需求项了。遇到大家不一致的地方，会把不一致的人员拉上来，开会进行讨论、辩证的分析：哪些数据是有意义的，有必要的，哪些是不需要的，可以初版不做，后期讨论的。
　　需求采集其实就是确定需求范围，比较类似于＂体验五要素＂中的＂范围层＂。
　　需求分析：其实在采集的过程中，多多少少能够感觉到需求方对数据项的重视程度了。再加上格外的需求分析这个阶段：对所需的数据进行重要程度分析、实现难度分析（也会和技术进行讨论），经过这一系列的分析，基本上心中大体有数了。哪些高频重要的、哪些低频次要的，哪些简单可做、哪些复杂延后……
　　需求决断：需求分析的结果一定是需求的判断、抉择，这也是分析的目的、意义。判断、抉择异常重要，它关系着后续产品经理跟进项目的整个大局。决断的结果，就几乎定下了后续产品经理需要多大的精力、成本去跟进项目的进展，项目周期多长，是否能满足领导的上线需求。所以，产品经理不妨也站在自己的角度上，该砍的需求，要毫不留情；该做的需求，要有心理准备；该豁出去时，要豁出去（顶着压力，短时间内加班加点完成项目）。
　　需求管理：数据这类需求，非常需要对其进行有条理的维护、管理，最好详细的列一个表格，记录数据的类别、逻辑含义、重要程度，面向角色，调取来源。这样的好处在于，以后数据出现问题，可以很好的翻箱检查，也可以在此基础上进行优化、迭代版本。例如：我个人的这次项目中最终确定下来的需求包括：楼盘项目数据、客源数据、财务相关数据。
　　系统层面的考虑
　　1、为了灵活配置数据指标，需要权限系统予以支持。可以将该功能纳入后台统一的权限管理系统中，不需要多余的开发。
　　2、由于大家需求不同，所以在权限中全部列出全部的需求数据项，然后业务人员为每一个角色进行勾选。
　　这样做的好处就是大大的提高了为角色配置数据指标的灵活度，另外就是减少了产品、研发的维护成本，勾选权限的任务交给业务部门来做。
　　功能流程、页面结构
　　整个需求阶段走完后，那么就是页面的流程、结构了。这个阶段强调的是把决断后的需求内容转化成一个可视化的流程、架构。这个阶段非常类似＂体验五要素＂中的＂结构层＂，但我个人的描述要比这个＂结构层＂更实用一些，更具有实践性（王婆卖瓜，自卖自夸:-D）。
　　在这里，我想自问自答一下：为什么要把功能流程和页面结构放在一起思考？其实我个人理解，流程和页面是密不可分的。如果仅仅是脑中构思，一般而言可能是一个形象化的构思过程：把功能的入口放在哪里？先操作什么再操作什么？这样便捷度如何？整体流程乱不乱？页面跳转的多不多等等。功能流程必定会和页面结构息息相关。两者分开的话，容易思路不完整；综合考虑这两点，会更灵活、更快捷、全面。
　　重要思路过程：
　　1、如果功能流程较多，可以画一下流程图。先画流程图，理清了功能步骤，有哪些页面大体也就会应运而生。如果还不能想象出页面，那么就再细化流程，直到细化到—这段流程就是一个页面的程度，不信页面的感觉出不来（:-D）。
　　2、大体页面的形成后，就是把页面进行组织、构架起来，形成：首页、列表页、专题页、详情页、结尾页、个人中心等等，也就初步勾勒出了页面结构。
　　思路的重点：
　　1、重要的、核心的功能流程是什么？页面上要予以突显出来。先构架出这个核心流程的页面。
　　2、功能流程转化为页面的思考顺序，一般无非是：入口、列表、详情、结尾、个人中心。具体的要具体分析。也会有些大类别的独立页面，例如：天猫，京东，有很多的类别是有独立的汇聚页。
　　3、需求的关联性，也会影响到功能流程、页面结构。如果需求是关联性强，那么页面结构上可能会更密切。反之亦然。例如：电商中的购物流程，社区分享流程。两大功能虽然都是用户需求，但两者关联性不强，可以互相独立一些，没必要流程、页面交错一起。
　　我个人的数据统计APP的功能流程和页面结构，比较简单，就是＂入口、列表、详情＂，涉及到后台的是权限管理界面。这个是现成的，只要加内容即可。
　　内容的交互、布局
　　这个阶段非常类似＂体验五要素＂中的＂框架层＂。在这里，就不过多的描述啦，相信大家都看过＂体验五要素＂中对这段的描述。另外，其实我个人有时习惯把这个阶段和功能流程、页面结构一起考虑，具体看个人吧，也看具体的项目量。
　　对于我个人的数据统计APP的项目，我也不做交互、布局层面的原由、逻辑分析了。把之前做的保真原型图，直接放上来：
　　下图是＂数据统计列表页＂， 功能定位：对所有关键指标一目了然，点击可进详情页。
　　下图是＂指标详情页＂，功能定位：通过走势图、不同维度排行榜，展示某一指标的全部信息。
　　下图还是＂指标详情页＂， 增加一个时间的交互，快捷日期选择一步到位：
　　本次就到这儿了，把所有的干货都拿了出来。大家有什么不同观点希望在评论中讨论一下。
　　同时欢迎阅读我的相关文章，值得你来~