主管的敏捷性從哪裡來?

.

參考自 佩吉及大衛‧洛克菲勒 夫婦的珍藏

.

主管的敏捷性從哪裡來?

團隊成員的敏捷性大都來自平常工作上的相互切磋逐漸培養出來的，哪主管呢?

下面我們運用影響地圖 Impact Mapping 來分析，主管獲取敏捷性的途徑。

.

主要路徑: 企業文化，次要路徑: 自問自學

(這裡刻意用「自問自學」，因為一般人很少會自己問自己的，因此特別強調一下)

.

其實不同位階和組織規模大小的主管對資訊的獲得方式，會有相當大的差異，這裡針對的是中小企業的管理階層。我實際訪談之下的收穫是: 「企業文化」可能是主管敏捷性最大的來源，也就是說；一個敏捷的環境最能培育出敏捷性高的主管，其次是「自我提問」；也就是自問自學的思維方式是主管們獲取敏捷性的另一大來源，幾乎占到30%。再來是藉由「團隊的敏捷性」影響所得來的，約占10%左右。透過「閱讀」得來的也差不多，再來才是得自敏捷教練或是透過訓練課程所學來的。

 

》由管理轉變成領導的思維

管理的定義有“計畫、組織、控制和領導”四大職能，看起來管理的範疇似乎比領導要廣得多，管理包括了領導，只不過，在管理的四大職能中，只有領導側重於人，其他三個職能側重於事。對於敏捷而言；主管不對團隊進行行為的控制，反之；前三個職能的工作都應該交給團隊自己去做，也就是所謂的自組織(因為這樣做能發揮團隊最高效能，請參考: 卡普曼戲劇三角 – 心理學界的系統思維)。

.

管理三部曲；是敏捷給予主管的唯一工具

.

》運用引導來協助團隊達成任務

引導(Facilitate)是敏捷給主管的唯一工具。主管在日常持續依據透明的原則來查看團隊在任務上的運作情形，再依靠會議或是有形的數據來衡量進行檢核的工作(檢核原則)，並以對事不對人的方式協助團隊進行持續改善(調適原則)。上圖顯示，引導的行為位於透明、檢核與調適原則的核心，原因是敏捷要求主管不應該干涉任務的執行，也就是不能直接將手伸進任務下起指導棋，而是將構建任務的工作完全交給團隊，主管自己則從旁以類似建築鷹架(Scaffolding)的方式來協助團隊進行施工。這便是引導；它通常是以發問的方式來引發團隊對該問題進行討論、思考，若能因此激發團隊運用群體智慧獲得解題方案為佳，但至少是以客觀的角度來巡視問題，而不是以傳統管理上的命令與控制模式，也就是直接下指令(大家聽我的，就這麼做就對了)。

 

》加強提問思維，加強主管的敏捷性

主管能問出好問題，不但能讓組織上下溝通順暢，更能提升部屬的思辨能力，同時也可以凝聚團隊共識與增進信任感，能鼓勵成員表達自己的想法、要勇於說真話。提好問題不但能打開透明性，還能增進主管與團隊之間的信任度，這二點都是敏捷化成功的基本要素。但怎麼問出好問題呢? 答案是激發團隊願意提出一大堆問題開始。

.

問對問題，比答對答案更有威力！

.

我想推薦的是一種強大的思維方式，它叫提問式思維(QT:Question Thinking)。要抱歉的是我找不到任何學術理論來支撐它，但絕妙的是它來自一本極暢銷的好書，我們可以盡情的欣賞、玩味。提問式思維；討論的是一個亙古不變的話題：每分每秒，我們掌控自己思想的能力。QT提供了觀察和評估我們當下思考(尤其是我們對自己提出的問題)的技能，然後指導我們客觀的設計出能產生更好結果的新問題。QT可以幫助我們更好地帶著正念去思考，而不是自發回應式的思考，(自問自答要避免流於自發回應式的思考方式)如此，即使在壓力下，也可以做出精明的選擇從而獲得富有成效的結果。養成可靠的、有建設性的思考能力，是我們在工作或是個人生活中，做出有意識的、可持續性改變的關鍵。

 

QT的作者，有一個著名的例子是: 早晨出門前穿衣服時的提問，試問一下你都怎麼決定今天要穿什麼樣的衣服出門的?

 

“你今天早晨穿衣服時，我相信，你肯定是走到衣櫃前，或穿衣鏡前，不經意地問了自己一些問題，比如，我要去哪兒？天氣怎麼樣？什麼衣服穿著舒服些？甚至是，哪幾件衣服還比較乾淨？比較舒服？你很快做出決定並且用行動來回答你的這些提問，你選好衣服，穿在身上。總之，你現在穿的就是你的答案。”

 

– 若是你能更客觀的、更正確的提出更好的問題，結果一定更美好。而你便更能掌握自己的思維，也能因此而學到更多東西。

 

提問式思維是一套工具體系，通過巧妙地提問來轉變思維、行動和結果。其中，提問包括我們向自己提出的問題，以及向他人提出的問題。但其實，即便我們是向別人提出問題，回答的人其實是再把問題拿去問了一下自己，才作成回答的。

 

主管就是讓事情變得更簡單、更容易達成的人。

– 梅若李 亞當斯

 

補足主管在做引導動作時的缺失 – 不容易客觀

引導的字面意思是讓事情變得更容易去達成的意思。正好符合上面梅若李的那句話(主管就是讓事情變得更簡單、更容易達成的人。)，而引導也一直是敏捷管理時主管所能依賴的工具，也就是不直接干涉專案的進行，運用引導的動作從旁來協助團隊完成任務。

進行引導的基本方式就是用「提問」來啟發改變他人(引導)的行為模式。對管理者而言，就是避開運用傳統的命令與控制模式來指揮團隊，而採取詢問的方式來引導團隊完成任務。

QT提問式思維要求你透過理智的問自己問題來增加你的客觀性思維，這一點正好可以彌補主管因為自己對團隊成員先入為主的主觀評估(主管要負責打考績，便很難做到客觀了，話說；我們總是習慣把較好的考績評給自己最喜歡的部屬，也總以為工作能力較強的成員，在其他方面的也一定會優於其他人–其實這是最大的偏見)。

.

我們最大的偏見，可能就是認為那些不贊成我們主張的人都有偏見。

.

》主管的敏捷性從哪裡來?

就從問對自己問題而來，因為經常做客觀性的提問而培養出自己在做決策時的客觀性態度，而能夠在授權給團隊之後接著進行賦能的工作，也就是「主管能在授權給團隊之後，再以不直接介入任務的方式從旁運用引導的技巧，讓團隊能夠達成任務的工作方式」- 主管的敏捷性定義。

 

結語

組織文化是否敏捷是影響主管行為是否敏捷的最大依據。但相反的；主管的行為是影響組織文化的一大要素。也就是說如果你進入的組織已經具有十分敏捷的組織文化了，則你(主管)的表現自然要容易敏捷化許多，你也能很快的學得如何提升自己的敏捷性，這是組織文化的強大影響力。我們都想擁有這種力量，但要從無到有的歷程卻是那麼的困難，到底要怎麼做呢?

 

變革要先改變流程還是人?

