一位測試經理,我們稱她為瑪麗,與開發負責人丹舉行每週會議。「我們目前的錯誤數量是多少?」她在最近一次會議中問道。丹回答:「我們清除了三個優先級一錯誤,修復了四個優先級二錯誤,並清除了創紀錄的十二個優先級三錯誤。這是一個相當不錯的一週,對吧?」
瑪麗看著開發負責人,輕輕搖了搖頭,回答說:「不幸的是,我們的客戶回報了五個優先級一錯誤、六個優先級二錯誤和十五個優先級三錯誤。你下週需要更努力了。」丹感到沮喪和不知所措,因為他錯失了目標,他離開會議時心想要求他的團隊再加班一個週末。
管理階層熱愛他們的度量標準。他們的思考模式類似這樣:「我們需要一個數字來衡量我們的表現。數字能讓人專注,並幫助我們衡量成功。」雖然本意良好,但數字管理法卻會直覺地導致有問題的行為,並最終損及更廣泛的專案和組織目標。度量標準本身並非壞事;只是經常被不適當地使用。本文說明了管理階層傳統使用度量標準所造成的許多問題,並提供了解決這些功能障礙的替代方案。
2013 年 2 月 19 日
告訴我您如何衡量我,我將告訴您我的行為。
從數字管理的角度來看度量標準的組織遵循的流程如下
管理階層提出目標並制定衡量標準
管理階層為執行工作的員工設定一個長期間(3-6 個月至一年)的目標
管理階層僅傳達目標(根據商定的度量標準)
執行工作的員工盡一切努力達到目標數字
此程序鼓勵以以下目的過度載入指標
指標作為目標 – 數值指標讓人們特別容易將其用作傳達目標的唯一方法。告訴人們一個刻度和一個數字通常比解釋一個更複雜的目標容易得多。目標通常是一個任意數字,有些組織甚至花費大量時間來確定這個數字應該是多少。
指標作為績效衡量 – 有一個既定的數字而不是一個明確的目標,現在經理很容易使用相同的衡量來追蹤從事這項工作的人員朝著目標前進的速度。許多組織將這些數字連結到個人績效目標。
指標作為最佳實務 – 將指標同時用作目標和績效衡量會產生一個意外的副作用 – 暗示此指標是朝著目標努力的最佳方法。當一個獨立方使用數值目標衡量其他人時,這會對從事這項工作的人員施加更大的壓力,只要達到一個既定的數字即可。由於他們只根據此指標的績效進行衡量,因此他們會盡一切所能來達成那個特定指標。這表示沒有其他方法最能達成最終目標。
以多重目的過度載入單一指標會造成許多問題,特別是在處理軟體等知識工作時。指標是更複雜屬性的簡化。簡化複雜性的代價是失去對真實最終目標的視線,並導致次佳結果。
我們來看一個例子
一位測試經理,我們稱她為瑪麗,與開發負責人丹舉行每週會議。「我們目前的錯誤數量是多少?」她在最近一次會議中問道。丹回答:「我們清除了三個優先級一錯誤,修復了四個優先級二錯誤,並清除了創紀錄的十二個優先級三錯誤。這是一個相當不錯的一週,對吧?」
瑪麗看著開發負責人,輕輕搖了搖頭,回答說:「不幸的是,我們的客戶回報了五個優先級一錯誤、六個優先級二錯誤和十五個優先級三錯誤。你下週需要更努力了。」丹感到沮喪和不知所措,因為他錯失了目標,他離開會議時心想要求他的團隊再加班一個週末。
在這個非常簡單的故事中,所選的指標符合讓會議快速進行的一個好處。丹回報他的結果後,兩個人都很快了解進度,瑪麗回應時也是如此。不幸的是,傳遞有用軟體的隱含目標錯失了,丹離開會議時帶著一個更有可能導致進一步軟體問題並拖累軟體品質的解決方案。
瑪麗陳述她的目標的方式對丹施加了壓力,要求他減少錯誤數量。這似乎是一個令人欽佩的目標。雖然減少錯誤數量是一個好的目標,但它也會導致一個非常被動的解決方案。丹離開會議時心想,他必須更加努力工作。瑪麗提出的問題忽略了更廣泛的目標,她沒有提出關鍵問題,引導丹和他的團隊修復錯誤存在的根本原因。如果不解決這個根本原因,丹和他的團隊註定要一輩子修復錯誤。
丹正在經歷單迴路學習[1]。單迴路學習是重複嘗試解決同一個問題,沒有方法變化,也不會質疑目標。如果丹希望擺脫這個惡性循環,他需要採取不同的做法。不適當的軟體使用讓丹遠離提供有用軟體和提升整體軟體品質的最終目標。愛因斯坦對瘋狂的定義似乎很適合這裡:「不斷重複做同一件事,卻期待不同的結果。」
組織喜歡指標,因為這讓設定目標更簡單,並阻止人們質疑目標背後的目的。這讓管理者產生組織效率的錯覺。與強勁指標相關的強勁誘因迫使人們專注於工作的某個部分,忽略其他可能讓目標更成功的促成因素。組織必須小心這種積極破壞性的關注,這會導致人們忽略其他重要因素。
即使敏捷技術也無法保護團隊免於測量和追蹤錯誤數字所驅動的不良行為。例如,敏捷團隊經常使用使用者故事卡[2]進行開發工作。團隊經常將這些小增量的工作視覺化,並在團隊的軟體生命週期中移動。典型的流程可能如下所示,理想的故事流程從左到右移動
圖 1:故事牆範例
管理階層和產品管理部門經常問:「那個功能什麼時候可以完成?」團隊經常將此解讀為編碼完成的時間,屈服於測試和生產路徑是軟體流程中微不足道且無關緊要的部分的想法。專案管理透過詢問「我們這週編碼完成多少個故事?」而不是更好的問題「我們滿意發布給最終使用者的故事有多少個?」或更好的「我們發布給最終使用者的故事有多少個?」來強化這種觀念。更好的問題是:「我們的使用者從最近的版本中發現多少價值?」
團隊想要做正確的事,而這些問題和指標因此驅使開發人員專注於讓故事開發完成。讓我們看看過度專注於這個次佳目標的後果
馬爾科姆是一位行銷代表,他總是對開發人員為他建構的內容抱持濃厚興趣,因此他會盡可能頻繁地拜訪團隊。他經常與開發人員丹交談,詢問他的功能什麼時候可以完成。丹不希望讓馬爾科姆失望,因此努力專注於完成馬爾科姆要求的任何事,他知道馬爾科姆很快就會回來詢問進度。他經常在心裡想:「這個功能一定非常重要。」團隊裡最新的測試人員提姆經常需要找開發人員,例如丹,了解如何觸發新開發的功能。
某天,Tim 走向 Dan,說:「嗨,Dan!我真的很需要你的協助,才能了解如何測試你上週完成的功能。」Dan 正承受著交付快照的壓力,因此說:「你自己不能做任何事嗎?我需要完成這個功能,這樣 Malcolm 才會停止催促我。」Tim 對 Dan 的回應感到震驚,回到自己的座位,並等待。他心想:「在 Dan 協助我之前,我什麼事都做不了。」
這種情況每週都會發生,隨著時間推移,等待測試的故事堆積如山。最後,Malcolm 召集團隊開會,因為他擔心兩個月前要求的功能至今仍未在製作中。Dan 驚訝地表示,他一個月前就已完成。Tim 羞怯地回答:「我無法測試那個故事,因為我需要 Dan 的協助,而他一直忙於其他工作。我不想打擾他。」
我們可以從這個故事學到什麼?首先,對 Malcolm 來說重要的是工作流程的順利進行。即使 Malcolm 詢問某項工作何時會完成,他真正想要的是能夠在製作中使用它。我們知道 Tim 沒有完成工作所需的知識,而 Dan 完成更多工作的壓力,也阻止了 Tim 獲得更多知識。最終結果是測試中的工作不斷堆積,從未發布,而 Malcolm 則困惑於自己為何未收到他要求的功能。這就是為什麼像看板軟體開發這樣的程式鼓勵明確進行中的工作限制。這些限制迫使人們在出現瓶頸時互相協助。這些 WIP 限制有助於克服不良行為,這些行為會在人們以個人生產力而非整體交付價值的錯誤指標衡量時出現。這本書,精實軟體開發,強調衡量最終結果而非僅是流程中的一小部分的重要性,並提出他們稱為「最佳化整體」的原則。最佳化整體表示確保所使用的指標不會對交付有用軟體的實際目標造成次佳行為。
鑑於因不適當使用量度而出現的不良行為,這是否表示量度沒有容身之處?當然有量度的容身之處。需要的是不同的方法。使用以下準則引導您更適當地使用量度
明確將度量標準連結至目標
優先追蹤趨勢,而非絕對數字
使用較短的追蹤期間
當度量標準不再驅動變革時,請變更度量標準
我們將使用以下各節探討這些準則的含義。
在傳統風格中,管理層決定特定目標的最佳量度是什麼。然後,管理層根據該量度設定目標。然後,管理層僅向執行工作的人員傳達此目標,通常以數字表示。用於監控進度朝向目標的量度與實際目標本身之間的界線模糊不清。隨著時間推移,量度的背後原因消失,人們專注於達成目標,即使該量度不再相關。更適當地使用量度是確保進度的所選量度(量度)被挑出來,但與其目的(目標)相關。
例如,在軟體開發背景中,您可能會看到類似這樣定義的量度
方法必須少於 15 行。方法不得有多於 4 個參數。方法圈複雜度不得超過 20。
適當地使用量度,每個量度都應清楚地連結到其原始目的。追蹤和監控的現行機制必須與其目標脫鉤,並明確說明該目標,以幫助人們更了解量度的意圖。量度在更豐富的背景下存在,引導人們朝向目標做出更適當、務實且最終有用的決策。沒有其目的,所付出的努力意味著人們找到方法來創造性地玩弄他們的系統,最終偏離真正的目標。以下是其樣貌
我們希望我們的程式碼不那麼複雜,更容易變更。因此,我們應致力於撰寫短方法(少於 15 行),並具有低圈複雜度(少於 20 較佳)。我們還應致力於擁有少數參數(最多四個),以便方法保持盡可能專注。
將指標明確連結至目標,能讓人們更有效地質疑其相關性,找出其他滿足需求的方法,並幫助人們了解數字背後的意圖。如果沒有明確的目標,人們可能會無意間找到方法,與隱含的目標背道而馳。例如,許多技術可能有助於減少方法長度,但如果沒有正確的意圖,這些技術可能會因為更難閱讀而增加整體的複雜性。
軟體開發的本質表示,大多數的工作都是知識工作,因此很難觀察。很容易監控活動(他們在電腦前坐了多久),但很難觀察他們產生的價值(滿足實際需求的有用軟體)。人們離程式碼越遠,就越難欣賞所涉及的複雜性。這表示,對於離工作最遠的人來說,要真正知道監控進度時最佳的衡量標準,是非常困難,甚至是不可能的。
轉向更適當的使用指標表示,管理階層無法孤立地提出衡量標準。他們必須不再自欺欺人,認為自己知道監控進度的最佳方法,並停止強制執行可能與目標最相關或最不相關的衡量標準。相反地,管理階層有責任確保始終關注最終目標,與對系統最了解的人員合作,提出最合理的衡量標準,以監控進度。
管理階層發現指標難以抗拒,因為它將組織的複雜性提煉成每個人都能理解的東西,也就是數字。很容易看出一個數字比另一個數字大或小,或一個數字與另一個數字相差多遠。要看出該數字是否仍然相關,就困難多了。這種傳統的管理方法喜歡使用這些指標,因為當目標達成時,很容易溝通。「只要達到這個數字,我們就沒問題了」。
當你將定性和高度詮釋性的問題(想想生產力、品質和可用性)轉換成數字時,任何數字都是相對的和任意的。程式碼覆蓋率在 5% 和 95% 之間可能存在顯著差異,但 94% 和 95% 之間真的有顯著差異嗎?選擇 95% 作為目標有助於人們了解何時停止,但如果要獲得最後的 1% 需要大量的努力,那真的值得嗎?這只是人們必須在自己的組織環境中主觀解決的事情。
觀察趨勢比是否達成目標提供了更多有趣的資訊。找出是否達成目標很容易。困難的工作,以及管理階層必須與具備完成技能的人員合作的工作,是觀察趨勢,看看它們是否朝著預期的方向和足夠快的速度前進。趨勢提供了組織複雜性所產生的績效的領先指標。當趨勢越來越遠離預期狀態時,顯然專注於數字的差距是沒有意義的。
關注趨勢很重要,因為它根據任何已實施變更的實際資料提供回饋,並為組織創造更多反應選項。例如,如果團隊趨離理想狀態,他們可以自問是什麼原因導致他們遠離目標,以及他們可以採取什麼措施。它比僅在計算出數字之前盡可能多做一些事情來得更早採取行動。如果團隊發現自己趨向理想狀態,他們可以自問是什麼幫助他們朝著目標前進,以及還能採取什麼措施來加速這個速度。衡量團隊會鼓勵人們進行更多實驗。調整一件事並觀察它對趨勢的影響,監控你在理想狀態中的位置,並知道何時停止。
任意的絕對數字也會造成無助感,特別是在朝著目標前進的進度緩慢,而且依賴於其他部門或企業政策(超出小組控制範圍)會阻礙進一步進展時。趨勢有助於將人們的努力集中在朝著正確方向前進,而不是在看似無法解決的差距中陷入癱瘓。
更適當的指標使用需要管理階層更多參與趨勢的報告和記錄,因為圍繞團隊的生態系統是管理階層的責任。這個生態系統包括組織的政策、工作的排程或規劃方式,以及團隊和人員的組織方式。這個生態系統通常對趨勢的影響遠大於個人付出的努力。管理階層應對趨勢感興趣,以觀察對這個生態系統進行變更的影響。
適當使用指標,會發現趨勢比絕對數字更有用。沒有正確的趨勢,任意目標並無太大意義,思考影響趨勢的因素以及還能採取哪些措施來影響趨勢,比指出任意數字與現實之間的差距更有助於提出更好的問題。
許多組織使用指標設定非常長期的目標,通常為 3-6 個月,甚至長達一年或更久。經理會設定這個目標,而責任則落在執行工作的人員身上,他們必須盡其所能來達成目標。管理階層會在期間結束時重新檢視這個目標,以「評估」執行工作的人員。在此系統中,管理階層與員工之間的關係充其量只能用對抗性來形容。員工盡其所能達成目標,並暗自認為管理階層沒有任何責任。
長時間重新檢視指標的後果是,未達成管理階層的任意目標會變得越來越不可接受。我曾聽過經理說:「你有一整年的時間來達成目標,但你卻錯失了。」追蹤期間越長,失敗的風險和成本就越高。
敏捷方法偏好較短的檢視期間,因為任何績效差距的成本較低。在一週內未能取得足夠進展,遠比在一年內未能取得足夠進展來的影響小。每週檢視進度會產生比一年後檢視進度更多的選項,原因很簡單,因為有更多機會做出反應和改變。在短時間(例如一週)後,你還會有更多關於實際發生情況的資料,而不是計畫內容,這應可用於透過推動變更來影響結果。
組織受益於使用較短的追蹤期間,因為這樣可以創造更多重新計畫的機會,從而實現最大價值。
我與一個團隊合作,每兩週就會將軟體發布到生產環境。企業喜歡定期發布,因為他們幾乎可以立即使用軟體。在使用最新版本發布後部署的軟體時,企業發現他們有足夠的功能來執行新行銷計畫所需的幾乎所有事項。這只是他們最初要求的一小部分。
開發團隊並未撰寫可能永遠不會使用的功能,而是挑選了剩餘故事中的小部分,並開始著手進行下一項計畫。
適當使用指標可以追蹤較小週期的進度,因為它提供了更多資訊,說明專案在未來可能如何結束。追蹤較小的期間有助於找出趨勢,而暫停則讓組織有更明智的立場來影響環境以及趨勢的速度/方向。
追蹤較小的期間也能促進更多協作,因為它提供了更多機會讓管理階層參與。追蹤較小的期間提供了更多關於實際發生事件的資料,這些事件會影響趨勢,而不是在較大期間結束時單純「評估」人員。
如果組織可以輕易達成目標,他們就永遠不需要指標。組織可以改變方向,並立即達成目標。遺憾的是,現實生活中並非如此,這就是為什麼需要衡量標準。達成目標通常需要更長的時間。適當使用指標的第一個準則,是將真正的目標與用於監控進度的衡量標準分開。真正的目標必須始終明確說明。
準則 #2 和 #3,監控趨勢並在較短的期間內執行,目的是幫助組織更快實現目標。這無法透過本章節前面所述的單迴路學習來達成。組織需要的是 Argyris 所寫的雙迴路學習。適當使用指標會驅使人們質疑目標,並根據收集到的真實資料,實施變更以達成目標。
以下是雙迴路學習的樣子
開發人員 Dan 每週都因修正錯誤而感到沮喪,他開始思考為什麼他必須不斷修正錯誤。在過去三週,Malcolm 回報許多問題,表示事情並未如他預期般運作。他退一步思考實際發生了什麼事,較不擔心他總是被問到的錯誤數量,而更擔心他一開始為什麼會有這些錯誤。
當 Dan 選擇一個故事時,他經常有許多問題要問 Malcolm,關於它應該如何運作。Dan 知道 Malcolm 有其他行銷活動讓他很忙碌,並了解 Malcolm 無法坐下來回答他的問題。Dan 承受著巨大的壓力,必須交付一些成果,因此他做出許多假設,以確保他可以交付一些東西,而不是一無所獲。
檢視錯誤後,Dan 發現許多回報的錯誤都是基於他一直做出的那些小假設。交付成果的壓力表示 Dan 從未在第一次就建立正確的事物。
當 Dan 向 Malcolm 解釋這一點時,他們同意在每個新故事開始時坐下來,確保在 Dan 開始編碼之前回答他所有的問題。他們在下週嘗試這麼做,而當週回報的總錯誤數量減少了。
雙迴路學習需要更多關於實際發生事件的資料。較短的期間會產生更多資料點,讓找出任何趨勢變得更容易。這些趨勢提供了對系統目前效能的見解,應當用於觸發思考和解決問題,了解系統中運作的更深層次基本力量,而不仅仅是用於追蹤效能衡量。實施真正的變更有助於加速組織朝向目前的目標前進。
改變人們工作的系統通常比專注於個人更努力或更快速地工作,具有更大的影響力。在我們的案例中,Dan 每週可以花更多時間嘗試修正錯誤,但透過調整資訊流動以及 Malcolm 和 Dan 之間的工作關係,他們改變了系統,讓它變得更有效率。
專案驗屍在專案結束後回顧,尋求經驗教訓,希望將其應用於未來的專案或擴及整個組織。在專案結束時進行驗屍,無法實際將這些經驗教訓應用到專案本身。敏捷回顧的意圖不同,在專案進行中尋求改變,在此時採取的行動比在結束時更有影響力。這些會議讓團隊有機會尋找改變的機會,儘管仍然依賴人員和組織承諾這些改變。
當組織達成目標時,是時候回顧用於達成目標的指標。請記住,如果組織立即達成目標,就永遠不需要指標。定義、追蹤、監控和解讀指標需要時間和資源,這些資源可以更有效率地用於新的目標。組織需要放棄不再相關的指標,而不是堅持收集所有習慣收集的指標。適當使用指標,了解哪些指標應予以淘汰會很簡單,因為這些指標已明確連結到目標,且在期間持續監控趨勢會鼓勵持續檢視最終目標的狀態。
您可以詢問人員「我們為什麼需要收集這個數字?」來尋找一些可能過時的指標症狀。很糟糕的回應可能包括「我們一直都是這樣做」,或更糟的「這是我們的政策」。這個問題不一定要區分解釋不良的目標或過時的指標,因此可能需要多加探究。管理階層有責任確保組織的時間不會浪費在不必要地收集、維護不必要的指標上。
指標在組織和團隊中都有其目的和位置。指標不能用來取代思考。組織也不能認為數字管理就足以有效率地交付軟體。組織必須對因不當使用指標而產生的不良行為保持警覺。雙迴路學習有助於我們了解,在組織學習更適當使用指標之前,無法專注於讓個人表現出不同的行為。
適當使用指標,組織將每項指標連結回一個所有人都了解的明確目標。用於監控進度的指標必須與目標脫鉤,並且隨著時間推移,歡迎挑戰每個指標的相關性。更適當地使用指標的組織了解觀察趨勢的價值,在較短的期間內監控以了解個人、管理階層和組織的影響。更佳的使用方式也表示頻繁檢查和調整這些影響,以確保趨勢在持續評估其適用性的最終目標脈絡中加速、減速和逆轉。最適當的使用指標也表示了解何時指標不再相關,在朝向目標邁進且周圍環境改變時,取代或放棄這些指標。
您可能會發現以下文章對指標的使用和誤用很有趣
2013 年 2 月 19 日:首次發布