每個領域都有幾本歷久彌新的經典作品，例如想學投資， Malkiel 的《漫步華爾街》經典不敗數十年，如果是對策略有興趣，Nalebuff & Brandenburger 合著的《競合策略》就是必讀大作，若談到專案管理，以實務經驗為基礎總結而成的這本《人月神話 》受到許多資深前輩的推崇。
近代由於資訊科技的蓬勃發展， Project Manager 成為一個熱門的工作選擇，專門討論軟體專案管理的文章更是爆炸性的增加，科技進步日行千里，1975 年出版的《人月神話》有什麼獨特之處，讓跨世代的專案管理者一再推薦呢？
寫在前面:大型專案就是大型投資
真正的大型專案其實很稀有 (以書中的作業系統開發專案為例，該專案規模大於 5,000 個人年) ，絕大多數的專案管理師與科技傳教士都沒有這種經歷與機會，而使得不少傳授內容其實來自憑空想像。
大型專案就是大型投資，專案經理人一定要謹記在心。大型專案如果失敗要承擔的損失很大，正由於複雜度很高又很稀有，站在前人的肩膀上吸收經驗化為己用，對於專案管理人員以及背後的企業來說極為重要，即使經過多年，談專案管理的書籍也少有這種規模的專案第一手經驗可供借鏡，《人月神話》就這樣不停地被賦予新的時代意義流傳下來。
《人月神話》全書可為三大部分，分別涉及專案管理的基本要素、軟體工程的特殊專案議題以及專案管理組織設計，以下我們逐一討論。
《人月神話》第一部:專案管理的基本規劃要素
雖然近代專案管理風格丕變，大多數的簡易專案，其實只要列出基本的事項清單，做好各團隊之間的資訊同步以及充分溝通就可以了。
對於更複雜的專案來說，《人月神話》的第一部分列出了專案規劃的基本要素可供借鏡：
-
專案目標
專案目標的說明需要有明確可測量的完成/成功/失敗的定義。
「定義」本身是否清楚是一個很重要的細節，文字和語言經常不夠精確，而很多無形的目標又常常定義不清，一個有效的方式是給予一個定義多個同義描述，藉由比較等價的文字描述來消除解釋上的歧異。
-
執行規格與產出
規格和產出依據專案不同，可能是 5 x 5 大小的雕花石板或是一個有 30 個 input options 能承載 1 萬 TPS 的 API 或是一份 20 – 50 頁包括 6 個規定章節的檢驗報告。
好的規格描述與專案目標緊密呼應，而好的規格細節則與測試案例的設計高度相關。
-
預算評估
專案內的所有工作項目與需求都是成本，預算分析不可能也不應該獨立於要達成的目標與規格之外。
好的預算清單，它的面向應該是多元的，不應該只有錢這麼單調，時間也是影響預算的一個重要因素。整體的 man-days 是時間考量的一部分，具體會佔用哪些人的多少精力也是一個因素，高手與庸手的時間並不等價。
-
專案時程評估
所有專案都逃不了回答客戶、主管這個問題：專案要多久才能做完？
專案時程經常與目標、預算牽扯不清，當然所有人的目標都是時間越短越好、品質越高越好而且成本越低越好，但顯然很多時候這些需求彼此之間互相衝突，那怕是一小部分衝突都很容易延誤整體時程。
一個對於化繁為簡很有幫助的技巧是制定合理的專案里程碑，這些里程碑也跟目標一樣是需要明確定義並且可測量的，里程碑的使用可以從宏觀的角度執行 PERT / Critical Path 或是用甘特圖式的時程分析來視覺化。
《人月神話》第二部:軟體工程的特殊專案管理議題
《人月神話》的第二部分，提出了幾個特殊的軟體工程問題，溫掌櫃的經驗是它們常在軟體開發專案中被忽略，提高了失敗風險：
-
重設計風險
軟體設計跟寫作有一些相似之處，例如描述一個恐怖小說的場景可能有一千種表達方式，直到寫出來以前很難評斷哪一種比較好，寫程式也是一樣。
軟體工程還有一個額外的挑戰，儘管有多個方式可以達到需求，不同方式之間的隱性技術取捨、可兼容性、可維護性與成本可能截然不同，這導致某些時候修改設計，甚至修改需求可能對整個專案最有利。
客戶的需求也可能隨著專案演進而改變，有時候一個概念上的小更動將違反直覺地造成專案極大的負面影響。在專案計畫中留下「一頁空白」的可能性是有價值的，因為從來沒有任何專案計畫一開始就能完美無缺。
-
評估失誤與校正
對於軟體工程師來說，針對從未執行過的需求進行工時、風險的評估永遠是一項難題。
除了前導的研究時間外，練習、測試並思考不同的執行邏輯都需要足夠的時間醞釀創意，在一個大專案裡，可能有成千上萬個小項目隱藏其中，當一部分預測失準時 (例如完成所需的實際時間比預期更長，也可能是某些功能達不到)，就會對整個專案造成「長鞭效應」，越是複雜的專案最終失準的情況越是被放大。
為了避免最後一刻才開天窗，定期針對整個時程波動進行重新檢討常常是必須的手段，而專案經理人則必須承擔計畫變更帶來的壓力並展現高超的溝通協調技巧化解衝突，尤其是在事情往糟糕的方向前進時。
-
人員流動
工程師的程式碼產出與邏輯巧思有很高的獨佔性，即使一群人做好各種協同工作機制，也比不上全部由一個熟練老手製作來得完整。在時間跨度長達數月甚至數年的專案裡面，人員的更動是一項很大的成本與不安定因素。
一旦有人從專案裡退出，就必須多花時間找人、訓練、交接、熟悉並接軌進度，這些都是「本來不包括在專案裡的工作項目」，毫無疑問地將延遲專案的進度，而工作品質也會隨著人員不同而浮動。
由於每個人的能力、經驗與評估標準都不一樣，隨著新人加入，原有的計畫像是可行性、使用工具或設計邏輯甚至時程的假設可能都不再有效，若是新加入的人員又再次流動 (在今日的職場生態裡越來越常見! ) ，專案領導人真不知該如何是好？
大型專案中可能動輒數十、上百甚至更多成員，專案領導人不可能一一掌握每個人的情況，因此需要搭配專案組織的切割與分工，依賴各小組的主管來管理這些風險，並將風險定期評估列為正式的工作項目，這在今日的軟體專案管理中已經越來越不可避免。
-
非核心工作的干擾
軟體工程師 (尤其是大神) 除了寫程式之外還有很多週邊工作，例如與其他團隊討論技術問題，又例如擔任救火隊四處排難解疑等等，這些調查與開會也會佔去很多時間，更不用說工程師最不擅長卻難以避免的文件撰寫了。
因為非核心工作很可能會降低工程師的生產力，因此許多團隊都有設置專案經理或直接由團隊主管/系統分析師擔任對外窗口，形成一道寶貴開發資源的防火牆，用來過濾多餘或不必要的干擾。
無論如何，把這些延伸的非核心工作考慮進來，我們才能得到一個比較有效的基本時程單位，許多技術團隊現在都採取直接將 5-6 個小時的工作量歸為一個人天或一個點數而不是 8 個小時，提供一些額外的緩衝。
-
人月神話
業務與客戶對程式設計團隊最常有的誤解與爭辯其中之一就是：我們是如何決定一個 man-day 單位的？ 雖然表定一天工作 8 小時，實務上 man-day 的單位幾乎不可能用 8 小時的工作量來代表一天。
這其實有充分的原因，軟體設計是腦力創意工作，不像某些重複性高的工作一樣可以簡單的將單位工作量線性外推以得到長期生產力，軟體工程涉及大量的發想、整合、測試與除錯，一個 100 人天的工作並不等於 100 個人做 1 天的加總，而且在真的做出來以前也難以驗證或保證其成果。
再加上前面說到的人員流動與非核心工作原因，當一個專案落後 30 個人天進度的時候，給開發團隊增加一個可使用一個月的人力並不會真的幫助到專案進度，反而有很高的機會讓專案更加落後。
這個狀況雖然對於初次接觸的人來說很難接受，但其實我們生活中充斥著類似性質的現象：一個孕婦需要懷胎 10 月產子，找來兩個孕婦並無法讓懷胎時間縮短成 5 個月。
「人月神話」定理簡要地總結了這個觀察：在一個已經落後時程的軟體專案中增加人手，只會讓它更加落後。
-
文件管理
文件是現代軟體工程/產品管理中不可或缺的一環，常見文件的類型包括開發需求說明書 (Statement of Requirement)、使用者手冊 (User Guide)、技術參考手冊 (Technical Reference)、執行/佈署手冊 (Implementation/Deployment Guide)、版本管理手冊 (Version Control Reference) 等等，依據專案的類型可能會有不同的文件組合。
實務上有幾個跟文件相關的議題可以思考一下：
-
產品手冊/使用手冊應該由產品經理或是主要工程師撰寫？
-
程式碼邏輯說明應該以備註形式融合在代碼中或是獨立維護一套文件？
-
System Processing 的邏輯說明應該要放在哪一個文件裡面？
-
流程圖的必要性、顆粒度與使用時機
準備及維護一套好的文件所耗費的時間心力經常超乎預期，但對於一個將長期營運的系統來說，投資時間在這方面絕對會有所回報。
-
系統測試
系統測試是軟體產品開發過程及上線之前一道重要的工序，旨在確保最低可行產品的運作正常並且預防上線後才檢查到無法立刻修復的問題。
有些團隊會採用測試驅動開發 (TDD) 的作法，先設計好測試再回頭開發邏輯，另一些例子則是在寫功能代碼之前利用 Dummy Component ，例如快速製作一個空殼 API 僅能回傳固定但合格的資料以供其他系統提早試用，以便快速製作原型 (Prototype) 。
基本的測試可以從是否會產生系統報錯 (合格/不合格) 以及發生的頻率 (常見/罕見) 來細分：
-
常見-合格案例
-
罕見-合格案例
-
常見-不合格案例
-
罕見-不合格案例
測試內容除了工程角度的輸入輸出、資料格式之外，也包含使用者角度的介面操作等等，由於光是收集測試案例的過程可能就會花上不少功夫，因此一定要留下足夠的時間給測試，當專案緊急時，測試工作就像是升學主義下的國高中家政課或美術課一樣，是會被優先犧牲的項目，但是讓一個複雜的系統未經完整測試就上線的風險很高，因為幾乎沒有一開始全部都做對的系統。
出乎許多人意料之外的是，儘管產品改版的幅度不大，在相依系統中進行全面測試花掉的時間卻會隨著改版演進大幅增加。這是個實務上的大麻煩，往往需要取捨。
理想情況下，對於每一次改版都應該進行 Regression Test ，例如版本一擁有 10 個功能，平均一個功能測 30 個案例，在版本二中新增了 5 個功能變成 15 個功能，Regression Test 變成要計算 10*30 + 5*30 + 10*5*30 個案例。
有些經驗老道的主管會指出 Regression Test 雖然成本很高但是很值得考慮，因為軟體系統的天性就是當你改動了一些預期要修復的問題，卻意外的弄壞了一些本來沒問題的東西。
《人月神話》第三部:專案組織設計與分工
《人月神話》的最後一個部分主要涉及專案的組織設計與分工。
今天見到的大型軟體系統開發「執行」組織通常有很明確的以團隊為單位的前後台區分，前台是面對團隊外部的人員，像是團隊主管或是產品/專案經理，後台是團隊內部人員，像是測試員或工程師。
但在軟體系統「設計」方面，有時候分工就不夠明確，關鍵的問題像是：誰應該對於用戶的需求擁有最終詮釋權？
-
區分需求與技術的負責人
這個問題在一個大型專案組織裡面是很微妙的，不一定有很好的答案，但是在組織設計上可以用點巧思來減少這類問題，例如將歸納需求架構的工作 (客戶需求) 與規劃系統面 (系統工程) 的工作分開給不同團隊。
需求團隊擁有對用戶商業需求的最終解釋權力，而工程團隊則對於自己使用的技術內容與執行方法有主導權，將負責區域劃分清楚後，雙方主要的互動內容就會跟著明確：哪些需求在技術上太過昂貴而需要重新檢視？哪些技術特性可以完成額外的用戶需求進而變成功能的一部分？
需求與技術委員會的組成人數不能太多，否則會很難就所有問題達成共識，另外就是系統的設計風格與特性會不容易統一，有流於大雜燴系統的危險。
進一步討論，為什麼風格是大型系統開發重要的因素？
我很喜歡的一個例子是歐洲教堂的建築過程。大部分的歐洲建築在不同時代呈現的風格都不一樣，不同建築師對於整體設計的概念與強調的細節也各具特色，其中有一些費時百年才建好的城堡及教堂，假如後人不沿用前人的風格而擅自更動設計，就有可能破壞整個建築的美感與歷史價值；雖然軟體系統不太可能沿用數百年，但其中道理是一樣的。
掌櫃本人去過很多座歐洲的百年教堂，在巨型建築底下感覺自己渺小時，常常會想起這個譬喻。
一個值得留意的細節是，架構師團隊產生的文件與說明書應該由盡量少的人來主筆撰寫，再提供給團隊其他成員檢視以統一共識，因為在書寫的每個部分都有許多 mini-decision ，像是用字遣詞的方法及表達風格，由少數人操刀可以盡量維持相同的溝通意念，這對於使用這些文件的外部團隊來說有比較容易閱讀理解。
-
外科手術團隊
在專案建立之初，經常困擾專案經理人的一個問題是：根據手上的資源，什麼樣的團隊設計可以讓生產力最大化？
通常，我們有兩個直覺選擇，同樣的預算下，可以找來 10 個工程高手或是 50 個普通人。大部分經驗顯示， 10 個高手組成的團隊績效會比 50 個普通人更好，就組織角度，這是得利於溝通成本的極簡化，以及更低的整體人事與其他固定成本。但是我們都知道，高手之所以很容易被辨識出來就是因為稀有，寄望專案中所有人都具備高手資質是不切實際的，尤其是專案規模極大的時候。
同時，全部由高手組成的工作團隊在真正的大型系統專案中也不敷需求，因為大型系統動輒數百上千個「人年」，如果堅持用小團隊開發大概得等待人類移民火星的時代來臨才能完成了吧。
作為折衷方案， 《人月神話》 提出一個仍然貼近現代軟體開發需求的建議：「外科手術團隊」。
外科手術團隊的概念是，一個基本工作單位中只有一位主要的程式設計師 (主 code ) 擔任相當於主治醫師的角色，他對於程式開發的細部決定有主導權力，也是主要的產出者。
另外也會有一位「副 code」擔任助理醫師的角色，相當於主程的分身與 back-up ，需要對於程式開發的內容有與主治醫師相同的理解，也協助一部分的程式產出，這位分身可以是團隊對外溝通日常技術問題的主要窗口，讓「主 code」將所有精力留給程式開發。
最後是麻醉師的角色，在真正的外科手術團隊中麻醉師是掌握病人即時資訊的人，如果麻醉師認為病人身體情況不佳，那麼手術也必須延後。在軟體開發團隊中，麻醉師可能相當於專案經理，掌握外部的需求變化、互相關聯的其他工程團隊進度以及資源協調工作。
外科手術團隊的具體隱喻角色與人數放在今天的環境中並不需要斤斤計較，重點是其團隊設計理念，圍繞在高手身邊建立一個能與他互補的支援團隊，讓高手能夠最大程度的發揮他所具備超越常人的生產力。
一旦實現了外科手術團隊的組織設計，我們就能用 10 個高手分別擔任主 code，快速建立總規模可能達到 50-100 人的多個小工作團隊。
這個組織形式，並不限於專案，在大型企業當中分派明星領袖去打哪個一級戰場時，也經常有類似的思維。