Project又delay，怎麼辦？
一大team人做project，delay之事十常八九。每當老闆發現專案出了亂子，最常見的解決辦法是人海戰術，進度遲了便投放更多人手，希望把時間追回來。可惜成功追回進度的例子萬中無一，沒有更加落後已屬萬幸。有些無良兼無知的老闆，漠視現實不斷催迫團隊加班趕工，倒頭來把最能幹的下屬迫走，讓專案完工更加遙遙無期。市面上專案管理書藉多如繁星，坊間更有不少證書課程，質素參差讓人無從入手。我為大家介紹這本The Mythical Man-Month，跟據非正式統計，美國高科技公司一眾CEO中，十個有九個半均看過此書，可謂專案管理中的經典。
專案管理有一詞謂之「人月」（man-month），用來計算專案所需的資源。若六個人要做十個月，那麼專案便需要六十「人月」。「人月」的計算方法有一大缺陷，就是假定了人與月是可以隨意轉換的單位。如果六個人要做十個月，那麼十個人只要六個月就完成。按照同樣道理，一個女人懷胎九個月生一個小孩，難道九個女人生一個小孩只需一個月嗎？在傳統藍領行業，每個工人的勞動力差別不大，可以隨意加減互換。創業產業是知識型經濟，生產力來自腦袋中的智識。由於每個人所知不同，人與人不能任意取代，除非發明複製腦袋的機器。追加多些人手進入團隊，新人要花一定的時間學習，而團隊因人數增加，更要付出額多的溝通，間接增加成本。所以，多加一人，實際只有少於一人的生產力。團隊太大甚至會物極必反，總生產力不升反跌。
開發軟件是無中生有的工作，將腦袋中抽像的慨念，具體化實現成可用的產品。從思想轉換成軟件的過程中，無可避免會有些邏輯錯誤。而不同人負責的部件要組合時，因溝通不協調也會引致理解錯誤。科技進步可以減少無謂的錯誤，增加工作效率，換來開發更複雜的軟件，最終人為因素產生的錯誤數目維持不變。書中詳細講解控制人為因素的不同方法，在四十年前提出時是新思維，今天已是常識，只是世上仍有很多人無視常識。一個專案若要成功，得有一個總設計師：他是專案的靈魂，確保每部份的一致性，讓整個團隊寫出來的軟件恍如出自一人之手。有效的分工與合作是專案成敗的關鍵，促進團隊之間的溝通，減少團隊資訊負荷，讓他們專心工作。更重要是挽留和培養人材，在軟件界有個共識，天材與凡人的生產力相差十倍，十個臭皮匠，勝不過一個諸葛亮。
此書75年初版，95年出新版，作者是IBM OS/360系統的經理，他總結團隊多達數千人、史上最大軟件專案的經驗，寫出這部軟件界的管理天書。當年的電腦巨如一台貨車，現今的電腦小得可以放進口袋中，硬件進步千里，但開發軟件的精髓從沒有變，專案的最大障礙始終是人為因素。書中列舉的例子當然早已過時，但貫穿整本書的管理思想，卻是恆常不變的真理。相信大家還記Nokia曾經稱霸電話的年代，早於iPhone面世前兩年，Nokia已經著手開發新一代智能電話系統，開發進度一直未如理想，只因全無對手、管理層也不太著緊，直到07年iPhone橫空出世，Nokia才驚覺要急起直追，於是大幅增加專案人手，更邀請Intel加入共同開發，結果「人月」的詛咒應驗，MeeGo系統在三年後才勉強推出市場，電話早己被iOS和Andriod瓜分天下。而Nokia錯失搶佔市場的黃金時機，從此一代電話王國踏上末路，最後賣盤給微軟結業離場。
編寫軟件可以說是第一代的創意產業，在今天創意產業作為經濟發展的重要支柱，電腦全面進佔我們的工作和生活，只要是必需要使用電腦的專案，不論是工業設計還是多媒體製作，都可以實踐和應用此書中的道理。從我在科技公司當夾心中層的實戰經驗，更加肯定書中理論經得起時間考驗。此書是知識型經濟的管理階層，或有志晉進成為管理階層的打工仔的必讀之選。
後記：Project乃洋文，大陸譯作項目，台灣譯作專案，香港或從日文譯作企画，更多時候直接用英文。我認為台譯較傳神達意，故本文從之。
作者簡介： Frederick P. Brooks, Jr. (1931-) 史上第一台商業汎用大型電腦IBM System/360之父，電腦界最高榮譽圖靈獎（Turing Award）的得獎人。北卡羅萊納大學電腦 系創辨人兼系主任。他是電腦作業係統設計的權威，及後任職美國政府國家科學委員會和國防科學委員會。
原文刊於《閱刊》七月號。
