-
1 # 小榮的日常
-
2 # 青青vlog
大家好,我是青青。選擇一款適合自己的,能夠提高工作效率的就好了。一般選用最簡單的Excel,需求池就是一個數據庫,一個存放各種需求的地方。
-
3 # 紅姐娛樂看點
作為產品經理,你每天都會面臨各種各樣的需求,面著源源不斷的需求,你會找個地方把它們整理並記錄下來。而需求池就像一個數據庫,俗話說,好記性不如爛筆頭,需求池記錄著不在本次開發範圍內的所有產品需求,避免一個好的需求、創意被無意中丟失。可見,需求池對產品經理的重要性。這篇文章主要是給產品新人一些引導,讓其能夠快速建立有效的產品需求池。
一、建立產品需求池的作用
建立產品需求池有什麼好處呢?產品經理每天都會面臨各種各樣的需求,僅憑大腦去記住並不是長久之計。因此,必須要有一個地方去記錄這些需求,避免遺漏。需求池記錄暫時無法消化的需求,是頭腦風暴和下一次版本迭代的源頭。
版本規劃並不是閉門造車,需求池為下一個版本提供了方向,結合需求池、產品目前狀況和市場情況進行下一次版本迭代。
二、如何建立自己的需求池
產品經理在工作中,一定要建立自己的需求池,遵守“寬進嚴出”的原則,保證開發的需求都是有助於產品發展的。如何進行需求池的有效管理,不同的產品經理都有不同的管理辦法。一般需求池的需求型別主要包括以下內容,如圖所示。
需求池管理需求池由哪些元素組成?
關於需求池的建立工具,沒必要追求那些華麗的工具,選擇一款適合自己的,能夠提高工作效率的就好了。一般採用最簡單的Excel,原因是簡單、易管理。我一直強調,需求池就是一個數據庫,一個存放各種需求的地方。聽起來很專業,其實一個表格就可以說清楚了。
1、序號:需求的標識,便於需求管理和索引。
2、需求型別:對需求進行分類,分為:功能改進、提升體驗、內部需求、新增功能、修復BUG、想法創意。
3、需求名稱:簡單描述需求,簡短清晰易區分。
4、所屬模組:一般寫產品的一級、二級類目。
6、需求描述:對該需求進行具體的描述,使用者在什麼場景下,為了實現什麼目標需要做什麼任務,從使用者、場景、目標、任務去具象化需求。
7、提交人:需求的提出人
8、提交時間:需求提出時間,也就是進入需求池的時間。
9、需求優先順序:一般情況下,透過四象限的辦法進行需求優先順序篩選,即:P0緊急重要、P1緊急不重要、P2不緊急重要、P3不緊急不重要。具體在設定優先順序時,我們要考慮到到需求的受眾大小、投入產出比及近期的產品目標。優先順序判斷的一些原則:
受眾大,開發成本小的優先做(P0);
受眾大,開發成本大的進行排期,以後做(P1);
受眾小,開發成本小的根據情況實時插入(P2);
受眾小,開發成本大的,不做(P3)。
10、需求狀態:需求隨著專案的進展,會出現不同的狀態標識,比如:待確定、需求評審中、待開發、開發中、已完成。
11、上線時間:需求實現後的上線時間。
三、總結
需求池對產品經理工作起到非常重要的作用,建立有限的需求池,可以讓你以後的工作更加順暢,對產品的迭代有了更清晰的方向。選擇適合自己的需求管理方法,建立自己的產品需求池,當你某一天對產品的迭代迷茫的時候,也許需求池會給你很大的啟發。
回覆列表
說在前面的話:上兩篇文章講了市場調研、競品分析,肯定收集了一堆的需求,那麼我們怎麼去分析這些需求了?從哪些維度去分析?接下來這篇文章主要是說一下我個人對做需求分析的一些方法和步驟。
需求分析是整個專案計劃階段的重要活動,也是軟體生存週期中的一個重要環節,該階段是分析系統在功能上需要“實現什麼”,而不是考慮如何去“實現”。
需求分析的目標是把使用者對待產品提出的“要求”或“需要”進行分析與整理,確認後形成描述完整、清晰與規範的文件,確定軟體需要實現哪些功能,完成哪些工作。
此外,軟體的一些非功能性需求(如:軟體效能、可靠性、響應時間、可擴充套件性等),軟體設計的約束條件,執行時與其他軟體的關係等也是軟體需求分析的目標。
上面這張基本就是講大道理的,接下來這張圖是我整篇文章的分析步驟:
第一步:整理需求池
在透過上面的各種需求的收集,會收集一堆的需求,俗稱需求池。在收集的過程中,記錄需求大部分都是先拿筆記本記錄,最後在彙總到電腦裡面,所以會很分散,這個時候需要一張表格來規範所有的需求,做成一個列表。
示例如下:
文件說明:
(1)需求分類:一般需求可以劃分為五類。
(2)場景描述:主要描述需求發生的場景。
(4)優先順序:這個地方我用的是我司的優先順序排列方式,P0最高、P4最低。這個地方可以靈活處理,換成自己公司的就可以了。
(5)備註:一般用於抒寫,不解決的原因。和如果解決需要注意什麼。
分析方法:需求分析自己分析需求的方法我沒有寫,因為網上有一堆講這種自我分析需求的方法。
深度丨從上帝視角審視產品需求(上)
深度丨從上帝視角審視產品需求(下)
其他說明:
一般產品都會分為使用者端與後臺,所以在做Excel表格的時候,需要分為兩個模組,分別列對應平臺的需求。這樣會讓各個平臺的需求清晰明瞭。開需求大會的時候,分平臺的評審需求。
第二步:需求大會
參會的人員:相關領導、專案經理、產品相關人士(產品汪、產品助理、產品專員)、研發leader、運營。
會議時長:2-4個小時。
會議記錄:產品經理。
會議說明:
(1)這種需求大會,會針對每一個需求進行探討,V1.0版本做與不做,所以會議時長一般會很長。產品經理需要對每一個討論過的需求標記優先順序,是否需要第一個版本實現做備註,延後處理的需求,需要標明延後原因等等。一般都是在我之前列表的需求池列表的後面做處理。
第三步:初稿需求整理
會議結束,產品經理需要做的事情,就是把需求池列表的需求進行過濾,把V1.0版本初步需要做的需求進行進行一個需求的整理,單獨做成V1.0需求列表。
我簡單做了一個需求列表的Excel的表格,僅供參考:
列表欄位:編號、所屬模組、子模組、需求描述、場景描述、優先順序、備註。
備註說明:分別把前端和後臺的需求分開列。這樣展示會更清晰明瞭。
第四步:V1.0需求確認會
彙總完所有的V1.0需求,又是產品經理主持會議的時候到了,這次的會議室確定上一次會議的確定下來的版本需求。
參會的人員:相關領導、專案經理、產品相關人士(產品汪、產品助理、產品專員)。
會議時長:1個小時左右。
會議記錄:產品經理。
會議說明:
第五步:最終需求表
有些公司需求的確認會,需要經過很多次的需求會議,才會確認下來。本文只是理想化的做了2次,但是不管經歷了幾次需求確認會,都會走到最終定下來的這一稿。
我簡單做了一個最終需求列表的一個Excel表格,表格如下:
列表欄位:編號、所屬模組、子模組、需求描述、場景描述、優先順序、產品負責人、完成時間、預計用時、對應開發人員、完成情況。
備註說明:
產品負責人欄位:有些公司一個產品是多個產品經理負責,所以需要寫上對面模組的產品負責人,這樣在後期開發的過程中,開發有問題可以直接找到對應模組的負責人。
完成時間一般都是在需求定下來的時候就可以大概定下來的。
預計用時、對應開發人員、完成情況。這些是在幫研發leader做的了,leader拿到表就可以開研發內部任務分配會議了。
題外話:研發leader拿到這個需求列表後,召開研發的會議,然後分配任務給對應的開發人員,就可以直接在頁面天對應的天數、開發人員了。
結尾
本篇文章講解了產品從彙總需求池到需求確認的整個過程,接下來的一篇文章,會全面講解我們在做0到1的產品需要輸出哪些產物。
相關閱讀
實戰第一步:市場調研
實戰第二步:如何做一份有針對性的競品分析
下一篇:【第四步】產品輸出,敬請期待