編輯導(dǎo)讀：版本管理，是對軟件開發(fā)過程中特定功能的集合或特定代碼構(gòu)建結(jié)果進(jìn)行管理。本文作者圍繞軟件項(xiàng)目版本管理進(jìn)行了分析，希望對你有幫助。

什么是版本管理？版本管理，是對軟件開發(fā)過程中特定功能的集合或特定代碼構(gòu)建結(jié)果進(jìn)行管理，主要包括版本編號的管理、版本的前期規(guī)劃、版本開發(fā)時的需求變更應(yīng)對以及版本發(fā)布上線后的總結(jié)回顧等內(nèi)容。

在版本開發(fā)前：通過建立版本號標(biāo)識，明確版本目標(biāo)，制定好版本上線需求內(nèi)容，設(shè)計(jì)好發(fā)布策略，可以讓產(chǎn)品功能和質(zhì)量盡可能地符合用戶的預(yù)期。

在版本開發(fā)時：通過提升需求分析的確定性，提高需求方需求變更的成本，降低開發(fā)響應(yīng)需求變更的成本，從而幫助團(tuán)隊(duì)積極地應(yīng)對需求變更。

在版本發(fā)布后：通過對Bug和用戶反饋以及線上日志的收集分析，對版本進(jìn)行復(fù)盤，有助于及時應(yīng)對版本問題，從而制定有針對性的版本優(yōu)化。

一、如何對版本進(jìn)行規(guī)劃

對產(chǎn)品版本的規(guī)劃，主要包括四部分內(nèi)容：一是建立明確的版本號標(biāo)識，二是確定版本的目標(biāo)，三是制定版本內(nèi)容，四是設(shè)計(jì)發(fā)布的策略。

1. 建立明確的版本號標(biāo)識

為了使工作規(guī)范化、統(tǒng)一化，我們需要明確標(biāo)識產(chǎn)品的版本編號。目前業(yè)界在軟件版本的命名上，通常會采用以下方式：

版本號命名規(guī)則

例如：1.2.1, 2.0, 5.0.0 build-13124。其中，構(gòu)建版本號通常由編譯程序自動生成，對外不提供。

1、版本號更新規(guī)則

• 主版本號更新規(guī)則：產(chǎn)品功能發(fā)生全新的優(yōu)化，包括頁面、體驗(yàn)和技術(shù)上的全面更新優(yōu)化。如下圖所示兩個產(chǎn)品的版本號升級。
• 子版本號更新規(guī)則：1、產(chǎn)品新增了重要功能模塊；2、在原來功能基礎(chǔ)上作了重要更新；3、嚴(yán)重Bug的修復(fù)。
• 修訂版本號更新規(guī)則：1、新增或優(yōu)化一般的功能模塊；2、一般Bug的修復(fù)。

2、版本號后綴

版本號后面可以加入Alpha、Beta、Gamma、RC、Release等后綴，用來表示軟件當(dāng)前所處的階段。

• Alpha：內(nèi)測版。此版本表示該軟件在此階段主要是以實(shí)現(xiàn)軟件功能為主，通常只在開發(fā)者內(nèi)部交流，或者提供給測試人員測試用，一般而言，該版本軟件的Bug較多，需要繼續(xù)修改。
• Beta：公測版。該版本相對于α版已有了很大的改進(jìn)，消除了嚴(yán)重的問題，但還是存在著一些缺陷，需要經(jīng)過多次測試來進(jìn)一步消除，可以提供給一定的目標(biāo)用戶大規(guī)模體驗(yàn)測試。
• RC 版：候選版本。是 Release Candidate 的縮寫，意思是發(fā)布倒計(jì)時，該版本已經(jīng)相當(dāng)成熟了，完成全部功能并清除大部分的Bug。
• Release 版：該版本意味“最終版本”。是經(jīng)過前面版本的一系列測試之后，最終交付給用戶使用的一個版本。該版本有時也稱為標(biāo)準(zhǔn)版。

2. 確定版本目標(biāo)

版本規(guī)劃的第二部分內(nèi)容是關(guān)于版本目標(biāo)的確定。

