產品功能開發排序邏輯: 價值與複雜度矩陣
這是這個系列的第三篇
類似前一篇艾森豪矩陣這種用兩個元素來分析，並且為四個象限各自制定策略的方式還有一些其他的模式，我自己用過的是「價值」與「實踐複雜度」（Value & Effort）。
「價值」指的是為使用者或企業帶來的價值，評估方式可能會就使用者的價值、商業價值或者長期策略等方面來看；「實踐複雜度」對許多人來說基本上就是時間，實話說我也仍然大致相信複雜度高的東西更有可能花比較久時間，或者比較多成本，不然純粹評估複雜度的操作意義就小了；講未知事項時也是，越模糊我越認為有可能出錯、而要耗費比較大的力氣或者比較長的時間來處理。
四個象限的解析
藉由分析某項有待發展事物之價值與實踐複雜度，你可以把這件事情丟進這四類的其中一個：
- 高價值、低複雜度：有人會稱這個象限為 Quick Wins/Easy Wins/Low-hanging fruit，理想上會最快協助用戶及公司取得價值，價值又比較高。應該要儘速實踐。
- 高價值、高複雜度：有人會稱這個象限為 Stategic initiatives/major projects，雖然要付出比較大的精神，但對未來仍然有莫大幫助。這跟艾森豪矩陣的「重要、但不急」的情形都是需要好好關注的核心。
- 低價值、低複雜度：要做不難、做起來可能有人嫌雞肋的東西會落在這裡。可以拿來塞些小空檔，也因此有人會稱爲 Fill-ins。
- 低價值、高複雜度：按理說不是產品的核心，沒事不要做這邊的東西，或者嘗試走 workaround/替代服務
其實這類雙元素的矩陣，通常都會挑一個多了很好、跟另一個多了不好的元素，這時偏好順序一律會是趨吉避凶 > 福禍相依 > 徒勞無功。
價值/複雜度矩陣的優點
- 直覺、簡單：這跟 MoSCoW 與艾森豪矩陣一樣，都是那種跟別人說了別人會驚覺道理我都懂的類型。不太容易有人反對這樣的邏輯。
- 價值導向，也關乎成本：相較於前兩個介紹的邏輯基本沒有特別把成本拉出來（你當然可以說他們在考量時本來也要思考成本，你是對的），這個邏輯本身根基就是在處理價值與成本的拉扯 。
上一篇提到我不太用艾森豪矩陣，因為在我學到這種雙元素矩陣邏輯後，就直接先使用價值/複雜度了，這在實務上也蠻容易說服實踐單位的，畢竟你考量了他們要花的工。
價值/複雜度矩陣的缺點
- 這個方法仍然沒有處理價值定義問題，所以單純套用時必然還是要遇到多種價值衝突時孰優孰劣這類問題。
- 區分這麼粗的類別，優點是快，缺點仍是同個類別裡會有好幾件事。一定時間之後我們八成需要仰賴其他排序方法。
如果你要用價值與複雜度矩陣的話，這些想法給你參考
- 永遠的優先：先跟團隊及糕層對齊產品目標，再用這個目標來考量。好我覺得我每篇的第一個建議可能都是這個。
- 價值的定義應該會遇到不少麻煩，不過優先序的本質是相對，最終我們的目的不是去比較 A 比 B 價值高多少，而是確定 A 要不要比 B 優先做。嘗試先用排序的方法當作討論的開端即可，不一定要用絕對值，討論的過程裡應該會逐漸抓到價值衝突時團隊更重視什麼。
- 複雜度高的東西先考慮拆解，有時規模小了複雜度也會隨之降低，更容易著手。
其他這個系列的文，沒連結的就是還在寫/還在富奸：
我不時會在 LinkedIn 或 Facebook 分享些關於產品管理的看法/見聞/活動，另有讀書會跟線上諮詢，有興趣可以前往 https://www.bobchao.net
如果你覺得這篇還不錯的話，何不幫我按幾下掌聲，幫助演算法讓這篇飄遠一點，幫助其他跟你一樣的人？
Comments ()