[[134393]]

為什么說上面的想法很荒謬？因為我們沒有一種簡單又有效的方法來衡量程序員的生產(chǎn)力。一旦碰到我們無法衡量的東西，我們就會忽略它。

我這樣問你好了：你是愿意讓兩個新手來照顧你的寶寶，維修你的車，給你做腰椎穿刺，還是寧愿找一個資深的？

如果你一定要比較的話，那么其實程序員更像是作家。

有些作家寫出的東西能數(shù)以百萬計地賣出去，而有些作家寫出來的東西無聊至極最后只能用來燒火用！

但是，他們都生產(chǎn)出了一本書，因此，他們都是作家。可是除非你去閱讀他們的書，否則你就不會知道他們倆的差別。

編程經(jīng)理老早就認識到好程序員和差程序員兩者的生產(chǎn)力有著天囊之別。但實際測得的數(shù)據(jù)結果依然讓我們所有人都大吃一驚。在 研究中，Sackman、Erickson和Grant想要衡量一組經(jīng)驗豐富的程序員的表現(xiàn)。結果表明，最佳和最差的生產(chǎn)力比例平均約為10：1，特別是 編程速度的比例令人吃驚地達到5：1！ FRED BROOKS，《THE MYTHICAL MAN-MONTH》

 

下面我給你講一個真實的故事。（有關名字已作更改。）

一家軟件公司需要在他們的標志產(chǎn)品中實現(xiàn)一個新的模塊。Mr Lousy（差先生）剛好有空，于是就將這個任務交給了他，讓他立馬開工！

經(jīng)過四個月的修修補補，差先生終于完成了。 QA團隊發(fā)現(xiàn)存在著大量的bug和矛盾之處，并將報告返回給差先生。差先生根據(jù)報告又花了2周的時間來修復這些bug，并最終給出了一個新的版本！那些該死的惱人bug真是絞盡了差先生的腦汁。

測試然后修復，如此循環(huán)了兩三次。

用戶已經(jīng)在期待這個新的模塊。銷售人員也簽署了一些新的客戶。把這個模塊做出來，并整合到下一版本中這一過程的壓力之大可想而知。但是，所幸，成功了！開香檳慶祝吧！

呀，不對，新模塊中依然滿是bug。群眾的眼睛總是雪亮的，客戶總是特別擅長于找到一些以前從未被發(fā)現(xiàn)的bug。于是他們聯(lián)系技術支持。技術支持團 隊再去找是什么地方出了錯，是客戶不知道如何操作功能，還是他們自己搞錯了，抑或這只是一個bug，一個可以重現(xiàn)的bug。……然后技術支持團隊提交了錯 誤報告。于是，差先生悲劇了，——我的意思是，哪怕他正在搞另一個項目，在這個時候也只能放下手頭的一切工作來解決這些麻煩事。

（這還沒有涉及到代碼的維護性，邏輯性和文檔化問題——因為以后肯定會有其他人來改進這些代碼）

但是，唉，怎么說呢……似乎有一些bug超出了差先生的能力范圍，他根本修復不了。此外，不斷出現(xiàn)的新bug，沒人知道確實它們是新出來的，還是以 前就有但就是沒有被發(fā)現(xiàn)而已的。技術支持煩不勝煩。而銷售越來越惱火，因為新客戶紛紛表示這個模塊太不靠譜了，他們要取消合同！

最后，老板不得不讓Mr Rockstar（好先生）來看一看這些代碼。

好先生并不想為差先生收拾爛攤子，很多結構在他眼中都是沒有意義的。他建議重寫代碼，預期大概需要一個月的時間。然后他開工了，只比原先估計的多了 幾天就完成了模塊（他是好先生，而不是完美先生）。除了QA團隊發(fā)現(xiàn)了一些小錯誤，一切都能如期工作。 QA團隊在心里默默擔心：如果所有的程序員都像他一樣，那他們就沒有用武之地了。差先生認為好先生這是在傲慢地嘲笑他，但他的看法對好先生而言是無關緊要 的。

