软件版本迭代周期

2.3.9然后改成2.4.0？产品的版本号是如何确定的？什么时候再加一个？每当有产品更新的时候，你是否也有同样的疑问？笔者基于工作中对项目实践的思考和感悟，结合案例等，分享了产品迭代过程中应注意的要点。，供大家参考，一起学习。

随着互联网行业的快速发展，隔几天大更新，一直小更新的产品越来越多，但我们经常看到一些公司的版本管理及其混乱。有一次，我的一个朋友跟我说，他工作的公司根本不懂什么是版本。修复一个bug和更新一个弹出窗口将被视为版本更新。上线一个月后，APP版本更新至2.3.0。

一开始，我以为是个玩笑。后来发现这种情况并不少见。

常识概念版本号的通用命名规则。这里简单说一下常见的命名规则和版本的几种类型。

大多数情况下，常见的版本号是三段式的，也就是X.Y.Z我们用X来表示大版本号。一般当产品有重大更新、重写或者不再向后兼容时，我们会在X上加1，当X为0时，我们默认为开发或测试阶段。当x增加1时，我们将清除下面的Y.Z..我们用y来表示函数更新，同样，当y增加1时，我们将把下面的z清零。z表示轻微修改。比如我们修复一个bug，页面的UI布局会用Z修改调整，但是当Z等于10时，我们不会加到Y上，而是写成X.Y.10，然后更新为X.Y.11。

不同的项目会有不同的命名规则。这里只分享一个常用的命名规则，不能代表全部。

除了版本号之外，还会有一些修改的字样，比如:alpha:内部版本beta: beta版rc: lts:长期维护待发布为正式版本。

作为一个产品，很多时候我想让大家用名词，说人话。但是，身边总会有人为了显示自己是网络老鸟，会说缩写，从来不说中文。为了避免新人被这些黑话忽悠，不如干脆展开。

在思考阶段，首先作为一个产品，我们往往要负责功能和项目的调度。当大家都在小步快走做产品的时候，如果一个产品对版本管理有很深的理解，可以省去很多麻烦。

在开发版本之前，我们应该计划好我们将为这个版本做些什么，这将使我们清楚我们需要多少人，需要多长时间来完成这个计划。在开发版本的时候，要明确这个版本要解决哪些问题，要达到什么目标，这样才能有一个共同的目标，有一个明确的重点。版本开发完成后，我们需要了解哪些数据是我们需要重点关注的，之前的版本出现了哪些问题，这对我们验证需求很有帮助。而且我们要开始思考下一阶段应该怎么做。很多时候，作为产品经理，我们习惯把产品当成自己的孩子，这是一种很好的态度。那么，作为父母，我们应该更清楚自己的孩子长大后应该是什么样子。我们不能要求一个小学生去学物理化学，也要避免操之过急去鼓励别人。

这里我先抛出几个问题供大家思考:

某电商新品上线一个月，运营同学提出了一个通过用户签到获取优惠券的需求。计划一周后发射。合适吗？这个电商产品的后台工作人员提出了上传图片的操作流程有点繁琐的需求。希望能一键上传多张图，希望能尽快解决。在开发人员不足的情况下，是否应该给予高度重视，尽快解决？有一天，老板跟你说，最近有竞品发布了电商的直播功能。希望大家研究一下，抓紧时间做一个。要不要快速立项？

1.版本目标这些情况可能很常见。作为一个产品，我们每天都会面对来自四面八方的需求。每一个提出需求的人都希望自己的需求能很快得到解决。这时候我们会有一种进退两难的感觉，觉得自己不是这个产品的引领者，而是成为了一个需求工具人。大部分成长起来的产品经理都会经历这个阶段，摆脱困境。做了很多需求后，形成了自己的需求分析方法论，也解决了与老板和团队的沟通问题，从而获得了更好的执行力。但是大部分产品都处于两难的境地，大部分产品在方法和沟通上都或多或少存在问题。

