作者：IDCF學員?伍雪鋒???

某知名通訊公司首席敏捷教練，DevOps布道者。2020年到2021年小100人團隊從0-1初步完成敏捷轉型，專注傳統制造業的IT轉型，研發效能提升。

前言

在公司我們常常聽見這么一個流傳的故事，只要這件事情和考核掛鉤，基本上就黃了一半，比如我們道聽途說的亞某遜的組織KPI設計，IXM的銷售部門KPI指標迫使大型機的銷售人員長期推動大型機銷售，某軟的KPI設計讓所有人圍繞Windows系統轉。正所謂你考核什么就會得到什么，慣性思維我們會覺得KPI發揮的都是消極作用，這是真的嗎？

我們不妨問問這個問題是否永遠成立。敏捷轉型本質上也變革，關于變革可參考約翰科特。

今天我就聊聊敏捷轉型過程中如何讓KPI發揮積極的作用。

敏捷轉型的三步法

在軟件交付團隊，過往瀑布交付模型的背景下，項目經理對WBS的依賴性極為重要，項目的范圍、成本、進度、質量、風險都以WBS展開，在當時項目經理衡量項目團隊成員的績效主要看工時、看考勤。

隨著2020年疫情的黑天鵝事件，企業的信息化能力，應對變化的能力成為關鍵要素，2021年數字化轉型在這樣的背景下風生水起。在2020年我們也開啟了數字化轉型的步伐。在開展項目之初，我們團隊內部思考了很長時間，追問數字化轉型的本質是什么？

接下來我就分享一下我們敏捷轉型的三步法。

第一步：營造變革的緊迫感，達成上下同心，目標一致。

前期通過邀請高級經理、管理者、核心業務人員參與IDCF DevOps黑客馬拉松體驗端到端的交付，真實模擬從idea到設計、開發、測試、部署、發布的全流程，理解全生命周期中各角色發揮的作用，通過這種方式避免自嗨，用戶卷入到敏捷轉型的游戲中來，一起玩。

第二步：小范圍試點。

高層松土后，是不是立刻就可以擼起袖子干了呢？我們還需要把核心成員識別出來，找出早期的積極分子、鐵粉兒，接著就挑選3個項目進行小范圍的敏捷運作，組織試運行過程中內部解決不了的疑難雜癥，邀請王立杰老師帶我們乘風破浪，賦能企業內部自己的敏捷種子教練。把這部分項目的成功經驗內部分享，吸引更多的項目試點，參與；同時也能識別出誰是變革追隨者，誰是變革阻攔者。

第三步：績效考核機制的改變。

經過一年的時間，除軟件項目都按照敏捷項目進行運轉，我們一方面要營造一個試錯的環境，給敏捷團隊能夠更快速的學習，獲得正反饋；另一方面也要回答天使投資人：敏捷轉型效果如何？當前處于什么階段？

作為敏捷轉型的牽頭人，需要充當兩者之間的潤滑劑，橋梁。因為使用原始的度量體系，對于轉型后的敏捷團隊不再適用。如何過渡，以及節奏是什么？是轉型需要回答的問題。每次開月會的時候我就見縫插針地引導到新績效考核機制設定的話題，經過小半年的叨叨叨，叨叨叨，管理層實在受不了啦，確實也發現是這么回事兒，于是讓我主導整個IT部門的績效考核新機制設計。?

我腦袋里只有一個想法，這件事要兼容以前的KPI, 同時需要引入敏捷轉型的真北指標。找到那個能夠撬動整個團隊持續迭代的業務指標，這個指標一定要讓每個人都能秒懂。

前期的策略是從個人英雄主義的考核傾向導向最佳敏捷團隊導向，用華為的黑話就是：勝則舉杯相慶，敗則拼死相救。

圍繞轉型的真北指標：用戶提出一條需求到需求得到滿足用了多久？設計我們的組織KPI模型，對于執行團隊首當其沖的是扔個石頭下去，聽聽聲音，看大家是否能夠接受這個概念。下面我舉一個栗子：

潤物細無聲，做敏捷轉型的陪伴者

發現敏捷交付過程中的真問題：無效度量。

單純地講敏捷文化，Sprint計劃會議怎么開，回顧會議怎么開，故事如何拆而沒有好的武器，工程能力方面沒有提升，敏捷團隊沒有趁手的工具，組織心智沒有改變，本質上就是耍流氓。長期作為開發人員，我深刻理解一天要切換十幾個系統才能完成工作的痛苦，每一次切換耗散部分精力，研發一體化的協作平臺對于敏捷團隊的重要性不言而喻。

