案例幹貨|用友羅濤：打通產品開發的任督二脈
【精彩預告】用友集團開發管理部總經理羅濤將於5月21日在上海MPD工作坊進行《破解4小時上線傳說》的3小時分享。
通過一個故事引入互聯網+產品開發的叠代思路、價值發掘和發布規劃等核心思想和工具，將結組利用小圖團隊的力量使用影響地圖、用戶故事地圖、無代碼驗證等演練手段在3個小時的工作坊內快速發布一個產品，帶領學員在操作中理解精益和敏捷。
文章來源：公眾號 ：msup（ID：msupclub）關註回復“體驗工坊”有驚喜。
導讀：在面對需求的變化無常、人員的變動和技術的更新時，對客戶價值的識別尤其重要，這是產品成敗的關鍵。如何在產品研發過程中精準定位用戶價值，並針對用戶價值分析用戶場景、劃分場景叠代計劃，從而優化研發產品管理、研發項目管理、激發團隊戰鬥力、提升客戶滿意度，建立新的研發模式，不斷改進個體的溝通模式，啟發大家的思路，形成了團隊新的工作風格？
本案例從集團某行業研發中心產品研發團隊的實際情況出發，主要分享該團隊在產品需求、開發管理等方面，以及客戶價值的定位、場景的分析、叠代的規劃、方案的驗證等方面所做的創新，深度介紹新產品研發的POA、MVP、影響地圖和故事地圖的實際應用和具體效果。每個部分都會分享項目真實的體驗，希望讀者能從本中獲得啟發和靈感。
一、案例啟示
基於價值的產品發掘、定義、分析和交付是打造高績效團隊的前提和基礎。
價值是產品成敗的關鍵，做項目之前首先要確定能給客戶提供什麽價值；
快速驗證幫助產品實現客戶價值的最佳方法。
二、案例背景
一年以前，XX研發部剛和原來的部門分開，過去的一年半裏團隊沒有發布過任何版本、人員流動非常頻繁，這些原因導致整個團隊士氣低落。研發負責人和需求經理找到我，看能不能幫他們進行敏捷轉型。
我首先做團隊調研，發現相關方處於互相看不順眼的狀態：
客戶方典型沒有建立信任感。客戶常說“你做的東西根本不是我要的！”；“你不懂我啊！”，“要我等這麽長時間！”，“根本沒提供給我任何的價值呢！”；“要想上線，這個必須這麽改一下！”；“你們都是按照我說的在做，業務水平不如我，那就聽我的吧。”
產品團隊很痛苦。一方面被客戶逼，被客戶罵，一方面在開發面前，面對超出預期的交付周期，要面對“你說的這個需求到底是哪個客戶會這麽用？”；“你又不懂技術，這個沒法實現，必須換方案。”等類似的質疑和爭吵。
開發團隊更痛苦。天天996、007加班加點做出來的產品，產品團隊一句“這根本不是我要的”就退回了！說不清為什麽加這個功能，手頭工作還沒做完新的變更又來了。好不容易做完了，用戶不接受，說產品理解錯了…
以上問題造成產品需求與市場脫節，所做的產品客戶方不認，並且由於薪酬和發展等原因，核心人員流動很大，而市場又存在更多的需求需要去滿足。所以團隊有強烈的訴求通過引入新的研發過程來改變現狀，並希望能在年內推出新的產品在客戶處實施上線。
三、案例復現
3.1 策略與效果
圖1 打通產品研發的任督二脈
為了敏捷改進更好地落地，並且發揮敏捷的真正意義，我根據了解到的現狀和團隊進行了深入溝通，確定了“從加強產品管理入手，發掘真正的用戶價值，並快速研發產品，幫助用戶實現價值改進目標，從而利用產品來吸引客戶”的策略。我把準確發掘產品價值稱為任脈、快速研發產品稱為督脈，要想這個策略落地，必須打通產品研發的任督二脈（如圖1）。
經過近一年的叠代嘗試，目前團隊基本上打通了研發的任督二脈。打通後團隊的感覺主要有：
業務分析更為聚焦。整體構建後，大家全部聚焦在要完成的共同目標上，共同參與，為產品出力；與客戶的交流更為順利。使用客戶能聽明白的語言，客戶更容易理解，我們也更能控制產品發出的質量；
產品開發速度提升。產品開發的速度很快，每次的範圍小了，也更聚焦了，演示時客戶的參與度也更高，效果很好；
開發更有動力。每次與客戶交流後頗有成就感，客戶有期待，我們有動力，項目有進展。打通後團隊現狀是：
大團隊第一階段敏捷改進已結束,目前正在進行第二輪改進——小的特性團隊,端到端交付；各環節目標一致,幹勁十足；
把其他部門的團隊合入該部門一起管理。
3.2 案例復現
下面具體說說案例的實踐經過。
首先，我們需要在團隊建立產品的用戶思維，即所有的產品或服務要對用戶有用，也就是說一定是對用戶有價值的。基於這個出發點去判斷產品需求優先級。
另外，建議產品經理要對用戶思維辯證思考，用戶思維不是盲目跟隨用戶看他需要什麽我就做什麽，而是深入共情用戶，基於用戶的場景，給出用戶超預期的產品和服務。
3.2.1 需求優先級排列
之前團隊進行產品需求分析和優先級排序的方法基本上有以下幾種：
誰腿粗、嗓門大誰說了算：典型的管控型團隊，“職級高的”“會吵架的”“經驗老的”擁有話語權，這時候產品長啥樣就得聽領導的了，用戶，誰在意呢！
技術先進代替客戶需求：這是技術主導型團隊經常出的狀況，我們使用了最新最好的技術，用戶就應該買單。
以上兩種方法在語言上的典型表現是以“我認為”或“我想”開始發言，都是從自己出發，而不是從客戶價值出發的思路。
那麽該如何改進呢？
第一、引入用戶畫像（Persona），針對不同場景對用戶進行分類，給每類用戶建立用戶畫像（具體操作可參考相關書籍）。提醒一點：我們的用戶畫像是為特定場景服務的，所以不要脫離場景去制作它。
第二、制作用戶路徑圖。通過移情圖發現用戶實際的痛點和利益點，並基於此制作用戶路徑圖。用戶路徑圖是針對具體場景、根據不同職能描述各職能在不同時間在做什麽。到目前為止，我們都是在真實地描述用戶的業務實際場景，並沒有加入我們自己的主觀意識。
第三、繪制人性矩陣。我們分析用戶的行為中暗含的基本人性，研究用戶心理是喜歡還是厭惡這種感覺。針對不同的用戶心理，思考我們提供的產品或服務是否可以為用戶實現某種用戶價值。
到此，我們還是在研究用戶行為，因為要讓用戶習慣使用我們的產品和服務，第一步就是要發現他們在具體場景下的行為習慣，並研究這種行為背後的心理和人性，然後通過提供超預期的產品和服務，逐步改變他們在具體場景下的行為習慣。
第四、確定業務需求優先級。完成了這些之後，我們就要基於客戶價值確定業務需求的優先級。需要提醒的是：客戶的優先級有可能是出於政治方面的考慮，這在平時經常容易被忽略，但是在企業級市場這一點很可能最後決定成敗。所以，雖然有時我們覺得某些需求不是真正的業務需求，我們也得聽從業務代表或客戶的意見。
同時我們發現：如果項目不按照客戶的價值排優先級，我們很有可能無法識別關鍵的成功因素。因為產品需求從用戶中來，我們必須明確用戶到底需要什麽，然後把不同需求都列出來再確定優先級，這樣產品邏輯才會更清楚。
基於客戶價值進行優先級排序的常用方法主要有兩種：
● MoSCoW方法
● Kano方法
以敏捷計劃應用來說，敏捷團隊和客戶為開發協作選擇用戶故事，這些用戶故事必須進行優先級處理。優先級處理常以價值和風險為基礎，可運用MoSCoW 和Kano 方法和通過風險-價值、成本-價值指標執行。
要提醒的是，雖然在計劃期間用戶故事會做優先級處理，但敏捷團隊和客戶應以逐步完善（即增加知識和觀點）為基礎定期叠代審查優先級。
圖2 Kano方法
Kano方法把需求分為以下四類（如圖2所示）：
第一種 基礎需求，是最基本、必須有的需求；
第二種 期望需求，滿足這個需求用戶會覺得你的產品還可以；
第三種 興奮需求，這個很重要，它會讓用戶覺得你的產品太牛了，然後他們就會幫你傳播，幫你制造好口碑；
第四種 反向需求，這是用戶不想要的，也許你做了會掙到錢，但用戶可能會罵你怎麽搞這種東西出來。
基礎需求肯定要做。否則產品就不成立。你能想象買個手機不提供通話功能嗎？
期望需求盡量多做。期望需求的滿足會帶來用戶滿意度的線性增長，做得越多用戶數越多。
興奮需求最希望做。能夠提升品牌度和口碑的興奮需求投入較少，但帶來的價值是呈指數型增長的，所以產品要時刻發掘這種需求。
反向需求盡量不做。
另外，對於企業級應用來說：
用戶主路徑上的關鍵需求必須做，並且必須按場景做全。也就是說，你提供的應用或服務的整個路徑要跑得通，不能說采購下單了要付款的時候暢捷支付不能用、企業網銀也不能用，這就有問題，至少要滿足主流的支付方式。所以主場景路徑一定要先做，分支場景路徑可以到後面再做。
符合企業和項目目標的需求優先做。也就是立項時參照的企業目標是什麽。這個根據企業的情況而定，如果是要保證現金流和利潤，就滿足掙錢；如果是讓用戶體驗更好，就把用戶體驗放在第一位。這是團隊自己根據企業目標設定的，和企業願景、使命和戰略息息相關。
用戶覆蓋面廣的優先做。一般情況下參考2/8原則，有些功能可能只有20%的人在用，有些80%的人在用，這時候就優先做80%用戶需要的功能。但如果你的目的是戰略預研或樹立某種品牌形象，那就要考慮讓10%的願意嘗鮮的所謂內行和推銷員去做口碑推廣。
3.2.2 兩大神器——影響地圖、用戶故事地圖
下面介紹任督二脈打通的兩大神器：
● 影響地圖
● 用戶故事地圖
首先要明確產品設計的核心是什麽？
關註給用戶帶來的價值，而非實現難度
關註給用戶帶來的便利，而非商業模式
關註你可以為用戶做什麽，而非有多少競品
關註用戶邏輯，而非運營手段，運營不是目的
沒有脫離場景的用戶需求，所以在定義需求的時候一定要明確用戶的場景，以及用戶需要獲得的價值，如圖3。
圖3 用戶 場景
打通任脈--影響地圖
經過一個階段的教練，團隊就產品研發的目的達成共識：研發出好的產品，利用產品吸引用戶。團隊的所有活動都是圍繞為用戶創造價值而展開的。在團隊內推動敏捷改進，其目的是為了更快和更高效地提供用戶所需要的價值。
在產品分析階段能夠精準定位用戶價值是非常重要的。所以我為團隊引入了影響地圖這個神兵利器。通過學習得知：對產品開發價值本質的認知是基礎，只有把它們應用到實踐中才有意義。而“影響地圖”就是一個從產品開發本質出發的價值定義和價值發現的實踐。
影響地圖（圖4所示）指出：產品是為人服務的，必須通過影響人的行為才能實現目標。這也是“影響地圖”名稱的由來。為完成從目標到功能的映射，影響地圖要回答兩個問題：
對什麽人產生什麽樣的影響可以幫助目標的實現；
提供什麽樣的產品功能（或服務）才能產生這樣的影響。
圖4 影響地圖
這是一張模擬的影響地圖，其邏輯結構如圖5：
圖5 影響地圖邏輯結構
從這張地圖可以看出，目標、角色、影響都是從使用者的角度來進行定義的，而功能則是從系統提供者的角度來進行定義的。這樣就在用戶價值和系統功能之間進行了映射，明確了用戶價值的實現依賴，並為開發實現功能給出了明確的價值定義，確保了團隊對用戶價值和功能的一致認可，避免了溝通上的浪費。
我和團隊一起開發了很多套影響地圖，因為每個幹系人都有多個價值訴求，而其中很多都是我們系統的直接幹系人，所以必須分析每一個價值，並繪制影響地圖。如圖6所示：
圖6： 團隊繪制影響地圖局部
要註意的是影響地圖不應該專屬於某個職能，也不應該是某一時刻的靜態規劃。開發過程中，團隊持續交付功能、獲得反饋及其它信息輸入，深化對產品的認知。隨著認知的深化，影響地圖不斷地被修正、拓展。這一過程需要各個職能共同參與，影響地圖是管理人員、業務人員、開發和測試人員共享的完整圖景。
對於業務人員，他們不再是簡單地把需求列表扔給開發團隊，並等著最後的結果。通過影響地圖，業務人員和開發人員一同完成從目標到產品功能的映射，明確其中的假設，並在叠代交付中驗證這些假設，當假設被證明或否定後，應該對影響地圖做出調整，如繼續加強或停止在某個方向上的投入，或調整投入的方式。
對於開發人員，他們的目標不再限定於交付功能，而是拓展至交付業務目標。開發者除了知道交付什麽功能，也了解為誰開發、為什麽要開發。這樣就可以更加主動和創新地思考，有依據地做出決策和調整。
對於測試人員，除了參與上面的規劃和驗證活動外，測試的責任不再局限於檢查產品是否符合預定的功能，而是驗證產品是否產生了預期的影響。如果沒有對用戶產生期望的影響，即便完美符合功能定義，也不是高質量的產品。
通過使用影響地圖，團隊取得了如下效果：
開發團隊共同確認需要提供的用戶價值，有了共同的願景；
統一了做事情的目的和原因；
厘清了客戶業務和我們提供功能之間的差異和聯系；
更高效地溝通；
沒有了過去“抱大腿”“純技術”的現象。
在這個過程中，可以同步和用戶確認所需功能的價值體現，減少了團隊在開發過程中的路徑偏差。
打通督脈—用戶故事地圖
做到這一步，我們擁有了體現用戶價值的用戶故事列表(ProductBacklog)，但還是以傳統的條目化模塊化列表呈現，團隊在開發時還是不能盡快交付用戶價值。這時團隊的狀況是：
傳統的條目化模塊化列表
無法明確用戶場景
無法進行全景規劃和討論
需求無場景，討論起來太復雜，非常費時
具體來說，當我帶領團隊完成影響地圖之後，在使用敏捷開發的具體方法開展開發活動時，發現了一個問題：在2C的軟件開發中使用用戶故事基本沒有問題，因為這些軟件通常流程都不長，沒有復雜的業務依賴和流程邏輯。而企業級應用流程通常較長，涉及多個角色和更多的環節，只使用用戶故事會出現只見樹木不見森林的問題，不能很好地確保backlog覆蓋了最重要的用戶體驗路徑，並且不能很好地按照場景進行優先級規劃。
這就不得不說說用戶故事的問題了，根據相關書籍資料，主要如下：
只見樹木不見森林，重要的待辦項容易淹沒在各種細節中看不到全貌，因而難以排列優先；
不能方便地了解系統提供功能的完整性；
不能方便地了解系統提供的工作流以及價值流；
不能方便地利用遞增和叠代的方式確定發布計劃以及發布目標。
也就是說，用用戶故事在我們開始進行產品或項目規劃的時候，首先需要梳理出一個backlog，在其中按照優先級列出要實現的場景和具體功能。這時我們遇到的問題是：如何確保backlog覆蓋了最重要的用戶體驗路徑？是否我們當前所規劃的場景確實可以為用戶提供價值？這些問題單純使用用戶故事不能很好地得到解決。
所以必須要打通督脈，我采用的工具是用戶故事地圖。用戶故事地圖聚焦於需求梳理階段，幫助我們解決這些問題。
為了讓團隊更好地使用這個工具，我增加了場景說明並且將用戶活動定位為用戶的業務活動，而將task定位為系統提供的功能，根據具體場景將在場景中的用戶需求用對應於task的用戶故事來表現。發布可以包含多個場景，但一個場景不能被分到多個發布。如圖7所示。
圖7 用戶故事地圖
我們規劃發布時要先進行場景的優先級排序，用戶故事的優先級由所屬場景決定，當我們規劃叠代時，場景及其故事會被整個放入叠代，而不能單獨放入。
我們進行一段時間的試驗，獲得的改進效果如下：
按照場景進行需求闡述，統一了團隊語言，提高了研發效率；
場景化的優先級排序，交付客戶更有價值；
多層次計劃，有了高層次視圖；
開發、咨詢、實施有了統一的表現形式；
每次開發叠代都能提供有價值的產品，提供了團隊自信度、動力和效率；
提高了客戶滿意度。
周天循環方法-快速驗證
使用用戶故事地圖解決了場景規劃和叠代規劃問題，但是在具體的實現方案上，還存在如下問題：
同一場景不同角色會有不同的解決方案，大家開會討論，誰也不服誰，變成了吵架大會；
用戶對產品不滿意；
Sponsor也不滿意。
這時團隊已經有了很好的敏捷思維，為了提升發布質量、避免不必要的浪費，我們引入了進行周天循環的方法-快速驗證，即無代碼客戶驗證。該方法指在需求分析階段，根據發布計劃、需求和設計，將下一發布需要做的場景使用線框圖進行繪制，如果可能，將核心功能制作成紙板模型，帶著這些模型，在發布計劃開始之前和客戶進行面對面的確認和溝通，確保我們所做的設計是符合或超過用戶需求的，如圖8所示。
通過這種方式加快了用戶反饋的頻率，提升了客戶滿意度，降低了需求變更數，提升了生產率和產品質量。同時，當產品需求和產品開發意見不一致時，雙方各自按照自己的設想，制作線框圖原型，拿到客戶和相關幹系人處進行PK，以確定最符合客戶預期的方案，增強了產品和開發的理解，化解了雙方的對立，強化了溝通交流的效率。
圖8 某項目線框圖原型
通過這次改進，我們取得了如下效果：
快速編制原型，快速和客戶確認；
開發和產品各自出方案，以客戶價值和客戶認可為依據；
快速開發；
促進對客戶價值和客戶體驗的深度挖掘和實現；
促進了人員技術和業務能力的提升。
關於MPD
MPD是Make Professional Discovery的縮寫，MPD工作坊是一個圍繞崗位角色發展的實踐課堂，是由全球軟件、互聯網企業教練、一線研發團隊帶頭人聯合開發的角色勝任能力模型，是一種持續實踐、創新驅動的團隊管理提升培養項目。
MPD工作坊按照軟件研發中心的崗位職能劃分，以產品經理、團隊經理、 架構師、開發經理、測試經理作為五個分會場命名，以促進角色的共鳴思考、深度探討、相互交流。
案例幹貨|用友羅濤：打通產品開發的任督二脈