彌合工程師與管理者在開發者生產力認知上的差距。軟件工程管理者都希望開發者盡可能高效地工作。但在現實中我們也常常聽到開發者抱怨許多原本為了提升開發者生產力而引入的系統、工具和流程實際效果卻適得其反甚至讓他們更難專注于真正有價值的工作。為了找出這種認知錯位的根源我們面向開發者社區開展了一項小規模調研希望了解開發者究竟如何看待自己的生產力。對于工程領導者來說理解這些結果非常重要。高質量代碼的持續交付和開發者的士氣、工作滿意度以及整體績效密切相關。工程管理的最終目標是幫助開發者發揮出最佳水平。這也意味著管理者不能只從報表和指標出發理解開發者生產力更需要理解開發者自身對生產力的真實感受。開發者生產力為什么越來越重要預算充足、團隊快速擴張的日子已經過去至少在當下是這樣。全球軟件開發團隊都面臨著相似的挑戰預算收緊、效率審查加強、強制返崗以及大規模裁員帶來的不確定性。在這樣的行業環境下理解開發者生產力不只是為了“讓開發者做得更多”更是為了幫助管理者創造更好的工作環境讓團隊在資源更有限的情況下完成更多真正有價值的工作。同時這也有助于發現當前研發流程中的浪費環節。例如如果某些工具或耗時耗力的會議正在擠壓開發者的專注時間那么減少這些干擾就可能帶來雙贏企業節省了成本開發者也能獲得更好的工作體驗。對于一些跨部門協作頻繁的團隊來說借助Worktile這類通用項目協作系統將任務、項目、文檔、日歷和審批等信息統一管理也能減少重復溝通和低效會議讓團隊把更多時間留給真正重要的工作。很多管理者可能沒有意識到一些看似能提升生產力的機制比如頻繁的進度檢查會議實際上可能會降低開發者的工作效率。反過來真正有效的流程設計也能幫助管理者看清哪些機制確實在提升開發者生產力。通常來說更合理地安排協作會議或者設立無會議日往往會對開發者生產力產生積極影響。因為這些做法能讓開發者把更完整的時間投入編碼而不是在一場場會議之間不斷切換上下文只能用碎片時間推進工作。當然每個團隊的情況都不同。最好的方式仍然是通過一對一溝通直接詢問工程師哪些因素最影響他們的工作狀態哪些流程真正幫到了他們哪些機制正在消耗他們的效率開發者和管理者一樣都希望提高生產力調研顯示當開發者感覺工作進展順利、節奏穩定時他們的幸福感和滿足感最高。換句話說開發者希望自己更高效管理者也希望他們更高效。雙方的目標并不沖突真正的問題在于雙方對“生產力”的理解并不完全相同。對開發者來說生產力往往和“心流狀態”密切相關。所謂心流狀態指的是工程師完全沉浸在工作中保持高度專注并持續高效產出的狀態。這并不是一句空泛的說法而是一種真實存在的工作節奏。開發者只有在這種狀態下才更容易發揮出自己的最佳水平。當開發者頻繁受到打擾或者被復雜流程阻礙而無法進入心流狀態時工作就會變得混亂、繁瑣也更容易令人沮喪。同樣重要的是開發者需要感受到自己正在對代碼庫、團隊乃至整個組織做出有意義的貢獻。一位開發者在調研中說道“我希望自己能對團隊或整個組織產生影響。缺乏生產力、工作量不足或者長期從事瑣碎工作都會讓我感到沮喪。”另一位開發者也分享道“如果我無法保持高效我會覺得工作變得更難也更難享受它。當我效率很高時一天過得很快而且我也很享受自己正在做的事情。”當開發者長期感覺自己效率低下時挫敗感和不滿情緒會不斷累積進而讓他們變得消極、缺乏動力甚至逐漸失去對工作的熱情。對于希望打造優秀開發者體驗、持續交付高質量產品的團隊來說這顯然不是一個好信號。如何衡量開發者生產力團隊層面的生產力通常更適合用量化方式衡量而個人層面的生產力往往更需要結合定性視角來理解。大多數組織在衡量開發者生產力時更關注指標驅動的方法例如代碼變更數量、故事點數、已完成工單數量等并將這些結果逐級匯報給高層管理者。然而調研顯示開發者在判斷自身工作效率時往往會使用更偏定性的標準例如自己在計劃內工作和計劃外工作上分別花費了多少時間是否擁有足夠的專注時間是否真正推進了重要事項。在不同場景下同時使用這兩類方法仍然很有必要。例如通過比較六個月前和現在每個迭代周期交付的故事點數可以觀察團隊生產力隨時間變化的趨勢判斷團隊整體效率是在提升還是下降。與此同時當團隊層面的生產力指標沒有達到預期時一些更定性的線索可能更有價值。例如開發者是否花費了大量時間處理臨時問題、調試突發故障或者反復向同事解釋背景知識。對于希望系統化衡量和提升研發效能的團隊來說PingCode這類智能化研發管理工具可以將目標、需求、項目、開發、測試、發布和 Wiki 知識沉淀等環節打通讓研發過程中的數據更自然地流轉起來幫助管理者在團隊指標與個人體驗之間建立更完整的觀察視角。何時使用團隊層面的生產力指標衡量開發者生產力最傳統的方式是從團隊層面進行評估。對大多數團隊來說這通常意味著使用故事點數、迭代速度、已解決問題數量或完成工單數量來衡量團隊在某個迭代周期或時間段內的表現。這些宏觀指標是評估團隊整體績效的重要組成部分。通過持續追蹤故事點數或交付速度決策者可以了解團隊的長期發展狀態并獲得更穩定的速度數據從而更準確地估算未來的交付周期。此外團隊層面的指標也能幫助管理者觀察團隊成員休假、人員變動或其他產能影響因素對交付節奏造成的影響。但問題在于團隊層面的指標并不能完整反映開發者的真實感受也不適合簡單地用來評價個人績效。如果一對一溝通只關注“你這周交付了多少故事點”管理者很可能會忽略許多重要信息。開發者可能在那一周參加了太多會議可能缺乏足夠清晰的優先級可能被大量臨時事務打斷也可能遇到了某個重大技術障礙。因此除了團隊層面的量化指標管理者還必須關注更細微、更定性的生產力信號。何時關注個人層面的開發者生產力團隊由一個個具體的人組成。每個人的動機、家庭情況、壓力承受能力和工作節奏都不同。因此采用一刀切的激勵方式很難真正激發所有成員的潛力。從個人層面思考開發者生產力往往比單純從團隊層面觀察更有價值也更容易得到可執行的洞察。個人層面的衡量維度可以包括專注工作時間、投入明確優先事項的時間、發布新功能所需時間以及被計劃外工作打斷的頻率。同樣需要注意的是基于團隊指標的生產力衡量有時會滯后于個人層面的生產力問題。也就是說當團隊指標已經明顯變差時問題可能已經持續了一段時間。因此管理者有必要更早關注個人層面的生產力信號以便及時發現潛在風險。衡量個人生產力可以從哪里開始對于開發者來說生產力具有很強的主觀性它取決于個人經驗、工作內容和所處環境。以下是一些開發者對生產力的理解。第一能夠在不受干擾的狀態下專注完成任務。“對我來說高效意味著能夠很好地專注于當前任務比如開發新功能或修復錯誤。”第二能夠穩步推進而不是反復倒退。“在主要優先事項上持續前進避免因為質量問題而頻繁返工。”第三能夠感受到自己的工作產生了業務影響。“真正重要的是業務影響。這與故事點數、提交的 PR 數量或代碼提交次數無關這些指標有時會產生誤導。關鍵在于它對業務指標產生了多大推動作用。”第四能夠看到代碼庫中真實、可見且有意義的改進。“我喜歡看到代碼庫中出現可見的改進比如代碼差異中的變化以及最終成功部署上線的功能。”從這些回答中可以看到幾個關鍵主題開發者希望擁有較長時間的專注工作環境不被頻繁打斷希望直觀地看到自己對代碼庫產生的影響也希望理解自己的工作如何為公司的整體目標做出貢獻。對于管理者來說理解這些主題有助于和開發者圍繞生產力展開更深入的對話。管理者應當帶著好奇心發問而不是只用指標下判斷。例如在一對一溝通中你可以詢問開發者他們的日程是否被重復會議或臨時任務占據每周是否有足夠的專注工作時間他們是否能看到自己對代碼庫的貢獻他們是否理解自己正在做的事情如何影響團隊和業務目標這些基于好奇心的問題能幫助管理者更準確地理解開發者的真實狀態也能幫助管理者找到提升個人生產力的具體切入點。將這些個人層面的洞察與團隊層面的量化指標結合起來才能更全面地理解團隊的生產力狀況。當然并不是每個人都能遇到主動提出這些問題的管理者。在這種情況下開發者也需要學會為自己爭取空間主動表達自己在專注時間、工作影響、流程阻礙和個人成長方面的真實感受。最后想說的提升開發者生產力不能只看團隊層面的數字也不能只依賴個人感受。團隊層面的指標能夠展現整體表現并為交付預測提供依據而個人層面的信號則有助于解釋這些指標背后的原因。真正有效的開發者生產力管理需要把兩者結合起來既關注團隊整體交付趨勢也關注每位開發者能否進入心流狀態、完成有意義的工作并清楚看到自己的貢獻。只有當管理者真正理解開發者如何看待生產力團隊才有可能建立更健康、更高效也更可持續的軟件交付方式。