上一篇《產品開發的黃金圈理論 Why-How-What》提到產品開發的黃金圈，接下來我想列舉我在產品需求盤點時，曾犯下的幾個失誤，也作為未來的警惕，(1) 確認好需求才進規劃、(2) 確認好解方要有框架、(3) 確認好框架才進開發。
誰適合看這篇文章？
✔ 對於產品開發、產品規劃、產品管理、產品策略有興趣的朋友。一、確認好需求才進規劃
大標題這句話聽起來很簡單，但我回想一開始執行需求彙整時，很常犯的錯是「聽到對方提一個需求後，就急著想要先解決眼前這個，沒有好好聽完他所有的需求，以及排序優先級」。
導致我收到需求，開始自己規劃解方時，邊想邊覺得「這個需求 … 怎麼好像不怎麼痛 … 有一點是個人操作問題衍生的需求」。
（一）確認需求所需要的內在評估
因此我目前在收集需求時，都會先有幾個內在評估：
- 產品目標：此需求是否符合這季、這半年的產品開發目標？例如獲客功能、會員功能？
- 影響程度：此需求是否會影響到日常運作？例如有做可以提升營收？
- 影響人數：是提需求的人自己的痛點？還是公司內部營運單位都有的痛點？還是客戶、消費者曾抱怨過的痛點？
- 優先層級：若上述都確認完，接著則是確認時間點，這個功能是否有急迫性？或是單純許願優化？
（二）開始分析需求，初步規劃
收到需求，也確定要執行，接著則是進到規劃評估，像是：
- 確認此需求最終想解決的目標：需要不斷與需求人訪談，挖出背後動機，像是提高按鈕轉換、介面轉換率，而非只是 OO 功能、OO 介面、OO 按鈕的增加。
- 確認此需求期待的場景：一樣需要藉由使用者操作，確認他卡在哪一關，例如在 OO 介面會遲疑、，而非只是要跟別的競品一模一樣的介面。
在規劃時，我目前會採取的方式是：
- 多方參考：根據目標，參考其他類似產品是如何打造的，像是別人的網頁的按鈕觸發會有什麼回饋機制、廣告版位如何配置、站內搜尋的邏輯及搜尋後的呈現結果。
- 內部狀況：確認內部的開發史，了解過往的開發過程，是否真的有漏掉此需求還是有工程上的難處。
- 需求文件：開始撰寫產品開發需求文件，包含整理需求緣起、開發目標、影響層面、開發時程、功能示意、檢核機制等。
二、確認好解方要有框架
有了上述的需求，下一步需要先確認好解方，我之前曾犯的失誤是急著想要找工程師、產品經理討論，但討論到一半我才發現我還沒提出預期解方，只是把問題、需求丟給別人，導致需求情境越討論越複雜。
（一）開始規劃後，先提出假說
因此後來在撰寫產品開發需求文件時，我會先不斷提出自己的假說，像是「若按照這個流程、新增這個介面，似乎可以解決他的需求」。
根據假說不斷去思考會影響的範疇，例如：
- 是否會讓後臺管理起來很複雜，e.g.增加人力管理成本
- 除了解決需求，是否為衍生其他問題，e.g. 功能邏輯矛盾
- 此功能是一次做完，還是需要頻繁改動，e.g. 因應行銷活動調整程式碼
（二）假說都思考幾輪後，接著劃出初步框架
當上述的疑慮都確認過，接著可以進到初步的 wireframe（有些公司是 UX 設計師畫、有些是 PM 自己畫），包含：
- 功能的外觀顯示位置：前台、後台的位置
- 功能的細節操作設定：按鈕位置、數字位置、圖片位置
三、確認好框架才進開發
早期曾犯的錯是「還沒有框架」，就急著想跟工程師討論開發細節，導致工程師一臉茫然，要向我追問很多細節，非常沒有效率。
（一）進開發前，先再盤點一次需求文件
在準備請工程師動工時，會再仔細盤點一次文件，確認 (1) 目標、(2) 情境、(3) 畫面、(4) 限制，這四點都準備到。
- 目標：這次開發出來是為了解決什麼？
- 情境：這個需求方的使用情境是什麼？
- 畫面：這次需求方期待的畫面是什麼？
- 限制：操作上是否會有極端情境產生？
（二）需求盤點完，開發向工程師確認時程
後續則是交付需求文件，開始追蹤開發進度。
四、總結
這篇主要是記錄我的產品企劃經歷，屬於不成熟的職涯紀錄，也作為自己未來在往產品經理道路上的警惕。
如對這系列有興趣，也可以觀看：
