溫故知新，遇見影響對映(Impact Mapping)簡單卻極高效的戰略性規劃技術，提供讓需求視覺化的能力
什麼是影響對映(Impact Mapping)
一個簡單卻極高效的協作性的策略規劃方法
影響對映(Impact Mapping)是一門屬於戰略性的規劃技術，通過清晰的溝通假設，說明團隊根據總體業務目標調整其活動，以及做出更好的里程碑決策，影響對映可以說明組織避免在構建產品和交付專案的過程中迷失方向。
影響對映可以有效的評估交付，作為質量回饋的標準之一。
Impact Mapping有助於讓計劃、交付活動與組織的整體目標保持一致。
同時還可以幫助干係人關注價值創造（為什麼要做），而不是僅僅關注特性開發（做什麼）。
通過將任務與組織目標關聯起來，Impact Mapping增強了戰略、規劃、交付之間的反饋迴圈。
Impact Mapping是一種比較簡便的方法，它在特定細節識別的同時顯示了全域性檢視。
由來
繼2011年6月Example of specification《例項化需求》一書的偉大貢獻之後（獲得2012年Jolt Award年度最佳圖書大獎），Gojko Adzic說我會更努力地在需求這個領域裡做出成績來的，請期待。他果然沒有讓大家等太久，2012年10月他發行了Impact Mapping《影響對映》這本只有三個部份，共73頁的小冊子。
Gojko Adzic（作者）戰略軟體交付顧問，專注于敏捷和精益開發，尤其擅長敏捷測試、例項化需求和行為驅動開發。Gojko經常在國際上重要的軟體開發和測試會議上發言，並運營著英國的敏捷測試使用者小組。最近這十多年來，他一直在財務和能源交易平臺、移動定位、電子商務、線上遊戲和複雜配置管理系統等行業專案中，從事程式設計師、架構師、技術指導和顧問等工作。
小冊子只說明瞭一件事：如何把概念視覺化 – Impact Mapping影響對映。 它展現了一種「讓需求視覺化的能力」，用簡單的Why-Who-How-What的分析法，搭配結構化的顯示方式，讓工程師能夠看見辛辛苦苦開發出來的功能是對應到哪一個業務的目標上。
哈哈！ 其實是倒過來的，因為它十分適合運用在需求還是極度抽象（概念）的時期，他讓業務目標能夠清晰化，讓大家都能以較抽象的方式看出需要那些功能才能達成這樣的業務目標。 它能夠串聯出來一條相關的影響路徑，並藉著關聯的圖示化，讓需求被看得見，這一點對產品的早期，還在做雛型設計的作業上有著極大的貢獻。
結構
為什麼（Why）– >誰（Who）–>怎樣（How）– >什麼（What）
我們的目標是什麼（Why），為了達成目標需要哪些人（Who）去怎樣（How）影響，為此我們需要做什麼（What）。
影響對映通過構建產品和交付專案來產生實質影響，從而達到業務目標。
特徵
- 結構性：從業務目標到交付的結構化梳理和挖掘的方法，目標–角色–影響–產出物。
- 整體性：連線目標和具體交付物之間的樹狀邏輯圖譜。
- 協作性：利益相關人一起溝通討論協作，把隱藏在個人頭腦中的預設的思維邏輯挖掘出來共享。
- 動態性：動態調整、迭代演進、經驗證的學習。
- 視覺化：一個清晰的檢視，關聯性的結構一眼可以望穿、易讀。
它將各種角色以不同的視角，不同的思維邏輯，不同的前提假設，通過視覺化和協作的方式進行整理、說明，相關性再作連線，一下子就串起來了。通過連線交付內容、影響和目標，影響對映顯示了之所以去做某一個功能的因果關係，同時也可視化了各利益相關人所做出的假設。這些假設包括了：業務交付的目標，涉及目標關係人，及檢視畫所達到的影響。
同時，影響對映溝通了兩個層面的因果關係假設：
- 交付會帶來角色行為的變化，產生影響;
- 一旦影響達成，相關的角色會對整體目標產生貢獻。
案例
重要性
公司經常忙於構建解決方案，以至於他們忘記了最初試圖解決的問題。產品會隨著時間而變化，最終結果並不總是映射回原目標，這可能導致產品市場適合問題或膨脹的產品，其核心目的具有不必要的功能。
影響對映幫助產品團隊將所有內容映射回該目標，從而保持對計劃主要目標的關注。如果一項功能沒有從影響對映過程中產生，那麼它可能根本不需要在產品中。
這也是一個極好的工具，向其他利益相關者解釋為什麼某些功能被優先考慮，為什麼其他功能沒有。由於衝擊對映簡單且視覺化，因此易於消化。此外，它100%專注於目標實現， 這使得它很難爭論。
影響對映基於假設。公司假定特定型別的演員會對目標產生影響。因此，必須進行額外的驗證，以確認使用案例是否有效，並且優先順序是合理的。
但是，影響對映尤其善於排除某些與商定目標沒有直接聯絡的功能。
影響對映還可以在探索實現主要目標的各種方法方面發揮早期作用。通過探索所有潛在的參與者、影響和可交付產品，產品團隊可以視覺化許多不同的方式到達他們期望的目的地，然後研究和選擇最有可能成功的道路。
構建
為什麼？
我認為這是人類的傾向， 開始任何尋求解決方案的想法， 做什麼。軟體功能也會發生這種情況。我們的利益相關者來到我們身邊說，"給我們一個 UI，它做 X、Y 和 Z。他們經常想給我們實施，儘管他們僱用了我們，因為我們是知道如何開發軟體的人。
當客戶這樣做時，詢問他們以下問題非常重要："您為什麼想要此功能？您正在解決哪些業務問題？它將新增什麼價值？我們將如何衡量它是否成功後，我們釋放到生產？一旦我們理解了目的，我們就可以運用我們自己的技術和領域知識以及我們的創造力來想出最簡單的有效解決方案。
當涉及到改進我們開發軟體的方法，包括我們如何測試和編碼它時，同樣的技術也適用。抵制從交付物開始的衝動，問問自己，"為什麼我們在這裡開會？我們希望實現什麼目標？
在他的書中，Gojko建議用"SMART"的目標來回答"為什麼？這是一種久經考驗的技術，沒有什麼新鮮事，但我們多久記得讓我們的目標"具體、可衡量、以行動為導向、現實和及時"？（根據維基百科，這方面有幾個公認的變化）。對我來說，思考如何衡量成功是關鍵。重要的是要記住，一旦我們嘗試實施一條改進問題的道路，就要進行測量。
將每個目標寫在粘性便箋上，並將其放在團隊工作位置周圍的桌子或牆壁空間上。
下面是一個檢視"為什麼"問題的例子？我的團隊正在為一部特定的史詩提供使用者故事， 但大多數故事多次被拒絕。開發人員沒有得到故事的完整和正確的要求，所以有不斷的流失。我的傾向是說，"我們需要做ATDD，讓開發人員更好地瞭解這些要求。但這始於"什麼？最好設定一個目標，例如，"讓我們在未來兩個月內將被拒絕的故事數量減少 20%。一旦開始，此過程將產生許多改進目標。
誰？
建立影響圖的下一步是考慮誰將幫助我們實現我們的目標，誰可能會妨礙我們。團隊之外是否有人可以提供幫助？回到我的例子目標，減少被拒絕的故事的數量，也許我們需要縮短我們的反饋迴圈，讓我們的連續整合構建完成更快，但我們缺乏必要的硬體。我們可能需要首席財務官的批准才能為此編出預算。
想想那些你通常不合作的人。營銷人員可以為我們提供關於對客戶最重要的資訊，這可以幫助我們適當地預算我們的時間。客戶支援和運營也擁有對我們有價值的資訊。有時人們甚至不知道我們甚至需要幫助。我記得當我們的團隊想到有一個障礙積壓，我們把"慢測試環境"放在首位。我們的資料庫管理員 （DBA） 和我們的系統管理員甚至沒有意識到我們的問題，他們很快為我們找到並設定了新的、更快的伺服器。
Gojko建議填寫此模板：<某種>可以通過<以不同的方式做某事>來幫助我們實現我們的目標。使<某一>具體。想想誰在限制你的選擇。有人能阻止你開始的團隊嗎？
將每個"誰"寫在便箋上，並圍繞您的目標排列這些。這是您影響圖的第二級。
怎麼做？
對於您認定為幫助或障礙的每個"誰"，請指定每個人的行為應如何改變、他如何幫助實現目標，以及如何成為障礙。這些是預期的更改的影響，這些更改將幫助您的團隊實現目標。如果我們已經確定首席財務官是一個可以幫助我們的人，批准購買或投入資金，我們需要在預算的影響。從營銷或客戶支援中獲得幫助可能很簡單，例如安排會議或安排與他們配對。
您的影響圖將幫助您視覺化誰產生了影響，以及如何促成目標。您可能不會選擇與您識別的所有參與者合作，或讓他們完成所有影響，但地圖可幫助您檢視實現目標的所有替代路徑。這些為小實驗提供了逐步改善問題區域的基礎。
什麼？
在Gojko的影響圖中，第三層回答了這樣一個問題："作為一個組織或團隊，我們能做些什麼來支援所需的影響？當您使用影響圖來設計可能的軟體產品時，這些是可交付功能本身和組織活動。在影響圖上，每個可交付的都與它們應該支援的影響相上下文。
使用影響圖來幫助解決問題，我們的"交付"是一個小實驗，我們將努力實現的影響，這將有助於我們解決問題。如果我們希望首席財務官批准購買或預算變更，我們需要整理一下我們將提交給她的案例，讓她接受。以我為例，我們可能決定量化我們的"故事拒絕流失"產生的技術債務，因為資金與首席財務官交談！交付的課程可能是團隊學習如何使用特定的測試框架或預算時間與業務分析師協作以獲得更完整的要求的必要培訓課程。
在我自己的衝擊測繪實驗中，我發現"什麼？思考那些能夠幫助或阻礙我們的人，以及他們如何做到這一點，是創造性想法解決問題的真正火花。