巴比Ｑ看世界

全書的重點大概分為下列這幾點：

   1. 在落後的專案增加人力，並非挽救時程之靈丹妙藥。
   2. 架構規劃應由少數精英為之，軟體實作才需多人並行。
   3. 垂直分工比水平分工有用。
   4. 軟體開發的瓶頸在於由「抽象概念」 --> 「實作架構」這段轉換流程。
   5. 專案成功四要素：(1) 高品質人力 (2) 正確的組織 (3) 良好的管理 (4) 優秀的環境。

在落後的專案增加人力

這個主題也是本書的重點，更是書名「人月神話」的由來。主要內容乃敘述專案管理者的一個迷思：「如果專案落後，那麼就多加一點人趕回來。」之所以無法用增加人力來趕上時程，乃因軟體開發為高度知識密集的工作。整個團隊成員會隨著專案時間的推移，慢慢共同擁有一種推動工作所需的知識。在一起工作的時間越長，這個共識就會越大。越晚進來團隊的成員，就得花越多時間汲取這個共識，趕上大家。 而原先在團隊中的某些成員，會因幫助這位新進人員，而拖慢原先的工作速度。

此外，越多人也代表需要溝通的管道越多。一個有 n 個人的團隊，每個人都需要跟其他 n-1 個人溝通。也就是所需的溝通管道有 n(n-1) 個這麼多。因此，在落後的專案中增加人力，有蠻大的可能會失敗的。

我個人倒是對此抱持一點點不同看法。雖說在知識密集的專案中加人得不到好處，但這不代表在軟體專案中，勞力密集的部份加人，是完全得不到好處的。相反地，若軟體架構都已經定好，剩下的只是找人把程式碼填上去，這部份如果增加人手，應該是可以加速整個專案進行的速度。但如果填程式碼時，仍需大量與其他人溝通，或者要填入程式碼，需要先汲取大量背景知識，那您可能就得考慮一下了。

架構規劃應由少數精英為之

作者見過一個大系統專案下來後，專案經理粗暴地切為數個模組，每個模組各交給一個團隊，去執行「設計、實作、測試」等動作，然後整合不起來的慘痛教訓。因此作者強調，「設計」或「架構規劃」這件事，必須僅由少數精英為之，免得發生最後整合不起來的狀況。作者用「先專制、後民主」來形容架構設計初期應由少數精英專制為之。等到架構固定後，怎麼去把它實作出來，則下放由程式師自由決定。這段話，我相當同意，也與我日常感受的實務經驗是相符的。

垂直分工 vs. 水平分工

執行過軟體專案管理的人應該都有這個經驗：一個專案如果要分工的話，究竟是應該依照「模組一」、「模組二」...這樣分給不同團隊，然後在每個團隊都配置程式師、測試人員呢？還是依照「專案組」、「實作組」、「測試組」...然後在專案需要實作時，整個交給實作組。需要測試時，整個交給測試組呢？前者作者命名為「水平分工」，後者則命名為「垂直分工」。

作者建議採取「垂直分工」會優於「水平分工」。如果採取「水平分工」，會破壞軟體專案的整體性，有可能導致各模組最後整合不起來的窘境。而每個小團隊內應採取「外科手術團隊」的模式。所謂外科手術團隊，就是只有一兩個人是主刀者，其他都扮演支援主刀者的角色。

以「實作組」為例。專案交到此組後，只會由一兩個人真正去實作。其他人都扮演支援實作者，讓他們速度加快的角色。如果不採取此一方式，而讓實作組內每個人都是程式設計師的話，軟體專案一來，又會落入如何切割此一專案，好讓它「平行」地被處理。然而我們都知道，軟體最好是不要切割，才容易在最後整合、並保有其完整性。

軟體開發瓶頸

整個軟體開發過程中，您知道哪一段最耗費時間嗎？先給您一點提示，絕對不是實作。之所以大家會花費大量時間在實作，那是因為我們都太早開始寫程式了。如果能將架構分析到稍微細一點，程式設計只是花時間寫就有成果的苦工而已。

答案是由「抽象概念」-->「實作架構」這段最花時間。套句軟體工程的行話，就是「Requirement」 --> 「Design」這段最花時間。舉例來說，一個 ATM 機器設計出它有「存款」、「提款」...等功能。但要設計到存款的軟體架構出來，是最花時間的。一旦架構清楚了，實作程式碼只是「花時間就有」的苦工。

