175 lines
12 KiB
Markdown
175 lines
12 KiB
Markdown
|
---
|
|||
|
|
title: 需求整理（持续更新）
|
|||
|
|
mdate: 2026-03-18 20:28:47
|
|||
|
|
mdevice: iPad
|
|||
|
|
doc_id: 204168cc4c3244b992d2f7e45ca44e15
|
|||
|
|
date: 2026-03-18 20:27
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 需求汇总
|
|||
|
|
|
|||
|
|
## 1. 线路与排班需求
|
|||
|
|
|
|||
|
|
### 1.1 线路结构优化
|
|||
|
|
|
|||
|
|
**现状**：原系统运营线路是单段设计，即【起点-口岸-终点】当做一条线路，没有考虑分段。跨境运营政策放宽后，售票和车辆调度不够灵活和高效
|
|||
|
|
> 备注: 线路设计的合理性和存在的问题
|
|||
|
|
> - 跨境运营政策放宽，可以允许两地使用不同的车辆和司机进行运营
|
|||
|
|
> - 单段设计，对口岸乘客统计上效率低下，实际统计数据时效性不强
|
|||
|
|
> - 多条线路的站点参与查票检索，检索速度慢，尤其是开发网上代理商接入，导致系统崩溃。目前通过限流方式初步解决。
|
|||
|
|
|
|||
|
|
**需求**：通过线路结构优化，提升运营效率和线路检索效率，有效接入互联网代理商，保证系统稳定性。
|
|||
|
|
- 在口岸出实现有效的客流统计，便于排班调度
|
|||
|
|
- 实现更灵活的线路制定，适应香港和内地两端的班次调配。
|
|||
|
|
- 优化线路、班次检索，有效对接第三方售票平台，而不是限流保持稳定
|
|||
|
|
|
|||
|
|
**建议**：对线路进行结构性改进，强化**口岸**属性**，**以口岸作为中间平台，以优化查询统计效率，提升调度能力
|
|||
|
|
- 无论班次线路一段或二段，必须具有口岸站点，不允许不经口岸的跨境站点。
|
|||
|
|
- 以口岸作为平台，实行到达口岸的乘客统计，计算口岸通往各地的乘客数量。
|
|||
|
|
- 二段检票需在口岸进行，否则不能进行二段检票。
|
|||
|
|
- 口岸人数统计必须保留日报表，作为排班调度的依据（可持续优化）。
|
|||
|
|
|
|||
|
|
### 1.2 线路查询优化
|
|||
|
|
|
|||
|
|
**现状**：线路查询目前采用【城市—>站点】的选择模式，但由于内地城市区划变更以及港人的认知习惯，导致在城市设定时加入旧有的城市名称。显著突出在自助机操作上，多一步操作或返回操作，都容易导致现场购票排队加长的情况。
|
|||
|
|
> 备注：两地认知惯性和检索效率（用户体验）
|
|||
|
|
> - 城市规模大，区级行政单位多，导致站点过多，查询不利于乘客检索。例如广州作为城市，操作上应该列出广州所有的站点。
|
|||
|
|
> - 港人对内地传统城区/郊区/县的使用习惯。例如番禺、顺德这些热门目的点，分别作为广州和佛山的区级单位，但港人的习惯是将其作为传统城市对待，以【市—>区/县—>站】这种多级检索方式可能导致查站困难。
|
|||
|
|
|
|||
|
|
**需求**：解决购票环节中两地用户的使用习惯和操作便捷性问题
|
|||
|
|
- 符合港人对湾区城市和地区的传统认知
|
|||
|
|
- 提供更加高效快捷的检索方式和手段
|
|||
|
|
|
|||
|
|
**建议**：兼顾正规的行政区域和传统地区对站点进行设置，以便进行检索。
|
|||
|
|
- 站点多种绑定方式。分别绑定城市区号，例如参考国内的区号设定，并同时支持自定义地区绑定，如广州城区（越秀、荔湾、天河、黄埔、白玉区部分）
|
|||
|
|
- 加入热门线路，方便在操作界面上直接点选。后期考虑通过注册用户的购票记录进行推荐。
|
|||
|
|
- 加入口岸检索，方便港人直接到口岸换乘。
|
|||
|
|
|
|||
|
|
### 1.3 排班优化
|
|||
|
|
|
|||
|
|
**现状**：排班工作量大，大量的操作重复，容易出错，并且操作不友好。
|
|||
|
|
> 备注：排班的常规操作
|
|||
|
|
> - 单线单日排班：单个班次需要设定的内容过多，对于同一条线路的不同班次需要重新设置，重复量大。
|
|||
|
|
> - 单线多日排班：一般比较固定地重复该线路的某一天的排班，除非特殊情况取消某些班次。
|
|||
|
|
> 固定班次排班需要提前一个月完成，对应售票是预售一个月后的车票。
|
|||
|
|
|
|||
|
|
**需求**：降低排班的复杂程度，提升排班效率和准确度。
|
|||
|
|
- 减少排班过程的重复操作，提升排班效率
|
|||
|
|
- 规范化排班流程，减少误操作
|
|||
|
|
- 对排班工具进行改进
|
|||
|
|
|
|||
|
|
**建议**：采用排班模板的方式，对线路进行映射，并制作排班规则进行批量排班。
|
|||
|
|
- 单班模板。针对线路设定模板，例如上下车站点、票数、票价策略等，通过模板进行线路的多班次创建。
|
|||
|
|
- 单日模板。设置或者选择排的单日所有班次作为单日模板，生成该线路的全天排班。可以制作工作日、休息日、节假日的模板。
|
|||
|
|
- 排班规则。使用排班规则进行批量排班，例如从某日开始，连续 N 日重复应用某个单日模板。
|
|||
|
|
- 票价策略。班次中包含票价策略的设定，例如节假日上浮的幅度、特殊时段的票价变动等。
|
|||
|
|
- 单班修改。批量排班后可以针对单班进行修改，并有明确的指引提醒该班具有单独调整的操作。
|
|||
|
|
|
|||
|
|
### 1.4 一键排班改进
|
|||
|
|
|
|||
|
|
**现状**：原系统一键排班采用比较传统的节点树和多选框方式进行操作，使用上并不友好，容易错选。
|
|||
|
|
> 备注：现有系统一键排班的操作方式
|
|||
|
|
> - 节点树选需要层层展开，子节点过多时不好选择，多选（非全选）操作效率低下。
|
|||
|
|
> - 缺乏检索和过滤功能，需要从 N 条线路或班次中人工选中并应用。
|
|||
|
|
|
|||
|
|
**需求**：提供切实好用的一键排班工具，降低重复操作的工作量。
|
|||
|
|
- 改进一键排班不友好的操作，如目录树操作
|
|||
|
|
- 提升一键排班的有效性和效率
|
|||
|
|
|
|||
|
|
**建议**：对操作进行改良，使用列表+过滤的方式进行准确操作。
|
|||
|
|
- 参考上述【排班优化】，通过模板+策略的方式减少操作。
|
|||
|
|
- 加入检索功能，对线路、模板、策略过多时进行检索过滤。
|
|||
|
|
- 在提交前进行排班信息确认，如使用了什么模板、设置了什么策略、应用在那条线路、受影响有哪些班次，避免误操作后重排。
|
|||
|
|
|
|||
|
|
### 1.5 班次站点统计
|
|||
|
|
|
|||
|
|
**现状**：目前没有针对班次站点的统计。
|
|||
|
|
> 备注：
|
|||
|
|
> - 该需求是从加班和调度中引出，初步定位为服务于站务人员。
|
|||
|
|
> - 用于加速[加班发起—>排班—>派车的流程]
|
|||
|
|
> 班次站点统计有利于对班线的长期跟踪
|
|||
|
|
|
|||
|
|
**需求**：加班和运营工作的依据和辅助。
|
|||
|
|
- 需要对班次站点的余票和购票情况进行统计，用作加班的依据。
|
|||
|
|
- 为日常班车运营优化提供数据支持。
|
|||
|
|
|
|||
|
|
**建议**：将以后台自动统计的形式存在，定时对班次进行自动统计。参考下文【加班监测】内容。
|
|||
|
|
- 后台服务对班次进行定时监测和统计
|
|||
|
|
- 对服务加班条件的班次进行消息推送
|
|||
|
|
|
|||
|
|
## 2. 加班和调度需求
|
|||
|
|
|
|||
|
|
### 2.1 加班监测
|
|||
|
|
|
|||
|
|
**现状**：目前班次加开使用人工监测和调度的方式进行。由站点始发站门店人员进行整体监测（不断刷新后台票务系统），当班次余票低于一定数值如10张（各班次不一样，根据实际运营经验所得），即由始发站人员向排班人员【调配大巴部】发起申请，排班人员向调车人员【车务部】咨询是否有车，再决定是否加开。若决定加开，则需要在系统设置加开班次信息。
|
|||
|
|
> 备注：目前加班的业务操作流程
|
|||
|
|
> - 手动刷新查看余票，需要人工不断监测。原系统在高峰期刷新售票页面缓慢，等待时间过长。
|
|||
|
|
> - 加班需要统计每个站点的售票情况，需要人工将余票转为售出票数
|
|||
|
|
> - 加班车的始发站会根据本班（非加班）售票最多的站点，作为加班车的发车站点，不一定是本班的始发站发车
|
|||
|
|
> - 触发加班的余票阈值不是固定的，需要根据实际经验进行调整，不是每个班次都一样。
|
|||
|
|
> 目前加班的操作都是采用人工联系方式进行
|
|||
|
|
|
|||
|
|
**需求**：提升系统刷新余票性能，能够实现余票与售票的统计。
|
|||
|
|
- 提升查票效率，减少等待时间
|
|||
|
|
- 实现余票统计和售票统计的切换
|
|||
|
|
> 备注：该需求属于外在需求，并不是需要沿着原系统改进，而是通过改进模式，用更好的方式替代。
|
|||
|
|
|
|||
|
|
**建议**：将人工监测和统计，改为【后台】按照规则自动统计并触发消息推送
|
|||
|
|
- 在班次设置增加余票触发设置 N 张
|
|||
|
|
- 建立后台算法，自动统计本班余票和各站点售票情况
|
|||
|
|
- 通过消息机制，向负责排班的人员发起通知
|
|||
|
|
- 完善车务系统，快速查询可用的司机和车辆
|
|||
|
|
- 优化，去掉站务监测统计环节，缩减【调度-车务】环节所需时间。
|
|||
|
|
|
|||
|
|
### 2.2 口岸乘客统计
|
|||
|
|
**现状**：跨境线路分为两段，乘客需在口岸下车，通关后再重新上车（不一定是原来的那一辆车）。实际调度时需要根据两地在口岸的乘客数量来匹配和调度车辆。因此需要加入口岸乘客的统计，用于通过实际数据来合理调度车辆。
|
|||
|
|
> 备注：可能出现的几种情况：
|
|||
|
|
> - 到从口岸下车乘客不定乘坐整条跨境线路，有可能到了口岸过关后选择其他交通工具，这部分可以剔除
|
|||
|
|
> - 在口岸下车的乘客有可能再次选择在口岸站点买票乘坐永东的车前往内地城市（在香港就近没买到直通票，到口岸曲线操作）
|
|||
|
|
> - 单边有多条线路多个班次指向同一口岸，但去往不同的内地城市，需要根据到达口岸的时间进行分类统计，优化调度。
|
|||
|
|
> - 单向不断加班，导致另一侧同样需要增加运力。
|
|||
|
|
|
|||
|
|
**需求**：针对两地乘客数量匹配的问题，需要精准计算和匹配，合理调配车辆。
|
|||
|
|
- 两地乘客在口岸进行换乘，多路汇入和多路输出需要在一个时间点内进行匹配
|
|||
|
|
- 根据统计数据进行车型和班次的调整
|
|||
|
|
- 加班存在的时候，乘客数据属于动态变更，需考虑变更后的跟踪和调整
|
|||
|
|
- 会存在因交通原因晚到的情况
|
|||
|
|
|
|||
|
|
**建议**：后台程序加入实时统计，分时间和目的地进行报表和结果输出，并提醒是否增减运力和匹配车型。类似【加班监测】的模式。
|
|||
|
|
- 通过口岸 ID 和到达口岸的时间进行匹配和统计
|
|||
|
|
- 按照目的地城市和终点进行分类输出。
|
|||
|
|
- 建立适当的规则进行消息提醒，避免人工监测数据。
|
|||
|
|
- 可在司机端 App 加入动态跟踪，预计车辆到达口岸的时间
|
|||
|
|
|
|||
|
|
### 2.3 快捷加班
|
|||
|
|
**现状**：加班需要重新创建班次并填写相关的参数，操作繁琐。
|
|||
|
|
> 备注：加班班次规则和操作：
|
|||
|
|
> - 现时的加班操作相关与新建一个班次，并将班次号与原班次进行递增，如原班次+b。
|
|||
|
|
> - 工作量与重新创建一个班次无异，操作步骤过多。
|
|||
|
|
|
|||
|
|
**需求**：减少在系统设置加班的所需的操作，符合加班的班次命名
|
|||
|
|
- 优化加班的系统操作
|
|||
|
|
- 建立加班班次的命名规则
|
|||
|
|
|
|||
|
|
**建议**：加入【一键加班】功能
|
|||
|
|
- 原班次的基础上增加快捷键，实现一键加班，复制需要加班的班次，并设置班次名称、首发站（可根据统计数据自动指定）、票数等参数。
|
|||
|
|
- 在操作界面上加入加班提醒，并在可原班次信息上加入【可加班】的标识。
|
|||
|
|
- 参考原系统的人工命名规则，在开通加班班次时自动应用规则。
|
|||
|
|
|
|||
|
|
## 3. 售票需求
|
|||
|
|
### 3.1 动态票价
|
|||
|
|
**现状**：实际运营是有实施动态票价，但系统中没有能设置动态票价的策略。
|
|||
|
|
> - 调价需要在系统中单独选择某些班次进行调整，并在排班的时候完成
|
|||
|
|
> - 调价也有一些快捷操作，例如从某天开始连续多少天进行整体调价
|
|||
|
|
> - 调整期结束后，需要重新设置为原来的价格，会切换比较复杂
|
|||
|
|
> - 没有灵活的调价方式，例如针对高峰期自动调价
|
|||
|
|
|
|||
|
|
**需求**：需要灵活的动态票价方式
|
|||
|
|
- 常态调整，工作日和休息日的价格调整
|
|||
|
|
- 高峰期价格调整，针对当前的高峰时段进行价格调整
|
|||
|
|
- 针对性调整，针对大型节假日、大型活动进行调整
|
|||
|
|
- 调价结束后自动恢复原价
|
|||
|
|
|
|||
|
|
**建议**：建议采用增加票价策略功能，在排班时应用具体调价策略来实现
|
|||
|
|
|
|||
|
|
|