在軟件行業(yè)中，定義和衡量程序員的生產(chǎn)率是大白鯨。這是巨額投資的基礎(chǔ)，眾多初創(chuàng)公司的價值主張，也是工程經(jīng)理或CTO職位描述中最困難的部分之一。對于所有經(jīng)驗水平的開發(fā)人員來說，這也是一種焦慮的源泉：您如何知道自己是否做得足夠（無論是全天候還是全天候）？當您所做的一切無形時，應(yīng)如何衡量？可以衡量嗎？在本文中，我將討論生產(chǎn)率衡量的最大陷阱以及幾種實現(xiàn)方法。

與其他領(lǐng)域一樣，在軟件開發(fā)中，許多人從投入和產(chǎn)出的角度來考慮生產(chǎn)力。在美國，專職開發(fā)人員每周工作40個小時，平均年薪為$ 107,510。工時和工資是可見的，易于量化的輸入。然后，開發(fā)人員會定期產(chǎn)生軟件功能，文檔，部署和/或錯誤修復(fù)。這些是輸出。如果開發(fā)人員像我們想象的那樣簡單地編寫軟件，那么提高他們的生產(chǎn)力應(yīng)該和要求他們工作更多小時或付給他們更高的薪水一樣簡單。當然，這是一個童話。開發(fā)人員和軟件都不會那樣工作。

輸入測量的問題

“工作時間”是用作衡量工作績效的幾種錯誤指標之一。我之所以首先提到它，是因為它是一個經(jīng)常檢查的默認設(shè)置，是阻力最小的路徑。如果公司不故意避免這樣做，則遲早會惡化到只有一個小時的環(huán)境。在大范圍流行的遠程工作之外，僅數(shù)小時的環(huán)境的癥狀很容易識別。上班時間被認為是無法商量的，并且在辦公室中出現(xiàn)被視為有人正在工作的證據(jù)。任何試圖提早幾個小時離開辦公室的人都會遇到敵意（有時像眉毛抬起一樣柔和，有時甚至更無禮）。任何在深夜工作或在周末進來的人都被視為高績效。這種“最后離開體育館”文化的誘因是不幸的：開發(fā)商被迫花費越來越多的時間在工作上，沒有其他任何方式來證明自己的價值，并被迫僅次于關(guān)注他們的工作成果。隨著時間的流逝，工作場所越來越成為每個人都在工作但無所事事的地方。

問題不止于此。如果我們假設(shè)所有工作都是“積極工作”，也就是說，所有工作都代表著朝著目標的進展，那么我們就是錯誤的。在精疲力竭，分心或生病時工作的開發(fā)人員傾向于熟悉“負工作”的概念：工作做得很差，必須撤消或在以后進行補償，從而增加而不是減少剩余的工作量。軟件開發(fā)是復(fù)雜，抽象，專心的工作，因此對開發(fā)人員的心理狀態(tài)敏感。就是說，有隱藏的信息在起作用：焦慮，沮喪，倦怠，工作中的毒性，悲傷，微侵略以及其他一百多種可以在任何一天降低或轉(zhuǎn)化個人生產(chǎn)力的事物。如果公司文化要求一周又一周的長時間工作，或者甚至只有八小時的工作日，而沒有靈活性或休假時間，那么開發(fā)人員將不可避免地將時間花在負面工作上：他們熬夜的工作實際上比回家時要少較早。而且由于疲勞，他們第二天的工作量也會減少。

另一方面，僅小時的環(huán)境并不是最壞的情況。它有一個公平的幽靈：如果兩個開發(fā)人員都在工作相同的小時數(shù)，那么就存在一個平等的清晰維度。他們似乎都沒有懈怠，似乎也沒有做得比他們應(yīng)得的要多。如果他們的產(chǎn)量低于預(yù)期，那么，至少他們會投入時間。而且，“工作時間”指標不會像某些指標那樣明顯地激勵不良代碼。因此，盡管這是一個很差的指標，甚至在很多情況下都會影響生產(chǎn)率，但我們應(yīng)該討論更糟糕的指標。

考慮一下軟件開發(fā)的其他顯而易見的投入：金錢。我開玩笑地向我的經(jīng)理建議過一兩次，生產(chǎn)率應(yīng)該用薪水來衡量，如果薪水加倍，我將以世界一流的軟件架構(gòu)師的水平來編寫代碼。當然，您憑直覺知道這很荒謬。向某人多付錢并不能立即使他們提高生產(chǎn)力（盡管可能是間接的，而且規(guī)模有限）。但是，在我看來，金錢和工時屬于同一類：不僅是投入，而且是輔助性投入，只能持續(xù)提高生產(chǎn)率。一種是由雇主提供的，另一種是由雇員提供的，但是這種交換是附帶創(chuàng)建有用的軟件的。

