建立你的Impact Map

認識我的朋友都聽過我強力推薦這本書,這本書影響我非常的多(尤其感謝我的啟蒙者Goufang Young),幾乎可以說是我在學習軟體工作領域的聖經參考,最主要的原因在於:
- 他鼓勵你面向多個不同的關係人,去跟他們接觸討論,知道它們的期待與可能受到的影響
- 保持中立,不因個人喜好而很快地走入偏頗的技術決策結果
- 很扎實地告訴你該有哪些基礎知識來幫助你做分析與設計
- 一部分的提到了CMU SEI ATAM,是個很有趣的方法論
影響地圖對人的執行力的幫助
無獨有偶的,在多年後Impact Mapping 這本書的推出,恰巧也在講述關於”影響”這件事情。他基於4個提問的原型( Why , Who , How , What)來分層的剖析對於目標(Why),誰來達成這目標,如何達成目標,以及產生的影響與後續的不斷深入層面去深究,找出你的 通往完成的路徑。

這也讓我想起之前看到目前稱霸日本職棒的 投打二刀流的 大谷翔平的一段軼事,在他高中時代還在打甲子園的時候,因為看到前輩 菊池雄星獲得6球團聯名第一指名加入NPB的強大,為了挑戰自己他就宣稱他未來要以8球團聯名第一指名的身分加入NPB,但他這小弟不是只是喊喊的,他訂出了他一套的 多層次夢幻九宮格的執行計畫目標:(更多關於大谷的介紹,請參考)
- 首先我的目標是 第一指名加入NPB
- 我要賭上我的青春催出160km的球速
- 增加變化球的掌握力
- 體力的增長
- 其他 (我日文不好請網友幫忙補充)

野球霸氣男兒講究目標不談夢想,夢想吹吹吹就算了,目標是要去實踐的 !
看到這上面的N層發散的九宮格了嗎? 要完成 大谷的目標總共要戮力執行 72個重要的行動,而且只有三年的時間得完成他,才能在高中畢業就達成第一指名的成就!!!
在此再搭配筆者昨天才發的一篇文章: 視覺化紀錄
我現在可以100% 保證,用一張大圖來勾勒自己的思考與執行的目標,是非常有用的!!!!
把圖像與文字串接起來,然後貼下來並時時讓你去追蹤自己的執行狀態到哪裡了。
PS: 我好訝異日本高中都有教這些幫助自己思考的方法,我在台灣吃了幾十年的米了,都還是要到處去抱大腿找豔遇才知道
完整的目標設定採訪影片參考這裡:
https://www.youtube.com/watch?v=5rsQVolOrBs&
從上面大谷的例子當中,我們可以理解關於 建立一份影響地圖的做法是怎麼來的:
- 先找出你真正要達成的目標
- 定義出可以被衡量可被量化的標準
- 逐步找出一個個初步的里程碑
有了前述的基礎了,接著要對應到落地實踐 ( Show , Don’t tell)
- 勾勒骨幹
- 找出執行項目的可能替代方案
- 排定優先順序
- 做下去,獲取成果,或者去學習如何達成這目標
影響地圖該怎麼找出來
昨天才跟朋友 ( Russle Cheng ) 聊到關於在銀行業,做系統開發的時候,經常系統分析師都只能接觸到很後段的 feature (功能要求),但是這些功能並沒有真實的反應到,在櫃員前台真正執行日常業務時的需要,也未能清楚的說明 這一系列的功能調整或新增,是為了那些真正的業務目標(Business Goal)而來的,反正就是業主甲方提了啥我就做啥,等做完再來發現很多白做工 或者根本沒人在用的功能留在那…
找出真正的目標
- 把背後真正可以拍板的權益人找出來(通常是出錢的人)
- 把這群人群聚起來,拿出白板與時間軸
- 讓他們真的列出想要的期望清單(或者說 奇妙清單 :D)
- 排上幾個里程碑,試著讓大家理解在時間軸上排上的里程碑 就是只能塞滿多少期望清單
- 如果沒有人能講出什麼是業務目標,那麼你可以試著去提幾個feature ,並提問這些feature是否是為了滿足某些目標,透過提問來喚醒真正的目的
- 假設問到關鍵點了,而這些行為會做出調整,那麼問問為何這些行為的改變很重要
- 那這些業務目標是否有用?
定義你的衡量指標
當你找出真正要達成的目標以後,你依然會需要知道怎麼樣才叫做達成目標
譬如說某家電商一直期望團隊能在 1Q 過後,能夠讓交易量成長,但具體衡量指標沒概念,這時候拉抬會員數增加10000人就是一個參考
Tom Glib 在他的著作 Competitive Engineering 當中提到如何去找出精確的衡量目標指標的方法,不過本書確實已經非常久遠了 (2005年),在此有幾個比較關鍵的方法可以先參考著用,若非常有興趣的人可以去翻看看Tom Glib 的著作:
- 什麼是我們即將要去評估衡量的部分? (Scale)
- 那要怎麼評估? (Meter)
- 現在這件事情的現狀如何? (Benchmark)
- 最小可以接受的狀態是什麼? 什麼時候會達到平衡點(原文指損益平衡 break-even) ?
- 拿來投資的項目 (Constraint)
- 最終期望帶來的價值 (Target)
看到這,不禁讓我想起AWS的雲服務的 設計理念 !!! 在決定軟件系統架構的Scaling 能力時,基本上也是依循著上述的幾個點去逐步完善的。
Scale for EC2
Meter for metrics something like I/O , CPU, Memory
Benchmark for current usage statistics
Break-even for Quick Scale out and Slow Scale in
Constraint for What you really needs
Target for All non-functional qualities for Services.
透過這幾個連續的提問方式來促進團隊問答討論,能更多面向的看到不同人對這些業務目標的解釋有所不同,這時你需要的是 — “先發散再收斂”。很有可能你最終會回歸到,好吧 那這些都要做花費多少錢,若花費對比不上帶來的價值,那麼爭論自然就會有所改變,最終而獲取共識而非妥協。
計畫你的里程碑

