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

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

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

一、明確一次版本升級包含的任務數量

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

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

二、明確一次版本升級的執行周期

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

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

三、確定好一次版本升級在各環境發布的時間節點和重要事項

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

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

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

四、對常見的突發問題做好預案

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

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

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

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

針對這樣的突發情況，我提供了2種預案：

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

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

2. 在開發周期內，正式環境有緊急任務或緊急bug需要優先處理

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

（1）根據修復問題的工作量，開發可以與產品經理等量置換計劃任務，產品經理做開發計劃的變更。

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

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

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

本文由 @魚既 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。