后主：APP版本迭代如何避免踩坑｜Harry李先生筆記

這是我之前好友總結(jié)整理的APP版本迭代流程與規(guī)范，主要涉及到版本迭代過(guò)程中的規(guī)范流程以及涉及到版本各個(gè)角色的職責(zé)分工等內(nèi)容。

為了避免和團(tuán)隊(duì)成員撕逼扯皮，可以按照如下規(guī)范流程和團(tuán)隊(duì)成員宣導(dǎo)，落實(shí)每個(gè)環(huán)節(jié)各個(gè)角色的職責(zé)和內(nèi)容，保證每個(gè)環(huán)節(jié)都能高效協(xié)作，避免踩到坑里，相關(guān)干貨流程分享給大家。

本文目錄如下：

• 一、引言
• 二、需求匯總階段流程
• 三、需求評(píng)審階段流程
• 四、需求開(kāi)發(fā)&測(cè)試階段流程
• 五、內(nèi)測(cè)階段流程
• 六、APP版本號(hào)命名規(guī)則

1、引言

1.1、目的

基于現(xiàn)在的開(kāi)發(fā)流程中缺少的環(huán)節(jié)進(jìn)行補(bǔ)足，使得開(kāi)發(fā)流程更加的流暢和正規(guī)化，以便以后的查閱與歸檔使用。面對(duì)互聯(lián)網(wǎng)行業(yè)中激烈的競(jìng)爭(zhēng)，讓我們的開(kāi)發(fā)流程更完整、更有效率，產(chǎn)品才能脫穎而出。

1.2、范圍

本文檔適用于App產(chǎn)品的迭代研發(fā)，主要流程包括：需求匯總、需求評(píng)審、技術(shù)&用例評(píng)審、開(kāi)發(fā)&測(cè)試排期、開(kāi)發(fā)&測(cè)試、內(nèi)測(cè)體驗(yàn)等環(huán)節(jié)。以后的產(chǎn)品開(kāi)發(fā)流程也可以參考此文檔的環(huán)節(jié)進(jìn)行開(kāi)發(fā)。

1.3 、讀者對(duì)象

本文檔的目標(biāo)讀者對(duì)象主要包括：產(chǎn)品經(jīng)理：輸出&收集匯總每個(gè)版本迭代的需求，同時(shí)對(duì)App迭代進(jìn)行體驗(yàn)驗(yàn)收，需求匯總階段、需求評(píng)審階段、內(nèi)測(cè)體驗(yàn)階段的主要負(fù)責(zé)人。交互設(shè)計(jì)師：根據(jù)相關(guān)需求文檔，進(jìn)行交互優(yōu)化，輸出優(yōu)化原型圖，提升產(chǎn)品整體用戶體驗(yàn)。視覺(jué)設(shè)計(jì)師：根據(jù)需求文檔&交互原型圖作為視覺(jué)設(shè)計(jì)的步驟和資源產(chǎn)出的依據(jù)。項(xiàng)目經(jīng)理：組織發(fā)起需求評(píng)審，并跟進(jìn)評(píng)審結(jié)果及輸出開(kāi)發(fā)測(cè)試排期，需求評(píng)審階段、發(fā)布上線階段的主要負(fù)責(zé)人。開(kāi)發(fā)：主導(dǎo)發(fā)起部分復(fù)雜需求的技術(shù)評(píng)審，根據(jù)需求文檔編寫(xiě)代碼，開(kāi)發(fā)測(cè)試過(guò)程由版本經(jīng)理主導(dǎo)推進(jìn)，為迭代上線負(fù)責(zé)。測(cè)試：根據(jù)需求文檔設(shè)計(jì)相關(guān)測(cè)試用例，并主導(dǎo)發(fā)起用例評(píng)審，跟進(jìn)測(cè)試階段的Bug解決。

1.4、App迭代階段流程圖

2、需求匯總階段

階段推進(jìn)方：主要由產(chǎn)品主導(dǎo)推進(jìn)與收尾產(chǎn)品部門(mén)&版本主要產(chǎn)品經(jīng)理

