破除資訊專案管理的迷思

人月神話 　 rederick P. Brooks, Jr./著，錢一一/譯 　 經濟新潮社出版 　售價：480元

這大概是近年來所看過最好的一本討論軟體專案管理書籍，32 年前的經驗至今竟然歷久彌新，在變動不止的軟體科技上，果然有可抽象、萃取的智慧。

本書的一段開場白：「史前時期最駭人的景象，莫過於一群巨獸在焦油坑裡做垂死前的掙扎。不妨閉上眼睛想像一下，你看到了一群恐龍、長毛象、劍齒虎正在奮力掙脫焦油的束縛，但越掙扎，焦油就纏得越緊，就算牠再強壯，再厲害，最後，都難逃滅頂的命運。過去十年間，大型系統的軟體開發工作就像是掉進了焦油坑裡…」。從事資訊工作的你我，是否也踩進了焦油坑呢？

前車之鑑
IT 專案管理一直是讓人頭大的事情，因為至今它仍不成熟，仍在手工業階段蹣跚走向工業化。雖 CMMI、Agile、RUP等理論與架構盛行，PMP課程充斥，但資訊專案失敗及不滿意的比例，仍大過成功與滿意的比例。

就筆者所接觸的專案，不管以顧問身份參與，或是作為系統開發的一員，其成本大自數億，小至自己獨立完成。不管領域、規模與人數，專案進行其間，團隊瀰漫的不滿與挫折情緒，往往多過本書作者描繪軟體開發所帶來的創作、成長與玩魔法的樂趣，絕大部分是在第一章所言的苦難中渡過。

早在1974年Brooks博士把他帶領建置IBM System/360、OS/360的經驗集結成冊，撰寫這本「人月神話」。至今，它的內容依然讓我受益良多。自己在IT領域裡，學習、實作了將近20年，最大的感嘆莫過於：唯一不變的就是「變」。筆者一直覺得掌握不變的、較為抽象、形而上的觀念，其重要性遠高於埋沒在繁雜變動的技術中。而此本書就是討論這類議題的好書，它敘說著IT專案管理上的誤謬。

越早開始的，越晚結束
在筆者己身的經驗中，IT 專案的起始需要細細琢磨Who、What、Which、When、How：
Who（有沒有夠專業的團隊）：這是成功與否的絕對關鍵因素，沒有正確的人，其他四個W都是瞎掰的。

What（需求是否清晰？系統主架構是否明確）：唯有正確的方向，才能做對的事情，否則只有嘆將帥無能，累死三軍。

Which（什麼樣的技術、軟硬體產品、開發方法論是適合的）：工欲善其事，必先利其器，如此才能把事情做對。

When（什麼是合理的時程與進度）：品質、功能、時程、成本是四個互相牽扯制肘的面向，而時程最難預估與掌控。

How（如何按部就班地實踐）：細節是成功的關鍵，要能有效地施行、監控與評估。

科技始終依靠人性
一直覺得資訊專案管理是一門藝術，它不太容易標準化或複製成功案例。資訊專案太倚賴高素質的人一起團隊合作，而與人相處本身就是一種藝術，要學有專精的人一起集結創意，更是藝術中的精品。

在這本書中，作者條列了IT專案的特徵、成功者須具備的條件，及失敗者常誤入的陷阱，但並沒有Step by Step的流程，可能軟體開發的本質，就是沒有放諸四海皆準的流程，畢竟功能需求、使用技術、人力配置、經費成本、組織文化等面向差異太大，因此需要管理者小心翼翼、步步為營地，關注呵護一個系統的成長。

這其實是IT經理人應該深思的，就筆者廣泛接觸的經理人們，為數不少的人都還在等待書中所懷疑的銀彈，癡心妄想地以為花點時間學一套蓋世神功，或覓得神兵利器，陷在泥淖的系統開發，就可以迎刃而解。

一些無心的專業經理人擁有甚囂塵上的PMP，朗朗上口CMMI的枝節，但未關注團隊人心，以致溝通不良。我無意貶抑PMP、CMMI、Agile等學理的重要性，它們非常重要，或許，可視為現今資訊專案管理的基本知識。有中心思想，才有進步的依據。

但我想強調的是：IT是活的，落於紙上的都是死的。「擱淺的船就是燈塔」，死掉的理論，只能避免我們不要擱淺在同一塊礁石上。但無心不經意地駕駛，終究會擱淺在另一塊礁石上。

