入冬許久，今天才剛剛有點涼意，把早早拿出來的衛衣換上。寫這篇文章的此時，我和朋友們坐在星巴克，一邊感受着久違的閒適，一邊懶散的碼着字。前兩天回顧2018年計劃——《用戶故事地圖》讀書筆記是做爲年度計劃來準備的，看來我早就知這件事情的困難——翻譯的書真是太難懂。看看思維導圖後面還有很多內容，不知道在12月底之前，是否能把它們全都寫完。
從各方收集到的需求（用戶故事），經過了機會階段的初步篩選、探索階段的設計與開發側的可行性評估，以及設計方案的實現和驗證。接下來，將會進入團隊共同參與的故事工作坊（在我看來就是項目需求評審會，以下均稱爲“評審會”），它也稱爲最後一次最佳參與的機會。
這一階段主要討論細節，其目標有2點：
- 基於開發層面拆分需求爲小模塊，以制定後續開發任務的迭代計劃；
- 對開發的各個小模塊達成一致的驗收標準；
準備階段
首先，在會議開始前要選擇粒度合適的故事進入評審，清楚這些需求必要的細節，如有必要可以提供多種方案來進行評估。
提前邀請開發團隊、其他利益相關人士等進入會議，例如開發人員、測試人員、體驗專家、視覺相關設計師，總數在3〜5爲益。爲保證會議效率，會議人員不益過多（我們都經歷過又臭又長的會議）。然而，在同一場會議中，在不同階段可能需要不同的人蔘與。這裏介紹一個“金魚缸協作模式”，可以保證讓更多人蔘與，同時降低人數太多造成的影響。
具體如上圖。參與討論的3〜5個人聚集在白板前討論——他們就是魚缸裏的金魚。處於魚缸（上圖中的圈）外面的人只能看，不能講話。魚缸外的人要想參與討論，必須與魚缸裏的人互換纔行。
待上述內容準備就續後，接下來正式進入評審會。
執行階段
1､與所有人一起，再次瞭解故事的大體情況
與前幾個階段一樣，會議開始時候我們依然需要講清楚3W（what、why、who）信息。有時候我們會認爲團隊成員不關心產品，只完成自己應該做的內容，不會從整體考慮。但我認爲真實的原因是，項目並沒有創造讓成員們關心產品的環境，需求來源往往下意識認爲其他人執行即可，不需要了解太多背景信息。同時也爲了節省時間，會在評審會時直接講解需求內容。這恰恰剝奪了成員們瞭解產品的機會。由此可見，講清楚每個需求的3W信息（特別是why）非常必要。
在會議中，所有人通過討論和交流，明確幾個內容：
- 用戶是誰？
- 他們是如何使用產品的？
- 功能完成後看起來應該是怎樣的？
- 我們要如何開發這些功能，他們的工作原理（業務邏輯、數據等）是怎樣的？
在討論方案過程中，儘量以用戶視角來討論，例如“用戶在做什麼”、“用戶接下來會看到什麼”。若遇到產品內部邏輯時候，可以使用“數據是如何輸入的”這樣的表述方式，更容易被所有人理解。
會議中隨時記錄大家的想法和點子。非常建議藉助一些道具來記錄，例如白板、掛圖、便利貼等，這樣即可以防止信息被蒸發，也可以讓大家都看到所有內容。（近期看了一本書《設計衝刺》，同樣倡議使用這樣的方法）。
2､分組討論
待所有人瞭解了功能的大概內容和運行原理之後，接下來要將參與人員分組，儘量保證每個小組有測試人員、開發人員、體驗設計師或需求人員。各組用固定時間，製作出這些用戶故事的開發計劃（估時）。
3､小組間分享計劃和估時
每個小組分享他們制定的開發計劃（不要講細節），在此期間，需要指出開發功能的問題和改進點，並估算開發時間。
對很多人來講，估算開始時間有時候是不太可能的。我猜測主要是對待開發內容和原有產品運行機制不瞭解導致：未知=不可估。而用戶故事地圖的過程，可以幫助大家對功能開發內容達成一致性的理解。此外，還可以將相似規模需求的實際開發時間做爲樣本，以讓開發時間估算儘量接近於真實值。而對於這一點，則需要我們對已投入的開發時間進行記錄，儘可能將大的計劃切分爲小的部分，這樣就可以獲得更多度量的機會。度量越頻繁，統計的時間結果越接近於真實值。
會議人員需要對上述開發決策和另外一項內容達成共識。“另外一項內容” 是指，驗證功能開發完成的最低標準（換句話說，就是一起評審軟件時，應如何展示開發的內容，例如按用戶操作流程，保證這個流程可以走通）。對驗收標準的討論，可以揭示如何進行工作分解。我們可以開發分解後得到的故事，並進行及時的檢查和調整。
異常情況
用戶故事工作坊的效果可能不會理想（開過需求評審會的同學應該深有體會），有幾點原因可能會導致這一情況的出現：
- 不能從功能和技術角度考慮方案，整個會議過程都在務虛；
- 大家只關注如何完成功能，不關心3W內容；
- 一言堂，沒有人積極參與。如何解決這些問題，那就是會議組織和管理的相關內容，可以自行學習。
除此之外，還有可能在討論細節和思考開發時間時發現故事太大，無法在規定時間內完成。這個時候就需要進一步分解故事——將“更好”的用戶故事，拆解爲“正好”的用戶故事。
—— end ——
全部內容鏈接：
用戶故事地圖（1）：體驗用戶故事
用戶故事地圖（2）：作用
用戶故事地圖（3）：故事與卡片
用戶故事地圖（4）：創建方法
用戶故事地圖（5）：開發流程之“機會”階段
用戶故事地圖（6）：開發流程之“探索”階段
用戶故事地圖（7）：開發流程之“設計”階段
用戶故事地圖（8）：開發流程之“故事工作坊”階段
用戶故事地圖（9）：開發流程之“研發-評估-交付”階段
用戶故事地圖（10）：開發流程之“回顧”階段
用戶故事地圖（11）：故事（需求）拆分
用戶故事地圖（12）：後記