? ? 不知不觉在家里都关了一个多月了,作为一个普通人,在武汉疫情期间即使是在家待着心情还是挺焦急的。于是结合自己小区的实际情况,我决定用我的一些专业知识(程序员)来就“小区团菜较混乱”的问题,略尽一份绵力。

一、分析小区团菜现状

? ? 经前期观察发现小区团菜流程是这样的:

  1. 由社区、物业人员或志愿者(以下简称物业人员)联系好商家,获取商品套餐信息
  2. 物业人员简历相应的团菜微信群,或直接在现有的团菜微信群中发布菜品套餐信息供业主选择
  3. 物业人员发起团购接龙,有需要购买的业主在微信群内接龙自己的套餐订购信息和个人信息
  4. 物业人员在接龙结束后统计人数及购买情况,并发起收款
  5. 将所收集到的菜款付给商家,等待菜品配送
  6. 待菜配送到小区后,根据最终付款结果,物业人员通知已购菜业主分批次下楼领取已购菜品
    ? ? 流程是这么个流程没错,但是在实际操作上却问题不断。

? ? 首先,物业人员一开始仅通过微信群自带接龙工具进行报名接龙。该工具在百人群内的表现堪称“灾难”。当物业人员发布了菜品套餐信息并开始接龙时,往往会有几十上百人同一时间开始点击接龙,而该工具并没有并发控制,以至于每个人填写完接龙信息并发出来之后,往往会出现:顺序不一致、漏缺信息等问题。而且该工具每接龙一次,就会在群内自动发送一条包含有前人所有接龙信息的文字。所以在接龙开始后,往往短时间内群内会出现“信息风暴”,群内消息瞬间99+,大量重复内容的复制发送会瞬间淹没群内正常发布的信息。

? ? 其次,鉴于上述工具所有人的团菜信息均在群内明文发送,故有个人信息泄露的隐患。这可能直接导致领菜时,你家的菜被人给冒领。

? ? 第三,每次接龙后,物业人员在统计、补漏、付款等工作环节均会耗费大量人力物力。前期我们小区物业团的3次菜,每次都需要物业人员花费2小时以上的时间去做报名统计。

? ? 第四,物业人员在菜品分发环节,受限于人力有限,每次发菜时都会出现个别业主菜被人冒领的事情。物业人员费时费力为大家团购一次菜,最后还要自己掏钱出来赔的闹心情况时有出现。

二、如何改善

? ? 针对上述发现的问题,我们需要逐个解决。

? ? 最大的问题就是在疫情期间物业人员人手完全不够。除开看守大门、垃圾转运、消毒的工作人员之外,平时帮助我们团菜的物业人员只有2人,且她们还身兼数职,往往熬夜整理完群里的团菜信息后,第二天清早又要去大门口值班。工作十分辛苦但是效率较低。解决该问题的最好办法就是招募志愿者,于是我报名参加了社区志愿者,帮忙物业人员处理团菜的一些事情。

? ? 对于上述的接龙工具问题,好在微信小程序中出现了不少已经开发完毕的成熟的接龙工具。在我的建议下,物业人员更换了一款带有:导出报名表格、隐藏用户信息、支持在线付款的微信小程序。每次开始团菜时,物业人员会将小程序链接发在群内,让业主们在小程序上填写自己的购菜信息,并完成付款。事后物业人员直接导出表格即可完成团购统计。在发放蔬菜时,根据导出表格发放。

三、意外情况

? ? 按照以上措施操作,理论上来说是不应该出错的,但是在上周团菜时,依旧出现了蔬菜分发的问题 —— 又有几位业主反馈说自家的菜被人冒领了!

? ? 事后大家一起总结问题时发现问题可能就出在“人”上。

? ? 那次团菜小区内共有124人参与团购,而物业人员仅在一张A4大小的纸上打印出了所有业主的购买信息,在分发时,密密麻麻的文字可能让物业人员看串了行。其次,因临时有事,中途换了一位阿姨过来帮忙发菜,但是她却没有按照要求通过核对领菜人的手机号码发菜,而是仅核对了领菜人姓名。但是根据群内订购信息公示表,领菜人的姓名是大家都可以看到的公开信息。第三就是可能因为人性的“贪”,拿了说没有拿到。然后白吃蔬菜不给钱。

四、改进方案2.0

? ? 诚然,在如此高强度的工作下,物业人员难免会有疏漏,特别是应对密密麻麻的数据时,看花眼也是很可能出现的事情。作为常年和电脑打交道的人,我自然而然地想到:对于这种根据特定条件发放物资这种不用用脑子变通的事情,用电脑来做肯定要比人更合适。于是在现有情况的基础上,我开始考虑在尽量不增加业主和物业人员工作量的情况下,针对订购蔬菜的核发流程做一些优化设计,旨在利用机器解决问题。

? ? 发菜流程设计如下:

发菜流程设计

? ? 考虑到下批团购菜也即将分发,上述流程图仅为一个简易实现思路。于是我花了一下午时间大致完成了符合上述流程的系统开发。

? ? 服务端采用Springboot Web技术,配合MySQL数据库快速开发完成相应的数据库表设计与服务端接口。安卓App采用Android Studio自带的Bottom Navigation Activity模板先直接生成了一个App框架,然后后续具体功能再自己完善。
安卓1

五、技术细节

? ? 服务端数据库设计上,考虑到原始数据来源为导出的excel表格,而表格上传可能会因为种种原因有多次上传的情况。这里默认把每次上传的excel数据都会创建为一张新的数据库表,每次默认激活的为最新生成的数据库表。这里我选择MyBatis作为ORM框架,并编写SQL语句动态创建表

<update id="createNewTable" parameterType="java.lang.String">
        CREATE TABLE ${tableName} (
        `id` int NOT NULL AUTO_INCREMENT ,
        `order_id` int NULL ,
        `wechat_name` varchar(50) NULL ,
        `real_name` varchar(50) NULL ,
        `phone_no` varchar(11) NULL ,
        `commodity` varchar(255) NULL ,
        `sign_up_time` varchar(20) NULL ,
        <!---1:未付款;0:未领取;1:已领取-->
        `status` int(1) NOT NULL DEFAULT -1,
        serial_number int(12) NOT NULL DEFAULT 0,
        update_time varchar(20) NULL ,
        PRIMARY KEY (`id`)
        )
        ;
    </update>

? ? 为了效率,服务端自助生成二维码的功能并没有自己利用依赖包生成,而是使用在线生成二维码接口API实现的该功能。

? ? 同样为了保证效率,安卓端也直接使用了大量的开源组件:

个人开发的部分主要在于使用OKHTTP3与服务器进行接口数据通信,使用Google GSON进行JSON解析。

六、界面样式

? ? 为了适配移动端,服务端的自助二维码生成页面采用了CSS3的自适应样式布局

自助生成二维码页面图
自助生成二维码页面移动端适配图

? ? 而安卓端这边,因为有Google官方模板和好看的Sweet Alert Dialog的加成,所以长相还过得去~ (#.#)

自己没啥时间整ListView样式了,所以就简单做了下布局。大概就长这样吧~? _ ~

安卓App UI图

? ? ? ? 最后把服务端挂在阿里云上跑着就行了。因为我们小区物业的工作人员电脑操作不太熟,所以excel上传的工作自然就是我来做了,不然这个系统应该是能不需要我干预就能完全自助运行的。

? ? ? ? 目前系统稳定地支持了一次物业团菜,果然没有人的菜再被冒领了~~? 后续有时间我再做一些小优化嘻嘻 (#.#)

(等完善一下,疫情结束后在开源吧)


孤独的摸鱼癌晚期患者