• – 負(fù)責(zé)發(fā)起版本迭代
• – 輸出相關(guān)App迭代需求
• – 收集其他需求方的App迭代需求
• – 匯總并進(jìn)行需求的初步分類與優(yōu)先級(jí)評(píng)定
• – 決策相關(guān)需求方案是否需要技術(shù)介入進(jìn)行前期初評(píng)
• – 決策相關(guān)需求方案是否需要進(jìn)行交互優(yōu)化&視覺(jué)設(shè)計(jì)
• – 郵件發(fā)送需求匯總清單至相關(guān)責(zé)任人
• – 確認(rèn)需求匯總完畢后發(fā)起需求評(píng)審
• – 匯總、整理、輸出本階段相關(guān)交付結(jié)果

階段參與方&職責(zé)：

交互設(shè)計(jì)師

• – 根據(jù)需求文檔及需求原型圖，進(jìn)行交互層面優(yōu)化，提升產(chǎn)品的用戶體驗(yàn)
• – 自發(fā)發(fā)起用戶體驗(yàn)提升相關(guān)的需求，并提交給產(chǎn)品經(jīng)理匯總?cè)氚姹镜枨笾?/li>
• – 輸出交互優(yōu)化稿后與產(chǎn)品經(jīng)理進(jìn)行評(píng)審確認(rèn)

視覺(jué)設(shè)計(jì)師

• – 根據(jù)需求文檔及需求原型圖或交互原型圖，進(jìn)行視覺(jué)設(shè)計(jì)
• – 輸出效果稿進(jìn)行視覺(jué)設(shè)計(jì)評(píng)審確認(rèn)
• – 輸出標(biāo)注稿供客戶端開(kāi)發(fā)工程師對(duì)照開(kāi)發(fā)
• – 輸出相關(guān)測(cè)試用效果切圖，供開(kāi)發(fā)&測(cè)試過(guò)程直觀查看效果用

項(xiàng)目經(jīng)理

• – 根據(jù)開(kāi)發(fā)對(duì)需求提出的疑問(wèn)點(diǎn)進(jìn)行分類匯總
• – 組織安排評(píng)審會(huì)議

開(kāi)發(fā)

• – 適時(shí)參與產(chǎn)品發(fā)起的需求方案初評(píng)
• – 查閱產(chǎn)品擬定的本版本迭代需求匯總，并初步提出相關(guān)疑問(wèn)點(diǎn)

測(cè)試

• – 查閱產(chǎn)品擬定的本版本迭代需求匯總，并初步提出相關(guān)疑問(wèn)點(diǎn)

階段工作描述

需求匯總階段也是版本迭代的準(zhǔn)備階段，該階段主要為需求的匯總及UED方面的設(shè)計(jì)輸出，同時(shí)也為需求評(píng)審準(zhǔn)備相應(yīng)的材料與文檔。

階段交付成果

• 版本迭代需求匯總
• 產(chǎn)品需求文檔
• UE交互優(yōu)化稿
• UI視覺(jué)設(shè)計(jì)稿&標(biāo)注稿
• 需求初期疑問(wèn)點(diǎn)匯總

3、需求評(píng)審階段

3.1、需求評(píng)審

階段推進(jìn)方：主要由產(chǎn)品主導(dǎo)推進(jìn)與收尾

• – 負(fù)責(zé)發(fā)起版本迭代需求評(píng)審
• – 配合項(xiàng)目經(jīng)理組織需求評(píng)審會(huì)議
• – 在需求評(píng)審會(huì)議中進(jìn)行需求宣講講解
• – 針對(duì)匯總后的需求疑問(wèn)點(diǎn)進(jìn)行答疑與溝通
• – 需求的責(zé)任人需進(jìn)行需求討論記錄并在會(huì)議的最后進(jìn)行需求討論記錄的確認(rèn)

階段參與方&職責(zé)如下

項(xiàng)目經(jīng)理

• – 組織安排評(píng)審會(huì)議，召集相關(guān)人員
• – 匯總并與相關(guān)方確認(rèn)最終的需求范圍

開(kāi)發(fā)

