最近又有一位学校信息中心的老师把旧小程序后台截图发过来，问还能不能修。打开截图我就知道麻烦了——家长请假入口里，班主任姓名是写死的。这学期老师一调岗，消息照样推给前任班主任。老师收不到，家长在群里问，德育处只能手动翻聊天记录。这个项目当初也是找了外包做的，费用不低，就是没人提醒学校，功能上线只是开始，权限和流程才是命门。
学校在找正规学校小程序开发外包时，最容易犯的错误，是把报价单上的功能名词当成交付标准。“家校互动”“在线请假”“校园缴费”，每个词听起来都差不多，实际上背后可能是完全不同的架构。低价外包的常见做法是拿一套通用模板改个校徽，演示时走得通，开学后各种边角场景全崩。
先看第一个坑：不懂学校角色权限的外包，基本是在做电商小程序。学校场景和电商完全是两套逻辑。电商用户买完东西就走，权限非常简单。学校呢？一个家长可能有两个孩子，一个孩子对应不同班级、不同班主任；科任老师只看自己任课班级；德育处只看跨天请假；财务只看缴费异常；校领导可能只看汇总。如果外包团队上来不问这些，直接让你看模板，后面踩坑是迟早的。
去年我们帮一所九年一贯制学校重构过小程序，原来的外包项目就是把家长做成一个角色，结果二孩家庭切不了孩子。老大的请假条推到老二班主任那里，德育处审批完了，财务还要从系统里导Excel再对一遍。最离谱的是，家长重复提交请假，教师端没有任何去重，一个孩子病假能刷出六条。这个重构不涉及高深技术，就是把身份绑定、多孩关系、班主任映射、审批路由重新梳理。上线后，家长端一个账号可以挂多个学生，普通病假自动推给班主任和值周老师，跨天请假才进德育处审批流，财务收到的已经是审批通过后的结构化数据。
第二个坑：数据归属不清。很多学校小程序做完，源码不交付，数据导出还要找原来的外包。服务器、域名、小程序主体、备案信息全挂在对方个人账号下面。学校想换服务商，等于从零开始。正规学校小程序开发外包至少要交付三样东西：完整源码、数据库字典、部署文档。最好支持私有化部署到学校自己的服务器或教育云。对方如果只说“数据在云端，很安全”，你可以接着问一句：账号谁管、备份在哪、迁移要多少钱。答不上来的，基本可以排除。
第三个坑：验收只打勾，不压异常场景。功能清单上每一项都打勾是最容易的，难的是异常流程。家长重复提交、审批人恰好请假、学生转学、毕业归档、微信模板消息推送失败、开学季并发量暴涨。这些场景不写进合同，上线后全是学校的运维成本。验收时别拿外包提供的测试账号点一遍，要让教务员和班主任用真实账号走完至少两个完整流程。合同里写清楚并发量、响应时间、备份频率、上线后三个月内的免费修复范围。微信小程序还有审核和接口调整，之前有学校的小程序突然收不到模板消息，因为微信改了类目要求，原外包失联，老师只能手动通知。
这些事其实不复杂，只是很多团队不愿意做。我们在做这一类项目时，会把接口文档、压测报告、数据字典随项目交付，上线前至少做一轮教师现场培训。不是服务多特别，是这些本来就该在服务清单里。学校信息化管理的投入，要花在让老师少加一个班、家长少打一个电话的地方，而不是给一个模板套壳。
回到开头那个旧项目，我们最后没让学校继续打补丁，花了两周把权限、审批流和数据归属重新整理了一遍。如果你正在找成都运多多网络做这类项目，或者想对比外包方案，可以先把“谁在什么场景下用”列成三张表：使用角色、关键流程、异常情况。能跟你一起把这三张表填清楚的团队，才值得把学校的小程序交给他。
