后台|业务管理后台的设计方案( 三 )

在我负责项目中，接收的数据要求有：

推送及升级情况：包括推送和下载情况；
设备及分布情况：当前主流设备版本号、版本分布情况、在线设备数量；
任务及详细情况：单次升级包推送情况、单词任务成功率、失败及对应日志；

针对推送及升级情况这类数据：
在初始化项目时，一般我们都是需要有初步的数据源导入到平台中，因为从0-1的项目中，设备未激活，无法上报对应的数据，我们就无法发布任务推送到端上，所以是需要默认的数据源作为平台的基础数据；
而一般这类基础数据都会由车企或者tier1来提供，我们需要导入到平台中进行初始化；
有了基础数据，我们还需要定义好具体的数据指标，方便项目交付后的验收，呈现的数量虽然能满足车企的诉求，但不够直观，所以一般我们还是需要定义具体指标；
如推送成功率=下载成功量/成功推送量等；
针对设备及分布情况这类数据：
这类数据需要基于客户端下载的情况进行上报，如设备在接收到软件包升级时，需要在升级成功时同时上报升级结果、当前版本，如果涉及到地区分布需求，还需要上报经纬度，然后后台进行推演按照地区或者省份进行展示；
针对任务及详细情况这类数据：
任务对于每次的ota都是至关重要的部分，需要准确记录每一个VIN码的升级情况（VIN码、升级成功与否、推送成功与否等），任务的推送情况及错误日志上报
另外任务的详细信息也许准确在后台上做展现，方便后续的维护和迭代运营；
四、填坑经验分享最后我就以个人的经验分享“坑”，方便大家避避雷；
坑一：平台审批权限不够细分
一般权限分几种：操作权限、菜单权限、数据权限和用户权限；
【后台|业务管理后台的设计方案】我遇到过之前有个平台只有菜单权限，整个平台中只要具备菜单的权限就可以进行操作，细分颗粒度不够，导致管控的力度比较粗；
这样导致的后果，就是无法有效的管理用户的操作和数据泄密的问题，而且如果还没有操作记录功能的话，那完全无法知道是谁做了哪些操作，追溯起来十分麻烦；
坑二：交互方式不太符合主流
一般而言，平台化的交互模式都是自上而下，模块放置左侧，右侧放置模块内容信息，并且以列表的形式呈现；
这样的结构符合用户的习性和查看习惯，如果刻意追求标新立异的模式，如从左到右的模式，就有种画蛇添足的感觉；
如之前接触过一个平台顶部放置功能栏，左侧放置数据报表和数据，右侧放置模块内容信息，整个交互即让人眼花缭乱，交互起来又经常出问题；
另外平台需要注意尽量不要出现以下几点：

弹框之后再出现弹框；
不知道操作路径在哪里，即用户无法知道进入的是二级还是三级；
能用弹框就用弹框，不要轻易新增页面；

以上就是本文的全部内容，希望能在业务管理后台的设计上提供一些建议和帮助！
本文由 @SiegZhong 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自Unsplash，基于CC0协议。