部份IT經理人不具備資訊科技的基本知識，因為日新月異的技術，早迥異於他在學校所學的。又磨光了初入行的熱忱才升上經理階級，沒時間也沒興趣吸收資訊常識。對於使用者的需求應用僅略知一二，整日忙著把酒言歡，與關鍵關係人建立人際關係。奢言要求他對系統主架構的認知與重視，更由於缺乏眼界與肩膀而盲目答應，讓團隊失去了方向。

同時，在人月迷思中，貶抑了專業的價值，以為人多就可辦事，花錢就可解決問題，而不思如何建構具水準的團隊。想要當個入門的IT經理人，或許需要先讀通本書，了解揉合科技與人性的困難。下頁

《作者簡介》胡百敬
現任職恆逸資訊教育訓練處資深講師，聯合報系、睿智資訊與臺灣微軟技術顧問。著有《SQL Server 商業智慧聖經》等書，並為專欄作家。資訊專案管理的重點
30多年前，Brooks博士在本書中所提及的概念，至今仍是IT開發的圭臬，由於己身知識與經驗不足，我試著表列自認為的重點如下：
●軟體系統大概是人類創作中最錯綜複雜的東西(從組成各部份的類型數量來看)。軟體開發的問題源自於本質上的複雜性，以及複雜性隨著軟體規模呈非線性成長。
●人月是個危險並很容易就遭到誤解的迷思，因為他假設人力和工時是可以互換的。
●在一個時程已經落後的軟體專案中增加人手，只會使它更落後。
●同樣資歷下，優秀程式設計師的生產力要比差勁的好上十倍。
●專案如果要成功，人的品質以及人的組織與管理，遠遠比他們所運用的工具或技術要來得重要。
●設計系統的時候，最重要的是概念整體性。
●太多的失敗都源自於自始至終都搞不清楚要做的是什麼。
●專案經理最好的朋友，就是整天和他唱反調的、獨立的產品測試小組。
●每個子專案（Subproject）都必須具備兩種領導角色，也就是管理者和技術總監或架構設計師，兩種角色的職掌不同，需要的天份也不同。
●在功能、效率、程式大小、成本和時程之間總是衝突的情況下，架構設計師需要綜觀全局，站在維護使用者利益的角度上做出取捨。
●為什麼專案會落後一年，因為每次落後一天。每天一點點的延誤，讓人不覺痛癢，很難預防也很難挽救。
●軟體專案越到後期，進展越慢。
●第一次出爐的系統絕少是有用的，把必然的一次失敗納入到正式計劃中，製作測試系統（如現今的Alpha、Beta 版本）。
●每修正一個錯誤之後，都應該將之前所有的測試案例拿來進行回歸測試。
●交付出去的程式都應附帶一小組測試案例，包含合法的輸入、罕見的輸入和明顯不合法的輸入。
●系統除錯與組件除錯相比，所耗費的時間將超乎你的預期，須具備一套條理分明、規劃良好的測試方案。

在書中，Brooks博士根據己身的經驗，或是旁徵博引各大師的研究著述，娓娓敘說著箇中原委。讀完此書，讓我有一個深深的感受，資訊專案的開發過程中，局部的錯誤失敗是必然的，並不可怕。可怕的是不能從失敗錯誤中學習，一再犯同樣的錯誤導致全面性的失敗。

書中在第八章開頭引用了一句話：「經驗的代價是昂貴的，但愚人就只能從經驗中學習(Experience is a dear teacher, but fools will learn at no other)。」但更為可惜的是，太多的專案經理由於過於忙碌，沒有時間也缺乏停下來深思的習慣，往往付出了慘痛的代價，但經由反省而學到的經驗卻少之又少。

做對的事，自然累積成功
若你從事的是資訊相關工作，不管是經理人，架構或需求的分析設計人員，開發、除錯、維護人員等，或許都該翻翻這本書，了解用來安身立命的工作之特質。書中描述了許多應有的態度與方式。從仿效開始，強迫自己養成好習慣，久而久之，自發性地做對的事情，自然會累積成功。

由於本書的各章節有其獨立的討論議題，建議你先概略瀏覽一下全書，在心中對軟體專案的特質有個概念，爾後在專案進行中，隨著情境的變遷，再回來溫習一下，相信會更有所得。另外，它的第十八章是個總結，若你需要提綱挈領，可以閱讀此章。

書中有一個特點就是每章開頭都附有貼切的短文與圖案，饒富機智與趣味。當筆者第一次看完這本書後，立刻就將所有章節開頭的短文都敲到網誌上。偶爾悵然若失時，讓我有機會反省一下是否又陷入了什麼樣的迷思。

期待這一本好書能讓你在資訊海洋航行時，摸索出正確的航向。