人月神話｜產品經理該讀的書

人月神話這本書，是軟體工程界的經典之作，如同夜空中閃爍的星辰，指引著一代又一代的軟體開發人員，作者在 IBM System/360 和 OS/360 專案中的親身經歷，深刻剖析了大型軟體專案的挑戰與困境，揭示了軟體工程領域中那些看似理所當然，實則暗藏玄機的「神話」。

身為一位在互聯網產業深耕多年的產品經理，同時也是敏捷方法論 Scrum 的忠實信徒的我，把小時候讀過，但讀的一知半解的《人月神話》再默默的看了一次，起源來自於 Reddit 論壇 r/programming 社群關於本書的討論後，讓我重新審視這部經典。

軟體專案的焦油坑

這一章用一個很生動的比喻告訴我們，為什麼做軟體專案這麼難，作者把這個比喻稱作「焦油坑」。

焦油坑是什麼？

焦油坑就像是史前動物會掉進去的黑色黏稠泥潭，一旦掉進去，就會越掙扎越陷越深，最後逃不出來。

在軟體專案中，焦油坑就像是專案進行到一半時遇到的問題，例如進度落後、功能複雜，或是突然需要增加人手幫忙，結果反而讓問題更嚴重。這個問題很容易被忽略，因為我們常以為增加資源就能更快完成任務，但真實情況卻完全相反。

人月的迷思

人月神話這本書特別點出「人月」這個概念是一個危險的陷阱，因為「人月」是把人數和工作時間相乘的估算方法，例如：

• 10 個人 × 1 個月 = 10 人月

這種算法的危險在於，它完全忽略了以下三個重要問題：

1. 溝通成本：人多時，團隊裡面每個人都要花更多時間溝通協調。
2. 任務相依性：任務之間互相有關聯，無法輕易地分割給更多人。
3. 新人學習曲線：新來的人需要培訓，並不能馬上發揮作用。

真實案例：OS/360 專案

人月神話在書中舉了一個非常有名的例子——IBM 的 OS/360 專案。

這個專案本來就已經落後進度，後來管理層覺得：「沒關係，晚了就多找一些人來幫忙。」但是最後反而因為增加的人太多，導致：

1. 介面衝突：每個人的想法不同，寫出來的東西互相衝突。
2. 知識傳遞困難：新人加入需要大量時間了解之前做了什麼，怎麼繼續進行。
3. 管理混亂：人越多，越難以分配和管理任務。

結果原本想要縮短的進度反而拖得更長，問題越來越複雜，就像一隻猛獁象掉進焦油坑，越掙扎越陷越深。

布魯克斯法則（Brooks’s Law）

人月神話為此特別提出一個非常重要的觀點，就是所謂的布魯克斯法則（Brooks’s Law）：

「對已經延遲的專案增加人力，只會讓它更晚完成。」

用了一個餐廳的比喻來解釋：

假如你點了一道菜，但菜遲遲沒做好，這時廚房再多加幾個新手廚師，不但無法解決問題，主廚還得花時間教學徒們，反而讓情況更糟糕，菜會更慢送上來。

專案管理的正確方式

知道這些問題之後，我們應該怎麼避免掉進焦油坑呢？

人月神話提出幾個建議：

1. 小團隊比較好管理：小團隊的溝通成本低，任務分配明確，做事效率更高。
2. 事前規劃要做好：避免臨時加入大量人手或大幅調整任務需求，這會讓團隊混亂，問題更嚴重。
3. 注意小延誤的累積：每天的小延誤，累積起來會變成大問題，要盡早發現並處理。

為什麼軟體專案常常超時？

超時的主要原因不是技術問題，而是時間管理的錯誤：

1. 低估時間：團隊通常會過度樂觀，以為「一切順利的話，應該可以準時完成」。
2. 人力與時間的錯誤換算：「一個人做 10 個月的工作，10 個人能在 1 個月內完成」的想法是錯誤的，因為軟體開發需要大量的協作與溝通，並非獨立工作。
3. 進度監控不佳：許多專案並未建立良好的進度追蹤機制，導致問題發現得太晚。