在確定版本上線需求的時候，往往容易只考慮那些最緊急的、用戶反饋?zhàn)疃嗟?、所謂優(yōu)先級最高的需求，然后將這些需求整合到下一次的版本發(fā)布計(jì)劃中，但是這么做無疑是撿了芝麻卻丟了西瓜，因?yàn)楹鲆暳藢φ麄€產(chǎn)品目標(biāo)的實(shí)現(xiàn)。

比如：需求A屬于模塊1，需求B屬于模塊2，需求C屬于模塊3，這些需求分屬于不同的業(yè)務(wù)，解決的是不同場景的需求，但同時實(shí)現(xiàn)這幾個需求，并不能體現(xiàn)出產(chǎn)品的目標(biāo)和優(yōu)勢。一個版本，就好比一個產(chǎn)品，產(chǎn)品要有自己的優(yōu)勢，版本也要有自己的目標(biāo)和優(yōu)勢。

基于海盜模型確定版本目標(biāo)

海盜模型是一種以用戶為中心的、著眼于轉(zhuǎn)化率的漏斗模型。這個經(jīng)典的數(shù)據(jù)模型把目標(biāo)整體分成了五個部分，即：獲取用戶（Acquisition）、激活用戶（Activation）、提高留存（Retention）、獲取收入（Revenue）和自傳播（Referral）。

1、獲取用戶

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

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

2、激活用戶

即促活，一般會以用戶的在線時長、與其他用戶的互動頻次等數(shù)據(jù)來做以考量。初期用戶的活躍度是至關(guān)重要的，甚至對產(chǎn)品以后的發(fā)展會有很長遠(yuǎn)的影響。

案例：抖音在最初的版本上線的時候，通過各種渠道吸引了很多在校的大學(xué)生錄制作品，他們大多來自于音樂學(xué)院、表演系等顏值出眾的年輕人。這些用戶的積極互動和推廣為抖音在用戶的心里留下了一個新潮時髦的印象，從而吸引更多人參與到短視頻的制作和互動中來。

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ī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)一步刺激了用戶分享給身邊人，加強(qiáng)了產(chǎn)品本身的傳播性。

3. 制定版本內(nèi)容

版本的目標(biāo)確定了，我們就需要從需求池中挑選需求了。需求很多，但是開發(fā)資源緊張或存在其他一些客觀因素，不能在一個版本中全部實(shí)現(xiàn)。那么我們怎么對這些需求進(jìn)行排序呢？

基于KANO模型確定需求優(yōu)先級

KANO模型是東京理工大學(xué)教授狩野紀(jì)昭（Noriaki Kano）發(fā)明的對用戶需求分類和排序的工具。我們可以通過使用KANO模型，分析需求的優(yōu)先級，完成對版本上線內(nèi)容的制定。具體就是：要盡量避免無差異型需求，不做反向型需求，做好基本型需求和期望型需求，努力挖掘興奮型需求。

在KANO模型中，根據(jù)不同類型的需求與用戶滿意度之間的關(guān)系，可將影響用戶滿意度的因素分為五類：興奮型需求、期望型需求、基本型需求、無差異型需求、反向型需求。

1、興奮型需求

興奮型需求，就是哪些藏在暗處的、用戶意想不到的，需要挖掘/洞察的需求。

若不實(shí)現(xiàn)此需求，用戶滿意度不會降低；若實(shí)現(xiàn)此需求，用戶滿意度會有很大的提升。當(dāng)用戶對一些產(chǎn)品或服務(wù)沒有表達(dá)出明確的需求時，如果提供給用戶一些完全出乎意料的產(chǎn)品屬性或服務(wù)行為，會使用戶產(chǎn)生驚喜，提升用戶滿意度，從而提高用戶忠誠度。這類需求往往是代表著用戶的潛在需求。

例如網(wǎng)易云音樂的評論功能：網(wǎng)易云音樂剛推出時就摒棄了傳統(tǒng)音樂APP“音樂播放器”的普遍定位，以“音樂社交”為差異化切入點(diǎn)，讓用戶聽音樂后投入的情感以F發(fā)表評論的形式參與進(jìn)來，讓用戶體驗(yàn)的不僅僅只有音樂，還有情感的共鳴。

