軟件項目版本管理二三事

4 評論 13007 瀏覽 112 收藏 23 分鐘

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

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

在版本開發前:通過建立版本號標識,明確版本目標,制定好版本上線需求內容,設計好發布策略,可以讓產品功能和質量盡可能地符合用戶的預期。

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

在版本發布后:通過對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協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 大佬??

    回復
  2. 版本管理工作是軟件項目管理的重要內容,該工作貫穿版本開發前、版本開發時和版本發布后的全生命周期。

    來自中國 回復
  3. 又是一篇適合新手小白了解軟件項目版本管理整個業務流程,專業。

    來自江蘇 回復
    1. 謝謝支持

      來自河南 回復