對于一個傳統(tǒng)設(shè)計師來講，僅僅理解“開發(fā)流程”奈揍、“項目管理”、“敏捷”等術(shù)語的表層含義都要大費(fèi)腦筋钮莲。然而交互設(shè)計師卻是冠以設(shè)計師之名照藻，但從知識結(jié)構(gòu)袜啃、技能、思維方式等都與傳統(tǒng)設(shè)計師大相徑庭幸缕∪悍ⅲ“產(chǎn)品設(shè)計師”做為交互設(shè)計師未來職業(yè)發(fā)展方向之一晰韵，則要求擁有更富結(jié)構(gòu)的知識體系，對產(chǎn)品熟妓、團(tuán)隊雪猪、項目有更深的理解，而這也是我寫這一系列文章的原因之一起愈。
從這一篇開始只恨，將會進(jìn)入正式的知識“轉(zhuǎn)述”過程，如若這些文章有幸被此領(lǐng)域?qū)＜铱吹教洌l(fā)現(xiàn)了其中的錯誤漏官觅，還請斧正，幫助我們成長進(jìn)步阐污。
上篇文章結(jié)合一次沙龍簡單介紹了用戶故事的內(nèi)容和作用休涤。那它能解決哪些具體問題？在介紹用戶故事的具體內(nèi)容之前疤剑，我們先簡單聊聊滑绒，我認(rèn)為用戶故事圖最實(shí)用的三個方向：
- 規(guī)劃版本需求；
- 驗(yàn)證需求有效性隘膘；
- 產(chǎn)品優(yōu)化與開發(fā)跟蹤疑故；
規(guī)劃版本需求
對于用戶，版本開發(fā)的功能間有哪些影響弯菊？各階段版本對產(chǎn)品和用戶的整體影響是什么纵势？是否要遵循某些線索和規(guī)則？這些取決于如何選擇各版本的開發(fā)內(nèi)容管钳。
每個產(chǎn)品都會有一個需求池钦铁，里面存儲大量等待消化的需求。每當(dāng)規(guī)劃新版本才漆，從需求池中翻找需求都是很痛苦的過程牛曹。我曾帶過一個項目，我們使用用戶故事的語術(shù)描述需求醇滥，以便判斷其對用戶的影響黎比。隨著時間推移，有些需求不再適用鸳玩，但需求數(shù)量依然“穩(wěn)步”增加阅虫。這此需求粒度不同、指向不同不跟，每次篩選需求都十分痛苦不說颓帝，團(tuán)隊也被帶入各種細(xì)節(jié)中無法自拔。
用戶故事地圖很好的解決了這一問題。它從需求層面购城，對產(chǎn)品進(jìn)行橫向流程和縱向細(xì)節(jié)的梳理吕座。將需求按照核心操作流程進(jìn)行組織。每次先聚焦于各關(guān)鍵流程環(huán)節(jié)瘪板，再篩選對應(yīng)需求米诉。即保證持續(xù)從大局著眼，同時篷帅，又對所有需求進(jìn)行了結(jié)構(gòu)性的組織史侣。
驗(yàn)證需求有效性
產(chǎn)品開發(fā)中如何評估需求可靠性？如何評估與權(quán)衡需求的用戶價值和產(chǎn)品價值魏身？以用戶故事驅(qū)動的開發(fā)流程惊橱，提供了一些快速、不斷驗(yàn)證需求可靠性的方法箭昵。
在用戶故事地圖中税朴，未經(jīng)討論的需求被稱之為“機(jī)會”。在團(tuán)隊中家制，分階段對這些“機(jī)會”進(jìn)行不同層面（真實(shí)性正林、用戶/產(chǎn)品價值、重要性颤殴、成本等）的提問觅廓，以在開發(fā)前發(fā)現(xiàn)不合適的需求，節(jié)省后期的溝通和設(shè)計開發(fā)成本涵但。
流入開發(fā)階段的需求杈绸，結(jié)合快速原型、可用性測試矮瘟、用戶階段測試等方式快速校驗(yàn)方案瞳脓，并更新到用戶故事地圖中，以讓所有變化在整個地圖中得到體現(xiàn)澈侠，便于團(tuán)隊隨時刷新對產(chǎn)品的整體認(rèn)識劫侧。
產(chǎn)品優(yōu)化與開發(fā)跟蹤
開發(fā)和測試工程師普遍討厭變更，有時候以變更數(shù)量多來說明需求質(zhì)量差哨啃。變更越少越好嗎烧栋？大多數(shù)人都期待需求在早期就能完整和正確，然而哪些最牛逼的產(chǎn)品和交互設(shè)計師棘催，都無法代表用戶——在沒有反饋和驗(yàn)證的情況下保證方案適用劲弦。我們需要正確認(rèn)識“變更”耳标，它其實(shí)是在開發(fā)過程中不斷發(fā)現(xiàn)醇坝、學(xué)習(xí)新的知識，以修正最初的結(jié)果的工具。以變更數(shù)量來判別需求好壞呼猪，并非明智之舉画畅。
在開發(fā)過程中，常有“將XX功能放在后續(xù)版本”宋距、“具體看上線數(shù)據(jù)情況再調(diào)整”這種情況轴踱，但現(xiàn)實(shí)卻是這些“后續(xù)開發(fā)”的功能往往石沉大海。將這些“后續(xù)開發(fā)”的功能放在用戶地圖中谚赎，就能在后續(xù)規(guī)劃功能時看到它淫僻，并從大局去考慮是否真的有必要優(yōu)化。
產(chǎn)品負(fù)責(zé)人希望項目中所有人都關(guān)心產(chǎn)品壶唤，并且就開發(fā)內(nèi)容達(dá)成共識雳灵。但現(xiàn)實(shí)卻是，除了產(chǎn)品負(fù)責(zé)人和需求方闸盔，其他人大多扮演“被說服”的對象悯辙，被動完成任務(wù)。這導(dǎo)致需求方成為產(chǎn)品的瓶頸迎吵，而產(chǎn)品上線后的好壞躲撰，其實(shí)在開發(fā)之前就已被決定。
大多情況下击费，流入開發(fā)環(huán)節(jié)的需求已經(jīng)被確定拢蛋，團(tuán)隊直接按照需求完整開發(fā)、測試蔫巩，有時候遇到性又紅又專瓤狐、歷史邏輯問題，導(dǎo)致整體被推翻或干脆中止批幌。僥幸上線础锐，之后接觸到用戶發(fā)現(xiàn)效果不佳，只能縫縫補(bǔ)補(bǔ)荧缘，非常被動皆警。用戶故事地圖驅(qū)動的開發(fā)流程，建議我們分三個階段來開發(fā)功能截粗。各階段中分別進(jìn)行測試信姓，以驗(yàn)證其對用戶的有效性和穩(wěn)定性。
| 階段 | 內(nèi)容 | 目標(biāo) | 說明 |
|---|---|---|---|
| 開局 | 開發(fā)核心流程 | 排除技術(shù)風(fēng)險 | 1绸罗、通過數(shù)據(jù)觀察功能的性能意推； 2、使用自動化測試檢驗(yàn)穩(wěn)定性; 3珊蟀、關(guān)注技術(shù)挑戰(zhàn)和風(fēng)險菊值，通過消除技術(shù)風(fēng)險，避免風(fēng)險在后期造成更大成本; |
| 中局 | 開發(fā)周邊功能 | 關(guān)注質(zhì)量，達(dá)到可發(fā)布標(biāo)準(zhǔn) | 1腻窒、開發(fā)主流程之外的其他可選流程和復(fù)雜邏輯昵宇； 2、常常加入之前未發(fā)現(xiàn)的新特性; 3儿子、原系統(tǒng)無法滿足性能上的需求而需要額外投入來解決的問題 |
| 末局 | 打磨產(chǎn)品 | 讓產(chǎn)品更搶眼瓦哎、使用更高效 | 1、可能會加入未預(yù)想的東西柔逼； 2蒋譬、使用線上真實(shí)數(shù)據(jù)測試； 3愉适、常常會現(xiàn)在原型階段無法識別的改進(jìn)點(diǎn) |
—— end ——
全部內(nèi)容鏈接：
用戶故事地圖（1）：體驗(yàn)用戶故事
用戶故事地圖（2）：作用
用戶故事地圖（3）：故事與卡片
用戶故事地圖（4）：創(chuàng)建方法
用戶故事地圖（5）：開發(fā)流程之“機(jī)會”階段
用戶故事地圖（6）：開發(fā)流程之“探索”階段
用戶故事地圖（7）：開發(fā)流程之“設(shè)計”階段
用戶故事地圖（8）：開發(fā)流程之“故事工作坊”階段
用戶故事地圖（9）：開發(fā)流程之“研發(fā)-評估-交付”階段
用戶故事地圖（10）：開發(fā)流程之“回顧”階段
用戶故事地圖（11）：故事（需求）拆分
用戶故事地圖（12）：后記
