〔推薦序一〕
大型複雜系統的創新管理經驗與智慧
李仁芳
台灣不缺創新人才，供給嚴重不足的是創新管理人才。
我們有世界級的電影導演，但優秀的製作人(Producer)鳳毛麟角。
我們有個人擁有上百個專利的科技怪傑，但很難找到能經營企業研究中心(Corporate Lab)的技術長。
我們也有能寫優美程式的駭客級好手，但能管理一個大型複雜軟體系統開發的專案管理者則遍尋不著。
科技的創新與美學的創新，半靠天份，半靠後天的專注與努力﹔
但是創新專案的管理，特別是大型複雜系統創新的管理，其綜覽全局的眼光與對系統產品概念的整體性(Conceptual integrity)的掌控，則非仰賴蓄積的經驗厚度不可。
這種對大型複雜系統創新的管理經驗紋路與智慧奧義非常內隱，很少被彰顯出來。
微軟公司近年來非常重視新產品開發專案開發完成後的「專案稽核」(Project Audit)文件，強制要求未完成此文件的專案領導人不得結案交差。比爾．蓋茲的用意即在藉這些文件，讓複雜軟體開發的管理經驗得以在微軟內部流通，增益後來的微軟產品創新管理成效。
System/360與OS/360是人類軟體工程技術開發史上非常重要的里程碑，不論在技術成就或商業績效上，都是使IBM公司成為「大藍」(The Big Blue)的關鍵產品。
本書的作者Frederick P. Brooks, Jr.與另一要角Bob Evans（TSMC張忠謀先生好友，曾任行政院孫前院長的科技顧問及世界先進公司總經理）當年即為IBM此大型複雜系統專案的兩位主導人。
他們為System/360規劃了一系列不同的機型：Model 20、Model 30、Model 40、Model 50、Model 60、Model 62、Model 67……等等。
OS/360的創新開發，尖峰時期曾超過1,000人為之工作－－程式設計師、文件編寫員、機器操作員、助理、秘書、經理、支援小組等。從1963到1966年間，大約有5,000個人年（man-year）的工作量是投入到OS/360系統的設計、建構和文件撰寫工作。
雖然從效能最初階、最便宜到效能最佳、最貴多重等級都有，但這些機型的外觀系統都一樣，操作方式也彼此相容，只是內部的實作方式按等級做了調整。客戶可以視需要與預算來選擇適當的機型，而且拜單一架構之賜，使用者介面不需改變。因此客戶未來因業務成長想要升級時，門檻也很低——這是當時System/360一個很大的軟體工程技術成就與商業賣點。
Brooks的《人月神話》是記述人類工程史上一項里程碑式的大型複雜軟體系統開發經驗的「創新管理」經典之作。
書中揭示了許多大型複雜系統創新管理的經驗紋路與智慧奧義，是為有志於追求創新專案之管理專業人士參考。
創新管理是一極具「領域專屬」(Domain-Specific)特質的知識與技能。
管理大型複雜軟體專案的開發，與管理其他任何大型的專案(登月計畫、隱形轟炸機開發、局端交換機系統開發……)相比，類似的地方固然很多－－比大部分程式設計師所相信的還要多。
然而，管理大型複雜軟體專案的開發，與其他領域大型專案不同的地方也很多－－比大部分的專案經理所預料的還要多。
程式的創作必須呈現得非常完美，就像哈利波特要施展魔法一樣，咒文中的一個字或一個停頓，只要稍有差池，魔法就施不出來。
人類並不習慣做到這麼完美，人類的活動也很少需要做到這麼完美－－而調適自我及團隊成員習於追求完美是軟體工程創新管理最困難的部分。
這種極致追求完美的大型複雜系統創新管理經驗，是人類智慧寶藏中極為重要、極為寶貴的一個環節，值得看重創新管理的人士仔細咀嚼。
Brooks以內行人的經驗深度與形象化深入淺出的語言，對這段智慧寶藏做出了貢獻。
他所稱的：
‧ （新系統）概念整體性（Conceptual Integrity）；
‧ 外科手術團隊；
約束對（軟體工程開發）藝術而言是件好事（Discipline is good for art）；
形式就是解放（Form is liberating）；
架構（architecture）的外部規格制定出來，事實上反而會增加實作小組創意風格，而非貶損；
架構設計師和實作人員越早進行持續性、充分、仔細而和諧的溝通，可以使架構設計師具有良好的成本概念，而實作人員也會對設計更有信心，不會模糊了各自的分工；
巴別塔的失敗不是因為缺乏明確的目標與充沛的資源與技術，而是因為溝通（communication）以及隨之而來的組織（organization）問題！
這些創新管理的深刻經驗與見解，不只對大型軟體開發的管理十分寶貴，對其他領域的複雜系統之創新管理，也極具參考價值。像Brooks具備這種經驗厚度的人，寫出《人月神話》這樣的書，是人類知能累積過程中極大的福氣。社會應多鼓勵有這樣成就的人士多寫出類似的著作來。
（本文作者為政治大學科技管理研究所教授兼所長）
實在是令我感到驚訝與喜悅，二十年來《人月神話》一直如此受到歡迎，出版了超過25萬本。人們常常問我，當初在1975年所提出的理念與建議，有哪些仍然是為我所堅持的，有哪些則是已經改變，以及是如何改變的。雖然我有時會在演講中回應這些問題，但其實很早就想把它寫下來了。
任職於Addison-Wesley公司的出版夥伴Peter Gordon，他從1980年起就跟我一起共事，很有耐心、對我幫助很大；他提議來出個紀念版，我們決定不重新修訂原文，一字不改地再版（除非是一些小的錯誤改正），然後以更現代的想法來擴增其內容。
第16章是轉載自1986年在IFIPS發表的文章〈沒有銀彈：軟體工程的本質性與附屬性工作〉，這篇文章醞釀自我所主持的一項國防科學委員會對軍用軟體研究的經驗，參與那項研究的工作夥伴，也就是我們的執行祕書Robert L. Patrick，是他促使我重新接觸實務上的大型軟體專案，這份經驗相當珍貴。這篇文章在1987年曾經轉載於IEEE《Computer》雜誌上，因而使這篇文章得以廣為流傳。
事實證明〈沒有銀彈〉相當具爭議性，它預測十年內不會有任何軟體開發的技術能夠單獨帶給軟體生產力一個數量級的提升，這十年還有一年就要期滿了，看來我的預言應該是會應驗。在文獻上，〈沒有銀彈〉已經比《人月神話》引發了更多熱烈的討論，所以，第17章是針對一些出現過的評論所做的註解，並且更新了在1986年所提出的那些理念。
在為《人月神話》的回顧與更新做準備的同時，我突然想到，當年所做的論斷有多少引發了爭論、有多少通過了驗證、有多少已因軟體工程上持續的研究與經驗而證明是錯誤的呢？剝除掉原來所支持的理由與資料，將這些論斷做一個赤裸裸的分類，現在，已證明了這麼做對我是有所助益的，期望這些不加任何掩飾的陳述能夠鼓勵大家藉由評論與事實來對這些論斷加以驗證、舉出反證、更新、或粹煉，而這些綱要，我放在第18章。
第19章是屬於最新資訊的短文，先跟讀者聲明，這一章所談到的最新評論並不像初版書中的評論都經過了實務經驗的確認，我個人已經脫離業界，並在大學裡教了好一陣子書，所接觸到的都是小案子，不再是大型專案，自1986年以來，我只教授軟體工程的課程，並沒有進行相關的研究工作，我所研究的部分僅限於虛擬環境的領域及其應用方面。
在為這本書的回顧所做的準備過程中，我曾經向一些仍在軟體工程界工作的朋友們請教一些屬於當代的觀點，他們很樂意地分享這些觀點，並在文稿上提出創見性的評語，以及對我的再教育，這份熱心是值得讚揚的，這方面讓我受惠的有Barry Boehm、Ken Brooks、Dick Case、James Coggins、Tom DeMarco、Jim McCarthy、David Parnas、Earl Wheeler和Edward Yourdon。而新章節在技術面的製作則得力於Fay Ward高水準的經營。
感謝我在國防科學委員會軍用軟體專案小組的同事Gordon Bell、Bruce Buchanan、Rick Hayes-Roth，特別是David Parnas，他們提供了深入的見解與激發創意的構想，而第16章的那篇文章在技術面的製作則是得力於Rebekah Bierly。因分析軟體問題而引出本質性（essence）與附屬性（accident）工作的分類，靈感是得自於Nancy Greenwood Brooks，她在一篇談鈴木小提琴教學的文章中使用這種分析方式。
按照Addison-Wesley的出版慣例，並不允許我在這篇序言中向1975年初版的一些關鍵人物致謝，但是有兩個人的貢獻是應當要提出來的：Norman Stanton，當時的執行編輯；以及Herbert Boes，當時的美術指導。這本書的典雅風格是由Boes一手精心創造出來的，其中有一位審稿人還特別讚揚：「寬闊的書頁邊緣，〔與〕富涵創造力的字體運用和版面配置」，更重要的，就是他提出了每一章都用一幅圖做為開場的重大建議（當時，我手上只有焦油坑和Reims大教堂的圖），為了找這些圖片還額外多花了我一年的時間，但我永遠感激他所提出的這個構想。
Soli Deo gloria── 感謝老天。
北卡羅萊納大學Chapel Hill分校F. P. B., Jr. 1995年3月
共 
