本文作者從自身經(jīng)驗(yàn)出發(fā)，結(jié)合相關(guān)案例等對(duì)產(chǎn)品管理中關(guān)于版本命名、驗(yàn)收規(guī)范、發(fā)版管理相關(guān)的知識(shí)展開了梳理總結(jié)，與大家分享。

上一篇文章我們針對(duì)PRD文檔撰寫的why，what，how三個(gè)層面進(jìn)行了分析，本篇文章，我將針對(duì)產(chǎn)品的版本命名，產(chǎn)品驗(yàn)收、版本發(fā)布管理三個(gè)方面談一些想法。

01 產(chǎn)品版本命名規(guī)則

1.1 版本命名規(guī)范

軟件版本號(hào)有四部分組成：

第一部分為主版本號(hào)；

第二部分為次版本號(hào)；

第三部分為修訂版本號(hào)；

第四部分為日期版本號(hào)加希臘字母版本號(hào)，希臘字母版本號(hào)共有五種，分別為base、alpha、beta?、RC?、?release。

1.2 版本號(hào)修改規(guī)則

（1）主版本號(hào)：當(dāng)功能模塊有較大的變動(dòng)，比如增加模塊或是整體架構(gòu)發(fā)生變化。此版本?號(hào)由項(xiàng)目經(jīng)理決定是否修改。

（2）次版本號(hào)：相對(duì)于主版本號(hào)而言，次版本號(hào)的升級(jí)對(duì)應(yīng)的只是局部的變動(dòng)，但該局部?的變動(dòng)造成程序和以前版本不能兼容，或者對(duì)該程序以前的協(xié)作關(guān)系產(chǎn)生了破壞，或者是功能上有大的改進(jìn)或增強(qiáng)。此版本號(hào)由項(xiàng)目決定是否修改。

（3）修訂版本號(hào)：一般是Bug?的修復(fù)或是一些小的變動(dòng)或是一些功能的擴(kuò)充，要經(jīng)常發(fā)布?? ?修訂版，修復(fù)一個(gè)嚴(yán)重?Bug?即可發(fā)布一個(gè)修訂版。此版本號(hào)由項(xiàng)目經(jīng)理決定是否修改。

（4）日期版本號(hào)：用于記錄修改項(xiàng)目的當(dāng)前日期，每天對(duì)項(xiàng)目的修改都需要更改日期版本?號(hào)。此版本號(hào)由開發(fā)人員決定是否修改。

（5）希臘字母版本號(hào)：此版本號(hào)用于標(biāo)注當(dāng)前版本的軟件處于哪個(gè)開發(fā)階段，當(dāng)軟件進(jìn)入到另一個(gè)階段時(shí)需要修改此版本號(hào)。此版本號(hào)由項(xiàng)目經(jīng)理決定是否修改。

1.3 版本階段說明

Base：此版本表示該軟件僅僅是一個(gè)假頁面鏈接，通常包括所有的功能和頁面布局，但是頁面中的功能都沒有做完整的實(shí)現(xiàn)，只是做為整體網(wǎng)站的一個(gè)基礎(chǔ)架構(gòu)。

Alpha?：軟件的初級(jí)版本，表示該軟件在此階段以實(shí)現(xiàn)軟件功能為主，通常只在軟件開發(fā)者????內(nèi)部交流，一般而言，該版本軟件的Bug較多，需要繼續(xù)修改，是測(cè)試版本。測(cè)試????人員提交Bug經(jīng)開發(fā)人員修改確認(rèn)之后，發(fā)布到測(cè)試網(wǎng)址讓測(cè)試人員測(cè)試，此時(shí)可將軟件版本標(biāo)注為alpha版。

Beta?：該版本相對(duì)于Alpha?版已經(jīng)有了很大的進(jìn)步，消除了嚴(yán)重錯(cuò)誤，但還需要經(jīng)過多次????測(cè)試來進(jìn)一步消除，此版本主要的修改對(duì)象是軟件的UI。修改的的Bug?經(jīng)測(cè)試人?員測(cè)試確認(rèn)后可發(fā)布到外網(wǎng)上，此時(shí)可將軟件版本標(biāo)注為?beta版。

RC?：該版本已經(jīng)相當(dāng)成熟了，基本上不存在導(dǎo)致錯(cuò)誤的Bug，與即將發(fā)行的正式版本相差無幾。

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

1.4 版本發(fā)布周期

（1）非緊急情況：按照一般發(fā)包管理制度執(zhí)行

（2）緊急情況：如果Bug比較緊急可跳過一般流程，由開發(fā)人員盡快修復(fù)Bug，測(cè)試及產(chǎn)品確認(rèn)之后直接發(fā)布該版本。

