在大部分情况下常见的版本号是三段式的，即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。

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

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

（1）关键性需求

在一般情况下我们会将这种需求的优先级定为P0，如果不能完成这个需求将会导致整个版本不能正常上线，或毁灭之前的所有努力。

一般情况下电商购物APP的通用关键性需求都会有支付和订单这两种需求。

（2）后续关键性需求

这种需求一般不会影响前面的项目进展，但是如果不加以满足的话将导致后面的版本无法正常上线。

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

（3）后续重要性需求

这种需求一般情况下是会影响用户的体验或项目人员的工作价值，如果没有满足的话会导致用户“出逃”或同事血拼。

案例：该电商产品如期在1.1.0版本推出了用户积分，运营人员本来打算在这里让用户以积分来兑换优惠券。此时该需求就属于后续重要性需求。但是没有在这个版本中得到，用户看着自己的积分没有消耗途径觉得该产品在“耍猴儿”，于是出逃，运营人员因为没法完成kpi而与产品大打出手。

（4）改良性需求

这种需求一般情况下不会影响已有功能的使用，如果实现了会更好。如果没有满足的话可能会造成用户的满意度下降或同事的成就感降低。

案例：在运营同学和产品的一番亲密会晤后紧急完成了优惠券功能的开发并上线。由于当时需求太急，UI的同学觉得之前的设计有些粗糙，优化了积分与优惠券的交互操作并用心设计了更美观的页面。这个时候更美观的页面和更优的交互体验就属于改良性需求。

（5）可选性需求

这种需求一般为一种设想或待验证的需求，大多情况下为探索和尝试，抑或是个别客户的需求。

案例：在优惠券上线之后的用户调研中有一名核心用户提出希望增加优惠券的获取途径。这时该需求就属于可选性需求。