2、期望型需求

期望型需求，是處于成長期的需求，也是體現(xiàn)競爭能力的需求。

實(shí)現(xiàn)此需求，用戶滿意度會提升；不實(shí)現(xiàn)此需求，用戶滿意度會降低。對于這類需求，不僅要滿足，還要保證質(zhì)量。

例如：電子書APP閱讀方式的多樣性，既支持文字閱讀，又能支持語音聽書。

3、基本型需求

基本型需求，即痛點(diǎn)，對于用戶而言，這些需求是理所當(dāng)然必須滿足的。

當(dāng)不實(shí)現(xiàn)此需求，用戶滿意度會大幅降低，但優(yōu)化此需求，用戶滿意度不會得到顯著提升。這類需求是核心需求，也是產(chǎn)品必做的功能，所以應(yīng)該不斷地調(diào)查和了解用戶需求，并通過合適的方法在產(chǎn)品中體現(xiàn)。

例如：電商購物類APP的支付和訂單這兩種需求。

4、無差異型需求

用戶根本不在意的需求，對用戶體驗(yàn)毫無影響，無論提供或不提供此需求，用戶滿意度都不會有改變。對于這類需求，沒有必要花大力氣去實(shí)現(xiàn)。

5、反向型需求

用戶根本都沒有此需求，實(shí)現(xiàn)這類需求用戶滿意度反而下降。所以這類需求不能去實(shí)現(xiàn)。

4. 設(shè)計(jì)發(fā)布策略

版本規(guī)劃的第四個內(nèi)容是設(shè)計(jì)發(fā)布策略。版本發(fā)布策略需要考慮的問題是：直接發(fā)布給所有用戶？還是先讓一部分用戶試用？

比如說可以先讓內(nèi)部用戶使用，內(nèi)部用戶對軟件質(zhì)量問題容忍度是很高的，還可以幫助發(fā)現(xiàn)很多問題。還有就是采用灰度測試的發(fā)布策略，讓一小部分用戶先用新功能，如果沒發(fā)現(xiàn)什么問題，再繼續(xù)擴(kuò)大用戶規(guī)模，如果有問題，也只是影響少量用戶。例如：蘋果的iOS系統(tǒng)，用戶也可以選擇安裝最新的 Beta 版本，可以先體驗(yàn)新功能，但是必須忍受系統(tǒng)的不穩(wěn)定。

二、如何應(yīng)對版本需求變更問題

從版本的規(guī)劃進(jìn)入版本的實(shí)現(xiàn)階段，業(yè)務(wù)需求的變更是無法避免的，所以需要考慮如何應(yīng)對版本需求的變更問題。

問題一：同樣是工程，建筑工程也是有需求變更的，但卻不會像軟件項(xiàng)目這么頻繁和失控。為什么呢？

原因一：需求的確定性

建筑需求是很具象的，而軟件工程的需求是抽象的。所以建筑項(xiàng)目里面，無論是提出需求還是變更需求，客戶和施工方都明確地知道他們想要什么。然而，軟件需求則經(jīng)常是抽象、模糊、不精確的，模糊不清的需求導(dǎo)致在軟件開發(fā)有了雛形后，才慢慢想清楚真正的需求是什么，從而導(dǎo)致需求變更。

舉個例子：客戶最開始對軟件界面的顏色是沒有任何要求的，當(dāng)?shù)谝话姹镜能浖o客戶看的時候，客戶覺得白色背景太難看了，希望換成藍(lán)色的；第二版本換成藍(lán)色后，客戶現(xiàn)在已經(jīng)覺得黃色更好看，希望改成黃色背景；第三版本的時候，產(chǎn)品經(jīng)理擔(dān)心客戶還想換顏色，就直接做成了換皮膚功能，用戶可以自己選擇顏色，客戶還是不滿意，問能不能把背景換成圖片……

原因二：需求變更的成本

建筑項(xiàng)目里面的需求變更，都很容易和成本掛鉤，因?yàn)檫@些東西已經(jīng)是生活常識了，而軟件項(xiàng)目里需求的變更成本比較模糊不確定。