反思企業進行敏捷化的二件事: 就是改變人跟改變流程。哪個較重要呢? 答案當然是人，但是有趣的是每次變革我們都是由流程做起，也總是把資源大量的投入流程的改善上，但我們都知道，人才是重點。從流程開始的原因可能是想要改變人，很難看見成效更又沒法度量，而改善流程就容易得多了，也比較容易去持續改善，這一點造成了工程師越做越敏捷而主管卻反其道而行，因為急迫的工作接二連三的到來，造成人們為了求快而依據經驗來解題，便容易犯上直接下達命令與控制式的抉擇，因此而變得不敏捷了。這會衍生出團隊的文化成為一種亞文化Subculture的形式(參考《企業文化與變革指南》by 埃德加·沙因)，選擇改變人則是選擇了先去改善企業文化，難度高了許多，而選擇改善流程則容易在出現成效時製造了亞文化的體系。至於最終的企業敏捷性，則便是主文化融合入亞文化後的表現。評估方式則是參考自《敏捷文化：如何打造优秀的高效能团队》裡的誠信與責任模型。它強烈依賴主管的敏捷性的好壞，因此主管能否客觀的進行引導便成了這個話題的解答了。(敏捷團隊一定會製造出一種團隊特有的文化氣息，由於不同於組織文化，就稱之為亞文化)

.

為我們帶來啟迪的，並不是答案，而是提出的問題。

– 尤金 · 艾裡斯柯

.

主管能否客觀的進行引導

引導的第一條法則是保持客觀性。只有始終維持客觀性才可能做好引導的工作。而引導的方法則是千篇一律的以提出問題的方式來進行。因此能否客觀的進行提問便成了主管敏捷性好壞的依據。可以協助主管提升敏捷性的方法正是熟練提問式思維，下面陳列QT的 12工具，及選擇地圖。

.

經驗常常是偏見的來源，處在這個複雜的世界中，我們必须提出不同的問题，但是習慣的力量又將我們扔進評判者泥沼中。只有自己的意識轉變才能走出評判者的泥沼，擺脫經驗的束縛而如何置身於泥沼之外呢？ -《改變提問，改變人生》讓作者梅若李.亞當斯來告訴你。

.

參考自《改變提問，改變人生：12個改善生活與工作的有力工具》

.

註:

1. 《企業文化與變革指南》by 埃德加·沙因(Edgar H. Schein)
2. 《敏捷文化：如何打造优秀的高效能团队》By: 波丽安娜•皮克斯顿 (Pollyanna Pixton)
3. 《改變提問，改變人生：12個改善生活與工作的有力工具》By: Marilee Adams， 提問式思維的原創者
4.  其中工具2. 選擇地圖，更是主管可以運用來解決部門內人員相互產生衝突(conflict)時的良方。

廣告

人、流程: 敏捷變革二件事

.

敏捷變革就是處理人跟流程的問題

.

我們都說人才是最難處裡的，但在變革時卻把時間都花在處理流程上頭.

.

持續改善

敏捷變革就像一場沒有結束的遊戲一樣，像極了你在玩俄羅斯方塊一般，玩者就只能在遊戲中盡力的去爭取更高的分數，不會(你也不會期待)有結束的那一幕，因此持續改善便成了成功的關鍵。任何事情若是想要能夠做到持續改善的話，起步一定要從簡單的地方開始，一開始作難了，挫折感便大大提升了半途而廢的機會。因此想要持續改善，就從最簡單的地方開始吧! 變革也是這麼回事。

 

透明、檢核及調適

透明、檢核與調適是敏捷開發裡Scrum 的三大支柱。這三者是敏捷化的基礎，沒有透明的訊息則團隊在互相不清楚對方在做什麼事情的情況下就不可能彼此支援，只有個人的戰力無法形成團隊戰力。站立會議則是團隊自身檢核的最佳時機，即時發掘問題預見風險，可以讓團隊少走很多冤枉路。而這三大支柱更應該由主管來主導，資訊才能更有垂直整合的效益。

 

水平與垂直的透明

透明有水平的部份，是屬於橫向的在同一個團隊裡大家共享的資訊，越是能互相協作的團隊能擁有全面的訊息交流，彼此的良性互動讓信任持續的茁壯。垂直的透明性則來則跨部們超越團隊邊界的資訊流通上，這是來自主管與企業組織的努力，讓有利於跨團隊的整合訊息能夠流動於團隊之間。它建立在主管與下屬的誠信上。

 

檢核與提問

問對問題比找對答案更能解決風險，我們經常倚賴數據來佐證事情的來龍去脈，但實質上數據是不會解釋事情的原委的，而是依靠我們自己解讀後所產生的假設，只有透過提問與討論方足以形成共識，少了提問的檢核是不會有共識的。尤其是沒有經歷過運用「提問風暴」來形成共識的團隊，便少了群體智慧的實作機會。Scrum 團隊在進行「檢核會議」時正是發起提問的最佳時機，讓客戶提問可以換來彼此的了解增進信任度，讓主管提問可以展現團隊的日常工作內容，拉近彼此間的距離。讓PO提問可以透明化各個功能的設計理念，同時也能提前透視開發風險。

 

團隊自組織的基礎

誠信與責任是形成自組織團隊的基礎。主管需要取得團隊的信任，團隊需要能為自己的工作擁有所有權並願意負起成敗的責任。信任度越高，願意承擔的責任越多，相對的產出與效能也會越高，這些道理大家都懂，但要怎麼做才能達到呢?尤其在一個大家都很忙的組織裡，一位主管一星期能接觸到幾位下屬呢? 越高的層級這件事就越難形成，為了這個理由，組織趨向扁平化的現象持續發生中，但多扁平就能達成呢?我想誠信應該不是這麼回事，主管的處事展現公正的態度應該才是關鍵，再來是資訊的透明化才是關鍵，當我們對主管做決策時的理由或過程眾說紛紜諸多猜測時，這個時候不論事情的對錯，誠信自然會受到質疑。因此誠信的基礎依賴在組織的透明化的程度上頭。而團隊的效能則依賴於是否能持續改善，也就是經常性的檢核與調適上頭。

 

主管，請後退一步

敏捷教練最常掛在嘴邊的一句話:「主管，請後退一步」

看起來，教練的目的是讓主管盡量不要去干預團隊，讓團隊習慣自組織。但其實他的目的要深遠了許多，只是很少有敏捷教練有機會去跟主管說清楚的。敏捷教練是希望主管能學會如何去帶領一個自組織的團隊的，而「後退一步」則只是一個開始。那；主管要怎麼辦呢?

主管要在授權團隊之後，設法協助團隊讓他們能夠達成任務。也就是所謂的賦能。這個時候，被運用在學校教學體系下的「鷹架理論」便是一個很好的作法，也就是說；當建築物要蓋2樓的時候，應該先把3樓的鷹架蓋起來，要蓋3樓的時候，應該先把4樓的鷹架蓋起來，由外部讓整個施工都順暢起來。主管不但沒有把手伸入工程中，而是藉由給予團隊來自外部的協助，而更容易去達成任務。

 

提問式思維 Question Thinking

簡稱QT，為 梅若李·亚当斯 所創的一種思維方式，它的目的在教人用問自己問題的方式來加強思考的完備性。著眼於教人在遇事情做反應時，能夠選擇學習者路線，而不是走評判者的路線，讓心境能夠維持在正向的學習道路上，即便你一開始感到不快而加以評判，也能迅速的藉由轉換的方式，走回正途。這一點尤其適合無法進行客觀引導團隊的主管，依然能夠以共事者的角度來進行引導。(主管由於負責考核下屬，所以在進行引導時，便無法從完全客觀的角度去引導團隊，而這正違背了引導必須保持客觀的守則)

 

結語

