Skip to content

Product Builder 面試日練 — 2026-09-19：Technical PM

2026年9月19日1 分鐘
首頁›daily
TL;DRTechnical PM 面試最容易被看穿的地方,是把版本策略講成一句「我們會做 v1、v2」,卻答不出誰該承擔升級成本、多久允許一次 breaking change。今天練一道情境題:企業合約要求 API 六個月內穩定不能無預警改格式,工程團隊目前沒有版本管理。答案框架是版本策略選項比較(路徑版本、header 版本、日期滾動版本)搭配 Cost-Reversibility 權衡矩陣,把每個選項的工程成本與客戶風險攤開來比。案例是 Stripe 用日期命名的滾動版本策略——每月版本只允許相容變更、每半年一次大版本才准破壞相容性,且每個帳號可以釘住自己的版本,讓 API 十幾年沒有真的「壞」過任何一個整合。
#product-builder-interview#daily#technical-pm
系列: Product Builder 面試日練 (31 / 32)
Product Builder 面試日練 — 2026-09-18：Growth & Experimentation

🌏 English version

今日主題

Technical PM 面試裡最容易看出深淺的問題之一,是「你的 API 要怎麼做版本管理」。多數候選人會直接跳答案——「我們會用 v1、v2 這種路徑版本」——但這其實只回答了「怎麼標示版本」,沒回答真正困難的部分:誰該承擔升級成本(是平台團隊吃下相容性維護,還是要求所有客戶配合遷移)、多久允許一次會破壞相容性的改動、以及當業務端簽了「不能無預警改格式」的合約條款時,工程團隊的日常改動節奏要怎麼跟這個承諾對齊。

這個主題在面試中重要,是因為它同時考驗你能不能把一個表面上的「技術規格選擇」,翻譯成一個有明確代價歸屬的商業決策——而不是丟出一個聽起來很懂技術的名詞就結束。

核心框架速記

API 版本策略選項比較

在決定怎麼版本化之前,先把常見選項的代價攤開來看,而不是憑直覺選一個:

策略做法對客戶的影響對工程團隊的維護成本
路徑版本(/v1/、/v2/)URL 直接標示大版本清楚,但每次大改都要客戶主動遷移到新路徑中——要同時維運多套路徑的程式碼
Header 版本客戶在 request header 指定版本號不易發現自己用的是舊版,容易被動忽略升級通知低——邏輯可以共用同一套路由
日期滾動版本每次改動標記發布日期,帳號可釘住特定日期版本最細緻,升級頻率自己決定高——要維護每個歷史日期版本的行為快照

面試時的用法:被問「你會怎麼做版本管理」時,不要只回答格式,要先講清楚你選的策略把升級成本放在誰身上,以及這個選擇如何對應公司當下最在意的東西(客戶信任 vs. 工程維護資源)。

Cost-Reversibility 權衡矩陣

技術決策常常被簡化成「這個方案比較貴/比較便宜」,但真正該比的是兩個軸:短期實作成本,以及這個決定日後能不能撤回。

容易撤回難以撤回
短期成本低先做,快速驗證(例如先手動維運一個版本,觀察真實需求)危險區——便宜但鎖死未來選項,要格外小心
短期成本高可以晚點做,等訊號更明確再投入需要 RFC/ADR 等級的審慎討論,通常要先取得跨團隊共識

面試時的用法:被問「你怎麼判斷該不該多花工程資源做一個更完善的方案」時,不要只講 ROI,要先定位這個決定落在矩陣的哪一格——尤其要主動指出「難以撤回」的選項,因為那是最常被低估風險的地方。

今日練習題

題目

「你剛加入一家中型 SaaS 公司,擔任平台團隊的 Technical PM。銷售部門簽下一筆大型企業合約,對方要求六個月內能透過 API 存取公司的三個核心資料物件(帳務、使用量、稽核紀錄),合約條款還載明:API 格式之後不能無預警變更,否則對方有權要求違約金。你去看現況,發現工程團隊目前的做法是每次需求變動就直接改既有 REST 回應的欄位,完全沒有版本管理。你要怎麼設計因應方案,並讓工程團隊願意接受這個新的約束?」

(來源:自擬,情境設計參考 Dataford Docusign / Fivetran Technical PM 面試題庫中常見的「API-first 產品」與「架構權衡」題型)