長話短說，測量輸入是一種不足的技術(shù)，因為軟件開發(fā)不是方程式，并且組裝線無法構(gòu)建代碼。因此，讓我們談?wù)勢敵觥?/span>

輸出測量的陷阱

在這里，也許是違反直覺的，我們發(fā)現(xiàn)了軟件開發(fā)世界中許多最糟糕的指標。有些人掉入了一個陷阱，認為軟件開發(fā)的工作輸出是代碼行或提交到版本控制中。當然，這些是過程的一部分，但它們更像副產(chǎn)品，而不是結(jié)果。嚴格來說，不能解決問題的代碼行總比沒有代碼差。因此，通過開發(fā)人員貢獻多少代碼來衡量開發(fā)人員的生產(chǎn)力，就像通過他們產(chǎn)生多少廢棄物來衡量發(fā)電廠，還是通過他們通過多少賬單來衡量國會？與實際價值成正比。

更糟糕的是，游戲這些測量非常容易。按代碼行付款的開發(fā)人員可以輕松地在一天之內(nèi)賺取全年的薪水，而不會產(chǎn)生任何業(yè)務(wù)價值。大多數(shù)開發(fā)人員都會采用更巧妙的方法，但是同樣，您應(yīng)該小心自己的期望。

當一項措施成為目標時，它就不再是一項好的措施。

開發(fā)人員大體上都了解這一點，但是令人尷尬的是，我們?nèi)匀粌A向于使用提交和代碼行作為眾所周知的孔雀羽毛。當我們看到Google（代表2015年所有Google品牌產(chǎn)品）跨越20億行代碼，或者Windows團隊每天進行超過8400次代碼推送時，即使我們都不知道這兩個代碼都可以是什么使Google或Windows有用。

無論如何，我們都可以將這些措施添加到無效代理列表中。如果要解決的問題稍微多一點，則根據(jù)已修復(fù)的錯誤，已完成的任務(wù)或所提供的功能來衡量生產(chǎn)率同樣是徒勞的。如果目標是修復(fù)更多的錯誤，則開發(fā)人員可以故意編寫有錯誤的軟件，然后編寫大量的修復(fù)程序；例如，或者，為了實現(xiàn)相反的目標，他們可以通過盡可能慢地編寫功能來減少錯誤計數(shù)。如果目標是發(fā)布功能，則他們可以快速而幼稚地編寫它們，從而導(dǎo)致軟件運行緩慢且?guī)缀鯚o法運行。如果目標是完成任務(wù)，那么整個團隊都可以融入政治，因為每個開發(fā)人員都在爭奪最簡單（或最被高估）的人。一個好的團隊也許可以忽略您的措施而只是工作，但是即使在最好的情況下，糟糕的措施也是難以忽視的障礙。

一些組織表現(xiàn)出深刻的妄想癥，將間諜軟件安裝在員工的計算機上，以跟蹤諸如鼠標移動，按鍵和屏幕截圖之類的瞬間工作的細節(jié)。對我而言，目前尚不清楚在這種審查之下，任何員工如何開展創(chuàng)意工作。我希望大多數(shù)開發(fā)人員都會立即退出。但是，與上述措施一樣，這最明顯的失敗之處在于它沒有捕獲到對企業(yè)或其客戶真正有意義的任何東西。您會因為他們在Reddit上花費大量時間或沒有充分移動鼠標而對高效率的開發(fā)人員進行培訓嗎？您會因為他們花很多時間在Visual Studio中打字而又難以合作而晉升為開發(fā)人員嗎？一些經(jīng)理顯然這樣做了，但是希望我們大多數(shù)人都比這更聰明。

在正確的水平上衡量生產(chǎn)力

現(xiàn)在，您已經(jīng)被警告不要嘗試使用最壞的措施，下面我們來談?wù)勔恍┖玫拇胧?。不幸的是，個人績效幾乎無法通過超出“此團隊成員貢獻”或“此團隊成員不貢獻”的二元狀態(tài)來衡量。而且它不能在遠處測量。

