18 KiB
RailwaySystem 一期默认开发决策与需求假设 V0.1
文档用途： 在甲方暂时无法持续确认需求的情况下，为一期开发提供统一默认方案。 原则： 默认方案用于推动开发，不代表甲方最终确认。现场测试后，如甲方业务不同，再根据本文件中的“扩展策略”调整。
核心思想：
不把所有可能方案全部开发出来；而是选择一套合理主流程，同时对高概率变化点进行配置化，对结构性变化预留扩展能力。
一、总体开发策略
整个一期采用：
flowchart LR
A[需求明确] --> B[直接实现]
C[规则不明确] --> D[选择默认方案]
D --> E[参数配置化]
F[结构不明确] --> G[选择默认主流程]
G --> H[底层预留扩展能力]
B --> I[形成一期可运行版本]
E --> I
H --> I
I --> J[内部全流程模拟]
J --> K[现场验证]
K --> L[根据甲方真实业务调整]
我们把不确定需求分成两类：
| 类型 | 含义 | 处理方式 |
|---|---|---|
| 配置型变化 | 改一个数字、开关、阈值就可以适配 | 配置化 |
| 结构型变化 | 会改变核心数据关系和业务对象 | 提前留扩展能力 |
例如：
报到截止时间变化
→ 配置型
成绩权重变化
→ 配置型
一个培训班一门课还是多门课
→ 结构型
二、P0-01 开班计划与课程关系
当前不确定点
目前需求和现有数据库都更接近：
一个开班计划
↓
一门课程
但真实培训场景可能是：
一个培训班
├─ 理论课程
├─ VR课程
├─ 3D课程
└─ 实操课程
这是目前风险最大的结构性问题。
默认开发决策
第一版业务界面
暂时按照：
一个开班计划选择一门主课程。
原因：
- 与当前需求文档一致；
- 与现有数据库一致；
- 可以最快跑通一期；
- 不擅自扩大甲方需求。
但底层设计不要彻底锁死
建议业务模型设计时保留：
flowchart LR
A[开班计划]
--> B[班级课程关系]
--> C[课程]
第一版可以限制：
一个开班计划只能有1条有效课程关系
但不要让未来数据库只能物理保存一个课程。
这样如果现场甲方说：
“我们一个培训班其实包含8门课程。”
只需要：
取消一班一课限制
+
调整页面
+
调整部分业务逻辑
而不是推翻整个数据库。
类型判断
结构型变化
开发策略
- 第一版：一班一课；
- 数据模型：尽量兼容一班多课；
- UI：第一版只允许选择一门；
- 现场确认后再开放多课程。
三、P0-02 学员如何进入培训班
当前不确定点
目前无法确定真实业务到底是：
管理员添加
Excel导入
学员自行报名
报名审核
外部系统下发
默认开发决策
一期首先支持：
flowchart LR
A[学员库]
--> B[管理员选择]
A --> C[Excel批量导入]
B --> D[参训名单]
C --> D
D --> E[等待报到]
即：
管理员添加 + Excel 批量导入
暂不优先做：
- 学员自主报名门户；
- 复杂报名审批；
- 外部单位自动下发。
底层统一成“参训名单”
无论学员以后从哪里来：
人工添加
Excel
自主报名
外部同步
最终都统一进入：
参训关系 Enrollment
flowchart TD
A1[管理员添加] --> E[参训关系]
A2[Excel导入] --> E
A3[自主报名] -.未来.-> E
A4[外部系统] -.未来.-> E
E --> F[报到]
E --> G[住宿]
E --> H[签到]
E --> I[成绩]
建议保留一个来源字段
例如逻辑上记录：
source_type
MANUAL
EXCEL
SELF_APPLY
EXTERNAL
当前只实际使用前两种。
这样以后不需要重新设计“参训”。
类型判断
结构型 + 来源可扩展
默认方案
- 管理员手动添加；
- Excel 批量导入；
- 所有方式统一进入参训名单；
- 暂不做复杂报名审批。
四、P0-03 课程表与课次
当前不确定点
需求明确要求：
报到后能够查看课程表。
签到数据里也已经出现：
本节课程开始时间
本节课程结束时间
所以从业务逻辑上看，“课次”几乎是必需的。
默认开发决策
一期正式引入“课次 Lesson”概念。
每条课次至少表示：
哪一期培训
哪门课程
哪个教师
什么时间
哪个教室 / 实训场地
推荐结构
flowchart TD
A[开班计划]
A --> B[课次1]
A --> C[课次2]
A --> D[课次3]
B --> B1[课程]
B --> B2[教师]
B --> B3[开始时间]
B --> B4[结束时间]
B --> B5[教室 / 实训场地]
为什么建议现在就做
因为它同时解决：
课程表
签到对象
教师冲突
教室冲突
实训场地冲突
培训历史
如果现在不做，以后很可能会从签到表里重新拆出来。
类型判断
核心结构型
默认方案
一期直接建课次。
这是七个 P0 里面，我认为最适合直接作为项目设计决策的一项。
五、P0-04 宿舍分配方式
当前不确定点
不知道真实业务是：
提前安排
报到时自动安排
现场人工安排
默认开发决策
一期采用：
提前预分配 + 管理员可调整。
推荐业务：
flowchart LR
A[参训名单]
--> B[住宿需求]
B --> C[系统推荐可用床位]
C --> D[管理员确认 / 调整]
D --> E[形成住宿安排]
E --> F[学员报到]
F --> G[展示住宿信息]
E --> H[触发门禁授权]
为什么不建议第一版完全自动分配
虽然需求提到根据：
性别
培训班
优先同班同寝
自动匹配。
但现场真实规则很可能还有：
领导 / 普通学员
特殊人员
同行单位
房间等级
临时调整
不住宿
这些现在完全不知道。
所以第一版：
系统辅助推荐，管理员最终确认。
比全自动稳妥。
“住宿”与“门禁”必须解耦
不要把：
分到305房间
等价成：
已经拥有305开门权限
应该是：
flowchart LR
A[住宿安排]
--> B[门禁授权任务]
--> C[人脸下发]
--> D[成功 / 失败]
现场设备接口变化时，住宿业务不会被一起推翻。
类型判断
业务规则型 + 设备集成型
默认方案
- 支持“不住宿”；
- 支持预分配；
- 支持管理员调整；
- 自动推荐可以做；
- 不强制完全自动分配；
- 门禁授权独立处理。
六、P0-05 报到截止时间
当前不确定点
需求写的是：
开班后 X 日内未报到自动取消资格。
最大问题就是：
X 不知道。
默认开发决策
不要开发：
开班后固定1天
也不要开发：
固定3天
而是直接设计成：
report_start_time
report_deadline
即：
每个开班计划独立配置报到时间窗口。
推荐流程
flowchart TD
A[开班计划]
--> B[报到开始时间]
A --> C[报到截止时间]
D[学员到场]
--> E{是否在有效期}
E -->|是| F[正常报到]
E -->|否| G[超期]
G --> H{是否请假 / 特殊处理}
H -->|是| I[管理员人工处理]
H -->|否| J[取消参训资格]
“自动取消”也建议谨慎
当前需求确实写了自动取消资格。
但甲方真实业务可能存在特殊人员。
因此第一版更稳妥的实现是：
超过截止时间
↓
自动标记“超期未报到”
↓
提醒管理员
↓
管理员确认取消
如果后面甲方明确要求真正自动取消，再打开自动处理开关。
类型判断
典型配置型变化
默认方案
- 每个班配置报到开始/截止时间；
- 不写死 X；
- 超期默认先标记；
- 是否自动取消做成可配置策略。
七、P0-06 综合成绩
当前不确定点
需求要求：
按权重计算综合成绩。
但没有定义具体比例。
默认开发决策
绝对不要写死：
课程 30%
实训 40%
考试 30%
建议：
每门课程配置自己的成绩组成及权重。
推荐模型
flowchart TD
A[课程]
--> B[成绩规则]
B --> C[理论成绩]
B --> D[实训成绩]
B --> E[考核成绩]
C --> C1[权重]
D --> D1[权重]
E --> E1[权重]
C1 --> F[综合成绩]
D1 --> F
E1 --> F
例如：
钢结构理论课
理论 70%
考试 30%
另一门：
VR实训
理论 10%
实训 70%
考核 20%
进一步建议
成绩类型也不要完全依赖固定三列。
因为后续可能出现：
安全考试
VR成绩
3D成绩
现场操作
理论考试
过程考核
业务上更适合未来扩展成：
考核项目
+
成绩
第一版页面仍然可以展示：
课程成绩
实训成绩
考核成绩
但底层最好不要太死。
类型判断
配置型 + 数据结构扩展型
默认方案
- 权重可配置；
- 默认可以先给一套演示比例；
- 演示比例不作为正式业务规则；
- 后续现场直接修改配置。
八、P0-07 培训完成 / 结业
当前不确定点
现在并不知道到底：
时间到了就结业
还是
成绩合格才能结业
还是
签到达标才能结业
默认开发决策
一期采用：
系统计算建议结果 + 管理员人工确认结业。
不要直接全自动。
推荐流程
flowchart TD
A[培训接近结束]
--> B[汇总学员数据]
B --> C[签到率]
B --> D[成绩]
B --> E[学习时长]
C --> F[系统给出结业建议]
D --> F
E --> F
F --> G{管理员确认}
G -->|结业| H[本次参训完成]
G -->|暂不结业| I[待处理]
H --> J[保存最终培训记录]
H --> K[失效本次培训相关权限]
为什么一定要“本次参训结业”
这里非常重要。
不能简单：
张三.status = 结业
因为张三以后可能：
参加第二期
参加第三期
参加其他课程
所以结业应该属于：
张三参加某一期培训的结果。
而不是张三这个人的永久状态。
结业条件做成配置
建议至少可以配置：
最低签到率
最低综合成绩
最低学习时长
是否必须人工确认
第一版可以先给默认演示值。
例如：
签到率 >= 80%
综合成绩 >= 60
管理员确认
但必须明确：
这是项目组演示默认值，不是甲方业务规则。
类型判断
配置型 + 状态模型型
九、7项默认开发决策最终汇总
| P0 | 当前默认开发方案 | 变化类型 | 处理方式 |
|---|---|---|---|
| 01 开班与课程 | UI暂按一班一课 | 结构型 | 底层预留一班多课 |
| 02 学员进入培训 | 管理员添加 + Excel导入 | 结构型 | 统一参训关系 |
| 03 课程表 | 正式引入课次 Lesson | 结构型 | 一期直接实现 |
| 04 宿舍分配 | 预分配 + 人工调整 | 规则型 | 分配与门禁解耦 |
| 05 报到期限 | 每班配置截止时间 | 配置型 | 不写死 X |
| 06 综合成绩 | 课程级权重配置 | 配置/结构型 | 不写死比例 |
| 07 结业 | 系统建议 + 人工确认 | 配置/状态型 | 条件参数化 |
十、由此形成的一期默认业务主流程
flowchart TD
A[维护教师 / 学员 / 课程]
--> B[创建开班计划]
B --> C[选择主课程]
B --> D[设置报到时间]
B --> E[设置招生人数]
C --> F[配置课次 / 课程表]
G[学员库]
--> H[管理员添加 / Excel导入]
H --> I[形成参训名单]
I --> J[住宿预分配]
J --> K[管理员确认]
I --> L[学员报到]
K --> L
L --> M[显示课程表 / 宿舍 / 场地]
L --> N[触发门禁授权]
F --> O[正式培训]
O --> P[电子班牌签到]
O --> Q[VR / 3D / 实训]
O --> R[成绩录入 / 导入]
P --> S[培训统计]
Q --> S
R --> S
S --> T[学员画像]
S --> U[结业条件判断]
U --> V[管理员确认结业]
V --> W[本期培训结束]
W --> X[本期权限失效 / 历史保留]
十一、需求假设管理机制
从现在开始，建议项目中新增一个正式文件：
docs/requirements_assumptions.md
所有没有得到甲方确认、但为了开发必须先决定的问题，都登记进去。
推荐格式：
编号：A-001
问题：
一个开班计划是否支持多门课程？
当前开发假设：
一期界面按一班一课开发。
扩展设计：
底层模型尽量保留一班多课能力。
影响模块：
开班、课表、签到、成绩。
现场是否必须验证：
是。
现场确认结果：
待填写。
推荐第一批假设
A-001 一期界面暂按一班一课
A-002 参训人员支持管理员添加和Excel导入
A-003 开班存在独立课次
A-004 宿舍可以提前预分配并人工调整
A-005 学员可以选择不住宿
A-006 报到期限按开班配置
A-007 超期未报到默认先标记异常，不直接物理删除
A-008 成绩权重按课程配置
A-009 结业采用系统判断 + 管理员确认
A-010 真实设备暂时使用Mock接口模拟
十二、什么应该配置化
建议至少以下内容不要写死：
flowchart TD
A[业务配置]
A --> B[招生人数]
A --> C[报名 / 报到时间]
A --> D[报到截止时间]
A --> E[成绩权重]
A --> F[成绩及格线]
A --> G[签到率要求]
A --> H[最低学习时长]
A --> I[是否住宿]
A --> J[是否自动取消资格]
原则：
可能因为不同培训班不同而变化的东西，不要做成代码常量。
十三、什么需要预留扩展能力
这些地方不要为了“未来可能”全部开发功能，但是底层不能彻底锁死：
一班一课 → 一班多课
人工参训名单 → 自主报名 / 外部系统名单
Mock电子班牌 → 真实电子班牌
Mock门禁 → 真实智能锁
Mock VR / 3D → 真实接口
固定成绩类型 → 更多考核项目
这叫：
预留结构能力，而不是提前实现未来功能。
十四、什么坚决不要提前做
一期暂时不要因为“以后可能需要”就开发：
复杂工作流引擎
完整BPM审批平台
高度通用动态表单
几十种报名流程
几十种宿舍策略
完整设备管理中台
复杂消息中心
二期数字孪生
二期平板控制
原则：
没有需求依据，只为了未来可能使用的复杂功能，不进入一期。
十五、现场验证策略
最终去现场时，不应该问甲方：
“你们到底想怎么做？”
而应该拿一套已经能运行的系统演示。
例如：
flowchart LR
A[创建课程]
--> B[创建培训班]
--> C[导入30名学员]
--> D[安排课程表]
--> E[预分配宿舍]
--> F[模拟刷脸报到]
--> G[模拟门禁]
--> H[模拟班牌签到]
--> I[模拟VR成绩]
--> J[统计]
--> K[画像]
--> L[结业]
然后现场逐项问：
“你们实际是不是这么做？”
比拿需求文档让甲方从零描述流程更容易获得有效反馈。
十六、现场重点验证清单
现场测试时重点验证：
1. 一个培训班究竟包含几门课程？
2. 学员名单实际从哪里来？
3. 课程表实际由谁排？
4. 一天会有多少节课？
5. 教师是否会变化？
6. 教室 / 实训场地是否按课次变化？
7. 谁负责分宿舍？
8. 是否有人不住宿？
9. 报到什么时候开始、什么时候截止？
10. 请假和迟到实际怎么处理？
11. 成绩具体有哪些类型？
12. 综合成绩怎么算？
13. 学习时长怎么认定有效？
14. 什么情况下算结业？
15. 真实电子班牌接口是什么？
16. 真实门锁接口是什么？
17. VR / 3D / 实训系统能够提供哪些字段？
十七、当前可以冻结的临时开发基线
在无法进一步获得甲方确认的情况下，项目组暂时按以下规则推进：
1. 一期必须先跑通一个完整培训闭环。
2. 默认业务选择最简单、最符合当前文档的一种实现。
3. 不穷举实现所有可能业务方案。
4. 数字、阈值、权重、时限等高频变化项配置化。
5. 一班多课、参训来源、设备接入等结构变化点提前预留扩展能力。
6. 所有未经甲方确认的开发决策进入《需求假设清单》。
7. 去现场的目标是验证假设并微调，而不是重新开发整个系统。
8. 一期完成后根据现场反馈，将业务基线从临时版本升级为正式 V1.0。
十八、下一阶段
基于以上默认决策，现在已经具备进入下一阶段的条件：
flowchart LR
A[需求分析]
--> B[业务基线]
B --> C[默认开发决策]
C --> D[需求假设清单]
D --> E[PRD]
E --> F[核心业务模型]
F --> G[数据库V2]
G --> H[API / 页面]
H --> I[Epic / Issue]
I --> J[开发]
因此，当前不需要继续无限扩展需求讨论。
下一步应该开始：
将当前业务基线和默认开发决策正式转成 PRD。