1.5 版本號(hào)修改舉例說明

如此時(shí)版本號(hào)為：1.0.0.0321_alpha?，此時(shí)為內(nèi)部測(cè)試階段

（1）開發(fā)人員修復(fù)了測(cè)試人員提交的bug并經(jīng)測(cè)試人員測(cè)試驗(yàn)證關(guān)閉bug之后，發(fā)布到外網(wǎng)時(shí)，此時(shí)就進(jìn)入了軟件的下一個(gè)階段，版本號(hào)可改為：1.0.0.0321_beta?，如當(dāng)前日期跟上一個(gè)版本號(hào)的日期不一樣，版本號(hào)可改為：1.0.0.0322_beta。

（2）如果修復(fù)了一些重大Bug?并按照流程發(fā)布到外網(wǎng)時(shí)就可發(fā)布一個(gè)修訂版，如1.0.1.0322_beta，日期為發(fā)布的當(dāng)前日期。

（3）如果對(duì)軟件進(jìn)行了一些功能上的改進(jìn)或增強(qiáng)，進(jìn)行了一些局部變動(dòng)的時(shí)候要修改次版本號(hào)，如：1.1.0.0322_beta（上一級(jí)有變動(dòng)時(shí)，下級(jí)要?dú)w零）。

（4）當(dāng)功能模塊有較大變動(dòng)，增加模塊或整體架構(gòu)發(fā)生變化時(shí)要修改主版本號(hào)，如新增加了退款功能，則版本號(hào)要改為：2.0.0.0322_beta?。

02 產(chǎn)品驗(yàn)收流程

2.1 流程

流程描述：

a、測(cè)試人員在確定所有bug修復(fù)之后交由產(chǎn)品進(jìn)行驗(yàn)收，一部分公司中，產(chǎn)品也需要參與到測(cè)試中，特別在各項(xiàng)文檔不是很齊備完善的情況下，產(chǎn)品可以在關(guān)鍵節(jié)點(diǎn)介入測(cè)試一下，防止研發(fā)出的功能與想要的功能差距較大。

b、產(chǎn)品功能驗(yàn)收—產(chǎn)品驗(yàn)收主要是驗(yàn)收功能，功能是否與設(shè)計(jì)一致，主流程是否通暢，交互是否順暢，數(shù)據(jù)是否正常，是否有缺漏，異常流程是否考慮，各類提示及消息通知是否具備。一定要驗(yàn)收異常流程，很多時(shí)候正常流程可能沒有問題，異常流程是很容易遺漏的，異常流程是否系統(tǒng)考慮完備的重要體現(xiàn)。

c、視覺設(shè)計(jì)驗(yàn)收—視覺驗(yàn)收產(chǎn)品也可以進(jìn)行，但最好是讓視覺設(shè)計(jì)師再進(jìn)行一次驗(yàn)收，這樣分工明確，也可以有所側(cè)重，也形成多次驗(yàn)收，防止出現(xiàn)意識(shí)偏差。

2.2 產(chǎn)品驗(yàn)收?qǐng)?bào)告標(biāo)準(zhǔn)

產(chǎn)品驗(yàn)收?qǐng)?bào)告包含：

a、驗(yàn)收編號(hào)-表明所歸屬的項(xiàng)目及驗(yàn)收日期

b、產(chǎn)品版本、上線時(shí)間、發(fā)起人

c、驗(yàn)收清單項(xiàng)目——包括功能及視覺，檢查清單項(xiàng)可以保證不遺漏，此功能驗(yàn)收還需要以prd文檔輔助，以prd文檔為基礎(chǔ)，核對(duì)本次迭代中的功能、流程等。

d、簽字確認(rèn)項(xiàng)——明確驗(yàn)收，權(quán)責(zé)

03 產(chǎn)品發(fā)版管理

3.1 目的

制定發(fā)包的相關(guān)管理制度是為了規(guī)范相關(guān)做事流程，明確相關(guān)交接文檔，確定相關(guān)權(quán)責(zé)，讓事情有據(jù)可依、有根可查、有人負(fù)責(zé)，從而提高團(tuán)隊(duì)做事效率。此處的發(fā)版說的是公司內(nèi)部通知，不是針對(duì)外界的通知，外界通知可由運(yùn)營或相關(guān)對(duì)于推廣部門運(yùn)作。

3.2 產(chǎn)品發(fā)版更新流程

（1）產(chǎn)品新功能提需求，需要提交到禪道，按不同類型進(jìn)行分類，歸屬到不同需求池，需求的提交按需求點(diǎn)方式提交，備注需求歸屬，是哪個(gè)系統(tǒng)，前端or后臺(tái)、模塊、功能、優(yōu)先級(jí)等，并寫明需求內(nèi)容、規(guī)則。

