同行们好,叫我“c鸽”就行,技术型产品经理,从业8年,项目无数,之前基本没有对外发布过自己的产品经理的一些文章,有点对不起自己了,现在决定冒着被各位大佬怼的风险持续发布相关产品管理的总结文档,您怼您的,您怼完我,我就学完您,先谢谢,就不多废话了。
版本管理目的:产品管理之源-需求易清晰、团队易协同
--------------------------------------------------------------------------------------------
版本全观
--------------------------------------------------------------------------------------------
管理规则:
一、主版本号(Major version)
1、更新时间:产品需求计划时;
2、更新规则:
(1)产品需求发生重大变更、迭代或产品战略性的变更,主版本号加1;
(2)产品需求发生全面全新的优化,包括页面、体验及技术上的全面全新优化,主版本号加1;
二、副版本号(Minor version)
1、更新时间:产品需求计划时;
2、更新规则:
(1)主版本号更新时,副版本号归0;
(2)产品需求新增重要功能模块,副版本号加1;
(3)产品体验重要性功能模块有显著性的提升,包括页面、体验、技术的优化,但未达到全面的优化阶段,副版本号加1;
三、迭代版本号(Iterative version)
1、更新时间:产品需求计划时;
2、更新规则:
(1)主版本号、副版本号更新时,迭代版本号归0;
(2)产品需求新增及优化一般性非重要性功能模块,迭代版本号加1;
四、调整版本号(Adjust version)、标识区
1、更新时间:产品需求计划时;
2、更新规则:
(1)当前需求计划上线之前,标识区必须带“beta”,每次对内部团队发布一次需求,调整版本号加1;
(2)产品上线后,临时性地修改线上产品Bug,突发性的尚不需单独形成计划的小需求,调整版本号加1,此时去除标识区“beta”;
(3)当前产品需求计划第一次上线,直接去除标识区“beta”;
五、备注
1、对外展示的版本号,只展示主版本号、副版本号、迭代版本号;
2、调整版本号、标识区仅用于内部需求对应,不对处展示;
--------------------------------------------------------------------------------------------
一、重点提示
1、标识区用于区分当前更新是内部版本更新还是当前需求已上线的外部更新;
2、每一次发布需求必更新版本;
3、上线后的版本不能带标识区“beta”;
二、示例
1、2010.07.12 产品首次形成原型需求文档并第一次发布此需求时,版本号为:v1.0.0.1beta;
2、2010.07.18 第二次更新需求并发布需求时,版本号为:v1.0.0.2beta;
3、2010.07.22 当在第二次更新需求发布后,开发测试完成最终上线版本号为:v1.0.0.2,此时直接去除标识区“beta”;
4、2010.07.25 解决并上线一个bug,版本号为:v1.0.0.3;
版权所有:文章归中所有内容版权归作者本人,未经同意不得擅自使用,否则必纠。