需求管理-需求池－第6堂【B2B2C產品經理PM的8堂必修課】

你在的團隊有這些問題嗎？

業務、營運、產品、研發的溝通，還停留在史前時代，靠「口耳相傳」嗎？
需求散落在各地，你的需求跟他的明明可以一次解決，但卻做了兩次！
做到一半，發現跟客戶要的不一樣？開發團隊都不知道自己在解決什麼問題！
做完發現東漏西漏的，做了新建功能，沒做編輯功能？
客戶說什麼就做什麽，做出來卻遭嫌棄？
說好的上線時間，怎麼又延遲了？每一次都這樣！
離職了，接手的人沒有東西可參考！？

做好「需求管理」可以解決以上問題

一、需求池是什麼？

需求池可以是一個資料庫，也可以是一張表，是產品經理PM用來管理與追蹤所有產品需求的唯一集中地，用於記錄、管理與監控所有產品需求的相關信息，包括合作商需求、C端用戶需求、B端商戶需求、市場需求、內部需求...等。

產品需求池最終的目的是：「確保產品需求準時準確地交付」。

二、為什麼需求池很重要？

主要原因是，需求來源多且雜。相較於To C或To B的產品團隊，對B2B2C產品來說，任何用到服務的，都是我們的客戶，因此如何管理眾多需求方的問題與需求，是一個非常大的挑戰。簡單看一下，需求方的來源有：

落實需求池管理的４大好處

良好產品規劃，提高競爭力：能迅速且持續地回應市場整體與商戶、用戶的需求，制定更精確的產品計畫與RoadMap，也可及時調整產品策略和功能，滿足不斷變化的需求。
提升團隊工作效率、降低風險：共同的需求池，提高團隊間的透明度和溝通，確保每人都了解需求背景和進度。且能提前預知開發情況，協調不同團隊之間的工作，有效分配資源，減少浪費、重工和延遲交付機率。降低風險對專案成功的影響，確保團隊按時完成有價值的功能和任務。
提高商戶（B端）、用戶（C端）滿意度：及時回應客戶的反饋和建議，事事有回覆。通過了解產品問題，做好版本規劃與更新，一次性解決，且於下次開發時提前避免。減少錯誤或不必要的功能開發，提升易用性。
組織資產累積：為組織累積經驗，減少人員入職、離職造成的銜接問題，在開發新產品、功能時，可以參考產品需求池裡的問題

三、怎麼建立與使用需求池？

3-1 需求池該建在哪裡呢？

需求池是一個工具，沒有一定的格式，有的公司用Jira, Asana，設定成一個專案，設定好一定的公式與條件，或是用Notion, Confluence 搭建的公司wiki裡，抑或是Google雲端的一個共享表單，只要能讓所有人知道要需求就只有一個表單，那裡就是需求池。以每個產品線或大產品去維護一個需求池。

3-2 誰會使用到需求池

需求池的負責人是該產品、系統的產品經理，不過，不全然是PM填寫這個表格，通常會被多個角色使用，比如：

產品經理：產品經理負責整個產品開發過程，包括收集、管理和優先處理需求。他們可能使用需求池來追蹤市場需求、客戶反饋和功能優先級，以便進行產品規劃和優化。
營運經理：營運經理負責軟體產品的日常運作和管理。他們可能使用需求池來安排資源、分配工作、追蹤進度和監控產品開發流程。
業務人員：業務可能在一線了解客戶需求後後，通過彙整集合後，可能由業務方通過一定流程來將需求放入產品需求池，也可能交由負責該業務部門的營運經理，統整後交給產品經理。
技術團隊：開發人員、設計師和測試人員等技術團隊成員可能使用需求池來了解開發任務、設計要求和測試需求。
客戶支援：客戶支援團隊可能使用需求池來追蹤客戶反饋、問題和需求，以提供更好的客戶支援服務。

3-3 什麼時候使用需求池？

如果軟體產品經理的職責在於「規劃好產品」、「推動產品開發」、「優化產品」。需求池的位置會放在「優化產品」裡，而產品經理對於需求池的關注度，常常是在於產品推出到市場後，正常來說，推出後需求池裡的需求佔PM的工作量會逐步減少。

只是在產品開發流程中的其中一環，所處位置詳見。

四、怎麼寫需求？

對於產品經理來說，需求池若以表格形式呈現的話會如下圖，其中可以分為五個模塊，分別為「需求描述」、「提出情況」、「方案概述」、「需求判斷」、「進度追蹤」，依照不同模塊下，又有不同的狀態，可以依照自己團隊、產品的屬性建立。

第１步：需求描述

需求模塊	系統-->一級功能-->二級功能-->三級功能
需求點	OO用戶，在ＯＯ場景，遇到ＯＯ問題，有ＯＯ需求
圖片	貼上相關圖片

＊注意事項：

重點在於名詞定義要一致，忌同義詞、縮寫
同模塊需求集中紀錄，忌按照創建時間記流水帳
除了要做什麼，盡量把為什麼要做記錄清楚，場景要還原現象
形成完整的句子，忌一個詞

第２步：提出情況

提出人	提出需求的源頭，如oo客戶
提出時間	提出需求的具體日期
追蹤人	將問題提交給產品經理的人，如OO營運

第３步：方案概述

需求類型	新增需求：現無相關功能、已有功能不包含該需求點優化需求：已有功能優化邏輯、交互、視覺等
是否解決	判定需求是否給予解決
解決方案	簡要描述實現功能思路
拒絕理由	技術實現難度、替代方案、客製化問題等

第４步：需求判斷

緊急程度	提出人的緊急度，可用P1~4劃分
重要程度	提出人認為的緊急度，可用P1~4劃分
優先程度	產品經理判定的優先程度，可用P1~4劃分

第５步：進度跟蹤

當前狀態	排期中、開發中、已上線
規劃版本	預計在哪個版本實現
計畫上線日期	預計上線日期，便於回覆客戶
實際上線日期	紀錄實際日期，便於做對比回顧
負責人	主要負責產品經理，涉及多人時，由一人為主要負責人