不懂需求分析的開發(fā)不是好開發(fā)。上周經(jīng)過一周的緊張準備，在周五做了一次關(guān)于需求全景及用戶故事地圖的分享潜支；期間柿汛，快速閱讀了Jeff的《用戶故事地圖》。把上周學到的和分享的內(nèi)容總結(jié)如本文络断。
需求全景
首先需求全景，從字面意思理解弱判，就是指對需求的完整認識锥惋，也是項目中經(jīng)常提到的whole picture。打個比方遭商，買房子的時候我們在售樓部看到的沙盤捅伤，就是那種高空俯瞰全景的感覺。
什么是用戶故事地圖
那么用戶故事地圖就是幫我們構(gòu)建需求全景地圖的工具丛忆。隨著敏捷軟件開發(fā)的興起蘸际，它帶來了很多積極的影響，比如人們開始認同粮彤，大型需求是可以拆分為一個個小的用戶故事的姜骡。但是需求拆分也帶來了相應(yīng)的負面影響屿良，那就是容易造成只見樹木不見森林尘惧，丟掉需求全景的理解。用戶故事地圖就是一種在需求拆分過程中仍然保持需求全景圖的一種方法喷橙。
那么什么是用戶故事地圖呢？它是一個有方向的圖表悬荣，以時間線為橫軸疙剑，以優(yōu)先級為縱軸，然后會涵蓋所有的用戶故事嚼蚀，表達需求全景管挟。用戶故事地圖長這樣：
上圖中標出了時間線作為橫軸，優(yōu)先級為縱軸拳芙，里面是全量的用戶故事皮璧。我們用卡片表示用戶故事，同時我們看到這里有不同的顏色表示不同層級的用戶故事：其中上面是主干部分（橙色和藍色）睹限，下面是細分需求的用戶故事（黃色）讯檐。
通常我們在創(chuàng)建用戶故事地圖的時候，首先從用戶角度來講用戶故事别洪，一邊講一邊把其中的重要步驟記錄在便簽紙上，從左到右排列痒钝，這個過程的產(chǎn)出就是圖中的主干部分，這個過程中我們需要注意的幾個原則蚕甥，第一是力求把故事講完整栋荸，第二是堅持廣度優(yōu)先，不過度涉及細節(jié)晌块。故事講完之后我們就有了主干部分匆背，這個時候是一種只見森林不見樹木的狀態(tài)。接下來第二步我們就回過頭來討論每個步驟的細節(jié)靠汁，這個過程中我們會進行頭腦風暴闽铐，期間會通過一些問題啟發(fā)思考兄墅，比如用戶在這一步具體會做些什么，怎樣讓用戶在這一步獲得更好的體驗隙咸，如果出現(xiàn)問題該怎么處理，然后把這些細節(jié)在每個步驟下面垂直排列藏否。這樣我們就形成了圖上這種網(wǎng)格結(jié)構(gòu)充包，并且達到一種又見森林又見樹木的狀態(tài)。
同時我們可以看到淆储，用戶故事地圖上還有藍色的彩帶家浇，它表示三次發(fā)布計劃。也就是說當我們完成了需求細分之后点额，我們需要進行第三步，通過充分的討論對細分需求咖楣，也就是用戶故事排列優(yōu)先級。并且基于優(yōu)先級娃肿，制定發(fā)布計劃珠十。這里我們就需要提到MVP的概念。MVP晒杈，Minimum Viable Product就是最小化可用產(chǎn)品孔厉，這個概念源于精益，他的目的是用最小的投入發(fā)布對用戶有價值的產(chǎn)品粪般，來幫助我們快速獲得反饋污桦，快速試錯，并且不斷迭代找到產(chǎn)品的正確方向小作。針對MVP可以舉個例子稼钩，比如產(chǎn)品需要登錄功能，那么MVP1我們可以只上線最簡單的用戶名密碼登錄础拨。然后在后續(xù)MVP實現(xiàn)手機驗證碼登陸诡宗；然后再后續(xù)的MVP中實現(xiàn)其他比如微信掃碼登錄等等击儡。
最后我們用一句話概括用戶故事地圖：用戶故事地圖是一種識別需求和梳理需求的工具，同時能幫我們建立需求全景圖阳谍。
通常在項目的起始階段也就是inception階段，我們的產(chǎn)品經(jīng)理鸽疾，BA，Tech lead連同客戶會一起梳理需求并達成共識冒窍，這個過程使用的工具和產(chǎn)出就是用戶故事地圖豺鼻；那么當項目進入交付階段，我們會把用戶故事地圖帶到交付團隊谬莹，以用戶故事地圖為載體桩了，幫助交付團隊理解需求。用戶故事地圖也是一個很好的溝通平臺士葫，比如項目交付中間送悔，客戶那邊的stakeholder來了爪模，我們可以很方便的展示我們的當前進度，完成了哪些部分洁段，還剩下哪些部分共郭，等等。
用戶故事地圖的簡單示例
這是一個非常簡單的取錢的場景写半。首先我們以時間順序列出取錢需要經(jīng)過的步驟：開車去銀行尉咕，使用ATM，查看賬戶悔捶，取錢，拿到交易憑條犁柜，開車去high堂淡。或者還有另一種場景股囊，查看賬戶之后發(fā)現(xiàn)自己太窮了更啄，于是取消交易，開車回家祭务。這就是我們說的廣度遍歷义锥，從用戶角度講出一個完整的故事。
第二步拌倍，我們對以上步驟進行細分，比如查看賬戶的時候数初，分為幾種情況：查看活期賬戶梗顺；查看定期賬戶和查看交易記錄。其中每一個都是一個用戶故事仑鸥，并且按照必要程度自上而下排序变屁。同時再比如取錢，也細分為：用戶能夠有取現(xiàn)金的選項泵琳；用戶能夠有默認金額選項從而改善用戶使用體驗；用戶能夠有無卡取現(xiàn)選項谷市。
在完成第二步的拆分并且劃定優(yōu)先級后击孩，我們可以識別出第一次上線，也就是第一個MVP：包括兩個用戶故事创泄，用戶能夠看到活期余額及用戶有取現(xiàn)選項括蝠，這就是一個基礎(chǔ)款的實現(xiàn)。那么后面第二次可以是支持用戶更開心更便捷的取錢搁拙；第三次是支持用戶無卡取錢法绵。需要提及的是，整個過程無論是第一步講用戶故事盐茎；第二步細分需求徙赢；第三步排列優(yōu)先級并制定發(fā)布計劃，都是可協(xié)商的過程募谎，沒有標準答案阴汇。
構(gòu)建用戶故事地圖的練習
講解的時候穿插了一個構(gòu)建用戶故事地圖的練習节槐。題目來源于《用戶故事地圖》這本書，對上班過程（起床為起點哥倔，到公司為終點）進行需求梳理和拆分揍庄，并劃分MVP。
練習沒有標準答案沃测，練習過程中首先梳理骨干故事：回想一下起床的過程，分為幾個階段：比如起床馏谨，洗漱附迷，穿衣，出門喊儡，上班途中稻据，到達公司。如果任務(wù)太多攀甚，可以通過摘要行的任務(wù)來描述一堆任務(wù)秋度，即引入任務(wù)層級，當我們提取用戶故事的主干時埠居，建議用一個不同顏色的便簽紙事期，來涵蓋下方任務(wù)卡所要表達的意思，即使手邊沒有不同顏色當便簽紙绎橘，也可以把便簽紙旋轉(zhuǎn)45度變成菱形從而讓故事層級更加清晰唠倦。使用便簽紙而不是直接用筆寫在白板上，是因為便簽紙可以更方便的移動（體現(xiàn)優(yōu)先級冈止，順序等）候齿，討論闺属。
第二步需求拆分過程中周霉，需要進行頭腦風暴诗眨，期間我們可以用問題啟發(fā)他人：想一想你今天早上做了什么？是不是還有一些不太順利的早晨匠楚，停水了芋簿，沒有熱水了，忘帶手機了与斤，沒有擠上地鐵撩穿。再想一想完美的早上是什么樣的？頭腦風暴的過程是一個充分發(fā)散的過程雾狈，這個過程中我們并不需要篩選抵皱，想到的都可以列出來，為了充分發(fā)揮大家的創(chuàng)造性移盆，這是一個不會否定他人的階段伤为。同時頭腦風暴應(yīng)該首先關(guān)注于主要場景，然后才是次要場景叙甸，什么是主要場景爽醋，比如對于一個創(chuàng)建試題的步驟便脊，創(chuàng)建試題是主要場景，而編輯試題和刪除試題是次要場景遂赠。
第三步，對細分需求進行討論并排列優(yōu)先級和必要性筷弦。經(jīng)過步驟二的頭腦風暴抑诸，我們得出的用戶故事是豐滿的蜕乡，甚至近乎臃腫，那么此時我們會經(jīng)過討論來進行收斂号醉。同時完成了優(yōu)先級排序辛块，我們就可以制定發(fā)布計劃，比如mvp1就是我們要遲到了线椰，需要幾分鐘內(nèi)出門授药，我們就拉一條彩帶或者畫一條彩線，把這種情況下不需要的任務(wù)都轉(zhuǎn)移到彩帶下方莱衩。然后會有其他目標娇澎，比如過一個豪華的早晨；兩周長假出行前的早晨括细。
就像前面說過的戚啥，構(gòu)建用戶故事地圖的過程沒有標準答案，有的人可能會列出更多細節(jié)览濒，比如做早餐會寫成熱面包片和熱牛奶。有一個來自《用戶故事地圖》的比喻应又，用戶任務(wù)就像石頭乏苦，如果用錘子敲打汇荐，他就會變成小石子。
練習過程中其實會有一些尷尬的點奖磁，每個人的任務(wù)可能不一樣，有的人起床要化妝繁疤，有的人起床要鍛煉咖为，有的人起床要照顧小朋友，或者遛狗稠腊。這里也就引出了用戶畫像的概念躁染，用戶畫像就是我們針對不同場景對用戶分類，給每類用戶建立用戶畫像架忌。使用用戶畫像非常大的優(yōu)點是建立同理心吞彤，當你建立起用戶畫像的時候，就會產(chǎn)生代入感叹放，站在用戶的角度思考問題饰恕。用戶故事地圖本身期待用戶加入一同梳理需求井仰，也就是所謂的參與性設(shè)計埋嵌，與之相對的經(jīng)驗性設(shè)計則著重于前期的客戶調(diào)研，然后設(shè)計師以一己之力完成產(chǎn)品設(shè)計俱恶。在刻畫用戶形象時雹嗦，我們需要討論哪些客戶會使用我們的產(chǎn)品，為我們的產(chǎn)品付錢合是，羅列各種用戶了罪，討論他們的使用方式，思考他們需要哪些功能聪全。?
再次歸納構(gòu)建用戶故事地圖的步驟：
通常泊藕，我們拿到一個項目時，他的需求文檔是這樣的：
那么同樣的需求我們希望翻譯為用戶視角：
有了用戶視角的需求文檔难礼，我們就開始試著構(gòu)建用戶故事地圖：
第一步娃圆，梳理應(yīng)用的骨干業(yè)務(wù)流程
出題人出題汽久，然后老師布置作業(yè)，然后學生答題踊餐，然后老師批改，最后學生查看成績臀稚，這就是完整的用戶故事吝岭，這里我們有不同的用戶角色。
第二步吧寺，準備好核心用戶的用戶旅程（user journey）
比如出題人出題時首先需要創(chuàng)建題目窜管，然后創(chuàng)建試卷，然后把題目和試卷關(guān)聯(lián)起來稚机。同樣老師布置作業(yè)的時候幕帆，首先創(chuàng)建作業(yè)，然后關(guān)聯(lián)作業(yè)和試卷赖条，然后選擇布置作業(yè)的班級失乾。那么學生答案的過程包括首先查看作業(yè)，然后答題纬乍，最后提交答案碱茁。老師改卷的時候需要首先查看學生提交的試卷，然后批改仿贬，最后發(fā)布成績纽竣。之后學生就可以查看成績。
第三步茧泪，從核心場景出發(fā)蜓氨，頭腦風暴支撐每個用戶任務(wù)的功能需求
比如針對出題人創(chuàng)建題目的用戶任務(wù)，其核心場景就是創(chuàng)建題目队伟。
第四步穴吹，針對其他次要場景，頭腦風暴支撐每個用戶任務(wù)的功能需求
次要場景比如上圖的編輯題目和刪除題目缰泡，所謂次要場景刀荒，指的是即使沒有這兩個功能系統(tǒng)仍然可用，比如我在第一次上線的時候不包括這兩個場景棘钞，那么產(chǎn)品仍然可用缠借，用戶可以暫且通過后臺編輯和刪除題目。
第五步宜猜，頭腦風暴每個功能需求的支撐性需求
紫色的部分就是支撐性需求泼返，相對于功能性需求，也成為非功能性需求姨拥。支撐性需求指的是一些技術(shù)故事绅喉，比如郵件服務(wù)器的集成渠鸽。那么之所以把這些支撐性需求在用戶故事地圖列出來，是為了tech lead和開發(fā)團隊可以針對性對這些需求提前進行技術(shù)預(yù)研或者實現(xiàn)柴罐，那么當我們的功能性需求涉及到比如和郵件服務(wù)器的集成徽缚，就可以直接引用預(yù)研結(jié)果。保證我們的交付進度革屠。這些支撐性需求往往由Tech lead和BA一起列出來凿试。這也是為什么不僅產(chǎn)品經(jīng)理和BA（Business Analyst）需要學習用戶故事地圖，開發(fā)與測試人員同樣需要的原因似芝，因為有一天你也會成為Tech lead呀Ｄ峭瘛：）
以上就是用戶故事地圖的內(nèi)容總結(jié)了，最后強烈推薦《用戶故事地圖》一書党瓮，作者就是用戶故事地圖這一工具的提出者详炬，本書從作者親身經(jīng)歷出發(fā)，講述用戶故事地圖是如何讓需要梳理更加清晰寞奸，如何拯救項目于混亂的需求的呛谜，同時語言輕快，閱讀愉快枪萄！
