專案管理是一種生活思維

本文原始發於 2007年10月02日

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

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



(上圖，IE的警語。 除非使用者自己去選擇「允許執行」，否則整個網站的內容都會被封鎖。 )

懂電腦的使用者當然對此沒問題，但是因為介紹光碟也可能會給一些對電腦不怎麼精通的人，因此這樣的封鎖很可能會讓他們不知所措。 於是，這位新來的同事，花了很多時間在研究怎麼讓系統不要出現這樣的警告資訊。 但是，耗費了幾天始終都不成功。

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

我們立刻認知的框架

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

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

鳥瞰全貌後對問題的理解
 

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

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

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

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

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