• – 會(huì)前確認(rèn)主流程、主方向、主內(nèi)容的認(rèn)可
• – 非常細(xì)節(jié)的內(nèi)容，不涉及主流程環(huán)節(jié)可會(huì)后單獨(dú)與產(chǎn)品經(jīng)理討論確認(rèn)
• – 參與需求評(píng)審，并根據(jù)需求講解情況，提出疑問(wèn)點(diǎn)，進(jìn)行討論確認(rèn)
• – 確認(rèn)最終的需求范圍及需求內(nèi)容

測(cè)試

• – 會(huì)前確認(rèn)主流程、主方向、主內(nèi)容的認(rèn)可
• – 非常細(xì)節(jié)的內(nèi)容，不涉及主流程環(huán)節(jié)可會(huì)后單獨(dú)與產(chǎn)品經(jīng)理討論確認(rèn)
• – 參與需求評(píng)審，并根據(jù)需求講解情況，提出疑問(wèn)點(diǎn)，進(jìn)行討論確認(rèn)
• – 確認(rèn)最終的需求范圍及需求內(nèi)容

階段工作描述

需求評(píng)審階段是版本迭代的關(guān)鍵節(jié)點(diǎn)，該階段主要需要對(duì)需求進(jìn)行嚴(yán)格的審閱與傳達(dá)，需要需求方與實(shí)現(xiàn)方進(jìn)行完整全面的溝通。同時(shí)也是后續(xù)技術(shù)設(shè)計(jì)評(píng)審、測(cè)試用例評(píng)審的根基，力求將問(wèn)題放在初期解決確認(rèn)。

階段交付成果

• 各個(gè)需求的需求討論點(diǎn)記錄
• 需求評(píng)審總結(jié)與會(huì)議紀(jì)要
• 需求范圍確認(rèn)后的版本迭代需求匯總清單

3.2、技術(shù)/測(cè)試用例評(píng)審&排期

階段推進(jìn)方：主要由項(xiàng)目經(jīng)理主導(dǎo)推進(jìn)與收尾

• – 負(fù)責(zé)在確認(rèn)需求范圍后，發(fā)起開(kāi)展技術(shù)設(shè)計(jì)評(píng)審、測(cè)試用例評(píng)審
• – 負(fù)責(zé)確認(rèn)版本經(jīng)理、測(cè)試負(fù)責(zé)人
• – 負(fù)責(zé)收集各個(gè)需求的開(kāi)發(fā)/測(cè)試工作量評(píng)估
• – 負(fù)責(zé)輸出版本迭代排期，并與各方最終確認(rèn)排期情況

階段參與方&職責(zé)如下：產(chǎn)品經(jīng)理

• – 參與技術(shù)設(shè)計(jì)/測(cè)試用例的評(píng)審，并提出疑問(wèn)并溝通確認(rèn)
• – 確認(rèn)技術(shù)設(shè)計(jì)/測(cè)試用例是否符合需求
• – 確認(rèn)開(kāi)發(fā)/測(cè)試的排期情況

開(kāi)發(fā)

• – 確認(rèn)版本經(jīng)理
• – 由版本經(jīng)理評(píng)估相關(guān)需求是否需要進(jìn)行技術(shù)設(shè)計(jì)評(píng)審并發(fā)起推進(jìn)
• – 根據(jù)確認(rèn)的技術(shù)設(shè)計(jì)方案or需求，進(jìn)行開(kāi)發(fā)工作量評(píng)估
• – 參與測(cè)試用例評(píng)審并確認(rèn)一級(jí)用例范圍
• – 確認(rèn)轉(zhuǎn)測(cè)條件

測(cè)試

• – 確認(rèn)測(cè)試負(fù)責(zé)人
• – 輸出相關(guān)測(cè)試用例并分級(jí)，發(fā)起測(cè)試用例評(píng)審并推進(jìn)
• – 參與技術(shù)設(shè)計(jì)方案評(píng)審
• – 根據(jù)確認(rèn)的測(cè)試用例，進(jìn)行測(cè)試工作量評(píng)估
• – 確認(rèn)轉(zhuǎn)測(cè)條件

階段工作描述

技術(shù)設(shè)計(jì)方案評(píng)審&測(cè)試用例評(píng)審及排期是版本迭代的重要節(jié)點(diǎn)，此階段延續(xù)需求評(píng)審后對(duì)需求的理解，從開(kāi)發(fā)/測(cè)試的角度出發(fā)，制定相關(guān)方案，為后續(xù)開(kāi)發(fā)/測(cè)試工作提供指導(dǎo)與依據(jù)。

