excel協作?編輯導讀：版本管理，是對軟件開發過程中特定功能的集合或特定代碼構建結果進行管理本文作者圍繞軟件項目版本管理進行了分析，希望對你有幫助，現在小編就來說說關于excel協作?下面内容希望能幫助到你，我們來一起看看吧!

excel協作

編輯導讀：版本管理，是對軟件開發過程中特定功能的集合或特定代碼構建結果進行管理。本文作者圍繞軟件項目版本管理進行了分析，希望對你有幫助。

什麼是版本管理？版本管理，是對軟件開發過程中特定功能的集合或特定代碼構建結果進行管理，主要包括版本編号的管理、版本的前期規劃、版本開發時的需求變更應對以及版本發布上線後的總結回顧等内容。

在版本開發前：通過建立版本号标識，明确版本目标，制定好版本上線需求内容，設計好發布策略，可以讓産品功能和質量盡可能地符合用戶的預期。

在版本開發時：通過提升需求分析的确定性，提高需求方需求變更的成本，降低開發響應需求變更的成本，從而幫助團隊積極地應對需求變更。

在版本發布後：通過對Bug和用戶反饋以及線上日志的收集分析，對版本進行複盤，有助于及時應對版本問題，從而制定有針對性的版本優化。

對産品版本的規劃，主要包括四部分内容：一是建立明确的版本号标識，二是确定版本的目标，三是制定版本内容，四是設計發布的策略。

1. 建立明确的版本号标識

為了使工作規範化、統一化，我們需要明确标識産品的版本編号。目前業界在軟件版本的命名上，通常會采用以下方式：

版本号命名規則

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

1、版本号更新規則

主版本号更新規則：産品功能發生全新的優化，包括頁面、體驗和技術上的全面更新優化。如下圖所示兩個産品的版本号升級。

子版本号更新規則：1、産品新增了重要功能模塊；2、在原來功能基礎上作了重要更新；3、嚴重Bug的修複。

修訂版本号更新規則：1、新增或優化一般的功能模塊；2、一般Bug的修複。

2、版本号後綴

版本号後面可以加入Alpha、Beta、Gamma、RC、Release等後綴，用來表示軟件當前所處的階段。

Alpha：内測版。此版本表示該軟件在此階段主要是以實現軟件功能為主，通常隻在開發者内部交流，或者提供給測試人員測試用，一般而言，該版本軟件的Bug較多，需要繼續修改。

Beta：公測版。該版本相對于α版已有了很大的改進，消除了嚴重的問題，但還是存在着一些缺陷，需要經過多次測試來進一步消除，可以提供給一定的目标用戶大規模體驗測試。

RC 版：候選版本。是 Release Candidate 的縮寫，意思是發布倒計時，該版本已經相當成熟了，完成全部功能并清除大部分的Bug。

Release 版：該版本意味“最終版本”。是經過前面版本的一系列測試之後，最終交付給用戶使用的一個版本。該版本有時也稱為标準版。

2. 确定版本目标

版本規劃的第二部分内容是關于版本目标的确定。

在确定版本上線需求的時候，往往容易隻考慮那些最緊急的、用戶反饋最多的、所謂優先級最高的需求，然後将這些需求整合到下一次的版本發布計劃中，但是這麼做無疑是撿了芝麻卻丢了西瓜，因為忽視了對整個産品目标的實現。

比如：需求A屬于模塊1，需求B屬于模塊2，需求C屬于模塊3，這些需求分屬于不同的業務，解決的是不同場景的需求，但同時實現這幾個需求，并不能體現出産品的目标和優勢。一個版本，就好比一個産品，産品要有自己的優勢，版本也要有自己的目标和優勢。

基于海盜模型确定版本目标

海盜模型是一種以用戶為中心的、着眼于轉化率的漏鬥模型。這個經典的數據模型把目标整體分成了五個部分，即：獲取用戶（Acquisition）、激活用戶（Activation）、提高留存（Retention）、獲取收入（Revenue）和自傳播（Referral）。

1、獲取用戶

即拉新，一般是用戶的注冊、下載、關注等行為。通常用新增用戶數來作為考量。任何一款産品上線之初都避不開這個環節，而且拉新是會持續的伴随整個産品生命周期。一般在剛剛上線核心功能後，都會重點關注并優化用戶的注冊登錄的路徑，甚至通過不斷的埋點來獲取數據，從而做數據分并優化需求。

案例：最初新浪微博的注冊流程，是需要用戶在第一次注冊時綁定手機号、身份證、輸入賬号密碼和保密郵箱等等非常多的内容，後來在後台的數據埋點中發現由于注冊流程繁瑣，導緻不少用戶在注冊了一半的情況下就跳出了頁面。之後随着版本的不斷叠代，如今新浪微博的注冊隻需要輸入賬号和密碼即可，隻有在需要用到核心功能時才會需要我們綁定手機号和身份證等相關信息。這樣就大大降低了用戶的操作成本，讓獲取用戶變得更容易。

2、激活用戶

