距離寫完還有兩章左右。最近突然對生活有了新的感受，按照我以往的性格，對身邊的事情都非常在意，在意人的感受、在意彼此的關系、在意別人的看法。但突然之間，很多事情、很多人，似乎都沒有那么重要。人與人再緊密，彼此之間依然會活成一座座孤島。在這其中，最重要的是要懂得珍惜自己，珍惜生活，珍惜當下。也許就是在這個時候，突然感受到了一直在追求的時間管理的下一個階段，對當下的珍視和關注——不思量過去，不焦慮未來，投入最大的心力和注意，就在當下。
從項目開始到結束，一個需求從頭腦中的想法轉變成“機會”，經過“探索”找到更多細節，由設計師進行模型設計，然后進入“故事工作坊”進行周期評估，最后研發、測試、上線。開發也許到此已告一段落，然后對于團隊而言，它還有一個重要環節需要進行，那就是“回顧”（或稱為總結、復盤）。
我們常常會經歷過這樣的回顧：
- 對回顧不重視，時有時無；
- 回顧總結形式化；
- 其樂融融或者爭吵不休。
大部分回顧會議似乎都很少能持續推進具體執行力、對團隊有易的結論和措施。回顧之所以被忽略，想來原因很大可能是因為回顧不是“特效藥”，即不可能當下就對項目、對產品產生可見的幫助，而錯誤的回顧方式和會議技巧，無疑加重了對這一認知的偏見。在《用戶故事地圖》中，回顧的作用被說明為“沉淀優化產品和開流程”，它向我們提供了兩種不同目的回顧會議：
- 與項目外的角色一起回顧
- 與項目內的角色一起回顧（項目反思與回顧會議）
與項目外的角色一起回顧
此類回顧需要邀請的“項目外角色”是指團隊外的重要干系人。回顧會議能幫助他們理解剛剛完成的內容和整體規劃的關系，在團隊討論中對產品的一些洞察和利弊分析。團隊開發需要全員參與，因為它是非常不錯的、讓團隊成員看到他人對產品真實反應的機會，有助于提醒他們自己在做的事情有多重要。
回顧會議不需要很正式，最好帶一些吃的（這是這本書中反復強調的，也許吃的東西能讓人們放松一些）。在這場回顧會議中，要評估兩個內容：
1. 可交付的故事
內容包括方案的目標用戶和預期結果、當前方案的發布進度、每個方案構建成果。
2. 后續探索性的故事
包括當前已在處理的機會、為理解問題和解決方案做的所有工作、當前所做的原型，并討論用戶對解決方案的看法。
與項目成員一起回顧
當然，與項目成員在一起回顧的氛圍可以更輕松，找一個安全的地方，帶上一些吃的。這種回顧會議有三方面內容：
1. 針對產品，需要成員對產品質量進行評估
這是指項目所有成員對產品質量的一次主觀評級，質量共分為1?5級，最是最好的。我們會通過問自己一些問題，來從三個方面進行評級。具體如下：
- 用戶體驗質量：
- 它有預期的那么好嗎？
- UI和具體使用體驗是怎樣的？
- 功能質量：
- 測試過程是否流暢？
- 測試人員認為測試更多內容或時間可以發現更多BUG嗎？
- 是否還有許多BUG未解決？
- 代碼質量：
- 維護的容易度和擴展度？
- （應該是只有開發人員才有資格對代碼質量進行評級）
2. 針對過程，成員們討論最近一次開發周期中的工作方式
它主要包括兩方面的內容：
- 下一次開發周期要做哪些改變？
- 最近一次開發周期中做的改變有效嗎？這些策略是繼續保持還是放棄？
以上部分常常是最容易被忽略的，因為它們并不與KPI直接相關，也無法對產品有快速見效的改變。也許這就是短視之處，人們常常需要“特效藥”，但我相信團隊協作和效率問題，并不是一兩項舉措就可以有所改變而受用終生。團隊，畢竟是一群人的協作，只有慢慢協調和調整，引導群體逐漸適應，才能源源不斷的為團隊提供向前沖的動力。
3. 針對計劃
了解scrum的朋友相對更容易理解大迭代和沖刺的關系。無數個沖刺組成一個迭代，每個沖刺相當于小的開發周期。而在每個沖刺結束時，都需要進行回顧，團隊成員一起目前項目的進展，已完成和未完成的故事和數量。以決策是否需要對開發內容和進度有所調整。
——end——
全部內容鏈接：
用戶故事地圖（1）：體驗用戶故事
用戶故事地圖（2）：作用
用戶故事地圖（3）：故事與卡片
用戶故事地圖（4）：創建方法
用戶故事地圖（5）：開發流程之“機會”階段
用戶故事地圖（6）：開發流程之“探索”階段
用戶故事地圖（7）：開發流程之“設計”階段
用戶故事地圖（8）：開發流程之“故事工作坊”階段
用戶故事地圖（9）：開發流程之“研發-評估-交付”階段
用戶故事地圖（10）：開發流程之“回顧”階段
用戶故事地圖（11）：故事（需求）拆分
用戶故事地圖（12）：后記