人力與時間並非可互換

許多管理者以為「10 個人月 = 1 個人 10 個月」，但這種計算方式只適用於可以平行處理的工作，例如工廠生產，然而，軟體開發的特點是：

• 許多任務是線性的，無法並行進行，例如設計 -> 程式開發 -> 測試。
• 溝通成本會隨人數指數成長：當團隊人數變多，成員之間的溝通、知識傳遞、整合成本會大幅增加。

因為新加入的成員需要時間學習（降低效率），還會打亂現有的團隊運作，導致生產力下降。

軟體開發的時間分配

在人月神話提出了一個軟體專案的時間分配原則，這個分配方式可以幫助管理者理解開發過程中各個階段需要的時間比例（注意，這本書是 1975 年發行的，你們參考就好）：

1. 1/3（33%）：規劃與設計
   • 包含需求分析、架構設計、技術選擇。
   • 這個階段決定了專案的基礎，錯誤的決策會導致後續開發階段困難重重。
2. 1/6（17%）：寫程式
   • 這是實際寫程式碼的時間。
   • 許多人誤以為「寫程式」佔據了專案的大部分時間，但事實上，只佔了不到 1/6。
3. 1/4（25%）：測試
   • 包括單元測試、整合測試、系統測試。
   • 測試階段的時間常常被低估，但如果這部分省略或縮短，可能會導致產品出現大量錯誤，影響最終交付。
4. 1/4（25%）：整合與系統測試
   • 在這個階段，團隊要確保所有模組能夠順利合作，並修正最後的問題。
   • 許多專案在這個階段發現問題，才驚覺需要花費比預期更多的時間來修正。

這樣的時間分配方式，說明了一個關鍵點：寫程式並不是開發專案中最花時間的事情，規劃、測試、整合同樣重要。如果管理者只關心「程式寫得快不快」，而忽略了其他階段，專案最終很可能會出現嚴重的延誤與品質問題。

很多專案都把時間過度集中在「寫程式」這個階段，卻低估了測試與整合的重要性，導致最後的延誤。

當專案落後時該怎麼辦？

錯誤做法：

1. 增加人手，希望加快進度（但會造成更多混亂）。
2. 縮短測試時間（導致產品品質低落，後續問題更多）。

正確做法：

1. 重新評估專案時程，避免「小幅延期 → 大幅拖延」的問題。
2. 確保架構完整性，讓開發團隊能夠並行作業，減少彼此依賴性。
3. 提高開發流程效率，而不是盲目增加人力。

外科手術團隊

人月神話有一個核心概念是「外科手術團隊」，想像你要做一個超級複雜的樂高模型，通常你可能會找很多朋友一起幫忙，但如果人太多，反而會互相干擾，甚至有人可能會弄亂你原本的設計。所以，最好的方法是讓一個人當主導，其他人負責支援，這樣才能組裝出最完美的樂高。

在軟體開發中，傳統方式常常是把一個大專案拆成很多小部分，然後分配給不同的人做，最後再組合起來。但這樣容易出現問題，例如：

1. 每個人的風格不一樣，導致系統不統一。
2. 需要很多溝通，結果時間花在開會和協調上，而不是寫程式。
3. 一個部分有問題，可能會影響到其他部分，修正起來很麻煩。

外科手術團隊：讓專案更有效率

外科手術團隊這種模式就像醫院裡的外科手術室，只有一位「主刀醫生」負責主要的開發工作，其他人都是支援角色，幫助確保手術順利進行。這種方式的好處是：

1. 決策快：由最有經驗的人來做核心設計，不需要花太多時間開會。
2. 品質穩定：程式碼風格統一，整體架構也更有一致性。
3. 溝通成本低：不需要所有人都參與設計，只要核心成員清楚整體方向。

這種方式最大的優點是讓最優秀的人專注在最關鍵的事情上，其他人則提供支援，讓他可以更快完成任務。

