一支球队不只有球员。教练、体能团队、分析师、队医、理疗师、设备人员、运营和行政人员共同构成球队日常运转的人员体系。星空体育球队研究的核心问题是：当这些不同角色的人都在同一个系统里工作时，身份、权限和任务应该怎样组织，才不会互相干扰。
People层级不只是"球员名单"，还包括教练、体能团队、运营、行政、设备人员、分析师和管理层。每类角色对信息和权限的需求不同，系统需要按角色而不是按"一个账户一份数据"来组织内容。
身份回答的是"你是谁"——姓名、所属球队、联系方式；权限回答的是"你能看到和做什么"——是否能查看训练负荷数据、是否能修改差旅安排、是否能看到其他人的合同信息。如果系统把这两件事绑死在一起（比如"教练"这个身份自动等于某一组固定权限），一旦出现身份和实际职责不完全对应的情况（比如一名教练同时兼任球探），系统就很难灵活处理。
更合理的设计是把身份和权限做成两个独立但可以关联的概念：一个身份可以关联一个或多个角色，每个角色对应一组具体权限，系统根据当前上下文（比如正在查看哪支球队的数据）决定应用哪一组权限，而不是给每个人分配一个固定不变的"角色标签"。
很多系统在设计之初假设每个用户对应一个固定角色，教练就是教练、球探就是球探。但现实中一名青年队教练很可能同时承担球探工作，一名体能教练也可能同时服务两支梯队。如果系统只能给这名教练分配一个角色，要么他缺少完成球探工作所需的权限，要么系统被迫给他分配一个"超级角色"，反而超出了实际需要的权限范围。
支持多角色、并按上下文授予权限的设计，能够更准确地反映真实的工作情况：这名教练在处理一线队事务时使用教练权限，在处理球探相关工作时使用球探权限，两组权限互不干扰，也不需要额外创建一个模糊的复合角色。
一份孤立的任务列表（比如"确认下周客场酒店"）如果不关联到具体的日期和上下文，很容易被淹没在其他日常事务里，也很难判断这项任务和当天的训练、差旅安排是否存在时间冲突。任务本质上是嵌在具体时间和场景里的，脱离日历单独管理，会丢失很多帮助判断优先级的上下文信息。
把任务和日历绑定在一起，能让工作人员在查看某一天安排的同时，直接看到当天关联的待办事项，而不是分别打开任务列表和日历各查一遍。这也是星空体育App把训练日程和会议任务放在同一视图下设计的原因，详见星空体育App。