学校类型
北京市某多校区小学
放学系统交付不是把页面部署出来就结束,而是要把学校实际放学流程、老师操作、设备条件、通知规则和后台查询都配置清楚。
| 阶段 | 要做什么 | 输出结果 |
|---|---|---|
| 需求访谈 | 确认学校类型、班级、校门、通知和安全要求 | 需求清单 |
| 现场评估 | 确认网络、设备、大屏、闸机、校牌和广播 | 部署边界 |
| 数据准备 | 整理年级、班级、老师、学生、家长等基础数据 | 基础数据表 |
| 系统配置 | 配置权限、批次、屏幕范围、通知规则和播报模板 | 可运行配置 |
| 培训试跑 | 培训老师、门岗和管理员,模拟放学流程 | 试运行结果 |
| 复盘优化 | 根据日志、通知和异常记录调整配置 | 正式上线方案 |
| 项目类型 | 参考节奏 | 成立条件 |
|---|---|---|
| 小程序轻量首期 | 资料齐全后进入快速配置与试运行评估 | 账号、隐私指引、组织数据、权限、通知路径和试点人员已确认 |
| 标准学校项目 | 常见参考周期为 2 至 4 周 | 需求和范围稳定,数据按时提供,培训和试运行可安排 |
| 设备利旧或接口联调 | 在标准流程上增加资料核验、样机测试和异常复测 | 接口开放、原厂配合、网络条件和测试设备可用 |
| 私有化或纯内网 | 增加环境准备、安全核对、部署和运维交接 | 服务器、网络、端口、备份和校方运维角色明确 |
| 阶段 | 学校负责 | 青鸽负责 | 完成标志 |
|---|---|---|---|
| 需求与范围 | 提供流程、角色、设备、网络和目标 | 梳理范围、边界、风险和方案 | 双方确认需求与不包含项 |
| 数据与环境 | 提供数据、账号、场地、网络和设备资料 | 检查格式、环境和接口前置条件 | 数据与环境检查通过 |
| 配置与联调 | 安排现场和设备配合人 | 完成配置、接入、日志和异常测试 | 联调用例与问题清单关闭 |
| 培训与试运行 | 安排老师、门岗、管理员和试点班级 | 培训、陪跑并记录问题 | 真实流程按约定范围跑通 |
| 验收与交接 | 按口径确认结果和遗留项 | 提交配置、记录、运维和复盘材料 | 验收结论与后续责任明确 |
北京多校区记录说明了需求转向、版本研发、批次迭代和校区扩展的实际阶段。公开记录没有完整起止日,因此这里只呈现实施路径,不编造周期。
北京市某多校区小学
教师不承担主要操作、校门值班人员集中指挥、校区内网互通。
指挥端、PAD、LED、语音、批次规则与多校区扩展。
需求确认、网络、数据、联调、培训、试运行和验收均会影响排期。
请说明学校类型、班级与学生规模、校门数量、网络边界、已有设备和希望先解决的问题,我们会按相近条件整理实施路径。
获取同类型学校实施方案 →需要学校提供基础数据、现场流程、网络与设备信息,并安排老师和管理员参与培训试运行。
可以,而且通常建议先选择一个校门、一个年级或一个高频问题试运行。试点前要确定责任人、异常降级办法和验收口径,验证稳定后再逐步扩大范围。
可以评估,但应先把需求分成标准平台能力、按校配置、接口适配和项目改造四层。优先通过角色、批次、状态、通知和终端配置解决共性需求;涉及新状态、新接口或特殊责任链时,再形成范围、原型、数据边界、异常方案、工期和验收用例。尚未开发和验证的能力不能作为现成功能承诺。
至少需要产品能力边界、部署拓扑、服务器与端口清单、角色权限表、任务与状态说明、接口协议、设备字段与错误码、联调用例、异常降级流程、安装升级手册、培训材料、验收清单和责任矩阵。涉及学校既有设备时,还要取得原厂协议与配合范围;涉及个人信息或外部通知时,应补充数据字段、保存期限和安全责任。