基于這樣的背景我需要思考是采購還是自研，如下DevOps Report 2020年度報告中使用內部平臺的一個數據詳情：

2020年經過一年時間，IT部門內部完成了DevOps工具鏈1.0版本。

2021年搭建了DevOps工具鏈的2.0版本。

同樣的人一旦配備上趁手的工具，效能10倍+成為可能，干起活來也倍兒有尊嚴感。

首先結合已經有的研發一體化平臺，如何把績效數據轉變為績效信息，最終展示為績效報告成為關鍵。第一件事是沉到所有敏捷團隊中，看看大家是如何使用這個平臺的，有哪些方式可以通過流程、程序去設計，整個績效考核的數據建模就變得尤為重要。

集合Jira的底層數據模型，我們小團隊經過一番設計、培訓就奠定了整個部門的績效數據錄入基礎。

如下為我們從用戶旅程地圖全局視角去設計的一個作業鏈路。

如何通過KPI的設計改變當前的狀況

經過三個沖刺的數據收集，試點，績效數據開始有了積累，IT側的作業可以做到百分百在線，但是如果讓敏捷團隊野蠻生產，績效數據只是一堆數據，如何讓數據發揮作用比數據本身更重要。

這就好比我們引導一個人閉眼進行轉動魔方，一種是隨機性轉動，我們大概需要137億年才能完成，但如果我們每一次都給轉動者一個反饋，這一次是離目標遠了還是近了，只需要2.6分鐘，這就是傳說中的魔方實驗。

這個故事讓我深深感受到了反饋的魔力，于是我們經過九九八十一難從天使投資人那里獲取一小筆費用，作為項目的啟動資金。設計了以最佳敏捷團隊為導向的考核機制，每個沖刺評比一次，小伙伴們再也不用每個禮拜填寫工時計劃、周報了，開發、測試、BA都只需要在Jira上通過任務拖拽，將工作可視化，管理者和使用者都報以擁抱的心態。經過5個沖刺的試運行，效果真的是出奇的好。7月份從傳統的工時考核切換到研發效能考核。

驗證一個組織是否轉型成功，就是要看敏捷轉型團隊撤出后，組織是否依然能夠有效運行，所以我們需要從底層設計一套運行機制，讓整個組織在持續學習與試錯的過程中，快速迭代。

如下為我們團隊的底層思考，找到敏捷轉型的那個基石假設。

實踐分享

需要清晰地定義邊界，你是從用戶視角在度量，還是從內部IT項目的視角在度量，也就是我們常說的Outcome VS Output。

• 組織轉型初期可以循序漸進，先厘清內部的一個研發效能，避免一上來就從全局視角出發，業務部門直接甩鍋所有的問題是IT側的問題，內憂外患導致敏捷轉型舉步維艱，穩定中求發展。

• 明確度量的維度，根據不同的階段，與團隊確認考的邏輯和看的邏輯，先建立安全的環境，收集數據，逐步展開。

• 清晰地定義敏捷團隊的度量指標，需求，開發，測試，設計形成一條完整的交付供應鏈。

• 拉通所有敏捷團隊對項目，故事，任務的顆粒度理解。

• 明確考核指標的定義，計算規則，考核等級，常見的問題。

• 明確業務需求考核的優先級。

• 建立敏捷激勵方案，讓團隊能夠及時獲得正反饋，讓反饋的環轉得更快。

• 通過物質激勵和精神激勵，讓每一個敏捷轉型的小伙伴從被變革轉身為參與者。

總結

經過踩了一年的坑，做一個小小的總結：

• 業務價值是通過團隊間的合作來實現的，IT部門的成功取決于為業務部門提供了什么價值，解決了業務部門什么痛點，組織績效考核要圍繞業務價值設計，避免IT側自嗨。

• 全局優化大于局部優化，績效考核要以業務結果指標為牽引。

• 績效考核要分清是考的邏輯還是看的邏輯，讓團隊快速試錯，營造安全、信任的環境。

• 不要試圖只用績效考核工具和技術來解決人文問題。

• 敏捷轉型的過程中，新的績效考核一定要跟得上，在過渡階段的流程機制不免存在考慮不全面的情況，敏捷團隊會有抱怨，會有要求，轉型團隊的負責人一定要作為潤滑劑，連接管理層和敏捷團隊的橋梁。

• 績效考核要變得有趣，讓團隊從過去的受害者身份變為玩家，參與者。

總結

以上是生活随笔為你收集整理的如何让组织的KPI成为敏捷转型的推手而不是杀手 | IDCF的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。