作者┃Shawn

專案會議上，大家已經討論了一個小時。

業務團隊認為應該盡快上線，先搶占市場時機；產品團隊擔心需求還沒釐清，現在上線只會留下更多問題；技術團隊則強調資源不足，希望縮小範圍。

每個人說的都有道理，卻沒有人願意退讓。會議結束時，主持專案會議的你只能說：「大家再想一想，我們下次繼續討論。」

專案表面上卡在意見分歧，實際上卡住的，往往不是大家意見不同，而是團隊還不知道該如何處理這些不同。

分歧不是意外

許多人會把分歧視為一種異常狀態：只要溝通得更充分，大家最後就應該得出同一個答案。

但專案涉及的角色越多，各自看到的風險、責任和目標就越不同。業務關注時機，產品關注使用者體驗，技術關注可行性。這些差異並不是誰不配合，而是不同職位正在保護不同的東西。

如果你一開始就要求「統一意見」，團隊通常會走向兩個結果：一種是繼續爭論，試圖證明自己才是對的；另一種是表面同意，實際執行時仍然各走各的。

真正需要處理的，並不是如何讓所有人擁有相同看法，而是如何讓不同看法進入同一個決策過程。

會議為何反覆打轉

討論會卡住，常常是因為團隊把不同層次的問題混在了一起。

有人在爭論事實：「使用者到底會不會需要？」有人在爭論優先順序：「速度和完整性哪個更重要？」有人在表達風險：「如果出了問題，誰來承擔？」還有人已經跳到方案：「我們應該先做 A，不要做 B。」

這些話聽起來都像意見，背後處理的卻不是同一種問題。只要它們混在一起，參與者就很難回應彼此，只會不斷重複自己的立場。

這時，主持專案會議的你若急著表態支持其中一方，可能會暫時結束會議，卻不一定能真正解決分歧。沒有被看見的擔憂，之後往往會以消極執行、反覆質疑或跨部門摩擦的方式重新出現。

先辨認分歧在哪裡

當討論開始繞圈，你可以先暫停方案之爭，問團隊一個簡單的問題：

「我們現在分歧的，究竟是對事實的判斷、目標的優先順序、風險的承受程度，還是具體方案的選擇？」

這個問題的作用，不是立刻找出正確答案，而是幫助團隊確認：大家究竟在討論什麼。

如果分歧來自事實判斷，就需要補充資訊或驗證假設；如果來自優先順序，就需要明確這一階段最重要的目標；如果來自風險承受程度，就要決定哪些風險可以接受、哪些不能；如果只是方案不同，才適合進一步比較各方案的成本與效果。

當分歧被準確命名，團隊才能從彼此反駁，轉向共同處理問題。

把立場變成標準

下一步，不要只問成員支持哪個方案，而要追問他們想保護什麼。

你可以請每一方說明：

「你堅持這個方案，最希望保護的是什麼？」

「如果採用另一個方案，你最擔心發生什麼？」

「什麼條件得到滿足後，你願意支持其他選擇？」

這些問題會把「我支持方案 A」轉化為更具體的判斷標準，例如上線時間、使用者影響、技術風險、資源投入或後續維護成本。

一旦這些標準被擺到桌面上，團隊就不必再決定誰贏誰輸，而可以共同判斷：哪個方案更符合目前專案真正重視的條件。

推進不等於達成全體共識

你或許會擔心，只要還有人不同意，就不能做決定。但專案推進並不要求每個人都認為某個方案最好。

更實際的狀態是：大家理解决定為何這樣做，知道哪些擔憂已經被納入考量，也清楚接下來由誰負責、何時檢查結果，以及什麼情況下可以調整。

如果資訊仍然不足，也不必讓討論無限延長。團隊可以先確定一個可逆、範圍有限的嘗試，例如用兩週驗證關鍵假設，再根據結果決定是否擴大投入。

這不是迴避決定，而是把無法靠爭論解決的分歧，轉換成可以透過行動取得的資訊。

建立決策出口

下次專案因意見分歧停滯時，你可以依序做三件事：

先確認團隊分歧屬於哪一種問題；再把各方立場背後的擔憂整理成判斷標準；最後明確誰來決定、根據什麼決定，以及決定後的檢查節點。

你真正要推進的，不是所有人的意見變得一致，而是讓團隊即使帶著不同判斷，也能形成一個清楚、可執行、可複盤的決定。

當分歧有了被理解的位置，決定有了明確的出口，專案才會重新向前移動。