在版本管理中，我们在更新一个版本的时候，要尽可能的明确更新的目的，建立一个共同的目标。

在数据分析中，有一种非常常见的模型叫做AARRR模型，也就是大家所熟知的海盗模型。它由五部分组成:获取、激活、保留、收入和推荐。在互联网思维日益成熟的今天，这种方法适用于大多数场景。

在这个经典的数据模型中，我们将整个对象分为五个部分，这五个部分相互依赖，形成一个循环。这些概念看起来都是运营方向的问题。在这里，我们将单独讨论数据。成功的产品往往有两个特点:不偏离用户需求，不偏离数据迭代。

这里我们简单提出一些在盗版模型中需要注意的数据，以及这些数据将如何指导我们的迭代。

(1)获取用户，也就是我们常说的拉新，一般是注册、下载、关注用户的行为。我们经常考虑增加新用户的数据。任何产品在推出之初都无法避免这个环节，它会持续伴随整个产品生命周期。一般我们在刚上线满足核心功能后，会重点关注和优化用户的注册路径，甚至通过不断的埋首来获取数据优化需求。

案例:回顾新浪微博最初的注册过程，需要绑定手机号、身份证、输入账号密码、机密邮箱等大量内容。第一次注册的时候。在后台数据埋点，不难发现很多用户因为信息繁琐，注册了一半就跳出了页面。随着版本的不断迭代，今天我们只需要输入账号和密码进行注册，只有在需要使用核心功能的时候才会需要绑定手机号和身份证等相关信息。这一更新无疑大大降低了用户的运营成本，更容易获取用户。

(2)激活用户也可以理解为我们常说的激活，一般是通过用户的在线时间、与其他用户的互动频率等数据来考虑的。在一个以内容为核心的社区产品中，初期用户的活跃度非常重要，甚至对产品未来的发展有着长远的影响。

案例:《Tik Tok》原版上线后，吸引了很多大学生通过各种渠道录制作品。其中大部分来自音乐学院、表演系等价值观突出的年轻人。这些用户的活跃和推广在用户心中留下了Tik Tok是一个高价值用户群体的印象。

回到我们前面提到的第一个问题，一般来说，一个新品上线一个月左右，运营的重点一般会放在拉新品这件事上。签到功能在更多情况下会增强我们的留存，对拉新品的作用可能没那么强。

(3)留存是指一段时间后，有多少用户留下来了。一般用户还是在月、周、日的时间维度上作为数据考量，也就是我们常说的DAU、WAU、MAU。

案例:留存在一些社区和游戏行业是非常重要的指标。当一个产品的用户留存越来越低的时候，即使带来新的用户，依然难以摆脱冷清的局面。根据王者荣耀的数据，非节假日期间用户留存率会下降。为了抢占用户时间，促进留存，经常会发布签到送皮肤和钻石金币等任务。

(4)一般情况下，取得收入会被理解为变现。这一步，我的理解是不仅开发者可以实现收益，用户也可以在这一步获得收益。

案例:为了更好地促进用户的优质内容创作，知乎新增了付费问答等功能。这些功能让用户有更强的动力持续输出内容，同时也给平台带来一些收益。

(5)自传播是指用户可以自发的向身边的用户推荐我们的产品。

案例:拼多多采用了“分组”的模式，让用户获得优惠和福利，进一步激发了用户与身边人分享的动力，强化了产品本身的传播和用户的贡献。

在定义了版本更新的目的和目标之后，我们应该记住一些功能优先级。

2.版本中需求的优先级。我在做版本管理的时候会习惯把需求分成五种类型。

(1)关键需求

一般情况下，我们会把这个需求的优先级设为P0。不满足这个要求会导致整个版本无法正常上线或者毁掉之前的所有努力。

以一款全新的电商产品为例。一般来说，电商购物APP的一般关键需求会有两个需求:支付和订单。

(2)跟进关键需求

一般这种需求不会影响前期项目的进度，但是如果不满足，后期版本就无法正常上线。

