编辑导读：版本管理，是对软件开发过程中特定功能的集合或特定代码构建结果进行管理
本文作者围绕软件项目版本管理进行了分析，希望对你有帮助
什么是版本管理？版本管理，是对软件开发过程中特定功能的集合或特定代码构建结果进行管理，主要包括版本编号的管理、版本的前期规划、版本开发时的需求变更应对以及版本发布上线后的总结回顾等内容
在版本开发前：通过建立版本号标识，明确版本目标，制定好版本上线需求内容，设计好发布策略，可以让产品功能和质量尽可能地符合用户的预期
在版本开发时：通过提升需求分析的确定性，提高需求方需求变更的成本，降低开发响应需求变更的成本，从而帮助团队积极地应对需求变更
在版本发布后：通过对Bug和用户反馈以及线上日志的收集分析，对版本进行复盘，有助于及时应对版本问题，从而制定有针对性的版本优化
一、如何对版本进行规划对产品版本的规划，主要包括四部分内容：一是建立明确的版本号标识，二是确定版本的目标，三是制定版本内容，四是设计发布的策略
1. 建立明确的版本号标识为了使工作规范化、统一化，我们需要明确标识产品的版本编号
目前业界在软件版本的命名上，通常会采用以下方式：版本号命名规则例如：1.2.1, 2.0, 5.0.0 build-13124
其中，构建版本号通常由编译程序自动生成，对外不提供
1、版本号更新规则主版本号更新规则：产品功能发生全新的优化，包括页面、体验和技术上的全面更新优化
如下图所示两个产品的版本号升级
子版本号更新规则：1、产品新增了重要功能模块；2、在原来功能基础上作了重要更新；3、严重Bug的修复
修订版本号更新规则：1、新增或优化一般的功能模块；2、一般Bug的修复
2、版本号后缀版本号后面可以加入Alpha、Beta、Gamma、RC、Release等后缀，用来表示软件当前所处的阶段
Alpha：内测版
此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在开发者内部交流，或者提供给测试人员测试用，一般而言，该版本软件的Bug较多，需要继续修改
Beta：公测版
该版本相对于α版已有了很大的改进，消除了严重的问题，但还是存在着一些缺陷，需要经过多次测试来进一步消除，可以提供给一定的目标用户大规模体验测试
RC 版：候选版本
是 Release Candidate 的缩写，意思是发布倒计时，该版本已经相当成熟了，完成全部功能并清除大部分的Bug
Release 版：该版本意味“最终版本”
是经过前面版本的一系列测试之后，最终交付给用户使用的一个版本
该版本有时也称为标准版
2. 确定版本目标版本规划的第二部分内容是关于版本目标的确定
在确定版本上线需求的时候，往往容易只考虑那些最紧急的、用户反馈最多的、所谓优先级最高的需求，然后将这些需求整合到下一次的版本发布计划中，但是这么做无疑是捡了芝麻却丢了西瓜，因为忽视了对整个产品目标的实现
比如：需求A属于模块1，需求B属于模块2，需求C属于模块3，这些需求分属于不同的业务，解决的是不同场景的需求，但同时实现这几个需求，并不能体现出产品的目标和优势
一个版本，就好比一个产品，产品要有自己的优势，版本也要有自己的目标和优势
基于海盗模型确定版本目标海盗模型是一种以用户为中心的、着眼于转化率的漏斗模型
这个经典的数据模型把目标整体分成了五个部分，即：获取用户（Acquisition）、激活用户（Activation）、提高留存（Retention）、获取收入（Revenue）和自传播（Referral）
1、获取用户即拉新，一般是用户的注册、下载、关注等行为
通常用新增用户数来作为考量
任何一款产品上线之初都避不开这个环节，而且拉新是会持续的伴随整个产品生命周期
一般在刚刚上线核心功能后，都会重点关注并优化用户的注册登录的路径，甚至通过不断的埋点来获取数据，从而做数据分并优化需求
案例：最初新浪微博的注册流程，是需要用户在第一次注册时绑定手机号、身份证、输入账号密码和保密邮箱等等非常多的内容，后来在后台的数据埋点中发现由于注册流程繁琐，导致不少用户在注册了一半的情况下就跳出了页面
之后随着版本的不断迭代，如今新浪微博的注册只需要输入账号和密码即可，只有在需要用到核心功能时才会需要我们绑定手机号和身份证等相关信息
这样就大大降低了用户的操作成本，让获取用户变得更容易
2、激活用户即促活，一般会以用户的在线时长、与其他用户的互动频次等数据来做以考量
初期用户的活跃度是至关重要的，甚至对产品以后的发展会有很长远的影响
案例：抖音在最初的版本上线的时候，通过各种渠道吸引了很多在校的大学生录制作品，他们大多来自于音乐学院、表演系等颜值出众的年轻人
这些用户的积极互动和推广为抖音在用户的心里留下了一个新潮时髦的印象，从而吸引更多人参与到短视频的制作和互动中来
3、提高留存留存：指在经过一段时间后有多少用户留了下来，一般情况下会以月、周、日的时间维度来作为数据考量，也就是我们常说的DAU、WAU和MAU
案例：在一些社区及游戏行业中留存是一个相当重要的指标，当一款产品的用户留存越来越低，即使有新用户进来，也依然难以摆脱冷清的局面
例如，根据王者荣耀的数据发现，在非长假期间用户的留存率会出现下降的情况，所以为了抢占用户的时间，提高留存率，程序会经常发布一些诸如签到送皮肤和送钻石金币等任务活动
4、获取收入即变现
不止是软件的开发方获得收入变现，用户也可以在这一步获得利益
案例：知乎为了更好的促进用户进行高质量内容创作，增加了付费问答等功能，这些功能让用户有更强烈的动机去进行持续的内容输出，同时也为平台带来了部分收益
5、自传播自传播：即用户可以自发的向身边用户推荐我们的产品
案例：拼多多采取了拼团模式让用户获取到折扣和优惠，同时进一步刺激了用户分享给身边人，加强了产品本身的传播性
3. 制定版本内容版本的目标确定了，我们就需要从需求池中挑选需求了
需求很多，但是开发资源紧张或存在其他一些客观因素，不能在一个版本中全部实现
那么我们怎么对这些需求进行排序呢？基于KANO模型确定需求优先级KANO模型是东京理工大学教授狩野纪昭（Noriaki Kano）发明的对用户需求分类和排序的工具
我们可以通过使用KANO模型，分析需求的优先级，完成对版本上线内容的制定
具体就是：要尽量避免无差异型需求，不做反向型需求，做好基本型需求和期望型需求，努力挖掘兴奋型需求
在KANO模型中，根据不同类型的需求与用户满意度之间的关系，可将影响用户满意度的因素分为五类：兴奋型需求、期望型需求、基本型需求、无差异型需求、反向型需求
1、兴奋型需求兴奋型需求，就是哪些藏在暗处的、用户意想不到的，需要挖掘/洞察的需求
若不实现此需求，用户满意度不会降低；若实现此需求，用户满意度会有很大的提升
当用户对一些产品或服务没有表达出明确的需求时，如果提供给用户一些完全出乎意料的产品属性或服务行为，会使用户产生惊喜，提升用户满意度，从而提高用户忠诚度
这类需求往往是代表着用户的潜在需求
例如网易云音乐的评论功能：网易云音乐刚推出时就摒弃了传统音乐APP“音乐播放器”的普遍定位，以“音乐社交”为差异化切入点，让用户听音乐后投入的情感以F发表评论的形式参与进来，让用户体验的不仅仅只有音乐，还有情感的共鸣
2、期望型需求期望型需求，是处于成长期的需求，也是体现竞争能力的需求
实现此需求，用户满意度会提升；不实现此需求，用户满意度会降低
对于这类需求，不仅要满足，还要保证质量
例如：电子书APP阅读方式的多样性，既支持文字阅读，又能支持语音听书
3、基本型需求基本型需求，即痛点，对于用户而言，这些需求是理所当然必须满足的
当不实现此需求，用户满意度会大幅降低，但优化此需求，用户满意度不会得到显著提升
这类需求是核心需求，也是产品必做的功能，所以应该不断地调查和了解用户需求，并通过合适的方法在产品中体现
例如：电商购物类APP的支付和订单这两种需求
4、无差异型需求用户根本不在意的需求，对用户体验毫无影响，无论提供或不提供此需求，用户满意度都不会有改变
对于这类需求，没有必要花大力气去实现
5、反向型需求用户根本都没有此需求，实现这类需求用户满意度反而下降
所以这类需求不能去实现
4. 设计发布策略版本规划的第四个内容是设计发布策略
版本发布策略需要考虑的问题是：直接发布给所有用户？还是先让一部分用户试用？比如说可以先让内部用户使用，内部用户对软件质量问题容忍度是很高的，还可以帮助发现很多问题
还有就是采用灰度测试的发布策略，让一小部分用户先用新功能，如果没发现什么问题，再继续扩大用户规模，如果有问题，也只是影响少量用户
例如：苹果的iOS系统，用户也可以选择安装最新的 Beta 版本，可以先体验新功能，但是必须忍受系统的不稳定
二、如何应对版本需求变更问题从版本的规划进入版本的实现阶段，业务需求的变更是无法避免的，所以需要考虑如何应对版本需求的变更问题
问题一：同样是工程，建筑工程也是有需求变更的，但却不会像软件项目这么频繁和失控
为什么呢？原因一：需求的确定性建筑需求是很具象的，而软件工程的需求是抽象的
所以建筑项目里面，无论是提出需求还是变更需求，客户和施工方都明确地知道他们想要什么
然而，软件需求则经常是抽象、模糊、不精确的，模糊不清的需求导致在软件开发有了雏形后，才慢慢想清楚真正的需求是什么，从而导致需求变更
举个例子：客户最开始对软件界面的颜色是没有任何要求的，当第一版本的软件给客户看的时候，客户觉得白色背景太难看了，希望换成蓝色的；第二版本换成蓝色后，客户现在已经觉得黄色更好看，希望改成黄色背景；第三版本的时候，产品经理担心客户还想换颜色，就直接做成了换皮肤功能，用户可以自己选择颜色，客户还是不满意，问能不能把背景换成图片……原因二：需求变更的成本建筑项目里面的需求变更，都很容易和成本挂钩，因为这些东西已经是生活常识了，而软件项目里需求的变更成本比较模糊不确定
举个例子：装修房子的时候，如果墙面已经刷成白色了，但是客户想都刷成蓝色，那么他会很清楚，这涉及一系列成本：需要重新购买涂料、需要找人重新粉刷
但换成一个软件项目，客户想把界面的白色背景换成蓝色的，他会觉得这是很简单也是理所当然的，甚至有时候产品经理也会这么想，就会对开发这么说：“不就是换个颜色吗？几行代码的事，客户让换就换了嘛
”但是实际上，软件项目的需求变更，哪怕是换一个背景颜色，同样是要涉及成本的：需要修改所有涉及背景颜色的代码，需要更新相关测试代码，还需要对涉及的界面重新测试
问题二：如何缓解需求变更问题？在软件项目开发中，需求变更其实是不可避免的，找到合适的方案来改善并积极拥抱合理的需求变化，减少不必要的需求变更，这是我们讨论如何缓解需求变更问题的前提条件，也是共识的基础
1、提升需求确定性，把需求分析做好，减少需求变更例如：在了解完客户的需求后，不急于马上输出PRD文档让开发实现，而是自己先用 Axure等原型设计工具，做一个简单的交互原型，给需求方演示
用户会针对原型的效果提出一些修改意见，然后再快速地修改原型，这样反复确认，等到用户没有什么修改意见后，再着手具体的文档编写和开发实现
2、规范变更流程，提升需求变更成本例如：如果有条件，当业务需求发生变更时，可以根据实际情况，要求需求部门需通过“电子化管理平台中的需求管理流程”进行需求变更，并提交《需求变更申请》，经主管领导及项目经理审批后提交给技术负责人实施”
需求变更申请通过后，文档管理人应将《项目需求规格说明书》同步更新到最新版本
3、降低开发响应需求变更的成本，积极应对需求变更例如：技术上可以通过换皮肤的方式来定制界面，可以通过插件的方式增加功能，以此来应对个性化的需求
三、版本发布后的工作当版本发布上线后，可能这才只是新的开始，因为还有两项重要的工作需要继续跟进，一是问题跟踪，二是版本复盘
1. 问题跟踪用户在使用产品的时候，可能会遇到一些 Bug 或者是有一些建议，所以需要提供用户反馈问题的渠道，让用户可以有途径对于 Bug 或者功能去反馈
除了被动地依靠用户反馈问题，还需要主动的对发布的版本进行监控
比如说要收集系统崩溃的日志、监控服务器资源占用情况、监控 API 出错的比例、监控网页响应的速度等数据
当发现数据异常时，很可能说明发布的版本是有问题的，需要及时的应对，回滚版本或者发布新的更新补丁
2. 版本复盘对版本进行复盘，就是通过分析和讨论实现版本过程中出现的问题，进而总结成功经验，吸取失败教训，提升团队能力
版本复盘主要包括四个步骤
1、回顾版本目标版本在最开始规划的时候都会确定该版本的目标，所以复盘的第一步，就是要回顾最初的目标，方便对最终结果进行评估
做好版本目标回顾的前置条件，是准确和客观的目标描述
只有做到目标的准确和客观，在后续才能对目标的完成情况进行准确地评估
2、评估版本结果好的结果：比如说版本上线后质量稳定，Bug 比例低于上一次版本，没有出现需求遗漏，开发和测试能及时同步需求的变更
坏的结果：比如说开发过程中间有比较多的需求变更；项目发生了延期等
3、分析原因导致好结果的原因，比如：增加了自动化测试代，改进了开发流程，代码合并之前有代码审核等；改进了项目流程，对于所有的需求细分后，基于任务跟踪系统记录了起来，这样可以及时了解任务进程
导致坏结果的原因，比如：版本没有及时冻结需求，频繁增加新的需求，导致开发节奏被打乱频繁等4、总结规律落实行动例如，需求变更是导致项目延期的主要源头，需要在后续项目中控制好需求的变更，比如我们将缩短项目周期，采用快速迭代的开发模式，及时响应需求变更，同时在一个迭代中，没有特殊情况，不做需求上的变更，有变更放到下一个迭代中
或者，任务跟踪系统可以方便地跟踪需求的执行情况，也能保证项目成员能及时同步需求的变更
那么就继续使用任务跟踪系统，对需求任务进行跟踪，并且可以尝试对于一些临时性的任务也用任务跟踪系统跟踪起来
通过回顾目标、评估结果、分析原因和总结规律这四个步骤对版本进行复盘，有助于我们发现做的好的地方和做的不好的地方，找出背后的原因，最终总结出来规律，落实成行动，做出积极的改变，把经验转化成能力
四、结语版本管理工作是软件项目管理的重要内容，该工作贯穿版本开发前、版本开发时和版本发布后的全生命周期
版本开发前，通过建立明确的版本号标识，明确版本目标，制定好版本上线需求内容，设计好发布策略，尽可能地让产品版本功能和质量符合用户的预期；版本开发时，通过提升需求分析的确定性，提高需求方需求变更的成本，降低开发响应需求变更的成本，帮助团队积极地应对需求变更；版本发布后，通过对Bug和用户反馈以及线上日志的收集分析，对版本进行复盘，及时应对版本问题，从而为下一步制定有针对性的版本优化做好准备
以上就是本人对于软件项目版本管理的一些思考和总结，希望对从事项目管理、产品管理的同行有所帮助
本文由 @xyh产品研习录 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于CC0协议

（图片来源网络，侵删）