我之前待過一間軟體公司，曾經有件讓我記憶深刻的事情。 當時的老闆希望製作一份產品介紹的光碟，能在客戶放入光碟時跳出一個歡迎頁面，讓觀看光碟的人可以選擇相關產品的介紹或是短片。

當時老闆交代一名新來的工程師：「也不用弄的多特別，就做個簡單的網站吧。 讓使用者放入光碟時，會自動打開裡頭的網站，然後他就可以點選連結看介紹影片」。 可是那時候Windows一直在改造他的系統安全設定，所以如果有網站是在光碟或是硬碟上的話，系統會跳出一個類似下圖的警語： 

 

某天下班前，我很偶然的關心了他一下，問他：『怎麼啦？ 似乎花了很長的時間在處理？』 他一邊搔著亂髮，一邊跟我說他碰到的困難，還告訴我他試了很多高深的技巧想破除這問題 (但老實說，我其實根本聽不懂那是些甚麼高深技巧)。 我疑惑的問道：『聽起來似乎很麻煩啊？ 為何你不直接用程式寫個簡單的歡迎視窗，並放些選單讓使用者來點選，那對你來說應該不難才是？』

「是不難，可是老闆說要用網站啊！」他回答我。

『唔，這點我不確定耶，我並不真的認為他一定就要網站，他可能.只.是.以.為.做網站比較容易？ 但畢竟光碟的.目.的.是介紹產品，有個不造成使用者困擾的介面應該不論是怎麼形式都OK的吧？ 你要不要再跟他聊聊？』我沉吟道….

「不用了！ 其實研究這東西很有挑戰性喔！ 還是讓我再試試吧！」

我不知道還該說甚麼，畢竟不是我的案子也不好再多管閒事，只好作罷回家了。

後來幾天，他還是一樣整天搔著頭髮在他的小隔間中唉聲嘆氣，甚至某天早上我來開門時，發現他還趴在桌上睡著了，後方的垃圾桶還有兩個空泡麵盒子，似乎根本整夜沒回去。 但是很遺憾，雖然他這麼辛苦又努力，最後卻始終沒能有進展，問題始終沒解決。 又過幾天，那位置的桌子空了下來。

後來，又有個新人進來。 這次大家學聰明了，請他寫個選單程式就好。 他僅花了下午的幾個小時就寫好了一個簡單大方的介面，之後內容製作的工作就終於可以繼續開始了。

這是很多時候人們常走不過的一個盲點。

成案的目的通常是為了解決一個問題，但如果我們沒有想的周全時，有時候我們會抓住一個解決方法而把他當然唯一解、或是最佳解。 就算它不是這麼完美，我們也因為太早開始思考如何滿足「以那方法」來解決的細節問題，而忘記其他東西。 到最後，甚至完全忘了滿足那個方法並不是我們的目的，那不過只是解決問題的過程而已。

「一個只會使用榔頭的人，所有問題看起來都像是根釘子」，忘記誰說過這麼有意思的一段話。

學校雖然讓我們專精於某項事情(深度)，但卻減弱了我們面對問題時的廣度。 也因此我們若很會挖井，在沒水喝時就會抓緊這技能一直在原地往下挖；但是實際上，很可能我們根本不需要挖，我們只需要附近繞繞是可以找到山泉的。 但如果沒有全面思考怎麼解決「根源問題」時，我們很可能就會陷在一個框框裡頭出不來了。 常常實務上的衝突不僅是技術問題而已，也未必是技術解可以正確涵蓋的。

以專案而言，有些是可以透過範疇、成本、時間的三角來調整交換，但很多問題同樣是可以透過合約的法律程序、流程的制定或是調整、溝通方式的改變、重組組織架構、過程的品保稽核、不同的評量機制、甚至透過政治或是人際關係的互動來達到。 也因此，要選擇合適的解法，我們必須先要知道「根源問題的緣由為何」，以及「甚麼才是真正要被解決」的。

我們立刻認知的框架

水平思考指的是跳脫框框的思考模式，也就是由廣逐步收斂的一種思考方式。 這其實是很困難的東西，但卻是很值得練習的東西。 畢竟我們都在學校待了十幾二十年，學校教育讓我們專注於追尋框架下的正確答案，但有時候反而我們失去了解決問題的能力，因為現實生活中有時候根本沒有正確答案這東西存在。

那該怎麼提升我們解決問題的能力呢? 我會建議，在面對任何問題時，學習先取得鳥瞰問題的可能性。 不管問題「看起來是甚麼」，它很可能實際上的全貌並不是「那個甚麼」。 不管問題被交付給你時老闆或是客戶怎麼跟你說，不管你直覺覺得有甚麼立刻的技術解，都應該一律先分析大架構的影響，才去思考細微的解法。

 
鳥瞰全貌後對問題的理解

 
分析其他解法，以及跟你原始想像做比對

回到前兩週裝潢房屋的那問題，在看完問題後，如果你立刻開始思考的是怎麼在「目前的限制下」解決問題，那其實你已經被問題的框架先設限了下來。 但實際上，我們應該試著讓自己站在框架外來思考。 客戶提了顯然是強人所難的要求，雖然我可以透過一些方式內部處理掉，但這樣是否真的是對所有人都好的方法? 可能是，也可能不是。 更重要的是為何客戶提出類似這樣無理的要求？ 他是真的所有條件都不能妥協，還是其實有一兩樣是可以妥協的？

可能他兒子要結婚所以想把新房趕快搞定，時間不能讓步，但他其實可以接受你多找些人多加些錢？ 或可能他因為股票大跌突然沒錢裝潢了，但他最終其實願意減少些議定的範疇？ 但同樣有可能他只是無聊順口問了一句心裡並不期待真能做得到的事情？ 但如果你不了解他為何提出，你任何的技術解都有可能只是個短線解，也可能沒抓到重點。

很多人誤以為專案的本質是變動、所以也以為專案管理的本質就是隨波逐流、隨機應變、是沒天沒夜的加班、或是任勞任怨的把所有的要求都加入。 變動是存在的，但實際人生不可能隨著變動完全反應；也因此，管理專案的本質其實是交換。 而主要的交換點，就在如何在範疇、成本、時間的三個邊上達到平衡。 專案的負責人如果不先了解這點，那他必然會為了虛無的目標或是隨著變動的擺佈而犧牲了團隊、當團隊崩解下最後則必然犧牲了客戶/老闆以及自身的利益。 慘烈犧牲卻最後未能有個好成果，這絕對是可惜的狀態。 也因此，與其透過慘烈犧牲來達成目標，好的經理人更應該要思索的是如何提供一個能達到最大利益的「妥協」方案下給其上位的決策者。

世界不是完美，專案不可避免要面對妥協，也因此我們要了解怎麼妥協。

圖片出處: http://www.funnyanimalsite.com/pictures/Thinking.htm