案例分享 | 定点投放的共享资产怎么做运维呢？
上一篇文章和大家分享了共享单车管理系统的大体构想，并简单描述了一下资产管理的思路；今天和大家聊一项有意思的业务——共享单车巡检，可能看过上一篇文章的朋友们会有所印象。
今天呢，还要告诉大家一个重要的业务背景，那就是笔者所在的公司不是市面上主流的几大共享单车企业（摩拜、哈啰等），而是以社区为主要投放场景的共享单车；这里给大家道个歉，不是刻意隐瞒哈~
一、业务背景
1. 投放场景
- 人车分离的封闭式小区；
- 桩+车的组合；
桩，通电，联网，蓝牙（扫描模式），下文简称“蓝牙桩”；
车（车锁），联网，蓝牙（广播模式），在蓝牙桩范围内锁车结束计费。
2. 业务描述
封闭式小区投放的共享单车和城市中哈啰单车的投放模式有所区别，我们暂且称呼“哈啰、摩拜”单车的投放方式为开放式投放，社区定点投放的方式为“封闭式投放”吧。
“开放式投放”的共享单车，由于运营的区域相对开放且较大，对于一线运维最主要的工作可能是调度和检修；而对于“封闭式投放”的社区单车，主要工作就是需要运维人员定期定点的巡检来保证资产的正常运行和安全了。
而巡检工作产生的数据，又可以作为管理人员和运营人员对指导下一步工作的有效参考。
- 运维人员需要每日对社区内的车辆巡检工作，确保投放车辆设备的正常运转和资产安全；
- 巡检结果生成的数据将作为考核地方运维的重要数据；
- 巡检结果所展示的资产情况将作为重要的运维工作参考。
3. 管理需求
对于一线运维小伙伴来说，这项日常工作配套的功能可能只是个工具而已；但是对于管理者来说，需要通过这个功能来实现对一线运维同事的监督与考核，而监督和考核的目的，就是让认真做事的员工能够脱颖而出，让偷奸耍滑的人无处可藏。
另外也可以通过这个功能来增加运维巡检的真实性，从而得到的巡检数据就越真实，而真实的数据对集团运营起到的作用无需多说了吧，这也是这个功能的重要价值。
- 真实记录每日巡检的社区；
- 真实记录巡检到的车辆；
- 巡检情况后台可视化。
二、设计过程
少啰嗦，直入主题
1. 用户角度
从上一段的描述可以知道，这个功能的主要用户有两个，“管理用户”、“运维用户”：
- “管理用户”主要用于后台查看运维数据和巡检单的简单管理；
- “运维用户”主要用于移动端操作资产巡检。
后台端：
- 角色：运维管理
- 功能：数据查看
移动端：
- 角色：一线运维
- 功能：车辆巡检
2. 后台端
对于后台端来说，分了3个界面：
- 【巡检单管理】：查看具体的巡检单详情，不可对巡检单做其他操作；
- 【巡检单统计（按人员）】：对一线运维人员的巡检结果以“人员”维度做的统计；
- 【巡检单统计（按城市）】：对资产投放的城市以“城市”维度，且作为最小粒度做的统计；
功能界面：
【巡检单管理】
【列表】：
【详情】：
【巡检单统计（按人员）】
【列表】：
【数据算法】：
【巡检单统计（按城市）】
【列表】：
【数据算法】：
3. 运维端
逻辑：
为了方便一线运维作业，巡检工作没有固定线路，所以“巡检单”没有以任务的形式去搞；而是采用了比较灵活的方式，这也是充分和一线的管理人员沟通之后采取的当时比较合理的方式了。
第一步，运维人员打开运维移动端，进入【巡检管理】功能界面：
第二步，在移动端【巡检管理】页面可以查看当前自己创建的巡检单，根据创建时间降序，并需要在当前页面点击【新建+】创建新的巡检单。
功能界面：
第三步，在【新建巡检单】页面，选择自己负责的社区。
功能界面：
第四步，在打开的【巡检单】页面按照要求操作巡检。
功能界面：
【操作界面】
【巡检中】：
第五步，查看已完成巡检单（第二步点击查看同理）
功能界面：
4. 运维端完整流程
三、收笔
到此为止，这块功能就给大家讲完了，全过程没有设计太多复杂的东西；上文给大家讲到“巡检单”为什么要用这种方式，明明是任务形式的，为什么还允许自由创建；自由创建了，为啥还有一天只能创建一条等等的要求。
这里，笔者要给大家讲的，是我们在根据业务设计产品的时候，完美的业务逻辑和产品固然重要；但也要考虑实际的应用场景，以及应用团队的实际情况（不要给实际使用人员添乱）——就是在不降低人效的情况下，保证业务产品的逻辑完整和易用性是很重要的。
最后，To B，加油！
本文作者 @橙子哥哥
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
