神譯局是36氪旗下編譯團隊，關注科技、商業(yè)、職場、生活等領域，重點介紹國外的新技術、新觀點、新風向。
編者按：定義和衡量程序員的生產效率是工程經(jīng)理或CTO的職位描述里面最困難的部分之一了。當你所做的一切都是看不見的時候，應該怎么去衡量呢？或者說究竟能不能衡量呢？Isaac Lyman對業(yè)界用來衡量開發(fā)人員工作績效的若干指標進行了分析，認為目前大部分用來衡量程序員表現(xiàn)的指標其實都是非常糟糕的，并給出了他的建議方案。原文發(fā)表在StackOverFlow官方博客上，標題是：Can developer productivity be measured?
劃重點：
定義和衡量開發(fā)人員的效率是個難題
用輸入來衡量效率，職場會變成大家在“摸魚”的地方
軟件開發(fā)很抽象很復雜，需要專注，所以對開發(fā)人員的心理狀態(tài)非常敏感
金錢和工時都屬于同一類：這兩個不僅屬于輸入，而且屬于輔助性的輸入，只能稍微提高一點生產率
代碼行數(shù)或提交次數(shù)幾乎是最糟糕的衡量指標
寫出來的東西沒有解決問題永遠都要比不寫還要糟
當措施本身成為目標時，就不再是好措施
軟件是團隊努力的結果，個體工作之間的相關性是外部觀察者無法衡量的
衡量團隊績效的關鍵是看速度，看他們有沒有在數(shù)周乃至數(shù)月的時間范圍內持續(xù)開發(fā)出有用的軟件
在軟件行業(yè)里面，定義和衡量程序員的生產效率是類似大白鯨一樣的東西。這是巨額投資的基礎，是眾多初創(chuàng)企業(yè)的價值主張，也是工程經(jīng)理或CTO的職位描述里面最困難的部分之一。這還是各種不同經(jīng)驗水平的開發(fā)者的焦慮之源：怎么才能知道自己已經(jīng)做夠了（不管是工作時間還是非工作時間）？當你所做的一切都是看不見的時候，你應該怎么去衡量呢？或者說究竟能不能衡量呢？在本文中，我會討論衡量生產效率的最大陷阱是什么，以及若干好的衡量手段。
跟其他領域一樣，很多人也是從投入和產出的角度來考慮軟件開發(fā)的生產力。在美國，全職開發(fā)人員每周要工作40個小時，平均年薪為107510美元。工時和工資都是可見的，且易于量化的輸入。然后，開發(fā)人員會定期開發(fā)軟件功能，編寫文檔，進行部署及/或錯誤修復。這些則是輸出。如果開發(fā)人員寫軟件像我們想象的那么樣簡單的話，那么提高他們的生產力應該就跟要求他們延長工作時間或者支付更高薪水一樣簡單。當然，這種想象只是童話。開發(fā)人員和軟件的工作方式都不是那樣的。
用來衡量工作績效有好些指標都是錯誤的，“工作時間”就是其中之一。我之所以要先提這個，是因為這個經(jīng)常不做審查就被當作默認，是阻力最小的做法。如果公司不可以避免這種做法的話，遲早會惡化成為只論工作時長的環(huán)境。在遠程辦公成為常態(tài)的疫情之外，這種只看時間的環(huán)境是很容易看出來的。上班時間被認為是沒有商量余地的，而在辦公室出現(xiàn)被看成是正在工作的證據(jù)。誰要是想提前幾個小時離開辦公室都會遇到敵意（有時候可能就是側目一下，有時候可能會更加無禮）。任何開夜車或者周末來加班的行為都會被看成是高效的表現(xiàn)。不幸的是，這種“最后一個離開健身房”文化的激勵措施很不幸：除了把生活的更多時間花在工作上以外，開發(fā)者人員沒有任何其他方式來證明自己的價值，還會造成工作成功反而變成了次要的關注對象。慢慢地，工作場所逐漸變成人人都在工作但無所事事的地方（摸魚）。
問題還不止這些。如果我們假設所有的工作都屬于“正功”，也就是說，所有的工作都代表朝著目標逼近的話，那你就大錯特錯了。開發(fā)者如果是在精疲力竭，分心或生病的時候工作的話，那種工作往往屬于“負功”：工作做得很差，以至于必須撤消或者事后補窟窿，導致剩余工作量不是減少而是增加。軟件開發(fā)很抽象很復雜，需要專注，所以對開發(fā)人員的心理狀態(tài)非常敏感。也就是說，有一些隱藏的輸入會影響工作表現(xiàn)：如焦慮，沮喪，倦怠，惡劣的工作氛圍，悲傷，微攻擊等一百多種可以在任何一天降低或逆轉個人工作效率的東西。如果公司文化要求連續(xù)長時間的工作，或者甚至只是朝九晚五而沒有靈活性或休假時間的話，那開發(fā)人員把時間用來做“負功”將不可避免：熬夜做出來的成果甚至還不如早點回家做出來的好。由于疲勞，他們第二天的工作量也會減少。
另一方面，只看時間的環(huán)境還不是最壞的情況。這里面還有一個公平的幽靈：如果兩個開發(fā)者工作的時長都是一樣的話，則兩人有一個明確的維度說明大家是相同的。兩人似乎都沒有懈怠，似乎也沒有多做。如果他們的產出不達預期，至少人家投入了時間。而且，“工作時間”這個指標不會像某些指標那么明顯地鼓勵寫出不好的代碼。所以，雖然這是一個很糟糕的指標，甚至在很多情況下還會影響到生產效率，但還有更糟糕的指標值得我們討論。
不妨考慮軟件開發(fā)另一個顯然的輸入：錢。我曾經(jīng)跟我的經(jīng)理開過一兩次玩笑，說生產效率應該用薪水來衡量，如果給我的薪水加倍的話，我就會用世界級軟件架構師的水平來寫代碼。當然，你憑直覺就知道這很荒謬。多給錢并不能馬上提高開發(fā)者的生產力（盡管間接可能會，但規(guī)模有限）。不過，在我看來，金錢和工時都屬于同一類：這兩個不僅屬于輸入，而且屬于輔助性的輸入，只能稍微提高一點生產率。只不過一種是由雇主提供的輸入，而另一種是由雇員提供的，但是這種交換只是開發(fā)有用軟件的陪襯。
長話短說，通過輸入來衡量效率是不充分的，因為軟件開發(fā)不是方程式，代碼沒法靠組裝線開發(fā)出來。所以，我們就來談談輸出吧。
在輸出這里你會發(fā)現(xiàn)很多軟件世界里面最糟糕的衡量指標，這一點也許會有違直覺。有些人會掉進這樣的陷阱里面，他們以為軟件開發(fā)的工作輸出就是代碼行數(shù)或者提交到版本控制的次數(shù)。當然，這些是流程的一部分，但那更像是副產品，而不是最終結果。嚴格來說，寫出來的東西沒有解決問題永遠都要比不寫還要糟。也就是說，靠看開發(fā)者貢獻了多少代碼來衡量生產效率，就好像靠產生的廢物量來衡量發(fā)電廠的績效，或者靠通過多少法案來衡量國會的績效一樣；這跟實際價值毫無關系。
更糟糕的是，這些指標作弊非常容易。如果薪水是按代碼行數(shù)計費的話，開發(fā)人員在一天之內就能輕輕松松賺走一年的薪水，但卻不能產生任何的商業(yè)價值。大多數(shù)的開發(fā)人員做法會更加微妙一些，但基本都是換湯不換藥，你最好管理好自己的預期。
當措施本身成為目標時，就不再是好措施。
——古德哈特定律
開發(fā)人員基本上都了解這一點，但是令人尷尬的是，我們往往還是把提交和代碼行作為考核的目標。當我們看到Google開發(fā)的代碼量超過20億行（Google旗下所有產品，當時是2015年）的消息，或者Windows團隊每天的代碼push超過8400次時，我們都會瞪大眼睛，即便我們知道這兩個都不是讓Google或Windows變得有用的關鍵。有時社區(qū)甚至會折騰出類似這樣的廢話：
（順便說一句，我還是要對他養(yǎng)成這種幾乎每天都寫代碼的習慣表示祝賀，也對他偶爾不寫表示祝賀。盡管在沒有看過他們的貢獻歷史的情況下，我不會對這個人的工作效率下結論）
不管怎樣，我們都可以將這些衡量措施添加到無效手段清單里面。用修復的bug數(shù)量、完成的任務數(shù)，或者交付的功能數(shù)來衡量同樣是徒勞的。如果目標是修復更多的錯誤的話，那開發(fā)人員可以故意寫出有bug的軟件，然后再去寫大量的修復程序；或者，為了實現(xiàn)相反的目標，他們可以用慢工出細活為理由來減少錯誤數(shù)量。如果目標是功能發(fā)布的話，他們可以寫得很快很幼稚，導致軟件運行緩慢且?guī)缀鯚o法運行。如果目標是完成的任務數(shù)，那么整個團隊都會卷入內斗，因為大家都會去爭奪最簡單（或最被高估）的任務。高素質的團隊也許會不理睬你的衡量措施，只顧干好本分工作，但就算是在最好的情況下，糟糕的衡量措施也是很難無視的障礙。
有些組織在這方面已經(jīng)走火入魔，開始在員工的計算機上安裝間諜軟件，妄圖用鼠標的移動，按鍵以及屏幕截圖等手段來跟蹤每時每刻的工作細節(jié)。在這種監(jiān)視下，還有誰能夠開展創(chuàng)造性的工作呢？我覺得大多數(shù)的開發(fā)人員都會馬上自己炒老板魷魚。但是，就像前面討論過的衡量措施一樣，這里最明顯的失敗在于，它沒有捕捉任何到對企業(yè)或客戶真正有意義的東西。你會因為某位高效表現(xiàn)的開發(fā)人員在Reddit上面逛的時間太長，移動鼠標的頻率高而對他進行懲罰嗎？你會因為某位開發(fā)人員花來很多時間在Visual Studio上面敲代碼而提拔他嗎（就算他們很難跟別人合作）？有的經(jīng)理顯然就是這么做的，我唯有希望我們大多數(shù)人都能做得更聰明些。
好了，我已經(jīng)警告過你最好不要用哪些最糟糕的衡量手段了，接下來我們再來談一談哪些才是好的手段。不幸的是，個人的績效幾乎沒法靠“這個團隊成員有貢獻”或者“這個團隊成員沒有貢獻”這種非此即彼的二分法來衡量。而且，也不能遠距離地進行衡量。
軟件開發(fā)團隊不是一群人在那里單干；每個團隊成員的工作成果都是所有其他隊友工作成果的函數(shù)，更不用說一天當中那些有意義的，不可衡量的互動了。個體工作之間的相關性以及微妙之處實在是太復雜了，是外部觀察者無法衡量的。比方說，某些團隊成員是團隊其余成員的力量倍增器——那些人也許沒法獨立完成很多工作，但如果沒有他們的幫助和影響，其他團隊成員的生產效率就會大大降低。像這樣的人是高效工程組織的秘密武器，但是他們的生產效率是沒辦法在個人層面來衡量的。有的團隊成員未必能開發(fā)出很多的功能，而是隨時隨地充當“代碼管理員”的角色，對代碼進行仔細的測試，清理以及重構，從而讓團隊成員可以更快、更輕松地開發(fā)功能。作為個人，這些人的生產力也是無法衡量的，但是其對團隊生產力的影響卻是指數(shù)性的。哪怕對于要定期發(fā)布新功能的程序員來說，生產效率在短期內往往也會有很大差異，導致難以進行具體的跟蹤。出于這樣的原因，個人的績效最好留給個人貢獻者自己以及彼此進行衡量。
而反過來看，團隊的績效則要好評價得多。跟蹤績效的最好辦法也許是問。這個團隊有沒有在數(shù)周乃至數(shù)月的時間范圍內持續(xù)開發(fā)出有用的軟件？這一點正好跟敏捷的第三項原則呼應：“頻繁地交付可工作的軟件，周期從兩周到兩個月不等，最好所用的時間跨度較短?！?能夠定期地做出有用的軟件的團隊就是高效的團隊。如果不能，那就要問問為什么。缺乏效率一般都會有正當?shù)睦碛伞４蠖鄶?shù)生產效率不高的團隊都希望提高生產效率，而生產效率高的團隊大都希望更上一層樓。
可以通過簡單的，整體的觀察從組織的規(guī)模上去衡量團隊的生產力。而且由于團隊成員之間往往很了解彼此的貢獻（無論這種貢獻是不是可以衡量），所以通過良好的組織習慣就可以發(fā)現(xiàn)個人生產力方面存在的任何嚴重缺陷，比方說，經(jīng)理跟自己的直接下屬之間可以經(jīng)常進行一對一的會面；定期收集匿名的真實反饋；鼓勵每一位團隊成員匯報自己取得的成績，對失敗承擔責任，通過這樣加強個人責任感。
這里面很多都要取決于人，而不是靠趨勢圖和原始數(shù)據(jù)。這是軟件不可回避的事實：軟件更多跟人有關，遠不止是0和1，而且一直都是這樣。生產力跟蹤工具和激勵計劃永遠不會像職場的積極文化那樣能夠產生巨大的影響。當問責制和健康的溝通融入到這種文化里面時，最有能力解決這些問題的人很快就會意識到生產力的關鍵時刻。
很多組織把速度作為衡量團隊生產力的首選指標，如果做法合適的話，這可以是了解軟件開發(fā)過程的一個有用工具。速度是一個聚合的衡量措施，用來考量團隊隨時間轉移完成的任務情況，一般會考慮到開發(fā)人員自己對每項任務相對復雜性的估計。它要回答諸如“這支團隊在接下來的兩周里可以做多少工作？”之類的問題?；鶞实拇鸢甘恰按蟾鸥皟芍芤粯印?，而速度就是這一陳述的背景。這項措施是計劃性的，而不是追溯性的，任何人如果想給它施加激勵，最終都會發(fā)現(xiàn)它的準確性會在壓力下逐漸消失（有關這部分內容，可參閱Ron Jeffries寫的《軟件開發(fā)的本質》）。當你要確定功能開發(fā)的優(yōu)先級，要建立客戶的預期，以及進行未來產品規(guī)劃時，了解一個團隊、一個部門或者整個公司的速度如何是基礎。
再也沒有比“任務乘以復雜性”更有效的衡量手段了。就像某些工具一樣，衡量團隊這個級別的提交數(shù)，代碼行數(shù)或者編碼所花費的時間并不必個人層面上有用?？磮F隊寫出的代碼量，看他們花在代碼上的時間，這些跟所做貢獻的價值之間根本就沒有關系。
很多組織在沒有任何不可改變的衡量措施的情況下也能做得紅紅火火。如果有用的軟件對于目標以及開發(fā)工作的主要衡量手段（雖然難以量化）來說都很容易理解，并且輸入被相應降低了優(yōu)先級的話，那這個指標的潛在意義要大得多。這樣一來，開發(fā)人員可以無拘束地去做出自己的最好的表現(xiàn)，而不用受到時間和地點的限制。這可以是朝九晚五，也可以不是。有些人會出于個人喜好或者需要，選擇在早上或者深夜完成大部分的工作。而有的人則可能更適合零敲碎打：這個時候干1小時，然后過一陣子再干幾個小時。有的人喜歡在家里干活，有的愿意在辦公室工作，有的喜歡在路上干活。這屬于功能，而不是錯誤。這種做法強調真正的生產力，而不是生搬硬套進某種可觀察的機械主義，而且這樣還可以為更加深厚的人才庫提供支持，比方說那些上班族父母以及殘疾人。關于結果導向的工作環(huán)境（ROWE），關于遠程辦公，關于減少在會議上花費的時間，以及靈活的工作時間的好處的文章有很多，也討論了很多。所有這些都是真正精明的生產效率指標的體現(xiàn)。
有個說法叫做你考核什么就得到什么。按照這個說法，你就應該只考核你真正想要的東西，而不管這個東西能不能畫成折線圖。對于某些人來說，去做或管理沒法簡化成數(shù)字的工作可能會令人沮喪。但是對于像軟件開發(fā)這樣微妙而抽象的工作來說，我們越是深入細節(jié)，就越無法實現(xiàn)自己的目標。有用的軟件是我們的目標，除此以外，我們不應接受（或衡量）任何其他的東西。
譯者：boxi。
本文來自翻譯, 如若轉載請注明出處。
