产品版本号是若何确定的？一文教你看懂产品迭代机制

随着互联网行业的发展越来越快，几天一次大更新，无时无刻不在小更新的产品越来越多，但我们常常会见到一些公司对付版本的管理及其混乱。
一次我的一个码农朋友跟我讲他在的那家公司完备不理解版本是什么，修复一个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在最初的上线时用户的体验就已经很完全了。
近几年杀出的黑马产品有很多，拼多多在淘宝场景升级的情形下找到了下沉用户的市场杀出一条血路。
网易云在播放器软件成熟的时期以极致的用户体验杀出了一条血路来，这些实在都是在长尾市场中进行创新。

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

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

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

在用户的操作流程已经形成习气，用户的心智模型也已经建立起来的情形下，纵然再极简也须要我们为用户供应完全的入口和出口。

5. 趣事分享

这里还有一个小趣事想和大家剖析，提及版本与迭代一定也还有一件事情困扰着产品，当我们推出了体验更好的新版本时用户却不愿意下载更新怎么办？

大家是否还记得微信的飞机大战？

在2013年8月微信将版本更新到了5.0版本，这一版本加入了绑定银行卡功能和表情商店等主要更新，这也意味着微信正式开启了支付和收费的一些干系功能。
为了尽快测试到版本的一些主要目标数据和用户的反馈，产品们一定都非常希望用户尽快的将版本更新到最新。

回向一下那个时期我们常常遇见的运用版本更新是什么样的？那个时候险些都是立即更新和关闭，连稍后更新都少只有少。
在那个不更新就闪退的时期微信用了一个及其优雅的姿态劝用户主动完成了更新——飞机大战。

微信作为一个社交产品在当时有着巨大的用户上风，微信利用了社交产品中用户的胜负欲、好奇心等生理奥妙的让用户帮忙宣扬了这一版本的更新。

还记得那天朋友圈溘然涌现了无数个人在发自己飞机大战的战绩，于是在这种用户传播下大家纷纭主动进行了更新。

同理，微信在更新小程序的时候也推出了跳一跳，又一次引爆了朋友圈和更新热潮。

末了的一点思考

产品在进行迭代时要考量的事情有很多很多，当下的互联网环境，用户的习气和口味，用户群的特色画像， 自身的技能实力等等非常多的成分。
在产品本身根据时期和环境的不断迭代的本日，产品经理自身的方法和思维也是须要不断进行更新与迭代的。

如何快速的将需求推进是产品们永恒的话题。
这里我总结了一些常常会导致我们对付项目进度推进慢的缘故原由。

什么需求都接没有合理安排好需求的优先级没有很好的与需求方或开拓方做好沟通没有安排好版本的侧重点没有搞清楚产品什么时候可以上线

以上这些问题可能对付一个新人产品是非常常见的，抛砖引玉一些望大家少走弯路少采坑，末了附上本篇的条记。

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

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