先把已有结果摆出来。
学生端、老师端与管理端完成协同上线核心咨询与志愿填报流程实现在线化产品后续持续使用并做过前端改造
以上内容仅用于说明项目经历和交付边界，不代表对新项目作出同等结果承诺。未经公开核验的客户经营数据不作为宣传结论展示。
02 / 角色与边界
我们具体负责了什么。
项目负责人：参与现场调研、需求梳理、原型确认、后端开发、团队管理和上线协同。
先理解当时的业务条件。
客户拥有高校招生、志愿老师和学生资源，希望把线下志愿填报服务在线化。
高考志愿填报有明显时间窗口，系统既要承接大量咨询，也要让老师和学生能快速完成匹配与沟通。
真正影响交付的难点。
- 01
学生、老师和运营人员角色不同，流程不能混在一起
- 02
咨询高峰集中，系统要支撑短期集中访问
- 03
志愿填报涉及学校、专业、分数等结构化数据
- 04
业务上线后需要运营团队持续维护内容和老师资源
先跑通关键链路，再扩大范围。
拆分学生端、老师端和后台管理端
先完成选校选专业、咨询对接、语音沟通和用户管理主流程
用原型确认关键页面，减少开发过程中的反复返工
上线后根据真实使用继续优化前端体验
实际交付物
- 学生端 App
- 志愿老师端功能
- 官网展示入口
- 管理后台
- 需求文档与原型
关键技术与协作选择
- 移动端：App 承接学生高频使用场景，配合官网做信息展示和下载转化
- 后端：用户、学校、专业、咨询关系和老师排班等核心业务对象建模
- 通信：线上语音对接和咨询记录，支撑老师与学生远程服务
- 运营后台：内容、用户、老师和咨询状态管理
没有做什么
- 不替代老师完成志愿决策
- 不披露学生信息、客户名称与未授权经营数据
如何验收
- 学生、老师和运营角色能够完成各自主流程
- 咨询与志愿填报流程可在线流转并由后台管理
披露限制
项目名称、客户主体、学生数据和具体运营指标受保密边界限制，本页只说明参与角色与已交付流程。
能迁移到下一次合作的经验。
01教育类产品能不能跑起来，资源和运营比功能清单更关键。
02有真实老师资源和学生来源时，技术的作用是放大业务能力，而不是替代业务能力。