花了很多天終於看完了著名的專案管理聖經─『人月神話』
在此整理一下大致的重點
1. 開發一個軟體系統產品要付出的代價是一般組件程式的九倍。因為產品化是一般組件程式的三倍時間，設計整合測試又是三倍時間，這兩方面的成本計算基本上是獨立的。
2. 以成本會計為基礎的時程預估方式，使我們誤把工作量和專案進度混為一談，人月是一個危險並容易遭到誤解的迷思，因為他假設人力和工時可以互換。
在此本書裡面，提到，專案管理人員不應該把人/月這樣的標準來做為專案規劃的標準，因為當人員多起來後，整個專案的運行會需要花更多的時間在溝通、管理、協調上，人月之間的關係並非線性關係。
並且勿忽略掉新的程式師要學習上手的開發時間，以及要耗費掉的老手的教育時間。因此，在一個已經延遲的專案中增加人手，只會讓它更加的落後，這邊較建議的方式是重新安排時程、或者刪減工作。
在這一章裡，也提出建議的專案軟體時程安排方法
1/3 規劃
1/6寫程式
1/4組件測試和早期系統測試
1/4系統測試和完成所有的組件
3. 從第三章到第七章，都是在討論保有『整體概念性』的重要。
一個專案的規劃必需出由同一人之手，也就是說，一個專案不應該有兩個領導者。
我們必須選出一個能力強的人，來帶領整個專案的開發及方向，我們寧可忽略掉一些可能新奇、或很棒的想法，也必須讓整個專案都能呈現同一個設計理念。此一概念便是這本書所一直提及的整體概念性。
在第三章裡，此本書提出了一個外科手術團隊的做法，來解釋該如何去達到這個整體概念性的目的。
(1) 首席程式設計師：也就是整體概念性裡所提到的做決策的主腦。負責定義功能、設計程式、測試程式並撰寫文件。
ps: 此本書也提到，真正優秀的專案管理人員，也應該要寫程式，沒有真正去撰寫一些程式的PM，是無法做好專案管理的工作的。
(2) 副手：外科醫生的分身，可以做所有首席設計師所做的事，或提出想法，但是首席設計師不一定要接納他的想法。
(3) 行政助理：幫忙處理首席程式設計師的所有庶務。一位行政助理可同時處理兩個以上團隊的工作。
(4) 文件撰寫人員、秘書(負責專案協調事宜及產品無關文件)、程式助理、測試員、語言專家、工具專家。
4. 第五章的地方，提到了第二系統效應，這個效應是指說，最容易失敗的專案，反而是我們第二個設計的系統，原因是加入了太多不相關功能。我們要慎防在設計第二個系統的時候過度設計(自律)。
5. 第六章在說意念的傳達，設計必須出於同一人之手，那些有規範那些沒有應定義清楚。溝通方式包括：將定義(指規格書裡的定義)直接融入實作、開會(分為每週召開的會議、和公開大會，討論一些重大議題及無法預見的瑣碎事項)、多重實作(當規格與程式衝突時兩方都有可能要更改)、電話紀錄(現在可用email)、產品測試(專案經理最好的朋友)
6. 在第七章探討了巴別塔失敗的原因
(1) 充分的溝通十分重要
(2) 工作手冊的結構十分的重要，且每一位成員都應看到全部的文件內容
(3) 專案管理的權力結構應該要是樹狀的，也就是第三章所講的整體概念性，任何人都不能同時聽命於兩個老闆。而組織內的溝通結構則應該是網狀的
7. 第八章是在討論專案時程預估要注意的點
(1) 員工只有50%的時間真正在寫程式
(2) 溝通時間應要納入估算
(3) 開發程式的類型不同以及大小之間的關係必須算進去。專案大小及費力程度大概是1.5的指數關係
8. 必須做好整體空間規劃，不單包括常駐空間的、背後有連帶關係的動作也應納入考量(ex: 記憶體分頁錯亂)
方法1. 確保大家的本事是真正通過程式設計的訓練而來
方法2.認知組件是去創造才有，每個專案都應有個手冊是專門蒐集關於佇列、搜尋、堆疊、雜湊(hashing)、Sorting的副程式且要有兩套方法，一個是用的空間最少的、一個是速度最快的。
9. 規劃軟體開發的文件：目標、產品規格、時程、預算、場地配置、組織編製圖
10. 把一次必然的失敗納入正式計劃之中(失敗是成功之母)
(1) 表格驅動技術：將設定值寫在表格檔案之中
(2) 軟體開發十分容易面臨無窮無盡的改變，因此 將改變量化，使組織利於改變
(3) 軟體測試在維護時期要用更多的資源(要做迴歸測試)，也會需要進一步、退兩步，任何修改都有可能會破壞掉原有的軟體結構。
11. 第十二章在講開發工具的重要性，通常我們開發時的工具機器和最後程式要跑的目標機器是不一樣的，因此我們需要採用成熟的機器避免偶爾出現/偶爾正常的問題被忽略。程式語言的選擇也是工具的選擇之一，在這邊提到採用高階語言可以大量提高生產力。
12. 在專案開發中要如何避免錯誤的發生呢?在第十三章的地方提到了幾點重點
(1) 整體概念性的具備：也就是不同開發人員做出了彼此不協調的假設，具備了整體概念性的軟體容易使用、易於開發、也比較不容易發生錯誤。
(2) 規格審查：規格書應交給獨立的測試小組進行審查，而不應該給程式設計人員去審查
(3) 由上而下的設計方式：這是一種持續細分精製的步驟，先勾勒出粗略的工作定義和執行方案以得到主要的結果，然後做更深入的探討，看看跟我們真正要的東西有何不同。也就是把大步驟細分成幾個更小的步驟。
(4) 結構化程式設計：由Dijkstra所提出的最短路徑方式，在說由某一節點到另一個結點的最短路徑。
13. 要如何避免大災難的發生，有以下幾點：
(1) 里程碑應要明確、不模陵良可，要明顯到無法讓人自己騙自己，可以輕易查證
(2) 團隊應充滿幹勁，我們亦可提出計劃評核圖(PERT chart)或要徑時程表(critical-path schedule)來顯示什麼做完才可以做什，並告訴我們什麼事情是重要的需要先做
PERT chart
a：最樂觀時間 (Optimistic Time)為最短時間
m：最可能時間 (Most Likely Time)為適中時間
b：最悲觀時間 (Pessimistic Time)為最長時間
要徑的概念：通過網路最長的路徑，稱為要徑。若最長路徑的作業延遲了，整個專案就延遲，若要縮短專案完成時間，只要縮短要徑作業的工期即可。要完成專案，所有的路徑都必須通過。
(3) 避免隱匿不報的狀況發生：為了避免下面的人明知專案延遲卻不往上報的狀況，在組織上應降低角色衝突(老闆不應干涉部屬可以自己解決的問題)，並且訂定一些審查技巧。
