高速公路工程水土保持全过程管控系统
校企合作项目,从 0 到 1 主导产品方案与前端落地,审批效率提升 70%,数据错误率由 12% 降至 1%
一、项目背景
高速公路工程穿越山地丘陵等水土流失敏感区域,依据《水土保持法》须在工程全周期开展水土保持管控。传统模式下,建设、施工、监理、监测、验收等多方主体协同依赖线下手工记录与纸质流转,存在明显痛点:
1. 审批耗时长:水土项目材料需经多单位多岗位审批流转,线下多单位平均流转 3-5 天,影响项目进度。
2. 数据混乱:施工台账、监测数据、验收资料分散在各参与方 Excel 与纸质件中,版本不一、易丢失且管理混乱,数据错误率高达 12%。
3. 信息不对齐:各主体掌握的工程状态不同步,预警信息滞后,常在问题发生后才被发现。
二、核心职责
作为项目组长兼产品、前端,统筹项目全生命周期,承担以下五项核心职责:
2.1 需求调研
深度参与企业员工访谈,覆盖建设、施工、监理、监测等多角色岗位,从一线真实工作流中提炼出审批慢、数据乱、信息不对齐三大核心痛点,并输出需求清单与业务流程图。
2.2 产品方案设计
设计系统整体功能架构,明确六大功能模块与数据流向;输出完整 PRD 文档,并使用 Figma 完成高保真原型,作为研发与评审基线。
2.3 前端开发
基于 Vue2 + ElementUI 负责核心前端实现,主要包括:
- 搭建基于角色的动态路由,实现八类用户差异化菜单与页面权限;
- 配置 ECharts 可视化预警图表,实时展示施工指标与阈值对比;
- 协调后端接口联动,主导前后端联调与数据契约定义。
2.4 测试优化
组织 2 轮 Beta 测试,收集 20+ 名员工真实反馈,迭代优化 12+ 功能点,涵盖表单交互、预警规则、权限边界等关键场景。
2.5 项目管理
统筹项目全生命周期管理,牵头对接企业部署上线;输出标准化使用手册,并负责员工赋能培训,保障系统顺利落地使用。
团队协作机制:项目启动前输出明确的里程碑计划;每周组织1次会议同步当前任务进度;遇到UI/前端/后端不一致时由我牵头拉对齐会并做决策。我的协作风格偏向'文档先行+快速闭环'——先写PRD定基线,再有风险小步快跑迭代,避免反复返工。
三、系统功能模块
系统围绕"数据—预警—协同"三条主线,划分为六大功能模块,覆盖水土保持从方案到验收的完整闭环(可点击左栏模块导航查看各模块说明与界面截图)。
3.1 中心数据库管控
以中心数据库为底座,串联水土保持方案、工程设计、工程施工、专项验收四大阶段,实现各阶段数据可追溯、可对比,打破参与方之间的信息壁垒。
3.2 实时预警系统
系统将现场施工数据(如扰动面积、弃渣量、防护措施进度)与控制中心设定的目标阈值实时比对,一旦超出阈值即自动触发预警,按责任归属推送至对应岗位,将"事后补救"转为"事前干预"。
3.3 文件上传模块
针对施工现场网络不稳定场景,文件上传支持本地暂存,待网络恢复后一键提交。同时引入路由后置守卫,在用户未保存即试图离开时进行拦截确认,避免录入数据丢失。
3.4 动态路由权限
基于用户角色动态生成路由表,登录后根据后端返回的权限标识addRoutes动态挂载可访问页面,菜单与页面双重校验,详见第五章权限矩阵。
3.5 数据可视化
采用 ECharts 构建实时预警看板,包括阈值对比柱状图、趋势折线图、风险分布地图等,帮助管理者一屏掌握全局水保管控状态。
3.6 响应式适配
系统兼容 PC 端与小程序端,施工现场巡查人员可通过小程序实时上传照片与数据,回传中心数据库,实现"现场—中心"数据闭环。
四、技术选型与实现
基于校企合作 B 端场景对稳定性与开发效率的双重要求,技术栈选型如下:
| 层级 | 技术 | 选型理由 |
|---|---|---|
| 前端框架 | Vue2 | 2023年项目启动时,Vue3生态对ElementPlus的部分B端组件支持仍不够稳定,Vue2+ElementUI对中小型B端项目是经过大量实战验证的成熟组合,团队熟练度高、风险低。 |
| UI 组件库 | ElementUI | 表单/表格/弹窗组件完备,契合数据密集型后台 |
| 后端框架 | Springboot | 快速构建 RESTful 接口,便于前后端分离联调 |
| 数据存储 | MySQL | 关系型存储保障业务数据一致性与事务可靠性 |
| 数据可视化 | ECharts | 灵活的图表配置,满足实时预警与多维度看板需求 |
五、动态路由权限设计
系统面向八类用户角色,按业务职责划分功能权限。登录后后端返回角色权限标识,前端据此动态生成路由与菜单,实现各类角色专属访问控制。
| 用户类型 | 中心数据库 | 实时预警 | 文件上传 | 工程施工 | 水保验收 | 系统管理 |
|---|---|---|---|---|---|---|
| 建设单位 | 查看 | 查看 | 编辑 | 审批 | 发起 | — |
| 编制单位 | 查看 | 查看 | 编辑 | 审批 | 发起 | — |
| 设计单位 | 查看 | 查看 | 编辑 | 编辑 | — | — |
| 施工单位 | 查看 | 查看 | 编辑 | 编辑 | — | — |
| 监理单位 | 查看 | 查看 | 审核 | 审核 | 参与 | — |
| 监测单位 | 查看 | 编辑 | 上传 | 查看 | 参与 | — |
| 验收单位 | 查看 | 查看 | — | 查看 | 审批 | — |
| 系统管理员 | 查看 | 查看 | — | 查看 | 监管 | 管理 |
六、项目成果
系统上线后,在水保审批效率与数据质量两个核心维度取得显著成效:
| 指标 | 系统上线前 | 系统上线后 | 变化幅度 |
|---|---|---|---|
| 单次审批时长 | 3-5 天 | 数小时 | 效率 +70% ↑ |
| 数据错误率 | 12% | 1% | -92% ↓ |
| 信息同步方式 | 线下纸质流转 | 中心库实时共享 | 信息对齐 ↑ |
| 预警时机 | 事后发现 | 事前实时预警 | 风险前置 ↑ |
成果归因:
效率提升归因:流程线上化(消除线下跨单位签字跑腿)+并行审批改造(原串行改多人可同时审批非依赖节点)。
数据质量提升归因:中心库统一纳管(淘汰各单位Excel分散存储)+表单校验规则(防止脏数据提交)+预警规则可视化与邮件事前拦截。
预警规则机制说明:系统的预警逻辑基于'编制值vs施工值'的对比——编制单位在工程前期填报各类水土保持措施的编制值,系统在多家施工单位填报施工值时自动累计比对,一旦施工值累计超过编制值设定阈值,即触发邮件预警给建设单位、监理单位、施工单位三方,实现事前拦截而非事后追责。
七、项目复盘与反思
做得好的地方:
- 从需求调研切入,先厘清"审批慢、数据乱、信息不对齐"三大痛点,再反推功能架构,避免功能堆砌;
- 动态路由权限设计前瞻,八类角色权限矩阵一次性规划,后续新增角色无需重构;
- 2 轮 Beta 测试 + 20+ 员工反馈形成闭环,12+ 功能点迭代有据可依;
- 兼顾 PC 端与小程序端,贴合施工现场真实使用场景。
不足与改进方向:
- 预警规则以静态阈值为主,未引入基于历史数据的动态阈值,存在误报可能;
- 文件上传的断点续传能力较弱,弱网大文件场景体验仍有优化空间;
- 权限矩阵未做细粒度字段级控制,部分敏感字段依赖前端隐藏,安全性可进一步加固;
- 数据可视化看板缺少自定义配置能力,后续可开放给管理者自定义指标组合。
协作中的一次典型挑战:
前后端对齐接口时,发现对同一产品需求存在认知偏差——不同单位在审批流程中有不同的先后顺序与不同的权限操作按钮,复杂的业务流程让前后端对'谁先审、谁能改、谁只能看'的理解不一致。
我的解法:
①第一时间拉产品、前端、后端三方对齐会,梳理三方对需求的理解差异;
②对于需求无法直接实现的矛盾点,我基于业务流程图重新拆解,找到'业务必需'与'技术可实现'的交集;
③带着两版可实现的替代方案与共识结论,与甲方对齐确认最终方案;
④确认后更新PRD与接口文档,作为后续开发的基线。
这次经历让我形成了一套协作方法论:'发现分歧→三方对齐→提炼替代方案→与甲方共识→文档留痕',后续在多个复杂需求场景中复用有效。