階段交付成果

• 技術(shù)設(shè)計(jì)概要
• 技術(shù)設(shè)計(jì)概要評(píng)審會(huì)議紀(jì)要
• 測(cè)試用例
• 測(cè)試用例評(píng)審會(huì)議紀(jì)要 
• 版本迭代開(kāi)發(fā)&測(cè)試排期表

4、開(kāi)發(fā)&測(cè)試階段

階段推進(jìn)方：主要由版本經(jīng)理主導(dǎo)推進(jìn)與收尾

• – 對(duì)整體開(kāi)發(fā)&測(cè)試過(guò)程主導(dǎo)推進(jìn)并負(fù)責(zé)
• – 及時(shí)同步進(jìn)度并進(jìn)行風(fēng)險(xiǎn)預(yù)警
• – 推進(jìn)開(kāi)發(fā)并同時(shí)跟進(jìn)開(kāi)發(fā)進(jìn)度
• – 推進(jìn)轉(zhuǎn)測(cè)并同時(shí)跟進(jìn)測(cè)試進(jìn)度

階段參與方&職責(zé)如下：

產(chǎn)品經(jīng)理

• – 參與進(jìn)度同步，及時(shí)根據(jù)風(fēng)險(xiǎn)預(yù)警進(jìn)行調(diào)整
• – 參與代碼開(kāi)發(fā)階段的討論，確認(rèn)細(xì)節(jié)點(diǎn)
• – 參與測(cè)試階段的討論，確認(rèn)細(xì)節(jié)點(diǎn)
• – 決策是否需要在開(kāi)發(fā)過(guò)程中進(jìn)行需求變更

視覺(jué)設(shè)計(jì)

• – 在測(cè)試階段介入進(jìn)行視覺(jué)還原
• – 跟進(jìn)視覺(jué)還原的修復(fù)進(jìn)度
• – 確認(rèn)開(kāi)發(fā)過(guò)程中的部分對(duì)視覺(jué)的問(wèn)題點(diǎn)

開(kāi)發(fā)

• – Coding
• – 參與轉(zhuǎn)測(cè)演示，并對(duì)轉(zhuǎn)測(cè)演示結(jié)果負(fù)責(zé)
• – 在測(cè)試階段及時(shí)清理相關(guān)Bug與問(wèn)題
• – 與產(chǎn)品積極溝通相關(guān)細(xì)節(jié)點(diǎn)

測(cè)試

• – 根據(jù)轉(zhuǎn)測(cè)演示結(jié)果，決策是否轉(zhuǎn)測(cè)成功
• – 發(fā)起測(cè)試階段，并根據(jù)測(cè)試用例進(jìn)行數(shù)輪測(cè)試
• – 跟進(jìn)提出的Bug的解決進(jìn)度
• – 與產(chǎn)品積極溝通相關(guān)細(xì)節(jié)點(diǎn)

階段工作描述

開(kāi)發(fā)&測(cè)試階段是版本迭代的實(shí)現(xiàn)階段，本過(guò)程持續(xù)時(shí)間長(zhǎng)，且過(guò)程需要大量持續(xù)的溝通與工作，需要各方進(jìn)行緊密的配合。

階段交付成果

• 相關(guān)接口協(xié)議文檔
• 測(cè)試版本App 
• 版本迭代節(jié)點(diǎn)通知 
• 日常進(jìn)度信息
• 測(cè)試驗(yàn)收?qǐng)?bào)告

5、內(nèi)測(cè)體驗(yàn)階段

階段推進(jìn)方：主要由產(chǎn)品主導(dǎo)推進(jìn)與收尾