（2）技術(shù)人員開發(fā)并通過本地測(cè)試后，交由測(cè)試人員進(jìn)行測(cè)試。

（3）測(cè)試人員進(jìn)行測(cè)試，參照原型等產(chǎn)品相關(guān)文檔數(shù)據(jù)檢查，頁面核對(duì)，文字核對(duì)及其它測(cè)試。測(cè)試產(chǎn)生功能性等Bug，需向禪道提交bug，分配bug修改人并關(guān)聯(lián)bug對(duì)應(yīng)功能的研發(fā)人員。

（4）產(chǎn)品測(cè)試完成，需要產(chǎn)品進(jìn)行驗(yàn)收測(cè)試，測(cè)試人員與技術(shù)確認(rèn)，并填寫《產(chǎn)品更新確認(rèn)表》，填寫本次實(shí)際更新的功能，打印《產(chǎn)品更新確認(rèn)表》簽字，技術(shù)負(fù)責(zé)人簽字。

（5）《產(chǎn)品更新確認(rèn)表》交給產(chǎn)品確認(rèn)驗(yàn)收，產(chǎn)品查驗(yàn)更新功能與需求是否有出入，并進(jìn)行驗(yàn)收。如果驗(yàn)收測(cè)試有bug，則由測(cè)試提交bug到禪道，關(guān)聯(lián)相關(guān)研發(fā)人員。Bug修改完畢，先由研發(fā)測(cè)試、提交測(cè)試人員、測(cè)試人員無誤提交產(chǎn)品。內(nèi)部發(fā)布也需要走發(fā)布版本管理，需產(chǎn)品負(fù)責(zé)人及項(xiàng)目負(fù)責(zé)人簽字確認(rèn)。有必要的情況下組織會(huì)議商議對(duì)策，會(huì)議記錄方式參考《會(huì)議紀(jì)要模板》。

會(huì)議注意事項(xiàng)：

1. 會(huì)前與參會(huì)人員溝通時(shí)間，通知會(huì)議議題事項(xiàng)，
2. 開會(huì)圍繞主題圍繞事項(xiàng)，以解決事情為主，不要搞成茶話會(huì)
3. 事事有負(fù)責(zé)人及截止時(shí)間點(diǎn)
4. 會(huì)后有跟蹤執(zhí)行落實(shí)和反饋

（6）產(chǎn)品測(cè)試驗(yàn)收完成簽字，產(chǎn)品留一份簽字確認(rèn)紙制文檔，并將電子文檔給測(cè)試給研發(fā)負(fù)責(zé)人。由研發(fā)或測(cè)試再給更新正式發(fā)包運(yùn)維人員并加此次更新已經(jīng)簽字完成的《產(chǎn)品更新確認(rèn)表》電子文檔。

（7）發(fā)布正式環(huán)境，測(cè)試無誤后產(chǎn)品通過釘釘群方式發(fā)送發(fā)布版本公告。產(chǎn)品發(fā)公告的內(nèi)容主要包括：

1. 本次產(chǎn)品版本更新主要需求內(nèi)容，需求提出方，對(duì)應(yīng)UI、研發(fā)人員、產(chǎn)品、項(xiàng)目經(jīng)理等關(guān)聯(lián)人員；
2. 版本號(hào)——版本號(hào)的規(guī)范參照《版本命名規(guī)則》執(zhí)行；
3. 發(fā)布時(shí)間（按實(shí)際發(fā)布時(shí)間）；

（8）測(cè)試環(huán)境通過后發(fā)包更新至預(yù)發(fā)布環(huán)境或生產(chǎn)環(huán)境，測(cè)試再次進(jìn)行測(cè)試驗(yàn)證，如此時(shí)發(fā)現(xiàn)有問題，也必須重新按照產(chǎn)品發(fā)包更新流程走，填寫《產(chǎn)品更新確認(rèn)表》，測(cè)試環(huán)境測(cè)試完成才可在生產(chǎn)環(huán)境發(fā)包。

以上是關(guān)于產(chǎn)品版本命名、驗(yàn)收規(guī)范、發(fā)版管理相關(guān)內(nèi)容，下一篇文章將是——項(xiàng)目管理；

#相關(guān)閱讀#

產(chǎn)品管理流程及規(guī)范2——產(chǎn)品規(guī)劃及相關(guān)文檔

產(chǎn)品管理流程及規(guī)范3：產(chǎn)品原型設(shè)計(jì)

產(chǎn)品管理流程及規(guī)范4：PRD文檔撰寫

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

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