产品治理流程及规范5版本命名、验收规范、发版治理

上一篇文章我们针对PRD文档撰写的why，what，how三个层面进行了剖析，本篇文章，我将针对产品的版本命名，产品验收、版本发布管理三个方面谈一些想法。

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。
修正的的Bug 经测试人 员测试确认后可发布到外网上，此时可将软件版本标注为 beta版。

RC ：该版本已经相称成熟了，基本上不存在导致缺点的Bug，与即将发行的正式版本相差无几。

Release：该版本意味“终极版本”，在前面版本的一系列测试版之后，终归会有一个正式的版本，是终极交付用户利用的一个版本。
该版本有时也称标准版。

1.4 版本发布周期

（1）非紧急情形：按照一样平常发包管理制度实行

（2）紧急情形：如果Bug比较紧急可跳过一样平常流程，由开拓职员尽快修复Bug，测试及产品确认之后直接发布该版本。

1.5 版本号修正举例解释

如此时版本号为：1.0.0.0321_alpha ，此时为内部测试阶段

（1）开拓职员修复了测试职员提交的bug并经测试职员测试验证关闭bug之后，发布到外网时，此时就进入了软件的下一个阶段，版本号可改为：1.0.0.0321_beta ，如当前日期跟上一个版本号的日期不一样，版本号可改为：1.0.0.0322_beta。

（2）如果修复了一些重大Bug 并按照流程发布到外网时就可发布一个修订版，如1.0.1.0322_beta，日期为发布确当前日期。

（3）如果对软件进行了一些功能上的改进或增强，进行了一些局部变动的时候要修正次版本号，如：1.1.0.0322_beta（上一级有变动时，下级要归零）。

（4）当功能模块有较大变动，增加模块或整体架构发生变革时要修正主版本号，如新增加了退款功能，则版本号要改为：2.0.0.0322_beta 。

02 产品验收流程2.1 流程

流程描述：

a、测试职员在确定所有bug修复之后交由产品进行验收，一部分公司中，产品也须要参与到测试中，特殊在各项文档不是很齐备完善的情形下，产品可以在关键节点参与测试一下，防止研发出的功能与想要的功能差距较大。

b、产品功能验收—产品验收紧张是验收功能，功能是否与设计同等，主流程是否通畅，交互是否顺畅，数据是否正常，是否有缺漏，非常流程是否考虑，各种提示及关照是否具备。
一定要验收非常流程，很多时候正常流程可能没有问题，非常流程是很随意马虎遗漏的，非常流程是否系统考虑完备的主要表示。

c、视觉设计验收—视觉验收产品也可以进行，但最好是让视觉设计师再进行一次验收，这样分工明确，也可以有所侧重，也形成多次验收，防止涌现意识偏差。

2.2 产品验收报告标准

产品验收报告包含：

a、验收编号-表明所归属的项目及验收日期

b、产品版本、上线韶光、发起人

c、验收清单项目——包括功能及视觉，检讨清单项可以担保不遗漏，此功能验收还须要以prd文档赞助，以prd文档为根本，核对本次迭代中的功能、流程等。

d、具名确认项——明确验收，权责

03 产品发版管理3.1 目的

制订发包的干系管理制度是为了规范干系干事流程，明确干系交卸文档，确定干系权责，让事情有据可依、有根可查、有人卖力，从而提高团队干事效率。
此处的发版说的是公司内部关照，不是针对外界的关照，外界关照可由运营或干系对付推广部门运作。

3.2 产品发版更新流程

（1）产品新功能提需求，须要提交到禅道，按不同类型进行分类，归属到不同需求池，需求的提交按需求点办法提交，备注需求归属，是哪个别系，前端or后台、模块、功能、优先级等，并写明需求内容、规则。

（2）技能职员开拓并通过本地测试后，交由测试职员进行测试。

（3）测试职员进行测试，参照原型等产品干系文档数据检讨，页面核对，笔墨核对及其它测试。
测试产生功能性等Bug，需向禅道提交bug，分配bug修君子并关联bug对应功能的研发职员。

（4）产品测试完成，须要产品进行验收测试，测试职员与技能确认，并填写《产品更新确认表》，填写本次实际更新的功能，打印《产品更新确认表》具名，技能卖力人具名。

（5）《产品更新确认表》交给产品确认验收，产品查验更新功能与需求是否有出入，并进行验收。
如果验收测试有bug，则由测试提交bug到禅道，关联干系研发职员。
Bug修正完毕，先由研发测试、提交测试职员、测试职员无误提交产品。
内部发布也须要走发布版本管理，需产品卖力人及项目卖力人具名确认。
有必要的情形下组织会议切磋对策，会议记录办法参考《会议纪要模板》。

会议把稳事变：