[置頂] 程序員編程生產力相差10倍意味著什么？

在軟件工程研究中，被驗證得最多的結論就是對于同等經驗的兩個不同程序員，在效率和質量上可能會有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、每個月產出的代碼行數、每行代碼的平均缺陷數量、不當修復的比率，等等。
• 不要認為只要有了某種標準（無論單獨或者組合）就可以對不同個體的生產力進行細致的鑒別了
  要記住一點：這些個人生產力的標準只是為你找出問題，但是并不會回答這些問題。對這些標準的不當使用，比如用來進行績效評估，不但會帶來管理上的問題，也會造成統計上的問題。
• 整體的趨勢常常比某個時間點上的測量結果更重要
  將這些測量結果在不同個體間進行橫向比較往往是得不出任何有意義的結論的。更有用的做法應該是將某個人的測量結果進行縱向分析，看看這個人有沒有隨著時間的推移而進步。
• 你要問自己：我測量個人生產力到底是為什么
  在研究環境中，研究員們需要評估不同技術的效率，所以需要測量個人生產力。相對于研究環境，在現實項目中使用同樣的測量標準產生的問題就要多得多了。在現實項目環境中，你想要用這些測量標準來做什么？績效評估？這主意不行，原因剛剛才說過。分配任務？但我所訪問過的大部分管理者都說他們不必測量也知道誰是他們團隊中的明星成員，這一點我也相信。做預算？不行，不同設計方法導致的差距、不同的任務難度以及其他相關的原因使得我們無法有效利用這些標準來做項目預算。

在現實項目中，個人生產力的標準很難找到一個對項目管理有益而又符合統計學規則的用處。根據我的經驗，除了做研究之外，人們想對個人效率進行測量的動機通常來自一些在統計學上不能成立的結論。也就是說，雖然我知道在研究中對個人效率的測量非常有意義，但是我認為在實際項目中卻很難找到它的合理用處。

軟件開發中的團隊生產力差距

軟件專家們很早就已經發現，團隊生產力的差距和個人生產力的差距一樣大，是以數量級為單位的[11]。這里有一部分原因是因為物以類聚，人以群分，這一點已經由一次對來自18個組織機構的166個職業程序員的研究證明了。

又比如，在一次對7個完全相同的項目的研究中，研究人員發現，在這些團隊中耗費精力最多的是最低的3.4倍，而對于程序的大小，最大的是最小的3倍 [3]。雖然生產力有一定差距，但是這次研究中的程序員都來自相似的背景。他們都是科班出身的職業程序員，而且都有多年的經驗。我們可以合理地推測，如果研究對象的背景差異再大一些，那么他們之間的差距會更大。早期的一份對編程團隊的研究曾指出，對于同樣的項目，不同團隊所提交的程序大小的比例可以達到5∶1，而所需時間的比例可以達到2.6∶1[15]。

Barry Boehm等研究人員為了確立COCOMO II 成本估算模型而研究了超過20年的數據，并總結到：對于同樣的程序，能力評分在15+的團隊需要的時間是得分為90+的團隊的3.5倍（以100分算）。如果一個團隊比另一個團隊在程序語言或者應用領域上更有經驗，那么這個差距還會更大。

一個具體的例子就是Lotus 1～2～3第三版和微軟Excel 3.0開發團隊之間的生產率差距。兩者都是在1989～1990這個時間段發布的桌面電子表格應用程序。由于很少看到兩個公司公布相似項目的數據，所以這種死對頭之間的對比就顯得尤其有趣了。這兩個項目的數據如下：Excel的工作人員總共消耗了50個工年 ，共寫了649 000行代碼 [8]。而Lotus 1～2～3消耗了260個工年，共寫了400 000行代碼 [13]。Excel的團隊每個工年的代碼產出是13 000行代碼。而Lotus的團隊每個工年的產出只有1500行代碼。兩個團隊之間的生產力差距超過了8倍，正好證明了我們此前的主張，即團隊的生產力也有差距，并且有著更大量級的差距。
有趣的是，這些量化的結果和局外人對于這些項目的感覺非常貼近。Lotus 123第三版當時是出了名的跳票王，比預期的時間至少晚了兩年才發布。而在微軟內部，Excel大受贊揚，被譽為是微軟最成功的項目之一。對于真實公司的真實項目，這種程度的同類比較恐怕已經是能做到的極致了。

如前所述，這個例子說明了造成生產力差距的各種因素。Lotus和微軟都煞費苦心地為各自的項目招募了頂級的人才，所以我懷疑團隊生產力的差距并不只是由于團隊成員的能力差距造成的，還牽扯到了很多組織結構上的因素，比如產品遠景是否清楚、客戶需求是否明確以及成員之間是否能同心協力，等等。

組織的因素會影響團隊生產力的發揮。杰出的組織中個人能力平庸的團隊可以超越平庸組織中個人能力杰出的團隊。當然，像杰出的組織+杰出的團隊或者平庸的組織+平庸的團隊這樣的組合也不是沒有的。在這種時候，團隊生產力（或者叫組織生產力）和個人生產力一樣相差10倍也就不足為奇了。

本文摘自《軟件之道：軟件開發爭議問題剖析 》