30年後仍適用的軟體專案管理概念

The Mythical Man-Month
人月神話，探究工時與人力無耗損互換的迷思
人月神話》出版至今已經超過三十年，一直被視為是軟體專案管理的聖經。《人月神話》之所以能歷久不衰，一方面是作者Frederick P. Brooks, Jr.本身曾擔任IBM System/360與OS/360這類大型軟體系統專案的專案經理，因此能從實務中提取出具體意見。另一方面，即使IT產業在這三十年中飛快成長，然而《人月神話》對於軟體專案提出的看法與建議，至今仍有參考價值。

所謂的人月（man-month）是用來衡量工作量的單位，也就是一個人在一個月內所能完成的工作量，例如有個專案預估需要12個人月，那麼如果派了4個人來處理這項專案，理論上只要三個月就能達成。Brooks之所以將這個換算的機制稱為神話，是因為軟體專案在本質上，人力與工時是無法互換的，換言之，當專案進度落後時，光靠加派人力到該專案中，並不會增加產能，反而有可能讓情況更加失控。

Brooks認為，軟體專案在本質上是系統性的工作，在過程中必須處理複雜的交互關係，在溝通上必須花費不少的成本。

因此Brooks認為，在專案的人員配置上，最好是有如外科手術團隊，利用支援性的角色，協助操刀的外科醫師，讓開刀過程可以更流暢，而不是讓整個開刀床旁圍滿了一堆外科醫師。另外書中也針對軟體專案的問題，像是架構與實作的分野、溝通的方式、軟案時程預估、預防失敗等多種面向，提出理論與實務兼俱的立論，希望藉此讓陷入困境的專案能順利走出焦油坑。文⊙黃天賜

Tar Pit
焦油坑
焦油坑是因石油揮發而成的黏稠瀝青，表面會因日照而反射出光亮，而讓野獸誤以為是水池而走近，最後陷在其中無法逃脫。

Brooks以焦油坑作比喻，形容他觀察到的大型系統的軟體開發。雖然系統最後總能釋出、運作，但是開發團隊往往無法達到既定的目標、時程或預算上的要求，因此被種種問題困住的開發團隊，就好像跳不出焦油坑的巨獸一樣。

Tractable Medium
易操控介質
在論及寫程式的樂趣時，Brooks舉出數個原因，包含創造的樂趣、有益於他人、可目睹成果動起來、持續學習的樂趣，以及最後的原因便是易於操控的介質。

在介質這一點，Brooks將程式設計師與詩人相提並論，只要動動腦筋，兩者就可以創造出美妙的事物，而更甚於詩人的是，程式設計的結果，能具體讓人感受到它的運作。一些問題也伴隨容易操控的特性而來，軟體工程便是在解決這些問題。

Aristocracy
貴族政體、菁英份子
軟體系統在設計時，至關重要的一點是保持概念的整體性（conceptual integrity），Brooks認為寧可丟棄某些新奇或更好的特色，以反映出同一組設計理念。

為了達到這樣的目的，在設計系統時，必須採用少數人決定的方式，類似於貴族統治的方式，由架構設計師這類角色，決定系統整體的規格。雖然在開發團隊中採用民主方式，可以廣納意見與創意，卻會破壞概念整體性。

Tower of Babel
巴別塔
巴別塔是聖經上的知名故事，人們想要合作搭建通天的高塔，上帝於是將人類的語言分成多種言語，彼此即無法溝通，高塔的任務即告失敗。

Brooks用這個故事來聚焦軟體開發過程中溝通的重要性，他指出許多問題都源自左手不知道右手在做什麼的情況，因此開發團隊成員應該應用各種方式，包含非正式方法、會議與工作手冊進行溝通。

Document Hypothesis
文件假說
「在成堆的書面資料中，有一小部分關鍵性文件記錄著任何專案管理的核心工作，而這些文件是身為管理者最重要的工具。」這是Brooks提出的假說，而他透過與其他產業運用文件的情況，驗證這個假說的真實性。

紙上作業經常被視為繁瑣、無趣，但Brooks認為對管理者而言，文件能讓團隊的思考與討論更集中，也能作為監督和預警的機制，因此對軟體工程的文件作業和其他產業一樣重要。

Silver Bullet
銀彈
在傳說中，銀彈是殺死狼人的致命武器，因此如果將軟體專案比喻為狼人，那麼能讓狼人一槍斃命的銀彈會是什麼呢？Brooks懷疑這種銀彈並不存在，這和軟體工程的本質有關。

他認為軟體工程的本質是架構許多抽象概念，並進一步制定規格、設計與測試，這造成它的高度複雜性，易變性、隱匿性等特質，因此軟體工程，這些難度不會因為軟體技術進步（像高階語言、整合開發環境）而帶來根本性改變。

Catastrophe
大災難
軟體專案釀成不可收拾的大災難究竟是如何造成的？Brooks認為大災難其實就是每天一點一點地的延誤中造成的。

因此日常的監控機制便相當重要，像是建立明確描述、可量測的里程碑（milestone），或是利用計畫評核圖來監控與應變進度狀況。
另外，成立計畫監控小組，擔任進度的守門員，進而提醒團隊容易疏忽掉的落後時程，對於專案有相當大的幫助。

Auxiliary Program
輔助程式
開發軟體系統，測試與除錯是相當重要的一環，因此建立良好的測試方案就至關重要。Brooks介紹了數種測試方案中應該包含的項目，而在介紹建立充份的測試鷹架（scaffolding）這個項目時，他介紹三種鷹架形式：傀儡組件、迷你檔案和輔助程式。

輔助程式是用來產生測試資料、列印特定分析結果與分析交互參考的表格的工具程式，提升除錯工作的效益。

Surgical Team
外科手術團隊
Brooks認為太多人參與專案開發，往往會增加溝通的成本，容易因為傳達不清形成不良影響。然而面對大系統，精簡的人力又往往增加時間成本。

兩難之中權衡，他認為開發團隊應該像外科手術團隊，不需要每個人都要實際操刀，而是應該安排像隨侍在外科醫生旁邊的支援性角色，增加操刀者的效率與生產力。換句話說，可以適時地加入行政助理、祕書、程式助理等人員。