敏捷變革不就是在處理人跟流程二件事。處理流程由下往上來得實在而真實，依循一般敏捷教材便可達成。處理人的問題便要由上往下了。重點便放到主管的敏捷性上頭了，所謂主管由假設團隊的反應而決定他對團隊的態度，而團隊則依據對主管的行為解讀，而決定了他們的行為準則，然後主管再經由團隊所表現出來的行為來修正他對團隊的態度，這一切都是相互影響的，而他們共同建立了所謂的組織文化。因此當我們抱怨是組織文化造成推行政策的不力時，其實我們自己也是罪魁禍首之一。因為我們沒能善用敏捷所謂的小增量、迭代與 回饋的功能。

主管的態度來自對團隊行為的假設

.

註:

提問風暴

原自《改变提问 改变人生》一書裡的提問工具。

鷹架理論

又名支架式教學（Scaffolding Instruction），是指學生在學習一項新的概念或技能時，透過提供足夠的支援來提升學生學習能力的一種教學準備的工作。

提問式思維 Question Thinking

為暢銷書《改变提问，改变人生》的作者梅若李·亚当斯（Marilee Adams）所創的一種思維方式。他著眼於問自己問題多於問別人問題的一種思考的方式，不是一般教授提問方法的書本，它運用問自己問題的方式強化個人的批判式思維。

 

決策者的工具: Cynefin Framework

.

Dave Snowden 喜歡的平板式 Cynefin Framework圖示，皺褶處指的是山谷或山脊

.

Cynefin Framework 庫尼文

解題難，尤其是起步時更難。遇問題時，通常我們會先進行觀察(Observe)，然後回頭看看自己所處的環境(定位，Orient)估算一下自己在當下能夠解題嗎?也可能會反覆的觀察一下然後在判斷一下，直到弄清楚是怎麼回事之後，在做好決定(Decide)然後開始行動。這種行為模式，稱之為OODA循環的決策模式(*1)。這個方法最早應用於美國空軍戰鬥機飛行員的訓練，作為交戰程序的一部份。感覺上既簡單、符合人性又有效率，但這個方法在遇到難題時，好像就幫助不大了。Dave Snowden 提供了更進一步的決策模式，Cynefin Framework庫尼文(發音[ku.nev.in])是威爾斯語「棲息地」的意思。

 

它只是一個架構不是解題的方法，當你遇問題時可以用這個架構來判斷問題的類型然後參考架構所推薦的解題方式，然後在決定如何去處理它。Cynefin Framework尤其適合在現在多變的環境下，尤其是管理者遇到找不到正確答案的問題的時候。你需要有相當的創意與創新的做法來解題，敏捷開發裡 Scrum 的指導原則便是在這個時候發揮功效的，因為你無法用簡單的因果關係來看出問題的全貌，只有透過探索的方式，運用迭代每次產出小增量，經由結果的回饋來進行解題，就稱為浮現式的解題方式。

 

Cynefin Framework為 Dave Snowden在 1999年所創，指的是我們環境與經驗中的許多因素，會以我們無法理解的方式影響我們，因此決策者可以用描述問題, 環境與系統, 對照到這個架構所落入的象限中, 便適合使用什麼樣的解決方案，一個提供決策者客觀解題的架構。採用此庫尼文架構，可以協助高階主管了解自己所處的情況，避免因個人偏好某種管理風格而容易犯錯。

 

解法是這樣的；當我們面對一個問題時，首先要決定的是它是屬於有序還是無序的系統類型，有序的；指的是我們可以將因果聯繫起來; 也就是如果我們採取了某一種行動，我們知道它便會產生什麼影響。而無序的系統；指的是我們無法確定這麼做了，會得到什麼樣的回應的因果關係。

.

問題依它的狀態可分成有序跟無序二類

.

有序的類型能分成簡單(Simple)的系統及繁雜(Complicated)的系統二種。在有序系統中，特徵是；系統受到高度約束，行為具有高度的可預測性，因果關係可以從經驗中明顯看出，也可以通過分析來確定。簡單的系統；原因很明顯可見，適合稱之為不言而喻。如果原因不是那麼明顯但仍可以通過分析來確定，我們就說這是一個複雜的系統，俗稱為專家意見，也就是需要透過專業的分析過程來追溯出原因。

.

無序的類型又能分成複雜及 Chaotic

.

無序的類型又能分成複雜Complex及 混沌Chaotic，以及一種沒有能確定的失序系統，把它們放在正中間，稱之為“無序”。複雜的系統；它的因果關係是事前不可預知的、是不穩定的，一般情況下，這類問題往往沒有標準答案。問題無法單純通過拆解分析的方式來解決。混沌性的系統；問題的因果關係不可得知，完全無法瞭解問題是怎麼發生的，也就是原因不明，或者是原因太過多變，那麼就屬於混亂的系統，系統緣無故出現突發性的問題便屬於這一類。

 

依據這五種系統類型的定義，決策者使用時可以依照問題的類型，採取相對有效的解題步驟。Dave Snowden建議；當遇到簡單型問題時；可以採用察覺、分類的方來因應它。遇到繁雜型問題時；可以透過專家進行感知、分析來因應它。當遇到複雜型的問題時；則必須透過連續試探後再得到相當的因果關係後再進行感知來因應它。至於屬於混沌型的問題，則因為無法一下子就解決，因此首先要做好停損，然後迅速採取行動，嘗試將所處的領域再轉變為其他類型的問題領域，然後才再來解題。整理成表格如下:

參考自“A Leader’s Framework for Decision Making, ”HBR , November 2007

.

網路上已經有太多 Cynefine Framework 的圖形了，但還沒有專門的書來談它，能找到的只有一本小冊子(The-Cynefin-Mini-book-online By Greg Brougham)，為了上課方便，容我在增加一個。

.

右下角；簡單問題的象限: 由於問題顯而易見，因此在觀察(sense)之後透過分類或階層化的方式便能做到最佳的實踐，是一種適合制定SOP的解題類型。此時可以採用Waterfall 的方式來解題。 【步驟: 觀察→分類→因應】

右上角；繁雜問題的象限: 由於問題稍見複雜性，因此可能需要透過專家來進行分析尋求較好的解答。此時適合採用看板方法或 Scrum等敏捷的方法來解題。【步驟: 觀察→分析→因應】

左上角；複雜問題的象限: 由於問題的現象變來變去，感覺上像是動態的在改變，在這種情況下，很難採用因果關係單靠還原現象做分析來推論解題，此時運用反覆的探索、觀察的方式來嘗試找到一種浮現方式的解答，機會較大。適合運用Scrum的敏捷方法，採用小增量、迭代的模式去趨近問題的核心以求取在持續嘗試錯誤之下所衍生出來的解答。一般專案大都屬於這個範疇內，所以運用影響地圖來確認真正的問題及採用用戶故事地圖來掌握需求，這樣的工具都有利於浮現出可行的解答。【步驟: 試探→觀察→因應】

左下角；混沌問題的象限: 由於問題的因果關係不可知，完全無法瞭解問題發生的原因，或者問題的原因太過多變，那麼就屬於混亂型。這個時候，首要任務是及時停損。迅速採取行動，嘗試將所處領域轉變為其他領域。也就是試著從混亂轉變為複雜問題。【步驟: 行動→觀察→因應】

一般IT部門在遇到無緣無故發生的嚴重Bug時，經常就處於這種狀況下，此時需要果斷的處置行動，先求停損然後在設法轉成複雜問題的象限來處理。此時可以參考原著(The Origins of Cynefin)的這張圖示:

