Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 三月 2016

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

with 2 comments

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

 

 

 

 

 

 

廣告

Written by ruddyllee

2016 年 03 月 26 日 at 08:19:00

看見的力量 – (I) 解題的思維

with one comment

這篇文章;已經梗了我三個多星期了。這期間飛了二次大陸做演講、往返幾個大城市做教授敏捷開發運用在精實創業的課程。教材內容都是簡體的,它們始終沒有機會在國內用上,心理常想著;無論如何我都要把它們翻成繁體中文,雖然國內沒有人找我講這個課程,沒關係。就把它登在大眾媒體,跟大家分享。(哈哈! 寫了幾回草稿,但旅行中杭州的雲霧繚繞還有茶香美景並沒有幫上忙,文章架構依然凌亂,倒不是沒有頭緒而是頭緒太多。最後我決定改用分段的方式來跟大家分享,希望你能接受。)

 

看見的利器

※「看板方法」Kanban Method
可以讓我們看到工作流程,然後依據半成品的理論來持續改善、管理流程。

※「使用者故事地圖」User Story Mapping
可以幫助我們階層化使用者故事並整理出需求的全貌,讓我們知道該從哪裡開始來解題、動手實做專案。

※「影響地圖」Impact Mapping
可以把業務目標跟產品功能串接起來,然後讓客戶、分析師及開發團隊都能看見撰寫的產品功能對業務的影響在哪裡。

好了;這一系列文章就是在談上面這三個東西,三個可以協助我們看清楚需求的工具(方法)。標題似乎可以改寫成: 如何運用這些方法來看見需求的本質。而想談的問題是;藉助視覺化 Visualize的力量來解決專案開發時需求變來變去的困擾。用一張圖示,來說明這幾個工具的運用時機。(一下子;輕輕鬆鬆便可以畫完的圖,但改用文字來描述起來還真是有一點麻煩。我想用如何思維解題,到過程的描述分析,然後在對應到想要完成的目標,最後是拿來輔助的工具來探索它。順序就是依照下圖最左側的那一行【思維 – 過程 – 對象 – 工具】)作為一系列文章的起頭。

0 視覺化產品開發中的價值

第一排思維的方式

由「極度抽象」到「抽象」再到「明確」最後寫成程式碼,達到「極度明確」的解題方式。

這是我慣用的一種解題方法。解題;一開始;要先後退個幾步,讓自己跟問題物件的距離先拉遠一點,減少一些訊息數量的干擾,讓自己的視野再加大一些,能看得更全面一點。目的是;設法看見全貌。這可是自己花了好多年的時間才糾正過來的習慣,避免患了一看到問題就急著思考如何解題的習慣,就是俗稱的「工程師的視野」。

 

在抽象與明確之間徘徊解題  –持續優化

想辦法先看到。當你經常受到需求改來改去的殘害時,最好的解決方法便是讓它提前優化,運用paper prototype 或其他成本較低的方式先行對問題的解答進行驗證,針對產品功能是否解決了真正的業務需求進行模擬或假設式的確認。我習慣在這裡來回穿梭,寧可多花一些時間在抽象與明確之間徘徊,也不願意太快進入程式的撰寫階段(你可以先做未來展示時會用的PPT,或就手頭的需求先整理一些Spec,不要急著收斂),這倒不是在逃避寫程式,而是擔心一旦開始寫了些程式碼,要回過頭修正假設錯誤的地方,就要多花一些功夫在修正程式邏輯上頭,這要賠上許多時間,有些划不來。而且程式一旦改來改去,總讓人覺得好像有一種壞味道油然而生(有些不衛生,不幹淨的感覺),還是慢慢來,一次做對比較乾淨舒服些。

 

倒推的方式是最常用的手法。也就是所謂的從最後開始(Start at the End)。先想像你已經完成文件上所陳述的功能了,然後回過頭來看看問題是否真的被解決了嗎? 試著問自己;使用者因此就可以如同用戶故事上所描述的「因為獲得了他想要的功能,從此以後便能獲得這樣的利益了」。(當然,用影響地圖在這裡最為受用,請容我下次再補做說明)

針對較頭痛的問題,我通常會採用寄信給自己的方式,用email藉由時空的延遲隔離,來和自己交談(一種自己給自己的回饋方式),用說交談的方式來進行自我回饋,用這種稍稍客觀的形式來提醒自己,讓時間帶來多一點的資訊獲得,也就是依靠延遲決策的方式(Decide as Late as Possible),讓思維更為成熟一些(哈哈!很難說這種方式會有用,但一經養成習慣,心態便會穩定需多)。

 

明確到極度明確

第一步;先確認文件規格是正確的。我習慣先整理足夠用來做coding用的文件規格(可以用測試案例(Testcase)或是單元測試來當作文件),先把測試的方案開起來做好命名,最後才是建立主程式專案,這裡才是接下來的戰場,這種方式有人就認為是TDD了,但我實際上只是要透過預做準備的動作,來多思考一次也就是擊發二次思維(2nd thought)的動作而已。接著才是興高采烈的進入coding 階段。期許自己能夠一次做對,讓coding 變得更有趣,讓code變得越簡單越好(偵錯)。

 

小結

針對上圖所示,我們先談第一排、所謂的「解題的思維」。解題;它沒有標準,上面是我長期以來一直依據的Mary shaw 抽象解題法的使用心得。提供大家做參考,下一篇就會開始描述處理需求的「影響地圖 impact Mapping」。會這麼做,是害怕自己沒有足夠的時間做長篇大論,就以這種分段描述的方式,盡量抽空來做作功課了。

 

Written by ruddyllee

2016 年 03 月 25 日 at 11:38:01