為什麼這種模式適合軟體開發？

在大多數軟體專案中，最常見的問題是「團隊太大，反而變得沒效率」。就像打籃球，如果場上有 20 個球員在搶同一顆球，反而會一團亂。傳統的開發方式讓很多人分工，但這樣容易出現：

1. 溝通問題：每個人都有自己的想法，最後程式碼變得很混亂。
2. 決策變慢：每次改動都需要所有人討論，結果什麼都做不了。
3. 責任不清楚：當一個 bug 出現時，沒有人知道該找誰修。

貴族制、民主制的系統設計

系統設計的兩種方法：貴族制與民主制，並強調 「概念完整性」對於系統設計的重要性。

主要觀點

1. 概念完整性
   • 一個好的系統應該有統一的設計理念，而不是由不同開發者各自加入的拼湊設計。
   • 統一的願景可以讓系統更加一致、簡潔，並且使用起來更直覺。
   • 這就像一棟經過多代建築師設計的教堂，如果每一代都加上自己的特色，最後整體風格可能會變得混亂。
2. 貴族制與民主制
   • 貴族制指的是由少數具有遠見的架構師主導系統設計，確保統一性。
   • 民主制則是讓每個碼農都可以自由加入自己的設計理念，但可能導致系統風格不統一。
3. 產品開發的實踐
   • 一個好的軟體系統，就像一座偉大的建築，應該有一位「總建築師」，確保最終的概念完整性。
   • 軟體開發不應該是一個完全民主的過程，而是需要一位「架構師」來確保整體一致性。
   • 產品經理的角色就像是這位「架構師」，確保功能、設計與整體願景一致，而不是讓每個工程師各自為政，導致產品變得複雜難用。

「民主可以決定要做什麼，但貴族制應該決定怎麼做。」 這就是為什麼產品開發不能完全民主，而需要一個清晰的主導者。

第二系統效應 The Second-System Effect

這個效應指的是在第一次設計一個系統時，通常會專注於最基本的需求，因為團隊經驗不足，資源有限，不會過度設計。但當他們設計第二個系統時，往往會想要補償第一個系統的缺點，結果加入太多功能，導致系統變得過於複雜，難以維護，甚至失敗。

為什麼會發生？

1. 設計師對於第一個系統的遺憾，想要「一次補足」所有功能。
2. 在第一個系統成功後，團隊的自信心增強，可能會低估新增功能帶來的影響。
3. 團隊會受到市場或高層壓力，要求加入過多的「創新」功能，而忽略系統的核心目標。

如何避免第二系統效應？

1. 自律與克制：團隊應該時刻提醒自己，不要為了補償第一個系統的遺憾，而過度增加新功能。
2. 明確的功能取捨：每個新增功能都應該有清楚的價值評估（例如「這個功能值多少嗎？能提高多少效能與記憶體需求能下降多少？」）。
3. 經驗豐富的架構師：團隊應該由有兩個以上系統開發經驗的人來帶領，避免陷入過度設計的陷阱。

我們要特別警惕「功能膨脹」，專注於真正重要的需求，而不是追求「一次把所有可能性都加進去」，尤其是老闆的「建議」。

傳遞決策，確保設計決策能夠有效地被傳遞

當軟體專案規模變大時，「主刀醫生」的決策如何確保所有實作團隊都能夠理解並執行？如果沒有良好的溝通機制，設計上的概念完整性就會被破壞，導致系統變得混亂。

1. 文件規格的重要性
   • 「文件規格」是確保架構決策傳遞的重要工具。無論是系統設計文件、API 規範，還是開發標準，這些書面規格能夠確保團隊內部的資訊同步，減少錯誤的發生。
   • 如果沒有詳細的書面規範，開發人員可能會根據自己的理解做出決策，導致與原本的設計不符。
   • 對產品經理來說，就是所謂的 PRD 文件了，詳請可以參考我這篇PRD 怎麼寫？我教你文章。