.

在象限中轉換(註創始者 Snowden 已將簡單 Simple 改成 Obvious)

.

專案進行的過程，總是由複雜透過抽絲撥繭到逐漸明朗化成為繁雜的一堆事物，再經由持續實作演進到大家都能看清楚的有序狀態，在專案完成前來到簡單的領域，並在最終獲得成功。上圖中問題求解的循環實際上是一直在轉換中演進的，無所謂靜態的停滯的，也就是說事情擺著會逐漸變得更糟的，而敏捷正是以一種務實的精神運用小增量、迭代化去求解的過程。

.

結語

人的習慣是先觀察再定位然後下決定。但要觀察什麼？要定位到什麼呢？觀察什麼、定位什麼，它會有大不同的。在多變且越來越複雜的世界裡，往往沒有一種放諸四海皆準的方法，越來越多標準作業程序被打破、需要修正，明顯的我們應該視問題的狀態再來採取相對應的解題方式，而 Cynefine framework 正是一個可以參考的架構。網路上有太多衍生出來的解法，看上去也都很有價值，敏捷只是一種做事的態度，時時存乎於心才是上策。

.

註 1. OODA循環的決策

OODA循環（英語：OODA loop），也被稱為柏伊德循環（Boyd cycle），由美國空軍上校約翰.柏伊德提出的決策方法。這個方法是一個循環，由觀察（Observe），定位（Orient），決定（Decide），與行動（Act）組成，反覆進行。

註 2. 2017/12 Dave Snowden 最新 Cynefin framework 說明影片(含 Agile development)。

主管的引導方式 – 目標式引導

薩提爾女士的冰山理論模式

 

敏捷教練們經常要求主管要後退一步，目的是讓團隊能自己做決策，形成自我組織的團隊，但對於主管而言，這是一種消極的做法，不適合主動性強的人士。積極的做法應該是去改變管理方式，也就是運用引導的方式來協助下屬達成目標。

 

目標式引導 (Facilitate)

管理者的引導方式是不同於一般引導者的，一般引導強調必須有著中立的立場，例如: Scrum Master或引導師進行引導時。這是因為管理者需要去評核他們的表現，也就是打考績，所以很難扮演絕對中立的角色，你必須時時進行評估與判斷，才可能適時的授權給他們，而且你還必須與他們共同負起成敗的責任，團隊會更在意的是過程，但管理者的引導應該更注重在目標而非過程。因此適當的目標導向是管理者的引導與引導師最大不同點。說穿了就是運用目標來做溝通，用目標來做計劃，運用引導的技能來達成目標。

 

著名的維琴尼亞．薩提爾女士(Virginia Satir，1916-1988)所提出的冰山理論，正是一種以目標為導向的引導方式。它把重點放在運用冰山理論揭開部屬的行為障礙及思維盲點上，也就是讓他們看見現狀的事實，然後再進行轉化及改變。程序是：

 

1. 確認目標

要先確認談話的目標，如果情境不合宜，就得調整目標，才能使整個交談能夠聚焦在單一的重點上。當目標過多時，便很難達到預期的效果了。

 

2. 辨識並排除冰山盲點的干擾，開創新的可能

辨識及排除冰山盲點的方法可以簡單歸納為下列三點：

1. 詢問他為什麼這樣做，是什麼觀點造成你決定這樣做的，讓他講出來自己的觀點，你可以觀察到他的情緒、觀點、期待及渴望。也就是冰山下的盲點。
2. 引導他探討、分析固守的行為、情緒、觀點、期待及渴望模式對於其外在表現的利弊得失，讓他能客觀的認知自己的盲點在哪裡。
3. 引導他去探討不同的可能性，找出可以改變行為的重要因素，進而創造出新的可能並發揮出要達成目標所需要的潛能。

一旦能夠自覺地看到自己的盲點，也看到其他的可能性，就有機會突破既有框架，發揮出潛力。

 

3. 落實改變行動

教練式領導的目標是藉此促使部屬改變行為模式，而不僅止於內在心理因素的改變。

.

結語: 引導就是問對問題

領導者應該多提問，尤其是那些能夠幫助個人、團隊、組織以及我們自身成長的問題。你會發現越是卓越的領導者則越是能夠提出精彩的問題。提問已經成為領導者必備的技能了。舉一個架構的例子來看，敏捷開發的團隊裡遇到最大挑戰便是架構的設計，因為你不能一口氣就把整個架構都設計完畢，必須隨著功能的推進以鷹架(Scaffolding)的方式逐步地堆疊出你的架構，我們稱這種設計方式為衍生式設計(emergent design)或是浮現式設計。但架構設計要如何能像築鷹架一樣，鷹架築到三樓蓋二樓、築到四樓蓋三樓，以一種漸增的方式來構築呢?

 

其實這種理念是違背架構設計的，架構設計就是要先去設想到全貌會長成什麼樣子，才能接著拿它去做依據的來進行設計，記得自己在剛踏入敏捷領域的時候就已經做了多年的架構設計了，那個時候每當我必須作架構設計時，我總是改不掉老習慣，先用自己的假設把架構圖畫完，然後就把架構圖收到抽屜裏去，就以提問的方式，選擇與團隊一起討論出一個初步的架構圖來，然後始終用團隊共同討論出來的架構來做設計，一直到有一天工程師因為換位置的關係從我的抽屜裡找到這張架構圖，然後笑說什麼時候我重畫了大家討論的架構圖也不分享出來。其實這是一開始就做好的架構思維，我只是把它轉變成一系列的問題，再透過團隊一起討論一起取得共識，而我的作法是在討論的過程裡選擇一直去問對問題，運用問題來引導團隊去進行架構的設計，我必須承認這不是一種標準的衍生式設計的方式，但效果好極了。透過大家圍繞問題的討論，所獲得的結果讓大家都清楚了這個設計，而且也更願意主動去實現它。多年來我還是一直這樣做，而沒有想說，這正是一種引導式的設計。

主管對執行內容與團隊成員的態度無法是中立的，大多數情況他憑藉著個人的知識和經驗，對內容進行評價、判斷，並很難無視於團隊成員的錯誤，因此，態度是最困難的(請參考主管要如何面對團隊)。

.

註: 薩提爾模式

維琴尼亞．薩提爾女士(Virginia Satir，1916-1988)所提出，薩提爾模式是以人性關懷的角度(人本信念)，來探索行為背後的緣由，並從其中找到轉化的方法(冰山理論)，以協助當事人重新學習及成長。又因為薩提爾模式強調學習成長，所以也被稱為是成長導向的模式。

參考:  引導式對話，讓員工自己發現問題背後的原因！

主管要如何面對團隊？

.

循環式學習螺旋(註)

.

「主管處裡事務的態度決定了公司的文化」、「文化不是一天可以形成的」…

.

建構學習型組織 -第五項修練

如何形成敏捷的企業文化呢?首先要在認知上同意《第五項修練》彼得聖吉所謂的持續學習是企業最重要的技能。如果我們接受讓團隊持續學習是企業存活的前提，則所有的行為就應當以促進團隊的學習效能為主，然後在這個前提下主管就容易決定如何與團隊相處了，我們可以參照「循環式學習螺旋」來調整與團隊相處的關係。通常主管們以達成上級所交代的任務為前提，這一點沒有問題，但敏捷是這樣看的，敏捷會後退一步(系統思維)，讓團隊持續學習，經過學習來克服他們昨天所作不到的事(運用小的迭代來進行檢核、調整，至於範圍的大小就看你可以承受的短期失敗而定了 )，也就是讓團隊自己做，用學習來增強能力克服任務上的困難以達成任務，正如同賈伯斯所言: 「我們不該去追求成功，要去追求卓越則成功將隨之而來」

