大多數基層的工程師往往對老闆很有意見，如果說專案管理裡面有什麼比 “客戶” 更大的風險，那應該就是老闆了。一個具有絕對決定權的人，對於專案卻不一定有全盤的瞭解，這種角色下的決定當然很容易就出錯。久而久之，老闆似乎就成了專案中最大的不定時炸彈。

但是到底為什麼老闆會做出錯的決定？又是怎麼樣的環境限制了老闆的能力？假如我們相信，大多數的老闆，在當老闆以前還是有幹過一點像樣的事、帶過一些像樣的專案、至少還是有一點能力的，那麼為什麼在老闆的位置上卻反而變成絆腳石呢？先前和一位朋友聊天後，有了以下的心得。

老闆容易天馬行空

我們聊到一位資深、素富聲望的資深 PM，被公司賦予一個任務，“開發下一代的電子商務系統“。下一代，代表沒有參考點，當然也就不是照抄別家網站兜一兜就可以了。這個團隊花了很多時間構思五年到十年後的系統，所用的技術當然也是最新的架構，從這些新東西上試著建築出 “下一代的電子商務系統”。”下一代” 的另一個隱含意義是 – “現在還不能用“，但是人力物力花了下去，公司不可能持續燒錢來支持一個不能用的系統；這裡的問題是，為什麼一個資深的 PM 或是總工程師，會造出一台不會跑的車？

關鍵是在天馬行空。大部份商業環境下，專案往往有許多限制，越到底層限制和責任也就越明確。每一個 PM 或是工程師往越上晉升，除了專案所牽涉的複雜度增加以外，限制也逐步減少。限制減少一方面代表的是空間變大，另一方面也代表風險增加，更糟糕的是，這代表評估專案成功的底線也越來越模糊。

一個”下一代的電子商務系統”，它的評估條件到底是在 “下一代” 還是 “賺錢” ? 它的成功是因為公司的過渡成本低廉還是因為長期支出降低？它能滿足的需求是公司目前的業務還是應付未來的變化？這些根本的問題是專案成功與否的基準線，但是這些基準線卻很可能逐漸的、緩慢的擺到另一頭去，原因是即使有經驗的 PM 或總工程師為自己設下假設性的限制，這些假設都很容易因外界而改變；公司政策的突然轉向、產業的典範轉移，都會讓某些假設顯得荒謬。

那麼老闆的問題又和這種總架構師或大 PM 有什麼相似之處呢？多數老闆都長期在沒有限制的狀態下思考，唯一的限制就是現金流。老闆的成功與否也沒有評估的基準線，除了慘賠的案子以外，老闆幾乎都可以用自己想要的方式來評估成功與否。一個不賺錢的案子可以說是賣進去了下一個更好賣、接不到下一個也可以說累積經驗。沒有一以貫之的評估條件，就很難決定朝向哪個方向走才是對的；先有地平線，才能知道往哪飛才是高。老闆常是別人的地平線，但老闆自己的地平線在哪裡呢？

離現實越遠，越不容易掌握成本

另一個常見的問題，則是來自老闆對專案的突發異想。越到高層自然不會也不該事必躬親，所以對於許多決策的形成過程不瞭解，這是其一；但專案會議既然希望高層列席，當然也是希望他們能提供觀點、看專案是否和他們心中的 “基準線” 相符，這是其二。原本這兩件事都是正常的，但是在這種情形下，很容易變成專案一面倒的妥協，只為了希望贏取高層的支持。事實上，符合高層 “基準線” 並不代表要迎合每一個要求，如果你相信老闆是理智的，那麼其實應該要做的是讓高層瞭解變動的成本為何。專案執行者如果沒有把成本的資訊往上回送，老闆當然就很容易做出錯誤的指示。

老闆如何避免帶領專案時犯錯

• 反求諸己: 假裝自己是低一層的專案管理者，為自己事先套上一些前後一致的(consistent)限制；
• 建立基準線: 避免射了箭才畫靶的心態

老闆如何避免自己提的意見成為專案的風險

• 從下到上: 鼓勵團隊解釋決策過程；
• 吃米要知米價: 確認按照自己意見修改的成本；
• 不要深不可測: 事先、主動的表明自己評估專案的基準，避免下面為了猜測自己的基準線而一味退讓。

優秀的資管人形形色色，但通常都有的特質是:

• 邏輯好, 頭腦清楚;
• 至少有一個專長;
• 溝通能力強;
• 興趣廣泛

如果以武將來說，大約是姜維的水準；拿他跟呂布 PK 一定死，找他跟司馬懿下棋當然也被電好玩的，問題就是姜維既不會跟魏延鬧脾氣、遇到雜魚也可拿刀跟他對幹。所以爭論誰程式寫得好是沒意義的，但是，絕對要能寫水準以上的程式。

問題就是，姜維真的是學校教得出來的嗎？這就是資管教育最根本的問題了。水鏡可以開班授課教出八奇，反正孫子兵法照念，前八名的再趁就業博覽會時介紹給大公司就好了；武將反正就是練兵跟打仗，打了幾年下來還沒死的人自然就是個將軍了。但又要唸兵書又要打仗的學校，到底是拉單槓重要還是唸陣法重要？

可是回過頭來說，一個軍隊也不能只有諸葛亮和關羽吧，不然八陣圖要建的時候會這樣:

