團隊的開發人員撇開需求沉浸在想象中的“完美”程序中；測試人員迷茫的點擊著按鈕試圖搞明白這到底是個什么功能；設計師造出了沒有盡頭的樓梯，更糟的是，客戶愛上了這個設計；團隊領導四處救火，力有不逮。種種跡象表明，我們得打破分工帶來的壁壘，建設全功能團隊——大多數人能完成大多數種類工作的團隊。
百度技術沙龍第十期報名：Web App開發與應用暨2011年技術趨勢展望
在一次閑聊中，女友的母親說起實習大夫必須輪崗一年才會進行分科學習，我質疑道：“對于致力于心臟病治療的醫生來說，他豈不是在不相干的學習上浪費了一年時間么？”，她母親笑著說：“不這么作，你怎么確信病人的確患有心臟病呢？”。不知道為什么，我眼前突然浮現出這樣的場景?測試人員在怯生生的詢問：“這是一個缺陷么（而不是操作系統/瀏覽器的限制）？”。
亞當·斯密于1973年在描述大頭針工廠的專業化生產時提出了社會分工的好處：提高熟練程度、減少任務切換時的開銷、便于機器的應用。我們似乎可以非常自然得推導出重復設計、重復編碼、重復測試可以增加相應崗位員工技術熟練度，提升效率，并由此提升企業的盈利能力。
然而市場的不斷變化讓重復生產的美夢不在，切換任務變得越來越頻繁。IT公司不是大頭針工廠，知識工作者畢竟有別與體力勞動者，在勞動主體發生變化的過程中有兩件事情的差異被放大了：一是局部優化與整體優化的差異，二是正確的做事與做作正確的事情的差異。
有一道數學題，假設每個開發人員每天可以完成一個功能，測試人員每天可以測試2個功能，團隊由3名開發人員和1名測試人員組成，那么一周內通過測試的功能多為多少個？
大多數人的第一反應是5（天）x2（功能/天）=10功能，下面的表格會告訴你，由于負載不均衡，測試人員在周一沒有功能可測，團隊其實無法在一周內交付10個功能。
| 周一 | 周二 | 周三 | 周四 | 周五 | 總計 | |
| 開發人員 | 3功能 | 3功能 | 3功能 | 3功能 | 3功能 | 15個功能 |
| 測試人員 | 0功能 | 2功能 | 2功能 | 2功能 | 2功能 | 8個功能 |
表一）
那么我們改變一下條件，假設團隊中有4個開發人員，并且開發人員可以參與測試，結果會怎樣呢？
| 周一 | 周二 | 周三 | 周四 | 周五 | 總計 | |
| 開發人員 | 4功能 | 4功能 | 3功能 | 2功能 | 0功能 | 13個功能 |
| 測試人員 | 0功能 | 0功能 | 2功能 | 4功能 | 8功能 | 14個功能 |
表二）
我們終能夠交付13點，產量提高了60%， 如果我們只留下三名全能人員：
| 周一 | 周二 | 周三 | 周四 | 周五 | 總計 | |
| 開發人員 | 3功能 | 3功能 | 3功能 | 1功能 | 0功能 | 10個功能 |
| 測試人員 | 0功能 | 0功能 | 0功能 | 4功能 | 6功能 | 10個功能 |
表三）
居然比3個開發人員和1個測試的人員組合還多交付兩個功能！
我們當然有理由質疑第二題的假設：“開發人員可以勝任測試人員的職位”。又或者繼續討論迭代二的數據變化。我對此的的回答是：
第一，以我的觀察來看開發人員之所以不進行測試工作，不是能力不允許，而是主觀上認為測試工作是簡單、重復而枯燥的，不愿意作。客觀上開發人員們比較貴也更難于培養，組織層面不允許這樣的“浪費”。
對測試工作的偏見客觀上促成了大量不具備技術能力的人選擇測試工程師作為職業，而技能不足則一步導致了測試工作傾向于簡單重復。測試人員在很大程度上無法判斷什么是正確的事情（作正確的事），從而更傾向于熟練的按照腳本進行操作（正確的做事）。
第二，我的關注點不在交付8點還是10點，我希望這個例子能夠引發大家對于均衡生產的思考。
軟件的需求和實現可以被細化，但它畢竟不是大頭針，需求和實現間往往呈現出關聯與依賴，換言之，局部效率的增加無法直接轉換為整體效率的增加。而整體效率的優化往往依賴于均衡生產（參考表三），即消除生產的波峰(過度生產)和波谷（生產不足），避免任務時松時緊，松時生產力浪費（周一時專職測試人員），緊時加班加點，粗制濫造。
