用user story來代替prd焦辅，不僅清晰直觀宪摧，還能提升團(tuán)隊(duì)的溝通效率台腥；玉米大人分享一些寫故事和切故事的方法及注意事項(xiàng)烫止。

我跟用戶故事的淵源

記得13年初有參加過敏捷咨詢師Daniel Teng一個(gè)工作坊，導(dǎo)師給我們布置的任務(wù)就是每組從自己日常生活的痛點(diǎn)出發(fā)疾棵，自由發(fā)散的去想一個(gè)創(chuàng)意點(diǎn)盗飒；之后團(tuán)隊(duì)成員自己分角色扮演不同的用戶類型，上去講故事陋桂；然后從故事里抽離出產(chǎn)品需求，根據(jù)需求在卡片上畫低保真的原型蝶溶；每個(gè)團(tuán)隊(duì)依次把原型卡片貼在白板上嗜历，按用戶體驗(yàn)流程去講宣渗；最后大家投票評(píng)選出公認(rèn)的價(jià)值點(diǎn)高的產(chǎn)品。

當(dāng)時(shí)只覺得整個(gè)過程很有趣梨州，并沒有真正放在心上痕囱。我真正開始寫用戶故事，是在去年使用快速迭代的開發(fā)方式后暴匠，每次完成幾個(gè)獨(dú)立的用戶故事鞍恢，快速上線給用戶驗(yàn)證，及時(shí)發(fā)現(xiàn)問題每窖，快速調(diào)整帮掉。使用下來不僅不用寫長長的prd文檔了，團(tuán)隊(duì)溝通效率更高了窒典，用戶和公司高層都能更快的看到我們的產(chǎn)品的更新迭代蟆炊。

論講故事的重要性

什么是用戶故事？

用戶故事（user story）是從敏捷開發(fā)scrum中提出來的瀑志。是從用戶的角度來描述用戶渴望得到的功能涩搓，它是一個(gè)獨(dú)立完整的、可直接上線交付的劈猪、有一定業(yè)務(wù)價(jià)值的最小粒度的產(chǎn)品昧甘。

舉個(gè)微信的栗子：

微信1.0上線了樓層式的單人會(huì)話，用戶可以在手機(jī)上給好友發(fā)送文字和照片战得，以實(shí)現(xiàn)在手機(jī)端即時(shí)免費(fèi)聊天的目的充边。1.2版本上線了多人會(huì)話，用戶可以在手機(jī)上發(fā)起一個(gè)群聊贡避，并邀請(qǐng)相關(guān)好友入群痛黎，以實(shí)現(xiàn)在手機(jī)上展開小群組的討論的目的。這2種會(huì)話方式 是針對(duì)同類用戶的不同場(chǎng)景刮吧，每個(gè)故事都是相對(duì)獨(dú)立的湖饱，又給用戶完整的體驗(yàn)，當(dāng)然業(yè)務(wù)價(jià)值也是顯而易見的杀捻。

用戶故事的價(jià)值體現(xiàn)：

告別prd井厌，通過講故事來提升團(tuán)隊(duì)效率

早些年我們寫需求文檔，前面幾頁都是標(biāo)準(zhǔn)的模板致讥，關(guān)于項(xiàng)目背景仅仆、目標(biāo)、風(fēng)險(xiǎn)等的描述垢袱。但現(xiàn)實(shí)中開發(fā)要么不看文檔墓拜，要么打開導(dǎo)航，直接跳著找跟自己相關(guān)的请契，漂一眼界面原型圖和大概流程咳榜，就開干了夏醉；而且在需求評(píng)審會(huì)上，把這10p+的prd文檔講完涌韩，沒個(gè)2小時(shí)真搞不定畔柔。

上圖是我們之前寫的prd模板↑

我們寫prd的目的是什么？告知團(tuán)隊(duì)成員我這個(gè)需求的背景或者問題是什么臣樱、用戶群體有哪些靶擦、要實(shí)現(xiàn)的目標(biāo)是什么，解決方案是什么雇毫；這些都可以通過一個(gè)個(gè)短小精悍的用戶故事來闡述玄捕。

