软件项目版本管理二三事

软件项目版本管理二三事

什么是版本管理？版本管理，是对软件开发过程中特定功能的集合或特定代码构

建结果进行管理，主要包括版本编号的管理、版本的前期规划、版本开发时的需

求变更应对以及版本发布上线后的总结回顾等内容。

在版本开发前：通过建立版本号标识，明确版本目标，制定好版本上线需求内容,

设计好发布策略，可以让产品功能和质量尽可能地符合用户的预期。

在版本开发时：通过提升需求分析的确定性，提高需求方需求变更的成本，降低

开发响应需求变更的成本，从而帮助团队积极地应对需求变更。

在版本发布后：通过对Bug和用户反馈以及线上日志的收集分析，对版本进行

复盘，有助于及时应对版本问题，从而制定有针对性的版本优化。

一,如何对版本进行规划

对产品版本的规划，主要包括四部分内容：一是建立明确的版本号标识，二是确

定版本的目标，三是制定版本内容，四是设计发布的策略。

1.建立明确的版本号标识

为了使工作规范化、统一化，我们需要明确标识产品的版本编号。目前业界在软

件版本的命名上，通常会采用以下方式：

主版本号.子版本号,[修订版本号,[构建版本号]]

Major_Version_Number.Minor_Version_Number[.Rev»s»cn_Number[.Build_Number]]

版本号命名规则

例如：121,2.0,5.0.0build-13124。其中，构建版本号通常由编译程序自动生

成，对外不提供。

1、版本号更新规则

•主版本号更新规则：产品功能发生全新的优化，包括页面、体验和技术上的全面更

新优化。如下图所示两个产品的版本号升级。

•子版本号更新规则：1、产品新增了重要功能模块；2、在原来功能基础上作了重要

更新；3、严重Bug的修复。

・修订版本号更新规则：1、新增或优化一般的功能模块；2、一般Bug的修更。

2、版本号后缀

版本号后面可以加入Alpha、Beta、Gamma、RC、Release等后缀，用来表示

软件当前所处的阶段。

•Alpha:内测版。此版本表示该软件在此阶段主要是以实现软件功能为主，通常只

在开发者内部交流，或者提供给测试人员测试用，一般而言，该版本软件的Bug较

多，需要继续修改。

•Beta:公测版。该版本相对于a版已有了很大的改进，消除了严重的问题，但还是

存在着一些缺陷，需要经过多次测试来进一步消除，可以提供给一定的目标用户大

规模体验测试。

•RC版：候选版本。是ReleaseCandidate的缩写，意思是发布倒计时，该版本已

经相当成熟了,完成全部功能并清除大部分的Bug。

•Release版：该版本意味"最终版本"。是经过前面版本的一系列测试之后，最终

交付给用户使用的一个版本。该版本有时也称为标准版。

2.确定版本目标

版本规划的第二部分内容是关于版本目标的确定。

在确定版本上线需求的时候，往往容易只考虑那些最紧急的、用户反馈最多的、

所谓优先级最高的需求，然后将这些需求整合到下一次的版本发布计划中，但是

这么做无疑是捡了芝麻却丢了西瓜，因为忽视了对整个产品目标的实现。

比如：需求A属于模块1,需求B属于模块2,需求C属于模块3,这些需求分

属于不同的业务，解决的是不同场景的需求，但同时实现这几个需求，并不能体

现出产品的目标和优势。一个版本，就好比一个产品，产品要有自己的优势，版

本也要有自己的目标和优势。

基于海盗模型确定版本目标

案例：抖音在最初的版本上线的时候，通过各种渠道吸引了很多在校的大学生录

制作品，他们大多来自于音乐学院、表演系等颜值出众的年轻人。这些用户的积

极互动和推广为抖音在用户的心里留下了一个新潮时髦的印象，从而吸引更多人

参与到短视频的制作和互动中来。

3、提高留存

留存：指在经过一段时间后有多少用户留了下来，一般情况下会以月、周、日的

时间维度来作为数据考量，也就是我们常说的DAU、WAU和MAU。

案例：在一些社区及游戏行业中留存是一个相当重要的指标，当一款产品的用户

留存越来越低，即使有新用户进来，也依然难以摆脱冷清的局面。例如，根据王

者荣耀的数据发现，在非长假期间用户的留存率会出现下降的情况，所以为了抢

占用户的时间，提高留存率，程序会经常发布一些诸如签到送皮肤和送钻石金币

等任务活动。

4、获取收入

即变现。不止是软件的开发方获得收入变现，用户也可以在这一步获得利益。

案例：知乎为了更好的促进用户进行高质量内容创作，增加了付费问答等功能，

这些功能让用户有更强烈的动机去进行持续的内容输出，同时也为平台带来了部

分收益。

5、自传播

自传播：即用户可以自发的向身边用户推荐我们的产品。

案例：拼多多采取了拼团模式让用户获取到折扣和优惠，同时进一步刺激了用户

分享给身边人，加强了产品本身的传播性。

3.制定版本内容

版本的目标确定了，我们就需要从需求池中挑选需求了。需求很多，但是开发资

源紧张或存在其他一些客观因素，不能在一个版本中全部实现。那么我们怎么对

这些需求进行排序呢？

基于KANO模型确定需求优先级

KANO模型是东京理工大学教授狩野纪昭(NoriakiKano)发明的对用户需求

分类和排序的工具。我们可以通过使用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、分析原因

导致好结果的原因，比如：增加了自动化测试代，改进了开发流程，代码合并之

前有代码审核等；改进了项目流程，对于所有的需求细分后，基于任务跟踪系统

记录了起来，这样可以及时了解任务进程。

导致坏结果的原因，比如：版本没有及时冻结需求，频繁增加新的需求，导致开

发