2. 定期的技術會議
   • 透過定期的技術會議，確保架構師與開發團隊能夠對齊理解，避免誤解。
   • 這些會議不只是通報決策，而是確保大家都能正確理解背後的邏輯。
3. 建立「電話紀錄」（現在應該叫會議記錄）
   • 在開發過程中，開發人員難免會遇到不確定的技術問題，此時最好的方式是直接向架構師請教，而不是自行猜測。
   • 建議建立「電話紀錄」，讓架構師將每一次的技術解釋記錄下來，並定期彙整給團隊，確保所有人都能獲得相同的資訊。
4. 測試團隊的獨立性
   • 測試團隊應該獨立於開發團隊，這樣才能夠客觀地審視產品（ 不要讓碼農測試自己的代碼，Bug 會變成功能），確保最終結果符合規格。
   • 測試團隊的角色類似於「魔鬼代言人」，專門找出產品中的缺陷，避免產品上線後才發現嚴重問題。

架構師的決策如果沒有被清楚地傳遞，就算設計得再好，最終的實作仍然可能變得混亂不堪。 所以，產品經理或技術主管在帶領團隊時，必須重視「決策傳遞」的機制，確保每個人都能理解並執行一致的規範。

為什麼巴別塔為何失敗了？

巴別塔的故事是醬的：在很久很久以前，人們本來都講一樣的語言，他們決定一起蓋一座通往天空的高塔，讓自己變得很厲害，不會被世界分散。但上帝看到了，覺得這樣不行，於是讓他們的語言變得不一樣，大家聽不懂彼此在說什麼，結果塔就蓋不下去了，計畫失敗了。

那這和軟體開發有什麼關係？ 人月神話用這個故事來說明「軟體開發為什麼容易失敗」。巴別塔之所以失敗，不是因為人手不夠、資源不夠、時間不夠，也不是技術不夠，而是「溝通」出了問題，當大家聽不懂彼此的語言，工作沒辦法協調，軟體開發就會卡住，甚至讓團隊分崩離析。

這就像在一個軟體開發裡，如果團隊成員之間沒有良好的溝通，沒有人知道別人在做什麼，就會出現功能不合、程式錯誤、進度延遲等問題。當專案變得越來越大時，這種問題會更加嚴重，導致最後專案失敗。

巴別塔的故事告訴我們什麼？

1. 專案不是只有技術，溝通才是關鍵
   • 很多人覺得，只要有好的工程師、有足夠的時間和金錢，軟體開發就一定會成功，但事實並非如此，真正的挑戰是如何讓這麼多人可以有效合作。
   • 就算是最厲害的工程師，如果沒有清楚的溝通，最終專案還是可能會失敗。
2. 溝通不良會導致「巴別塔效應」
   • 在軟體專案中，如果團隊之間沒有良好的溝通，開發的功能可能會彼此衝突、資訊不一致，導致最後整個系統無法運作，就像巴別塔的建造計畫一樣，最後被迫停工。
3. 專案管理的重點：組織與溝通
   • 在軟體開發中，溝通與組織是比技術更重要的事情，如果沒有良好的協調，就算有最頂尖的工程師，最後還是可能做出一個無法運作的系統。
   • 所以，產品經理應該確保軟體開發有良好的資訊傳遞機制，例如：
     • 建立正式的文件：讓每個人都能清楚知道規則和進度。
     • 保持定期會議：確保每個人都知道目前的進展，並解決可能的問題。
     • 讓每個團隊之間有清楚的責任分工：避免混亂與重複工作。
4. 軟體開發範圍越大，溝通成本越高
   • 當軟體開發團隊規模擴大，問題會隨著人數增加而變得更嚴重，因為當團隊變大，彼此之間的溝通成本會指數級增加，每個人需要花更多時間確認資訊，並解決各種誤解和衝突。
   • 如果一個軟體開發團隊有 N 個人，那麼可能的溝通路徑有 N(N-1)/2 條，這意味著人越多，溝通的難度會變得超級高。

這不是在通靈，準確估計進度就是那麼困難