故事+意義=品牌，通過故事來觸達(dá)人心

不但產(chǎn)品需求可以通過講故事來簡化嘴拢，后續(xù)的營銷也離不開故事桩盲。記得17年底的時(shí)候，順豐官網(wǎng)的大banner是個(gè)微視頻席吴，一個(gè)老父親小心翼翼的把戶口本遞給順豐小哥赌结，小哥雙手接過并微微點(diǎn)頭；畫面一轉(zhuǎn)孝冒，看到一對(duì)新人滿臉笑容的拿著戶口本和結(jié)婚證從民政局出來柬姚。然后配合順豐的slogan“承諾，為每一份托付”庄涡。

怎么寫故事

用戶故事的顆粒度

敏捷中有提到epic量承，即史詩級(jí)的故事，然后才是user story穴店，其實(shí)故事粒度還可以更大撕捍，大到為什么做這個(gè)產(chǎn)品。在梳理產(chǎn)品需求的時(shí)候可以由粗到細(xì)泣洞，先列出粗顆粒的epic忧风，然后切分成小顆粒的user story，用戶故事一定要切分的夠細(xì)球凰，最后是進(jìn)行分組和排序狮腿，產(chǎn)出用戶故事地圖，也就是我們常見的迭代版本清單呕诉。

寫故事四字法：起承轉(zhuǎn)合：

其實(shí)我們小時(shí)候?qū)懽魑囊彩怯玫倪@個(gè)方法缘厢，先介紹故事的主人翁及故事背景，然后在這樣的背景下甩挫，主人翁想要什么或者想達(dá)到什么樣的目的【前面都是起】贴硫，但是現(xiàn)實(shí)中遇到了哪些問題或困難導(dǎo)致很難實(shí)現(xiàn)目的【承】，后來他做了什么事或者哪些努力【轉(zhuǎn)】?伊者，最終歷盡千辛萬苦實(shí)現(xiàn)了目標(biāo)【合】夜畴。

接下來我們結(jié)合產(chǎn)品經(jīng)理梳理需求的思路來提煉重點(diǎn)：

主人翁---user（角色）

故事背景---scene（場(chǎng)景）

想要什么或者想達(dá)到什么樣的目的---Want（目的）

遇到了哪些問題---defect（問題/不爽）

他做了什么事或者哪些努力---Action（行動(dòng)）

舉個(gè)栗子：

小c的工作需要經(jīng)常出差拖刃，有次忘記定酒店了，當(dāng)時(shí)已經(jīng)很晚了贪绘，跑了一天也很累，晚上還要發(fā)工作匯報(bào)郵件央碟，小c想快速的找個(gè)最近的酒店安頓下來税灌。當(dāng)他在手機(jī)上找酒店的時(shí)候，還要點(diǎn)開詳情頁亿虽，去看看當(dāng)晚還有沒有空房菱涤，有些有空房的價(jià)格又高出很多，最后還要到酒店設(shè)施里確認(rèn)下有沒有wifi洛勉。于是小c就背著電腦包在馬路邊盯著手機(jī)找了好久粘秆，找到酒店后我還要把酒店地址貼到百度地圖里，最終跟著導(dǎo)航找到了酒店收毫。

用戶故事的標(biāo)準(zhǔn)模板：

As a , I want to , so that .

作為一個(gè)xxx（某類用戶）攻走，我要xxx（做一件事），從而達(dá)到xxx（某一結(jié)果或動(dòng)機(jī)）此再。

套用這個(gè)模板的示例：作為出差在外卻沒有預(yù)定酒店的人昔搂，我要找到我現(xiàn)所在地點(diǎn)步行距離內(nèi)的經(jīng)濟(jì)酒店，從而能夠睡覺休息输拇、上網(wǎng)處理郵件摘符。

