以產品經理的日常工作，常會收到不同部門的各種需求，像是功能優化、Bug 修復、文案調整，這些「需求」也可以說是對產品的「要求」，因為需求方通常僅根據自己的角度傳遞想法，但產品往往需要綜合多方使用者的描述，將這些「要求」轉化為通用、或是最有價值的需求。
這篇會從 5 個面向探討產品經理如何有效地評估需求：
- 需求的資訊充足性與明確性
- 需求的必要性與商業價值
- 需求與解決方案的關聯性
- 技術可行性與成本評估
- 需求實現的長遠影響
一、需求的資訊充足性與明確性
⠀⠀
當接收到一個需求時，產品經理首先要確保獲得了足夠的背景資訊，通常要收集到以下幾個要素：
- 現況問題：闡述使用者在操作上遇到的困難。
- 預期解方：使用者想透過什麼方式達到目標（雖然需求方不一定能提供完整的解決方案，但他們的初步想法可以作為參考）。
- 預期效果：使用者操作後，可以解決什麼問題、帶來什麼好處。
這些資訊能幫助產品經理寫出一個初步的使用者故事（User story），典型的格式為：
「作為 {某種使用者}，我想要 {做到某件事}，這樣我就可以 {達到什麼目標}。」
例如：
- 作為 {數位行銷人員}，我想要 {在系統後台設定滿額折扣的優惠券}，這樣我就可以 {在特定行銷檔期吸引更多人來官網下單}。
- 作為 {業務開發人員}，我想要 {紀錄聯繫過的客戶名單}，這樣我就可以 {每天追蹤客戶聯繫狀況和簽約進度}。
- 作為 {官網購物的消費者}，我想要 {結帳時知道我有多少紅利點數和優惠券可使用}，這樣我就可以 {在結帳當下進行折抵}。
上面這個公式看似簡短，但卻是需求開發最基本的元素，若無法明確講出這句話，通常在後續撰寫更詳細的功能需求文件時，也會卡關。
二、需求的必要性與商業價值
⠀⠀
獲得充分資訊後，下一步是評估需求的必要性和商業價值，這個階段會考慮以下幾點：
- 區分必要 (must-have) 與想要 (nice-to-have)：評估如果不實現這個需求會造成什麼影響，例如「客戶需要有這個功能才願意簽約」、「消費者因為此問題導致無法順利下單」。
- 商業價值與目標：分析實現這個需求能為公司帶來什麼價值，有些功能可以協助業務簽下潛在客戶，有些功能可以協助客戶經理安撫客戶對功能不滿的情緒，有些功能則可以解決消費者頻繁客訴的問題。
- 數據支持：有些產品會有各方數據支持開發，這時可以鼓勵需求方提供數據，像是如用戶每週抱怨數、結帳失敗率、頁面跳出率、Timeout 次數等，有數據支持的需求通常更容易獲得優先處理。
會需要確認必要性是因為在產品經理的日常工作，很常會被問到：「功能要改的地方這麼多，為什麼 A 需求要現在做？有什麼很緊急的原因嗎？」
這時就要準備好一套說詞，跟各方主管說明「A 需求現在要先做的原因，B 需求要後做的原因，根據什麼判斷因此這樣排序」。
三、需求與解決方案的關聯性
⠀⠀
確認完需求的必要性和價值後，接下來要評估提出的解決方案是否真正能解決問題，會需要確認：
- 避免直接採納需求方的解決方案：產品通常會有多方使用角色，若只採那一方的建議，也可能會導致其他人使用不順暢。
- 深入分析問題根源：要確認是使用者個人問題，還是每種使用者都會遇到一樣的狀況，例如用戶沒看到入口、用戶不知道這是可點擊的等。
- 跨團隊討論：與設計師、工程師討論可能的解決方案，確認是前端可解決的還是後端。
在工作中，我們都會被要求盡量避免「Jump to Conclusions 太早下定論」，要先確認好「你想解決什麼問題」，再來討論「要用什麼方式解決」。
因此就算需求方已經提出他期望的解決方案，身為產品經理仍需要保持開放、保持好奇去思考有沒有其他解法。
四、技術可行性與成本評估
⠀⠀
在確定解決方案後，接下來會仔細評估技術可行性，包含：
- 技術難度：有時方案是產品經理和業務或其他利害關係人討論出來的，這時就要盡快與工程團隊討論實現難度，確認是否涉及新技術、是否需要大幅度修改現有系統。
- 時間成本：若技術可行，則要評估完成這個需求需要多長時間，若有多種方案但差異不大，通常會優先考慮開發時間較短的需求。
- 人力資源：時間評估完，接著要評估團隊人力，是否有足夠的前端工程師、後端工程師、測試人員來一起完成，需不需要借人。
- 分階段實現的可能性：針對較大的需求，也可以考慮是否分階段交付，1 月先上 A 功能，2 月再補 B 功能。
⠀⠀
一剛開始我會有點困惑「到底要先找工程師確認需求？還是確認需求再找工程師？」，後來發現幾乎要併行進行，通常我的順序是：
- 先自己確認好預期的幾個方向
- 和工程師確認技術上可不可行、各自要多少開發時間
- 再和利害關係人提案
- 調整好方向，再和工程師確認最終開發時間
- 再和利害關係人定案
順利的話通常 2-3 輪就可以定案。
五、需求實現的長遠影響
⠀⠀
技術面也確認完之後，產品經理最後要考慮的就是長期影響，包括：
- 技術債務：評估所選的方案是否是短解，是否會造成技術債務，是否未來還要再改一次。
- 產品一致性：確認新功能的操作路徑、介面文字描述方式是否與其他介面的格式一致。
- 可擴展性：評估解決方案是否具有良好的可擴展性，未來若客戶想要加需求，是否可以再迭代。
- 維護成本：新功能上線後是否需要長期維護或壓資料。
結論
⠀⠀
需求評估是產品經理幾乎每天都會遇到的事，也幾乎一定會經歷過 (1) 蒐集需求資訊、(2) 確認需求必要性、(3) 確認解決方案、(4) 確認技術可行、(5) 確認長遠影響。
在這個過程以我的經歷不會一次到位，一開始可能在定義需求就會花好幾次開會，但慢慢地就可以培養敏銳度、開始能知道需求方想要什麼、系統可以做到什麼。
如對這系列文章興趣可以再觀看：
非常謝謝你的閱讀！上述單純以我的職場生活來整理，未能涵蓋所有案例。
如果文章有一點啟發或幫助，可以留言或來信讓我知道 👏
．撰寫於：2024/08/24 (六)
