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