• – 推動(dòng)App迭代內(nèi)測(cè)正常進(jìn)行，組建內(nèi)測(cè)群，拉內(nèi)測(cè)員
• – 整理版本主要更新點(diǎn)并發(fā)布內(nèi)測(cè)邀請(qǐng)
• – 收集匯總內(nèi)測(cè)員的問(wèn)題反饋并記錄相關(guān)反饋人
• – 反饋問(wèn)題的定性與分類，確認(rèn)是需求orBug，同時(shí)進(jìn)行后續(xù)分配與確認(rèn)
• – 判定需求是否采納，采納則納入需求池，酌情安排迭代，不采納則將原因描述反饋歸檔
• – 歸檔全部的問(wèn)題及問(wèn)題認(rèn)定后，進(jìn)行問(wèn)題反饋分級(jí)
• – 根據(jù)問(wèn)題反饋分級(jí)，對(duì)反饋內(nèi)測(cè)員發(fā)送對(duì)應(yīng)獎(jiǎng)勵(lì)

階段參與方&職責(zé)如下：

測(cè)試

• – 確認(rèn)預(yù)發(fā)布驗(yàn)證通過(guò)，準(zhǔn)備內(nèi)測(cè)包并發(fā)起內(nèi)測(cè)流程
• – 配合產(chǎn)品一起完成對(duì)反饋的問(wèn)題的定性分類分級(jí)
• – 對(duì)分類為Bug的問(wèn)題反饋，進(jìn)行確認(rèn)與復(fù)現(xiàn)，同時(shí)確認(rèn)Bug的優(yōu)先級(jí)
• – 高優(yōu)先級(jí)Bug，當(dāng)前版本需解決，錄入系統(tǒng)跟進(jìn)本版本內(nèi)解決
• – 低優(yōu)先級(jí)Bug，可延后解決，錄入系統(tǒng)Bug池延后版本解決

開(kāi)發(fā)

• – 確認(rèn)需發(fā)布內(nèi)容的Checklist
• – 對(duì)后臺(tái)進(jìn)行逐一發(fā)布
• – 內(nèi)測(cè)包的打包與準(zhǔn)備

內(nèi)測(cè)員

• – 內(nèi)測(cè)員一般由內(nèi)部員工或灰度員工參與
• – 下載并安裝內(nèi)測(cè)包，進(jìn)行體驗(yàn)
• – 重點(diǎn)體驗(yàn)本版本的更新點(diǎn)相關(guān)流程
• – 輕度體驗(yàn)App的常規(guī)常用流程
• – 發(fā)現(xiàn)問(wèn)題并在內(nèi)測(cè)群內(nèi)反饋問(wèn)題，配合產(chǎn)品完成問(wèn)題的確定與歸集

項(xiàng)目經(jīng)理

• – 跟進(jìn)版本迭代的生產(chǎn)環(huán)境發(fā)布
• – 推動(dòng)最終對(duì)外上線發(fā)布

階段工作描述

內(nèi)測(cè)階段是上線前最后一個(gè)階段，在這個(gè)階段需要從常規(guī)用戶的角度來(lái)最終體驗(yàn)，以防存在有未覆蓋的點(diǎn)存在問(wèn)題。

階段交付成果

• 生產(chǎn)環(huán)境App
• 內(nèi)測(cè)體驗(yàn)報(bào)告

六、APP版本號(hào)命名規(guī)則作為移動(dòng)端產(chǎn)品經(jīng)理，經(jīng)常會(huì)做APP版本迭代規(guī)劃，所以不可避免的需要給APP版本確定版號(hào)的工作，大多數(shù)情況下可能都是拍腦袋確定的版本號(hào)。有些公司可能會(huì)有專門(mén)的項(xiàng)目經(jīng)理負(fù)責(zé)版本管理和版本號(hào)的命名，但是絕大多數(shù)小公司可能都是產(chǎn)品經(jīng)理來(lái)做這項(xiàng)工作。

6.1、為什么要規(guī)范APP版本號(hào)的命名？

首先需要說(shuō)明的是哪些人員需要用到APP版本號(hào)，第一是產(chǎn)品經(jīng)理，第二是開(kāi)發(fā)人員，第三是項(xiàng)目經(jīng)理，第四是用戶。

對(duì)于產(chǎn)品經(jīng)理，APP版本迭代基本都是由產(chǎn)品經(jīng)理發(fā)起的，因此很多情況下都是產(chǎn)品經(jīng)理在進(jìn)行需求管理和版本規(guī)劃的時(shí)候就大體上劃分了版本號(hào)，版本號(hào)對(duì)于產(chǎn)品經(jīng)理來(lái)說(shuō)可以更好更清晰的篩選和確定每個(gè)版本的需求；

