對(duì)于一個(gè)傳統(tǒng)設(shè)計(jì)師來(lái)講，僅僅理解“開發(fā)流程”、“項(xiàng)目管理”、“敏捷”等術(shù)語(yǔ)的表層含義都要大費(fèi)腦筋。然而交互設(shè)計(jì)師卻是冠以設(shè)計(jì)師之名，但從知識(shí)結(jié)構(gòu)、技能、思維方式等都與傳統(tǒng)設(shè)計(jì)師大相徑庭?！爱a(chǎn)品設(shè)計(jì)師”做為交互設(shè)計(jì)師未來(lái)職業(yè)發(fā)展方向之一，則要求擁有更富結(jié)構(gòu)的知識(shí)體系，對(duì)產(chǎn)品、團(tuán)隊(duì)、項(xiàng)目有更深的理解，而這也是我寫這一系列文章的原因之一。
從這一篇開始，將會(huì)進(jìn)入正式的知識(shí)“轉(zhuǎn)述”過(guò)程，如若這些文章有幸被此領(lǐng)域?qū)＜铱吹?，發(fā)現(xiàn)了其中的錯(cuò)誤漏，還請(qǐng)斧正，幫助我們成長(zhǎng)進(jìn)步。
上篇文章結(jié)合一次沙龍簡(jiǎn)單介紹了用戶故事的內(nèi)容和作用。那它能解決哪些具體問(wèn)題？在介紹用戶故事的具體內(nèi)容之前，我們先簡(jiǎn)單聊聊，我認(rèn)為用戶故事圖最實(shí)用的三個(gè)方向：
- 規(guī)劃版本需求；
- 驗(yàn)證需求有效性；
- 產(chǎn)品優(yōu)化與開發(fā)跟蹤；
規(guī)劃版本需求
對(duì)于用戶，版本開發(fā)的功能間有哪些影響？各階段版本對(duì)產(chǎn)品和用戶的整體影響是什么？是否要遵循某些線索和規(guī)則？這些取決于如何選擇各版本的開發(fā)內(nèi)容。
每個(gè)產(chǎn)品都會(huì)有一個(gè)需求池，里面存儲(chǔ)大量等待消化的需求。每當(dāng)規(guī)劃新版本，從需求池中翻找需求都是很痛苦的過(guò)程。我曾帶過(guò)一個(gè)項(xiàng)目，我們使用用戶故事的語(yǔ)術(shù)描述需求，以便判斷其對(duì)用戶的影響。隨著時(shí)間推移，有些需求不再適用，但需求數(shù)量依然“穩(wěn)步”增加。這此需求粒度不同、指向不同，每次篩選需求都十分痛苦不說(shuō)，團(tuán)隊(duì)也被帶入各種細(xì)節(jié)中無(wú)法自拔。
用戶故事地圖很好的解決了這一問(wèn)題。它從需求層面，對(duì)產(chǎn)品進(jìn)行橫向流程和縱向細(xì)節(jié)的梳理。將需求按照核心操作流程進(jìn)行組織。每次先聚焦于各關(guān)鍵流程環(huán)節(jié)，再篩選對(duì)應(yīng)需求。即保證持續(xù)從大局著眼，同時(shí)，又對(duì)所有需求進(jìn)行了結(jié)構(gòu)性的組織。
驗(yàn)證需求有效性
產(chǎn)品開發(fā)中如何評(píng)估需求可靠性？如何評(píng)估與權(quán)衡需求的用戶價(jià)值和產(chǎn)品價(jià)值？以用戶故事驅(qū)動(dòng)的開發(fā)流程，提供了一些快速、不斷驗(yàn)證需求可靠性的方法。
在用戶故事地圖中，未經(jīng)討論的需求被稱之為“機(jī)會(huì)”。在團(tuán)隊(duì)中，分階段對(duì)這些“機(jī)會(huì)”進(jìn)行不同層面（真實(shí)性、用戶/產(chǎn)品價(jià)值、重要性、成本等）的提問(wèn)，以在開發(fā)前發(fā)現(xiàn)不合適的需求，節(jié)省后期的溝通和設(shè)計(jì)開發(fā)成本。
流入開發(fā)階段的需求，結(jié)合快速原型、可用性測(cè)試、用戶階段測(cè)試等方式快速校驗(yàn)方案，并更新到用戶故事地圖中，以讓所有變化在整個(gè)地圖中得到體現(xiàn)，便于團(tuán)隊(duì)隨時(shí)刷新對(duì)產(chǎn)品的整體認(rèn)識(shí)。
產(chǎn)品優(yōu)化與開發(fā)跟蹤
開發(fā)和測(cè)試工程師普遍討厭變更，有時(shí)候以變更數(shù)量多來(lái)說(shuō)明需求質(zhì)量差。變更越少越好嗎？大多數(shù)人都期待需求在早期就能完整和正確，然而哪些最牛逼的產(chǎn)品和交互設(shè)計(jì)師，都無(wú)法代表用戶——在沒有反饋和驗(yàn)證的情況下保證方案適用。我們需要正確認(rèn)識(shí)“變更”，它其實(shí)是在開發(fā)過(guò)程中不斷發(fā)現(xiàn)、學(xué)習(xí)新的知識(shí)，以修正最初的結(jié)果的工具。以變更數(shù)量來(lái)判別需求好壞，并非明智之舉。
在開發(fā)過(guò)程中，常有“將XX功能放在后續(xù)版本”、“具體看上線數(shù)據(jù)情況再調(diào)整”這種情況，但現(xiàn)實(shí)卻是這些“后續(xù)開發(fā)”的功能往往石沉大海。將這些“后續(xù)開發(fā)”的功能放在用戶地圖中，就能在后續(xù)規(guī)劃功能時(shí)看到它，并從大局去考慮是否真的有必要優(yōu)化。
產(chǎn)品負(fù)責(zé)人希望項(xiàng)目中所有人都關(guān)心產(chǎn)品，并且就開發(fā)內(nèi)容達(dá)成共識(shí)。但現(xiàn)實(shí)卻是，除了產(chǎn)品負(fù)責(zé)人和需求方，其他人大多扮演“被說(shuō)服”的對(duì)象，被動(dòng)完成任務(wù)。這導(dǎo)致需求方成為產(chǎn)品的瓶頸，而產(chǎn)品上線后的好壞，其實(shí)在開發(fā)之前就已被決定。
大多情況下，流入開發(fā)環(huán)節(jié)的需求已經(jīng)被確定，團(tuán)隊(duì)直接按照需求完整開發(fā)、測(cè)試，有時(shí)候遇到性又紅又專、歷史邏輯問(wèn)題，導(dǎo)致整體被推翻或干脆中止。僥幸上線，之后接觸到用戶發(fā)現(xiàn)效果不佳，只能縫縫補(bǔ)補(bǔ)，非常被動(dòng)。用戶故事地圖驅(qū)動(dòng)的開發(fā)流程，建議我們分三個(gè)階段來(lái)開發(fā)功能。各階段中分別進(jìn)行測(cè)試，以驗(yàn)證其對(duì)用戶的有效性和穩(wěn)定性。
| 階段 | 內(nèi)容 | 目標(biāo) | 說(shuō)明 |
|---|---|---|---|
| 開局 | 開發(fā)核心流程 | 排除技術(shù)風(fēng)險(xiǎn) | 1、通過(guò)數(shù)據(jù)觀察功能的性能； 2、使用自動(dòng)化測(cè)試檢驗(yàn)穩(wěn)定性; 3、關(guān)注技術(shù)挑戰(zhàn)和風(fēng)險(xiǎn)，通過(guò)消除技術(shù)風(fēng)險(xiǎn)，避免風(fēng)險(xiǎn)在后期造成更大成本; |
| 中局 | 開發(fā)周邊功能 | 關(guān)注質(zhì)量，達(dá)到可發(fā)布標(biāo)準(zhǔn) | 1、開發(fā)主流程之外的其他可選流程和復(fù)雜邏輯； 2、常常加入之前未發(fā)現(xiàn)的新特性; 3、原系統(tǒng)無(wú)法滿足性能上的需求而需要額外投入來(lái)解決的問(wèn)題 |
| 末局 | 打磨產(chǎn)品 | 讓產(chǎn)品更搶眼、使用更高效 | 1、可能會(huì)加入未預(yù)想的東西； 2、使用線上真實(shí)數(shù)據(jù)測(cè)試； 3、常常會(huì)現(xiàn)在原型階段無(wú)法識(shí)別的改進(jìn)點(diǎn) |
—— end ——
全部?jī)?nèi)容鏈接：
用戶故事地圖（1）：體驗(yàn)用戶故事
用戶故事地圖（2）：作用
用戶故事地圖（3）：故事與卡片
用戶故事地圖（4）：創(chuàng)建方法
用戶故事地圖（5）：開發(fā)流程之“機(jī)會(huì)”階段
用戶故事地圖（6）：開發(fā)流程之“探索”階段
用戶故事地圖（7）：開發(fā)流程之“設(shè)計(jì)”階段
用戶故事地圖（8）：開發(fā)流程之“故事工作坊”階段
用戶故事地圖（9）：開發(fā)流程之“研發(fā)-評(píng)估-交付”階段
用戶故事地圖（10）：開發(fā)流程之“回顧”階段
用戶故事地圖（11）：故事（需求）拆分
用戶故事地圖（12）：后記
