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