對(duì)于開(kāi)發(fā)人員，版本號(hào)是直接和代碼相關(guān)的，很多時(shí)候不同版本交叉開(kāi)發(fā)，同一時(shí)間可能在開(kāi)發(fā)不同版本，為了保障代碼的規(guī)范和清晰，避免不同版本出現(xiàn)交叉混亂，版本號(hào)是極其重要的一環(huán)；

對(duì)于項(xiàng)目經(jīng)理來(lái)說(shuō)，版本號(hào)是需求管理中唯一標(biāo)識(shí)符，需要根據(jù)版本號(hào)去管理和分配下發(fā)工作，同時(shí)也為了在軟件產(chǎn)品生命周期中更好的溝通和標(biāo)記；

對(duì)于用戶來(lái)說(shuō)，盡管版本號(hào)對(duì)于用戶來(lái)說(shuō)只是一串?dāng)?shù)字，但是版本號(hào)給用戶的感知是不斷更新的數(shù)字，可以通過(guò)版本號(hào)來(lái)判斷自己的APP是不是最新的。

6.2、APP版本號(hào)的組成與規(guī)范

目前很多情況下，版本號(hào)可能只遵循了兩個(gè)原則和規(guī)范，即版本號(hào)是唯一的，且是一串?dāng)?shù)字這個(gè)基本原則。在介紹APP版本號(hào)的命名規(guī)范和原則之前，我們首先需要了解一些APP版本號(hào)的組成是怎樣的。

軟件版本號(hào)有四部分組成：<主版本號(hào).><子版本號(hào)>.<階段版本號(hào)>.<日期版本號(hào)加希臘字母版本號(hào)>。

希臘字母版本號(hào)共有5種：base、alpha、beta、RC、Release。例如：2.1.0.181209_Release。

下面對(duì)希臘字母版號(hào)進(jìn)行簡(jiǎn)述：Alpha版：也叫α版（開(kāi)發(fā)環(huán)境），此版本主要是以實(shí)現(xiàn)軟件功能為主，通常只在軟件開(kāi)發(fā)者內(nèi)部交流Beta版：此版本相對(duì)于α版已經(jīng)有了很大的改進(jìn)，消除了嚴(yán)重的錯(cuò)誤，但還是存在著一些缺陷，需要經(jīng)過(guò)多次測(cè)試來(lái)進(jìn)一步消除，此版本主要的修改對(duì)像是軟件的UI。

RC版：此版本已經(jīng)相當(dāng)成熟了，基本上不存在導(dǎo)致錯(cuò)誤的BUG，與即將發(fā)行的正式版相差無(wú)幾，測(cè)試人員基本通過(guò)的版本。

Release版：此版本意味著“最終版本”、“上線版本”，在前面版本的一系列測(cè)試版之后，終歸會(huì)有一個(gè)正式版本，是最終交付用戶使用的一個(gè)版本。該版本有時(shí)也稱為標(biāo)準(zhǔn)版。

一般情況下，Release不會(huì)以單詞形式出現(xiàn)在軟件封面上，取而代之的是符號(hào)(R)。而對(duì)于絕大多數(shù)APP來(lái)說(shuō)，一般采用的基本都是GNU風(fēng)格的版本號(hào)管理策略，APP完全版本號(hào)的組成包括三組數(shù)字<主版本號(hào).><子版本號(hào)>.<階段版本號(hào)>，也即X.Y.Z，其中X、Y、Z都為正整數(shù)。

6.3、APP版本號(hào)的命名修改規(guī)則

1、主版本號(hào)

• 當(dāng)App的多個(gè)主要模塊有較大的變動(dòng)，一般情況下比方說(shuō)APP新增一個(gè)TAB，整個(gè)產(chǎn)品結(jié)構(gòu)都改變了，或者新增了新的功能或業(yè)務(wù)。比方說(shuō)微信上線錢(qián)包，抖音上線直播
• 主版本號(hào)起始值為0或者1，具體需要由產(chǎn)品經(jīng)理來(lái)決定是否需要修改主版本號(hào)（PS：大多數(shù)可能需要老板拍板）

