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）在现今互联网思维越发成熟的今天这个 *** 适用于绝大多数场景。