原因在於，有些任務是無法分解的，存在先後順序。無法同步進行。
增加人手，增加的是溝通成本，相互牽制。可以分解的任務就可以通過增加人手來加快速度。但是不能分解的任務，增加人手只會增加開發時長。打個通俗比方，懷孕需要12個月，增加人手，也不能加快時間。
作者讚賞的是，小型精幹的技術團隊是最好的。溝通成本低，開發效率高。
廚師煎一個蛋，需要5分鐘，而顧客期望2分鐘。怎麼都達不到，2分鐘的辦法是，把火開大可以快速點（類似於軟體加班，多投入人），蛋會燒掉。
已經延期的專案增加人手，會更加延期。分配任務，培訓新成員的成本。
這方面的坑，前人遇到過了。
困難的預估不足。這是我們的問題。
做專案，任務的評估時間忽視了軟體開發的特點，我們往往憑著直覺來評估週期。增加人手不能解決問題。
我們自己做的時候，不會這樣。等到位置變了，就想當然了。
這本書裡面提到一個經驗，除錯和測試的時間花費是最多的。比開發寫程式碼要多得多。
現在看來是這樣，有時候為一個bug，除錯，定位問題，耗費長時間。
建立一個組織架構，不要強調頭銜。
具體的辦法為：
1，叫負責人，而不是叫總監。叫法會造成心理的隔閡。負責人強調的是身上的責任和擔子。將會促使人去幹實事。
2，提供技術和管理兩條發展路線。級別要一樣，不應該有待遇差別。辦公室的位置要一樣，不要刻意顯示地位差別。否則，技術人員都擠著想做管理(不安心鑽研技術，因為級別和待遇低)，而管理人員則顯得自己地位的差別，技術人員的話語權就低了。
管理能獲得更好的待遇（薪資、受尊重程度，各種權利和榮譽）。那麼管理將會務虛不務實了。
3，技術人員向管理的轉換，要以調動的名義，而不要以晉升的名義。這種調動時，待遇不要跟著變化，而應該不要變。
作者觀點是：
對於一個廣泛使用的程式，維護成本是開發成本的40%甚至更多。而且據發現，系統的使用者數越多，發現的錯誤越多（我們想想windows常年打補丁進行更新）。
為什麼會這樣？使用者數多，他們熟練使用舊功能後，就會使用新功能。於是就會發現新功能那些不容易察覺的問題。
修復bug，往往會引入新的bug。經常出現這樣現象：前進兩步（修復和完善兩個地方），後退一步（引入一個新的缺陷）。
讀到這個觀點，程式設計師是不是深有共鳴？
我想，更關心的是如何解決這個問題？
……………………書中籠統而過解釋了一下
為什麼缺陷不能更徹底地被修復？首先，看上去很輕微的錯誤，似乎僅僅是區域性操作上的失敗，實際上卻是系統級別的問題，通常這不是很明顯。修復區域性問題的工作量很清晰，並且往往不大。但是，更大範圍的修復工作常常會被忽視，除非軟體結構很簡單，或者文件書寫得非常詳細。
其次，維護人員常常不是編寫程式碼的開發人員，而是一些初級程式設計師或者新手。
作為引入新 bug 的一個後果，程式每條語句的維護需要的系統測試比其他程式設計要多。
理論上，在每次修復之後，必須重新執行先前所有的測試用例，從而確保系統不會以更隱蔽的方式被破壞。實際情況中，迴歸測試必須接近上述理想狀況，所以它的成本非常高。
顯然，使用能消除、至少是能指明副作用的程式設計方法，會在維護成本上有很大的回報。同樣，設計實現的人員越少、介面越少，產生的錯誤也就越少。
……………………
作者已經幫我們歸納原因了，那麼我們可以根據原因，依據自己專案中實際情況做改進。
原因：
1，修改系統的人不熟悉原來的系統。比如他是系統的新手。比如系統的維護人員，由於他並不是之前開發這個系統（功能）的人員，於是不熟悉系統，修改就會造成麻煩。
不熟悉，改了具備後會影響到哪個環節。
2，缺少評估修改系統後，產生的影響。大系統，修改功能，評估時間做足夠點，重點不要放在評估開發時間上，放在修改區域性造成哪些方面會影響。不要走形式。
3，系統缺乏必要的文件說明。造成接手的技術不知道來龍去脈，那麼為了應付上級任務催促，就只能先改好再說，但是改了後出現問題了。
歸納對策
1、減少開發系統人員的波動。現實中這的確比較難，實際上根源並不是人員波動(因為人員不波動是理想狀態而已)，而是人員波動後造成的銜接故障問題。只要解決這個根本性問題即可。一個國家主席會有任期，沒有不散的筵席。怎麼保證國家政權的平穩過渡，有選舉制度，按流程走。
2 、詳細的文件，避免混亂。古代的經驗，今天的人怎麼繼承的。靠的是古人的文字記載。
作者的觀點：
傑出的設計人員應該與傑出的管理人員一樣重要，受到的回報要一樣，不僅僅是薪資待遇，要在認可方面一樣：辦公室規模、安排、人員支援等方面。這樣才會有更多回報。
良好的設計人員和卓越的管理人員都是稀缺的。卓越的管理人員，絕不會比良好的設計人員更加迫切。
之所以那麼重管理，那是傳統的工廠活，因為是機械式的幹活，不需要很強的創造力。而當面對高階人才的時候，這些高階人才往往是自我驅動型，對他們的管太多會造成情緒不爽的。
如何解釋小型團隊帶來的好處。
維護系統比開發系統的成本更高。如何才能做到這樣。
有些開發任務是沒法拆分的，拆分後，反而效率不高。需要投入溝通時間，培訓成員的時間。
這本書提出一個觀點，成員多交流，定期交流，這樣才能知道需求有沒有偏差。
作者建議的幾種搭配：
產品經理和技術總監是同一人。
產品總監總指揮，技術總監當其左右手。
技術總監總負責，產品經理做左右手。
為什麼要這樣子設計呢？好處是什麼呢？
知道正確的辦法。很多事情要回報。
老闆的目標，如何培養人才，使得技術和管理人員可以互換。
提供兩條晉升路線的辦法，為什麼存在一些社會性障礙。
為技術和管理人員建立相同薪資容易，建立相同的威信則需要很多措施。
專案經理的職責之一就是協調大家按照一致的方向前進。他的重要不是做在決策，而是溝通，溝通使得大家保持一致方向。
文件是作為溝通的渠道，讓大家想法達成一致。文件減輕了溝通障礙。
只
有以文件記錄下來，大家的分歧才會明朗，矛盾才會突出。因為文件往往是精確的，可以溝通的(相比口頭語而言)。這裡文件有個細化到什麼程度的問題：什麼事
情需要文件，什麼事情不需要文件。我以為，重大或者關鍵性的決定口頭說是不準確的，溝通看起來快（相互馬上知道），但是要接地氣實施目標困難。會出現溝通
偏差，誤解，白做。
達到無為而治的情況。
的確是屁股決定腦袋