改進過的模塊很快發(fā)布了。每個人都很高興，因為終于可以正常工作了。萬歲！

現(xiàn)在真的到了可以開香檳慶祝的時候了！

但是此時，似乎所有人都忘記了好先生只用了一個月左右的時間就成功搞定了差先生用了七八個月也搞不定的任務。

這兩個開發(fā)人員生產(chǎn)力水平的巨大差異由此可見一斑——他們執(zhí)行的是完全相同的任務。

通過編寫更精簡但功能更多的代碼，通過編寫bug更少更易于維護的代碼，一個優(yōu)秀的開發(fā)人員可以減輕QA人員，同事和管理人員的工作壓力，提高身邊每一個人的生產(chǎn)力。這就是為什么研究得出的這些數(shù)據(jù)，如28倍的生產(chǎn)效率是可能的，甚至可能還報低了，如果你縱覽全局的話。 PHIL HAACK，《10 DEVELOPERS FOR THE PRICE OF ONE》

 

那么，在這個故事中可能會發(fā)生的最糟糕的事情是什么呢？

好先生終于注意到他比差先生的效率要高得多：他能輕易識別不良代碼。但是盡管如此，他很肯定自己的薪資和差先生的差不多。他表示不滿，甚至于毅然決然地離開。于是你的開發(fā)團隊失去了一個高效的力量支柱。

即使他不離開，當面對由于發(fā)布/項目延遲導致的整個團隊的加班，他會怎么想？離開是必然的，只是時間早晚而已。

并且，如果你真的運氣實在不佳，提了另一個人去取代好先生的位置，卻不幸是另一個差先生的話，那我就只能默默地為你點根蠟燭了。

那么，為什么我們總是習慣于忽略這個事實呢？

因為忽視比糾正問題容易得多——至少某種程度上，的確如此。并且沒人愿意做告發(fā)同事的小人，成為他丟掉飯碗的原因：因為搞不好差先生上有高堂要贍 養(yǎng)，下有兒女嗷嗷待哺；或許他剛剛買了新房子，每個月都要還貸——最重要的是，真的很難衡量開發(fā)人員的工作效率，除非你讓他們倆做相同的任務來做對比，就 像上面的故事一樣。

于是我一直在想這個問題：該如何衡量開發(fā)人員的工作效率。我很嫉妒做銷售的，因為他們的薪酬是根據(jù)業(yè)績來的。我有一些想法（還不成熟）能讓你去其糟粕取其精華。我也有一些想法關于如何識別、吸引和留住好的開發(fā)人員。

我的身份以及我為什么要告訴你這些真相

我曾作為一個全職的開發(fā)人員干了10多年。早在1989年我做出了我的第一個商業(yè)化的產(chǎn)品（游戲）。雖然它并沒有給我?guī)砗芏噱X，但感覺真的超好 （那時我才16歲）。幾年后，我出售了其中一個游戲點子，并最終發(fā)布于任天堂游戲機（以及其他格式）上！從我經(jīng)驗的角度，我可以告訴你，當你看到你想出來 的東西（包括名稱）最終出現(xiàn)在商店中，這感覺不要太爽。

2008年，我應聘了一家技術驅(qū)動公司的一個非技術職位。我想了解企業(yè)一般的運行模式，包括銷售在內(nèi)的企業(yè)中發(fā)生的所有非技術進程。雖然，我的技術能力對我的求職很有幫助，但不再是工作的重要組成部分。

我不再為了謀生而編程（確切的說，是當時），但經(jīng)常在業(yè)余項目上鼓搗各種新技術。對我來說，讀一本好書，既令人興奮，同時又能夠得到放松。

在我目前的崗位上，我經(jīng)常會遇到一些誤解概念或缺乏開發(fā)基本知識的人。而在他們身處的職位上（通常是那些CxO們），這些基礎知識會造成巨大的影響。

很多CxO會將開發(fā)人員當作是砌磚工人，死板地計算他們的工作效率。但是，在這里，我想再次重申這個“作家理論”，開發(fā)人員是腦力工作者，OK？