在一個時程已經落後的軟體專案中增加人手，只會讓他更加落後——人月神話
本書的第二章，章節名稱：人月神話，正是這本書的書名。這個章節能夠作為書名，代表他的重要性。
書中認為，軟體專案進行不順利的原因，大多是因為缺乏良好的時程規劃。其中最重要的觀點是，有許多專案管理者，錯把工作量跟專案進度混為一談，進而以為在時程延誤的時候，可以透過加人的方式來趕上進度。
專案進度跟工作量的關係
一個專案有固定的工作量？是的，但這是最樂觀的時候。軟體專案有太多意料外的事情可能會發生，導致工作量可能會發生變化。
我們先撇開意外不談，來看看所謂的人月 (man-month)。
人月是用來衡量工作量的單位，指的是一個人工作一個月的產出。如果說一個專案需要 6 個人月，那代表需要花一個人 6 個月的時間，才可以完成專案。
但如果是兩個人投入呢？
是不是代表只要6/2 = 3個月的時間？理想上是這樣，但現實答案通常是NO。只有在工作可以被完美切割，並且加入的人都可以獨立運作的時候，才會這麼剛好。
如果在 A 手上的東西，難以分給 B 來幫忙做，那麼就算有 B 加入了，對於整體工時也沒辦法改善，B 只能在旁邊發呆。
工作量是會被創造出來的
在軟體開發中，新的人員加入團隊，需要花一點時間了解專案內容、團隊的做法等等，很難馬上就上手，提供生產力。
在做這些事情的時候，因為都在溝通跟學習而已，專案的進度實際上是沒有前進的。換個角度來講，這代表在專案內容沒有改變的情況下，工作量被創造了。
進一步講，A 的工作雖然可以讓 B 來幫忙分擔，但 A 要花額外的時間來告訴 B 該怎麼做，在進行溝通的時候，對於專案進度是沒有幫助的。
稍微用簡單的數學來計算一下，如果原本的工作量是 10 人月，A 的開發能量是 1 人月，那這個專案就需要開發十個月。B 加入後，新增的溝通成本是 2 人月，那整體工作量會變成 12 人月，由兩個人分擔的話專案需要 6 個月來完成，而不是一開始預期的 10/2 = 5 個月。
大家可能會好奇說，雖然比預期的慢，但專案不是還是變快了嗎？
是的，但隨著人數變多，溝通成本會快速成長，2個人溝通跟4個人溝通會是完全不一樣的場景。最後這些額外的溝通成本和人多造成的混亂，累積到某個程度後，專案搞不好還變慢了。
人月神話的迷思
用人月來評估軟體工作的工作量，容易陷入一個思考上的陷阱，那就是以為人多幾倍，工作時間就會少幾倍。
但了解軟體開發的作法後，就知道這樣的迷思必須要被破除，否則管理者會做出錯誤的判斷。
個人想法
確實知識產業不像製造業，兩個人就等於兩倍生產力，難怪人家會說台灣老闆都是製造業思維。
現在也許沒有那麼遭
這本書出版的時間，已經將近50年前了，當時開發環境沒有現在成熟方便。我認為現代物件導向架構、還有網頁開發的前後端分離等等概念，已經大幅減少分工的困難度了。
各式開發框架，PHP 的 Laravel，前端的 React 、 Vue 等，這些框架統合的大家的做法，讓大家的分歧也變少了，有效的減少溝通成本。
專案時程安排
我們現在在評估工時，有時候會進行合理的灌水，例如工程師評估出來的工作時間是 1，實際給出去的數字可能會是 1.5 甚至 2。
畢竟專案本來就會有各種狀況發生，這 1.5 至 2 中間的內容，可能就包含跟其他工程師的溝通成本。
無法分割的工作
這些無法分割的工作，也許不是真的那麼無法分割。
但想像一下，一個團隊中沒有人其他懂 K8S，那負責 K8S 的工程師就要獨挑大樑，專案進度緊湊的時候，他不太可能還停下來花時間教會組員整套 K8S 的作法，這就是一種工作無法分割的狀況，就算其他人都開發完了，也還是只能等他架設環境。
對人月神話有興趣嗎？點此前往博客來購買