在前公司做項目時因緣際會下接觸salesforce，由於要在短時間內了解基本知識，於是透過trailhead自學，也養成了每個月花個半天左右完成quest的習慣，就這樣持續了快兩年，達成最高階all star ranger的同時也免費拿到一件hoodie及4雙襪子～

簡介：本書是經典軟體專案管理書籍，特別是對於大型、複雜專案的管理提供了深刻的見解。書中的內容來自作者在IBM System/360系列電腦以及其搭配的大型操作系統OS/360專案中的實際經驗，為軟體開發者和專案管理者提供了寶貴的教訓和建議。書中的觀點Brooks法則：增加人手只會讓專案更加落後，作者指出當軟體專案進度延遲時，加入更多人手並不會加快進度，反而會因為工作重新切分、團隊溝通和新進人員的訓練而增加複雜性，進一步拖慢專案進度。本書強調，良好的時程規劃對於軟體專案的成功至關重要，提出了一個經典的專案時間分配模式：1/3的時間用於規劃、1/6用於寫程式、1/4用於組件測試、1/4用於系統測試，提醒管理者必須謹慎分配和預估各階段所需的時間。此外，書中還探討了軟體開發的四大特質：複雜性、配合性、易變性和隱匿性，並提出應對這些挑戰的方法，如自上而下的設計、結構化程式設計、規格審查等。本書揭示了軟體開發中的許多原則，即使技術不斷進步，書中的理念仍具有高度的適用性，對軟體專案管理和開發具有持久的啟發性。

心得：在閱讀本書後，深刻認同書中討論的許多觀點，特別是在軟體專案管理和系統設計中的經典理論。作為軟體開發者和專案經理打交道，隨著工作經驗的慢慢累積，愈發體會到本書中的智慧，強調人際和管理問題依然是每個專案的核心挑戰。書中提到的系統設計的概念整體性對於任何專案都是至關重要的。在之前的一個小型軟體專案中體現得淋漓盡致。我們需要設計一個輕量的後台管理系統，團隊成員各自負責不同的模組，若不保持整體設計的一致性，會導致每個模組的接口和風格不統一，進而增加後期整合的困難。主管採用專制設計方法，讓架構師確保整體設計的統一性，而每個開發者在具體實現上有自由發揮的空間，這樣既保證了系統的整體性，又讓開發者在實作過程中充分發揮，這種方法不僅提高了專案的協作效率，也減少了因溝通不良而產生的錯誤和返工。

本書強調重用既有的軟體模組，這點對於小型專案尤為重要。許多時候，開發新功能時我們並不需要從零開始，而是可以重用現有的解決方案，我在專案中採用了多個開源庫，而不是自己編寫，這樣的重用不僅節省了開發時間，也提高了系統的穩定性和可靠性。這也與作者提到的「以現成模組提高生產力」的觀點不謀而合，隨著開源與ai生態系統的日益成熟，熟悉並善用這些工具已成為軟體開發中的一個關鍵優勢。我也切身體會到書中提到的人月迷思。在一個進度落後的專案中，增加人手往往不僅無法解決問題，反而會拖慢進度。在另一個進度延遲的專案中曾犯過這樣的錯誤：為了加快進度，臨時增加了兩名新成員。然而，這導致原有團隊不得不花更多時間去訓練新人和協調工作，最終不僅沒有提升生產力，反而讓專案更加延遲，專案的成敗不僅取決於人數，而是團隊的協作效率和任務切分的合理性。當需要提高效率時，優化現有流程和工具，避免不必要的溝通障礙，是更有效的方法。

在實務經驗中，發現書中提到的時程規劃原則蠻實用的。特別是關於測試時間的規劃，我曾低估測試的重要性，在編寫程式時分配過多時間，導致測試時間不足，造成了些問題差點無法在交付前解決。經過這次教訓，我現在更重視在專案初期就制定合理的測試計劃，並確保系統從早期階段開始就進行測試。書中提到的外科手術團隊理念，在小型專案中也很適用，每個專案都應有明確的決策者，而不是讓每個人都參與每個決策。這樣既能保持專案的決策速度，也能讓每個人各司其職，在專案中採用了這種模式，由一名技術負責人統一決策，團隊其他成員專注於各自的工作，這有效地減少了不必要的討論，專案的進展也更加順暢。保持組織的靈活性也至關重要，軟體專案會隨著需求變化和技術進步不斷調整，因此組織結構必須具有彈性，以應對這些變化，每次專案變更後，能夠快速調整團隊結構和分工，這樣可以保持專案的動力和效率。本書提供了軟體專案管理的深刻洞見，這些原則在參與的專案中得到了驗證，無論是保持概念整體性、合理分配人力資源，還是重視時程規劃與測試，這些經驗法則都在現代軟體開發中具有重要指導意義，對於任何與軟體開發相關的工作者來說，這本書的智慧依然歷久彌新。

1. 時程預估：1/3規劃、1/6寫程式、1/4組件測試、1/4系統測試。
2. 在一個時程已經落後的軟體專案中增加人手，只會讓它更加落後。
3. 欲增加人手，必須付出三個代價：工作重新切分本身所造成的混亂與額外工作量、新進人員的訓練、新增加的相互交流。
4. 把工作切分給更多人造成的額外溝通代價：訓練和相互的交流。
5. 軟體專案不順利的大部分肇因於缺乏良好的時程規劃。
6. 資料呈現的方式是程式設計的本質。
7. 把必然的一次失敗納入正式計畫之中。
8. 避免發生錯誤的方法：做好定義以防止誤解、規格審查、由上而下的設計方式、結構化程式設計 文件：為使用者而寫（目的、環境、輸入輸出值域、演算法、輸出入各式、執行過程指示、執行時間、選項、輸出結果精確度與檢驗方式）；為建立對程式的信心而寫（主案例、罕見合法案例、罕見不合法案例）；為修改程式而寫（流程圖、完整描述的演算法及運用到的檔案設計說明）。
9. 軟體系統的特質：複雜性、配合性、易變性、隱匿性 軟體的創作包括本質性和附屬性工作。

書名：人月神話：軟體專案管理之道（20週年紀念版）
作者：Frederick P. Brooks, Jr.
出版：經濟新潮社