案例:电商购物产品计划在1.1.0版本推出用户积分，以用户消费金额累计积分。那么在1.0.0，用户完成订单的记录就是后续的重点需求。没有这些记录，我们无法计算用户获得多少积分。

(3)后续重要性要求

一般这种需求会影响用户的体验或者项目人员的工作价值，如果得不到满足就会导致用户的“外逃”或者同事的购物。

案例:电商产品在1.1.0版本如期推出用户积分，运营商原本打算让用户在这里用积分兑换优惠券。此时，这个需求属于后续的重要性需求。但是在这个版本中并没有获得，用户看着自己的积分就觉得产品在“耍猴”，于是就逃跑了，运营商因为完成不了kpi就和产品打起来了。

(4)改进需求

一般这个要求不会影响现有功能的使用，如果实现了会更好。如果不满意，可能会导致用户满意度或同事成就感降低。

案例:运营同学和产品的一次亲密会议后，紧急完成优惠券功能的开发并上线。当时由于需求迫切，UI同学觉得之前的设计有点粗糙，优化了积分和优惠券的交互操作，精心设计了一个更漂亮的页面。这时候更漂亮的页面，更好的交互体验，就是提升的要求。

(5)可选要求

这种需求一般是一种想象中的或者有待验证的需求，大多数情况下是探索和尝试，或者是个别客户的需求。

案例:优惠券上线后的用户调查中，一位核心用户提出增加优惠券的获取途径。此时，需求是可选的。

回过头来看我们谈到的第二个问题，这是新人经常感到尴尬的事情。在换位思考的模式下，我们考虑到目前后台工作人员的工作确实有些繁琐，会影响后台学员的工作效率，是应该为他们解决的需求。另一方面，开发人员短缺，被各种需求和进度压力压得喘不过气来。前台和后台的要求不断进来，看着学生稀疏的头发有点受不了。这是一个复杂的情况，我们将从几个角度考虑这个问题应该优先处理。首先是背景生在当前情况下能否保质保量完成任务，这个需求是重点需求之一还是当前阶段的后续需求。

3.快速迭代。我们谈到了产品经理的各种技能。再来说说产品经理的方式。很多成功的产品往往被称为有灵魂的产品，比如乔布斯的Iphone，张小龙的微信，雷军的小米，罗永浩的锤子，王石木的网易云。这些产品都倾注了心血，甚至在一些细微之处表现出了对产品乃至人性的思考。

很多时候，我们的需求方可能不仅仅是用户，运营有时候也来自老板。在这种情况下，我们也要把老板当成我们的用户之一。在面对这个用户的时候，也要思考用户诉求背后的动机，以及更深层次的需求。比如老板在这件事上会不会有更多的资源或者长期布局？

网上有各种如何解决老板需求的讨论，这里就不赘述了。综上所述，大多数实践都是采用MVP模式进行产品开发。MVP模型是指可用的最小产品模型，旨在以最低的成本满足核心功能，进行市场尝试。在座的各位都有一个熟悉的产品迭代记录——微信。

打开今天的微信，我们发现我们可以在上面做任何事情。我们可以订机票和酒店，报销女朋友的账单，免去陪逛街的苦恼。我们甚至可以黑女朋友，让朋友帮忙推荐一个新女朋友..回想一下微信在线的第一个版本，当时非常简单，只有两个功能，发消息和图片。

微信的每一个版本都是今天讲的，而这背后，我想提醒大家不要忘记时间。微信第一版发布于2011年。经历了移动互联网从2.5G到3G甚至4G的老前辈们，只要在网上做一个产品，一定还记得用户的时代。

有很多老产品会告诉新人，不要等到产品完善了再上线。从来没有完美的产品。我非常同意这一点，但我们应该正确理解在什么情况下产品是完美的？我们知道，产品经理并不是一个很古老的职业，尤其是在如今的互联网环境下，每个人的学习路径都不一样。我曾经问过几个产品新人，发现他们看过的书都出奇的一致，掌握的方法和理论都一样。这可能是一个非常稳妥的做产品的方式，但是一个好的产品确实需要创新，做产品的方法也需要与时俱进的不断迭代。