即促活，一般會以用戶的在線時長、與其他用戶的互動頻次等數據來做以考量。初期用戶的活躍度是至關重要的，甚至對産品以後的發展會有很長遠的影響。

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

3、提高留存

留存：指在經過一段時間後有多少用戶留了下來，一般情況下會以月、周、日的時間維度來作為數據考量，也就是我們常說的DAU、WAU和MAU。

案例：在一些社區及遊戲行業中留存是一個相當重要的指标，當一款産品的用戶留存越來越低，即使有新用戶進來，也依然難以擺脫冷清的局面。例如，根據王者榮耀的數據發現，在非長假期間用戶的留存率會出現下降的情況，所以為了搶占用戶的時間，提高留存率，程序會經常發布一些諸如簽到送皮膚和送鑽石金币等任務活動。

4、獲取收入

即變現。不止是軟件的開發方獲得收入變現，用戶也可以在這一步獲得利益。

案例：知乎為了更好的促進用戶進行高質量内容創作，增加了付費問答等功能，這些功能讓用戶有更強烈的動機去進行持續的内容輸出，同時也為平台帶來了部分收益。

5、自傳播

自傳播：即用戶可以自發的向身邊用戶推薦我們的産品。

案例：拼多多采取了拼團模式讓用戶獲取到折扣和優惠，同時進一步刺激了用戶分享給身邊人，加強了産品本身的傳播性。

3. 制定版本内容

版本的目标确定了，我們就需要從需求池中挑選需求了。需求很多，但是開發資源緊張或存在其他一些客觀因素，不能在一個版本中全部實現。那麼我們怎麼對這些需求進行排序呢？

基于KANO模型确定需求優先級

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

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

1、興奮型需求

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

若不實現此需求，用戶滿意度不會降低；若實現此需求，用戶滿意度會有很大的提升。當用戶對一些産品或服務沒有表達出明确的需求時，如果提供給用戶一些完全出乎意料的産品屬性或服務行為，會使用戶産生驚喜，提升用戶滿意度，從而提高用戶忠誠度。這類需求往往是代表着用戶的潛在需求。

例如網易雲音樂的評論功能：網易雲音樂剛推出時就摒棄了傳統音樂APP“音樂播放器”的普遍定位，以“音樂社交”為差異化切入點，讓用戶聽音樂後投入的情感以F發表評論的形式參與進來，讓用戶體驗的不僅僅隻有音樂，還有情感的共鳴。

2、期望型需求

期望型需求，是處于成長期的需求，也是體現競争能力的需求。

實現此需求，用戶滿意度會提升；不實現此需求，用戶滿意度會降低。對于這類需求，不僅要滿足，還要保證質量。

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

3、基本型需求

基本型需求，即痛點，對于用戶而言，這些需求是理所當然必須滿足的。

當不實現此需求，用戶滿意度會大幅降低，但優化此需求，用戶滿意度不會得到顯著提升。這類需求是核心需求，也是産品必做的功能，所以應該不斷地調查和了解用戶需求，并通過合适的方法在産品中體現。

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

4、無差異型需求

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

5、反向型需求

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

4. 設計發布策略

版本規劃的第四個内容是設計發布策略。版本發布策略需要考慮的問題是：直接發布給所有用戶？還是先讓一部分用戶試用？

比如說可以先讓内部用戶使用，内部用戶對軟件質量問題容忍度是很高的，還可以幫助發現很多問題。還有就是采用灰度測試的發布策略，讓一小部分用戶先用新功能，如果沒發現什麼問題，再繼續擴大用戶規模，如果有問題，也隻是影響少量用戶。例如：蘋果的iOS系統，用戶也可以選擇安裝最新的 Beta 版本，可以先體驗新功能，但是必須忍受系統的不穩定。

從版本的規劃進入版本的實現階段，業務需求的變更是無法避免的，所以需要考慮如何應對版本需求的變更問題。

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

原因一：需求的确定性

建築需求是很具象的，而軟件工程的需求是抽象的。所以建築項目裡面，無論是提出需求還是變更需求，客戶和施工方都明确地知道他們想要什麼。然而，軟件需求則經常是抽象、模糊、不精确的，模糊不清的需求導緻在軟件開發有了雛形後，才慢慢想清楚真正的需求是什麼，從而導緻需求變更。

舉個例子：客戶最開始對軟件界面的顔色是沒有任何要求的，當第一版本的軟件給客戶看的時候，客戶覺得白色背景太難看了，希望換成藍色的；第二版本換成藍色後，客戶現在已經覺得黃色更好看，希望改成黃色背景；第三版本的時候，産品經理擔心客戶還想換顔色，就直接做成了換皮膚功能，用戶可以自己選擇顔色，客戶還是不滿意，問能不能把背景換成圖片……

原因二：需求變更的成本

建築項目裡面的需求變更，都很容易和成本挂鈎，因為這些東西已經是生活常識了，而軟件項目裡需求的變更成本比較模糊不确定。

