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