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

.

銷售思為.png

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

.

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

.

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

.

業務人員需要敏捷嗎?

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

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

 .

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

.

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

.

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

 

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

.

業務解題.png

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

.

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

.

銷售思為_1.png

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

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

.

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

.

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

.

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

Impact Mapping_1.png

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

.

製作影響地圖

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

 

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

【準備】

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

.

1j4y.48.png

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

.

【製作】

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

 

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

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

.

範例說明: 財務交易處理

.

範例1

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

.

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

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

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

 

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

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

 

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

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

.

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

.

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

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

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

.

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

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

.

結語

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

 

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

.

devops_sale.png

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

.

註.

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

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

》「影響地圖範例遊」

.

1_範例.png

.

2_範例.png

.

3_範例.png

.

4_範例

.

5_範例.png

.

6_範例.png

.

7_範例.png

.

8_範例

.

9_範例.png

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

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

  • 目標是什麼Why?

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

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

 

  • 能產生需要的效果Who

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

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

 

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

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

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

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

 

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

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

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

 

敏捷開發學習前移

學習前移.png

在影響地圖中運用行動學習的技能,讓敏捷開發產生學習前移的效果。也就是在需求仍在分析的階段時就有機會在ㄧ邊擬定工作需求下(運用影響地圖功能進行需求分析)一邊進行針對完成專案所需要的相關知識進行學習,或可稱之為在行動中進行學習,也就是 Action Learning.

.

敏捷需求的分析工具

.

敏捷探討需求的分析工具

圖示.png

敏捷探討需求的分析工具說明

.

