在軟件工程研究中，被驗證得最多的結(jié)論就是對于同等經(jīng)驗的兩個不同程序員，在效率和質(zhì)量上可能會有10倍的差距。研究人員還發(fā)現(xiàn)，這種差距也適用于團隊級別上，也就是說在同一行業(yè)內(nèi)不同的團隊也是如此。

　　軟件開發(fā)中個人效率的變化

　　首先發(fā)現(xiàn)不同的人在編程生產(chǎn)力上的巨大差距的研究，是1960年由Sackman、Erikson以及Grant三個人完成的。他們研究了工作經(jīng)驗平均在7年的專業(yè)程序員，并發(fā)現(xiàn)最好和最差的程序員寫新代碼的時間比為20:1；調(diào)試次數(shù)是25:1；程序大小是5:1；程序的執(zhí)行效率是10:1。他們還發(fā)現(xiàn)，程序員的經(jīng)驗和代碼質(zhì)量或效率并沒有關(guān)系。

　　在詳細(xì)地研究了Sackman、Erickson以及Grant的研究結(jié)果之后，我們可以發(fā)現(xiàn)他們所使用的方法中有很多缺陷，例如把使用低級程序語言和高級程序語言的程序員合在一起研究等。但是，即便把這些缺陷考慮進來，他們的數(shù)據(jù)也仍然表明，最好的程序員和最差的程序員之間的差距能達到10倍以上。

　　那次研究之后，還有很多其他關(guān)于專業(yè)程序員的相關(guān)研究都證明了一個結(jié)論：程序員的水平也分三六九等。

　　除些之外，很多軼事傳聞也支持這種觀點。在20世紀(jì)80年代中期，當(dāng)我還在波音公司工作的時候，有個約80個程序員組成的項目組正面臨著無法按時完成一項關(guān)鍵任務(wù)的風(fēng)險。這個項目對于波音來說至關(guān)重要，所以他們把項目上80個人中的一大半換成了另外1個人，而這位仁兄單槍匹馬地完成了所有的編程工 作，并按時交付了軟件。我并沒有在這個項目組中工作，也不認(rèn)識這位天才，但是這個故事是一位我所信任的人告訴我的，所以我相信這是真的。

　　這種差距并不僅限于軟件行業(yè)。Norm Augustine的一份研究指出，在各行各業(yè)中，包括寫作、橄欖球、發(fā)明、警務(wù)工作等，都存在一個情況，那就是行業(yè)中位列前20%的頂尖人才的產(chǎn)出占到 了該行業(yè)總產(chǎn)出的50%，無論這些產(chǎn)出是得分、專利、偵破的案件還是軟件 。你可以想想看，這還是有道理的。我們都知道，有的學(xué)生就是比其他學(xué)生優(yōu)秀，運動員、藝術(shù)家甚至家長也是如此。既然這種差別存在于所有人群中，那么軟件開發(fā)又怎么會例外呢？

　　巨大的差距帶來的負(fù)面影響

　　Augustine的研究發(fā)現(xiàn)，由于有些人完全沒有任何實質(zhì)的貢獻（例如不能得分的前鋒、沒有專利的發(fā)明家、無法破案的警探等），人與人之間的差距的實際情況可能比上文提到的數(shù)據(jù)還要大。

　　在軟件行業(yè)中似乎就是這樣。在多個已發(fā)表的關(guān)于軟件開發(fā)效率的研究項目中，大約有10%的實驗參與者無法完成實驗任務(wù)。這些研究報告常常會這樣說 道：“所以我們從數(shù)據(jù)集中排除了這些參與者的結(jié)果。”但是在現(xiàn)實生活中，如果某個人“無法完成任務(wù)”，你就不能簡單地“從數(shù)據(jù)集中排除他們的結(jié)果”了。你或者得等他們完成，或者得另外指派一個人完成他們的工作，等等。這里有一個有趣（而又可怕）的暗示，那就是在軟件行業(yè)中，差不多有10%的人對項目產(chǎn)出的貢獻是負(fù)數(shù)。

　　和此前一樣，這也和我們在現(xiàn)實生活中的感受一致。我相信很多人都能夠在共事過的人中找出符合這個描述的人。

　　什么造就了真正的“10倍程序員”

　　很多人并不喜歡被貼上“10倍”這樣的標(biāo)簽，因為他們覺得人們會說：“我們團隊中曾有個超級程序員，他牛哄哄的，每個人都不愿和他來往，要是沒有他整體效率反而還要高些。”

　　通常來說，任何對10倍程序員的實用定義都必須考慮這樣的程序員對于團隊其他人員的影響。我也知道的確有牛哄哄的超級程序員。但更多的時候，那些牛哄哄的超級程序員其實只是普通水平的一般程序員而已，甚至還達不到普通水平。他們只是用牛哄哄的外表來讓自己的表現(xiàn)看上去不那么差而已。我所共事過的真正的超級程序員們除了技術(shù)水平以外，通常還有很好的團隊精神（雖然有時也有些例外）。

