讀了禍起蕭牆這一章後，綜合網上其他讀者的思想，總結如下：
專案是怎樣延遲了一年的時間？---- 一次一天。
一天一天的進度落後比起重大災難，更難以識別，更不容易防範和更加難以彌補。
里程碑必須是具體的，特定的，可度量的事件，能進行清晰能定義。
如果里程碑定義得非常明確，以至於無法自欺欺人時，程式設計師很多會就里程碑的進展弄虛作假。
慢性進度偏離是士氣殺手。
進取對於傑出的軟體開發團隊，同優秀的棒球隊伍一樣，是不可缺少的必要品德。
不存在關鍵路徑進度的替代品，使人們能夠辨別計畫偏移的情況。
每個老闆同時需要採取行動的異常資訊以及用來進行分析和早期預警的狀態資料。
狀態的獲取時困難的，因為下屬經理有充分的理由不提供資訊共享。
老闆的不良反應肯定會對資訊的完全公開造成壓制；相反，仔細區分狀態報告，毫無驚慌地接受報告，決不越俎代庖，將能鼓勵誠實的匯報。
必須有評審機制，從而所有成員可以通過它了解真正的狀態。出於這個目的，里程碑的計畫和完成文件是關鍵。
對於大型專案，乙個對里程碑報告進行維護的計畫和控制小組是非常可貴的。
閱讀筆記 人月神話02
人月神話 主要討論的便是人和月之間的關係。並且怎樣處理系統開發的預估，正如作者所說 在眾多軟體專案中，缺乏合理時間進度是造成專案滯後的最重要原因。首先，我們對估算技術缺乏有效的研究。過於樂觀 第二，我們採用的估算技術隱含的假設人和月可以互換，錯誤的將進度與工作量相互混淆 第三，由於對自己的估算缺乏信...
《人月神話》閱讀筆記02
在專案完成過程中，一定要準確書寫專案工作手冊，這便利於日後的管理和維護，若工作人員對硬體或軟體的某一部分存在疑問，通過檢視工作手冊，即可快速解決問題。在講到工程專案中的管理問題時，文中提到三點建議，第一，小型專案中產品負責人和技術主管最好是同一人 第二，產品負責人作為總指揮，技術主管充當左右手的管理...
人月神話閱讀筆記02
繼續人月神話的閱讀。在書中，作者提到了關於外科手術式的隊伍。這點是我剛開始稍微有點不理解的。我們都知道，在現代的開發中，一般不會有個人開發的情況，畢竟乙個人不會將事情做得那麼全面，無論他是多麼的強大，個人能力是多麼的突出，他仍然會在一些情況下出現各種各樣的問題，所以，我們一般的都是採用的多人參與開發...