.

我們不是為了健康而去運動，而是為了興趣而持續去運動，健康則是附帶而來的。

-系統思維

.

主管要如何面對團隊?

如上圖中循環式學習螺旋的描述，主管依靠自己的基本信念及經驗預設團隊將會有的反應，並依此決定了行動方案，而團隊則會依據對主管行動的解讀而形成他們的行動，主管在經由團隊的行為表現進一步驗證了自己最初的假設而採取了接下來的行動，這是一種循環。為了跳離傳統的命令與控制型的管理，主管必須重新思考自己的角色。主管不可以在試圖知道所有的事情和做出所有的決定，他的重點需要轉移到定義團隊方向和營造一個環境使其他人也有機會學習和做出決定。這一點像極了家長在對待即將成年的孩子一般，你必須停止去替他們下決策也就是後退一步，他們必須學會為己的決策負責，否則就會像長不大的孩子一樣，不會主動為自己的行為負責，始終無法獨立。這一點常常是家長們放不開所致，一如主管凡事都事必躬親一般，也就不容易建立與團隊之間的信任度了。

 

相反的，主管的信任度和行為表現可以引領團隊職級的學習。此時如果主管嘉獎獨立、有擔當的員工，則團隊自然會產生相對應的行動。信任便成了團隊的回報，它也能減少主管的擔憂。這是促成團隊凡事朝向正面思維的重要一步，上圖的循環說明了主管的態度將引導團隊的行為模式，而建立信任在適當授權給團隊，讓團隊為自己的工作負責則是建立自組織團隊的基礎。相反的，如果團隊有推諉、逃避責任的現象，則表明了主管與團隊之間的信任度是不足的，要讓團隊敏捷起來則應該從建立互信著手。

 

結語

主管不能歧視任何人，你的態度將被團隊成員放大來解讀，而成為團隊一種無形的規範。檢視的方法是去傾聽團隊對事情的看法，若是偏向負面則你的循環式學習螺旋就會偏向負面(產生負面的學習過程)，一種常聽見的說詞是”我不喜歡但還是得這麼做，因為這是我們主管所樂意見到的”。主管應該視團隊行為是一種回饋，並依此來調整自己對團隊或個別成員之間的態度，有時放入太多的關注反而沒能讓團隊學到該有的經驗，應盡可能引導團隊朝正面思維方式是建立互信的基礎。有一個很好的做法是從「表現的公正」開始。

.

.

註: 參考自《敏捷文化》循環式學習螺旋， by Pollyanna Pixton 等。

誰說敏捷化一定會成功的?

.

敏捷化路徑 1. Trust-Ownership model 或許翻譯成"信任-所有權模式"會更洽當

.

以終為始

我做過許多企業的敏捷化顧問，有做1個月的也有待上2、3年的，誰說敏捷化一定會成功的! 但要怎麼來判斷敏捷化的成敗呢?最糟糕的是: 有些大企業的文化就是要追問每一個方案的成果，即便它是既抽象又無形的哪種, 或是需要過一段時間後才看得到影響效果的方案，上級也會要求要硬擠出報告來，當然最好是有數據，或是搞個問卷也成，就是要具體化產出，真是勞民傷財!

身為專業的敏捷教練，我是怎麼看成敗的呢?! 這裡說給你聽:

》你的效率變好了嗎?

敏捷不是一種實施完就結束了的活動，是必須一直持續下去的。但敏捷也不是商業行為，企業的本業才是。所以敏捷是用來輔助你的本業的，目的就是幫你效率化的面對市場上多變的需求。因此實行敏捷化一段時間後，試問你的效率變好了嗎?這才是重點。

我經常看不到自己顧問過的團隊後來怎麼樣了，他們是如何在我離開之後，持續的把敏捷(的心態)運用在工作上頭的。是否能在面對重大又困難的專案來臨時能善用敏捷的原則，維持住敏捷的步調呢? 這一點非常重要，因為你要相信它，敏捷才能幫你分憂解危，你才可能用得好敏捷。不要一遇到金額大得嚇人、時程又趕的不得了的專案就慌了手腳，這是我離開顧問團隊時最擔心的一件事。(但通常都沒來得及交代，就必須離開團隊了，繼續迎接新團隊，這就是做顧問的生活，看不到結果也只能窮擔心了)

上面那張「信任與責任模型圖」可以回答我們的疑惑。縱軸是主管對團隊或個人的信任程度，越往上表示信任度越高，也就是授權與賦能做得越好。橫軸是代表團隊或個人對於專案成敗的責任感與承諾的程度，越往右表示團隊越能自主，組織效能越高(左下角是最低效，右上角是最高效)。這張圖重要的不得了，它驗證了主管與團隊之間的信任與責任狀態，也是團隊在透過敏捷化之後效能成果的展現。

 

圖上1.的路徑是在說明通常在敏捷教練離開團隊後的影響 (敏捷顧問離開所產生的影響純屬巧合，但幾次經驗下來結果都是一樣，但不能就這樣斷定它是必然的結果)。團隊從傳統的由主管或技術leader下命令做工作分配的控制模式下，當上升到需要高度信任的情境時，敏捷教練在的時候，會時時提醒，請主管後退一步，請技術 leader後退一步，目的就在讓團隊培養出自己組織起來面對問題的責任感。但一旦在沒有敏捷教練在一旁提醒主管時。當遇到緊急的事故，主管通常是身先士卒的跳出來處理，這時候就可能出現麻煩了，若是主管只是扮演整合釐清問題的角色，則一切OK。若是主管為了求快速解題，依靠自己豐富的經驗直接下指導棋，採用命令的方式來處理時，就完蛋了。敏捷教練辛苦建立的自組織團隊就可能被一下子打回到原形。這時候我們稱之為敏捷化停在藍色「失敗」的區間裡。也就是大家常常掛在嘴邊的，所謂「主管的敏捷性左右了敏捷化的成敗。」

.

※ 遇嚴重問題，先求暫解再做長期解。二階段的解題流程無可厚非，但要把長期解撰寫成需求加上權重在放入需求的Listing 裡，以避免永遠使用暫時解。

.

敏捷是怎麼失敗的 – 團隊失去自組織。

『就是主管下指導棋，來你做這個，你呢? 做這個，這樣就可以搞定了。相信我就沒錯了。』

請注意，信任 Trust 是沒哪麼容易建立的。需要人與人之間經過長時間的互動之後，逐漸建立起來的。在企業裡主管要產生1對1的互動比較難，必須靠誠信來逐漸樹立起互信的橋樑。所以上面那張圖又稱為誠信-責任模式。

 

敏捷是怎麼失敗的 – 沒有依據 Scrum Guide的規範。

『我們組織的特性就是這樣，很難維持小團隊』、『我們習慣的工作量就是這樣，很難做迭代式開發』、『我們的團隊在遠端，很難做站立會議』 …這就是所謂的 Scrum Butt!

 

企業以一種依循傳統超越敏捷指導原則的做事方法，進行敏捷化的行為。結果自然會遲遲看不到敏捷的成效。如果你經常這麼懷疑的話，回過頭來，檢討一下是不是犯了 Scrum Butt的現象。

 

敏捷是怎麼失敗的 – 事事根據SOP就對了。

