距離你負責的產品年度最大改版上線日，只剩下最後一個月，進度落後兩週的事實，你和團隊其實都心知肚明。這幾個禮拜以來，你們每天的站會都在討論如何追趕進度，但幾個核心功能的複雜度就像泥沼，讓團隊深陷其中，難以脫身。

今天，是決定是否要向上呈報「專案延期」的最後期限。

你看著看板上那幾張依然停在「開發中」的關鍵需求任務，再看看行事曆上那個被紅圈標示、絕不能延後的上線日期，熟悉的焦慮感又油然而生。

這時，團隊的資深工程師阿傑為了打破沉默率先開口說道：「目前的開發進度確實落後了，如果要準時上線，我們勢必得做一些取捨...我的想法是這樣測試的部分，可能要稍微犧牲一下了。」他轉向 QA 工程師小梅：「小梅，我們先全力把功能做出來，上線前一週，我們全部門的人一起幫妳點一點、測一測，抓幾個重點流程就好。」

技術主管也立刻附和：「沒錯，現在最重要的是追上進度，確保功能能如期交付。我們先全力往前衝，品質問題之後再說。」

你看著大家為了準時交付這個共同目標而提出的「捷徑」，但在這股巨大的時程壓力下，實在是很難開口反對，兩難之下最後你也點了點頭說：「好的，那就辛苦大家了。」

於是整個團隊就像一輛為了追趕前車而拆掉煞車的跑車，以驚人的速度在崖邊的公路上狂飆，所有人都專注於油門踩得多深，卻沒有人留意前方的彎道與逐漸逼近的深淵。

症狀診斷

如果你的團隊也出現類似的狀況，在此鄭重宣布，你們已集體感染了「品質隨緣症」。

這個病症的根源，在於團隊錯誤地將品質保證這件事，當成了專案流程的「最後一個步驟」甚至是可忽略步驟，而非「每一個步驟」都應具備的內在屬性。

「品質」並不是像一件衣服，可以在產品完成後才穿上，品質更像是建築物的鋼筋，必須在打地基、砌牆、封頂的每一個階段，就牢牢地埋設進去。你不可能蓋完一整棟 101 大樓後，才在最後一天想著「我們現在該把鋼筋插進去了」。

許多團隊把「功能開發完成」當作「工作完成」，卻忽略了那些看不見的成本：一個未經測試的功能，就像一顆定時炸彈。你以為你完成了一項任務，實際上你可能只是在專案地圖上，又多埋了一顆地雷。

處方籤

這份處方，是你在面對「火燒屁股」的當下必須立刻服用的「強心針」。

第一劑：承認現實，引導團隊做出「聰明的妥協」

在巨大的時程壓力下，純粹地捍衛原則是非常無力的。

一個務實的 PM 會承認現實，但我們並不要直接放棄測試，而是需要嘗試帶領團隊的討論方向從「要不要放棄測試」，引導到「我們願意承擔多大的風險」。

你可以嘗試用這樣的方式來引導大家：「感謝大家提出方案，『犧牲部分測試來換取時間』確實是我們現在必須考慮的選項。不過，在我們做出這個決定前，我想確保我們都清楚這個風險有多大，並且把它降到最低。讓我們一起來做個討論，找出一個風險最低的折衷方案，好嗎？」

先把團隊從「全有或全無」的 2 選 1 框架拉出來。

第二劑：主導「風險評估」，聰明作戰

• 區分作戰優先級：將所有未完成的功能，根據「對使用者的重要性」和「出錯的毀滅性」，區分出「絕對不能出錯的核心戰區」（如：登入、付款）和「可容忍小瑕疵的次要戰區」（如：修改個人頭像）。
• 重新分配火力：你對團隊說：「我建議我們將 80% 的測試資源，集中火力在核心戰區，確保它們 100% 穩定。對於次要戰區，我們先進行基礎的測試，接受它可能有小 Bug 的風險。這樣能讓我們在有限的時間內，守住最重要的底線。」

B計畫：當怎麼分析都還是沒有辦法

好，我們又要來談談最讓人胃痛的時刻 : D。

如果在跟著團隊一起重新風險評估與資源分配，但整個精密計算後，依然還是只剩下兩個選項

A. 準時上線，但帶著一堆已知和未知的 Bug

B. 延後上線一週，確保品質。

