起点
先把球队库立起来
386 支球队的档案一支一支录进去,涵盖 26 项联赛与杯赛。这一阶段的目标很朴素:让每支球队在站内都有一个对得上的名字。
路径主张
看球的麻烦很少出在信息太少。开赛时间在一个地方看到,阵容变动在另一个地方刷到,伤停消息是两天前贴出来的,你还得自己判断哪一条现在还作数。中间那点犹豫,往往就错过了赛前两小时能改主意的窗口。
我们从第一天就选了一条笨一点的路:把所有东西按时间铺开。386 支球队的档案、26 项联赛与杯赛的赛程,收进同一条按日期往下走的路径里。未来 14 天横着排一遍,重点场次只留开赛时间、场地、首发、伤停、停赛、阵容变动和更新时间这 7 个字段,其余的都让位。
路径的好处是你不用先想清楚自己要查什么。顺着日期往下走,看到哪一场就点开哪一场,确认完原路退回,上面那一屏还在原来的位置等你。
团队构成
团队不大,所以每个人手上负责的那一段都很具体。下面这张环图按人数切开四块,鼠标停到条目上能看到各自的人数。
盯住 6 家数据服务方在同一场比赛上的出入,决定哪一条进库、哪一条退回重看。
定义那 7 个字段长什么样、放在哪一屏,也负责 iOS、Android 和网页版看起来是同一套东西。
管采集、入库、推送和三个端的稳定性,赛前两小时那条提醒就从这里发出去。
工作日 9:00-18:00 接邮件和电话,帮赛事编辑和社群组织者把对不上的那一场找出来。
数据流程
6 家数据服务方各自交上来的原始记录先摊在一起,谁和谁不一致、差在哪个字段,做运营的人当场标出来。同一场比赛的伤停条目,每 15 分钟重新比对一次。
确认过的内容才落到 386 支球队的档案里,和这支球队所属的赛事、近期阵容变动放在一起。没确认的不会进库,也就不会出现在你看到的那一屏。
每条记录都会带一个更新时间戳,用琥珀色标在字段旁边。你扫一眼就知道这条是刚刷出来的,还是已经躺了半天。
iOS 端按球队单独开关,开赛前两小时推一条阵容变动。只推一次,不重复打扰;不想看的球队可以关掉,不影响其他场次。
版本脉络
近两年走了 9 次版本迭代,大致每 6 到 8 周一个小版本。下面这条节点带可以左右拖动,中间那个跨度最大的就是 3.0 重构。
起点
386 支球队的档案一支一支录进去,涵盖 26 项联赛与杯赛。这一阶段的目标很朴素:让每支球队在站内都有一个对得上的名字。
扩张期
需求一条条叠进来,一场比赛要填的字段涨到 14 个。信息是多了,但打开一屏要往下划很久,赛前那几分钟根本看不完。
3.0 重构
球队库和伤停记录的节奏在这一版重做,字段从 14 个砍到 7 个,只留开赛时间、场地、首发、伤停、停赛、阵容变动和更新时间。同时确立以更新时间为主轴的排列方式——你更在意的往往不是消息本身,而是它多久没更新了。
节奏期
伤停栏目全面转到以更新时间为轴,每 15 分钟比一次,时间戳跟着字段走。日历也加上了导出一张横向图片的能力。
现在
测试版延续同一套 7 个字段的结构,正式版不会换另一套说法。iOS、Android 与网页版功能范围保持一致,你在哪一端看都是同一份内容。
合作与生态
6 家数据服务方各自盯着自己擅长的赛事和区域,把原始记录交过来。我们在中间做那个把差异摊开的人:同一条伤停,六份记录对不上就先不进库,等搞清楚再写。这样做慢一点,但每一条进库的内容都有人担保。
赛事内容方那边的合作走的是另一条线。他们需要把某个联赛整轮的开赛时间一次排出来,我们提供按球队、赛事、日期三个维度组合的清单,让他们直接生成自己的关注列表。
如果你是要把日历转给同事或社群的那个人,网页版支持把未来 14 天整体导成一张横向图片。发到群里不用解释怎么点,对方一眼就能看到哪几天有球。
服务与支持
赛事日历和阵容变动相关的问题,附上具体日期与球队名称,我们能直接定位到那一条。