立即登录 共享单车早已成为日常的一部分，出门扫一辆就走，社区门口、街角路边随处可见。但很少有人想过，那些海量投放的单车，平时是怎么维护和检查的？今天聊一个具体的实操案例——社区场景下的共享资产巡检。
先交代下背景。上篇文章介绍过共享单车的管理系统框架和资产管理思路，今天要深入的是"巡检"这个业务。不过得说明白：这里说的不是哈啰、青桔这类头部品牌，而是以封闭社区为主要场景的小型共享单车项目。之前没展开讲，并非故意藏着，这点先道个歉。
这个项目的投放场景很典型：人车分离的封闭小区，采用"桩+车"组合。桩通电、联网、带蓝牙，扫码就能用；车本身也联网、带蓝牙，广播信号，进入桩的蓝牙范围即可锁车计费。和城市里的开放式投放不同，社区场景是封闭定点模式——哈啰那种叫"开放式投放"，社区这种叫"封闭式投放"。
开放式投放面积大、范围广，运维以调度和维修为主；封闭社区小得多，核心工作是定期定点巡检，保证设备正常运转、资产不丢失。巡检数据还有另一个作用：为管理者提供决策参考，指导后续工作。
具体业务说起来就几句话：运维人员每天巡社区、查车辆，确保设备正常、资产安全；巡检结果既用于考核一线运维，也能反映资产状况。管理上的需求更深一层：对一线运维而言，这是干活的工具；对管理者来说，这是监督考核的抓手——让认真干活的冒出来，让偷懒的藏不住。同时，巡检真实性也得靠系统保障，数据越真实，对集团运营的价值越大。
最终落到纸面上的需求就三条：每日巡检社区的真实记录、检查车辆的真实记录、后台可视化呈现。
直接入正题。这个功能有两类用户：管理用户和运维用户。管理用户在后台看数据、管巡检单；运维人员在手机端跑现场、做巡检。
后台端分了三个界面："检查单管理"，查看具体巡检单详情，纯浏览，不可修改；"检查单统计（按人员）"，以人为维度统计每个运维工的检查结果；"检查单统计（按城市）"，以城市为最小粒度统计各投放城市的数据。算法逻辑就不展开了，主要是统计口径的设计。
运维端的逻辑值得多说两句。为了照顾一线操作的便利性，巡检没有做成固定线路的任务模式，而是采用了更灵活的方式——这是跟一线管理人员反复沟通后的结果。流程走下来五步：打开运维App进入巡检功能；在巡检管理页查看已有巡检单，按创建时间倒序排列，也可点"新建"开新单；选择负责的社区；在巡检单页面逐项检查；查完的可随时回头查看。整个流程串下来，形成完整闭环。
这个功能做下来，整体没搞太复杂。前面提到的"为什么不用任务形式而允许自由创建""自由创建了为什么一天只能建一个"——这些看似矛盾的设计，其实都是在业务逻辑和实际场景之间找平衡。
做B端产品时常遇到这种事：业务逻辑要闭环，但实际使用者是人，得考虑团队的现实情况。不能为了系统完美，给一线添不必要的麻烦。目标很明确：保证业务逻辑完整、产品好用，同时不降低人的效率。
To B这条路，继续走吧。
