上一篇文章我们针对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修改完毕，先由研发测试、提交测试人员、测试人员无误提交产品。内部发布也需要走发布版本管理，需产品负责人及项目负责人签字确认。有必要的情况下组织会议商议对策，会议记录方式参考《会议纪要模板》。
会议注意事项：
会前与参会人员沟通时间，通知会议议题事项，
开会围绕主题围绕事项，以解决事情为主，不要搞成茶话会
事事有负责人及截止时间点
会后有跟踪执行落实和反馈
（6）产品测试验收完成签字，产品留一份签字确认纸制文档，并将电子文档给测试给研发负责人。由研发或测试再给更新正式发包运维人员并加此次更新已经签字完成的《产品更新确认表》电子文档。
（7）发布正式环境，测试无误后产品通过钉钉群方式发送发布版本公告。产品发公告的内容主要包括：
本次产品版本更新主要需求内容，需求提出方，对应UI、研发人员、产品、项目经理等关联人员；
版本号——版本号的规范参照《版本命名规则》执行；
发布时间（按实际发布时间）；
（8）测试环境通过后发包更新至预发布环境或生产环境，测试再次进行测试验证，如此时发现有问题，也必须重新按照产品发包更新流程走，填写《产品更新确认表》，测试环境测试完成才可在生产环境发包。
