2.3.9之后再改就是2.4.0？產(chǎn)品的版本號是如何確定的？什么時候會多加一個？每當(dāng)一個產(chǎn)品更新是，你是否也有這樣的疑問？本文作者依據(jù)工作中項目實踐的所思所想，并結(jié)合案例等分享了產(chǎn)品迭代過程中需要注意的關(guān)鍵點(diǎn)，供大家一同參考和學(xué)習(xí)。

隨著互聯(lián)網(wǎng)行業(yè)的發(fā)展越來越快，幾天一次大更新，無時無刻不在小更新的產(chǎn)品越來越多，但我們經(jīng)常會見到一些公司對于版本的管理及其混亂。一次我的一個碼農(nóng)朋友跟我講他在的那家公司完全不理解版本是什么，修復(fù)一個bug更新一個彈窗都會當(dāng)做版本更新，在上線一個月以后已經(jīng)把APP的版本更新到了2.3.0。

開始聽到這個事情時我還當(dāng)做是一個笑話，后來發(fā)現(xiàn)這種情況其實并不罕見。

常識類概念

常見的版本號命名規(guī)則

在這里先簡單的和大家聊一下關(guān)于版本的常見命名規(guī)則和幾種類型。

在大部分情況下常見的版本號是三段式的，即X.Y.Z 我們用X來表示大版本號，一般當(dāng)產(chǎn)品出現(xiàn)重大更新、重寫、不再向后兼容的情況時我們會在X上加1，當(dāng)X是0的時候我們默認(rèn)為開發(fā)或測試階段。當(dāng)X增加1時我們會把后面的Y.Z清零。 我們用Y來表示功能更新，同理當(dāng)Y增加1時我們也會將后面的Z清零。 Z則表示小修改，如我們修復(fù)了一個bug，頁面的UI布局做了修改調(diào)整時都會增加Z，但是當(dāng)Z等于10時我們不增加到Y(jié)，而是寫成X.Y.10，之后的更新為X.Y.11。

在不同的項目也會有不同的命名規(guī)則，這里只做一種常見的命名規(guī)則分享，并不能代表全部。

除了版本號之外還會有一些修飾的詞，比如： alpha: 內(nèi)部版本 beta: 測試版 rc: 即將作為正式版發(fā)布 lts: 長期維護(hù)

作為一個產(chǎn)品很多時候我希望大家名詞，講人話。奈何身邊總會有人為了顯示自己是互聯(lián)網(wǎng)老鳥，能說縮寫的絕對不會說中文。為了避免新人被這些黑話唬住，還是簡單的拓展一下。

思考階段

首先我們作為產(chǎn)品很多時候也要對功能和項目的排期負(fù)責(zé)，在大家都在小步快跑做產(chǎn)品時，如果一個產(chǎn)品對于版本的管理理解深刻的話，可以省去不少麻煩。

• 在版本開發(fā)前我們要計劃出這一版本我們要做什么，這會讓我們明確我們需要多少人手，需要多長時間來完成這次的計劃。
• 在版本開發(fā)時我們要明確這一版本我們要集中解決哪些問題，達(dá)成什么樣的目標(biāo)，這會讓我們有共同的目標(biāo)和清晰的側(cè)重點(diǎn)。
• 在版本開發(fā)后我們要明確上一版本中我們需要重點(diǎn)關(guān)注哪些數(shù)據(jù)和出現(xiàn)了哪些問題，這對我們驗證需求有很大的幫助。并且我們還要著手去思考下一階段我們應(yīng)該做什么。

很多時候我們作為產(chǎn)品經(jīng)理會習(xí)慣將自己的產(chǎn)品視作自己的孩子，這是很好的心態(tài)。那么我們作為家長，更應(yīng)該清楚自己的孩子在成長中應(yīng)該在什么階段是什么樣子，我們不能要求一個小學(xué)生去學(xué)習(xí)物理化學(xué)，切忌操之過急拔苗助長。

在這里我先拋出幾個問題來供大家思考一下：

