有的產品,它還活着,它已經死了;有的產品,還沒發佈,就已經死了。
太多的產品失敗的案例,源於方向性錯誤,基於錯誤的假設,功能與業務目標/價值之間缺少必然的關聯與一致性,在作的事與指望的目標南轅北轍。
影響地圖試圖經過結構化、可視化、協做化的方式來從源頭解決上述問題。segmentfault
週六參加了 王立傑@Agile1001 組織的影響地圖工做坊,學習體驗了一把,這兩天又仔細研讀了GOJKO ADZIC的《影響地圖》一書,書摘、Workshop體驗以及本身的一些思考分享出來,歡迎一塊兒探討。app
影響地圖是一門戰略規劃技術,經過清晰的溝通假設,幫助團隊根據整體業務目標調整其活動,以及作出更好的里程碑決策,影響地圖能夠幫助組織避免在構建產品和交付項目的過程當中迷失方向。確保全部參與交付的人對目標、指望影響和關鍵假設理解一致。學習
同時,影響地圖能夠有效的評估交付,做爲質量反饋的標準之一:若是一個需求沒有有效的支持指望的行爲影響,那麼即便在技術上正確,功能交付給用戶了,也仍然是失敗的。spa
影響地圖試圖去解決組織面臨的範圍蔓延、過分工程、缺少總體視圖、開發團隊和業務目標不能保持一致等困擾。設計
簡單的講,影響地圖是這樣的一個思惟邏輯和組織結構:爲何(Why)-->誰(Who)-->怎樣(How)-->什麼(What)排序
也就是:咱們的目標是什麼(Why),爲了達成目標須要哪些人(Who)去怎樣(How)影響,爲此咱們須要作什麼(What)。影響地圖經過構建產品和交付項目來產生實質影響,從而達到業務目標。ci
回答:咱們爲何作這些?也就是咱們要試圖達成的目標。項目管理
找到正確的問題,要比找到好的回答困可貴多。把本來描寫在文檔中,更多的是隱藏在高層利益干係人頭腦中的業務目標,定性定量的引導出來。目標描述要遵循SMART原則:Specific明確,Measurable可度量,Action-Oriented面向行動,Realisitc現實的,Timely有時限的。確保每一個人知道作事的目的是什麼,幫助團隊協做,針對真正/合適的需求設計更好的方案。開發
回答:誰能產生須要的效果?誰會阻礙它?誰是產品的消費者或用戶?誰會被它影響?也就是那些會影響結果的角色。文檔
考慮涉及到的這些決策者、用戶羣和生態系統,注意角色一樣有優先級,優先考慮最重要的角色。
角色定義應該明確,避免泛化,能夠參考用戶畫像Persona的方式進行定義。
回答:考慮角色行爲如何幫助或妨礙咱們達成目標?咱們指望見到的影響。
只列出對接近目標有幫助的影響,而不是試圖列出全部角色想達成的事。影響是角色的活動,是業務活動而不是產品功能。理想狀況下應展示角色行爲的變化,而不只僅是行爲自己。
不一樣的角色可能有不一樣的方法,幫助或阻礙業務目標的實現,這些影響彼此之間多是相互參考,相互補充,相互競爭,或者相互衝突的。既要考慮到正面的影響,也要考慮負面或阻礙的影響。
注意:業務發起方應該針對角色Who以及影響How,而不是交付內容What進行優先級排序。
回答:做爲組織或交付團隊,咱們能夠作什麼來支持影響的實現?包含:交付內容,軟件功能以及組織的活動。
理論上這裏是最不重要的一個層次,避免試圖一開始就將它完整列數,而應該在迭代過程當中逐步完善。同時注意,不是全部列出來的東西都是須要交付的,它們只是有優先級的交付選擇。
「永遠不要試圖實現整個地圖,而是要在地圖上找到到達目標的最短路徑。」
影響地圖足夠簡單,操做性強,又有足夠的收益:可以幫助建立更好的計劃和里程碑規劃,確保交付和業務目標一致,並更好的適應變化。影響地圖的首要任務是展現相互的關聯,次要任務是幫助發現替代線路。
正如做者所言:影響地圖符合軟件產品管理和發佈計劃的發展趨勢——包括面向目標的需求工程、頻繁的迭代交付、敏捷和精益軟件方法、精益創業產品開發循環,以及設計思惟。若是你認同上述趨勢,那麼影響地圖會是你的菜。
它將各個部門/角色不一樣的視角,不一樣的思惟邏輯,不一樣的前提假設,經過可視化和協做的方式進行梳理、澄清和導出。經過鏈接交付內容、影響和目標,影響地圖顯示了之因此去作某個功能的因果鏈,同時也可視化了各利益相關人作出的假設。這些假設包括:業務交付的目標,涉及目標干係人,視圖達到的影響。
同時,影響地圖溝通了兩個層面的因果關係假設:
是否能夠將影響地圖分層?
我認爲徹底能夠並且合理。《影響地圖》也提到建議計劃兩次會議:第一次定義預期的業務目標和度量;第二次來製做一張地圖。第一步就是肯定使命,而一個戰略目 標每每太大,沒法快速見效,須要拆分紅可短時間達成的戰術目標,根據優先級排序的戰術目標,逐次進行影響地圖分析,期間動態調整更新,按期決定是否須要繼續。
所以能夠有兩層的影響地圖:「一份針對總體產品願景,一份針對中期交付。」
同時,經過分層,也能夠有效的控制參與兩個會議的人員組成。高階的領導者未必須要參加全部的影響地圖活動,尤爲是戰術影響地圖會議。
Decision Maker,注意必定要有決策者參與,包括:商業決策、技術決策、營銷決策(原書中爲高級技術和業務人員)。若是發現一個問題討論好久沒有決定,也許是由於缺少合適的參與人員,應該找更高階的人員決策。
參與人數:原書的建議是將第一次會議人數限制在不超過5-6人,確保關鍵的業務決策者和技術人員參與進來。隨後的會議能夠適當擴大規模分組討論,隨後彙總,但人數越多,會議的節奏和範圍就越須要控制。
影響地圖的輸出物,能夠做爲用戶故事的輸入,做爲Epic、UserStory的來源。這些輸入已經通過了價值判斷,角色挖掘,優先級排序,甚至已經有了一 部分的驗收標準(是否影響了受衆同時爲達成目標做出貢獻),同時也由於有資深技術人員的參與,初步作過技術可行性判斷。所以這些backlog的輸入,往 往更加靠譜,對交付團隊更具價值。
《影響地圖》書中有明確的描述,把三段式的用戶故事與影響地圖幾個層級進行mapping:做爲一個Who,我但願What,以便於How。
看似動態調整的故事列表,根據精益消除浪費的思想,維護完整的故事列表,事實上也是浪費。存在的問題有兩點:
業務目標能夠與迭代的發佈計劃關聯,每次迭代只處理少許的目標;《影響地圖》建議一次 只處理一個目標,目的在於快速反饋和調整;我的認爲基於團隊規模、迭代步速,一次迭代能夠包含幾個目標決定於目標的顆粒度以及時間估算,不可一律而論。當 然在具體執行時,這裏會是一個爭論以及變數較多的點。
實戰練習中,咱們40多人分紅6組,分別繪製本身的影響地圖;實際場景中,若是每組都基於同一個目標,繪製出來的地圖會各具特點而發散,最終須要引導將發散的地圖進行收斂,在此過程當中,會發現更好的實現或是新的假設導出,最終獲得成型的影響地圖。
分層和分拆時,掌握80/20原則,不求面面俱到,只須要涉及最關鍵重要的因素。考慮到大部分團隊會使用物理板+即時貼的方式進行影響地圖的設計,我的以 爲,本來由於物理空間受限以及可讀性緣由存在的物理白板的弊端,反而能夠做爲細化程度的一個有效限制原則(正如著名的兩個披薩原則):以物理牆/白板爲影 響地圖的最大邊界。
相對於咱們一般關心的業務功能/營銷活動,即影響地圖的第四層What,咱們更應該把把注意力放 在前三層目標、角色和影響上,尤爲是角色和影響上,關注點如此,優先級排序也是如此;先不要關注在What即本身要作什麼事情上,這每每會讓咱們陷入執行 的細節,埋頭作事,而忽略了事情的初衷。
首先要避免過早陷 入過多的細節,將來一切都是未知的,全部的都是基於當前的假設,因此維護一份完整的地圖,試圖將全部想法都概括在地圖上,是不必的。其次,目標導向,避 免在那些對總體目標沒有做用的影響上花費過多的時間。整理出來的路徑,固然能夠保留下來,做爲下一次影響地圖的部分輸入。
此外,須要注意的是,What包含交付內容、軟件功能和組織的活動,若是交付的全部條目都是技術性,也許要從新審視影響地圖,尤爲是角色Who與影響How兩部分,並不是全部的目標都是須要經過產品功能達成,更多狀況下,也許一個簡單的營銷活動就能夠快速實現目標。
「當關鍵想法已經出如今地圖上」,當已經達成目標,而且肯定最快/小路徑,暫時也想不出更好的替代方案時,就能夠結束。建議設定嚴格 的timebox,一旦出現時間點超時,或者是團隊陷入太過細節的討論,或是沒有找對合適的人,缺少合適的決策者,也許是業務決策者,也許是技術決策者。
如同計劃,在制定出來的那一刻也許影響地圖就已經失效,所以須要適時調整(注意是適時,未必是實時)。影響地圖更像是迭代計劃,每一個影響達成,進行反饋評估,對影響地圖的內容以及優先級進行調整;一旦目標達成,也許這張影響地圖就完成了使命。
我的認爲影響地圖的思惟方法和邏輯結構是廣泛適用的,所以能夠應用到不少領域,諸如旅行,健身,減肥,教育,學習計劃, 戰略目標,營銷戰略,銷售計劃等;但實際執行的過程未必要完整的按四個階段進行。
始終牢記作事的初衷是達成業務目標,而不是實現功能,甚至不是達成影響(若是影響最終不能幫助實現目標);
不要試圖一次完成好幾件事,而應該分拆成多個里程碑,多張地圖;不要試圖一件事作完美,指望把全部列出來的事情都完成是不現實且不必的;掌握80/20原則,達成目標便可,業務環境始終在變,業務關注點也會隨之變化;
不偏不倚,不驕不躁,邊走邊學邊調整,對目標和將來抱着一顆坦誠、恭敬與探索的心,不否認、不自大、不盲從。
懷疑一切,多問幾個爲何;把假設引導出來,經過分析和實踐來驗證假設;
一切以實用出發,價值導向,目標導向,結果導向,保持簡潔。
來源:AgileRunner
做者:IDCF導師 冬哥
6月每週四晚8點,【冬哥有話說】開心一「夏」。公衆號留言「開心」可獲取地址