軟件開發(fā)團隊不是一群孤立地工作的人；每個團隊成員的工作成果都是其所有隊友的工作成果的函數(shù)，更不用說一天中的一些有意義的，不可衡量的互動。單個作品的相互依存和細微差別過于復(fù)雜，無法由外部觀察者來衡量。例如，某些團隊成員是團隊其余成員的力量乘數(shù)-他們可能無法獨自完成很多工作，但如果沒有他們的幫助和影響，他們的隊友的生產(chǎn)力就會大大降低。像這樣的人是有效的工程組織的秘密武器，但是他們的生產(chǎn)力無法以個人規(guī)模來衡量。其他團隊成員可能不會產(chǎn)生很多功能，而是充當“代碼管理員”，無論他們身在何處都應(yīng)進行仔細的測試，清理和重構(gòu)代碼，以便其隊友可以更快，更輕松地開發(fā)功能。他們作為個人的生產(chǎn)力也是無法衡量的，但是它們對團隊生產(chǎn)力的影響卻是指數(shù)級的。即使對于定期發(fā)布新功能的程序員而言，生產(chǎn)率在短期內(nèi)也往往有很大差異，從而難以進行任何特定的跟蹤。出于這樣的原因，個人績效最好留給個人貢獻者自己和彼此衡量。

另一方面，團隊績效更明顯。追蹤問題的最佳方法也許就是問，這個團隊是否在數(shù)周至數(shù)月的時間范圍內(nèi)持續(xù)生產(chǎn)有用的軟件？這呼應(yīng)了敏捷的第三項原則：“頻繁交付工作軟件，從幾周到幾個月不等，而更傾向于縮短時間?！倍ㄆ谏a(chǎn)有用的軟件的團隊富有成效。應(yīng)該問一個沒有的團隊為什么不這樣做。通常有正當理由缺乏生產(chǎn)力。大多數(shù)非生產(chǎn)性團隊希望提高生產(chǎn)效率，而大多數(shù)生產(chǎn)性團隊希望提高生產(chǎn)率。

可以通過簡單，整體的觀察在組織規(guī)模上衡量團隊的生產(chǎn)力。而且由于隊友往往很了解彼此的貢獻（無論是否可衡量），因此可以通過良好的組織習慣來發(fā)現(xiàn)個人生產(chǎn)力方面的任何嚴重缺陷，例如，經(jīng)理與直屬人員之間經(jīng)常進行一對一的訪談報告；定期收集誠實，匿名的反饋；并鼓勵每個團隊成員通過報告自己的成就并對失敗承擔責任來行使個人責任感。

這里有很多取決于人，而不是趨勢圖和原始數(shù)據(jù)。這是軟件不可回避的事實：與人類有關(guān)的遠不止于零和一，而且一直如此。生產(chǎn)力跟蹤工具和激勵計劃永遠不會像工作場所中的積極文化那樣產(chǎn)生巨大的影響。當問責制和健康的溝通融入這種文化中時，最有能力解決這些問題的人們將很快意識到生產(chǎn)力的關(guān)鍵時刻。

許多組織將速度作為衡量團隊生產(chǎn)力的首選指標，如果做得對，這可能是了解軟件開發(fā)過程的有用工具。速度是團隊隨時間推移完成的任務(wù)的總體度量，通?？紤]開發(fā)人員自己對每個任務(wù)的相對復(fù)雜性的估計。它回答諸如“該團隊在接下來的兩周中可以做多少工作？”之類的問題。基準答案是“大約與過去兩周一樣”，而速度是該陳述的背景。這是一項計劃性措施，而不是一項追溯性措施，任何嘗試加入激勵措施的人都會發(fā)現(xiàn)其準確性在壓力下逐漸消失（有關(guān)此內(nèi)容，請參閱Ron Jeffries撰寫的《軟件開發(fā)的本質(zhì)》）。在確定功能開發(fā)的優(yōu)先級，與客戶設(shè)定期望并計劃產(chǎn)品的未來時，了解團隊，部門或公司的速度可能是基礎(chǔ)。

沒有比“任務(wù)乘以復(fù)雜性”更有效的措施了。像某些工具一樣，衡量提交，代碼行或編碼所花費的時間，在團隊規(guī)模上比在個人規(guī)模上沒有更多用處。團隊產(chǎn)生的代碼工件的數(shù)量，他們花在代碼工件上的時間與他們的貢獻價值之間根本就沒有關(guān)系。

許多組織在沒有任何堅決措施的情況下蓬勃發(fā)展。在組織中，有用的軟件被公認為是目標和主要（盡管很難量化）的標準。