功能需求，不等於真正的需求

最近讀《馬斯克寶典》，對一句話特別有感：先質疑需求，再刪除、簡化，最後才自動化。

放到企業數位轉型，這句話其實很實際。

我們收到的，大多是「功能需求」

很多時候，產品單位收到的都是功能需求：

• 我要推薦功能。
• 我要篩選功能。
• 我要線上預約。
• 我要多一個欄位。

一開始做產品的時候，我會覺得這樣很好，需求清楚、範圍明確，排進開發就好。但做久了會發現：功能只是表象。真正需要被改變的，往往是背後的業務流程。

數位化，不等於解決問題

以健檢為例，表面上的問題可能是：怎麼讓客戶在線上選健檢項目？

最直覺的做法，是把原本的紙本方案、加選邏輯、服務流程全部搬到網路上。畫面做漂亮一點，選項分類清楚一點，好像就完成了數位轉型。

但這樣做，只是把複雜的流程「數位化」，並沒有真正解決問題。因為使用者真正的痛點不是：

「我不會點。」

而是：

「我根本不知道自己該選什麼。」

這兩個問題，完全不同。前者是介面問題，後者是決策問題。用解介面問題的方法，去解決策問題，做得再精緻都會卡住。

往前再問幾層業務問題

這時候，我們應該往前再問幾層：

• 為什麼客戶需要自己判斷？
• 哪些資訊其實不需要讓客戶理解？
• 哪些決策可以由資料、規則與 AI 先協助完成？
• 哪些流程只是因為過去的組織分工而存在，而不是因為客戶真的需要？

最後一個問題特別重要，也特別不好問。很多流程的形狀，反映的其實是公司內部怎麼分工，而不是客戶怎麼想事情。客戶不在乎這個環節歸哪個部門，他只想知道自己該怎麼選。

問到這裡，問題就從「要做什麼功能？」變成「這段業務，應該怎麼重新設計？」

AI 的價值，也在這裡

我越來越不認為 AI 的價值，是在既有流程上再加一個 AI 功能。真正有價值的是：利用 Data、Rules、AI，重新設計決策與流程。

順序應該是：

Business Problem → Process Redesign → Data / AI → Product Feature

而不是：

收到需求 → 開功能 → 上線 → 流程還是一樣複雜

這兩種做法，最後可能都有一套系統，但創造的價值完全不同。前者讓客戶少做一些判斷；後者讓客戶在一個更漂亮的畫面裡，做一樣多的判斷。

這也是馬斯克那句話的意思：在想自動化之前，先質疑這個需求本身。自動化一個不該存在的步驟，只是讓錯誤跑得更快。

看到需求單時多問一句

所以現在看到一張需求單，我們反而會多問一句：

這真的是一個功能需求？還是，我們只是還沒有重新設計這段業務流程？

這句話問出口，常常會讓會議變長。需求單位可能會覺得，我只是要一個功能，為什麼要談這麼多。我能理解這種感受，換作是我站在需求單位的位置，大概也會這樣想。手上的問題很急，誰都希望功能趕快上線。

但多花一場會議把問題問清楚，通常比上線三個月後才發現沒人用，便宜很多。

最後

真正的數位轉型，不是把需求做完，而是有能力回頭問：

這個需求，原本就應該存在嗎？