5000字干貨好文 | APP版本迭代流程&版本號命名規則(建議收藏)

7 評論 1.1萬 瀏覽 212 收藏 22 分鐘

編輯導讀:面對互聯網行業中激烈的競爭,讓我們的開發流程更完整、更有效率,產品才能脫穎而出。本篇文章總結整理的APP版本迭代流程與規范,主要涉及到版本迭代過程中的規范流程以及涉及到版本各個角色的職責分工等內容,與大家分享。

本篇文章總結整理的APP版本迭代流程與規范,主要涉及到版本迭代過程中的規范流程以及涉及到版本各個角色的職責分工等內容,分享給大家:

本文目錄如下:

  1. 引言
  2. 需求匯總階段流程
  3. 需求評審階段流程
  4. 需求開發&測試階段流程
  5. 內測階段流程
  6. APP版本號命名規則

一、引言

1.1 目的

基于現在的開發流程中缺少的環節進行補足,使得開發流程更加的流暢和正規化,以便以后的查閱與歸檔使用。面對互聯網行業中激烈的競爭,讓我們的開發流程更完整、更有效率,產品才能脫穎而出。

1.2 范圍

本文檔適用于App產品的迭代研發,主要流程包括:需求匯總、需求評審、技術&用例評審、開發&測試排期、開發&測試、內測體驗等環節。以后的產品開發流程也可以參考此文檔的環節進行開發。

1.3 讀者對象

本文檔的目標讀者對象主要包括:

產品經理:輸出&收集匯總每個版本迭代的需求,同時對App迭代進行體驗驗收,需求匯總階段、需求評審階段、內測體驗階段的主要負責人。

交互設計師:根據相關需求文檔,進行交互優化,輸出優化原型圖,提升產品整體用戶體驗。

視覺設計師:根據需求文檔&交互原型圖作為視覺設計的步驟和資源產出的依據。

項目經理:組織發起需求評審,并跟進評審結果及輸出開發測試排期,需求評審階段、發布上線階段的主要負責人。

開發:主導發起部分復雜需求的技術評審,根據需求文檔編寫代碼,開發測試過程由版本經理主導推進,為迭代上線負責。

測試:根據需求文檔設計相關測試用例,并主導發起用例評審,跟進測試階段的Bug解決。

1.4 App迭代階段流程圖

二、需求匯總階段

階段推進方:主要由產品主導推進與收尾

產品部門&版本主要產品經理:

  • 負責發起版本迭代
  • 輸出相關App迭代需求
  • 收集其他需求方的App迭代需求
  • 匯總并進行需求的初步分類與優先級評定
  • 決策相關需求方案是否需要技術介入進行前期初評
  • 決策相關需求方案是否需要進行交互優化&視覺設計
  • 郵件發送需求匯總清單至相關責任人
  • 確認需求匯總完畢后發起需求評審
  • 匯總、整理、輸出本階段相關交付結果

階段參與方&職責:

交互設計師:

  • 根據需求文檔及需求原型圖,進行交互層面優化,提升產品的用戶體驗
  • 自發發起用戶體驗提升相關的需求,并提交給產品經理匯總入版本迭代需求中
  • 輸出交互優化稿后與產品經理進行評審確認

視覺設計師:

  • 根據需求文檔及需求原型圖或交互原型圖,進行視覺設計
  • 輸出效果稿進行視覺設計評審確認
  • 輸出標注稿供客戶端開發工程師對照開發
  • 輸出相關測試用效果切圖,供開發&測試過程直觀查看效果用

項目經理:

  • 根據開發對需求提出的疑問點進行分類匯總
  • 組織安排評審會議

開發:

  • 適時參與產品發起的需求方案初評
  • 查閱產品擬定的本版本迭代需求匯總,并初步提出相關疑問點

測試:

查閱產品擬定的本版本迭代需求匯總,并初步提出相關疑問點

階段工作描述:

需求匯總階段也是版本迭代的準備階段,該階段主要為需求的匯總及UED方面的設計輸出,同時也為需求評審準備相應的材料與文檔。

階段交付成果:

  • 版本迭代需求匯總
  • 產品需求文檔
  • UE交互優化稿
  • UI視覺設計稿&標注稿
  • 需求初期疑問點匯總

三、需求評審階段

3.1 需求評審

(點擊查看大圖)

