about 2 years ago

幾年以來,我在執行專案時,一直是使用「使用者故事」的方式,與團隊一起進行敏捷專案開發。

開發專案時,捨棄寫 Spec,而改由撰寫「使用者故事」。可以讓團隊釐清,整個專案有多少角色,在什麼場景,執行什麼功能。我們再針對爬梳出來的 User Story,進行資源以及執行期限的限制篩選。擬定可以執行的方案。

但是,後來這一套方案在特定的狀況下遇到嚴重瓶頸。我們公司的架構當時是分隔台美兩地。Product Owner 在美國協助整理使用者需求,台灣團隊收到後執行。但是,以往管用的招式在此狀況下卻不管用。

原因是以前如果開發團隊都在同一個辦公室,使用者故事上「沒寫到」的細節或原始情境,透過快速的口頭補述交流,就可以補完。專案不至於執行偏差。但是在團隊分隔兩地的情況下,因為時差與團隊成員功力差異,許多「需求」的「原始情境」會消失。

「使用者故事」變成 Product Owner 的一面之詞,他憑著「自己的判斷」以及「喜好」,寫成了「無原始背景」的技術性用戶故事,加上公司又是 Operation-Oriented,有些細節必須要是在現場才會知道。這些「重要的細節」隨著 Remote 與溝通不良被蒸發,於是「使用者故事」又變成只是「簡單版的 Spec」而已。這讓團隊之間,摩擦又開始變得很大。

於是我掙扎著又設計協調出另外一份問題解決結構,搭配 User Story 執行。方式是這樣的:

  1. 我們遇到了什麼問題?
  2. 為什麼這件事會發生?
  3. 我們目前的限制是什麼
  4. PM 建議的解決方案
  5. (召集相關的開發成員)大家建議的解決方案是什麼
  6. (召集相關的開發成員)簡單的 vote

這份敘事的結構,目的有幾個:

  1. 讓「原始目的」與「原始情境」儘可能的被重現
  2. 讓團隊了解這個問題的資源限制,以作出最好的建議(一天之內要解決?一週之內要解決?或放著想根本沒差)
  3. 讓相關的成員有參與感,以及可以激盪出最好最適切的解決方案。(透過 Hackpad 討論,所以來回不會很冗長,通常一個工作天內會結論與表決同時出爐)。而不再是 PM 的一面之詞。

我們成功用這個架構 deliver 了很多大大小小 tricky 的專案。

本來我們也以為這套方案是獨家發明,後來跟一個朋友聊天分享過後。才發現這其實已經是麥肯錫內的架構解決 Best Practices 了。我在麥肯錫新人培訓七堂課 這本書內有找到更多這套方法的敘述與強化。

以下整理出方法重點:

1. 解決真正的問題

比如說老闆抱怨「最近生意不好」,所以我們要搞個「促銷」。此時重要的不是真的去寫「促銷」的 User Story。而是去找出「生意不好」是指「來客量不高」,還是「單個客人貢獻營業額不高」。

2. 定義問題、假設與分析、解決策略

執行這個步驟的重點在於「分離現象和原因」。利用邏輯樹找出問題結構後

  • 生意不好
    • 來客量不高
      • 每個客戶平均成交率低
      • 沒有花新力在開發新客戶
    • 單個客人貢獻營業額不高
      • 單品平均銷售額沒有增加
      • 顧客平均購買量沒有增加

然後再找出什麼是最重要的議題。(因為沒有美國時間一個一個去做)

3. 根據團隊目前限制針對最重要問題設計出有意義的解決方案

因為產品開發不可能無限制發散討論。一定要有得收斂,且要在「一定時間內」完成,否則超過時間限制,原始的討論也會變得一點意義都沒有,而淪為純清談。

解決問題時必須注意到的重點

  1. 不要受眼前的狀況和條件所限
  2. 經常意識到邏輯思考
  3. 不斷問為什麼?
  4. 為什麼?做什麼?怎麼做?

「為什麼?做什麼?怎麼做?」

在商場上,這三個問題就是把「哪些產品與服務,透過什麼方法,提供給哪種類型的顧客?」只要這三個問題沒弄清楚,就會搞錯方向,浪費資源。

這也是當初我們單純只讓 PO 使用「User Story」單純敘事的缺陷。

PO 少告訴了大家「為什麼?」,而 PO 單方面的決定「做什麼?」「怎麼做?」。

這個方法是一個把產品所有權回歸到整個團隊的好方法。

推薦給大家使用。

← 如何同時執行 Growth 戰術以及 Project Management 淺談 O2O 的未來:由 HomeJoy 倒閉事件衍伸出來的 Inconvenient Truth →
 
comments powered by Disqus