拜現在大家越來越能接受敏捷思維所賜,所以要找個Incremental 與 Iterative 的比較實在是容易的多,對於Sponsor來講,他期望付出的每一分毫,在任何時間點都希望是有價的!!
所以,別再純粹的 Waterfall了 …
有了目標以後,我們需要幾個里程碑(milestone)來逐步交付產出物,但是我們怎麼選在那些時間點該先完成哪些事情?
- 用錢來算,讓你的真正的sponsor 出來看這些業務目標,對每一個目標標上它值多少錢
- 通常最值錢的事情,在當下的時間價值會最高(這意味著可以在下一個時間波段去重新衡量價值)
- 基於最高價的進行排序
- 基於團隊的能力在里程碑裏頭放上可能可以做到的最前面幾項
- 如果每一件事情都要花得太長時間或太大資源,你該再試著去拆小一點
- 是不是開始覺得 User Story 與 Impact Mapping 真的是絕配了 !
開始建立地圖骨幹

以下是以一個遊戲公司希望增加100萬玩家的目標來開始推展 !
當開始以 4個W的提問原型開始展開細節時,我們需要問問自己幾件事情:
- 這些被我們找出來的功能 真的會有影響嗎? 真的可以?
- 這些影響對真正參與的人來說真的是可以接受的?
- 這些功能就算真的做了,能真的達到目標嗎?
- 如果自己都說服不了自己,也就再從頭來過吧 ~
找看看有沒有替代方案?
當你勾勒完第一次的影響地圖後,試著讓團隊分組再多想一下有沒有其他替代的選擇,譬如說更省錢或者更快可以提交的,這過程不要去責難或挑戰團隊的產出,目的是希望多聽不同的聲音,因為很可能這些替代方案,都會在非預期的狀態下可能發揮效用 (譬如忽然跑了一堆人,公司資金短缺)。
而這些替代方案也不是隨便就找出來了,可以依循以下這幾個問題來去催化生出這些替代方案 :
- 還有誰能幫我們多做哪些事情?
- 誰可能阻礙到我們?
可以試著填寫下面這幾張卡,就能找到替代方案的可能性。


找出關鍵優先權
其實找優先權這件事情,在不同人身上看到的結果完全不一樣,比較好的方式是讓sponsor出來講,從影響的層面重大者優先,影響得多的意味在當下的市場價值是大的,這絕對比起開發團隊在那吹噓說我這架構複雜要先行開發,之後東西才做得好之類的 等等屁話 ~
你可以用點數的方式去標記,建議以3點為最大,點數再大多了就沒意義了

找出待施行的工作項目
經由一系列的 找目標,找參與者,找影響程度,接下來就是去把針對這些影響要去實施的工作給拍板下來去執行,必須注意的是我們不是要做整體大而全的思考規劃,更受喜愛的方式是”試錯” !
小範圍投入並快速獲取回饋才是王道,有太多不確定性的事情在那裏了,所以先做一個可以真正端到端的實現價值的東西才是正解 ~
可以透過以下的提問來提醒自己是否夠小夠快了:
- 有沒有什麼樣最簡單的方式可以達成這件事情,我們還有哪些可以做的?
- 如果不是很清楚這件事情的現況與未來假設他能達成的目的,那有沒有啥辦法可以先去嘗試測試看看?
- 能不能在還沒投入開發工作時就能先測看看?
- 能不能透過手動方式來跑這個業務流程,看看我們能得到什麼回饋?

在上圖中,每一個Impact 所推展的子項目都是他的假設,如果我們不能確定這些假設是否是正確的,那必須再去找其他方式去印證這些假設的可行性才行!
當一切都完成了,我們最終需要把衡量的指標給一起放到地圖上,用來提醒我們是否真的都做對了!
不僅是提醒,也是個很好的業務目標推展的 Roadmap 規劃 !

總的來說,筆者認為Impact Mapping 在很多面向上都可以使用,從通用的產品設計開發到個人生涯規劃都可以,只要你真的找到了你的目標 !
今天,你再次確認了你的人生目標了嗎 ?
