在《#063 搞懂版本控制，上線前的防護網》 我們談了版本控制。團隊有了可以回溯的時光機，理論上，哪一版改了什麼、哪一段邏輯什麼時候被加進來，都查得到。問題是，查得到，不代表就講得清楚。真正進到上線與維運階段，很快就會遇到另一個更直接的問題。當系統出問題要退版，究竟是退到哪一版。
系統一出事，PM 最容易脫口而出的話就是「先退回上一版」。這句話聽起來合理，但只要團隊沒有一套明確的版號規則，這句話其實非常危險。因為你說的「上一版」，有可能是昨天下午修完 Bug 的那一版，也可能是上個星期還沒加新功能的那一版，甚至可能是測試環境那一版。每個人腦中想的都不一樣，最後最可怕的不是系統出事，而是沒有人能直接回覆狀況。
這就是版號存在的價值。它不是工程師拿來標示檔案的形式，也不是為了看起來專業。它的作用很單純，給整個團隊一個可以精準指向某個版本狀態的編號。你只要講對版號，團隊才知道現在在談哪一個版本狀態，問題才有辦法處理。
◆ 有了版本控制，為什麼還需要版號
很多人會問，既然 Git 都能追蹤歷史紀錄了，為什麼還需要版號。原因在於，版本控制處理的是程式碼歷史，版號處理的是團隊溝通與發布管理。
Git 很適合回答這些問題。誰改了什麼，哪一天改的，這次修改影響哪些檔案。
版號更適合回答另一類問題。現在正式環境跑的是哪一版，這一版包含哪些功能，客服回報問題時該先核對哪個版本，出了重大問題要先退回哪個穩定版本。
你可以把兩者分開理解。版本控制比較像內部履歷，版號比較像對外發布與對內溝通的門牌號碼。沒有門牌號碼，你還是找得到歷史資料，但每一次都要先花時間把位置講清楚。系統出狀況時，這種多花出去的時間，往往就是壓力開始失控的起點。
◆ 三層式編碼，讓團隊有一種講得清楚的方式
業界有很多種版號命名方式。有些團隊用語意化版本，有些團隊用日期，也有些團隊把內部流水號放進去。格式不是唯一答案，真正重要的是，你的團隊有沒有一套固定規則，讓大家看到數字就知道它代表什麼。
以我自己比較常見、也比較習慣的做法來說，會採用一種三層式編碼，例如
v1.0.000001
這不是一串拿來裝飾的數字，而是一組有結構的資訊。
第一碼，大版號（Major）
大版號通常對應系統的重大變動。可能是架構調整、底層邏輯改寫，也可能是整個介面與流程的大幅翻新。當版本從 v1 進到 v2，通常代表這不是小修小補，而是使用方式、技術結構，甚至測試與驗收方式都可能一起改變。
第二碼，中版號（Minor）
中版號通常對應功能更新。新增了一個可被感知的功能模組，例如報表匯出、付款方式擴充、會員中心改版，這時中版號就會進位。它傳達的訊息是，這一版不只是修正，而是多了新的東西。
第三碼，小版號或流水編碼（Build）
這一段最細，也最容易被忽略。只要程式碼有任何修改，不管是修一個小 Bug、調整一個提示文字、修補一個條件判斷，小版號都可以往前推。它的重點不是宣告「有新功能」，而是幫團隊留下可精準識別的順序。你之後在查問題時，這一段反而最有價值。
這種規則的好處不在於它漂亮，而在於它讓團隊很快知道，眼前這個版本是大改、功能更新，還是持續修補中的某一次結果。
◆ 專案版號，是 PM 對內對外溝通的主座標
除了前端版號與後端版號之外，實務上通常還會再有一個更上層的版本，也就是專案版號。
這個版號不是拿來取代前端版號或後端版號，而是作為整個產品發布時的主要識別編碼。
意思是，每一次正式上版本時，團隊對外公告、對客服說明、對營運與業務溝通，通常不會直接講前端版號或後端版號，而是以專案版號作為對外的主要版本名稱。
例如這次發布的是 v2.3.0，這就是這一次上線對外溝通的版本。
但在團隊內部，這個專案版號背後，其實還會對應一組更細的技術版本資訊，例如
- 專案版號 v2.3.0
- 前端版號 v2.3.0.102
- 後端版號 v1.8.0.245
這種情況很常見。因為專案版號進版，可能代表這次有一個新功能或一個正式發布節點，但實際上，前端與後端的變動不一定同步。
有時候是後端修了一段商業邏輯，對使用者畫面沒有任何改變，因此後端版號有進版，前端版號沒有變動。
也有可能只是前端調整文案或介面排列，後端完全沒動。
所以對 PM 來說，要有兩層理解。
第一層是對外溝通用專案版號。
你面對客戶、客服、營運、業務，甚至公告與驗收文件時，主要使用的是這一組版本。因為它代表的是這一次發布的產品狀態，而不是某一端的技術細節。
第二層是對內追查用前端版號與後端版號。
當發生資料對不起來、畫面沒更新、規則異常、API 行為不一致時，PM 就不能只停留在專案版號，而要進一步確認這個專案版號所對應的前端與後端實際版本。這樣問題才查得下去。
◆ 前端與後端，版號本來就可能不一樣
PM 需要先接受一個很基本的現實。前端與後端的版號，很多時候本來就是分開管理的。
原因不難理解。前端面對的是畫面、互動、流程與顯示內容，更新頻率通常比較高。後端面對的是規則、資料與服務邏輯，雖然也會變動，但節奏不一定和前端同步。所以你可能會看到前端已經走到 v2.5.000345，後端還停留在 v1.2.000120。這種情況很正常，不代表誰落後，也不代表管理混亂。
真正重要的是，PM 要清楚知道一個功能上線時，它對應的是哪一個前端版本，以及哪一個後端版本。
因為有些問題不是單看其中一邊就能判斷。畫面已經更新，但 API 還沒切到正確邏輯。後端規則已經修正，但前端還在舊版流程。這些都是專案實務裡非常常見的問題。沒有版號，大家只能靠印象推測。有版號，至少能先把問題範圍縮小。
所以版號管理不只是為了追發布歷程，它也是 PM 在驗收與維運階段辨識問題來源的工具。
◆ 版號真正的價值，不只在記錄歷史，更在安排專案節奏
很多人一開始理解版號，會把它當成一種歷史紀錄。這樣的理解不能說錯，但只說到一半。因為在專案執行的實際情況裡，版號更重要的價值，往往不在回頭看，而在於往前安排。
專案進行時，不可能永遠只看「下一個版本」這麼單純。更多時候，大系統更新、小功能上線、日常 Bug 修正，都是穿插進行的。這時候如果沒有版本規劃，需求就會一股腦地往前擠，今天說這個先上，明天又說那個比較急，最後整個專案不是在推進，而是在被需求牽著走。
有了版號的概念之後，PM 才能開始做一件更重要的事，預先安排版本節奏。
例如先定義下週要上的版本，是以 Bug 修正為主，還是包含某個新功能。再往後看，如果是重大功能更新，或是牽涉到底層結構調整，就要思考它應該落在哪一個版本，是否需要先做測試準備、資料轉換、客服說明，甚至是否要避開某些高風險時段。
換句話說，版號不是等事情做完之後才補上的標記，而是專案推進過程中的節奏控制工具。
它幫助團隊把不同性質的工作分開，讓大家知道哪一版是穩定修補，哪一版是功能擴充，哪一版是結構性調整。當版本安排清楚，需求就比較不容易彼此擠壓，測試、驗收、上線也才有可能跟著穩定下來。
對 PM 來說，真正的差別就在這裡。
沒有版本規劃時，你很容易被需求追著跑。
有了版本規劃之後，你才有機會把需求放進適當的節點，決定什麼先做、什麼延後、什麼需要準備期。也就是說，版號讓 PM 從被動接球，慢慢回到主動安排專案進程的位置。
◆ 版號還有另一個用途，是判斷要不要更新
版號除了用來追溯、退版、溝通之外，還有一個非常實際的用途，就是判斷目前的客戶端是否需要更新。這件事對 App 特別重要。
因為 App 的更新，不一定每次都代表整包都要重新安裝。有些更新影響範圍很大，例如核心流程調整、資料結構改變、安全機制修補，這種情況就可能需要整個 App 進行更新。
但也有一些更新只是調整文案、圖片、設定檔、活動頁內容，這時候可能不需要使用者重新安裝 App，而只是下載新的資源檔即可。
系統怎麼判斷要走哪一種方式，很多時候就是靠版號規則。
例如先比對專案版號，確認目前使用者所使用的是不是這次正式發布的版本。必要時再往下比對資源版號、前端版號或其他細部版本，進一步判斷這次差異屬於哪一種狀況。
- 必須整包更新
- 只需要更新資源檔
- 目前版本仍可繼續使用
這種判斷如果沒有版號規則支撐，最後就只能依賴人工判斷，或讓系統在模糊條件下自行處理。前者效率低，後者風險高。
所以版號在這裡不只是記錄歷史，它同時也是版本升級策略的一部分。
◆ 為什麼團隊一定要有版號規則？因為追溯與退版都不能靠感覺
版號格式可以不同，但團隊一定要有一套共通規則。原因只有兩個，而且這兩個理由都很現實。
第一，功能追溯
客服接到回報時，PM 第一個問題不該只是「你遇到什麼問題」，還應該先確認現在使用的是哪一個版本。版號一旦明確，工程師才有辦法往回查，這一版包含哪些功能、哪些修正、哪些已知風險。否則團隊討論半天，講的可能根本不是同一個系統狀態。
第二，精準退版（Rollback）
當新功能上線後，若發現造成嚴重異常，現場最需要的不是空泛地說「先退掉」，而是明確指定退回哪一版。例如退回 v1.2.000150 這個穩定版本。這一串數字的價值，在於它能讓工程師在最短時間內回到正確位置，而不是在壓力下憑記憶判斷。
退版這件事之所以能成立，不是因為大家夠冷靜，而是因為平常就有把版本編號管理清楚。沒有版號規則，退版也只能變成模糊指令，風險並不會比較小。
◆ 版號不是只有工程師要看，PM 更需要看得懂
很多初階 PM 看到版號，會下意識覺得那是工程端的資訊，自己只要知道「有上線」就好。但只要經歷過幾次上線出錯、回溯困難、現場誰都說不清楚現在跑的是哪一版，你就會知道，版號和 PM 的工作關係其實很近。
PM 不一定需要制定版號規則，但至少要能理解團隊使用的版號邏輯。你要知道這次是大版更新、中版功能調整，還是小版修補。你也要知道測試中的版本、正式環境的版本、客服目前收到回報的版本，是否指向同一個地方。
因為你一旦說得出來，會議裡的討論就會穩很多。你不是在講模糊感覺，而是在講具體版本。這種差異，看似只是多一串數字，實際上卻是專案管理成熟度的差別。
◆ 廣三觀點
嗨，我是廣三。很多 PM 一開始看版號，真的會覺得那只是工程師拿來標記檔案的數字，跟自己關係不大。但只要經歷過幾次上線出狀況，半夜大家圍著電腦問「現在到底是哪一版」卻沒有人能立刻回答，你就會知道，版號不是技術細節，而是專案管理的一部分。
我一直覺得，版號比較像產品的履歷。它記錄這個系統走到哪裡，也提醒你每一次更新到底帶來什麼改變。當你能在會議裡很自然地說出，下週二預計發布 v2.1，這一版的重點是購物車新功能；若只是小範圍修正，則會延續 v2.0 的小版號往前走。你其實已經不是在背數字，而是在用一套明確方式管理節奏。
PM 不需要會寫程式碼，但你要知道什麼時候該踩油門，什麼時候該踩煞車。版號，就是你手上最基本、也最不該忽略的那一組儀表板。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
請於下方輸入電子郵件信箱，即可接收最新訊息。
探索更多來自 AI時代|PM破局未來 的內容
訂閱即可透過電子郵件收到最新文章。
留言