建立你的Impact Map

Kim Kao
Kim Kao
Aug 22, 2017 · 9 min read

認識我的朋友都聽過我強力推薦這本書,這本書影響我非常的多(尤其感謝我的啟蒙者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&

https://youtu.be/5rsQVolOrBs

從上面大谷的例子當中,我們可以理解關於 建立一份影響地圖的做法是怎麼來的:

  • 先找出你真正要達成的目標
  • 定義出可以被衡量可被量化的標準
  • 逐步找出一個個初步的里程碑

有了前述的基礎了,接著要對應到落地實踐 ( Show , Don’t tell)

  • 勾勒骨幹
  • 找出執行項目的可能替代方案
  • 排定優先順序
  • 做下去,獲取成果,或者去學習如何達成這目標

影響地圖該怎麼找出來

昨天才跟朋友 ( Russle Cheng ) 聊到關於在銀行業,做系統開發的時候,經常系統分析師都只能接觸到很後段的 feature (功能要求),但是這些功能並沒有真實的反應到,在櫃員前台真正執行日常業務時的需要,也未能清楚的說明 這一系列的功能調整或新增,是為了那些真正的業務目標(Business Goal)而來的,反正就是業主甲方提了啥我就做啥,等做完再來發現很多白做工 或者根本沒人在用的功能留在那…

找出真正的目標

  • 把背後真正可以拍板的權益人找出來(通常是出錢的人)
  • 把這群人群聚起來,拿出白板與時間軸
  • 讓他們真的列出想要的期望清單(或者說 奇妙清單 :D)
  • 排上幾個里程碑,試著讓大家理解在時間軸上排上的里程碑 就是只能塞滿多少期望清單
  • 如果沒有人能講出什麼是業務目標,那麼你可以試著去提幾個feature ,並提問這些feature是否是為了滿足某些目標,透過提問來喚醒真正的目的
  • 假設問到關鍵點了,而這些行為會做出調整,那麼問問為何這些行為的改變很重要
  • 那這些業務目標是否有用?

定義你的衡量指標

當你找出真正要達成的目標以後,你依然會需要知道怎麼樣才叫做達成目標

譬如說某家電商一直期望團隊能在 1Q 過後,能夠讓交易量成長,但具體衡量指標沒概念,這時候拉抬會員數增加10000人就是一個參考

Tom Glib 在他的著作 Competitive Engineering 當中提到如何去找出精確的衡量目標指標的方法,不過本書確實已經非常久遠了 (2005年),在此有幾個比較關鍵的方法可以先參考著用,若非常有興趣的人可以去翻看看Tom Glib 的著作:

  1. 什麼是我們即將要去評估衡量的部分? (Scale)
  2. 那要怎麼評估? (Meter)
  3. 現在這件事情的現狀如何? (Benchmark)
  4. 最小可以接受的狀態是什麼? 什麼時候會達到平衡點(原文指損益平衡 break-even) ?
  5. 拿來投資的項目 (Constraint)
  6. 最終期望帶來的價值 (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 在很多面向上都可以使用,從通用的產品設計開發到個人生涯規劃都可以,只要你真的找到了你的目標 !

)

    Kim Kao

    Written by

    Kim Kao

    To be an excellent System Software Architect . Remind myself never let passion goes by !

    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade