幾年以來，我在執行專案時，一直是使用「使用者故事」的方式，與團隊一起進行敏捷專案開發。
開發專案時，捨棄寫 Spec，而改由撰寫「使用者故事」。可以讓團隊釐清，整個專案有多少角色，在什麼場景，執行什麼功能。我們再針對爬梳出來的 User Story，進行資源以及執行期限的限制篩選。擬定可以執行的方案。
但是，後來這一套方案在特定的狀況下遇到嚴重瓶頸。我們公司的架構當時是分隔台美兩地。Product Owner 在美國協助整理使用者需求，台灣團隊收到後執行。但是，以往管用的招式在此狀況下卻不管用。
原因是以前如果開發團隊都在同一個辦公室，使用者故事上「沒寫到」的細節或原始情境，透過快速的口頭補述交流，就可以補完。專案不至於執行偏差。但是在團隊分隔兩地的情況下，因為時差與團隊成員功力差異，許多「需求」的「原始情境」會消失。
「使用者故事」變成 Product Owner 的一面之詞，他憑著「自己的判斷」以及「喜好」，寫成了「無原始背景」的技術性用戶故事，加上公司又是 Operation-Oriented，有些細節必須要是在現場才會知道。這些「重要的細節」隨著 Remote 與溝通不良被蒸發，於是「使用者故事」又變成只是「簡單版的 Spec」而已。這讓團隊之間，摩擦又開始變得很大。
於是我掙扎著又設計協調出另外一份問題解決結構，搭配 User Story 執行。方式是這樣的：
- 我們遇到了什麼問題?
- 為什麼這件事會發生？
- 我們目前的限制是什麼
- PM 建議的解決方案
- （召集相關的開發成員）大家建議的解決方案是什麼
- （召集相關的開發成員）簡單的 vote
這份敘事的結構，目的有幾個：
- 讓「原始目的」與「原始情境」儘可能的被重現
- 讓團隊了解這個問題的資源限制，以作出最好的建議（一天之內要解決？一週之內要解決？或放著想根本沒差）
- 讓相關的成員有參與感，以及可以激盪出最好最適切的解決方案。（透過 Hackpad 討論，所以來回不會很冗長，通常一個工作天內會結論與表決同時出爐）。而不再是 PM 的一面之詞。
我們成功用這個架構 deliver 了很多大大小小 tricky 的專案。
本來我們也以為這套方案是獨家發明，後來跟一個朋友聊天分享過後。才發現這其實已經是麥肯錫內的架構解決 Best Practices 了。我在麥肯錫新人培訓七堂課 這本書內有找到更多這套方法的敘述與強化。
以下整理出方法重點：
1. 解決真正的問題
比如說老闆抱怨「最近生意不好」，所以我們要搞個「促銷」。此時重要的不是真的去寫「促銷」的 User Story。而是去找出「生意不好」是指「來客量不高」，還是「單個客人貢獻營業額不高」。
2. 定義問題、假設與分析、解決策略
執行這個步驟的重點在於「分離現象和原因」。利用邏輯樹找出問題結構後
- 生意不好
- 來客量不高
- 每個客戶平均成交率低
- 沒有花新力在開發新客戶
- 單個客人貢獻營業額不高
- 單品平均銷售額沒有增加
- 顧客平均購買量沒有增加
- 來客量不高
然後再找出什麼是最重要的議題。（因為沒有美國時間一個一個去做）
3. 根據團隊目前限制針對最重要問題設計出有意義的解決方案
因為產品開發不可能無限制發散討論。一定要有得收斂，且要在「一定時間內」完成，否則超過時間限制，原始的討論也會變得一點意義都沒有，而淪為純清談。
解決問題時必須注意到的重點
- 不要受眼前的狀況和條件所限
- 經常意識到邏輯思考
- 不斷問為什麼？
- 為什麼？做什麼？怎麼做？
「為什麼？做什麼？怎麼做？」
在商場上，這三個問題就是把「哪些產品與服務，透過什麼方法，提供給哪種類型的顧客？」只要這三個問題沒弄清楚，就會搞錯方向，浪費資源。
這也是當初我們單純只讓 PO 使用「User Story」單純敘事的缺陷。
PO 少告訴了大家「為什麼？」，而 PO 單方面的決定「做什麼？」「怎麼做？」。
這個方法是一個把產品所有權回歸到整個團隊的好方法。
推薦給大家使用。