在台灣許多公司環境，PM 是不分產品或是專案的，甚至還要去管理 DevOps 維運，這問題牽扯到很多層面。

身為產品經理 / 專案經理的你，向利害關係人（老闆 / 客戶）闡述完你接下來要做的事期，他們一定都會跟你說：

1. 兩個 Sprint 才能完成的功項，給我壓縮到一個 Sprint
2. 成本最好壓低一點，最低價最好是能再砍個三分之一
3. 系統功能的交互 Loading 不能大於 2 秒

這些問題都發生在產品經理的工作日常上。初入行的產品經理遇到上述的問題，當下可能會非常地懊惱，最後想不出辦法只能默默接受 …

但你可曾想過，到底該怎麼規劃和執行，才能達到需求方的期望 - 要快、要好還要夠便宜？

​

目錄

1. The Impossible Trinity（三元悖論）
2. 想躲，躲不掉，遲早要還的
3. 如何說服利害關係人？

​

The Impossible Trinity（三元悖論）

國際金融學中的原則：The Impossible Trinity(不可能的三位一體) 又稱不可能的三頭馬車、三難選擇、不可能三角或三元悖論（Mundellian Trilemma），指一個國家不可能同時完成下列 3 者：

• 資本自由進出（Capital mobility）
• 匯率穩定（Exchange rate）
• 貨幣政策自主權（Monetary policy）

不可能的三位一體，其中只有 2 個是可以同時實現的。例如一個國家採用了 a 政策，就可以維持固定匯率和資本自由進出，但代價就是失去貨幣的獨立自主性。

在資本自由進出及固定匯率之下，政府無法固定貨幣供給，也不能固定利率，於是資本的流動將使利率趨向於國際利率水準，失去貨幣政策自主權。

不可能的三位一體原則簡單易懂，它不僅僅適用於決策者進行政策思考架構，這個分析思考模型，也可以廣泛用來分析任何事物或系統目標。

​

PM 在進行產品規劃、功能開發，也會遇到不可能的三角 （亦是專案管理金三角）：

• Time / Schedule（時間）
• Resource / Cost（成本）
• Quality（品質）

在之前撰寫的 PRD 相關文章 - 產品經理的硬實力 - PRD(產品需求規格書)， 不管你是專職產品經理的職務或是一人分飾兩角(產品規劃, 專案管理)的 PM, 你必須規劃整個 Scope, Resource. 也就是團隊投入的資源 - 時間、成本及品質。在 Scope 完全不做更動的情況下，PM 不可能同時擁有彈性的時間、充裕的資源以及符合交付標準的品質，這是產品經理必定面臨的難處 。

當你面臨既要，又要，還要的窘境，不妨想一想，現階段你能夠滿足哪幾個條件？而未能滿足的條件有哪些？不能滿足的原因是什麼？這時候你會怎麼規劃策略並實際行動呢？

​

想躲，躲不掉，遲早要還的

在理想的情況下，開發產品 / 專案的預算都是在實際開發前規劃好的，一但設定好預算、上限級距，後續就不會做變更。

不過身為蓋房子的工人，發現大樓沒電梯真的能不蓋嗎？（真人真事：悲劇！西班牙摩天大樓忘了重設計電梯）

開發期間，一定會遇到這幾個常見的阻礙因素：

1. 需求變更、新需求
2. 現有風險的影響、新風險
3. 修正合約、資源成本、經濟因素，甚至是疫情等因素所造成的成本估算變更

​

這幾個看似「正常」的事件，但其影響可大可小，嚴重的話可能會導致這項產品 / 專案提前結束：

• 執行期間需求變更範圍太大，讓開發團隊不足以應付，導致於整個產品變得不可行。

• 無法再取得足夠的資金來完成需求

• 發生重大風險，導致產品無法順利完成

• 買方或賣方認為不再需要這項產品的可交付成果（通常都是政治手段造成的）

  ​

除此之外，還有「外力影響」需要防範：

• 法律或法規的變更

• 對組織造成影響的合併或收購

• 全球或國內經濟變動（e.g. 2022 年下半年升息）

• 大環境（e.g. 2019 年底第一例的 Covid 19, 隨後全球開始大流行）

  ​

當上述的情況發生，PM 就必須對金三角或多個項目進行變更。有經驗的 PM 一定很有感，極力去追求「如期、如質、如預算」的最終成果，有時候只會帶來「反效果」。例如客戶沒有明確地把產業的 Domain Knowledge 告知開發團隊，而團隊進行需求訪談時也沒意識到，最後導致產品缺東缺西。

我們能以如期、如質、如預算為目標，但因為異動的可能性非常地大！應適時地按現況隨時去彈性調整計畫，逐步朝向目標邁進才是。

