需求都排好優先順序了，但我們排的是對的問題嗎？

在排優先順序之前，先確認我們排的是對的問題。

上一篇談到，End-to-End 流程一旦攤開，問題常常不是太少，而是突然變得很多。這時候大家很自然的下一步，就是排優先順序。

先說清楚：排序這件事，我沒有要挑戰它。

在大型顧問專案裡，很多時候我們是在既定 Scope 之下，協助客戶把已經提出的需求排序與落地。用 Business Impact、Feasibility、Implementation Effort、Time to Value、Risk 這些指標建一張 Matrix——這個方法很重要，我現在也仍然會使用。它回答的是一個明確的問題：

「這些既有需求，先做哪一個？」

只是現在自己直接跟經營者討論時，我開始想把工作的起點再往前移一點。在把需求放進 Matrix 之前，多問一個問題：

我們現在放進來排序的，真的是最值得解的問題嗎？

這兩件事看起來像同一件事，其實是兩層。Prioritization 回答「已經提出的需求，先做哪一個」；在它之前，還有一層 Problem Validation——或者說 Business Impact Validation——回答的是「這件事為什麼值得做」。

以前，我可能把 Business Impact 當成 Matrix 裡的一個欄位，打個高中低就往下走。現在我更想花時間跟客戶一起討論：這個 Business Impact，到底是怎麼被定義出來的？

因為每個人口中的「高影響」，可能是完全不同層次的事。對使用者，是「我每天少做兩小時」。對部門主管，是「這個月少一個 backlog」。對 IT，是「這個很容易做」。對經營者，真正的問題是：「這會不會影響毛利、現金、交期、庫存，或決策的速度？」每一種都叫重要，但層次完全不同。不要只把 Business Impact 當成一個欄位；Business Impact 本身，也值得被驗證。

所以在進 Matrix 之前，我現在會先走一條追問鏈：企業真正想改善的經營成果是什麼？哪些 End-to-End 流程真正影響這個成果？目前被提出的痛點與需求，哪些真的落在這條線上？如果解掉，Business Outcome 真的會不同嗎？這些問題走完，最後才進 Impact × Feasibility / Effort 的排序——這時候排出來的順序，才排在對的問題上。

這不是否定過去的方法，而是角色與視角的演進：從在既定範圍內把需求做好，到跟經營者一起確認範圍本身。

我的一句話總結是：在排優先順序之前，先確認我們排的是對的問題。

不過，就算問題找對了、優先順序也排對了，專案仍然不一定推得動。因為接下來要遇到的，是人。這是下一篇的題目。