編輯導(dǎo)讀：產(chǎn)品的版本升級看似簡單，但是其實很復(fù)雜，有許多情況需要注意，例如任務(wù)數(shù)量、執(zhí)行周期、時間節(jié)點等。本文作者從實際工作出發(fā)，分享了幫助產(chǎn)品平穩(wěn)升級的幾點建議，希望對你有所幫助。

曾有一段時間，每周的版本升級都像是一次次“賭博”，賭贏了早早下班回家，賭輸了第二天早上下班回家，幾乎每次版本升級都充滿了不確定性和不可控性，這幾乎成了團隊中難以消散的“陰影”。

為了解決這個頭疼的問題，我梳理和規(guī)范了整個開發(fā)和升級流程，并經(jīng)過多次實踐的檢驗與迭代，形成了比較成熟的流程規(guī)范，大幅度提升了升級的成功率，緩解了了團隊聞“升級”而憂愁的情緒。

一、明確一次版本升級包含的任務(wù)數(shù)量

可能多數(shù)產(chǎn)品經(jīng)理都有過這樣的體驗：還有幾個小時就要升級了，突然又測試出來一個新的bug，要求開發(fā)改完再上線，不知不覺中就使得該版本的任務(wù)數(shù)發(fā)生了變化。產(chǎn)品經(jīng)理認為這是對產(chǎn)品高度的負責，對瑕疵的零容忍的表現(xiàn)，但實際上，卻干擾了開發(fā)同事們有序的升級準備工作。

因此，我們需要約定好每一次版本升級包含了有多少個需求任務(wù)，多少個優(yōu)化任務(wù)，多少個bug修復(fù)任務(wù)，并記錄下來。推薦使用簡單項目管理工具，如果沒有，用Excel在線文檔也可以。一旦需要增加任務(wù)，產(chǎn)品經(jīng)理需要綜合考量，而不是一味地“逼著”開發(fā)立即執(zhí)行

二、明確一次版本升級的執(zhí)行周期

每周固定一天作為“升級日”是很早就形成的慣例，相信很多公司也是這樣。但與開發(fā)同事溝通后，發(fā)現(xiàn)當周任務(wù)當周升級的方式會讓開發(fā)工作很倉促，其中免不了出現(xiàn)趕工而導(dǎo)致的問題。

我們按照慣例定在每周四晚固定時間升級，考慮到測試和修改問題的時間，如果當周開發(fā)當周升級的話，真正的開發(fā)時間只有3個工作日左右。因此，我將版本迭代的周期拉長為兩周：分別為開發(fā)周期和測試、升級周期。當周任務(wù)，下周升級，也就是在當周用足足一周的時間完成開發(fā)工作，下一周經(jīng)過測試和問題的修復(fù)后，再升級。開發(fā)工作與測試升級工作在兩周的周期中交替進行。

三、確定好一次版本升級在各環(huán)境發(fā)布的時間節(jié)點和重要事項

在未搭建開發(fā)環(huán)境（以下稱為DEV環(huán)境）時，開發(fā)全部在測試環(huán)境（以下均稱為BETA環(huán)境）上開展工作，常常導(dǎo)致版本發(fā)布時的混亂，明明在BETA環(huán)境驗證無誤的任務(wù)，發(fā)布到正式環(huán)境（以下均稱為WWW環(huán)境）后又有一堆問題。

DEV環(huán)境搭建完成后，終于算是有了全套的發(fā)開工作環(huán)境，根據(jù)團隊的工作習慣等實際情況，我規(guī)定了一次版本升級的周期內(nèi)，什么時候發(fā)布DEV環(huán)境，什么時候發(fā)布BETA環(huán)境，什么時候發(fā)布WWW環(huán)境的時間節(jié)點，以及發(fā)布前后要執(zhí)行的測試和驗證動作。