舉個例子：裝修房子的時候，如果墻面已經(jīng)刷成白色了，但是客戶想都刷成藍(lán)色，那么他會很清楚，這涉及一系列成本：需要重新購買涂料、需要找人重新粉刷。但換成一個軟件項(xiàng)目，客戶想把界面的白色背景換成藍(lán)色的，他會覺得這是很簡單也是理所當(dāng)然的，甚至有時候產(chǎn)品經(jīng)理也會這么想，就會對開發(fā)這么說：“不就是換個顏色嗎？幾行代碼的事，客戶讓換就換了嘛！”但是實(shí)際上，軟件項(xiàng)目的需求變更，哪怕是換一個背景顏色，同樣是要涉及成本的：需要修改所有涉及背景顏色的代碼，需要更新相關(guān)測試代碼，還需要對涉及的界面重新測試。

問題二：如何緩解需求變更問題？

在軟件項(xiàng)目開發(fā)中，需求變更其實(shí)是不可避免的，找到合適的方案來改善并積極擁抱合理的需求變化，減少不必要的需求變更，這是我們討論如何緩解需求變更問題的前提條件，也是共識的基礎(chǔ)。

1、提升需求確定性，把需求分析做好，減少需求變更

例如：在了解完客戶的需求后，不急于馬上輸出PRD文檔讓開發(fā)實(shí)現(xiàn)，而是自己先用 Axure等原型設(shè)計(jì)工具，做一個簡單的交互原型，給需求方演示。用戶會針對原型的效果提出一些修改意見，然后再快速地修改原型，這樣反復(fù)確認(rèn)，等到用戶沒有什么修改意見后，再著手具體的文檔編寫和開發(fā)實(shí)現(xiàn)。

2、規(guī)范變更流程，提升需求變更成本

例如：如果有條件，當(dāng)業(yè)務(wù)需求發(fā)生變更時，可以根據(jù)實(shí)際情況，要求需求部門需通過“電子化管理平臺中的需求管理流程”進(jìn)行需求變更，并提交《需求變更申請》，經(jīng)主管領(lǐng)導(dǎo)及項(xiàng)目經(jīng)理審批后提交給技術(shù)負(fù)責(zé)人實(shí)施”。需求變更申請通過后，文檔管理人應(yīng)將《項(xiàng)目需求規(guī)格說明書》同步更新到最新版本。

3、降低開發(fā)響應(yīng)需求變更的成本，積極應(yīng)對需求變更

例如：技術(shù)上可以通過換皮膚的方式來定制界面，可以通過插件的方式增加功能，以此來應(yīng)對個性化的需求。

三、版本發(fā)布后的工作

當(dāng)版本發(fā)布上線后，可能這才只是新的開始，因?yàn)檫€有兩項(xiàng)重要的工作需要繼續(xù)跟進(jìn)，一是問題跟蹤，二是版本復(fù)盤。

1. 問題跟蹤

用戶在使用產(chǎn)品的時候，可能會遇到一些 Bug 或者是有一些建議，所以需要提供用戶反饋問題的渠道，讓用戶可以有途徑對于 Bug 或者功能去反饋。

除了被動地依靠用戶反饋問題，還需要主動的對發(fā)布的版本進(jìn)行監(jiān)控。比如說要收集系統(tǒng)崩潰的日志、監(jiān)控服務(wù)器資源占用情況、監(jiān)控 API 出錯的比例、監(jiān)控網(wǎng)頁響應(yīng)的速度等數(shù)據(jù)。當(dāng)發(fā)現(xiàn)數(shù)據(jù)異常時，很可能說明發(fā)布的版本是有問題的，需要及時的應(yīng)對，回滾版本或者發(fā)布新的更新補(bǔ)丁。

2. 版本復(fù)盤

對版本進(jìn)行復(fù)盤，就是通過分析和討論實(shí)現(xiàn)版本過程中出現(xiàn)的問題，進(jìn)而總結(jié)成功經(jīng)驗(yàn)，吸取失敗教訓(xùn)，提升團(tuán)隊(duì)能力。版本復(fù)盤主要包括四個步驟。

