游戏版本管理在PM的日常工作中有着举足轻重的地位，开发者通过一个个游戏版本将内容带给玩家，本文将通过一个极简的版本模型介绍游戏版本管理的基本步骤。
版本管理，是对软件开发过程中特定功能的集合或特定代码构建结果进行管理，主要包括版本编号的管理、版本的前期规划、版本开发时的需求变更应对以及版本发布上线后的总结回顾等内容。
版本开发流程可以根据版本状态拆分为三个阶段，分别是「准备阶段」「开发阶段」和「运营阶段」，我们再将这三个阶段拆分为一个个相对具体的节点：
- 准备阶段：版本规划、确认版本需求范围
- 开发阶段：版本资源生产、版本功能开发、版本验收与测试、版本发布
- 运营阶段：反馈问题跟踪、版本复盘
准备阶段
计划阶段的核心是确定版本的目标和发布策略，再根据实际情况（可能存在的各种限制）将目标和策略拆分为一个个具体的需求。
版本规划
常见的游戏版本目标大致分为四类：拉新、留存、促活和增收。
在实际场景中，大家自然是全都想要，但由于开发资源有限，一个版本能承载的需求量是有上限的，这时需要根据游戏当前的数据情况，制定符合长线发展的版本目标。因此通常会从中选择一到两个作为主要的版本目标，投入大部分开发带宽。
发布策略是指游戏版本开发完成后，投放给玩家的方式。通常会先在测试服发布，验证数值和暴露Bug，一段时间后再全量发布，这样做能降低风险，就算版本有严重恶性Bug，影响范围也相对可控。
如《英雄联盟》会在新英雄正式放出之前，先在测试服验证新英雄的表现；《梦幻西游》会动态挑选线上服务器作为新功能/玩法的试点，收集一线玩家的反馈并作出相应调整。
版本号也是版本规划中必不可少的一环，此时可以考虑使用业界通用的规范。关于版本号的使用说明网上已有大量介绍，可根据项目实际情况自行选择，这里保留一篇原文引用的资料：软件版本命名规则 - 腾讯云开发者社区。
确认版本需求范围
版本规划完成之后，接下来需要探索实现目标路径。
当版本目标是提升留存时，有很多种方式看起来都能提升留存，比如增加游戏深度、增加运营活动、改善核心玩法体验、丰富外围系统等。此时团队需要选择具体的路径。
假设《代号C》是一款武侠游戏，新版本希望提升长线留存，团队认为需要继续打磨核心玩法，并将其和竞品做出明显的差异化，以此为卖点留住玩家。
对此，团队将「打磨核心玩法」拆分成了更具体的任务：
- 增加门派特色——门派专属技能
- 丰富战斗策略——添加更多增益减益类型
- 完善基础战斗体验——优化战斗表现和打击感
- ……
通过不断拆分，最终将抽象的目标变为可落地的需求点。
开发阶段
在准备阶段产出了一批需求，我们将在开发阶段将它们逐一实现。
版本资源生产
版本资源可以分为文档资源和美术资源。
比较理想的情况是策划提前两个版本完成文档编写，美术提前一个版本完成美术资源制作，这样程序在开工时能拿到确定的方案和正式美术资源，能有效降低风险。
以版本序列描述这种理想状态：1.2版本的策划案在1.0版本功能开发期间准备完成；进入1.1版本开发时，美术资源开始前置生产；到1.2版本正式开发时，程序能够拿到相对确定的方案和资源。
然而往往由于种种现实因素，无法实现上述这种理想情况。
因为游戏市场竞争激烈且外部环境变化较快，几个月前准备的策划案可能已经不适合当下的市场环境了，需要做出迭代或者推翻重新设计。如果是下游还没开工的策划案倒还好，影响相对有限，如果已经有美术/程序开始开发，则需要通过变更控制来确保整体风险可控。
变更控制流程值得单独写一篇文章，先挖个坑。
在策划案准备完成后，可以组织资源宣讲会，此时策划会和参与需求制作的美术描述需求详情。美术评估、拆解实现需求所需的素材清单。需求对清楚之后就可以排期制作了。
版本功能开发
到了这一步，程序将开始实现策划案里的功能。
这时PM需要对开发进度做整体把控，通过晨会、周会等各种正式和非正式渠道获得信息，了解开发过程中是否出现了阻塞或其他特殊情况（如请假、需求变更等），及时暴露风险并制定相应的后处理方案。
版本验收与测试
这里的版本验收与测试是指开发封版后的QA统一回归测试。
每个版本功能点的验收与测试应该是贯穿开发过程中始终需要策划、美术、程序密切配合的，并不是程序自己做完觉得没问题就结束了，而是整个功能点涉及的制作者都对效果验收通过才算结束，其中策划重点验收功能和各种边界条件，美术重点验收功能的表现效果。这里也非常考验团队配合，往往需要一段时间的合作才能把这一步跑顺。PM可以根据排期设置一些节点，提醒制作者参与到过程验收中来。同时也鼓励美术、程序将开发中的过程版本展示到开发群中，让大家了解功能目前的进展。
关于测试通过的标准，通常会有一些定量的指标。功能方面会有各类Bug率的指标，如：
- A类Bug = 0
- B类Bug < 10
性能方面也会有对应的要求，如：
- 低端机帧率达到20
版本发布
当版本终于通过测试之后，这时可以进行版本发布的流程。过程中会有一些分支切换、合并的动作，完成后QA去线上服白名单跑回归，回归通过后版本就正式见玩家了。
版本发布流程还是比较复杂的，上面只是简单概括了下大致流程，PM需要提前和相关同事确认好发版过程中各种突发情况的处理方案，确保风险可控。
运营阶段
版本发布后，我们将能收到真实玩家的反馈，此时PM需要关注反馈问题跟踪和版本复盘。
反馈问题跟踪
玩家在进行游戏的过程中会通过客服或社区反馈遇到的问题；线上日志也会暴露一些测试环境很难发现的问题。
PM此时可以定期组织团队，对收集到的问题、反馈进行优先级排序，逐一处理。对于一些影响严重的问题，如大量crash、充值失败等，在收到问题的第一时间就需要采取行动，在最短时间内解决问题。
这里牵扯到线上反馈问题的分级处理，有机会开新坑。
版本复盘
复盘的重要性不言而喻，之前整理过复盘的内容，可以回顾：游戏项目管理（3）——项目复盘。
至此，一个游戏版本的完整闭环就结束了。
和之前一样，上面描述的版本管理模式仅仅是一个极简模型，真实的项目可能比这个复杂得多，但整体思路框架是不变的，还是需要通过多实践掌握版本管理的精髓。
AI时代怎么看这个方法
AI可以帮PM从项目工具中汇总进度、标记长期未更新的依赖、整理版本风险和线上反馈，也能更快生成供团队讨论的初稿。但版本目标选什么、哪些需求必须砍、什么时候可以承担发布风险，仍然依赖PM对玩家、团队和业务的综合判断。更合适的用法，是把信息整理交给AI，把省下来的时间用于范围取舍、跨组沟通和关键节点决策。
观点溯源：《AI时代，游戏PM还剩下哪些不可替代的东西？》
如果你想继续系统梳理从执行到体系化管理的方法，可查看从执行者到架构师。