为什么你的城管小程序用不起来？问题多半出在这

前阵子跟一个做城管的甲方聊天，他跟我吐槽：去年花了几万块找人做了个城管小程序，上线三个月，日活不到20个人，一线执法队员宁愿在微信群里发照片，也不用这玩意儿。我问他，你们当初提需求的时候，有没有让真正上街巡查的人参与？他愣了一下，说主要是领导定的方向。

这个场景我太熟了。做软件定制开发这些年，我见过太多"看起来很美、用起来很废"的政务类小程序。城管这个场景尤其典型——它不像电商小程序那样用户有天然的使用动机，也不像内部OA那样有行政强制力。它卡在中间：既要给一线队员用，又要给领导看数据，还要面对商户和市民。三方需求拧在一起，最后做出来的东西谁都不满意。

我先说一个最容易被忽略的点：城管队员的使用场景，跟办公室里的人想象的完全不是一回事。他们一天到晚在街上走，夏天手机屏幕反光看不清，冬天戴着手套点不准，很多时候是单手操作，另一只手还拿着对讲机或者文书。你给他设计一个需要三级菜单才能上报问题的流程，他凭什么用？我见过一个项目，上报一个占道经营，要先选大类、再选小类、再填位置、再拍照、再写描述，七步。微信群里发张图加一句"XX路有摊"，两步搞定。你说他选哪个？

所以问题多半出在第一步：需求调研的时候，把"管理者想要的"当成了"使用者需要的"。领导关心的是案件闭环率、响应时长、数据看板；队员关心的是能不能三十秒内把事报上去、能不能少填几个必填项。这两者不是对立的，但如果你只满足前者，后者就会用脚投票。我的经验是，做这类小程序，功能清单要让一线班组长过一遍，让他们拿真实工单走一遍流程，走不通就砍。

第二个坑，是定位和地图。城管巡查有个特点，很多问题发生在路上、在巷子里、在工地边上，GPS漂移是家常便饭。我做过一个项目，队员在桥下上报，定位直接飘到河对岸，工单派给了隔壁中队，两边扯皮半天。后来我们做了个很土但很有效的处理：允许手动拖拽纠偏，并且把"定位不准"做成一个可反馈的按钮，后台能看到哪些区域漂移严重。这玩意儿不高级，但队员觉得"这软件懂我"。很多时候，体验的改善不靠炫技，靠的是承认现实的不完美，然后给个兜底方案。

第三个坑更隐蔽：数据只进不出。队员辛辛苦苦报了一堆案件，结果呢？除了月底考核被拿出来说"你这个月上报数量不够"，平时看不到任何反馈。人是要正反馈的。你报的问题解决了没有、谁处理的、花了多久，这些信息如果能在小程序里回显给上报人，他下次就愿意报。我见过一个做得不错的案例，他们在工单状态变化时给上报人推一条简短消息，就一句话："您上报的XX路井盖问题已修复"。就这么个动作，重复上报率降了不少。技术实现上一点都不难，难的是产品设计时有没有把"闭环"当回事。

还有就是性能。城管小程序往往要传大量现场照片，有的队员一次传九张，网络还是4G。如果图片不做压缩、上传不做断点续传，在信号差的地方就是转圈转到天荒地老。我们后来统一做了前端压缩加队列上传，弱网下先存本地，有网了自动补传。这些细节在需求文档里通常不会写，但恰恰是决定"用不用得起来"的关键。做软件定制开发，尤其是面向一线人员的工具，性能优化不是加分项，是及格线。

说到这儿，可能有人会问：那到底该怎么改？我的看法是，别一上来就想着大而全。先挑一个高频、痛点明确的场景做透，比如"随手拍上报"或者"巡查打卡"，让队员先用顺手，再逐步加功能。权限和角色也要想清楚，队员、班组长、中队内勤、领导，看到的东西应该不一样，别让所有人都面对同一个复杂的首页。另外，后台的数据看板别只给领导看，把队员个人的上报统计也开放给他自己，让他知道自己的贡献被记录着。

我们枫泽云创这几年在无锡及周边做软件定制开发，接触过不少城管、物业类的移动端项目。说实话，这类项目技术难度不算高，难的是把业务流程吃透、把使用者的真实处境摸清楚。我们团队五十来个人，做过的两百多个案例里，凡是上线后真正跑起来的，无一例外都是甲方愿意让一线人员深度参与前期设计的。工具是给人用的，人不对，再好的架构也白搭。

最后说句掏心窝的话：城管小程序用不起来，八成不是技术问题，是产品思维的问题。下次立项之前，别急着画原型，先去街上跟着队员走半天。看看他们怎么掏手机、怎么拍照、怎么跟商户说话。那半天看到的东西，比十页需求文档都值钱。