1. 一款電商新產(chǎn)品上線了一個月，運(yùn)營同學(xué)提出一個通過用戶簽到獲得優(yōu)惠券的需求，計劃在一星期后上線，是否合適？
2. 這款電商產(chǎn)品的后臺人員提出需求說上傳圖片時的操作流程有些繁瑣，希望可以一鍵上傳多張圖片，并且盼望能夠盡快解決，在開發(fā)人手不足的情況下是否要定為高優(yōu)先級盡快解決？
3. 有天老板對你說，競品最近發(fā)布了電商直播功能，希望我們研究一下抓緊時間也搞一個出來，要不要趕緊立項實現(xiàn)？

1. 版本目標(biāo)

這幾種情況可能是非常常見的，身為一個產(chǎn)品我們每天會面對來自四面八方的需求，每個提出需求的人都希望自己的需求能趕緊解決。這時我們會有一種進(jìn)退兩難的感覺，覺得自己并不是在主導(dǎo)這款產(chǎn)品，反而成了一個需求工具人。大部分成長起來的產(chǎn)品經(jīng)理都會經(jīng)歷這樣的階段并且擺脫了進(jìn)退兩難的境地，他們在做了很多需求后形成了自己的需求分析方法論，也搞定了與老板和團(tuán)隊的溝通問題，從而獲得了更好的執(zhí)行力。而大部分的產(chǎn)品都倒在了進(jìn)退兩難這一關(guān)，大多是在方法上和溝通上存在著或多或少的問題。

在版本管理中，我們進(jìn)行一次版本更新時應(yīng)該盡可能的明確更新目的，樹立共同目標(biāo)。

在數(shù)據(jù)分析中有一個很常見的模型叫做AARRR模型，也就是我們常說的海盜模型。它由五部分組成，獲取用戶（Acquisition）、激活用戶（Activation）、提高留存（Retention）、獲取收入（Revenue）、自傳播（Referral）在現(xiàn)今互聯(lián)網(wǎng)思維越發(fā)成熟的今天這個方法適用于絕大多數(shù)場景。

在這個經(jīng)典的數(shù)據(jù)模型中我們把目標(biāo)的整體分成了五個部分，它們相互依托以此來形成循環(huán)。這些拉新促活留存這些概念看起來似乎都是運(yùn)營方向的問題，這里我們單就數(shù)據(jù)來討論。成功的產(chǎn)品往往都會有兩個特征，沒有脫離用戶的需求，沒有脫離數(shù)據(jù)的迭代。

這里我們簡單的提出一些關(guān)于海盜模型中我們需要關(guān)注的數(shù)據(jù)以及這些數(shù)據(jù)對我們迭代會有哪些指導(dǎo)。

（1）獲取用戶也就是我們常說的拉新，一般是用戶的注冊、下載、關(guān)注等行為。我們常以新增用戶這一數(shù)據(jù)來作為考量。任何一款產(chǎn)品上線之初都避不開這個環(huán)節(jié)，而且拉新這件事會持續(xù)的伴隨整個產(chǎn)品生命周期。一般在我們剛剛上線滿足了核心功能后會重點(diǎn)關(guān)注并優(yōu)化用戶的注冊路徑，甚至通過不斷的埋點(diǎn)來獲取數(shù)據(jù)優(yōu)化需求。

案例：回想最初新浪微博的注冊流程，我們需要在第一次注冊時綁定手機(jī)號、身份證、輸入賬號密碼保密郵箱等等非常多的內(nèi)容，在后臺的數(shù)據(jù)埋點(diǎn)中我們不難發(fā)現(xiàn)因為這些信息的繁瑣導(dǎo)致不少用戶在注冊了一半的情況下就跳出了頁面。隨著版本的不斷迭代，在今天我們的注冊只需要輸入賬號和密碼即可，只有在需要用到核心功能時才會需要我們綁定手機(jī)號和身份證等相關(guān)信息。這一更新無疑大大降低了用戶的操作成本，讓獲取用戶變得更容易。

