基础覆盖：补齐至 30 款
对已开发不足 30 款的非 PANDA 品牌，原则上按品牌热度依次补齐；9 月 FASTSPIN 先于 JDB。品牌总量少于 30 款时直接完成全量。PG、Tada、G759、TOPPLAYER、POPOK 已达到门槛，无需重复投入。
239款 / 10个品牌需要补齐
01 · Capacity
月度产能与交付承诺
交付承诺采用保守口径：9 月按成熟团队产能排期，第一周 10 款、其余周 30 款；新增人员从第三周计入成本，但爬坡期不额外抬高 9 月交付承诺。
第一阶段：补齐基础覆盖
第二阶段：品牌全量完成
缓冲产能
✓
完整目标可在 12 月第 4 周前段交付。9 月第一周直接按 10 款产能执行；其他品牌在 12 月第 3 周完成后立即开发 PANDA，第 4 周完成剩余 34 款，最终留出 66 款产能。
余量 5.1%
02 · Weekly roadmap
周度开发排期
每周原则上按品牌热度顺序连续消化；9 月按执行要求将 FASTSPIN 调整到 JDB 之前。若品牌在周中完成，则同周无缝切换到下一品牌。
9月 · 3名开发 · 周产能30款
03 · Delivery strategy
两阶段交付策略
品牌排序取自《所有游戏.html》的唯一投注用户数热度排名；品牌内部游戏继续按同一热度口径优先。
深度覆盖：依热度完成全品牌
第一阶段完成后，从热度最高的 PG 开始，依次完成 Tada、G759、PP 等品牌全部剩余游戏；其他品牌全部收口后，最后集中完成 PANDA。
995款 / 含最后一批 PANDA 42款
04 · Brand backlog
品牌级开发清单
已开发基线来自《游戏列表(已开发).csv》。BGaming 20 款不在全部游戏主表中，单独保留但不占本次排期；PANDA 不参与第一阶段补齐，作为最后一批开发。
| 热度 | 品牌 | 总游戏 | 已开发 | 阶段一 | 阶段二 | 本期合计 | 完成节点 | 当前覆盖率 |
|---|
05 · Planning basis
测算口径与执行规则
这部分用于汇报时说明“为什么是这些数量、为什么按这个顺序”。
排期生成逻辑
- 1锁定范围
全部游戏 1,534 款均纳入目标；PANDA 42 款不做基础补齐，整体排在最后。
- 2核算基线
CSV 共 320 款已开发，其中主表内 300 款；BGaming 20 款为主表外存量。
- 3先广后深
第一阶段先补覆盖，第二阶段再按热度完成全量；PANDA 作为特定优先级最后开发。
- 4按周滚动
每周验收实际完成数；未完成量顺延，新增或返工优先使用 12 月 66 款缓冲。
06 · Management controls
执行中的三个控制点
新增游戏单独入池
本计划以当前源文件快照为基线。新增游戏先进入缓冲池，不回溯打乱已开始品牌的开发顺序。
周验收而非月末验收
每周确认“计划款数、完成款数、返工款数”。连续两周低于 90% 时，立即调整后续品牌切换点。
品牌内继续按热度
同一品牌的具体游戏，优先选择《所有游戏.html》中尚未开发且排名更高的游戏，确保业务收益优先。
07 · Workforce & cost
人力资源与成本预估
9 月前两周为 3 名研发（含 1 名管理）与 1 名测试；从第三周起扩展为 10 名研发（含 1 名管理）与 6 名测试，并持续到 12 月底。
9–12月预计人工总成本117.25万
人民币 · 不含福利、招聘、设备及办公成本
| 期间 | 管理岗 | 研发岗 | 测试岗 | 折算月数 | 期间成本 |
|---|---|---|---|---|---|
| 9月 第一–二周 | 1人 × 5万 | 2人 × 2万 | 1人 × 1.5万 | 0.5个月 | 5.25万 |
| 9月 第三–四周 | 1人 × 5万 | 9人 × 2万 | 6人 × 1.5万 | 0.5个月 | 16万 |
| 10月 | 1人 × 5万 | 9人 × 2万 | 6人 × 1.5万 | 1个月 | 32万 |
| 11月 | 1人 × 5万 | 9人 × 2万 | 6人 × 1.5万 | 1个月 | 32万 |
| 12月 | 1人 × 5万 | 9人 × 2万 | 6人 × 1.5万 | 1个月 | 32万 |
工作节奏与产能口径
用于周计划拆解、任务分配和交付验收。
研发工作时间每周 6 天5天开发 + 1天Bug修复
研发日开发量每天 2 款连续5个开发日
单研发周产能每周 10 款2款/天 × 5天
单测试测试量每天 3 款按6天计算为18款/周
稳定期测试能力：6名测试 × 3款/天 × 6天 = 108款/周，可覆盖研发团队每周最多100款的新游戏，并预留8款测试量用于回归与复测。