階段推進方:主要由產品主導推進與收尾

  • 負責發起版本迭代需求評審
  • 配合項目經理組織需求評審會議
  • 在需求評審會議中進行需求宣講講解
  • 針對匯總后的需求疑問點進行答疑與溝通
  • 需求的責任人需進行需求討論記錄并在會議的最后進行需求討論記錄的確認

階段參與方&職責如下:

項目經理:

  • 組織安排評審會議,召集相關人員
  • 匯總并與相關方確認最終的需求范圍

開發:

  • 會前確認主流程、主方向、主內容的認可
  • 非常細節的內容,不涉及主流程環節可會后單獨與產品經理討論確認
  • 參與需求評審,并根據需求講解情況,提出疑問點,進行討論確認
  • 確認最終的需求范圍及需求內容

測試:

  • 會前確認主流程、主方向、主內容的認可
  • 非常細節的內容,不涉及主流程環節可會后單獨與產品經理討論確認
  • 參與需求評審,并根據需求講解情況,提出疑問點,進行討論確認
  • 確認最終的需求范圍及需求內容

階段工作描述:

需求評審階段是版本迭代的關鍵節點,該階段主要需要對需求進行嚴格的審閱與傳達,需要需求方與實現方進行完整全面的溝通。同時也是后續技術設計評審、測試用例評審的根基,力求將問題放在初期解決確認。

階段交付成果:

  • 各個需求的需求討論點記錄
  • 需求評審總結與會議紀要
  • 需求范圍確認后的版本迭代需求匯總清單

3.2 技術/測試用例評審&排期

階段推進方:主要由項目經理主導推進與收尾

  • 負責在確認需求范圍后,發起開展技術設計評審、測試用例評審
  • 負責確認版本經理、測試負責人
  • 負責收集各個需求的開發/測試工作量評估
  • 負責輸出版本迭代排期,并與各方最終確認排期情況

階段參與方&職責如下:

產品經理:

  • 參與技術設計/測試用例的評審,并提出疑問并溝通確認
  • 確認技術設計/測試用例是否符合需求
  • 確認開發/測試的排期情況

開發:

  • 確認版本經理
  • 由版本經理評估相關需求是否需要進行技術設計評審并發起推進
  • 根據確認的技術設計方案or需求,進行開發工作量評估
  • 參與測試用例評審并確認一級用例范圍
  • 確認轉測條件

測試:

  • 確認測試負責人
  • 輸出相關測試用例并分級,發起測試用例評審并推進
  • 參與技術設計方案評審
  • 根據確認的測試用例,進行測試工作量評估
  • 確認轉測條件

階段工作描述:

技術設計方案評審&測試用例評審及排期是版本迭代的重要節點,此階段延續需求評審后對需求的理解,從開發/測試的角度出發,制定相關方案,為后續開發/測試工作提供指導與依據。

階段交付成果:

  • 技術設計概要
  • 技術設計概要評審會議紀要
  • 測試用例
  • 測試用例評審會議紀要
  • 版本迭代開發&測試排期表

四、開發&測試階段

階段推進方:主要由版本經理主導推進與收尾

  • 對整體開發&測試過程主導推進并負責
  • 及時同步進度并進行風險預警
  • 推進開發并同時跟進開發進度
  • 推進轉測并同時跟進測試進度

階段參與方&職責如下:

產品經理:

  • 參與進度同步,及時根據風險預警進行調整
  • 參與代碼開發階段的討論,確認細節點
  • 參與測試階段的討論,確認細節點
  • 決策是否需要在開發過程中進行需求變更

視覺設計:

  • 在測試階段介入進行視覺還原
  • 跟進視覺還原的修復進度
  • 確認開發過程中的部分對視覺的問題點

開發:

  • Coding
  • 參與轉測演示,并對轉測演示結果負責
  • 在測試階段及時清理相關Bug與問題
  • 與產品積極溝通相關細節點

測試:

  • 根據轉測演示結果,決策是否轉測成功
  • 發起測試階段,并根據測試用例進行數輪測試
  • 跟進提出的Bug的解決進度
  • 與產品積極溝通相關細節點

階段工作描述:

開發&測試階段是版本迭代的實現階段,本過程持續時間長,且過程需要大量持續的溝通與工作,需要各方進行緊密的配合。

階段交付成果:

  • 相關接口協議文檔
  • 測試版本App
  • 版本迭代節點通知
  • 日常進度信息
  • 測試驗收報告

五、內測體驗階段