　　測量程序員的個人生產(chǎn)力的問題

　　由于很多研究都指出不同程序員的效率可以有10倍的差距，導(dǎo)致很多人產(chǎn)生了一個想法，那就是測量他們在自己組織內(nèi)的個人效率。無論如何，這種想法所涉及的測量“活的”程序員的生產(chǎn)力和一般研究中所說的生產(chǎn)力有很大不同。

　　軟件工程研究通常用完成某個任務(wù)所需的時間、每小時或每個月能寫多少行代碼或者其他一些標(biāo)準(zhǔn)來測量生產(chǎn)力。但如果你嘗試在商業(yè)環(huán)境中用這些標(biāo)準(zhǔn)來測量生產(chǎn)力，那就會碰到很多問題。

　　生產(chǎn)力=每月產(chǎn)出的代碼行數(shù)嗎

　　軟件設(shè)計是一件非確定性的事情，對同樣的一個問題，不同的設(shè)計師/開發(fā)人員會做出完全不同的解決方案。如果我們用每月產(chǎn)出的代碼行數(shù)（或者類似的標(biāo) 準(zhǔn)）來衡量生產(chǎn)力，那么我們就默認(rèn)了用10倍的代碼來解決同樣的問題的程序員就有10倍的生產(chǎn)力。顯然事情并非總是如此。比如某個程序員可能會有一個絕妙的設(shè)計想法，結(jié)果只用10%的代碼就解決了普通程序員需要100%的代碼才能解決的問題。

　　有人曾斷言，偉大的程序員寫的代碼總是更簡短。事實上，編程水平和代碼的簡潔性之間可能有著某種關(guān)聯(lián)，但我現(xiàn)在并不想做這樣一個寬泛的結(jié)論。我只想說，偉大的程序員總是努力把代碼寫得更清楚，而結(jié)果通常就是更簡短的代碼。不過有時候，最清楚、最簡單和最明顯的設(shè)計和那些更“巧妙”的設(shè)計相比，需要更多一點的代碼。在這種情況下，我認(rèn)為偉大的程序員也會用稍微多一點的代碼來避免太過于取巧的設(shè)計。無論怎么說，用“每月產(chǎn)出代碼行數(shù)”來衡量生產(chǎn)力的想法都是有問題的。

　　Dilbert漫畫中有一個故事：老板說每發(fā)現(xiàn)一個bug就獎勵10塊錢，大家都高呼這次賺到了，還有人想通過這個辦法“寫出輛小貨車”來 。故事正好說明了這個問題，即如果你用代碼的產(chǎn)出量來衡量生產(chǎn)力，有的人就會利用這一點，寫很多很多也許完全沒有必要的代碼。這里的問題并不在于“代碼量”這個標(biāo)準(zhǔn)，而在于舊式的管理思想，即“人們只會做會被考察的事情”。但你必須小心不要考察錯東西。

　　生產(chǎn)力=功能點嗎

　　“每個月的代碼產(chǎn)出”所帶來的問題有一部分可以依靠功能點的標(biāo)準(zhǔn)來衡量程序規(guī)模。功能點是一套“合成”的測量程序大小的標(biāo)準(zhǔn)。包括輸入、輸出、查詢、文件數(shù)量等都被考慮進來，作為確定程序大小的參數(shù)。低效的設(shè)計/編程風(fēng)格并不能產(chǎn)生更多的功能點，所以功能點這個標(biāo)準(zhǔn)不涉及代碼量的問題。但是它卻有 一個更實際的問題，那就是你需要專業(yè)人士來計算功能點（很多公司并無這種人才），而且功能點和個人產(chǎn)出的對應(yīng)也非常粗略，所以無法用于確定程序員的個人生 產(chǎn)力。

　　復(fù)雜度呢

　　管理者常說：“我總是把最困難、最復(fù)雜的編程任務(wù)交給最好的程序員去做。所以無論用什么方法來衡量，他的生產(chǎn)力好像總是比別人低，但是如果同樣的事情讓別人來做，就可能花上兩倍的時間。”這種現(xiàn)象很正常，但是也會影響我們定義和測量生產(chǎn)力的方式。

　　到底有沒有辦法可以測量個人生產(chǎn)力

　　前文提到的這些困難讓很多人認(rèn)為：要想測量個人生產(chǎn)力簡直困難重重，沒人可以做到。但我認(rèn)為要想正確地測量個人生產(chǎn)力是可能的，只是需要注意以下幾點。