Silo穀倉效應就是發生在這裡，敏捷是要時時應付不可預期的改變的，最怕一種稱為『服從型的破壞者』。他事事依循公司規範，不屬於自己責任範圍的工作就不會主動去幫助別人，即便這些事情就發生在眼前。這種人士，看起來循規蹈矩，不會做出傷害到公司的事情，但其實他正在破壞組織的協作效能。

還有一種叫『經驗型的破壞者』，他依靠過去的經驗行事，也不是不敏捷，但就是太依靠經驗，少了一些嚐試錯誤的勇氣。也會讓團隊行事不敏捷，經常跟團隊說相信我，這樣做就對了。少了實驗性的成長要素，讓敏捷化始終在日常的行事中冒不出來。做主管的特別要注意這種人才，他能做事不是不能，但他是在無意中限制了團隊自組織的效應，若他已經是位高權重的主管了，那就更難處了，最好的做法是派遣他去專人專職打天下的工作了。

.

敏捷化路徑 2. 主管對團隊信心不足，經常 overwrite 團隊的決策

.

衝突不可怕，可怕的是衝突後的沉默。

.

衝突象限

團隊已經承諾要把專案做好，但是主管卻沒有信心。這種現象；通常在Bug層出不窮的團隊裡或是過度事必躬親的主管身上，主管會對團隊宣稱能夠把事情做好沒有信心怕他們失敗，就容易出現一種主管常常不贊成團隊的部分決策，私下overwrite某些決議事項的衝突現象，試問；當你發現孩子們的決定可能會犯錯遭致失敗的時候，你會選擇靜靜旁觀讓孩子們嘗試錯誤呢？還是毅然的出手介入，讓他們避開失敗呢？主管的作爲也可以同理心判斷，許多父母是太照顧孩子了，換來的是缺少獨立性，團隊的自主性亦然。此時團隊的信心會發生動搖，也會逐漸的選擇沉默，默認主管去做決定就好了，產生一種貌合神離的上下游關係。

尤其是在傳統階層複雜的組織裡，高階主管做了決策推行新政策，當沒有充分跟下屬溝通時，就容易讓下屬曲解了上面的意思，便盲目行事，造成團隊效能不彰的現象。歸根究柢通常是透明度不足的現象，造成團隊裡越優秀越有主見的人士失去對組織的信任，而選擇離開一途，這是組織的損失，也是執行敏捷化最害怕出現的現象。

.

看大家討論的怎麼熱烈，身爲技術主管，我建議採用這個作法… 這一下子就把所有權全部收回來了。

主管一定要避免作建議.

.

信任與責任的威力

所謂「三個臭皮匠，勝過一個諸葛亮」，在敏捷解決眾多難題裡佔著很大的份量，我們(主管與敏捷教練們)經常一再開會就為了找出一個看起來公平又公正，能讓人心服口服的解決方法的時候，團隊卻能選擇自主的透過加一點班把工作做掉的方式，輕輕鬆鬆的消除掉這個難題，這是我看到最多的現象，信任讓我們願意付出，願意承擔下這個責任(自組織就是這麼棒!)。說穿了是團隊選擇了退一步的行為，但實質上卻是責任感發揮了莫大的助力，協助管理者做到不容易處裡的事。這意味著創新與潛能持續在醞釀中，這正是團隊在累積正能量的現象。

.

由低效能走向高效能之途

.

自組織團隊是最高效能的團隊

如果你去查看(google 一下)如何樣養成一個高效能的團隊，一定會發現一個會自主管理的團隊是最高效的，換句話說就是「自組織團隊」的效能最高。也就是右上角象限的一個有活力與創新的團隊。上圖中的3A及3B路線都是到達高效能團隊路線，你或許會問我為何不是直接由左下角上升到右上角呢?這樣不是最快嗎? 這是一種在沒有歷史包袱需要克服時的途徑，它通常屬於「新創團隊」。這也就是各大企業都會選擇讓新創團隊獨立於企業外部的原因。但很不幸的，大部分我所顧問的團隊都是擁有深遠歷史的企業，長時期的組織文化根深蒂固的在層層的組織中，此時如果選擇採用穩紮穩打的形式做敏捷化變革的單位，就容易走上 3B這條路徑。對自己太有信心的單位，往往會選擇較激進的手法做改革，則容易走上 3A的路線，明顯的無論是經過失敗區間或是衝突區間這段時間都不能待太久，待久了可能就會轉型失敗，而再沒有幹勁邁向活力與創新的區間了。

 

如何讓團隊自組織呢?

二種協助自組織團隊的方法，一個是 CDE法 (CDE是Container容器 – Differences差異- Exchange交換，源自Glenda Eoyang的博士論文《Facilitating Organizational Change: Lessons from Complexity Science》)這是目前最被scrum master 們廣為採用的方法，也就是依據CDE的模型來進行引導的動作(「引導」Facilitate；它的字面意義: 「讓事情變得容易」)。

