你是否曾經聽過客戶開需求的時候，越想越興奮，功能越開越多：
「我的網站會有國外的用戶來訪，幫我做個中英雙語的版面。」
「另外，不同語言的 SEO 能否也幫我做一做？對了，日韓的用戶可能比較多，也留個後台讓我能自己新增不同語系好了，這樣就不會麻煩你們了！」

你本來只是想説套個 i18n 切換個靜態網頁的語言，頂多針對中文和英文的 Layout 稍微調整一下，不要跑版即可。卻突然要針對不同語系的 SEO 要優化，多了個後台要開發。

「等等，能不能預留個擴充性，購物的商品名稱和內容也要可以新增不同語言，再麻煩你了！」一時興起的客戶多加了個需求，你仔細想想，突然發現商品不是存在資料庫的嗎？那麼兩種語言的商品是要每個語言多一張表呢，還是每個商品的名稱、敘述等等都要多個欄位⋯

產品開發的時間、成本、範圍

上述狀況就是客戶所開需求的「範圍」太大了，多語言這種功能要做到極致，可以納百川。但是功能要做深，不但花的時間可能呈指數成長，而且帶來的效益也不見得能夠成比例的增長。

不過，此時若是直截了當的拒絕客戶，可能會得到不諒解。因為在客戶的腦海中，這增加一點點的功能，應該是不會花工程師這麼多時間吧？

可能更好的做法，是和他們說需求增加的「範圍」，會連帶增加開發的「成本」，例如新增 SEO 優化就要多一個工程師一個月的時間，好歹也要多報個 10 幾 20 萬新台幣。

又或者包含，這會連帶增加開發的「時間」：「雙語言的 SEO 會讓專案延期兩個月，設計管理者增加語系的功能要架設後台、資料庫，少則多四個月，多則半年，這樣子你們能夠接受嗎？」

正所謂又要馬兒跑，又要馬兒不吃草是不切實際的，增加需求的範圍必定會提高開發的時間和其他成本。

專案管理三角形

這邊所說的「時間」、「成本」、「範圍」，剛好可以畫出一個三角形，稱作專案管理三角形。

*專案管理三角形

三角形的中間則是「品質」，意味著在保持品質的前提下，如果調整任意一個因素，勢必會影響到另外兩個因素。

新增功能：就像是上述例子中所舉的增加「範圍」勢必導致「時間」及「成本」的變化。

縮短時限：而如果想讓專案的「時間」減少，盡快結案，那麼不是錢給得更多（成本），就是做的事情更少（範圍）。

壓低價格：又或是想降低金錢「成本」，那麼不好意思，專案可能要延期（時間），或是需求（範圍）少做一些。

當以後聽到新的需求，亦或是想要壓低開發的價格或提前專案 Deadline 時，可以想想專案管理三角形，避免落入「多快好省」的陷阱。