團隊合作可以增進軟體開發的生產力，運用分工來簡化工作，可以減少每位成員必須負責的工作量，而使工期縮短。但軟體工程界有名的「布魯克斯定律」卻告訴我們，在專案後期增加人手，反而會更加拖延專案工作的完成時間。
這是因為要為增加的人手分工，會增加正在進行開發工作的人員的溝通成本，反而會拖慢他們的工作進度。這是「人月迷思」的弔詭，不明其理的人會以為增加人力、或工時就可以彌補落後的進度，卻忽略軟體的團隊合作不只是分工，還需要考慮成員之間的合作，反而只會讓團隊陷入「焦油坑」當中而難以脫身。
同人前一陣子正好看到只曉得分工而不去思考合作的謬誤，長官指責我沒有指派下階段目標的任務交給新來的程式設計人員，但問題是還沒有系統分析人員交付下階段目標可供開發的程式規格。
據同人的了解，目前大部分的系統分析人員都忙於現階段目標系統的測試和程式規格的修正，應該還沒有人有空提供可實作程式的規格讓程式設計人員開發。有系統分析人員承諾下週會有可實作的共用元件規格產出，我原先的計劃是先讓新人在當週建立可用開發環境及了解程式開發的架構，這樣就可以讓他在下週開始進行共用元件的開發。
但長官認為我應該向系統分析人員索取下階段目標的程式規格，立即讓新人員著手進行開發，但同人認為系統分析人員現階段的工作就應接不暇，根本不會有空理我，而且他們又不是歸我管。長官和同人僵持不下，後來他請專案經理來協調紛爭。專案經理找來所有的系統分析人員，要求他們加班把下階段目標的程式規格提前產出，然後再交由同人指派給新人以進行開發。
故事發展至此，同人認為問題沒有被解決，只是我不想再爭論。尤其是對於軟體工程沒有正確觀念的管理階層，多說其實無濟於事。有位系統分析人員私下提到，他懷疑專案經理是否真的做過軟體專案，不然怎麼會向她解釋了那麼多，她還是不能了解系統分析人員真正碰到的問題所在。
同人觀察到專案經理所做的只不過是把工作分派下去，以為只要成員加班就能解決時程緊迫的問題，卻不知道加班很可能無濟於事，而是應該從團隊整體架構的角度來思考分工。其實用生產一般產品的生產線思維來看軟體開發是有問題的，因為軟體開發的不確定因素很高，任何一個環節的變化都可能會衝擊整體開發成果。往往在開發過程中，開發團隊付出了時間，投入了資源，但所獲得的卻不是有意義的產出。例如低落的士氣、缺乏成就感、或是溝通不良。
通常這些現象是團隊強調分工卻欠缺合作方面的考量，導致在開發過程中迷失方向。分工是專注在局部觀點的最佳策略，但沒有考慮合作，將會對達到專案整體目的有不良的影響。
例如面對時間急迫，增加更多程式開發的人手可以提昇生產力以縮短開發工期。以局部的觀點來看，似乎是面對問題的最佳處理方式。但考慮到整體的觀點，增加的程式開發人員會增加系統分析人員的工作量，不論是在現階段任務未完成就要進行下階段需求的分析和設計，以供程式開發的新人進行程式實作、或是要跟新人溝通程式實作過程碰到需求或設計的問題，就會影響他們現階段正在進行的工作，結果更拖延了工作，反而讓問題像滾雪球一樣的愈滾愈大。
就像同人在下面畫的系統思考圖，所謂「事件造成結構，結構造就行為」，期望用增加人手的「症狀解」來解決開發時間或人力不足的問題，這種行為只是讓人更深陷在「捨本逐末」結構的泥淖之中而無法自拔。
軟體專案的管理者應該注意，造就行為模式的結構一旦產生，人人都做自己以為正確的事，實際上卻造成完全相反的結果。這時候要領導專案團隊的正確方向，需要系統化思考，才能認清結構，以打破錯誤的行為模式。分工的迷思會讓管理者建樹不見林而沒有把穩方向。鄭炳強教授說過軟體開發有四大困難，亦即「溝通的困難、問題本質的困難、整合的困難、以及團隊合作的困難」，當我們思考「電腦對人腦、問題對答案、程式對系統、個人對團隊」時，如果單純的以為團隊合作就只是分工的話，那誤會可就大了。
管理者必須以系統的角度來看整個軟體開發過程，而不是巨細彌遺的微觀管理。管理者的責任是排除成員工作整合的障礙，而不是把責任推卸在成員身上，又在整合失靈的時候暴跳如雷，那只是顯示自己管理的無能而拖累團隊。因為「沒有不會作戰的士兵，而只有不會帶兵的將領」呀。
