小米首届员工运动会

我在梳理需求时发现，员工运动会需要同时服务员工与家属、参赛运动员、队长、裁判和现场运营人员。赛前要处理不同项目的报名规则与名额，赛中要同步签到、赛程和成绩，赛后还要汇总部门积分与个人结果。任何一个环节依赖临时表格或群聊，都可能在现场被放大成沟通成本。

因此，我没有把产品定义为一次性的活动 H5，而是从完整赛事流程出发，设计了一套由参赛端小程序和赛事管理后台组成的系统。小程序只呈现用户此刻最需要的信息，后台则承接规则、容量、进度与数据处理的复杂度。

运动会里的项目并不遵循同一种报名方式。个人比赛关注选手资格，趣味比赛需要队长组队并维护成员，瑜伽、篮球和羽毛球等体验项目则要选择具体时段，还必须实时判断剩余容量。我先把这些差异拆成项目类型、报名主体、人员信息、时段和名额五组规则，再用一致的页面结构呈现给用户。

用户可以从首页进入报名，先选择项目类别，再完成时段或队伍信息；提交后，所有记录会回到“我的报名”，便于再次确认或取消。规则虽然不同，但用户始终知道自己正在选择什么、还缺什么，以及报名是否已经生效。

现场运营最需要的不是更多页面，而是快速判断赛事现在进行到哪里、哪些项目还在报名、哪些体验时段已经接近满员。我把赛事进度与时段容量做成独立的后台管理能力，让运营人员可以直接调整状态、时间和名额，而不必修改小程序页面。

同一项变更会沿着统一的数据关系回到参赛端：后台调整赛事状态后，用户看到的入口与提示随之变化；时段人数更新后，新的报名会按照最新容量判断。这样，现场变化不再依赖开发人员临时改页面。

比赛结果不仅是一张后台表格，它还会影响个人成绩、队伍名次和部门积分。我让成绩、项目和部门共享同一套数据关系：运营人员完成录入与核对后，系统可以继续汇总积分，参赛者也能在小程序里按部门、队伍或个人维度查询结果。

为了让结果更容易理解，我没有在移动端复制复杂的后台表格，而是保留项目筛选、名次与关键成绩。用户只需进入排行榜，就能快速找到和自己有关的结果；运营团队则可以在后台查看更完整的积分汇总。

我把报名人数、项目分布、性别比例、部门参与情况和成绩数据集中到统计与导出模块，方便运营团队在筹备期判断资源配置，在比赛期间核对进度，也能在活动结束后沉淀完整的数据记录。

项目最终完成了1000+ 名员工及家属的活动承接，600+ 条运动员数据与200+ 条比赛成绩成功入库，支撑了小米首届员工运动会的顺利进行。