（2）激活用戶也可以理解為我們常說的促活，一般會以用戶的在線時長、與其他用戶的互動頻次等數(shù)據(jù)來做以考量。在一款以內(nèi)容為核心的社區(qū)產(chǎn)品，初期用戶的活躍度是至關(guān)重要的，甚至對產(chǎn)品以后的發(fā)展會有很長遠(yuǎn)的影響。

案例：在抖音最初的版本上線時通過各種渠道吸引了很多在校的大學(xué)生錄制作品，她們大多來自于音樂學(xué)院，表演系等顏值出眾的年輕人。這些用戶的活躍與推廣為抖音在用戶的心里留下了一個高顏值用戶群體的印象。

回顧前面我們說到的第一個問題，在一般情況下新產(chǎn)品上線一個月左右時運(yùn)營的重心一般會關(guān)注在拉新一事上，簽到功能更多情況下會提升我們的留存，對于拉新的效果可能并不那么強(qiáng)烈。

（3）留存是指在經(jīng)過一段時間后有多少用戶留了下來，一般情況下會以月、周、日的時間維度中用戶仍然使用來作為數(shù)據(jù)考量，也就是我們常說的DAU、WAU和MAU。

案例：在一些社區(qū)及游戲行業(yè)中留存是一個相當(dāng)重要的指標(biāo)，當(dāng)一款產(chǎn)品的用戶留存越來越低，即使有拉新用戶進(jìn)來也依然難以擺脫冷清的局面。根據(jù)王者榮耀的數(shù)據(jù)發(fā)現(xiàn)，在非長假期間用戶的留存率會出現(xiàn)下降的情況，為了搶占用戶的時間促進(jìn)留存，經(jīng)常會發(fā)布諸如簽到送皮膚送鉆石金幣等任務(wù)活動。

（4）獲取收入在一般情況下和會被理解為變現(xiàn)。在這一步驟中我的理解是不止開發(fā)方獲得收入變現(xiàn)，用戶也可以在這一步獲得利益。

案例：知乎為了更好的促進(jìn)用戶進(jìn)行高質(zhì)量內(nèi)容創(chuàng)作增加了付費(fèi)問答等功能，這些功能讓用戶有更強(qiáng)烈的動機(jī)去進(jìn)行持續(xù)的內(nèi)容輸出的同時也為平臺帶來了部分收益。

（5）自傳播是指用戶可以自發(fā)的向身邊用戶推薦我們的產(chǎn)品。

案例：拼多多采取了拼團(tuán)模式讓用戶獲取到折扣和優(yōu)惠的同時進(jìn)一步刺激了用戶分享給身邊人的動機(jī)，加強(qiáng)了產(chǎn)品本身的傳播性和用戶貢獻(xiàn)度。

在明確了版本更新目的和目標(biāo)后，我們心里就應(yīng)該對大部分的功能優(yōu)先級有了數(shù)。

2. 版本中的需求優(yōu)先級

在進(jìn)行版本管理時我會習(xí)慣將需求分成5種類型。

（1）關(guān)鍵性需求

在一般情況下我們會將這種需求的優(yōu)先級定為P0，如果不能完成這個需求將會導(dǎo)致整個版本不能正常上線，或毀滅之前的所有努力。

這里以一個全新的電商產(chǎn)品舉例，一般情況下電商購物APP的通用關(guān)鍵性需求都會有支付和訂單這兩種需求。

（2）后續(xù)關(guān)鍵性需求

這種需求一般不會影響前面的項目進(jìn)展，但是如果不加以滿足的話將導(dǎo)致后面的版本無法正常上線。

案例：電商購物產(chǎn)品計劃在1.1.0版本時推出用戶積分，以用戶的消費(fèi)金額累計獲得積分。那么在1.0.0時用戶的已完成訂單記錄就是后續(xù)關(guān)鍵性需求，如果沒有這些記錄我們將無法計算用戶獲得了多少積分。

（3）后續(xù)重要性需求

這種需求一般情況下是會影響用戶的體驗或項目人員的工作價值，如果沒有滿足的話會導(dǎo)致用戶“出逃”或同事血拼。

