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

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