專案成功四要素

首先是高品質的人力。根據研究，一位好的工程師與一般的工程師，生產力最高可達十倍以上。但每位專案經理也知道，要找能力好、配合度（我比較喜歡稱它為「溝通能力」）高的人，是非常不容易的一件事。我個人比較偏好選擇善於溝通的人。通常善於溝通的人也大多容易接受變化，吸收新知能力也不錯。所以，我會很留心那種履歷看起來不怎麼樣，但每個工作都隱藏了求職者在溝通領域上豐碩成果的人。

其次是正確的組織。一個正確的組織，可以降低溝通的複雜度。沒有一種組織可以適用於所有的專案，所以在這裡作者也沒有告訴我們一種可以照抄的「黃金組織」。您必須審慎評估每次任務著重的是什麼，來決定您的組織應該長得如何。

再來是良好的管理。所謂的管理，幾乎都跟人有關。這裡作者蠻推崇另一本書「Peopleware」。該書詳細提到軟體工程師在意的、不在意的事情有哪些。如果您不是工程師出身，建議您一定要去看看。您會驚訝的發覺，工程師在意的其實都是小事，而且還蠻容易達成的。您可能也會發覺，平常自覺做一些「有利於工程師」的事，為什麼他們都不領情。

最後是優秀的環境。很多人以為，工程師要的環境，是像 Google 總部那樣，要有喝不完的飲料、吃不完的餅乾、撞球檯...等。事實上，那些設備都是讓工程師覺得「我被重視，我不是一顆螺絲釘」而已。而讓工程師受到重視的方式很多，不一定要花大錢。只要把握「尊重」原則即可。像在大家加班時，經理人去買罐飲料請大家喝，都是讓工程師感到尊重的方法。此外，軟體工程師還需要「安靜」的環境。這裡的「安靜」，不是維持一根針掉在地上都聽得到的環境。正確一點來說，應該是「不被打擾」的環境。比如說，可以把電話鈴聲切斷，讓他們好好想程式碼或軟體架構的環境。或者是沒有愚蠢至極的「XXX 請接二線」那種廣播的環境。其實，只要你能提供工程師一個「不受打擾」的環境，剩下的部份，他們會把玩偶啦、書籍啦搬來辦公室，讓自己舒舒服服的，這點不用您操心。

本書內容概述

我覺得本書的精華在：

• 第二章「人月神話」：敘述「在落後的專案投入人力，未必能扭轉乾坤」。
• 第三章「外科手術團隊」：描述小團隊應只有一兩人執行「主刀者」的角色，其他人執行支援任務，可以達到最大綜效。
• 第四章「專制、民主與系統設計」：講述了系統架構設計應由少數精英為之，以稍微專制的方式維持其一致性。之後實作時，只要程式師能達到目標，實作內容應由程式師自由地決定。
• 第五章「第二系統效應」：談到在第一個版本成功後，要避免把第一個版本未實作的功能，一股腦塞入第二版本，導致系統規格崩潰的效應。
• 第十六章「沒有銀彈：軟體工程的本質性與附屬性工作」：這篇是 1986 年，作者大膽預測，在未來十年內，不會有任何一種工具，可以把生產力提高十倍以上。因為軟體工程的瓶頸，就是在把「系統需求」的抽象概念，轉換成「系統設計」的實作架構。而這部份需要高度的智慧，機器是無法代勞的。
• 第十七章「再論『沒有銀彈』」：前一篇刊出後，造成極大風波。作者在前一篇發表十年後，將他收集到的意見，重新詮釋他所謂「沒有銀彈」的真正意涵。並回頭檢視十年前他發表那一篇「沒有銀彈」，是否為正確的預測（當然是囉）。

至於其它章節，可能有些過時，或者當年說的事情，已經在今日奉為圭臬。所以參考價值不高。不過，能吸收到上面六個章節的概念，我也覺得已經值回票價了。

結論

本書雖然內容有部份已經過時，但仍有不少概念，歷經三十年，仍為業界真理。回頭看來，不得不佩服作者當年的遠見。建議所有專案經理人，都應該閱讀本書。本書前後章節雖偶有關聯，但關聯性不強。您可參照我上面提出的六個精華章節，順序閱讀完畢即可。期待同為喜好本書的讀者交流意見。