1、回顧版本目標(biāo)

版本在最開始規(guī)劃的時候都會確定該版本的目標(biāo)，所以復(fù)盤的第一步，就是要回顧最初的目標(biāo)，方便對最終結(jié)果進(jìn)行評估。

做好版本目標(biāo)回顧的前置條件，是準(zhǔn)確和客觀的目標(biāo)描述。只有做到目標(biāo)的準(zhǔn)確和客觀，在后續(xù)才能對目標(biāo)的完成情況進(jìn)行準(zhǔn)確地評估。

2、評估版本結(jié)果

好的結(jié)果：比如說版本上線后質(zhì)量穩(wěn)定，Bug 比例低于上一次版本，沒有出現(xiàn)需求遺漏，開發(fā)和測試能及時同步需求的變更。

壞的結(jié)果：比如說開發(fā)過程中間有比較多的需求變更；項(xiàng)目發(fā)生了延期等。

3、分析原因

導(dǎo)致好結(jié)果的原因，比如：增加了自動化測試代，改進(jìn)了開發(fā)流程，代碼合并之前有代碼審核等；改進(jìn)了項(xiàng)目流程，對于所有的需求細(xì)分后，基于任務(wù)跟蹤系統(tǒng)記錄了起來，這樣可以及時了解任務(wù)進(jìn)程。

導(dǎo)致壞結(jié)果的原因，比如：版本沒有及時凍結(jié)需求，頻繁增加新的需求，導(dǎo)致開發(fā)節(jié)奏被打亂頻繁等

4、總結(jié)規(guī)律落實(shí)行動

例如，需求變更是導(dǎo)致項(xiàng)目延期的主要源頭，需要在后續(xù)項(xiàng)目中控制好需求的變更，比如我們將縮短項(xiàng)目周期，采用快速迭代的開發(fā)模式，及時響應(yīng)需求變更，同時在一個迭代中，沒有特殊情況，不做需求上的變更，有變更放到下一個迭代中。

或者，任務(wù)跟蹤系統(tǒng)可以方便地跟蹤需求的執(zhí)行情況，也能保證項(xiàng)目成員能及時同步需求的變更。那么就繼續(xù)使用任務(wù)跟蹤系統(tǒng)，對需求任務(wù)進(jìn)行跟蹤，并且可以嘗試對于一些臨時性的任務(wù)也用任務(wù)跟蹤系統(tǒng)跟蹤起來。

通過回顧目標(biāo)、評估結(jié)果、分析原因和總結(jié)規(guī)律這四個步驟對版本進(jìn)行復(fù)盤，有助于我們發(fā)現(xiàn)做的好的地方和做的不好的地方，找出背后的原因，最終總結(jié)出來規(guī)律，落實(shí)成行動，做出積極的改變，把經(jīng)驗(yàn)轉(zhuǎn)化成能力。

四、結(jié)語

版本管理工作是軟件項(xiàng)目管理的重要內(nèi)容，該工作貫穿版本開發(fā)前、版本開發(fā)時和版本發(fā)布后的全生命周期。

版本開發(fā)前，通過建立明確的版本號標(biāo)識，明確版本目標(biāo)，制定好版本上線需求內(nèi)容，設(shè)計(jì)好發(fā)布策略，盡可能地讓產(chǎn)品版本功能和質(zhì)量符合用戶的預(yù)期；版本開發(fā)時，通過提升需求分析的確定性，提高需求方需求變更的成本，降低開發(fā)響應(yīng)需求變更的成本，幫助團(tuán)隊(duì)積極地應(yīng)對需求變更；版本發(fā)布后，通過對Bug和用戶反饋以及線上日志的收集分析，對版本進(jìn)行復(fù)盤，及時應(yīng)對版本問題，從而為下一步制定有針對性的版本優(yōu)化做好準(zhǔn)備。

以上就是本人對于軟件項(xiàng)目版本管理的一些思考和總結(jié)，希望對從事項(xiàng)目管理、產(chǎn)品管理的同行有所幫助。

本文由 @xyh產(chǎn)品研習(xí)錄 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于CC0協(xié)議