学校网络计费系统项目启动后，常见的一个卡点就是需求调研怎么都做不深。开会的时候业务方说"我们需要一个能计费的系统"，问得更具体一点，回答就开始模糊了——"大概能按人收钱就行"、"支持多种套餐吧"、"跟校园卡打通"。这些回答拿去选型，供应商方案里都有，但实际上线后才发现真实场景里到处对不上。问题往往出在调研阶段没有问对问题，业务方也被问住了，因为他们也没仔细想过这些细节。

先问"现在学生怎么用网络"，再问"想怎么用"

学校网络计费系统的需求起点，应该是当前网络使用的真实状态，而不是想象中的理想状态。调研时第一组问题应该围绕"现状"：现在学生用什么设备连网？宿舍区、教学区、图书馆的上网高峰分别是什么时候？目前有没有免费的流量配额？谁在管理这些设备的后台账号？用户报修最频繁的问题是什么？这些现状问清楚了，才能知道新系统上线后到底要替代什么、改善什么。如果跳过现状直接问需求，很容易陷入"凭空设计未来"的陷阱。

把"计费颗粒度"问具体

业务方说"按人计费"，这远远不够细。具体的颗粒度包括：是按学号、还是按手机号、还是按 MAC 地址？宿舍账号是按床位、还是按寝室、还是按楼层？毕业的学生账号什么时候清退？延期毕业的研究生怎么处理？转专业的学生账号怎么迁移？这些细节如果不问清楚，计费系统选出来之后会出现大量"边界 case"处理不了的情况。颗粒度问得越细，对系统的能力要求就越明确，供应商方案里到底支持哪些、不支持哪些就一目了然。

把"用户投诉场景"列出来

调研时如果只问"现在有什么问题"，得到的答案往往是"网速慢"这种笼统说法。更好的问法是"最近三个月内，用户投诉最多的是哪几类问题"。把投诉单子调出来做归类：认证页面打不开、认证后无法上网、计费余额不准、连接频繁掉线、特定设备无法识别、宿舍夜间断网等等。每一类投诉背后对应的是学校网络计费系统要解决的具体场景。把这些投诉清单当作需求验收标准，新系统上线后投诉量有没有下降，就成了可量化的评价指标。

财务对接的细节也要问清楚

学校网络计费系统如果涉及收费，必然要和财务流程对接。调研时需要问：缴费走校园卡还是走第三方支付？充值后多久到账？退款怎么处理？余额是否可以结转？结转的规则是什么？发票怎么开？这些财务相关的问题如果不提前问清楚，上线后财务部门会成为新的投诉来源。财务部门对账周期、对账格式的要求也必须明确，否则账目核对会变成一场旷日持久的拉锯战。

网络管理团队的能力也要评估

学校网络计费系统上线后，日常运维工作由网络信息中心承担。调研时不能只问业务方"想要什么功能"，还要问清楚"运维团队能不能扛得住"。比如：信息中心目前有多少人负责网络维护？7×24 小时响应能不能做到？数据库的备份机制是什么？遇到计费系统故障时，业务方的容忍度是多少？这些问题的答案决定了系统的复杂度和运维要求。如果运维能力薄弱，但系统设计得很复杂，上线后大概率会出问题。

不要漏掉学生组织的意见

学校网络计费系统的最终用户是学生，但调研时往往只问学校管理层和老师，忽略了学生群体的真实想法。可以通过学生会、研究生会、宿舍管理委员会等组织收集意见：他们对现有网络的吐槽点是什么？哪些场景下他们愿意为更好的网络付费？对认证页面的 UI 体验有什么要求？这些声音在选型时不一定起决定性作用，但能避免上线后出现"学生集体投诉"的情况。学生用脚投票的能力很强，一个不友好的计费系统会让学校在学生中的口碑变差。

把调研结论写进可执行的文档里

调研做完了，一定要落到一份"需求规格说明书"上，而不是停留在会议纪要。需求文档里要写清楚每条需求的优先级、验收标准、负责人、依赖项。后续选型时，需求文档就是评分依据；实施时，需求文档就是验收依据；运维时，需求文档就是变更依据。学校网络计费系统项目周期长、参与方多，没有一份扎实的需求文档兜底，中途跑偏的概率极高。