拆解思路

  1. 釐清問題:先問——合約裡「不能無預警變更」的具體定義是什麼(多久算「預警」?格式變更是否包含新增欄位,還是只限制刪除/改型別)?目前有多少既有客戶已經在用這三個物件的 API,他們的整合方式有多脆弱?六個月內除了這個企業客戶,還有哪些內部需求會逼工程團隊想改格式?
  2. 定義使用者:這裡至少有兩群使用者要同時照顧——外部企業客戶的整合工程師(在意穩定性、不想每季重寫串接程式碼)、以及內部工程團隊(在意能不能持續快速迭代資料結構,不被過去的承諾綁死)。方案不能只偏袒一邊。
  3. 結構化分析:用版本策略選項比較表,排除「路徑版本」(對這種需要細緻控制升級節奏的企業客戶太粗) 和「header 版本」(太容易被忽略、無法給出明確的相容性承諾),鎖定日期滾動版本作為候選;再用 Cost-Reversibility 矩陣檢查——現在導入版本管理制度屬於「短期成本高、難以撤回」象限,代表這值得先過一輪 RFC,而不是工程團隊私下決定。
  4. 提出方案:採用日期滾動版本——每月發布的變更只允許向後相容(新增選填欄位、不能刪除或改型別),每半年一次的大版本才允許破壞性改動,並提前在文件與 changelog 公告;每個客戶帳號預設釘住申請當下的版本,除非主動升級。企業客戶的合約承諾轉譯成內部規則:任何要跳過這個流程的緊急改動,都要走例外審核,而不是預設允許。
  5. 定義成功:護欄指標是「每次月版本發布造成的客訴/支援工單數」要維持在低點,主要指標是「企業客戶六個月內零非預期格式變更投訴」;同時追蹤「工程團隊維護多版本的額外工時佔比」,如果超過某個門檻,代表版本策略的粒度要重新談,不能讓穩定性承諾無限期吃掉工程產能。

範例回答(面試時可以這樣講)

問題釐清與定位:「我會先確認合約裡『不能無預警變更』具體指什麼——是完全不能動這三個物件的格式,還是只要求新增欄位這類相容變更要提前公告、破壞性變更才嚴格禁止?這個界線會決定我接下來要設計多嚴格的版本策略。我也會去看現在有多少既有客戶已經在串這幾個 API,因為新制度上線的過渡期,他們也會被影響。」

結構化分析與方案:「確認之後,我會排除路徑版本跟 header 版本,因為前者對這種需要細緻升級節奏控制的企業客戶來說太粗,後者太容易被忽略、給不出明確的相容性承諾。我會選日期滾動版本——參考業界已經驗證過的模式,每月只發相容變更,每半年一次的大版本才准動到既有欄位,而且每個帳號預設釘住自己申請時的版本。因為導入這套制度屬於『短期成本高、事後難撤回』的決定,我不會讓工程團隊私下決定,而是先寫一份簡短的 RFC,把這個承諾轉譯成內部規則——例如什麼情況算例外、誰有權核准跳過流程的緊急改動。」

成功定義:「我會用兩組指標檢查這個方案有沒有真的成立。護欄指標是每次月版本發布後的客訴或支援工單量不能上升,主要指標是六個月合約期內,這個企業客戶零非預期格式變更的投訴。但我也會同步追蹤工程團隊花在維護多版本相容性上的工時佔比——如果這個成本高到吃掉正常開發產能,代表版本策略的粒度要重新談判,而不是讓一個業務承諾無限期綁架工程資源。」

自我核對清單

用這張表檢查你的回答有沒有漏掉關鍵點:

核對項目有提到?
先釐清合約承諾的具體邊界,而不是直接假設「完全不能改」
同時照顧外部客戶穩定性與內部工程迭代速度兩種使用者
用結構化方式比較版本策略選項,而不是憑經驗直接選一個
判斷這個決定的可撤回性,決定要不要先走 RFC 等審慎流程
成功指標同時包含客戶端保護與工程端成本上限,而非只看一邊
加分項:提到用真實產品案例佐證版本策略的長期可行性

今日案例

Stripe:用日期命名的滾動版本,讓公開 API 十幾年沒有真的「壞」過

Stripe 在其公開 API 的版本策略中,採用以發布日期命名的滾動版本(例如 2017-05-24)。每個帳號在第一次呼叫 API 時就會被釘住當下最新的版本,之後除非開發者主動在 dashboard 或 request header 指定升級,否則行為不會改變。Stripe 的規則是:每月的例行更新只包含向後相容的變更(新增欄位、修正明確的錯誤行為),每年兩次的大版本(以命名版本區分,例如 2024-09-30.acacia)才允許真正的破壞性改動,並提前在官方 changelog 完整記錄每一項差異。這套機制讓 Stripe 能持續改進 API,同時對外承諾「你的整合不會無預警壞掉」。

面試連結:這個案例是「合約要求 API 半年內不能無預警改格式」這道情境題的真實答案版本,可以直接拿來回答「舉一個你認為做得好的 API 版本管理案例」,也可以用來檢驗自己的方案有沒有漏掉關鍵細節——尤其是「帳號釘住版本」跟「大版本 vs. 小版本的頻率切分」這兩個決定,正是 Cost-Reversibility 矩陣裡「難以撤回」象限該有的審慎設計。

延伸閱讀

參考資料

相關文章

Product Builder 面試日練 — 2026-09-12：Technical PM1 minProduct Builder 面試日練 — 2026-09-05：Technical PM1 minProduct Builder 面試日練 — 2026-08-29：Technical PM1 min