在軟體工程研究中，被驗證得最多的結論就是對於同等經驗的兩個不同程式設計師，在效率和質量上可能會有10倍的差距。研究人員還發現，這種差距也適用於團隊級別上，也就是說在同一行業內不同的團隊也是如此。
軟體開發中個人效率的變化
首先發現不同的人在程式設計生產力上的巨大差距的研究，是1960年由Sackman、Erikson以及Grant三個人完成的。他們研究了工作經驗平均在7年的專業程式設計師，並發現最好和最差的程式設計師寫新程式碼的時間比為20:1；除錯次數是25:1；程式大小是5:1；程式的執行效率是10:1。他們還發現，程式設計師的經驗和程式碼質量或效率並沒有關係。
在詳細地研究了Sackman、Erickson以及Grant的研究結果之後，我們可以發現他們所使用的方法中有很多缺陷，例如把使用低階程式語言和高階程式語言的程式設計師合在一起研究等。但是，即便把這些缺陷考慮進來，他們的資料也仍然表明，最好的程式設計師和最差的程式設計師之間的差距能達到10倍以上。
那次研究之後，還有很多其他關於專業程式設計師的相關研究都證明了一個結論：程式設計師的水平也分三六九等。
除些之外，很多軼事傳聞也支援這種觀點。在20世紀80年代中期，當我還在波音公司工作的時候，有個約80個程式設計師組成的專案組正面臨著無法按時完成一項關鍵任務的風險。這個專案對於波音來說至關重要，所以他們把專案上80個人中的一大半換成了另外1個人，而這位仁兄單槍匹馬地完成了所有的程式設計工 作，並按時交付了軟體。我並沒有在這個專案組中工作，也不認識這位天才，但是這個故事是一位我所信任的人告訴我的，所以我相信這是真的。
這種差距並不僅限於軟體行業。Norm Augustine的一份研究指出，在各行各業中，包括寫作、橄欖球、發明、警務工作等，都存在一個情況，那就是行業中位列前20%的頂尖人才的產出佔到 了該行業總產出的50%，無論這些產出是得分、專利、偵破的案件還是軟體 。你可以想想看，這還是有道理的。我們都知道，有的學生就是比其他學生優秀，運動員、藝術家甚至家長也是如此。既然這種差別存在於所有人群中，那麼軟體開發又怎麼會例外呢？
巨大的差距帶來的負面影響
Augustine的研究發現，由於有些人完全沒有任何實質的貢獻（例如不能得分的前鋒、沒有專利的發明家、無法破案的警探等），人與人之間的差距的實際情況可能比上文提到的資料還要大。
在軟體行業中似乎就是這樣。在多個已發表的關於軟體開發效率的研究專案中，大約有10%的實驗參與者無法完成實驗任務。這些研究報告常常會這樣說 道：“所以我們從資料集中排除了這些參與者的結果。”但是在現實生活中，如果某個人“無法完成任務”，你就不能簡單地“從資料集中排除他們的結果”了。你或者得等他們完成，或者得另外指派一個人完成他們的工作，等等。這裡有一個有趣（而又可怕）的暗示，那就是在軟體行業中，差不多有10%的人對專案產出的貢獻是負數。
和此前一樣，這也和我們在現實生活中的感受一致。我相信很多人都能夠在共事過的人中找出符合這個描述的人。
什麼造就了真正的“10倍程式設計師”
很多人並不喜歡被貼上“10倍”這樣的標籤，因為他們覺得人們會說：“我們團隊中曾有個超級程式設計師，他牛哄哄的，每個人都不願和他來往，要是沒有他整體效率反而還要高些。”
通常來說，任何對10倍程式設計師的實用定義都必須考慮這樣的程式設計師對於團隊其他人員的影響。我也知道的確有牛哄哄的超級程式設計師。但更多的時候，那些牛哄哄的超級程式設計師其實只是普通水平的一般程式設計師而已，甚至還達不到普通水平。他們只是用牛哄哄的外表來讓自己的表現看上去不那麼差而已。我所共事過的真正的超級程式設計師們除了技術水平以外，通常還有很好的團隊精神（雖然有時也有些例外）。
測量程式設計師的個人生產力的問題
由於很多研究都指出不同程式設計師的效率可以有10倍的差距，導致很多人產生了一個想法，那就是測量他們在自己組織內的個人效率。無論如何，這種想法所涉及的測量“活的”程式設計師的生產力和一般研究中所說的生產力有很大不同。
軟體工程研究通常用完成某個任務所需的時間、每小時或每個月能寫多少行程式碼或者其他一些標準來測量生產力。但如果你嘗試在商業環境中用這些標準來測量生產力，那就會碰到很多問題。
生產力=每月產出的程式碼行數嗎
軟體設計是一件非確定性的事情，對同樣的一個問題，不同的設計師/開發人員會做出完全不同的解決方案。如果我們用每月產出的程式碼行數（或者類似的標 準）來衡量生產力，那麼我們就預設了用10倍的程式碼來解決同樣的問題的程式設計師就有10倍的生產力。顯然事情並非總是如此。比如某個程式設計師可能會有一個絕妙的設計想法，結果只用10%的程式碼就解決了普通程式設計師需要100%的程式碼才能解決的問題。
有人曾斷言，偉大的程式設計師寫的程式碼總是更簡短。事實上，程式設計水平和程式碼的簡潔性之間可能有著某種關聯，但我現在並不想做這樣一個寬泛的結論。我只想說，偉大的程式設計師總是努力把程式碼寫得更清楚，而結果通常就是更簡短的程式碼。不過有時候，最清楚、最簡單和最明顯的設計和那些更“巧妙”的設計相比，需要更多一點的程式碼。在這種情況下，我認為偉大的程式設計師也會用稍微多一點的程式碼來避免太過於取巧的設計。無論怎麼說，用“每月產出程式碼行數”來衡量生產力的想法都是有問題的。
Dilbert漫畫中有一個故事：老闆說每發現一個bug就獎勵10塊錢，大家都高呼這次賺到了，還有人想通過這個辦法“寫出輛小貨車”來 。故事正好說明了這個問題，即如果你用程式碼的產出量來衡量生產力，有的人就會利用這一點，寫很多很多也許完全沒有必要的程式碼。這裡的問題並不在於“程式碼量”這個標準，而在於舊式的管理思想，即“人們只會做會被考察的事情”。但你必須小心不要考察錯東西。
生產力=功能點嗎
“每個月的程式碼產出”所帶來的問題有一部分可以依靠功能點的標準來衡量程式規模。功能點是一套“合成”的測量程式大小的標準。包括輸入、輸出、查詢、檔案數量等都被考慮進來，作為確定程式大小的引數。低效的設計/程式設計風格並不能產生更多的功能點，所以功能點這個標準不涉及程式碼量的問題。但是它卻有 一個更實際的問題，那就是你需要專業人士來計算功能點（很多公司並無這種人才），而且功能點和個人產出的對應也非常粗略，所以無法用於確定程式設計師的個人生 產力。
複雜度呢
管理者常說：“我總是把最困難、最複雜的程式設計任務交給最好的程式設計師去做。所以無論用什麼方法來衡量，他的生產力好像總是比別人低，但是如果同樣的事情讓別人來做，就可能花上兩倍的時間。”這種現象很正常，但是也會影響我們定義和測量生產力的方式。
到底有沒有辦法可以測量個人生產力
前文提到的這些困難讓很多人認為：要想測量個人生產力簡直困難重重，沒人可以做到。但我認為要想正確地測量個人生產力是可能的，只是需要注意以下幾點。
- 不要指望僅用一個單獨的衡量標準就能瞭解個人生產力的實際整體狀況
你可以參照一下那些在體育比賽中搜集的統計資料。我們甚至無法用一個單獨的標準來確定棒球比賽中擊球手的水平。我們必須考慮打擊率、全壘打、跑壘得分、上 壘率以及其他種種因素。而且僅有這些資料還不夠，我們還得去證明這些資料的意義。如果擊球手的優劣無法用簡單的標準來評斷的話，難道程式設計師的個人生產力這樣複雜的事情就可以嗎？我們應該用的不是一個單獨的標準，而是一整套標準的組合。這套組合標準的任務，就是讓我們對個人生產力有更深入的瞭解。比如，這套標準可能包括準時完成任務的百分比、管理者的評分1～10、同事的評分1～10、每個月產出的程式碼行數、每行程式碼的平均缺陷數量、不當修復的比率，等等。
- 不要認為只要有了某種標準（無論單獨或者組合）就可以對不同個體的生產力進行細緻的鑑別了
要記住一點：這些個人生產力的標準只是為你找出問題，但是並不會回答這些問題。對這些標準的不當使用，比如用來進行績效評估，不但會帶來管理上的問題，也會造成統計上的問題。
- 整體的趨勢常常比某個時間點上的測量結果更重要
將這些測量結果在不同個體間進行橫向比較往往是得不出任何有意義的結論的。更有用的做法應該是將某個人的測量結果進行縱向分析，看看這個人有沒有隨著時間的推移而進步。
- 你要問自己：我測量個人生產力到底是為什麼
在研究環境中，研究員們需要評估不同技術的效率，所以需要測量個人生產力。相對於研究環境，在現實專案中使用同樣的測量標準產生的問題就要多得多了。在現實專案環境中，你想要用這些測量標準來做什麼？績效評估？這主意不行，原因剛剛才說過。分配任務？但我所訪問過的大部分管理者都說他們不必測量也知道誰是他們團隊中的明星成員，這一點我也相信。做預算？不行，不同設計方法導致的差距、不同的任務難度以及其他相關的原因使得我們無法有效利用這些標準來做專案預算。
在現實專案中，個人生產力的標準很難找到一個對專案管理有益而又符合統計學規則的用處。根據我的經驗，除了做研究之外，人們想對個人效率進行測量的動機通常來自一些在統計學上不能成立的結論。也就是說，雖然我知道在研究中對個人效率的測量非常有意義，但是我認為在實際專案中卻很難找到它的合理用處。
軟體開發中的團隊生產力差距
軟體專家們很早就已經發現，團隊生產力的差距和個人生產力的差距一樣大，是以數量級為單位的。這裡有一部分原因是因為物以類聚，人以群分，這一點已經由一次對來自18個組織機構的166個職業程式設計師的研究證明了。
又比如，在一次對7個完全相同的專案的研究中，研究人員發現，在這些團隊中耗費精力最多的是最低的3.4倍，而對於程式的大小，最大的是最小的3倍 。雖然生產力有一定差距，但是這次研究中的程式設計師都來自相似的背景。他們都是科班出身的職業程式設計師，而且都有多年的經驗。我們可以合理地推測，如果研究物件的背景差異再大一些，那麼他們之間的差距會更大。早期的一份對程式設計團隊的研究曾指出，對於同樣的專案，不同團隊所提交的程式大小的比例可以達到 5∶1，而所需時間的比例可以達到2.6∶1。
Barry Boehm等研究人員為了確立COCOMO II成本估算模型而研究了超過20年的資料，並總結到：對於同樣的程式，能力評分在15+的團隊需要的時間是得分為90+的團隊的3.5倍（以100分算）。 如果一個團隊比另一個團隊在程式語言或者應用領域上更有經驗，那麼這個差距還會更大。
一個具體的例子就是 Lotus 1～2～3 第三版和微軟 Excel 3.0 開發團隊之間的生產率差距。兩者都是在1989～1990這個時間段釋出的桌面電子表格應用程式。由於很少看到兩個公司公佈相似專案的資料，所以這 種死對頭之間的對比就顯得尤其有趣了。這兩個專案的資料如下：Excel的工作人員總共消耗了50個工年 ，共寫了649, 000行程式碼 。而Lotus 1～2～3消耗了260個工年，共寫了400,000行程式碼 [13]。Excel的團隊每個工年的程式碼產出是13,000行程式碼。而Lotus的團隊每個工年的產出只有1500行程式碼。兩個團隊之間的生產力差距超過了8倍，正好證明了我們此前的主張，即團隊的生產力也 有差距，並且有著更大量級的差距。
有趣的是，這些量化的結果和局外人對於這些專案的感覺非常貼近。Lotus 1~2!3第三版當時是出了名的跳票王，比預期的時間至少晚了兩年才釋出。而在微軟內部，Excel大受讚揚，被譽為是微軟最成功的專案之一。對於真實公司的 真實專案，這種程度的同類比較恐怕已經是能做到的極致了。
如前所述，這個例子說明了造成生產力差距的各種因素。Lotus和微軟都煞費苦心地為各自的專案招募了頂級的人才，所以我懷疑團隊生產力的差距並不只是由於團隊成員的能力差距造成的，還牽扯到了很多組織結構上的因素，比如產品遠景是否清楚、客戶需求是否明確以及成員之間是否能同心協力，等等。
組織的因素會影響團隊生產力的發揮。傑出的組織中個人能力平庸的團隊可以超越平庸組織中個人能力傑出的團隊。當然，像傑出的組織+傑出的團隊或者平庸的組織+平庸的團隊這樣的組合也不是沒有的。在這種時候，團隊生產力（或者叫組織生產力）和個人生產力一樣相差10倍也就不足為奇了。
本文摘自《軟體之道：軟體開發爭議問題剖析》