产品版本号是如何确定的？一文教你看懂产品迭代机制（极简方块快跑）

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: 测试版 rc: 即将作为正式版发布 lts: 长期维护

作为一个产品很多时候我希望大家名词，讲人话。奈何身边总会有人为了显示自己是互联网老鸟，能说缩写的绝对不会说中文。为了避免新人被这些黑话唬住，还是简单的拓展一下。

思考阶段

首先我们作为产品很多时候也要对功能和项目的排期负责，在大家都在小步快跑做产品时，如果一个产品对于版本的管理理解深刻的话，可以省去不少麻烦。

在版本开发前我们要计划出这一版本我们要做什么，这会让我们明确我们需要多少人手，需要多长时间来完成这次的计划。
在版本开发时我们要明确这一版本我们要集中解决哪些问题，达成什么样的目标，这会让我们有共同的目标和清晰的侧重点。
在版本开发后我们要明确上一版本中我们需要重点关注哪些数据和出现了哪些问题，这对我们验证需求有很大的帮助。并且我们还要着手去思考下一阶段我们应该做什么。

很多时候我们作为产品经理会习惯将自己的产品视作自己的孩子，这是很好的心态。那么我们作为家长，更应该清楚自己的孩子在成长中应该在什么阶段是什么样子，我们不能要求一个小学生去学习物理化学，切忌操之过急拔苗助长。

在这里我先抛出几个问题来供大家思考一下：

一款电商新产品上线了一个月，运营同学提出一个通过用户签到获得优惠券的需求，计划在一星期后上线，是否合适？
这款电商产品的后台人员提出需求说上传图片时的操作流程有些繁琐，希望可以一键上传多张图片，并且盼望能够尽快解决，在开发人手不足的情况下是否要定为高优先级尽快解决？
有天老板对你说，竞品最近发布了电商直播功能，希望我们研究一下抓紧时间也搞一个出来，要不要赶紧立项实现？

1. 版本目标

这几种情况可能是非常常见的，身为一个产品我们每天会面对来自四面八方的需求，每个提出需求的人都希望自己的需求能赶紧解决。这时我们会有一种进退两难的感觉，觉得自己并不是在主导这款产品，反而成了一个需求工具人。大部分成长起来的产品经理都会经历这样的阶段并且摆脱了进退两难的境地，他们在做了很多需求后形成了自己的需求分析方法论，也搞定了与老板和团队的沟通问题，从而获得了更好的执行力。而大部分的产品都倒在了进退两难这一关，大多是在方法上和沟通上存在着或多或少的问题。

在版本管理中，我们进行一次版本更新时应该尽可能的明确更新目的，树立共同目标。

在数据分析中有一个很常见的模型叫做AARRR模型，也就是我们常说的海盗模型。它由五部分组成，获取用户（Acquisition）、激活用户（Activation）、提高留存（Retention）、获取收入（Revenue）、自传播（Referral）在现今互联网思维越发成熟的今天这个方法适用于绝大多数场景。

在这个经典的数据模型中我们把目标的整体分成了五个部分，它们相互依托以此来形成循环。这些拉新促活留存这些概念看起来似乎都是运营方向的问题，这里我们单就数据来讨论。成功的产品往往都会有两个特征，没有脱离用户的需求，没有脱离数据的迭代。

这里我们简单的提出一些关于海盗模型中我们需要关注的数据以及这些数据对我们迭代会有哪些指导。

（1）获取用户也就是我们常说的拉新，一般是用户的注册、下载、关注等行为。我们常以新增用户这一数据来作为考量。任何一款产品上线之初都避不开这个环节，而且拉新这件事会持续的伴随整个产品生命周期。一般在我们刚刚上线满足了核心功能后会重点关注并优化用户的注册路径，甚至通过不断的埋点来获取数据优化需求。

案例：回想最初新浪微博的注册流程，我们需要在第一次注册时绑定手机号、身份证、输入账号密码保密邮箱等等非常多的内容，在后台的数据埋点中我们不难发现因为这些信息的繁琐导致不少用户在注册了一半的情况下就跳出了页面。随着版本的不断迭代，在今天我们的注册只需要输入账号和密码即可，只有在需要用到核心功能时才会需要我们绑定手机号和身份证等相关信息。这一更新无疑大大降低了用户的操作成本，让获取用户变得更容易。

（2）激活用户也可以理解为我们常说的促活，一般会以用户的在线时长、与其他用户的互动频次等数据来做以考量。在一款以内容为核心的社区产品，初期用户的活跃度是至关重要的，甚至对产品以后的发展会有很长远的影响。

案例：在抖音最初的版本上线时通过各种渠道吸引了很多在校的大学生录制作品，她们大多来自于音乐学院，表演系等颜值出众的年轻人。这些用户的活跃与推广为抖音在用户的心里留下了一个高颜值用户群体的印象。

回顾前面我们说到的第一个问题，在一般情况下新产品上线一个月左右时运营的重心一般会关注在拉新一事上，签到功能更多情况下会提升我们的留存，对于拉新的效果可能并不那么强烈。

（3）留存是指在经过一段时间后有多少用户留了下来，一般情况下会以月、周、日的时间维度中用户仍然使用来作为数据考量，也就是我们常说的DAU、WAU和MAU。

案例：在一些社区及游戏行业中留存是一个相当重要的指标，当一款产品的用户留存越来越低，即使有拉新用户进来也依然难以摆脱冷清的局面。根据王者荣耀的数据发现，在非长假期间用户的留存率会出现下降的情况，为了抢占用户的时间促进留存，经常会发布诸如签到送皮肤送钻石金币等任务活动。

（4）获取收入在一般情况下和会被理解为变现。在这一步骤中我的理解是不止开发方获得收入变现，用户也可以在这一步获得利益。

案例：知乎为了更好的促进用户进行高质量内容创作增加了付费问答等功能，这些功能让用户有更强烈的动机去进行持续的内容输出的同时也为平台带来了部分收益。

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

案例：拼多多采取了拼团模式让用户获取到折扣和优惠的同时进一步刺激了用户分享给身边人的动机，加强了产品本身的传播性和用户贡献度。

在明确了版本更新目的和目标后，我们心里就应该对大部分的功能优先级有了数。

2. 版本中的需求优先级

在进行版本管理时我会习惯将需求分成5种类型。

（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在最初的上线时用户的体验就已经很完整了。近几年*出的黑马产品有很多，拼多多在淘宝场景升级的情况下找到了下沉用户的市场*出一条血路。网易云在播放器软件成熟的时代以极致的用户体验*出了一条血路来，这些其实都是在长尾市场中进行创新。

我们回顾第三个问题，老板看到竞品在做某一功能时本能的回去分析商业模式，这是身为一个老板的责任。但是在电商已经发展了十几年，直播行业也已经做的都非常成熟的今天，大部分用户的需求都被解决的差不多了，留给我们的往往都是些长尾需求。而在两个成熟体系和行业中进行一次合璧创新是否真的能用一个极简的产品模型来跑通是有待商榷的。

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

尤其在对两个行业进行合璧整合时，千万不要忘记用户的心理路径是需要形成闭环的。比如当我们做这款电商直播产品的时候我们要知道，我们面向的用户是双向的，既有主播也有粉丝。我们的功能也是两方面的，即有直播又有电商。对于直播来讲主播的上升通道是及其重要的，粉丝的打赏关注和互动功能也是这款产品的立身之本。

在用户的操作流程已经形成习惯，用户的心智模型也已经建立起来的情况下，即使再极简也需要我们为用户提供完整的入口和出口。