估計時間就像是預測未來一樣困難，每個軟體開發都有太多變數，包含需求變更、意外的技術挑戰、團隊的學習曲線等等，當我們以為一件事情能在兩週內完成，往往會因為各種不可控因素拖延更久。

1. 高層和開發團隊的溝通差距
   預測進度是管理者的責任，但往往管理者與實際負責寫程式的工程師之間有理解上的差距，老闆希望有明確的進度數據，但工程師卻知道，開發過程中會遇到大量意想不到的問題，這些問題無法在一開始就精確計算（尤其是技術債的累積）。
2. 過於樂觀的估計
   大多數開發人員是「樂觀主義者」，他們總是認為「這次應該沒問題」，所以時間估計往往太短。這也是為什麼很多專案剛開始時，看起來好像進展很順利，但到了後期卻出現了大量延誤。
3. 微小延遲的累積效應
   每天小小的延遲，最終會累積成重大延誤，例如，今天某個人請假導致會議延期，明天因為某個技術問題卡住，後天又因為某個決策需要重新討論，這些小延遲加總起來，可能讓專案整體晚了幾個月。
4. 如何應對這些問題？
   書中提到一個關鍵概念：里程碑管理，與其去預測每個小任務的準確時間，不如設定幾個「明確且不可變的里程碑」，這些里程碑能夠讓管理者更容易追蹤進度，並且在問題發生時提早發現。

假設我們要蓋一座狗屋，媽媽問我們：「你覺得什麼時候可以完工？」我們可能會說：「兩個星期！」因為我們覺得這很簡單，木頭釘一釘，窗戶裝上去，應該就沒問題了。

但實際上，可能發生這些問題：

• 第一天：木頭買來了，但發現尺寸不對，要回去換。
• 第三天：開始釘木頭，但釘子不夠長，得去買新的。
• 第五天：下雨了，不能施工。
• 第七天：窗戶來了，發現尺寸不合，要重新叫貨。
• 第十天：狗屋基本完成了，但發現樓梯還沒蓋，要再多兩天，靠！

原本估計兩週完工的狗屋，最後可能要一個月才能完成，這就是為什麼軟體開發專案的預測很難，因為我們在開始時，根本無法知道會遇到哪些問題。

解決方案：

1. 里程碑制度：與其預測每一個步驟的時間，不如設定幾個重要的完成點，例如：「第一週內完成地板」，「第二週內裝好牆壁」，這樣即使某些小步驟有問題，至少大方向不會太偏離。
2. 監控進度：每天記錄哪些地方有延誤，並思考如何補救，而不是等到最後才發現進度嚴重落後。
3. 合理的時間緩衝：在預估時間時，加入額外的「緩衝時間」，假設原本以為可以三天完成的任務，可能需要四到五天。

軟體開發中的「過度擁擠」

簡單來說，就是當開發團隊試圖在有限的時間、人力或技術條件下，硬塞進太多功能，結果往往導致品質下降、開發時間拉長，甚至讓整個產品崩潰。

為什麼軟體專案總是塞太多東西？

軟體開發時，最常見的問題是 「這個功能也想加，那個功能好像也不錯」，最後變成什麼都想做，但什麼都做不好。這通常有幾個原因：

1. 客戶或老闆不停地加需求：
   「欸，這個功能很酷，加進去吧！」、「競爭對手有這個，我們也要有！」結果專案變得越來越複雜，根本沒完沒了。
2. 老闆太樂觀：
   老闆以為加個功能很簡單，但沒想到一個小改動，可能會影響整個系統，最後修改來修改去，反而拖延了開發進度。
3. 怕產品太陽春：
   會擔心如果功能太少，客戶會不買單。但事實上，東西太多，反而讓使用者覺得混亂，最後沒人想用。

嗯，這三點，我前老闆全中。

硬塞功能的後果

如果在有限的時間內，硬要塞進太多功能，會發生幾個壞結果：