• 不要指望僅用一個單獨的衡量標(biāo)準(zhǔn)就能了解個人生產(chǎn)力的實際整體狀況

  你可以參照一下那些在體育比賽中搜集的統(tǒng)計數(shù)據(jù)。我們甚至無法用一個單獨的標(biāo)準(zhǔn)來確定棒球比賽中擊球手的水平。我們必須考慮打擊率、全壘打、跑壘得分、上 壘率以及其他種種因素。而且僅有這些數(shù)據(jù)還不夠，我們還得去證明這些數(shù)據(jù)的意義。如果擊球手的優(yōu)劣無法用簡單的標(biāo)準(zhǔn)來評斷的話，難道程序員的個人生產(chǎn)力這樣復(fù)雜的事情就可以嗎？我們應(yīng)該用的不是一個單獨的標(biāo)準(zhǔn)，而是一整套標(biāo)準(zhǔn)的組合。這套組合標(biāo)準(zhǔn)的任務(wù)，就是讓我們對個人生產(chǎn)力有更深入的了解。比如，這套標(biāo)準(zhǔn)可能包括準(zhǔn)時完成任務(wù)的百分比、管理者的評分1～10、同事的評分1～10、每個月產(chǎn)出的代碼行數(shù)、每行代碼的平均缺陷數(shù)量、不當(dāng)修復(fù)的比率，等等。

• 不要認(rèn)為只要有了某種標(biāo)準(zhǔn)（無論單獨或者組合）就可以對不同個體的生產(chǎn)力進行細(xì)致的鑒別了

  要記住一點：這些個人生產(chǎn)力的標(biāo)準(zhǔn)只是為你找出問題，但是并不會回答這些問題。對這些標(biāo)準(zhǔn)的不當(dāng)使用，比如用來進行績效評估，不但會帶來管理上的問題，也會造成統(tǒng)計上的問題。

• 整體的趨勢常常比某個時間點上的測量結(jié)果更重要

  將這些測量結(jié)果在不同個體間進行橫向比較往往是得不出任何有意義的結(jié)論的。更有用的做法應(yīng)該是將某個人的測量結(jié)果進行縱向分析，看看這個人有沒有隨著時間的推移而進步。

• 你要問自己：我測量個人生產(chǎn)力到底是為什么

  在研究環(huán)境中，研究員們需要評估不同技術(shù)的效率，所以需要測量個人生產(chǎn)力。相對于研究環(huán)境，在現(xiàn)實項目中使用同樣的測量標(biāo)準(zhǔn)產(chǎn)生的問題就要多得多了。在現(xiàn)實項目環(huán)境中，你想要用這些測量標(biāo)準(zhǔn)來做什么？績效評估？這主意不行，原因剛剛才說過。分配任務(wù)？但我所訪問過的大部分管理者都說他們不必測量也知道誰是他們團隊中的明星成員，這一點我也相信。做預(yù)算？不行，不同設(shè)計方法導(dǎo)致的差距、不同的任務(wù)難度以及其他相關(guān)的原因使得我們無法有效利用這些標(biāo)準(zhǔn)來做項目預(yù)算。

　　在現(xiàn)實項目中，個人生產(chǎn)力的標(biāo)準(zhǔn)很難找到一個對項目管理有益而又符合統(tǒng)計學(xué)規(guī)則的用處。根據(jù)我的經(jīng)驗，除了做研究之外，人們想對個人效率進行測量的動機通常來自一些在統(tǒng)計學(xué)上不能成立的結(jié)論。也就是說，雖然我知道在研究中對個人效率的測量非常有意義，但是我認(rèn)為在實際項目中卻很難找到它的合理用處。

　　軟件開發(fā)中的團隊生產(chǎn)力差距

　　軟件專家們很早就已經(jīng)發(fā)現(xiàn)，團隊生產(chǎn)力的差距和個人生產(chǎn)力的差距一樣大，是以數(shù)量級為單位的。這里有一部分原因是因為物以類聚，人以群分，這一點已經(jīng)由一次對來自18個組織機構(gòu)的166個職業(yè)程序員的研究證明了。

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

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

　　一個具體的例子就是 Lotus 1～2～3 第三版和微軟 Excel 3.0 開發(fā)團隊之間的生產(chǎn)率差距。兩者都是在1989～1990這個時間段發(fā)布的桌面電子表格應(yīng)用程序。由于很少看到兩個公司公布相似項目的數(shù)據(jù)，所以這 種死對頭之間的對比就顯得尤其有趣了。這兩個項目的數(shù)據(jù)如下：Excel的工作人員總共消耗了50個工年 ，共寫了649, 000行代碼 。而Lotus 1～2～3消耗了260個工年，共寫了400,000行代碼 [13]。Excel的團隊每個工年的代碼產(chǎn)出是13,000行代碼。而Lotus的團隊每個工年的產(chǎn)出只有1500行代碼。兩個團隊之間的生產(chǎn)力差距超過了8倍，正好證明了我們此前的主張，即團隊的生產(chǎn)力也 有差距，并且有著更大量級的差距。

　　有趣的是，這些量化的結(jié)果和局外人對于這些項目的感覺非常貼近。Lotus 1~2!3第三版當(dāng)時是出了名的跳票王，比預(yù)期的時間至少晚了兩年才發(fā)布。而在微軟內(nèi)部，Excel大受贊揚，被譽為是微軟最成功的項目之一。對于真實公司的 真實項目，這種程度的同類比較恐怕已經(jīng)是能做到的極致了。

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

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

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

it知識庫：程序員編程生產(chǎn)力相差10倍意味著什么？，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。