團隊的開發(fā)人員撇開需求沉浸在想象中的“完美”程序中；測試人員迷茫的點擊著按鈕試圖搞明白這到底是個什么功能；設(shè)計師造出了沒有盡頭的樓梯，更糟的是，客戶愛上了這個設(shè)計；團隊領(lǐng)導(dǎo)四處救火，力有不逮。種種跡象表明，我們得打破分工帶來的壁壘，建設(shè)全功能團隊——大多數(shù)人能完成大多數(shù)種類工作的團隊。

百度技術(shù)沙龍第十期報名：Web App開發(fā)與應(yīng)用暨2011年技術(shù)趨勢展望
在一次閑聊中，女友的母親說起實習(xí)大夫必須輪崗一年才會進行分科學(xué)習(xí)，我質(zhì)疑道：“對于致力于心臟病治療的醫(yī)生來說，他豈不是在不相干的學(xué)習(xí)上浪費了一年時間么？”，她母親笑著說：“不這么作，你怎么確信病人的確患有心臟病呢？”。不知道為什么，我眼前突然浮現(xiàn)出這樣的場景?測試人員在怯生生的詢問：“這是一個缺陷么（而不是操作系統(tǒng)/瀏覽器的限制）？”。

亞當·斯密于1973年在描述大頭針工廠的專業(yè)化生產(chǎn)時提出了社會分工的好處：提高熟練程度、減少任務(wù)切換時的開銷、便于機器的應(yīng)用。我們似乎可以非常自然得推導(dǎo)出重復(fù)設(shè)計、重復(fù)編碼、重復(fù)測試可以增加相應(yīng)崗位員工技術(shù)熟練度，提升效率，并由此提升企業(yè)的盈利能力。

然而市場的不斷變化讓重復(fù)生產(chǎn)的美夢不在，切換任務(wù)變得越來越頻繁。IT公司不是大頭針工廠，知識工作者畢竟有別與體力勞動者，在勞動主體發(fā)生變化的過程中有兩件事情的差異被放大了：一是局部優(yōu)化與整體優(yōu)化的差異，二是正確的做事與做作正確的事情的差異。

有一道數(shù)學(xué)題，假設(shè)每個開發(fā)人員每天可以完成一個功能，測試人員每天可以測試2個功能，團隊由3名開發(fā)人員和1名測試人員組成，那么一周內(nèi)通過測試的功能多為多少個？

大多數(shù)人的第一反應(yīng)是5（天）x2（功能/天）=10功能，下面的表格會告訴你，由于負載不均衡，測試人員在周一沒有功能可測，團隊其實無法在一周內(nèi)交付10個功能。

表一）

那么我們改變一下條件，假設(shè)團隊中有4個開發(fā)人員，并且開發(fā)人員可以參與測試，結(jié)果會怎樣呢？

表二）

我們終能夠交付13點，產(chǎn)量提高了60%， 如果我們只留下三名全能人員：

表三）

居然比3個開發(fā)人員和1個測試的人員組合還多交付兩個功能！

我們當然有理由質(zhì)疑第二題的假設(shè)：“開發(fā)人員可以勝任測試人員的職位”。又或者繼續(xù)討論迭代二的數(shù)據(jù)變化。我對此的的回答是：

第一，以我的觀察來看開發(fā)人員之所以不進行測試工作，不是能力不允許，而是主觀上認為測試工作是簡單、重復(fù)而枯燥的，不愿意作�？陀^上開發(fā)人員們比較貴也更難于培養(yǎng)，組織層面不允許這樣的“浪費”。

對測試工作的偏見客觀上促成了大量不具備技術(shù)能力的人選擇測試工程師作為職業(yè)，而技能不足則一步導(dǎo)致了測試工作傾向于簡單重復(fù)。測試人員在很大程度上無法判斷什么是正確的事情（作正確的事），從而更傾向于熟練的按照腳本進行操作（正確的做事）。

第二，我的關(guān)注點不在交付8點還是10點，我希望這個例子能夠引發(fā)大家對于均衡生產(chǎn)的思考。

軟件的需求和實現(xiàn)可以被細化，但它畢竟不是大頭針，需求和實現(xiàn)間往往呈現(xiàn)出關(guān)聯(lián)與依賴，換言之，局部效率的增加無法直接轉(zhuǎn)換為整體效率的增加。而整體效率的優(yōu)化往往依賴于均衡生產(chǎn)（參考表三），即消除生產(chǎn)的波峰(過度生產(chǎn))和波谷（生產(chǎn)不足），避免任務(wù)時松時緊，松時生產(chǎn)力浪費（周一時專職測試人員），緊時加班加點，粗制濫造。