案例：該電商產(chǎn)品如期在1.1.0版本推出了用戶積分，運(yùn)營人員本來打算在這里讓用戶以積分來兌換優(yōu)惠券。此時該需求就屬于后續(xù)重要性需求。但是沒有在這個版本中得到，用戶看著自己的積分沒有消耗途徑覺得該產(chǎn)品在“耍猴兒”，于是出逃，運(yùn)營人員因為沒法完成kpi而與產(chǎn)品大打出手。

（4）改良性需求

這種需求一般情況下不會影響已有功能的使用，如果實現(xiàn)了會更好。如果沒有滿足的話可能會造成用戶的滿意度下降或同事的成就感降低。

案例：在運(yùn)營同學(xué)和產(chǎn)品的一番親密會晤后緊急完成了優(yōu)惠券功能的開發(fā)并上線。由于當(dāng)時需求太急，UI的同學(xué)覺得之前的設(shè)計有些粗糙，優(yōu)化了積分與優(yōu)惠券的交互操作并用心設(shè)計了更美觀的頁面。這個時候更美觀的頁面和更優(yōu)的交互體驗就屬于改良性需求。

（5）可選性需求

這種需求一般為一種設(shè)想或待驗證的需求，大多情況下為探索和嘗試，抑或是個別客戶的需求。

案例：在優(yōu)惠券上線之后的用戶調(diào)研中有一名核心用戶提出希望增加優(yōu)惠券的獲取途徑。這時該需求就屬于可選性需求。

回顧我們說到的第二個問題，這是新人產(chǎn)品經(jīng)常會覺得為難的一件事。在同理心模式下我們考慮到了后臺人員的工作確實在目前有些繁瑣，這會影響后臺同學(xué)的工作效率，而且是應(yīng)該為其解決的需求。另一方面開發(fā)的人手不足，被各種需求和排期壓的喘不過氣來，前臺和后臺的需求不斷進(jìn)來看著開發(fā)同學(xué)們稀疏的頭發(fā)著實有點(diǎn)不忍心。這個情況是一件比較復(fù)雜的事情，我們將幾個角度來考慮這件事應(yīng)該拍在一個什么優(yōu)先級上面。首先是后臺同學(xué)在目前的情況下是否能保質(zhì)保量的完成任務(wù)，該需求在目前階段是關(guān)鍵性需求還是后續(xù)性需求中的一個。

3. 快速迭代

前面談到了產(chǎn)品經(jīng)理的各種術(shù)，我們也來聊一聊產(chǎn)品經(jīng)理的道。很多成功的產(chǎn)品往往都會被人稱為是有靈魂的產(chǎn)品，比如喬布斯的Iphone、張小龍的微信、雷軍的小米、羅永浩的錘子、王師沐的網(wǎng)易云。這些產(chǎn)品傾注了他們的心血甚至在一些細(xì)微處也展現(xiàn)了他們對于產(chǎn)品甚至人性的思考。

很多時候我們的需求方可能不只是用戶、運(yùn)營也有時候會來自于老板。在這種情況下我們也要把老板當(dāng)做我們的一個用戶，在面對這位用戶時我們也要思考用戶提出的需求背后的動機(jī)和更深層次的需求。比如老板是不是會在這件事上有更多的資源或長遠(yuǎn)布局？

關(guān)于老板的需求如何解決在網(wǎng)上有各種各樣的討論，這里就不做過多的贅述了，總結(jié)下來大多數(shù)的做法就是會采用MVP模型來進(jìn)行一次產(chǎn)品開發(fā)。MVP模型是指最小可用產(chǎn)品模型，旨在用最低的成本來滿足核心功能做市場嘗試。說到這里每個人都有一個耳熟能詳?shù)漠a(chǎn)品迭代記錄——微信。

打開今天的微信，我們發(fā)現(xiàn)我們可以在微信上面做一切事情。我們可以訂機(jī)票訂酒店，給女朋友報銷賬單而免去陪逛街的苦惱，甚至我們還可以將女朋友拉黑再找朋友幫忙推薦一個新女朋友..回想微信上線的第一個版本，那時很簡陋，只有兩個功能，發(fā)信息和圖片。