階段推進方:主要由產品主導推進與收尾

  • 推動App迭代內測正常進行,組建內測群,拉內測員
  • 整理版本主要更新點并發布內測邀請
  • 收集匯總內測員的問題反饋并記錄相關反饋人
  • 反饋問題的定性與分類,確認是需求orBug,同時進行后續分配與確認
  • 判定需求是否采納,采納則納入需求池,酌情安排迭代,不采納則將原因描述反饋歸檔
  • 歸檔全部的問題及問題認定后,進行問題反饋分級
  • 根據問題反饋分級,對反饋內測員發送對應獎勵

階段參與方&職責如下:

測試:

  • 確認預發布驗證通過,準備內測包并發起內測流程
  • 配合產品一起完成對反饋的問題的定性分類分級
  • 對分類為Bug的問題反饋,進行確認與復現,同時確認Bug的優先級
  • 高優先級Bug,當前版本需解決,錄入系統跟進本版本內解決
  • 低優先級Bug,可延后解決,錄入系統Bug池延后版本解決

開發:

  • 確認需發布內容的Checklist
  • 對后臺進行逐一發布
  • 內測包的打包與準備

內測員:

  • 內測員一般由內部員工或灰度員工參與
  • 下載并安裝內測包,進行體驗
  • 重點體驗本版本的更新點相關流程
  • 輕度體驗App的常規常用流程
  • 發現問題并在內測群內反饋問題,配合產品完成問題的確定與歸集

項目經理:

  • 跟進版本迭代的生產環境發布
  • 推動最終對外上線發布

階段工作描述:

內測階段是上線前最后一個階段,在這個階段需要從常規用戶的角度來最終體驗,以防存在有未覆蓋的點存在問題。

階段交付成果:

  • 生產環境App
  • 內測體驗報告

六、APP版本號命名規則

作為移動端產品經理,經常會做APP版本迭代規劃,所以不可避免的需要給APP版本確定版號的工作,大多數情況下可能都是拍腦袋確定的版本號。有些公司可能會有專門的項目經理負責版本管理和版本號的命名,但是絕大多數小公司可能都是產品經理來做這項工作。

6.1 為什么要規范APP版本號的命名?

首先需要說明的是哪些人員需要用到APP版本號,第一是產品經理,第二是開發人員,第三是項目經理,第四是用戶。

對于產品經理,APP版本迭代基本都是由產品經理發起的,因此很多情況下都是產品經理在進行需求管理和版本規劃的時候就大體上劃分了版本號,版本號對于產品經理來說可以更好更清晰的篩選和確定每個版本的需求;

對于開發人員,版本號是直接和代碼相關的,很多時候不同版本交叉開發,同一時間可能在開發不同版本,為了保障代碼的規范和清晰,避免不同版本出現交叉混亂,版本號是極其重要的一環;

對于項目經理來說,版本號是需求管理中唯一標識符,需要根據版本號去管理和分配下發工作,同時也為了在軟件產品生命周期中更好的溝通和標記;

對于用戶來說,盡管版本號對于用戶來說只是一串數字,但是版本號給用戶的感知是不斷更新的數字,可以通過版本號來判斷自己的APP是不是最新的。

6.2 APP版本號的組成與規范

目前很多情況下,版本號可能只遵循了兩個原則和規范,即版本號是唯一的,且是一串數字這個基本原則。在介紹APP版本號的命名規范和原則之前,我們首先需要了解一些APP版本號的組成是怎樣的。

軟件版本號有四部分組成:

<主版本號.><子版本號>.<階段版本號>.<日期版本號加希臘字母版本號>。希臘字母版本號共有5種:base、alpha、beta、RC、Release。例如:2.1.0.181209_Release。下面對希臘字母版號進行簡述:

Alpha版:也叫α版(開發環境),此版本主要是以實現軟件功能為主,通常只在軟件開發者內部交流

Beta版:此版本相對于α版已經有了很大的改進,消除了嚴重的錯誤,但還是存在著一些缺陷,需要經過多次測試來進一步消除,此版本主要的修改對像是軟件的UI。

RC版:此版本已經相當成熟了,基本上不存在導致錯誤的BUG,與即將發行的正式版相差無幾,測試人員基本通過的版本。

Release版:此版本意味著“最終版本”、“上線版本”,,在前面版本的一系列測試版之后,終歸會有一個正式版本,是最終交付用戶使用的一個版本。該版本有時也稱為標準版。一般情況下,Release不會以單詞形式出現在軟件封面上,取而代之的是符號(R)。