1. 程式變得超複雜，開發時間拖超久：
   這就像蓋一棟房子，原本只想要一層樓，結果臨時決定要加游泳池、地下室、屋頂花園，最後蓋到一半發現時間不夠、預算也不夠，整個爛尾。
2. 使用者搞不懂怎麼用：
   當一個 APP 有一大堆按鈕、一堆設定選項，使用者只會覺得認知過重，甚至直接不用了。
3. 系統效能變慢，bug 一大堆：
   功能越多，程式碼就越複雜，這樣很容易出錯，修 bug 也會變得更難，最後程式跑起來卡卡的。

怎麼避免這個問題？

1. 「先求有，再求好」：做最小可行版本（MVP）
   與其一次做出超完整的產品，不如先做一個最基本、但能解決主要問題的版本，然後看看市場反應，再決定要不要加新功能。這就像賣漢堡，先確保基本款好吃，再考慮加培根或起司。
2. 學會拒絕，不能什麼都加
   當老闆或客戶說：「這功能很重要，一定要加！」時，要敢於問：「這真的有必要嗎？沒有這個功能，使用者還是能解決問題嗎？」如果答案是「是」，那可能就不需要加（但我知道很難）。
3. 確保系統的可擴充性
   雖然一開始不要塞太多功能，但系統設計時，應該要留好「擴充的空間」，這樣之後如果真的要加新功能，不會因為舊架構不靈活而卡住，就像蓋房子時，先預留好插座和水管位置，未來要加東西才不會拆掉重來，但這件事也要產品經理給了足夠的願景，以及能聽懂的開發團隊成員。

但最終，還是要看你的利害關係人，是不是太利害了，若是，我唯一的建議，就是離職。

軟體開發不能沒有文件

你有沒有試過和朋友一起玩積木，結果大家對要蓋什麼完全沒有共識？有的人想蓋城堡，有的人想蓋機器人，結果弄到最後，什麼都不像，這就是沒有計劃、沒有溝通的下場。

軟體開發也是一樣的，如果大家沒有一個共同的藍圖，每個人照自己理解的方式寫程式，最後拼湊起來的東西可能會亂七八糟，甚至根本不能用。所以，文件就像是「藍圖」，讓每個人都能依照統一的規則來做事。

但問題來了，很多人都覺得文件很麻煩，覺得只要程式寫好，文件沒什麼用，這就像你蓋了一座很複雜的樂高建築，但完全沒有說明書，下一個人來維修或擴建時，只能靠猜測，甚至一不小心就把結構弄壞了。

什麼是「文件假說」？

文件不是可有可無的東西，而是軟體開發的「基礎設施」。人月神話書中認為，軟體系統的設計應該像法律文件一樣，清楚記錄每個決策，確保所有人都能理解並遵守。

但這裡有兩個關鍵概念：

1. 文件是團隊的記憶
   你可能覺得現在記得所有的決策，但半年後呢？更別說新加入的團隊成員了，如果沒有完整的紀錄，大家只能憑印象做事，很容易犯錯。
2. 文件是溝通的橋樑
   一個軟體專案可能有很多不同的角色，像是工程師、設計師、產品經理等等，每個人負責的事情不同。如果沒有清楚的文件，大家的理解可能不一樣，導致最後的產品和預期的完全不一樣。

怎麼寫好的文件？

光說文件很重要是不夠的，關鍵是怎麼寫出有用的文件。這一章給了一些建議：

1. 文件應該簡單、清晰
   太多文件會讓人懶得看，太複雜的文件也沒人看得懂。所以，好的文件要簡潔、重點清楚，讓讀的人能快速理解。
2. 文件要隨時更新
   軟體開發是一直在變的，如果文件沒有跟著變，就會變成過時資訊，甚至誤導團隊成員，所以，寫文件不是一次性的工作，而是要持續更新的。
3. 所有決策都要有記錄
   每當團隊做出一個重要決策，應該馬上寫進文件裡，確保未來的人知道當初為什麼這麼做，而不是憑空猜測。

文件和實作要同步