專案負責人Product Owner的利器

  1. 產品心經: 產品經理應該知道的60件事
  2. 超越需求: 敏捷思維模式下的分析 (Beyond Requirements: Analysis with an Agile Mindset)
  3. 用戶至上 (Understanding your users: a practical guide to user research methods) 用户至上(用户研究方法与实践原书第2版)
  4. 如何衡量萬事萬物:大數據時代,做好量化決策、分析的有效方法 (How to Measure Anything: Finding the Value of“intangibles” in business
  5. Essential Kanban Condensed  by David J Anderson and Andy Carmichael
  6. 使用者故事對照 (User Story Mapping: Discover the Whole Story, Build the Right Product)
  7. Google 創投認證!SPRINT 衝刺計畫:Google 最實用工作法,5天5步驟迅速解決難題、測試新點子、完成更多工作!(Sprint: How to Solve Big Problems and Test New Ideas in Just 5 Days)

看見的力量 – (II)影響地圖

Impact Mapping 真是令人驚豔的視覺化工具。等你看完這篇文章,你會愛上它的。

典故

繼2011年6月Example of specification《實例化需求》一書的偉大貢獻之後(獲得 2012年 Jolt Award 年度最佳圖書大獎),Gojko Adzic 說我會更努力地在需求這個領域裡做出成績來的,請期待。他果然沒有讓大家等太久,2012年10月他發行了 Impact Mapping《影響地圖》這本只有三個部份,共73頁的小冊子。小冊子只說明了一件事:如何把概念視覺化 – Impact Mapping影響地圖。它展現了一種「讓需求視覺化的能力」,用簡單的 Why-Who-How-What的分析法,搭配結構化的顯示方式,讓工程師能夠看見辛辛苦苦開發出來的功能是對應到哪一個業務的目標上。哈哈! 其實是倒過來的,因為它十分適合運用在需求還是極度抽象(概念)的時期,他讓業務目標能夠清晰化,讓大家都能以較抽象的方式看出需要那些功能才能達成這樣的業務目標。它能夠串聯出來一條相關的影響路徑,並藉著關聯的圖示化,讓需求被看得見,這一點對產品的早期,還在做雛型設計的作業上有著極大的貢獻。’

 

用Impact Mapping來分析電影  — 另類的詮釋

這是我的最愛,運用電影來闡述演講的情節內容(大概是2005年開始的,我記得當時講的第一部電影是基諾.李維的驅魔神探 康斯坦丁,技術上要探討的是微軟 Message Queue 的理論)。手法是在演講中撥放一段2到3分鐘的電影精彩片段,讓學員透過視覺化的影像,試著聯想著跟演講主題的種種關聯性,達到一種比單獨聽講者演說更為有效的共鳴。這招用多了以後,就自然而然成為了自己演講時的特色。一些熟識的學員,總會在上課前順道問一下今天會放哪一部片子啊?!

但這回採用impact mapping, 則是真的用來分析電影用,與技術無關,假借著運用它視覺化的能力,讓沒有看過這部電影的人也能像劇務一樣的熟悉著每個場景(似乎講得太誇張了,實質上只是畫出它的路徑而已,若是想要完全了解它,還是要配合著去看劇本吧,至於所有的功能描述,那是每個參與演出人的”腳本”),了解各個場景試圖要帶給觀眾的效果是什麼,以及它所想達成的目標。以下便是電影白日夢冒險王的影響地圖(或許是它的主題曲太吸引人了,所以就選它的電影來當範例了。它叫: Stay alive)。

00 requirement_Walter

由左往右;依序陳列的是電影要達成的目標,有哪些重要的角色,而這些角色要強調的是那些特色,這些特色所需要的構成因子,最後是用怎樣的劇情演出才可以獲得這樣的效果。(有一條可以依循的路徑,好像就可以勾勒出the whole picture,這是我們在思維模糊期所最最想要的,尋找條可以依循的思路,這需要練習,來動動手吧!)

試著用這些資料,開始說故事吧:

主角的目標(Why): 找到第25張底片,來做雜誌最後一期的封面故事。

人物主角(Who): 華特.米堤 Walter Mitty(由班·史提勒飾演)

主角的個性特色(How): (1)愛做白日夢。(2)是典型的宅男。

影響這個個性的描述(What): (1)表現得經常發呆、幻想。(2) 非常容易觸景生情。(3)少年時打工後遺留下來的創傷,等等。

場景(Scenario): 這是我自己加上的。因為要做這樣的個性描述,該有怎樣的布景來做配合,預備動用多少演員,準備拍攝多長的底片(也就是預備花費的成本)及腳本。

 

只是一張簡潔的圖示,針對 一個目標,陳述著;第一層、誰Who:指出主角人物,第二層、怎樣How:個性特色的描述,第三層、什麼What:列出影響的因素,然後再針對這些個因素設計出能夠展現達到讓觀眾引起共鳴的場景片段。最後再檢驗這些個片段是否能達成我們所預設的目標。這樣便OK了!一齣戲的極度抽象輪廓便可以成形了。

看著這張圖示;不論是導演、演員或是劇務,依靠這樣的說明,似乎看見了劇本中賦予這個角色的全貌,大家開始有了個基本的輪廓,也就是我們所謂的對主角、人物的輪廓, get the whole picture看見全貌(請注意Impact Mapping 是用來描述部分路徑的影響因素的,然後分析有它或無它的影響性,而不是用來分析所有相關路徑的全貌的,那就太複雜了,也就是說;因為故事的全貌通常都會太過於錯綜複雜,遠遠超過這種直列式分析方式的範疇,就是關連性太高、太複雜了很難畫出來,或是根本就畫不出來,因此我們幾乎不會把所有的相關因素都畫出來,只把重點放在想要探討的路徑上)。

 

老實說,我好喜歡用它來分析電影。而且每當分析完電影的那一刻,我總會覺得(自以為是的)自己可以去當導演了(或許應該把這種方法介紹給李安吧!)。

因此這一段我先用電影來跟大家分享自己的心得。但運用在軟體開發上,要怎麼轉換呢?

※請看它的使用者故事:

身為白日夢冒險王的主角,我希望能夠表現得常常發呆、幻想,從此以後當大家提到Walter Mitty時就會想到我是一個愛做白日夢的人。

 

電影說完了,開始講正課吧!

「誰Who」 剛好對照到使用者,「什麼What」則是對到願望,「怎樣How」對照到利益。我們能夠很容易地由視覺化的影響因素,引導出相關的使用者故事。這一點剛好可以提供我們在向他人陳述故事時的關聯性說明。

※附帶一提;在撰寫使用者故事的時候,應該是寫三張卡片而不是一張。

第一個故事卡片上描述實際的故事;

第二個是預留位置。為我們看到第一個故事後必然要做的改變保留位置;

第三個故事卡片就完成那些改變後所需要做的優化。

 

《依循這種方式,很快的你就會有一大堆使用者故事了,當資訊過多的時候,反而會讓你看不到真正工作的主軸,此時便該是使用者故事地圖出現的時候了》

 

 << 下面這一段參考自中文譯本,是標準教材,到處都可找得到。但請記得;看完後挑一部自己喜歡的電影,製作它的影響地圖,會很有成就感的!>>

 

何謂影響地圖?

一個簡單卻極高效的協作性的策略規劃方法

影響地圖Impact Mapping是一門屬於戰略性的規劃技術,通過清晰的溝通假設,説明團隊根據總體業務目標調整其活動,以及做出更好的里程碑決策,影響地圖可以説明組織避免在構建產品和交付專案的過程中迷失方向。

影響地圖可以有效的評估交付,作為品質回饋的標準之一。

 

 

影響地圖的結構

它是這樣的一個思維邏輯和組織結構:

 

為什麼(Why–>誰(Who–>怎樣(How–>什麼(What

 

也就是:我們的目標是什麼(Why),為了達成目標需要哪些人(Who)去怎樣(How)影響,為此我們需要做什麼(What)。影響地圖通過構建產品和交付專案來產生實質影響,從而達到業務目標。

 

 

影響地圖的特點

結構性:從業務目標到交付的結構化梳理和挖掘的方法,目標–角色–影響–產出物。

整體性:連接目標和具體交付物之間的樹狀邏輯圖譜。

協作性:利益相關人一起溝通討論協作,把隱藏在個人頭腦中的預設的思維邏輯挖掘出來共用。

動態性:動態調整、反覆運算演進、經驗證的學習。

視覺化:一個清晰的視圖,關聯性的結構一眼可以望穿、易讀。

它將各種角色以不同的視角,不同的思維邏輯,不同的前提假設,通過視覺化和協作的方式進行整理、說明,相關性再作連接,一下子就串起來了。通過連接交付內容、影響和目標,影響地圖顯示了之所以去做某一個功能的因果關係,同時也視覺化了各利益相關人所做出的假設。這些假設包括了:業務交付的目標,涉及目標關係人,及視圖畫所達到的影響。同時,影響地圖溝通了兩個層面的因果關係假設:

1、交付會帶來角色行為的變化,產生影響;

2、一旦影響達成,相關的角色會對整體目標產生貢獻。

小結

影響地圖可以作為使用者故事地圖的有效輸入,它剛好可以很有秩序的產出使用者故事減少我們運用頭腦風暴時所大量產出凌亂無序的使用者故事— 好的整理工具。它讓我們看到了使用者故事與業務價值之間的聯繫關係,這一點可以避免我們做了一堆沒有商業意義的功能。最後;它能讓我們在調整業務目標時,明確的判斷哪些功能該繼續做完,而那些功能可以不用做了。

還是用電影來做結尾吧! 影響地圖是極度抽象的視覺化產出物,就好比劇本裡的人物關係圖示,想知道真正的工作細項,還是得去閱讀劇本/腳本吧! 下一回;我們就來談談使用者故事地圖,它就是我所謂的劇本!

 

附上學員在上課時的作品:

00 榜00 即刻獵殺00 丹麥女孩

00 神鬼00 interstellar00 Lobster