孔明: “姜維, 這個八陣圖在這, 照圖施工就對了。”
姜維: “丞相, 請問石頭跟工人要怎麼調配?”
孔明: “有沒有這麼菜啊? 問我咧~”

<跑去找魏將軍>

姜維: “魏大將軍, 這個八陣圖麻煩您支援弟兄幫忙蓋一下…”
魏延: “賽你丞相, 關我屁事, 我們要去健身房鍛鍊啦~”

資管教育是可以教你技術和商業遇在一起時可能會產生什麼問題，教得比較好的老師也可以教學生怎麼解決問題，但實際上，大部份學生都太年輕而沒辦法真的吸收進去。考試當然更沒辦法考出什麼東西來，因為商業的東西終舊要在商業的環境中實戰才能驗證，而不是靠考試或報告。這也是大多數資管教育失敗的主因。

有板友說，美國資管系教育正在減少；我的看法是，美國人因為相信媒體宣傳的 “IT 已死”，認為這類技術工作終究會被外包到國外，所以唸這類科系的美國人大減，這是我和 CMU 資管的系主任 (管理學院副院長) 聊天時他說的。也因為這樣，系上會每年檢討開課跟業界的需求是否符合，儘可能以學生能找到好工作的方向推動。反之，台灣大部份的資管系所和業界的合作卻很少，對基礎能力的要求也不夠，畢業生出去時當然就比較吃虧了。

回到資工資管的問題，既然我都唸過，應該有一點點資格說話吧。人的時間是有限的，你花時間鑽研一項知識，就可能會漏掉或輕視另一個知識。你可以設計出世界上最好的新無線網路協定，但是如果你搞不定電信頻譜執照就是白搭；你可以寫出最棒的網站，但你應該不會有時間天天和金主吃飯開法人說明會。你的擋垃圾信演算法很棒，但是得有人去做無聊的市場調查才知道用戶到底在不在乎。

資管不是管理資工的人，而是管理資訊相關的議題，以及被資訊影響的人。總有一些事情是資工沒有教，但在現實社會中也和技術同樣重要的。資工沒有教是因為這些時間得省下來鑽研更深的技術來維持競爭力，並假設有人會去處理這些事。運氣好，處理的人對技術有概念就很好；運氣不好，整個團隊的競爭力瓶頸就會出現了。

即使我現在還是以寫程式為生，但我很高興有人幫我把市調做好、把事情優先順序整理好、把客戶需求搞清楚、把測試者的時程接好，這樣我可以專注在我做得最好的事情上。不管我做的事有多麼不可取代，沒有其他資源，我仍然是英雄無用武之地。我可以自己幹出一個網站，但要認真跟檯面上的大公司拼，個人是沒有用的。

雖然平心而論我覺得台灣的資管系設太多，但如果已經踏上這條路並打算走下去，我建議還是:

1. 要有一項專長, 不管是寫程式還是財務;
2. 溝通能力要強;
3. 學習力要強, 你會一直需要學新東西的.

《原發表於 PTT 八卦板》

相關閱讀: 《資訊和管理的交界 – 資管的心得分享》

前幾天在某板發文結果被酸打高空跟嘴炮，所以還是來自己的 blog 說的好。

很多研發人員和上司最大的衝突往往是專案的優先順序，研發人員認為 A 比較重要，上司或是老闆認為 B 比較重要。因為認知不一樣，所以雙方的磨擦和衝突就越來越多。一個很容易讓研發人員抓狂的老板語錄如下：

老闆：「那個 A 專案隨便做一下，可以交差(驗收)就好了。」

研發這時候往往會覺得老闆是豬頭，如果可以隨便做，客戶為什麼不自己隨便做就好？幹麻花這麼多錢包給我們？如果可以隨便做，那當初估出來的時程難道是估心酸的？

之所以雙方會有這麼不同的看法，主因還是思考邏輯的不同；想要說服老闆愛你的專案、或是事先知道老闆會不會愛你的專案，就要知道老闆是怎麼想的。
Continue reading →

記得在學校畢業前有一門必修課，叫 Digital Transformation，主要是利用個案來探討資訊科技對於企業甚至政府的影響：在這些個案中，主角都因為科技的變化而遭逢了一些問題，有的是傳統產業想要升級，有的則是國家的港口想要轉型，在這些個案中，對於資管的學生來說，科技，幾乎就是唯一的解答。所以甚至會看到有些不太認真的組，提出: “該公司應採用 Java 相關的 Web 技術來設計系統” 給 1995 的公司。的確，有些公司的問題，確實是只要等待科技稍微進步一點 (例如，BlackBerry 機的出現)，就會比較容易解決，但是實際上，管理上的問題並沒有這麼簡單，這也是同樣的技術，用在不同的公司，會有完全不同下場的主因。

前陣子聽到主管討論到把公司的每一個網站元件都切成獨立元件的問題。在工程師的完美世界裡面 (或是有一些 SOA 的宣傳文件裡面)，每一個 Service 都應該可以獨立運行，彼此之間只要界定好介面訊息，撰寫和維護各元件的工作應該就可以切開給不同的人 (或組) 負責；”負責” 代表權和責，某人要為它負責，當然需要確保這部份元件運作正常；既然他要負責，而且我們已經有完美的介面，自然其他人也應該尊重這個封裝，不應該去動他的程式碼。

幾乎所有老經驗的程式設計師都會同意，loosely coupled 和封裝可以減少很多問題，只要…我們不考慮效率的問題。
Continue reading →