1. DEV環(huán)境的發(fā)布節(jié)點為開發(fā)周期結(jié)束的周五晚上，下周一一上班就開始進行測試。在DEV環(huán)境，每一個任務(wù)要經(jīng)過2輪測試，一次是發(fā)開工程師自檢測試，一次是產(chǎn)品或測試同事進行驗證測試。
2. BETA環(huán)境在測試、升級周期的周二晚上進行，在BETA環(huán)境下的測試分別由不同的兩位產(chǎn)品或測試同事進行交叉驗證。
3. 最后的WWW環(huán)境發(fā)布節(jié)點在測試、升級周期的周四晚上進行，發(fā)布后再進行一輪整體驗收，即可宣告發(fā)布完成
4. 測試、升級周期的周五對本次版本升級進行復(fù)盤，總結(jié)經(jīng)驗教訓(xùn)，同時安排下一個開發(fā)周期的任務(wù)。

四、對常見的突發(fā)問題做好預(yù)案

無論多么嚴密的計劃，總不可避免一些意外情況，做好應(yīng)對突發(fā)問題的預(yù)案，才能遇事不慌，冷靜地處理問題。經(jīng)過一段時間“踩坑”的經(jīng)驗，總結(jié)出突發(fā)問題主要集中在兩個方面：

1. 任務(wù)無法按照計劃的時間全部完成

其原因可能是開發(fā)過程中遇到了問題，在某個任務(wù)上消耗了過多的時間；也可能是產(chǎn)品經(jīng)理安排的任務(wù)工作量就超出了計劃時間；也或者是由于上游協(xié)同部門問題影響了正常的工作進度；亦或者是有人請假、臨時有事等等，最終導(dǎo)致計劃任務(wù)沒有在開發(fā)周期內(nèi)完成。

遇到這種情況，如果不是特別緊急的任務(wù)，比較反對通過趕工的方式加班加點開發(fā)，在計劃時間里“硬上”，這樣做大概率開發(fā)質(zhì)量不高，升級時不穩(wěn)定風險很高。

針對這樣的突發(fā)情況，我提供了2種預(yù)案：

（1）保證發(fā)布時間不變，舍棄掉部分未完成開發(fā)的任務(wù)，調(diào)整發(fā)布計劃，只發(fā)布完成并能夠充分測試的任務(wù)。

（2）保證發(fā)布任務(wù)量不變，重新調(diào)整發(fā)布時間，一般延遲到下一個升級周期，保證全部任務(wù)的完成度和質(zhì)量后與下一開發(fā)周期的任務(wù)一并升級。但要注意這種情況只允許延期一次，如果多次延期發(fā)布，會導(dǎo)致待發(fā)布的任務(wù)越積越多，進而增大升級風險。

2. 在開發(fā)周期內(nèi)，正式環(huán)境有緊急任務(wù)或緊急bug需要優(yōu)先處理

當正式環(huán)境的產(chǎn)品出現(xiàn)緊急問題時，其優(yōu)先級往往都高于計劃的任務(wù)，修復(fù)后還需要盡快發(fā)布。這勢必會影響整個開發(fā)與升級計劃。為了避免這種突發(fā)事件帶來的混亂，我做了以下預(yù)案：

（1）根據(jù)修復(fù)問題的工作量，開發(fā)可以與產(chǎn)品經(jīng)理等量置換計劃任務(wù)，產(chǎn)品經(jīng)理做開發(fā)計劃的變更。

（2）修復(fù)好的問題，盡可能在升級窗口與計劃任務(wù)一并升級。我們約定的升級窗口在周四，如果是周三發(fā)現(xiàn)的問題并且修復(fù)了，建議等到周四一起升級。如果是周一發(fā)現(xiàn)并修復(fù)的問題，就要看其緊急和嚴重程度來判斷了。

（3）如果要解決的問題重要且緊急，等不到升級窗口，那就在當天安排針對這一個事項單獨的緊急升級。由于周三是正常計劃中在BETA環(huán)境測試的時間，為了不打亂BETA環(huán)境下的測試工作，緊急升級盡可能避免在周三進行。

（4）如果必須在周三進行，則需要單獨為緊急升級的任務(wù)發(fā)起代碼合并請求，與計劃中的正常升級區(qū)別開來。

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

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