欸對準一點 – 談校準的重要性(不服從的領導學心得)

不管在工作中還是敏捷開發，都有強調做價值的事，『有效』重要過『效率』（Effectiveness over Efficiency）。剛剛好在臉書上看到什麼是『有價值的工作』的討論，我覺得價值本來就是主觀的東西，沒有對錯，所以校準（Alignment）會比價值本身是什麼更重要。組織的方向是節約成本、研發為主、創意開放、流程至上，具體的做法都會不一樣。如果每個部門往公司的方向對準，每個團隊往部門方面對準，每個成員往團隊方向對準，那整體就超強啦。

關於校準這個概念我是多年前從 The Art of Action （不服從的領導學）一書中學來的，我認為這是影響我蠻大的一個管理概念，書中的許多想法也暗合敏捷精神，如響應變化 重於 遵循計畫 (Responding to change over following a plan)。（順帶一提，我覺得很多中文書名都跟內容不符，也許可以增加看書皮購買的興趣，但買了發現跟想像不同不是讓讀者感受更糟嗎？還是其實因為買書有看內容的是少數？越想越可怕 XD）

阻力無所不在

在組織中其實很多政策都是為了校準，確保下級單位有把上級的目標放在心裡，比如說 KPI 就是用胡蘿蔔與棒子的思維來校準。但為什麼我們花了很多心力在校準，但結果往往跟我們想的不一樣呢？

書中是用戰爭迷霧的例子解釋這個情況，在戰爭中敵人動向未知、跟自己人的聯繫也不穩定、還有絕對少不了的豬隊友，這些種種因素都是『阻力』，阻力造成落差妨礙我們達成目標。所以我們需要做的是減少阻力，減少阻力就可以讓落差減少。

書中把執行的過程分為三個部分：計畫（Plans）、行動（Actions）、結果（Outcomes），而三種落差就介於這三個部分之間。雖然本文主題是說校準，但另外兩種落差也蠻好理解的，就一併介紹吧。

校準落差：計畫和行動的差異

我們想要大家做的事 vs 實際上大家做的事

一般人減少校準落差的方式，就是把指令（Instructions）說的更清楚，讓下屬一步步照做。

作用落差：行動和結果的差異

我們預期行動的作用 vs 實際上行動的作用

減少作用落差的第一反應，就是更仔細的去控制下屬作業的過程，也就是俗話說的微管理（Micromanagement）。

知識落差：結果和計畫的差異

我們想要知道的 vs 實際上我們知道的

減少知識落差（結果和計畫之間的差異）的一般做法，是想辦法得到更多資訊再來做決定。

毛奇將軍減少落差的反直覺做法

19世紀德國名將老毛奇進入總參謀部後，把德國的軍事思想、後勤、教育、武器做了一番改革，他讓普魯士有足夠的軍事底氣統一德意志，還打趴了當時的強國法國和奧地利。老毛奇他最大的影響是改變了戰爭的戰爭的面貌，從以前靠個別將領打仗思維，變成靠系統來打仗。作者參考了老毛奇的文章和策略，總結出在戰爭中有效縮小落差的方法，而作者認為這些方法對企業營運也有幫助。

用簡報和反向簡報來減少校準落差

老毛奇減少校準落差（計畫和行動之間的差異）的做法是反直覺的，並不是擬出詳細的計畫後要求下屬照著計畫走。要減少校準落差，反而是上級只要說明自己的意圖（Intent），讓下屬單位他們自己想如何去執行。

具體的做法是簡報（Brief）和反向簡報（Backbrief），簡報是在往下交辦時，說清楚意圖，意圖是想要達成什麼和為什麼（What and Why），然後說明上面一層或兩層單位的意圖，讓下屬了解脈絡，最後加上限制或範圍。接下來由下屬做反向簡報，內容是他要打算如何（How）達成上層的意圖，以此來看看上下雙方的意圖有沒有校準。

這我想到的是 Scrum 中 Product Owner 和團隊間合作的關係，Product Owner 說明意圖，團隊提出做法，而 Sprint Planning 和 Sprint Review 都是讓雙方意圖校準的機會。引導也是蠻重要的一環，讓下級單位敢於反應他們取得的資訊和想法，上級才可以依照現況調整計畫和意圖。

讓下屬有現場決定權來減少作用落差

為了減少作用落差（行動和結果間的差異），毛奇認為應該讓每個層級都有在授權範圍內自我判斷的能力。因為戰場瞬息萬變，讓最接近戰場的人依照上層意圖、參考現場情況來做判斷最合適，如果要彙報等上級裁示在反應，可能都被敵人打趴了。

我覺得是呼應 Scrum 中對團隊自我管理的要求，這點說起來簡單，但具體做法最困難，因為這需要的是平時的練習和實實在在的授權，也許可以經由反思會議提升團隊的決策能力。

不過度計畫來減少知識落差

而減少知識落差（結果和計畫間的差異），並不是去收集更多細節，而是按照可以得知的訊息做規劃。因為在德國軍隊裡都知道，計畫只會存活到第一次與敵人接觸時。所以不花太多無謂的心力在準備計畫，還要要在隨時可以調整計畫的情況。

在敏捷開發中，許多的做法都符合不過度計畫這個原則。比如不過度設計（Over-design）、用迭代（Iteration）來演化做法、在 Product Backlog 中由上面最細節清楚到後面待辦事項（Item）的越模糊。

圖片來源：
https://www.slideshare.net/merv/stephenbungay