產品功能開發排序邏輯: 緊急度與重要性（艾森豪矩陣）
這是這個系列的第二篇
先前大舉徵才時，「你採用什麼方式來安排開發順序」是我幾乎一定會問到的題目。從大家的答案裡，我其實有點驚訝於不少公司是採用這個「緊急 x 重要」矩陣，又稱為「艾森豪矩陣」的手法來排序。
這個方法脫胎自美國總統艾森豪在 1954 年演說時發表的名言「緊急的事情不重要、重要的事情不緊急」，談到時間管理時就很有機會聽過。我是在高中末尾得知這套方法，生活中有時也拿來輔佐判斷，但卻沒有真正拿來當過產品功能排序的主力… 總之先說明方法要點，後面再補充。
艾森豪矩陣的四個象限
此矩陣依據事情「緊急程度」與「重要性」兩個維度劃分為四個象限：
- **又急又重要：**屬於高度優先的任務，通常涉及危機處理、緊急回應或迫在眉睫的時限，例如重大客訴處理、系統故障排除或客戶簡報準備。
- **重要，但不急：**通常代表這件事情對未來有所幫助，但不需立即處理，例如策略規劃、關係經營、專業成長等等。
- **急，但不重要：**這種事情多著，搞不好不用特別舉例… 總之是某些感覺好像急迫一定要做，但老實說對目標的貢獻極其有限的事。
- **不急也不重要：**無助於目標、也無急迫性。
一般來說，又急又重要的東西一定會立刻就去做，因為套用前一篇文章的概念這就是不做會死的事情；急但不重要的事情會建議丟給委任別人去做、而不急也不重要的事情則是不該做。
重要但不急的，就是要細細思量的事情。
艾森豪矩陣的優點
- 容易說明：超級知名的時間管理方法，很可能無論是不是產品經理，大部分的人都聽過
- 牌子老口碑好：在漫長的歷史中能夠廣為流傳還是有他的道理在，特別是這套方法其實有具體建議了委派、不做等等的行動，可以幫助你收斂一些想法
- 價值導向：鼓勵多放心思在重要但不急的事情上
那為什麼我本來沒想過要用來當主要判斷方式呢？
艾森豪矩陣（用在產品管理上）的缺點
- 跟 MoSCoW 一樣，這套方法本身不處理價值觀對齊，所以還是會遺留一個「重不重要誰說了算」的議題。
- 「急，但不重要」的事情在產品功能排序上其實沒有 1:1 的對應方式，畢竟我們要重新想一下「委派」在產品上是什麼意思。
- 同一類別裡的東西太多時，還是得用別的方式排序。
另一方面，後來我比較意識到資源的應用問題，而這類排序的手法都不考慮資源消耗問題（而是純粹的價值評估），因此就不會單純使用這個以及MoSCoW。
如果你要用艾森豪矩陣的話，這些想法給你參考
- 跟 MoSCoW 那篇的建議一樣，先跟團隊及糕層對齊產品目標，再用這個目標來考量。嚴格說起來每一種排序方式都應該要先考量當前的目標是什麼，且也需要上下對齊，不然就是個人想像而已了。
- 「又急又重要」的事情數量與週期本身應該視為一項警訊，也許代表先前有些該做的「重要但不急」沒考慮清楚，且急的事情也通常容易出錯。我相信我們應該要盡力把餘裕做出來處理「重要但不急」的事。
- 「重要但不急」的事情也許需要搭配別的框架，再拉一下順序。當然這邊也跟我對 MoSCoW 的建議一樣，要處理那塊時再排序也可以。
- 「急，但不重要」的事情，其實大概就是改用替代工具來處理需求（而不做進產品）或者 workaround。但當然 workaround 次數多的話，也許應該想想是不是真的那麼不重要。另一方面，這類急但是不重要的事情也許該考慮一下怎麼徹底消滅。
- 不要做任何一件不急又不重要的事。
其他這個系列的文，沒連結的就是還在寫/還在富奸：
我不時會在 LinkedIn 或 Facebook 分享些關於產品管理的看法/見聞/活動，另有讀書會跟線上諮詢，有興趣可以前往 https://www.bobchao.net
如果你覺得這篇還不錯的話，何不幫我按幾下掌聲，幫助演算法讓這篇飄遠一點，幫助其他跟你一樣的人？