舉個例子：裝修房子的時候，如果牆面已經刷成白色了，但是客戶想都刷成藍色，那麼他會很清楚，這涉及一系列成本：需要重新購買塗料、需要找人重新粉刷。但換成一個軟件項目，客戶想把界面的白色背景換成藍色的，他會覺得這是很簡單也是理所當然的，甚至有時候産品經理也會這麼想，就會對開發這麼說：“不就是換個顔色嗎？幾行代碼的事，客戶讓換就換了嘛！”但是實際上，軟件項目的需求變更，哪怕是換一個背景顔色，同樣是要涉及成本的：需要修改所有涉及背景顔色的代碼，需要更新相關測試代碼，還需要對涉及的界面重新測試。

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

在軟件項目開發中，需求變更其實是不可避免的，找到合适的方案來改善并積極擁抱合理的需求變化，減少不必要的需求變更，這是我們讨論如何緩解需求變更問題的前提條件，也是共識的基礎。

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

例如：在了解完客戶的需求後，不急于馬上輸出PRD文檔讓開發實現，而是自己先用 Axure等原型設計工具，做一個簡單的交互原型，給需求方演示。用戶會針對原型的效果提出一些修改意見，然後再快速地修改原型，這樣反複确認，等到用戶沒有什麼修改意見後，再着手具體的文檔編寫和開發實現。

2、規範變更流程，提升需求變更成本

例如：如果有條件，當業務需求發生變更時，可以根據實際情況，要求需求部門需通過“電子化管理平台中的需求管理流程”進行需求變更，并提交《需求變更申請》，經主管領導及項目經理審批後提交給技術負責人實施”。需求變更申請通過後，文檔管理人應将《項目需求規格說明書》同步更新到最新版本。

3、降低開發響應需求變更的成本，積極應對需求變更

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

當版本發布上線後，可能這才隻是新的開始，因為還有兩項重要的工作需要繼續跟進，一是問題跟蹤，二是版本複盤。

1. 問題跟蹤

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

除了被動地依靠用戶反饋問題，還需要主動的對發布的版本進行監控。比如說要收集系統崩潰的日志、監控服務器資源占用情況、監控 API 出錯的比例、監控網頁響應的速度等數據。當發現數據異常時，很可能說明發布的版本是有問題的，需要及時的應對，回滾版本或者發布新的更新補丁。

2. 版本複盤

對版本進行複盤，就是通過分析和讨論實現版本過程中出現的問題，進而總結成功經驗，吸取失敗教訓，提升團隊能力。版本複盤主要包括四個步驟。

1、回顧版本目标

版本在最開始規劃的時候都會确定該版本的目标，所以複盤的第一步，就是要回顧最初的目标，方便對最終結果進行評估。

做好版本目标回顧的前置條件，是準确和客觀的目标描述。隻有做到目标的準确和客觀，在後續才能對目标的完成情況進行準确地評估。

2、評估版本結果

好的結果：比如說版本上線後質量穩定，Bug 比例低于上一次版本，沒有出現需求遺漏，開發和測試能及時同步需求的變更。

壞的結果：比如說開發過程中間有比較多的需求變更；項目發生了延期等。

3、分析原因

導緻好結果的原因，比如：增加了自動化測試代，改進了開發流程，代碼合并之前有代碼審核等；改進了項目流程，對于所有的需求細分後，基于任務跟蹤系統記錄了起來，這樣可以及時了解任務進程。

導緻壞結果的原因，比如：版本沒有及時凍結需求，頻繁增加新的需求，導緻開發節奏被打亂頻繁等

4、總結規律落實行動

例如，需求變更是導緻項目延期的主要源頭，需要在後續項目中控制好需求的變更，比如我們将縮短項目周期，采用快速叠代的開發模式，及時響應需求變更，同時在一個叠代中，沒有特殊情況，不做需求上的變更，有變更放到下一個叠代中。

或者，任務跟蹤系統可以方便地跟蹤需求的執行情況，也能保證項目成員能及時同步需求的變更。那麼就繼續使用任務跟蹤系統，對需求任務進行跟蹤，并且可以嘗試對于一些臨時性的任務也用任務跟蹤系統跟蹤起來。

通過回顧目标、評估結果、分析原因和總結規律這四個步驟對版本進行複盤，有助于我們發現做的好的地方和做的不好的地方，找出背後的原因，最終總結出來規律，落實成行動，做出積極的改變，把經驗轉化成能力。

版本管理工作是軟件項目管理的重要内容，該工作貫穿版本開發前、版本開發時和版本發布後的全生命周期。

版本開發前，通過建立明确的版本号标識，明确版本目标，制定好版本上線需求内容，設計好發布策略，盡可能地讓産品版本功能和質量符合用戶的預期；版本開發時，通過提升需求分析的确定性，提高需求方需求變更的成本，降低開發響應需求變更的成本，幫助團隊積極地應對需求變更；版本發布後，通過對Bug和用戶反饋以及線上日志的收集分析，對版本進行複盤，及時應對版本問題，從而為下一步制定有針對性的版本優化做好準備。

以上就是本人對于軟件項目版本管理的一些思考和總結，希望對從事項目管理、産品管理的同行有所幫助。

本文由 @xyh産品研習錄 原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!