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

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

輸入測量的問題

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

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

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

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

長話短說，測量輸入是一種不足的技術，因為軟件開發(fā)不是方程式，并且組裝線無法構建代碼。因此，讓我們談談輸出。

輸出測量的陷阱

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

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

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

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

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

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

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

現(xiàn)在，您已經(jīng)被警告不要嘗試使用最糟糕的措施，讓我們來談談一些好的措施。不幸的是，個人績效幾乎無法通過“該團隊成員貢獻”或“該團隊成員不貢獻”的二元狀態(tài)來衡量。而且它不能遠距離測量。 

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

另一方面，團隊績效更明顯。追蹤問題的最佳方法也許就是問，這個團隊是否在數(shù)周至數(shù)月的時間范圍內(nèi)持續(xù)生產(chǎn)有用的軟件？這呼應了敏捷的第三項原則：“頻繁交付工作軟件，從幾周到幾個月不等，而更傾向于縮短時間?！?定期生產(chǎn)有用的軟件的團隊富有成效。一個沒有的團隊應該被問到為什么不這樣做。通常有缺乏生產(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ù)。這是軟件不可回避的事實：與人類有關的遠不止于零和一，而且一直如此。生產(chǎn)力跟蹤工具和激勵計劃永遠不會像工作場所中的積極文化那樣產(chǎn)生巨大的影響。當問責制和健康的溝通融入這種文化中時，最有能力解決這些問題的人們將很快意識到生產(chǎn)力的關鍵時刻。

許多組織將速度作為衡量團隊生產(chǎn)力的首選指標，如果做得對，這可能是了解軟件開發(fā)過程的有用工具。速度是團隊隨時間推移完成的任務的總體度量，通?？紤]開發(fā)人員自己對每個任務的相對復雜性的估計。它回答諸如“該團隊在接下來的兩周中可以做多少工作？”之類的問題?；鶞蚀鸢甘恰按蠹s與過去兩周一樣”，而速度是該陳述的背景。這是一項計劃性措施，而不是追溯性措施，任何嘗試對其施加激勵的人都將發(fā)現(xiàn)其準確性在壓力下蒸發(fā)（有關此問題的更多信息，請參閱軟件開發(fā)的本質(zhì)）。 （羅恩·杰弗里斯）。在確定功能開發(fā)的優(yōu)先級，與客戶設定期望并計劃產(chǎn)品的未來時，了解團隊，部門或公司的速度可能是基礎。

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

許多組織在沒有任何堅決措施的情況下蓬勃發(fā)展。在組織中，有用的軟件既是開發(fā)工作的目標又是主要的（盡管難以量化）測量結果，并且相應地降低了輸入的優(yōu)先級，這具有深遠而深遠的影響。無論何時何地，開發(fā)人員都可以放手去做最好的工作。這看起來可能是9：5。有些人會根據(jù)喜好或必要，在清晨和深夜進行大部分工作。其他人則以零散的方式工作：這里一個小時，那里幾個小時。有些會在家中工作，有些會在辦公室工作，有些會在旅途中工作。這是一個功能，而不是錯誤。它強調(diào)的是真正的生產(chǎn)力，而不是試圖將其折磨成可觀察的啟發(fā)式方法，殘疾人。關于“只有結果的工作環(huán)境”（ROWE），遠程工作，減少在會議上花費的時間和靈活的時間所帶來的好處，已經(jīng)有很多論述，并發(fā)表了很多看法。所有這些都只是精明的生產(chǎn)率指標的體現(xiàn)。

有人說，您得到了您所要衡量的。因此，您僅應衡量自己真正想要的內(nèi)容，無論它是否可以繪制為折線圖。對于某些人來說，做或管理無法減少的工作可能會令人沮喪。但是隨著軟件開發(fā)工作的細致和抽象，我們越深入細節(jié)，就越無法實現(xiàn)自己的目標。有用的軟件是我們的目標，我們不應滿足（或衡量）任何其他要求。