有些人可能覺得：「反正程式碼就是最好的文件，不用另外寫了。」但人月神話書中認為這是錯的，因為程式碼只能告訴你「怎麼做」，但不能解釋「為什麼這麼做」，如果沒有文件來補充說明，未來的開發者就只能猜測原本的開發意圖，這很可能會導致錯誤的修改。

所以，正確的做法是讓文件和程式同步發展，不管是新的功能還是系統的變更，都應該在文件中有清楚的紀錄，這樣未來才不會出問題。

文件不能只寫給現在的團隊

有時候，我們在寫文件時，只想著現在的團隊成員能看懂，但文件真正的價值是幫助未來的開發者，如果文件只適合現在的團隊，那一旦團隊成員更換，新人就會很難理解。

就像一本好的說明書，不管是誰來讀，都應該能快速上手，知道怎麼正確使用，軟體開發文件也是如此，應該讓未來的開發者能夠順利接手，避免重複犯過去的錯誤。

文件的價值在長期才會顯現

有些人覺得，文件看起來好像沒有什麼「立即的價值」，但是，好的文件在長期來看，能讓專案更順利，減少溝通成本，避免誤解與錯誤。

舉個例子，假設你玩一款很複雜的遊戲，如果有完整的攻略手冊，你可以很快理解遊戲機制，不需要自己慢慢摸索，同樣的，好的文件能讓開發團隊快速理解專案，少走很多彎路。

假設第一個版本就是要被丟棄的

這個概念聽起來有點奇怪，為什麼要花時間做出來的東西，最後卻要丟掉呢？

當一個團隊開始開發一個新系統時，他們對於這個系統的需求、技術挑戰、使用者需求等，通常還不是完全清楚，所以，第一個版本，其實是在試驗和探索，等到這個版本做出來之後，開發團隊才會真正理解整個系統的架構、技術上的困難，以及如何做得更好。

這也就是為什麼我，從來不買第一版的硬體；而你買回家的「軟體」一啟動就會叫你更新，因為，它就是在「趕出貨」。

這個概念對於產品經理來說特別重要，因為在產品開發的過程中，我們常常會遇到需求變更、市場環境改變，甚至是技術上的挑戰。如果我們太過執著於第一個版本，可能會導致整個產品變得臃腫、不靈活，甚至無法滿足使用者需求。但如果我們能夠接受「第一個版本只是學習的過程」，那麼我們就可以更靈活地調整產品設計，確保最終的產品能夠真正解決用戶的問題。

開發人員越多，溝通變得越困難

軟體開發不只是把很多零件拼湊在一起，還要確保它們能順利運作，如果不同團隊負責不同模組，但沒有良好的規劃與溝通，最後就可能變成一堆無法運作的零件，像是拼圖拼不起來一樣。

要讓軟體的各部分能順利合作，關鍵在於「串接的設計」，這就像是不同模組的溝通方式，如果沒有明確的標準，就容易發生對不上的情況。就像蓋房子時，窗戶的尺寸如果沒標準，窗框可能會裝不上去。因此，標準化文件和清楚的設計規範是必要的，這樣每個人都能按照相同的規則開發，避免出錯。

此外，軟體開發時，不能等到所有模組都寫完才開始整合，而應該「逐步測試和組裝」，這樣可以提早發現問題，避免到最後才發現拼不起來。

軟體專案的失敗往往是一步步發生的

這不是突然爆炸般的毀滅，這種失敗通常來自於許多小錯誤的累積，而這些錯誤可能一開始看起來並不嚴重，但當它們疊加在一起時，就會變成一場大災難。

關鍵路徑指的是專案中最長的那條任務鏈，這條路徑上的任何一個延遲，最終都會影響到整個專案的完工時間。簡單來說，如果有一個任務拖延了，那麼整個專案的交付時間也會被延後。但是啊問題是，很多時候我們並沒有清楚地知道關鍵路徑上的每個環節會發生什麼變數，所以當一個環節出問題時，通常會帶來一連串的影響。