而對于絕大多數APP來說,一般采用的基本都是GNU風格的版本號管理策略,APP完全版本號的組成包括三組數字<主版本號.><子版本號>.<階段版本號>,也即X.Y.Z,其中X、Y、Z都為正整數。

6.3 APP版本號的命名修改規則

6.3.1 主版本號

  • 當App的多個主要模塊有較大的變動,一般情況下比方說APP新增一個TAB,整個產品結構都改變了,或者新增了新的功能或業務。比方說微信上線錢包,抖音上線直播
  • 主版本號起始值為0或者1,具體需要由產品經理來決定是否需要修改主版本號(PS:大多數可能需要老板拍板)

6.3.2 子版本號

  • 子版本號初始值為0
  • 當APP的較少主要模塊發生較大的變動或新增模塊(涉及主邏輯變更的)、較多個分支模塊發生較大的變動或新增,相對于主版本號而言僅是局部的變動,比方說某個功能上的UI重構,某個頁面的優化等,其中較少模塊和較多模塊需要去定義,一般我們認為較少為小于3個,較多認為是超過3個;
  • 子版本號的最大值需要確定,不同的公司可能有最大的值,比方說最大為9,如果超過9,則需要主版本號進1,也有些公司可能不存在最大值,只會在主版本號+1的情況下才會將子版本號歸0。這里沒有確定的原則和規范,可以由產品經理自己定規則

6.3.3 階段版本號

  • 階段版本號初始值為0
  • 什么時候修改階段版本號,一般是Bug修復、較少個分支模塊的變動,比方說視覺、樣式、交互、文案等修改的情況。
  • 一般情況下,如果只是修復bug,則階段版本號+1即可;如果既涉及到bug修復,又涉及到較少分支模塊的修改,則階段版號+2;如果超過3個分支模塊的修改,則建議直接子版本號+1。

盡管說版本號只是一串數字,但是對于產品經理、開發人員以及用戶來說,都是有意義的一串數字,既能規范版本的生命周期,也能方便內部人員的溝通和工作,拍腦袋的去命名版本號是一個不嚴謹和規范的,而產品經理是需要去追求完美的,希望以上的APP版本的命名規范能夠給大家一些參考。

以上,就是APP版本迭代涉及到的各階段流程整理,以及各個階級涉及到的各角色的職責以及每個階段需要輸出什么交付物,每個公司每個產品涉及到的流程可能都會不一樣,但是大體上來說應該有會包含上述環節,大家可以根據自己的實際情況進行調整。

#專欄作家#

Harryli,微信公眾號:Harry李先生筆記,人人都是產品經理專欄作家。3年產品經驗,主要關注互金、新零售等領域,以及行業熱點相關產品、運營內容。

本文原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自Pexels,基于CC0協議。

給作者打賞,鼓勵TA抓緊創作!
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 好棒!比19年寫的更全面啦,看完后學到很多

    回復
  2. 不應該先通過需求評審把需求定下來再去做設計么?
    如果先設計再評審那需求評審不通過產品經理重新畫原型,設計師也跟著重新做那也太浪費時間了吧。

    回復
    1. 這里其實是把評審拆成初評和終審,初評的時候開發設計會一起參與,其實這個是由產品經理把握的,一般情況下由于敏捷迭代,如果在評審開發前設計稿還沒出來,這樣會把開發的時間壓縮,所以產品經理需要把握節奏,提前進入需求設計

      回復
    2. 我覺得你是把需求評審的定義搞錯了,需求評審是對需求進行評審,這個需求能不能做,怎么做的問題。重點是產品需求。

      設計的確認應該在UI評審就結束了,你的第二張圖片里也提到了UI評審,UI評審以后還要產品經理確認。那為什么產品經理不參加UI評審會,在評審會上確認呢?如果還有其他細節要集體確認的,一起來就是了。這樣少開一個會難道不好么?關鍵是,沒有什么細節要等到UI設計稿出來再一起確認的吧,畢竟只有前端開發才需要UI設計稿,服務端和測試都是不需要的。

      回復
  3. 版本號x.y.z管理:
    x是主版本,包括主流程、主功能,如當前是第二版本,即x=2
    y是需求迭代版本,如這個月是73期需求,那x.y=2.73
    z是修復缺陷的版本,如這次修復是第二次修復,那x.y.z=2.73.2

    回復
    1. 對的,是這個意思

      回復
  4. 學習了

    回復