top of page
  • 作家相片LeonLin
    • 1月17日
    • 已讀 4 分鐘

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

已更新：1月17日




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


  1. 業務、營運、產品、研發的溝通，還停留在史前時代，靠「口耳相傳」嗎？

  2. 需求散落在各地，你的需求跟他的明明可以一次解決，但卻做了兩次！

  3. 做到一半，發現跟客戶要的不一樣？開發團隊都不知道自己在解決什麼問題！

  4. 做完發現東漏西漏的，做了新建功能，沒做編輯功能？

  5. 客戶說什麼就做什麽，做出來卻遭嫌棄？

  6. 說好的上線時間，怎麼又延遲了？每一次都這樣！

  7. 離職了，接手的人沒有東西可參考！？



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



 


一、需求池是什麼？


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


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



 

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


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




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


  1. 良好產品規劃，提高競爭力：能迅速且持續地回應市場整體與商戶、用戶的需求，制定更精確的產品計畫與RoadMap，也可及時調整產品策略和功能，滿足不斷變化的需求。

  2. 提升團隊工作效率、降低風險：共同的需求池，提高團隊間的透明度和溝通，確保每人都了解需求背景和進度。且能提前預知開發情況，協調不同團隊之間的工作，有效分配資源，減少浪費、重工和延遲交付機率。降低風險對專案成功的影響，確保團隊按時完成有價值的功能和任務。

  3. 提高商戶（B端）、用戶（C端）滿意度：及時回應客戶的反饋和建議，事事有回覆。通過了解產品問題，做好版本規劃與更新，一次性解決，且於下次開發時提前避免。減少錯誤或不必要的功能開發，提升易用性。

  4. 組織資產累積：為組織累積經驗，減少人員入職、離職造成的銜接問題，在開發新產品、功能時，可以參考產品需求池裡的問題

 

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


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

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


3-2 誰會使用到需求池

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


  1. 產品經理：產品經理負責整個產品開發過程，包括收集、管理和優先處理需求。他們可能使用需求池來追蹤市場需求、客戶反饋和功能優先級，以便進行產品規劃和優化。

  2. 營運經理：營運經理負責軟體產品的日常運作和管理。他們可能使用需求池來安排資源、分配工作、追蹤進度和監控產品開發流程。

  3. 業務人員：業務可能在一線了解客戶需求後後，通過彙整集合後，可能由業務方通過一定流程來將需求放入產品需求池，也可能交由負責該業務部門的營運經理，統整後交給產品經理。

  4. 技術團隊：開發人員、設計師和測試人員等技術團隊成員可能使用需求池來了解開發任務、設計要求和測試需求。

  5. 客戶支援：客戶支援團隊可能使用需求池來追蹤客戶反饋、問題和需求，以提供更好的客戶支援服務。



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


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

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


 

四、怎麼寫需求？


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


第１步：需求描述

需求模塊

系統-->一級功能-->二級功能-->三級功能

需求點

OO用戶，在ＯＯ場景，遇到ＯＯ問題，有ＯＯ需求

圖片

貼上相關圖片


＊注意事項：

  1. 重點在於名詞定義要一致，忌同義詞、縮寫

  2. 同模塊需求集中紀錄，忌按照創建時間記流水帳

  3. 除了要做什麼，盡量把為什麼要做記錄清楚，場景要還原現象

  4. 形成完整的句子，忌一個詞

第２步：提出情況

提出人

提出需求的源頭，如oo客戶

提出時間

提出需求的具體日期

追蹤人

將問題提交給產品經理的人，如OO營運

第３步：方案概述

需求類型

新增需求：現無相關功能、已有功能不包含該需求點優化需求：已有功能優化邏輯、交互、視覺等

是否解決

判定需求是否給予解決

解決方案

簡要描述實現功能思路

拒絕理由

技術實現難度、替代方案、客製化問題等


第４步：需求判斷

緊急程度

提出人的緊急度，可用P1~4劃分

重要程度

提出人認為的緊急度，可用P1~4劃分

優先程度

產品經理判定的優先程度，可用P1~4劃分

第５步：進度跟蹤

當前狀態

排期中、開發中、已上線

規劃版本

預計在哪個版本實現

計畫上線日期

預計上線日期，便於回覆客戶

實際上線日期

紀錄實際日期，便於做對比回顧

負責人

主要負責產品經理，涉及多人時，由一人為主要負責人

 

五、如何管理需求池？


Comments

bottom of page