讀書有感–人月神話

看到介紹人月神話這本書，請不要以為是羅曼史小說或者傳奇故事。
它是一本二十年前出的、講三十年前軟體專案管理問題與經驗的書，原名是The Mythical Man-Month。其中的很多事例，現在仍存在，其中很多經驗，現在拿來用都還來得及。這次的版本為20週年紀念版。
此外，先說一下，這本書是lis介紹我看的，一直在等他介紹，沒想到我卻先寫了。

曾經接過急迫且大型的網站建置專案，但是進行上卻還算順利，這是由於系統工程師十分有經驗，在分工、次序與掌控上，都做了很好的安排。
但在最近的一個朋友的經驗中，卻是遇到網站的機制改版，在時程與資源運用上卻不斷延遲，還好是內部機制，不用對客戶交代，否則所蒙受的將不是只有金錢上的損失。
我們知道時程延遲，但原因在哪裡？為何會發生？
人月神話的第二章，應該是這本書的精華，也是書名的由來，看完這個章節，發現作者道出很多軟體專案上的管理關鍵。而軟體專案是不可以完全套用傳統產業的專案管理方式。
第一個關鍵 樂觀
首先作者提出了一件常常發生的事情，這也是一個朋友身上發生的故事：『程式設計師都是樂觀的傢伙。』而且我發現越年輕越樂觀，但是無可避免的這是個年輕的產業，很少會遇到很有經驗的程式設計人員，這些年輕人，即使告訴他這樣是會有問題的，他也不改其樂觀。
所以『他們所做的第一個錯誤假設是一切都會進行的很順利』可是沒有想到一個bug，就可以花上一天時間也無法解決。然後，就延遲了後面本來假設可以順利進行的部分。
第二個關鍵 人月
人月，是我們預估和排定時程用的，但是作者提出一個前提：『使用人月必須要在人力與工時可以互換的狀況下。而且要當工作可以切割、投入工作的人不用溝通，人力與工時才能互換。』就是說要可以互換，才能使一個人做30天，與30個人做一天的結果一樣，不然單純用人月去估算時程，一定會有誤差。
為什麼呢？首先軟體專案有其連續性，作者舉了個例子，蠻傳神的，他說，生小孩就是要九個月，你叫多少個媽來生都是一樣。第二點是因為即使工作可切割，但是需要溝通，越多人投入就需要多的溝通與教育的時間，所以一個人做30天的工作不可能用30個人做一天就完成。
所以，Brooks定論說，在一個時程已經落後的軟體專案中增加人手，只會讓它更加落後。
因此，要讓一個專案順利進行，首先要有良好的時程規劃，考慮所有的因素，而且，程式人員要有勇氣不要妥協，堅持自己預估的時程。就像是廚師一樣，即使外面的客人在等著上菜，一隻雞要烤多久就要烤多久，不能因為妥協就用大火烤焦了。
外科手術團隊
這個篇章看完突然想到研究所的專案管理課程，三個學分，卻是我們一個學期的研究重心，四個實際運作的專案，大家分組進行，教授不斷的製造專案危機，像是公司被併購、人員流失、專案形式改變、客戶不斷施以壓力等等，但最後大家還是順利的結案。
這是個難以忘懷的經驗，組員們的默契在起初的確造成危機，但是，由於大家的素質還算整齊，很快就可以建立溝通的語言。加上大家熟悉協同科技概念與網路溝通，可以做到分時分地作業，也使得專案進行有效率。
但當我看完這篇外科手術團隊後，我發現其實還有個成功的關鍵在其中，就是同學們各有專長，所以，分工很容易，又因為有選出leader作為掌控者，所以，不會亂。大家不會做重複的事情。每個人按照時程交差，就可以順利完成。
作者認為一個外科手術中，有操刀的大夫，有護士、有麻醉師等等，各司其職。而不是像屠夫團隊，每個人都得拿刀。一個團隊中只有一個人操刀，其他人扮演支援的角色。這樣整件事情就會出自一個腦袋不會亂，也不需要不斷的溝通協調。
這兩個篇章是我比較有感覺的，寫出來跟大家分享。
最後，作者還有一個人月的概念我覺得很重要，這會影響到組織的公平性：一個好手，花一天可以做完，但同樣一件事，庸才卻需要三四天以上，甚至加班趕工，也許還領加班費。如果照這樣去計算人月，一定會差之千里。
◎後記，這篇文章寫給我那些一起在『聲色場所』膽顫心驚共同應戰的同學們。
﹝延伸﹞到博客來看人月神話內容簡介。
﹝延伸﹞企劃人的工具書 考具讀後介紹 by 阿妮奇