産品叠代是怎麼進行的?2.3.9之後再改就是2.4.0？産品的版本号是如何确定的？什麼時候會多加一個？每當一個産品更新是，你是否也有這樣的疑問？本文作者依據工作中項目實踐的所思所想，并結合案例等分享了産品叠代過程中需要注意的關鍵點，供大家一同參考和學習，我來為大家科普一下關于産品叠代是怎麼進行的?下面希望有你要的答案，我們一起來看看吧!
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: 長期維護
思考階段作為一個産品很多時候我希望大家名詞，講人話。奈何身邊總會有人為了顯示自己是互聯網老鳥，能說縮寫的絕對不會說中文。為了避免新人被這些黑話唬住，還是簡單的拓展一下。
首先我們作為産品很多時候也要對功能和項目的排期負責，在大家都在小步快跑做産品時，如果一個産品對于版本的管理理解深刻的話，可以省去不少麻煩。
在版本開發前我們要計劃出這一版本我們要做什麼，這會讓我們明确我們需要多少人手，需要多長時間來完成這次的計劃。
在版本開發時我們要明确這一版本我們要集中解決哪些問題，達成什麼樣的目标，這會讓我們有共同的目标和清晰的側重點。
在版本開發後我們要明确上一版本中我們需要重點關注哪些數據和出現了哪些問題，這對我們驗證需求有很大的幫助。并且我們還要着手去思考下一階段我們應該做什麼。
很多時候我們作為産品經理會習慣将自己的産品視作自己的孩子，這是很好的心态。那麼我們作為家長，更應該清楚自己的孩子在成長中應該在什麼階段是什麼樣子，我們不能要求一個小學生去學習物理化學，切忌操之過急拔苗助長。
在這裡我先抛出幾個問題來供大家思考一下：
一款電商新産品上線了一個月，運營同學提出一個通過用戶簽到獲得優惠券的需求，計劃在一星期後上線，是否合适？
這款電商産品的後台人員提出需求說上傳圖片時的操作流程有些繁瑣，希望可以一鍵上傳多張圖片，并且盼望能夠盡快解決，在開發人手不足的情況下是否要定為高優先級盡快解決？
有天老闆對你說，競品最近發布了電商直播功能，希望我們研究一下抓緊時間也搞一個出來，要不要趕緊立項實現？
這幾種情況可能是非常常見的，身為一個産品我們每天會面對來自四面八方的需求，每個提出需求的人都希望自己的需求能趕緊解決。這時我們會有一種進退兩難的感覺，覺得自己并不是在主導這款産品，反而成了一個需求工具人。大部分成長起來的産品經理都會經曆這樣的階段并且擺脫了進退兩難的境地，他們在做了很多需求後形成了自己的需求分析方法論，也搞定了與老闆和團隊的溝通問題，從而獲得了更好的執行力。而大部分的産品都倒在了進退兩難這一關，大多是在方法上和溝通上存在着或多或少的問題。
在版本管理中，我們進行一次版本更新時應該盡可能的明确更新目的，樹立共同目标。
在數據分析中有一個很常見的模型叫做AARRR模型，也就是我們常說的海盜模型。它由五部分組成，獲取用戶（Acquisition）、激活用戶（Activation）、提高留存（Retention）、獲取收入（Revenue）、自傳播（Referral）在現今互聯網思維越發成熟的今天這個方法适用于絕大多數場景。
在這個經典的數據模型中我們把目标的整體分成了五個部分，它們相互依托以此來形成循環。這些拉新促活留存這些概念看起來似乎都是運營方向的問題，這裡我們單就數據來讨論。成功的産品往往都會有兩個特征，沒有脫離用戶的需求，沒有脫離數據的叠代。
這裡我們簡單的提出一些關于海盜模型中我們需要關注的數據以及這些數據對我們叠代會有哪些指導。
（1）獲取用戶也就是我們常說的拉新，一般是用戶的注冊、下載、關注等行為。我們常以新增用戶這一數據來作為考量。任何一款産品上線之初都避不開這個環節，而且拉新這件事會持續的伴随整個産品生命周期。一般在我們剛剛上線滿足了核心功能後會重點關注并優化用戶的注冊路徑，甚至通過不斷的埋點來獲取數據優化需求。
案例：回想最初新浪微博的注冊流程，我們需要在第一次注冊時綁定手機号、身份證、輸入賬号密碼保密郵箱等等非常多的内容，在後台的數據埋點中我們不難發現因為這些信息的繁瑣導緻不少用戶在注冊了一半的情況下就跳出了頁面。随着版本的不斷叠代，在今天我們的注冊隻需要輸入賬号和密碼即可，隻有在需要用到核心功能時才會需要我們綁定手機号和身份證等相關信息。這一更新無疑大大降低了用戶的操作成本，讓獲取用戶變得更容易。
（2）激活用戶也可以理解為我們常說的促活，一般會以用戶的在線時長、與其他用戶的互動頻次等數據來做以考量。在一款以内容為核心的社區産品，初期用戶的活躍度是至關重要的，甚至對産品以後的發展會有很長遠的影響。
案例：在抖音最初的版本上線時通過各種渠道吸引了很多在校的大學生錄制作品，她們大多來自于音樂學院，表演系等顔值出衆的年輕人。這些用戶的活躍與推廣為抖音在用戶的心裡留下了一個高顔值用戶群體的印象。
回顧前面我們說到的第一個問題，在一般情況下新産品上線一個月左右時運營的重心一般會關注在拉新一事上，簽到功能更多情況下會提升我們的留存，對于拉新的效果可能并不那麼強烈。
（3）留存是指在經過一段時間後有多少用戶留了下來，一般情況下會以月、周、日的時間維度中用戶仍然使用來作為數據考量，也就是我們常說的DAU、WAU和MAU。
案例：在一些社區及遊戲行業中留存是一個相當重要的指标，當一款産品的用戶留存越來越低，即使有拉新用戶進來也依然難以擺脫冷清的局面。根據王者榮耀的數據發現，在非長假期間用戶的留存率會出現下降的情況，為了搶占用戶的時間促進留存，經常會發布諸如簽到送皮膚送鑽石金币等任務活動。
（4）獲取收入在一般情況下和會被理解為變現。在這一步驟中我的理解是不止開發方獲得收入變現，用戶也可以在這一步獲得利益。
案例：知乎為了更好的促進用戶進行高質量内容創作增加了付費問答等功能，這些功能讓用戶有更強烈的動機去進行持續的内容輸出的同時也為平台帶來了部分收益。
（5）自傳播是指用戶可以自發的向身邊用戶推薦我們的産品。
案例：拼多多采取了拼團模式讓用戶獲取到折扣和優惠的同時進一步刺激了用戶分享給身邊人的動機，加強了産品本身的傳播性和用戶貢獻度。
在明确了版本更新目的和目标後，我們心裡就應該對大部分的功能優先級有了數。
在進行版本管理時我會習慣将需求分成5種類型。
（1）關鍵性需求
在一般情況下我們會将這種需求的優先級定為P0，如果不能完成這個需求将會導緻整個版本不能正常上線，或毀滅之前的所有努力。
這裡以一個全新的電商産品舉例，一般情況下電商購物APP的通用關鍵性需求都會有支付和訂單這兩種需求。
（2）後續關鍵性需求
這種需求一般不會影響前面的項目進展，但是如果不加以滿足的話将導緻後面的版本無法正常上線。
案例：電商購物産品計劃在1.1.0版本時推出用戶積分，以用戶的消費金額累計獲得積分。那麼在1.0.0時用戶的已完成訂單記錄就是後續關鍵性需求，如果沒有這些記錄我們将無法計算用戶獲得了多少積分。
（3）後續重要性需求
這種需求一般情況下是會影響用戶的體驗或項目人員的工作價值，如果沒有滿足的話會導緻用戶“出逃”或同事血拼。
案例：該電商産品如期在1.1.0版本推出了用戶積分，運營人員本來打算在這裡讓用戶以積分來兌換優惠券。此時該需求就屬于後續重要性需求。但是沒有在這個版本中得到，用戶看着自己的積分沒有消耗途徑覺得該産品在“耍猴兒”，于是出逃，運營人員因為沒法完成kpi而與産品大打出手。
（4）改良性需求
這種需求一般情況下不會影響已有功能的使用，如果實現了會更好。如果沒有滿足的話可能會造成用戶的滿意度下降或同事的成就感降低。
案例：在運營同學和産品的一番親密會晤後緊急完成了優惠券功能的開發并上線。由于當時需求太急，UI的同學覺得之前的設計有些粗糙，優化了積分與優惠券的交互操作并用心設計了更美觀的頁面。這個時候更美觀的頁面和更優的交互體驗就屬于改良性需求。
（5）可選性需求
這種需求一般為一種設想或待驗證的需求，大多情況下為探索和嘗試，抑或是個别客戶的需求。
案例：在優惠券上線之後的用戶調研中有一名核心用戶提出希望增加優惠券的獲取途徑。這時該需求就屬于可選性需求。
回顧我們說到的第二個問題，這是新人産品經常會覺得為難的一件事。在同理心模式下我們考慮到了後台人員的工作确實在目前有些繁瑣，這會影響後台同學的工作效率，而且是應該為其解決的需求。另一方面開發的人手不足，被各種需求和排期壓的喘不過氣來，前台和後台的需求不斷進來看着開發同學們稀疏的頭發着實有點不忍心。這個情況是一件比較複雜的事情，我們将幾個角度來考慮這件事應該拍在一個什麼優先級上面。首先是後台同學在目前的情況下是否能保質保量的完成任務，該需求在目前階段是關鍵性需求還是後續性需求中的一個。
前面談到了産品經理的各種術，我們也來聊一聊産品經理的道。很多成功的産品往往都會被人稱為是有靈魂的産品，比如喬布斯的Iphone、張小龍的微信、雷軍的小米、羅永浩的錘子、王師沐的網易雲。這些産品傾注了他們的心血甚至在一些細微處也展現了他們對于産品甚至人性的思考。
很多時候我們的需求方可能不隻是用戶、運營也有時候會來自于老闆。在這種情況下我們也要把老闆當做我們的一個用戶，在面對這位用戶時我們也要思考用戶提出的需求背後的動機和更深層次的需求。比如老闆是不是會在這件事上有更多的資源或長遠布局？
關于老闆的需求如何解決在網上有各種各樣的讨論，這裡就不做過多的贅述了，總結下來大多數的做法就是會采用MVP模型來進行一次産品開發。MVP模型是指最小可用産品模型，旨在用最低的成本來滿足核心功能做市場嘗試。說到這裡每個人都有一個耳熟能詳的産品叠代記錄——微信。
打開今天的微信，我們發現我們可以在微信上面做一切事情。我們可以訂機票訂酒店，給女朋友報銷賬單而免去陪逛街的苦惱，甚至我們還可以将女朋友拉黑再找朋友幫忙推薦一個新女朋友..回想微信上線的第一個版本，那時很簡陋，隻有兩個功能，發信息和圖片。
微信的每個版本到今天都被人津津樂道，在這背後我要提醒大家千萬不要忘了時間，微信的第一個版本發布于2011年。經曆過那個移動互聯網從2.5G到3G甚至到4G的老前輩們一定都還記得那個互聯網跑馬圈地，隻要做出一個産品上線就有用戶的時代。
有很多老産品會告訴新人，不要等到産品完美了再上線，從來都不存在完美的産品。這一點我也無比同意，但是我們要正确的理解産品在什麼情況下才是完美？我們知道，産品經理這個行業并不是一個很古老的職業，尤其在現今的互聯網環境下大家的學習路徑都不盡相同。我曾經問過幾個産品新人，發現大家讀過的書都驚奇的一緻，掌握的方法和理論也都非常相同。這可能是一種非常穩妥的做産品的辦法，但是好産品确實需要創新，做産品的方法也需要跟着時代不斷的叠代。
在這近10年的光陰裡我們見證了互聯網的飛速發展，用戶的習慣被培養的越來越成熟，用戶的口味也越來越刁鑽。試想一下如果今天的你看到朋友發的照片或視頻，而你在這時卻不能點贊評論，你還會認可這款産品嗎？
MVP模型是一種合理的市場嘗試方法，但在今天不一定适用于所有的産品。比如Twitter在最初的上線時用戶的體驗就已經很完整了。近幾年殺出的黑馬産品有很多，拼多多在淘寶場景升級的情況下找到了下沉用戶的市場殺出一條血路。網易雲在播放器軟件成熟的時代以極緻的用戶體驗殺出了一條血路來，這些其實都是在長尾市場中進行創新。
我們回顧第三個問題，老闆看到競品在做某一功能時本能的回去分析商業模式，這是身為一個老闆的責任。但是在電商已經發展了十幾年，直播行業也已經做的都非常成熟的今天，大部分用戶的需求都被解決的差不多了，留給我們的往往都是些長尾需求。而在兩個成熟體系和行業中進行一次合璧創新是否真的能用一個極簡的産品模型來跑通是有待商榷的。
随着互聯網環境的成熟，各行各業的互聯網産品都已經形成了頭部效應，留給我們做一個新産品的機會大多是整合或差異化創新。
尤其在對兩個行業進行合璧整合時，千萬不要忘記用戶的心理路徑是需要形成閉環的。比如當我們做這款電商直播産品的時候我們要知道，我們面向的用戶是雙向的，既有主播也有粉絲。我們的功能也是兩方面的，即有直播又有電商。對于直播來講主播的上升通道是及其重要的，粉絲的打賞關注和互動功能也是這款産品的立身之本。
在用戶的操作流程已經形成習慣，用戶的心智模型也已經建立起來的情況下，即使再極簡也需要我們為用戶提供完整的入口和出口。
這裡還有一個小趣事想和大家分析，說起版本與叠代一定也還有一件事情困擾着産品，當我們推出了體驗更好的新版本時用戶卻不願意下載更新怎麼辦？
大家是否還記得微信的飛機大戰？
在2013年8月微信将版本更新到了5.0版本，這一版本加入了綁定銀行卡功能和表情商店等重要更新，這也意味着微信正式開啟了支付和收費的一些相關功能。為了盡快測試到版本的一些重要目标數據和用戶的反饋，産品們一定都非常希望用戶盡快的将版本更新到最新。
回向一下那個時代我們經常碰見的應用版本更新是什麼樣的？那個時候幾乎都是立即更新和關閉，連稍後更新都少隻有少。在那個不更新就閃退的時代微信用了一個及其優雅的姿态勸用戶主動完成了更新——飛機大戰。
微信作為一個社交産品在當時有着巨大的用戶優勢，微信利用了社交産品中用戶的勝負欲、好奇心等心理巧妙的讓用戶幫忙宣傳了這一版本的更新。
還記得那天朋友圈突然出現了無數個人在發自己飛機大戰的戰績，于是在這種用戶傳播下大家紛紛主動進行了更新。
同理，微信在更新小程序的時候也推出了跳一跳，又一次引爆了朋友圈和更新熱潮。
最後的一點思考産品在進行叠代時要考量的事情有很多很多，當下的互聯網環境，用戶的習慣和口味，用戶群的特征畫像， 自身的技術實力等等非常多的因素。在産品本身根據時代和環境的不斷叠代的今天，産品經理自身的方法和思維也是需要不斷進行更新與叠代的。
如何快速的将需求推進是産品們永恒的話題。這裡我總結了一些經常會導緻我們對于項目進度推進慢的原因。
什麼需求都接
沒有合理安排好需求的優先級
沒有很好的與需求方或開發方做好溝通
沒有安排好版本的側重點
沒有搞清楚産品什麼時候可以上線
以上這些問題可能對于一個新人産品是非常常見的，抛磚引玉一些望大家少走彎路少采坑，最後附上本篇的筆記。
本文由 @體驗雜貨鋪 原創發布于人人都是産品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!
zpostcode 
Recruit 
weather 
mreligion 
Yellowpages 
sport 
constellation 
shopping 
name 
game 
directory 
literature 
Word 
tour 
furnish 
Lottery 
tftnews 
lyrics 
News 
digital 
car 
dir 
Edu 
Finance 