這里有提到角色，其實(shí)角色就是交互設(shè)計(jì)里經(jīng)常提到的用戶畫像persona策吠，后面我會(huì)單獨(dú)一章來分享我對(duì)persona的理解逛裤。不過在之前的文章《產(chǎn)品設(shè)計(jì)中數(shù)據(jù)觀點(diǎn)和用戶畫像--課程內(nèi)容整理》中，有一小部分是對(duì)persona的描述猴抹，感興趣的可以先看下~

總結(jié)：

個(gè)人覺得四字法更適合粗顆粒的史詩級(jí)故事带族，而故事模板更適合細(xì)粒度的用戶故事∏⒃悖或者說四字法更適合需求梳理初期炉菲，可以直觀的看到用戶使用場(chǎng)景和痛點(diǎn)，而痛點(diǎn)就是我們要解決的問題坤溃，而故事模板則更適合技術(shù)團(tuán)隊(duì)溝通拍霜。

如何切故事

為什么要切分故事？

其實(shí)user story就是被切分后的epic薪介。在實(shí)際項(xiàng)目中祠饺，越是高優(yōu)先級(jí)的故事，顆粒度要越小汁政，描述越具體道偷，這樣做的好處是：小的故事大家在理解上不容易產(chǎn)生偏差缀旁，而且更容易完成，故事越大不確定性就越大（比如外部依賴勺鸦，前置關(guān)聯(lián)并巍，臨時(shí)需求插入，團(tuán)隊(duì)人員請(qǐng)假等）换途。

如何切故事懊渡？

按工作流程：比如請(qǐng)假流程，可以把簡單的首尾故事先切分出來军拟，創(chuàng)建請(qǐng)假單剃执，審批請(qǐng)假單，然后中間各個(gè)環(huán)節(jié)的審批流轉(zhuǎn)作為獨(dú)立的故事懈息。

按功能操作：比如一般的后臺(tái)報(bào)表都有增刪改查的功能肾档，可以按增刪改查來切分。

按功能類型：比如接在線支付辫继，微信怒见、支付寶、銀聯(lián)可以拆分為3個(gè)故事來完成骇两，當(dāng)然每個(gè)下面還可以再切速种。

按內(nèi)容范圍：比如酒店詳情頁，先支持查看酒店基本信息和價(jià)格低千，再支持查看周邊交通配阵，地圖位置等。

按用戶需求層次：把性能和穩(wěn)定性方面的考慮拆分成獨(dú)立的新故事示血；

（說明：這些切分方法部分來自于Richard Lawrence棋傍，想了解更多切分方法的可以自己去看下）。

注意事項(xiàng)

從用戶是視角來講故事难审；

把握好用戶故事的粒度：

自己在前期梳理故事瘫拣，或者給高層講故事時(shí)，故事粒度可以粗一些告喊；但是給技術(shù)團(tuán)隊(duì)講故事麸拄，粒度要足夠細(xì)，足夠具體黔姜。

故事并不是越多越好：

一般一個(gè)迭代5-10個(gè)故事拢切，維護(hù)2-3個(gè)迭代周期的故事就可以了，讓那些價(jià)值不高的故事從你的待辦清單里消失吧~（數(shù)據(jù)僅供參考秆吵，具體還要看迭代周期的長短和團(tuán)隊(duì)資源的配比淮椰，我這個(gè)是5天一個(gè)周期，2個(gè)開發(fā)人員的工作量，當(dāng)然我的故事拆的非常兄魉搿）泻拦。

要有驗(yàn)收條件：

即符合什么要求的故事才算可交付的，也是給測(cè)試人員一個(gè)測(cè)試依據(jù)忽媒。

寫在最后

關(guān)于用戶故事我也是最近1年才開始使用争拐，踩的坑還不夠多，寫這篇文章前我又把相關(guān)的書和資料都看了一遍猾浦，修修改改的寫了1整天陆错，希望有經(jīng)驗(yàn)的小伙伴可以一起交流探討~~~