在看完《鳳凰專案》(書摘《鳳凰專案》) 後馬上就接著看《人月神話》，這一本以前還在學校時，曾從圖書館借來看一次，但那時候還是學生，對於書中很多東西沒什麼感覺，只覺得書中某句話好像很有道理：
後來上班後，對這句話的感覺完全不一樣，對書中很多東西也有感觸了，只能說很多書換個時間再看一次，常常會有不同的想法。軟體專案進行不順利的原因或許很多，但絕大部分都是缺乏良好的時程規劃所致。
這本書出版很久了，裡面很多技術或工具都很舊了，但核心的精神到現在依然很有用，例如書中討論到文件的架構、寫法與目的，雖然這幾年很多人打著 agile 不用寫文件，我依然習慣把架構或是偏整體設計面的文件寫下來，因為我自己記憶力再怎樣好，隔一陣子回頭看幾千行或幾萬行的程式碼，也會瞬間忘記這堆程式在做什麼？這時候自己寫的文件就幫上忙了。
比較意外的是這本書中提到蠻多首席設計師或是架構師的重要性，他確保系統的概念整體性，定義規格但對實作持開放讓開發者能夠發揮創意，自己的工作經驗中，第一份工作有和一位頗厲害的架構師合作過，第二份工作後來自己也當上架構師，甚至在另一家公司還曾經有過首席架構師的頭銜，但說實話，自己仍在摸索怎麼當一個好的架構師？
特別是與其他人的合作模式，在第七章看到三種常見模式特別有感覺：
- 管理者兼任技術總監，這比較沒有溝通問題，但同時擁有管理與技術天份的人其實不多，容易出現分身乏術，無暇確保概念整性。
- 管理者是老闆，技術總監是副手，這種搭配方式的困難在於如何賦予技術總監充分下達技術決策的權力。較適合大型的組織。
- 技術總監是老闆，管理者是副手，較適合小團隊。
不過，也許是我的錯覺，現在台灣的軟體公司似乎很少有在架構上考慮整體性，只在乎功能是否能兜出來，常常與特定框架或技術綁住，當使用的技術與框架不敷使用時，要轉換時才發現牽連甚廣，動彈不得。
書中的另一個焦點是專案的時程，時程這件事在開始工作後特別有感，因為光是工作量就是一個極難預估的事情，當把一個錯誤的預估除以人月就會得到一個根本不可能達成的時程，只是有趣的是，這本書出版已久，也號稱是最具影響力的專案管理經典，卻還是常看到很多公司依舊拿人月來算時程：
成本確實隨著人力與工時的乘積而變，但工作的進度可不是如此，所以用人月來衡量工作規模的大小是危險的，也是一個容易遭到誤解的迷思 (muth)，用人月的前提必須是人力與工時可以互換的情況下。
工作量難以預估的本質在第 16 章「沒有銀彈，軟體工程的本質性與附屬性工作」有很多的描述，其中一句便是：
我相信軟體開發真正的困難，是在於這種概念構造的規格制定、設計和測試，而並非孜孜矻矻在於它的呈現方式，以及測試該呈現方式的精確程度。
很多時候開發到一半，發現規格根本就不對，或是需求根本就沒有打到顧客的痛點，但花下去的工時已經要不回來了，更別說軟體的複雜性及後續的維護及修改。有趣的是，該章後半段提到的可能方法有幾個跟現在的敏捷方法所提的是相似的概念：
- 需求的提煉與快速原型製作。當今有非常多的軟體獲取程序都是基於一個假設，假設能夠預先界定出一份完善的系統規格，並以此為這項軟體專案進行喊價，然後獲准開發，直到把軟體安裝起來。我認為這個假設根本就是大錯特錯。
- 漸進式開發 — 發育軟體，而非建構軟體。
- 偉大的設計師。
在「再論沒有銀彈」一章，也提到一些我覺得很有用的：
非也，把重點放在品質上，生產力將隨之而來。
回歸到軟體的基本問題，並主張對於未能滿足軟體需求的問題，有一個方式是藉由客戶的參與，增加投入這種智能工作的成員，這樣的主張符合由上而下的設計方式。
管理者的工作並不是叫人去工作，而是去創造讓人想去工作的情境。
假如能夠小心地維持基層的自主與責任，領導中心將在微信與效能上獲益，其結果是個組織「越快樂、越欣欣向榮」
這本書看完後，挺受用的，特別是讓我想繼續往軟體架構去深研，決定下一本書要看什麼了，來看看《架構之美》。