​

如何說服利害關係人？

在任何領域都存在著「三元悖論」，你不可能預算、品質、時程三者都要。在這三者的因素關係中，任何一個因素發生變化，都會影響至少一個其它因素：

1. 要快又要品質沒問題 => 得增加預算，請需求方多給錢，或是補更多資源，才能在有限的時間點內完成工作。

2. 要快又要價格便宜 => 和客戶一同將需求做排序，最糟糕的就是降低品質，這樣才能在短時間內，以同樣的預算金額交付最終成果。不過需求方必須得買單「品質」不怎麼樣的產品。

3. 要便宜又要品質好 => 感覺不急？那就是不急著要這東西，可做可不做或是延後進行。

​

根據一間研究顧問公司 - The Standish Group 於 2020 年公開的年度報告當中，研究全球50,000 個專案，66% 都以失敗告終。

軟體專案問題層出不窮，全球(含我國)軟體專案，真正如期、如質、如預算成功的案例，僅佔35%；其餘65%不是協商減價驗收，就是完全失敗。 而在如此高比例的失敗專案中，又以：

1. 需求不清
2. 需求無止境變更所造成的比例最大

另外，在台灣的採購習慣上，更有以下問題，大大提高了驗收難度：

• 選商不慎：低價搶標且沒有維護能力

• 履約不實：以虛偽不實文件投標或履約

  ​

在開始執行產品 / 專案的開發進行前，產品經理要和能夠直接影響 / 間接影響的相關利害關係人共同定義成功、交付準則：

1. 產品最終的價值、功能
2. 可接受最晚的上線時間
3. 開發產品的基本預算、後續追加預算

身為 PM, 先行掌握這個金三角不是要讓團隊盡快動工應付客戶，而是讓買賣雙方對於後續合作有基本的認知，做到教導客戶、管理客戶期望。

重點在於，PM 能時常意識到不確定性，並儘速採取行動。一但設定每個階段目標，進而解決特定問題並建立特定流程，逐步去交付滿足需求，可以大大地降低不確定性。

​

－做好期望管理，創造雙贏

身為團隊的 PM, 針對客戶需求與期望管理，是攸關最後驗收的結果，務必要重視、保有警覺心。

今天你遇到客務的要求：

客戶有 1 百萬的預算，要做一個像 Apple 的網站，公司行銷部門可以上架商品，一般會員可以查看商品和購買，總之就是跟這個網站差不多就好了。因為要趕在開學季活動，期望能在 2 個月內完工。

這時候身為 PM 的你會怎麼規劃？又如何和客戶做溝通？

1. 時間太趕了啦！真的沒辦法，這我們做不到！（超直白）
2. 二個月團隊只能實現 7 成，剩下的 3 成因為技術上的瓶頸所以實現不了 （婉轉拒絕）
3. 這個需求來的又急又快，經過團隊的工項分解：
   • 50 % 是網站的基本操作，包含公司介紹、產品說明、研發專利等，這個 30 天就完工了
   • 30 % 是商家的商品管理、上架，大約 10 - 20 天完工
   • 20 % 是會員的購物車、購買和金流等，大約 10 - 20 天完工
   • 再來是要確保品質，必須得進一步進行測試(功能測試, 壓力測試)，這部分也需要部分工時，總計要再多花 3 天進行。整體來說，技術上團隊是能做到的，但因為人力不夠、時間太短，如果您可以多付一些加班費，我們可以透過加班去完工。

不用多說，正常的客戶都喜歡第 3 種溝通方式吧！我一百萬都在花了，這團隊這麼有心多付點錢哪有差？

這裡不僅僅爭取到多一點預算，最重要的是針對客戶的期望做管理，首先對客戶的需求進行分解，先滿足最基本的要求，後續再迭代其他功能，一步步實現客戶的要求，最後讓客戶感受到超出預期的成功。

針對利害關係人的期望管理其實有很多可以聊，但這不在本篇的重點，後續有機會再分享。

不管是老闆、客戶，甚至是團隊本身，都希望產品能如期、如質、如預算交付最終成果，但基本上這是不太可能的。

你會遇到老闆或客戶跟你說：「每項都很重要！」、「每樣都必須在期限內完成」，然後 PM 就默默地接受，回到團隊內又被你團隊的成員轟到爆炸，這是誰的問題？

我認為這是 PM 的問題和責任，PM 必須和需求方溝通、協調，請對方是必得有所取捨，以滿足初期的目標，後續再分階段進行、迭代去做交付。

我們必須得教育客戶，把專業、能力攤在對方面前，讓人懂你的難處，並進一步要求對方適度地降低標準，這樣才有可能協商出一個彼此當前能接受的成果。