我們已經習慣了用“人月”這個工作量單位來預估工期和估算成本。在軟件工程中，用人月來估算，似乎很合理。因為如果用其他量來估算，要麼無法量度，要麼適用面太窄。比如你告訴客戶“做完這個活需要一年”，人家很可能想“你都沒告訴我幾個人做，就出來一年的工期了”，顯然讓別人覺得你是一副很業餘的樣子，不合適。但是，用人月來潤色談話，那就不一樣了，對著別人張嘴說出來“我初步估計要完成這個工作需要20人月”，客戶第一次聽到基本不會懂，就顯得自己很專業、很不同。
但以人月為工期的計量單位，是非常危險的一件事情，是一個帶有欺騙性的神話。它在無時無刻不在暗示著你，時間和投入的人員數量是成正比的，這簡直不能用糟糕來形容。領導嘴中說出的每一個帶有人月的詞，都可能準確撩到程序員的痛點上。
大家正常的思維都是這樣的，舉個栗子：老漢我今年種了10畝小麥，僱一個人收麥子，一天收1畝，需要10天；那麼我乾脆僱傭10個人，一天就收完了，真好。根據這個人類淬鍊了幾千年的經驗，軟件工程肯定也是這樣，老總我今年承包了一個項目共需要10人月幹完，僱一個程序員，十個月完成；那麼幹脆我僱傭10個人，一個月就完成了，真香。這個例子中，如果一個項目工作分成的10份，相互之間不需要協助和從屬，那麼這麼想完全沒毛病。遺憾的是，這種事越來越難以發生了。
現在的項目，已經嚴重依賴於配合和溝通；產品等著銷售、設計等著產品需求、研發等著產品需求和設計、測試等著研發……，而且研發和產品還有很多功課要撕；測試和研發還有很多疑點要爭；相安無事，各幹各的，幾乎不存在的。
軟件開發的本質是一項精密合作的系統工作，擁有錯綜複雜的關係，溝通、交流的工作量十分之大，大到輕易能消耗掉技能熟練度所節省下來的個人時間。對於增加的人手，首先，你要先讓新加入的人瞭解和熟悉已經做了的工作，每進來一個，都要重新進行一遍這個過程。然後，本來的一個任務被拆成了多個，協作的工作量以n(n-1)/2的速度遞增（就是渠道的個數）。也就是說，一對一交流的情況下，三個人的工作量是兩個人的三倍，四個人的是兩個人的六倍。這就產生了這樣的場景：某天某個程序員幽怨的告訴你“還不如我一個人幹這個活快呢”。
更何況，很多人對人月的概念，就是知道了這個概念，僅此而已。至於多一點深入的思考，也是太費腦子的事情，比如一人月等於多少人天？為什麼要去想它呢。於是產生了這樣的場景：“給你加人了，怎麼還這麼慢”，“怎麼又要人”……
更不要提關鍵路徑，活動時間，資源平滑；我們知道的趕工的方式永遠都只有一種——加班！
閱讀更多 靜靜水流 的文章