4.精益迭代过去10年，我们见证了互联网的飞速发展，用户的习惯培养的越来越成熟，用户的口味也越来越精致。试想一下，如果你今天看到了朋友发来的照片或视频，但此时你却无法喜欢评论，你还会认可这款产品吗？

MVP模型是一种合理的市场试用方法，但不一定适用于今天所有的产品。比如Twitter刚推出的时候，用户体验就已经很完善了。这几年黑马产品很多，拼多多在淘宝场景升级的情况下，找到了一个下沉的用户市场杀出一条血路。在播放器软件成熟的时代，网易以极致的用户体验杀出一条血路。这些其实都是长尾市场的创新。

回过头来看第三个问题，老板看到竞品在做某个功能，本能的回过头去分析商业模式，这是一个老板的责任。但是电子商务发展了十几年，直播行业已经很成熟了。今天大部分用户的需求差不多解决了，留给我们的是长尾需求。然而，两个成熟系统和行业的创新组合是否真的可以通过一个最小的产品模型来实现，这是一个有待商榷的问题。

随着互联网环境的成熟，各行各业的互联网产品已经形成头部效应，留给我们的机会大多是通过整合或者差异化创新来做一个新产品。

尤其是在融合两个行业的时候，不要忘记用户的心理路径需要形成闭环。比如我们做这个电商直播产品，要知道我们面对的用户是双向的，既有主播，也有粉丝。我们的功能也是双面的，就是直播和电商。对于直播来说，主播的上升通道极其重要，粉丝的奖励性关注和互动功能也是这个产品的根本。

在用户的操作过程已经成为习惯，用户心智模型已经建立的情况下，哪怕是微乎其微，我们也需要给用户提供一个完整的入口和出口。

5.有趣的事情分享一下。这里还有一个有趣的事情想和大家分析一下。说到版本和迭代，肯定还有另一件困扰产品的事情。我们推出体验更好的新版本，用户不愿意下载更新怎么办？

你还记得微信的飞机大战吗？

2013年8月，微信更新版本至5.0版本，增加了绑定银行卡功能、表情商店等重要更新，这也意味着微信正式开放了支付、收费等部分相关功能。为了尽快测试版本的一些重要目标数据和用户的反馈，产品一定都希望用户尽快把版本更新到最新。

回到那个时代，我们经常遇到的应用版本更新是什么？当时几乎都是马上更新关闭，甚至后期更新都很少。在闪退不更新的时代，微信用一种非常优雅的姿态说服用户主动完成更新——飞机大战。

微信作为一个社交产品，在当时拥有巨大的用户优势。微信利用了社交产品中用户的输赢欲、好奇心等心理，帮助用户宣传这个版本的更新。

还记得那一天，无数个人突然出现在自己的飞机大战朋友圈里，于是在这种用户交流下，大家都主动更新。

同样，微信在更新小程序时也推出了跳转，再次引爆了朋友圈和更新热潮。

最后，产品迭代的时候需要考虑的事情很多，比如现在的互联网环境，用户的习惯和口味，用户群体的特征画像，自身的技术实力等诸多因素。今天，产品本身也在根据时代和环境不断迭代，产品经理自身的方法和思维也需要不断更新迭代。

如何快速推动需求前进，是产品永恒的话题。在这里，我总结了一些经常导致我们拖慢项目进度的原因。

所有的需求都是衔接的，需求的优先级没有安排好，与需求方或者开发方的沟通没有做好，版本的侧重点没有安排好，不清楚产品什么时候可以上线。这些问题对于一个新人的产品来说可能是很常见的，所以希望你少走弯路，少走坑。最后附上这篇文章的注释。

本文由@体验杂货店原创发布。大家都是产品经理，未经作者允许，禁止转载。

题目来自Unsplash，基于CC0协议。