产品经理必知的产品版本命名规范与规则

上一篇文章我们对产品的版本迭代的方法进行了一些总结，本篇文章我会针对产品的版本命名、验收、发布这三个层面，来总结一下我自己的想法，希望能对大家有所帮助。

01、产品版本命名的规范与规则

1.1 版本命名规范

软件版本号由主版本号、次版本号、修订版本号以及日期版本号加希腊字母版本号构成。

其中希腊字母版本号又分为base、alpha、beta 、RC 、 release五种。

1.2 各类版本号修改规则

(1) 主版本号：

该版本号由项目经理决定修改与否，一般当功能模块发生较为大幅度的变动时需要作出修改，例如该模块的增加或者是整体框架的变化等。

(2) 次版本号：

该版本号由项目本身决定修改与否。该版本号的变化可能对带来以下影响：与以往的版本无法兼容的问题；打破以往的协作关系；对功能进行较大的增进等。所以说，相比于主版本号的变动，该版本号的变动只是比较小规模的，但是带来的影响还是比较大的。

(3) 修订版本号：

该版本号依旧是由项目经理决定修改与否。修改的情况往往是对一些功能上或是小细节的修改，又或者是对BUG的修复。每修复一个较为严重的BUG时即可更新一个修订版本，经常发布修订版是很有必要的。

(4) 日期版本号：

该版本号修订与否由开发人员来决定。日期版本号的修改频率是比较频繁的，一般来说每天都要进行修改，目的是方便对项目修改的具体日期作及时记录。

(5) 希腊字母版本号：

该版本号依旧是由项目经理决定修改与否。该版本号的修改一般发生在一个软件的两个开发阶段的间隙，即当一个软件即将进入下一个开发阶段时，就需要修改希腊字母版本号。

1.3 版本各阶段介绍

Base：该版本仅代表网站的一个基本框架，包含页面的布局以及功能等，但并不具备一些具体功能的展现。因此也可以说这只是一个静态页面框架。

Alpha ：这是一个软件的初步版本，也可以称作测试版本。仅作为软件开发者之间的内部交流所用，因为尚未完善，所以一般存在较多的BUG，需要测试人员发现BUG交由开发人员修改确认，再由测试人员进行测试。这时就可以将版本称作alpha版。

Beta ：该版本是alpha版本的进阶版，在大方向上的错误已经被消除，但仍然需要进一步的修改，一般是对UI、交互、产品细节进行优化。当测试人员将优化的内容发布到外网时，我们就可以将该版本称之为beta版。

RC ：该版本相较于上面的几个版本来说，可以说是非常成熟的一个版本了，BUG明显少了很多，与下一步的正式版本没有太大区别。

Release：历经以上的各种测试版本之后，这就是面向用户的正式版本了，也称作标准版。

1.4 版本发布周期

通常分两种情况进行讨论：

• 如果是一般情况，即不是紧急情况的话，就按照常规发布流程进行；
• 如果遇到特殊情况的话，例如出现突发BUG时，可以直接交由开发人员迅速修复经测试以及确认后直接发布。

1.5 版本号修改实例

以该版本号为例：1.0.0.0716_alpha ，我们可以知道这处于内部测试阶段。

首先，如果开发人员修复了测试人员提交的BUG并经测试人员测试后，将版本发布到外网，这时候就进入了软件的下一个阶段，就可以将版本号修改成：1.0.0.0716_beta 。如果说修改的日期与上一个日期不同的话，就修改成：1.0.0.0717_beta即可。

其次，如果有修复一些较大的BUG 并按照流程上传到外网时就可发布一个修订版，日期即发布的当前日期，如1.0.1.0717_beta。

再者，如果对软件进行细节或者功能上的变动时，就需要修改次版本号，如：1.1.0.0717_beta。

最后，当功能模块发生较为大幅度的变动，例如该模块的增加或者是整体框架的变化等，就要将版本号更改为：2.0.0.0717_beta 。

02、产品验收流程

2.1 流程步骤说明

• 测试人员在确定所有BUG修复之后交由产品进行验收，这里需要注意的是，有时候产品本身也需要参与到测试中，可以在一些关键节点介入测试，以防理想与现实的差距过大。
• 对产品的功能进行验收，检测功能与设计的一致度，流程的通畅度，交互的顺畅度之类的。特别需要提醒的是，尤其要注意验收异常流程，因为异常流程是否正常是衡量一个系统完备程度的关键指标。
• 视觉设计验收可以一起进行，但最好是分开进行，让UI设计师分别进行验收，好处是既分工明确又点明重心，多次验收精准度也会更高。

2.2 产品验收报告的标准

产品验收报告包含：

• 验收编号，即表明所归属的项目及验收日期；
• 产品版本、上线时间以及发起人；
• 验收清单项目，包括功能及视觉，以需求文档为基础，对本次更新中的功能、流程等进行再次核对；
• 签字确认，明确验收以及权责划分。

03、对产品发版进行管理

3.1 管理的目的

需要明确的一点是，发版管理针对的是公司内部，而非对外公布。实行发版管理主要是为了规范协作流程，对一些交接工作和职责等作出明确规定，让整个团队运作更加协调、分工更加明确，进一步提高团队工作效率。

3.2 产品发版更新的步骤

（1）第一步，对于产品新需求的提出，首先提交后需要按照不同类型将需求分类，各类需求进入到自己的需求池之后，按照其归属，例如是归属于哪个系统等进行分类，同时应写明该需求的内容、规则等，方便后续操作。

（2）第二步，将产品交由研发人员进行开发，开发完成后进行本地测试，测试通过后再交给测试人员进行测试。

（3）第三步，由测试人员进行测试，主要的测试内容包括对产品相关文档进行数据检查、页面核对、文字核对以及其它测试。倘若在测试中出现BUG，需向TAPD提交BUG，交由修改人员并与BUG对应功能的研发人员沟通。

（4）第四步，产品测试完成阶段，还需要对产品进行验收测试，测试人员确认过后，填写《产品更新确认表》，填写本次实际更新的功能，测试人员以及相关研发人员在表上签字。

（5）第五步，《产品更新确认表》签好后，进行产品的确认验收，同样地，如果在这一步出现BUG，则由测试人员提交BUG到TAPD，同时联系相关研发人员。必要的话可以召开会议商讨对策。以下是几点会议需要注意的事项：

• 会前与参会人员沟通时间，通知会议议题事项；
• 会中围绕主题事项，以解决事情为主；
• 对时间点以及相关人员进行明确，做到事事有人负责，按时提交；
• 会后需要跟踪执行、落实和反馈的情况。

（6）第六步，产品测试验收后进行签字，保留一份纸制文档，并将电子文档交给研发负责人，并更新已经签字完成的《产品更新确认表》电子文档。

（7）第七步，测试无误后通过钉钉群发送发布版本的公告。公告的内容主要包括：

• 本次产品版本的主要更新内容，包括需求提出方、对应UI、研发人员、项目经理等关联人员；
• 版本号——版本号的规范参照《产品版本命名的规范与规则》执行；
• 发布时间。

（8）最后一步，测试环境通过后，再次进行测试验证，如此时发现有问题，也必须重新按照产品发版更新流程走，测试环境检测完成才可在生产环境发布。