另一個是Philip Anderson 的企業衍化七槓桿(在這裡《The Biology of business》，這是JOHN HENRY CLIPPINGER III與幾位作者共同出版的書，Philip Anderson負責第六章 Seven Levers for Guiding the Evolving Enterprise. 1999。書裡所說明的第一個槓桿:慎選外部環境( Select the external environment) 指的正是主管要善用此外部環境，藉著讓團隊在達成任務的過程中能夠順利成長並達成所賦予的任務，指導原則是參考鷹架學習理論。意思是指主管要製造一個便利於團隊自主學習的環境，並在工作中適時的給予協助克服種種困難，讓他們能夠順利完成任務。也就是所謂的不是只有授權後便認由他們去做不用在關心了，而是在必要的時機點扮演教練的角色，並藉由調整或協助克服困難以達到賦能的情境。(請參考赋能：打造应对不确定性的敏捷团队)

.

敏捷化；不外乎是推行敏捷的流程跟改變人心。

.

結語

敏捷執行的好壞怎麼評估呢? 我們在意的是效率變好了嗎?這一點好像只要把數位看板打開來，計算一下專案的「前置時間」與「實際開發時間」，相除起來就可以度量到效能的數值了(依據利特爾法則)，但我實在不建議這麼做。原因是每個專案都有它不同之處，很難只用一、二個標準去衡量他，這樣做太不公平了(巨觀來看，如果數量夠大，當實施的是 DevOps 時度量就不能疏忽了，當你評估的次數是百到千次以上的等級時，則得到的或然率評估就變得有参考價值了)。

我會選擇去看較抽象的團隊之間的信任度與責任感，而這二個項目正是企業文化在敏捷性這塊的表現。老實說；你不可能指望團隊裡的每個人彼此之間都充滿信任感，但是你卻能創建一種文化，讓大家在一個氛圍下有利於建立和增強彼此之間的信任度。

那信任度怎麼評估呢? 通常簡單觀察一下有沒有下面的現象，就能感覺出來了:

• 團隊遇任務受打斷時，是樂觀正面的接受，還是恐懼憤怒?
• 遇有插隊工作進來時，有沒有人自願出來認領。
• 團隊成員老是會自我保護，擔心被人誤解。
• 態度消極，老是一大堆理由。
• 對決策採取消極的抵抗和表現沒有誠意。
• 團隊一起罵主管，而不是就事論事。
• 沒有耐心，遇事急著下結論。
• 八卦滿天飛，只有抱怨缺少正面的觀點。

我經常有機會跟曾經帶過的團隊聚餐(有時是主管、有時是團隊成員)，言行之間便能輕易的問出團隊的現狀，這一點；經常讓人感概世事的多變(這篇文章就是這麼來的)。但也經常能欣慰團隊能持續的成長，可以拿來作炫耀。

.

主管透過透明、檢核與調適三部曲來擺脫成為敏捷化失敗的主要原因.

.

敏捷最不需要的是衡量

透明、檢核與調適溝成了敏捷化的三大支柱，從一開始實施敏捷化起，我們就應該努力的讓工作透明化，讓事實被看見，讓假設自動被澄清，把原本被隱藏的事情逐漸挖掘出來，讓大家都看見了，看見之後並且造成有相同的感覺，也就是達成「共識」，這個時期看板方法可能是最好的開始。隨後我們得依照看見的事實來進行檢核，這個時候能讓團隊自行擬定一些做事的規範，適時的學習自我檢視用來驗證工作的成果，這時候或許看起來會顯得幼稚或粗淺，有時候這群人還會犯上一些顯而易見的錯誤，但這不是問題，因為團隊沒有一起做過一些傻事，又怎能產生彼此之間的信任感呢。接踵而來的是透過回饋之後的調整。這時候我們會設法來放大回饋的效果。不能夠僅僅依賴檢核與回顧二個固定的會議來取得回饋，最好是事情發生的當下，在問題解決之後就立即進行回顧，讓經驗不斷的累積下來成為團隊的有價資產。而這三件事是一直持續在發生的(也是敏捷化的基本)工作，如果身為主管的人沒有意識到成長，或沒有讓其他主管感覺到團隊在成長，這才是做主管的人該檢討的事，也就是沒能讓團隊的成長透明出去，讓組織或企業看見這個事實，所以展現團隊敏捷化的成果是主管的責任。所以敏捷不需衡量，讓成效透明化是主管的基本責任。他能間接成就組織的敏捷化。

 

.

要怎麼測出人跟人之間的信任度呢？（有主管slack來問問題）

哈哈！這個問題容易，思考一下自己和某人溝通處理某件事情作決定的次數和採取行動的次數。試想要花多長時間和自己不信任的人完成一項任務？當你越是要花功夫為這次溝通作準備，那你們之間的信任度就越低。想想和充分信任的人溝通就知道了，打聲招呼就搞定了。

.

註.参考自《敏捷文化》The Agile Culture.

※ 要怎麼改善現有文化呢？

應該時時選擇去正視問題：

1. 消除下屬病態的恐懼 – 你們在擔心什麼？
2. 以團隊為主的業績考核，聚焦眼前的任務。
3. 要求短迭代，體驗協作。求取好的協作。
4. 期待成功但允許試錯。

.

※ 領導者該怎麼來培養團隊的信任呢？
1. 凡事出以公心。
2. 行事增加透明度。讓大家都知道你決定的依據。
3. 表現出值得信賴。
4. 為他們爭取福利，保護疆界。
5. 保持專業心態，樂於接受回饋。

.

敏捷成功了嗎?

.

如何讓業務敏捷起來 – 影響地圖

.

圖一、進行銷售時的影響地圖思維(業務的影響地圖草圖)

.

• 詢問客戶要的是什麼? (弄清楚客戶約我來的目標。)
• 然後設身處地的以客戶的立場思考我們公司的產品能幫上什麼忙?
• 接著展開公司產品為客戶所設計的功能。
• 最後，提供解題的具體方案，並解釋給客戶了解。

.

所有的主管都必須懂業務。

.

業務人員需要敏捷嗎?

範例一、櫃台有留言，某中大型企業要求與我們的業務取得聯繫。我是一位半資深的業務人員，談不上資深是因為部門裡還有好幾位前輩在。而我被指派負責前去拜訪客戶，下班前趕緊把公司的廣告型錄帶上，預做好迎接新客戶的準備。回家的路上那種躊躇不安的心還是持續的干擾著思維，雖然我已經不是菜鳥了，但每當要去call 新的客戶，在還沒與客戶碰面之前，還是會有心靈不安的感覺。我覺得需要一種策略規劃的工具來協助自己幫客戶解決問題。尤其是這種未知的課題，誰知道這個客戶又會冒出什麼難題來，而我能回答的好嗎?

》類似的情境，會在你初次與客戶見面之前，一再的重複著。

 .

範例二、在排定需求優先順序的會議中(註1)，產品部門受到開發部門強烈的質疑，為什麼要先做A而不是B呢? 一番爭執之後，雙方似乎都沒法說服對方，『歸根究底來說；客戶到底會先要什麼? 』:負責仲裁的大PO說話了，客觀一點的作法是先找提出需求的業務來說明一下，讓我們能夠針對需求的原委有進一步的了解，也好做判斷些。此時大家把目光轉向了與會的業務主管，原本只是代表業務部門來看看下一季會有那些功能可以拿來面對客戶的，此時反倒成了大家要做抉擇時的關鍵了。業務主管先清了清嗓子:『老實說，這幾個需求已經擺在清單上很久了，客戶可能都不記得了，應該是問不到了』。

.

客戶提出要求的當下，是釐清需求的最佳時機。

.

》類似的場景在做需求排序的會議裡一再的重現，而成熟的分析師都知道，要想釐清需求得在客戶提出的當下，就立即進行釐清、紀錄才是，事後再要來追問原委，恐怕都會有所爭議了，也就是說需求要做釐清、確認，一定要在客戶還沒忘記以前讓他簽字才會有效率，這是大家都知道的「需求訪談」時的不變真諦。所以在客戶向業務提出需求的第一當下，便是一個釐清需求的好時機。但問題來了，要有怎麼樣的背景的業務人員才做得來呢?

 

著名的《實例化需求》的作者GOJKO ADZIC 2012發明了一種策略規劃的工具叫「影響地圖」Impact Mapping以提供給業務使用，他的目的是希望在推行企業敏捷化的當下能把業務部門、產品部門及開發部門串接起來，真正的實踐 DevOps所謂的端到端的價值交付。

.

以一種協助客戶解決問題為前提的策略規劃

.

※豐富化你的影響地圖，下圖跟上一張圖最大的不同點是，加入不同的角色，由不同的視角，產生不同的影響及做法。

.

多種角色 – 不同影響  – 不同的做法

• 弄清楚可以達成客戶真正目標的各種解題方法。
• 以不同角色的立場對目標進行分析。
• 以不同的角色(視角)分析出不同的行為影響。
• 針對不同的行為提供實質的做法。

.

影響地圖視覺化了不同角色在不同解題方案之下的各種可能影響的狀態。我們得到了實施各種解決方案在路徑上的里程碑，以及它們的替代方案及據此所需要的度量與評估，以便於進行決策的參考。

.

行銷最大的武器是對公司產品功能的深入了解。

.

》影響地圖可以協助客戶將需求視覺化。

影響地圖；由誰來製作它就會長成那個樣子。

.

製作影響地圖

首先要問的是，誰應該負責製作它? 作者GOJKO說道:「想要發揮影響地圖的最大功效，就要與高級技術和業務人員一起工作。」應該要由一群專長不同的人的一起協作，但老實說；由誰製作它就會長成那個樣子。業務人員與客戶可能是初版影響地圖的製作者(如圖一，影響地圖草圖)，而接手的市場人員是持續維護或修改的主要人員，至於開發人員則適當地提供了在各個里程碑的度量數據與可行的解提方案。

 

市場部門應該是影響地圖的最佳Owner

【準備】

1. 發現真實目標 (由業務人員手裡獲取業務影響地圖草圖)
2. 定義需要的度量(由技術人員提供適當的協助)
3. 計畫第一個里程碑。

.

一個完整的影響地圖製作步驟

.

【製作】

1. 畫出地圖框架: 問出目標是什麼? 列出相關的角色? 依據角色推論出可採取行動。
2. 找出首要路徑、找出可行的替代選項。
3. 確定出關鍵優先順序

 

※ 採用反覆運算交付的團隊應當一次只處理一個目標。因此分成多個目標個別來完成，會比分成多個階層分段完成要合適。

• 視覺化並不代表大家就都有共識了，要透過個別闡述與排序之後才能達成共識。
• 不要想當然地認為所有列出的東西都是要實際交付的，你應該把列出的交付內容當成可選項(Option)。

.

範例說明: 財務交易處理

.

來自《影響地圖》書上的範例及說明

.

這個地圖說明的是交易處理系統的某個里程碑，關鍵目標是降低10%的交易處理成本。

【影響路徑1. 在德國的結算團隊的路徑】

一個選擇是減少處理交易需要的手工工作，選擇針對德國的結算團隊的角色做處理，假設他們能更快地處理重要的例外交易，就能降低下游團隊的工作量，從而極大降低交易成本，方法是；引進全自動處理流程，這將直接降低結算和所有下游團隊的工作。

 

【影響路徑2. 交易員的路徑】

另一個選擇是設法減少處理交易例外的數量並減少非標準的交易量，方法是；設法引入更多交易類型，即透過部門級的報告來加強控制。

 

【影響路徑3. IT運維的路徑】

其中的一個關鍵假設是，降低IT運營成本可以實現這個目標，對應的方法是簡化系統架構和淘汰需要較高支援成本的老系統，也就是選擇做系統優化，然而，優化系統需要很大的工作量，因為要到核心架構所以相對的風險也會高些。

.

像公路地圖呈現了市鎮以及連接它們的道路一樣，影響地圖展示了我們要構建的東西，以及它們與人們使用方案解決的問題之間的連接。公路地圖的首要任務並不是提供關於市鎮的詳細資訊，而是清晰展示它們之間的連接；它的次要任務是幫助我們發現替代線路。討論影響地圖上的節點，以及如何連接它們的不同假設，可以讓不同領域的人高效參與進來，發現有效的解決方案。

.

》誤導! 下面是一般對影響地圖的定義，實質上它是打破DevOps與業務部門邊界的有效利器。

一般的定義: 對產品開發和運營組織，影響地圖是一個簡單卻又十分高效的範圍管理、戰略規劃和協作方法。

實質意義: 它提供組織不同部門人員，以相同的視角，去正視客戶的需求，它是打破開發部門Dev、運維部門Ops與業務部門SD之間邊界的利器。

.

• 反覆運算式的計畫通常缺少了完整的圖像

影響地圖剛好架起了兩者之間的橋樑(反覆式與全盤計畫式)：它既可以組織戰略規劃、思想以創建關注業務目標的整體圖景；同時也可以引導反覆運算交付過程中的持續學習，協助我們管理專案的各個里程碑。

.

結語

由推行敏捷化到進入DevOps持續交付/部署的領域，二者之間最大的差異在原本只是在意於開發階段的速度，進而變成去統計整個企業的生產效能(請參考《加速》一書)，將過去只專注於生產效能的局部優化，延伸到去度量組織整體的效能，這一點讓敏捷化也開始走入組織裡的各個部門中，大家不禁要問道:「敏捷可以給我什麼?」一時之間，敏捷可以給業務什麼?成了串起DevOps所強調的端到端的價值交付的第一個環節，其實；我們可以試著倒過來思考這個問題，也就是業務需要敏捷提供什麼呢?

 

GOJKO ADZIC 寫於2012的策略規劃工具則填補了這個缺口，它叫影響地圖Impact Mapping.它提供了業務部門、產品部門、開發部門及運維部門以各自不同的視角，來協同合作探索如何滿足客戶的需求及盡快交付價值給客戶。這是策略規劃的一大邁進，而不是如”用戶旅行地圖”一般只是提供了釐清需求的一種方法。因此；如何讓業務人員習得繪製影響地圖草圖的技能(圖一)，便成了組織跨部門實踐DevOps的一大挑戰了。

.

讓敏捷走入業務環境已經成了實踐DevOps的一大課題

.

註.

》需求排序的會議一般簡稱為ONEPB(One Product Backlog)會議。是當組織內區分成多個開發團隊時，為了開發上能夠協同合作集中開發的戰力，而刻意的把所有的需求排進一個共同的列表裡，陳列在越上面的需求便越快會被做到，為排序所衍生出來的需求排序會議。

》 影響地圖的最佳Owner 是市場部門，而草圖的繪製則很可能是由業務人員所繪製。

》「影響地圖範例遊」

.

.

.

.

.

.

.

.

.

》如何繪製影響地圖的四個重要提問

影響地圖的繪製是由一群人從提出問題、討論答案所組合出來的視覺化紀錄。繪製時要問的四個問題如下:

• 目標是什麼Why?

也就是詢問為什麼要做這件事。由確立目標做為出發點。

它回答了最重要的議題：我們為什麼做這些？也就是我們試圖達成什麼樣的目標。GOJKO把它稱為「地圖的中央部位」，業務人員應該是第一位提出這個問題的人選，時機就發生在客戶陳述了它的問題之後，這是要避免業務人員直接就接受客戶的需求，而沒有進一步釐清需求。

 

• 誰能產生需要的效果Who？

影響地圖的第一層回答了以下問題：誰能產生需要的效果？誰會阻礙它？誰是我們產品的消費者或使用者？誰會被它影響？也就是那些人是會影響結果的角色。

為了能夠高品質地又快速的交付價值，我們首先要理解的是：這些人是誰，他們想從我們的產品或專案中得到什麼。這是DevOps中最重要的端到端的思維，也就是我們在做產品前應該先弄清楚使用者的期待和他真正的用法。繪出這些角色，探討不同的角色他們真正的需求，自然能弄清楚產品真正的用戶，也可以協助我們思考程式應該做到什麼樣的程度，也縮減了那些沒有必要的範圍。

 

• 這些角色的行為是怎樣改變的How？

影響地圖的第二層從業務目標的角度設置角色，它回答如下問題：角色的行為是怎樣改變的？他們怎樣説明我們如何達成目標？他們如何幫助或妨礙我們取得成功？而這正是我們試圖創造的影響。

 這正是我們試圖創造的影響。交付成功的關鍵在於理解客戶想要做什麼，而不是他們對於產品和服務的想法。這説明了交付組織調查不同的技術選擇，探索不同的解決方案，從而達成更好的結果。這些選項在這裡被繪製出來了，視覺化讓我們清楚自己有哪些替代方案(alternative)存在，一旦目標有所改變，替代方案或許就成了主要影響路徑了。

 需要強調的是，有些影響是有競爭性的，有些是相互衝突的，有些則只是補充而已。我們並不需要實現全部影響，我們要經常去比較和設定交付內容的優先順序，經常修正避免開始時做了錯誤的假設。

 

• 我們可以做什麼來解決它What？

一旦回答了前三個問題，我們就可以開始討論範圍了。影響地圖的第三層，回答了以下問題：作為一個組織或交付團隊，我們可以做什麼來支援影響的實現？包含：交付內容、軟體功能和組織的活動。也就是解決方案。

 這是影響地圖中最不重要的一個層級，不要在一開始時就試圖把它做完整，你應該在反覆運算交付過程中不斷完善它。