第一階段的需求結束，產品團隊很想松口氣带污，但是我在盤點需求文檔時遇到很多實際問題畅涂。
1、需求按模塊拆分脾歇，強調用例
用例利于項目組內部溝通，解決的是開發(fā)測試的問題淘捡。但藕各，用戶的使用與感受不可能通過用例去理解。
2焦除、整體框架與內部關聯關系模糊
雖然有全局規(guī)則的定義激况，有公共規(guī)則，有敘詞表膘魄，有權限表乌逐，有推廣需求，有數據統(tǒng)計……但是當每個人陷入細節(jié)创葡，特別是自己負責的那部分浙踢，誰來負責整體框架性與關聯關系？
3灿渴、業(yè)務缺乏可視化
文檔過于碎片洛波，缺乏可視化，查找某個深埋在某份文檔里的分支或規(guī)則非常困難骚露，方圓幾米蹬挤，基本靠吼或行走，沒有人有時間去翻荸百。
4闻伶、PRD 參差不齊
項目趕進度，PRD 很難盡善盡美够话，何況存在多人撰寫再合并蓝翰，個體能力與習慣不同光绕，文檔調性明顯不一。包括我自己的部分畜份，還是有很多細節(jié)诞帐，難以通過文字與研發(fā)、測試達成一致爆雹，更多要靠口頭反復確認停蕉，甚至是一起到交互處對著設計稿核對，團隊協同效率太低钙态。
5慧起、培訓是難題
業(yè)務丟失全景圖，想從全局角度理解業(yè)務有一定難度册倒。如果這個時候團隊有新人蚓挤，培訓就是難題。
就像某個前端同事說的驻子，“這么多文檔咋沒有個索引灿意？”
我開始思考，有沒有辦法用項目里各種角色的人（至少是產品團隊）都能理解的方式崇呵，構建一張業(yè)務全景圖缤剧，或者是需求索引？
用戶故事地圖（User Story Map）
整個故事的結構由脊梁骨（backbone）與行走中的骨骼（skeleton）組成域慷，骨骼中有較多的主干荒辕，按照必要性（necessity）從上到下排序。
圖片來源：SlideShare 公開資源
具體到案例演繹芒粹，有點像卡片分類與需求用例兄纺。
任務是用動詞描述用戶做什么事情。從左到右形成敘事主線化漆。
任務有不同的目標層級，優(yōu)先級從上到下降序钦奋。地圖的深度包含各個子任務座云。
活動構成了故事的主干。
橘色第一行付材，對應上圖中的脊梁骨（backbon）朦拖，就是最小化的用戶故事，即用戶行為厌衔。
藍色第二行璧帝，對應上圖中的骨骼（skeleton），按照從左到右的順序敘述用戶任務富寿。
黃色第三行睬隶，就是故事情節(jié)的內容組成與細節(jié)锣夹，按照優(yōu)先級，對應下圖中的發(fā)布計劃（Release）苏潜，Release 1 ＞ Release 2＞Release 3银萍。
圖片來源：Winnipeg Agilist
舉例：
圖片來源：SlideShare 公開資源
我們在新項目里的執(zhí)行
很可惜，我們在項目初期沒有采取這樣的方式恤左。但是在第一階段的需求盤點贴唇，這種模式還是給了我很大幫助。
用戶故事地圖的理論基礎飞袋，做適度的改良戳气。
個人體會：
需求范圍沒有擴大，但是我對需求的理解更加深刻了巧鸭。也許這會至少成為我在其他新項目里對于全局規(guī)則的標配物咳，它不取代全局規(guī)則的定義，但是可以輔助團隊進行討論蹄皱。
實踐經驗：
1览闰、展示了為誰做，為什么做巷折，而不僅僅是做了什么压鉴。
故事地圖以廣度優(yōu)先（從左到右），而非深度锻拘，探索時向深度拓展（從上到下）油吭。
2、實踐起來成本低署拟。
我甚至沒有用卡片也沒有用白板婉宰，就是最簡單的Excel，影響最大化（可用性較高推穷，利于傳播）心包。
3、PRD 不是最優(yōu)先的馒铃。
有不同用戶角色使用網站的步驟蟹腾，也有每個階段的需求點，需要查看細節(jié)区宇，可以隨時查看文檔娃殖，此時的 PRD反而成了備忘。
參考書目：《用戶故事地圖》
作者：Jeff Patton著 李濤 向振東譯
