編譯·整理 Y Chen
怎麼評估開發人員的績效？麥肯錫：懂 3 種指標，就能評估軟體工程師生產力
要觀察一位業務適任與否，可以靠做到多少業績、促成多少商業機會來衡量；如果是人資，也能以招募人數，或內部員工滿意度作為標準，但當帶領的團隊成員是軟體工程師或 IT 維運技術人員，主管有辦法使用哪些指標，正確評估他們的績效嗎？對於剛升任管理職的開發者，或沒有相關背景的主管來說，麥肯錫顧問公司（McKinsey & Company）認為這確實不容易，但仍然有正確評估的途徑。
認識最常見的開發生產力標準：SPACE 與 DORA
了解麥肯錫的方法之前，首先應認識當前業界最常使用的衡量架構：SPACE 架構跟 DORA 指標。
SPACE 架構為 GitHub 和微軟（Microsoft）共同提出，《富比士》（Forbes）說明，管理者可以透過 5 個角度，審視哪些事情會影響開發人員的效率。
這 5 個要素分別為 滿意度和幸福感、績效表現（速度快慢、品質高低和能否滿足客戶需求）、交付數量（完成了多少任務）、溝通和協作（團隊之間溝通頻率和效果如何）、效率和流程（開發過程會碰到哪些阻礙），透過 SPACE 架構不只能從更廣泛的角度了解生產力，更跳脫「一位開發者」、能夠看到整個團隊的情況。
假設組織當前採取 DevOps 的架構（編按：結合軟體開發人員（Dev）和 IT 維運技術人員（Ops）之間的流程，有助於更快速、頻繁的開發和推出新版本），那麼 Google 母公司 Alpabet 旗下的調查機構 DORA（DevOps Research and Assessment），就鼓勵使用與其同名的 DORA 指標，判斷產品開發以及交付的表現。
該機構在《2023 DevDops 報告書》中提到 DORA 指標共分為四個面向，以評估 DevOps 團隊的成熟度：平均部署頻率、更新準備時間、平均復原時間 和 變更失敗率。如果是最高等級的菁英（Elite）成熟度，每天都會部署多次，更新版本的失敗需落在 5% 以內，且更新的前置時間與失敗時要復原的時間，必須控制在 1 小時以內。
在麥肯錫眼中，更好的作法是基於 SPACE 架構和 DORA 指標，再加上以機會點為核心的評量方式，會更加全面。
聚焦流程與成果之外，也要關注做事方法和人員配置
麥肯錫解釋，SPACE 架構關注整個開發「流程」，哪些事情會增加或阻礙團隊的效率，而 DORA 指標則更聚焦於結果，加入「機會核心」（opportunity-focused）的指標，則有助於管理者了解「是否有機會改善成果的交付方式與價值？」（詳見下表）。
綜合來看，機會核心的衡量指標背後在意的，是怎麼調配出更有效率的團隊組合和工作方法。舉例來說，內 / 外圈花費時間分別代表寫程式等與產製產品直接相關的活動，以及要測試、檢驗安全性等需要和外部合作的活動，當組織想提高開發效率時，就應該盡可能增加內圈時間的比例。
至於貢獻度分析，則是找出團隊內每個人擅長的項目，並比對他現在的工作任務。假設一位程式寫得最好的工程師，卻必須處理許多外圈事務、無法專心於開發時，想當然整體的工作進度和成果品質都會受到影響。因此主管應該先從個人層面出發，了解每個人擅長的領域，依此分配適當任務。如果發現大家能力過度集中在某個方面時，也能鼓勵其中較具潛力的人才，往團隊當前需要的其餘方向發展。
當心誤用指標，只換來「帳面上」的績效提升
最後麥肯錫提醒，明確的指標有時候是雙面刃，一方面能便於主管更了解團隊的真實情況，但另一方面若誤用或有所偏頗時，反而會造成負面效果。這也是不少開發者社群對於麥肯錫此篇文章的反彈點之一，他們擔心引入過多指標，只會殘害工程師們的生產力。
知名開發者部落格 The Pragmatic Engineer 寫道，以結果論衡量生產力，可能會成為易於被利用的漏洞：一位想晉升的開發人員，會誇大所負責任務的執行效率和成果，最終就只是「帳面上」獲得好看的成果，其實對於整個團隊甚至整間公司都沒有實質幫助。
The Pragmatic Engineer 建議，首先要搞懂到底想解決什麼問題，例如：是要辨認高或低績效者？還是想整頓有問題的團隊？接著在思考解方或設定衡量條件時，應該更著重於「團隊」的成果和其影響，例如：是否有助於提高營收？新版本有沒有解決客戶的問題？而不要把焦點太過放在個人的努力和產出。