2、子版本號(hào)

• 子版本號(hào)初始值為0
• 當(dāng)APP的較少主要模塊發(fā)生較大的變動(dòng)或新增模塊（涉及主邏輯變更的）、較多個(gè)分支模塊發(fā)生較大的變動(dòng)或新增，相對(duì)于主版本號(hào)而言僅是局部的變動(dòng)，比方說(shuō)某個(gè)功能上的UI重構(gòu)，某個(gè)頁(yè)面的優(yōu)化等，其中較少模塊和較多模塊需要去定義，一般我們認(rèn)為較少為小于3個(gè)，較多認(rèn)為是超過(guò)3個(gè)；
• 子版本號(hào)的最大值需要確定，不同的公司可能有最大的值，比方說(shuō)最大為9，如果超過(guò)9，則需要主版本號(hào)進(jìn)1，也有些公司可能不存在最大值，只會(huì)在主版本號(hào)+1的情況下才會(huì)將子版本號(hào)歸0。這里沒(méi)有確定的原則和規(guī)范，可以由產(chǎn)品經(jīng)理自己定規(guī)則

3、階段版本號(hào)

• 階段版本號(hào)初始值為0
• 什么時(shí)候修改階段版本號(hào)，一般是Bug修復(fù)、較少個(gè)分支模塊的變動(dòng)，比方說(shuō)視覺(jué)、樣式、交互、文案等修改的情況。
• 一般情況下，如果只是修復(fù)bug，則階段版本號(hào)+1即可；如果既涉及到bug修復(fù)，又涉及到較少分支模塊的修改，則階段版號(hào)+2；如果超過(guò)3個(gè)分支模塊的修改，則建議直接子版本號(hào)+1。

盡管說(shuō)版本號(hào)只是一串?dāng)?shù)字，但是對(duì)于產(chǎn)品經(jīng)理、開(kāi)發(fā)人員以及用戶來(lái)說(shuō)，都是有意義的一串?dāng)?shù)字，既能規(guī)范版本的生命周期，也能方便內(nèi)部人員的溝通和工作，拍腦袋的去命名版本號(hào)是一個(gè)不嚴(yán)謹(jǐn)和規(guī)范的，而產(chǎn)品經(jīng)理是需要去追求完美的，希望以上的APP版本的命名規(guī)范能夠給大家一些參考。

以上，就是APP版本迭代涉及到的各階段流程整理，以及各個(gè)階級(jí)涉及到的各角色的職責(zé)以及每個(gè)階段需要輸出什么交付物，每個(gè)公司每個(gè)產(chǎn)品涉及到的流程可能都會(huì)不一樣，但是大體上來(lái)說(shuō)應(yīng)該有會(huì)包含上述環(huán)節(jié)，大家可以根據(jù)自己的實(shí)際情況進(jìn)行調(diào)整。

—— 如果覺(jué)得文章還OK，請(qǐng)轉(zhuǎn)發(fā) ——

特別提示：關(guān)注本專欄，別錯(cuò)過(guò)行業(yè)干貨！

PS：本司承接 小紅書(shū) / 淘寶逛逛 / 抖音 / 百度系 / 知乎 / 微博/大眾點(diǎn)評(píng) 等 全網(wǎng)各平臺(tái)推廣；

咨詢微信：139 1053 2512 (同電話)

首席增長(zhǎng)官CGO薦讀：

• 《首席增長(zhǎng)官 – 增長(zhǎng)黑客 Growth Hacker》
• 《小紅書(shū) – 增長(zhǎng)黑客 Growth Hacker》
• 《視頻號(hào) – 增長(zhǎng)黑客 Growth Hacker》

更多精彩，關(guān)注：增長(zhǎng)黑客（GrowthHK.cn）

增長(zhǎng)黑客（Growth Hacker）是依靠技術(shù)和數(shù)據(jù)來(lái)達(dá)成各種營(yíng)銷目標(biāo)的新型團(tuán)隊(duì)角色。從單線思維者時(shí)常忽略的角度和高度，梳理整合產(chǎn)品發(fā)展的因素，實(shí)現(xiàn)低成本甚至零成本帶來(lái)的有效增長(zhǎng)…