另一個有趣的點是「進度報告的陷阱」，人月神話中提到，許多團隊在專案進行到一半的時候，都會覺得「現在一切進展順利」，但到了最後 10% 時，才發現原來還有許多沒有解決的問題，這其實是因為我們在評估進度時，往往只看已完成的部分，而忽略了剩下的部分可能需要更多時間。

還有一個現象叫做「最後衝刺的錯覺」，也就是當專案進入最後階段時，團隊會試圖加快速度，投入更多人力和資源，希望能夠趕上計劃。但這往往適得其反，因為加入新的人力不會讓事情變快，反而會讓原本的成員花更多時間去解釋、協調，導致開發效率下降，這和 Brooks’ Law 是一樣的：「對於一個已經延誤的專案，加入更多人力只會讓它更慢。」

開發人員不是只寫程式，還有人際關係

許多技術人員喜歡獨自解決問題，但現實是，軟體開發通常是一個團隊工作，因此，溝通和協作與技術能力同樣重要，當你遇到困難，例如：

• 需求變更：使用者的需求經常改變，這可能導致開發人員必須反覆修改設計，增加不確定性和工作量。
• 時間壓力：專案往往會有截止日期，但軟體開發的進度不容易預測，容易產生延誤。
• 溝通成本：隨著團隊規模增長，成員之間的溝通變得越來越複雜，需要有效的管理來降低誤解和資訊不對稱的問題。

這個時候軟體開發人員不只是寫程式，更是一種需要管理、溝通和適應變化的工作，要成為一個真正優秀的開發人員，除了技術能力，還需要學習如何與團隊合作，如何應對專案的不確定性，以及溝通能力。

問題會越來越多，我們要學會應對

想像一下，你和朋友要一起蓋一座超級大的積木城堡。一開始，你們覺得應該不難，因為大家都有自己的積木，各自負責不同的範圍，可是當你們開始組裝時，問題出現了。

第一個問題是：「計畫趕不上變化」。

你本來以為只要照著說明書，一步步組合，就能完成一座完美的城堡，但當你蓋到一半時，朋友忽然說：「我想加一個大樓！」另一個朋友說：「我們應該有一座大橋！」這些新的想法讓目標一直變來變去，最後變得比你原本想像的還要複雜十倍，這就像是軟體開發中的「需求變更」，本來說好的功能，後來可能需要改來改去，讓整個專案變得更難完成。

第二個問題是：「時間不夠用」。

你們發現，雖然大家都很努力蓋積木，但比預期完成的時間還要慢，為了加速，你決定讓更多朋友來幫忙，但結果反而更糟，因為大家需要花時間跟新來的朋友解釋要怎麼蓋城堡才對，所以，溝通變得更慢，反而沒有加快進度。這就像前文所說的：「幫延誤的專案增加人力，只會讓它更慢。」

第三個問題是：「技術債」。

你開始發現有些積木的顏色不對，有些蓋的方式不穩，但你又想快點完成，所以先將錯就錯，想說以後再來修正換積木，可是問題是，當你的城堡越蓋越大，要修正那些錯誤變得更難，甚至可能會影響到整座城堡的結構，這就像軟體開發中的「技術債」，當一開始沒有把東西做好，未來的維護就會變得超級困難。

第四個問題是：「人類的能力是有限的」。

你和朋友已經蓋了一整天的積木，大家都累了，但城堡還沒完工，但這時候，居然有人開始隨便塞積木，有人開始偷懶，有人乾脆說：「我們放棄吧！」這其實就是人月神話想講的：「我們總是希望自己能做得比實際可能的還多，但實際上我們有體力和思考是有極限的，不能無止境地要求自己或團隊做到不可能的事情。」

關於人月神話這本書的心得

做軟體不像用積蓋城堡那麼簡單，而是像蓋一座會一直長大的城市，你不能只想著短期內完成，還要考慮長期維護、變化和人力的極限，這樣才能做出真正好用的產品。

人月神話這書的常見問題

要深入了解產品經理的基本職責和角色，請參考我們的詳細指南：產品經理是什麼？