微信的每個版本到今天都被人津津樂道，在這背后我要提醒大家千萬不要忘了時間，微信的第一個版本發(fā)布于2011年。經(jīng)歷過那個移動互聯(lián)網(wǎng)從2.5G到3G甚至到4G的老前輩們一定都還記得那個互聯(lián)網(wǎng)跑馬圈地，只要做出一個產(chǎn)品上線就有用戶的時代。

有很多老產(chǎn)品會告訴新人，不要等到產(chǎn)品完美了再上線，從來都不存在完美的產(chǎn)品。這一點(diǎn)我也無比同意，但是我們要正確的理解產(chǎn)品在什么情況下才是完美？我們知道，產(chǎn)品經(jīng)理這個行業(yè)并不是一個很古老的職業(yè)，尤其在現(xiàn)今的互聯(lián)網(wǎng)環(huán)境下大家的學(xué)習(xí)路徑都不盡相同。我曾經(jīng)問過幾個產(chǎn)品新人，發(fā)現(xiàn)大家讀過的書都驚奇的一致，掌握的方法和理論也都非常相同。這可能是一種非常穩(wěn)妥的做產(chǎn)品的辦法，但是好產(chǎn)品確實需要創(chuàng)新，做產(chǎn)品的方法也需要跟著時代不斷的迭代。

4. 精益迭代

在這近10年的光陰里我們見證了互聯(lián)網(wǎng)的飛速發(fā)展，用戶的習(xí)慣被培養(yǎng)的越來越成熟，用戶的口味也越來越刁鉆。試想一下如果今天的你看到朋友發(fā)的照片或視頻，而你在這時卻不能點(diǎn)贊評論，你還會認(rèn)可這款產(chǎn)品嗎？

MVP模型是一種合理的市場嘗試方法，但在今天不一定適用于所有的產(chǎn)品。比如Twitter在最初的上線時用戶的體驗就已經(jīng)很完整了。近幾年殺出的黑馬產(chǎn)品有很多，拼多多在淘寶場景升級的情況下找到了下沉用戶的市場殺出一條血路。網(wǎng)易云在播放器軟件成熟的時代以極致的用戶體驗殺出了一條血路來，這些其實都是在長尾市場中進(jìn)行創(chuàng)新。

我們回顧第三個問題，老板看到競品在做某一功能時本能的回去分析商業(yè)模式，這是身為一個老板的責(zé)任。但是在電商已經(jīng)發(fā)展了十幾年，直播行業(yè)也已經(jīng)做的都非常成熟的今天，大部分用戶的需求都被解決的差不多了，留給我們的往往都是些長尾需求。而在兩個成熟體系和行業(yè)中進(jìn)行一次合璧創(chuàng)新是否真的能用一個極簡的產(chǎn)品模型來跑通是有待商榷的。

隨著互聯(lián)網(wǎng)環(huán)境的成熟，各行各業(yè)的互聯(lián)網(wǎng)產(chǎn)品都已經(jīng)形成了頭部效應(yīng)，留給我們做一個新產(chǎn)品的機(jī)會大多是整合或差異化創(chuàng)新。

尤其在對兩個行業(yè)進(jìn)行合璧整合時，千萬不要忘記用戶的心理路徑是需要形成閉環(huán)的。比如當(dāng)我們做這款電商直播產(chǎn)品的時候我們要知道，我們面向的用戶是雙向的，既有主播也有粉絲。我們的功能也是兩方面的，即有直播又有電商。對于直播來講主播的上升通道是及其重要的，粉絲的打賞關(guān)注和互動功能也是這款產(chǎn)品的立身之本。

在用戶的操作流程已經(jīng)形成習(xí)慣，用戶的心智模型也已經(jīng)建立起來的情況下，即使再極簡也需要我們?yōu)橛脩籼峁┩暾娜肟诤统隹凇?/strong>