那麼，這時候我們就必須要向上呈報，告訴老闆有這樣的狀況。我們必須要讓老闆明白這個延期決定的重要性和嚴肅性。但同時，我們也要避免只是把問題丟給主管，而是提供清晰的選項和建議。

當你向老闆匯報時，建議可以參考下面的溝通框架：

• 直接說明狀況：
  「經過團隊的仔細評估，我們遇到了嚴重的進度挑戰。我們已經嘗試了所有可能的方案，但仍面臨兩個選擇：準時上線但帶著風險，或延期一週確保品質。」
• 提供具體數據：
  「我們目前有 X 項核心功能尚未完成測試，根據以往經驗，這些功能至少需要 Y 天才能完成充分測試。若準時上線，我們估計可能有 Z% 的用戶會遇到問題。」
• 清楚說明兩種選擇的風險與機會：
  「選項 A - 準時上線：優點是維持原定時程，但我們預估有 X% 機率會發生嚴重問題，可能導致客戶流失、緊急修復成本、品牌形象損害。」
  「選項 B - 延期一週：優點是確保產品品質，降低 Bug 風險，但會錯過原定上線日期，可能影響市場預期和短期營收目標。」
• 提供你的建議：
  「基於現行團隊的專業評估，我建議我們選擇選項 B。雖然會延期一週，但這樣能確保產品品質，避免更嚴重的風險。我們已經準備好了詳細的延期計劃，包括如何調整資源、通知利害關係人以及修改行銷計劃。」
• 展示團隊的承諾：
  「無論您做出哪個決定，我們團隊都會全力以赴。如果決定準時上線，我們會制定應急方案來處理可能的問題；如果決定延期，我們會確保這一週的時間得到最充分的利用。」

你的目標不是推卸責任，而是幫助老闆做出明智的決策，提供足夠的資訊和你的專業建議，但最終尊重老闆的決定。

特別門診：如何打造團隊的「品質免疫系統」

上面的急救處方能幫你度過眼前的危機，但要讓團隊不再重蹈覆轍，你需要的是長期的預防醫學。以下是幾帖能從根本上強化團隊品質體質的良藥。

• 第一帖：建立團隊的法律 → 約定 DoD
  身為 PM，當然不會由你來定義出「單元測試」等等技術細節。你的職責是召集並主持一場由技術主管、資深工程師和 QA 共同參與的會議，共同定義達成哪些條件才可以稱作 DoD 。這份文件一旦被團隊共同約定，它就是規則。然而，就像開頭的情境一樣，光有規則是不夠的，更重要的是在危機時刻，有人願意站出來捍衛它。 DoD 的真正價值，體現在團隊面臨時程壓力，依然能將其視為不可動搖的底線，確保每個人對「完成」有著一致的、包含品質的標準。
• 第二帖：將品質內建於流程 → 測試左移
  測試左移的核心精神是：越早發現 Bug，修復的成本就越低。與其在終點線前才做總測試，不如在開發路徑上設置一系列小關卡，例如導入 CI 工具、讓 QA 早期介入需求討論等，從源頭開始預防 Bug 的產生。
• 第三帖：讓品質債務視覺化 → 建立 Bug 儀表板
  有時候，團隊之所以忽視品質的重要性，是因為他們看不見「債」的代價。可以使用 Jira 或其他工具，建立一個所有人都能看到的儀表板，追蹤 Bug 數量、嚴重性、修復時間等指標。當團隊親眼看到，為了修復一個 Bug 所付出的代價時，也會更有機會讓他們開始重視前期的品質投入。

最後的醫囑

品質不是靠緣分、祈禱，更不是靠上線前幾天不眠不休的「人肉測試」。我曾因專案時程壓力而測試到半夜無法回家，結果隔天產品上線仍出現嚴重問題。更糟的是，前晚測試到精疲力竭，隔天完全沒有精力即時處理線上危機。這證明了壓在最後一刻是極為危險的做法。品質不只在最後階段才重要，而是需要團隊全體成員從一開始就重視，在整個開發過程中日積月累地打造出來。

一個充滿 Bug 的產品不僅傷害公司的聲譽和營收，而且沒有任何工程師會為自己寫出的 Bug 感到自豪。

我們必須將品質的責任從單一 QA 身上，分散到開發流程的每個環節、每個人的心中。因為你知道，預防永遠勝於治療，尤其是在專案管理這個高壓的急診室裡。

完全沒測試就上線的專案上線

真實經驗記憶猶新宛如昨日