大廠產品專家一招教你管理需求

0 評論 5025 瀏覽 32 收藏 11 分鐘

需求繁多,頻繁迭代,管理困難?大廠產品學姐將在這篇文章為你介紹需求池的管理方法,包括需求收集、需求池填寫和維護等,幫你一招搞定需求管理。推薦對產品、產品運營、需求分析等感興趣的童鞋閱讀。

回想學姐十幾年前剛入職的那會兒,第一個月折騰了半天,才做了一個簡單的小需求,從需求的調研到最后上線,我基本就跟這么一個需求,其余的時間就打打雜咯,也不需要做什么“需求管理”~

隨著自己的快速成長,半年后我就獨立負責一個App了,對口研發也有好幾十號,這時候需求就日益增多,每個迭代(當時我們是兩周一迭代)都會有大大小小十多個新增的需求,加上還沒做完的需求,或者需要繼續優化的需求……

同時還要應付其他部門的同事、老板們甩各種需求過來,這時候沒有一個比較好的工具去管理,就有點手忙腳亂了。需求管理是每個產品、運營在職業生涯上必須要掌握的技能,經驗當然也很重要,不過一個好的工具,可以讓大家上手更快,這篇文章學姐就介紹一個比較好的需求管理工具——需求池。

01 什么叫需求池?

剛才學姐也說了,隨著需求的增多,我們需要用一個工具去管理它們,我們形象地管這個工具叫做——需求池,英語叫做backlog。學姐覺得這個翻譯還挺傳神,因為需求就像水一樣,在這個池子里進進出出~

需求池的形式一般是一個在線的表格,里面記錄著每個需求的內容和狀態,你和其他相關同事可以隨時編輯、查看各需求的情況。這個迭代(或者版本)進入尾聲的時候,我們可以打開這個這個表格,盤一盤下個迭代或者下個版本我們要上哪些需求,對它們進行細化;等到需求評審會的時候,我們又可以對著需求池,逐一講解我們的需求;啟動研發后,我們又可以通過需求池來追蹤每個需求的狀態。

除了以上這些場景,我們還可以把需求池分享給其他部門的同事查看,以便他們在對我們的工作、資源飽和度產生質疑的時候,把信息共享(甩)給他們。另外,在平時做周報、月報的時候,我們對需求池稍加美化(當然是指格式美化不是指粉飾太平),就可以把最近的工作貼進去啦~這樣可以避免很多重復的工作量。

02 收集需求

在講需求池怎么用之前,學姐先來簡單介紹下一般的需求是怎么產生的,畢竟要先有需求,我們才能去管理。需求一般有以下幾種來源:

  • 調研分析:通過問卷、訪談、查閱行業報告等形式,總結歸納出用戶的痛點并解決;
  • 體驗產品:在體驗現有產品的過程中,發現現有流程的問題并改善;
  • 競品分析:通過體驗競品,發現自身產品的不足并優化;
  • 業務方、合作部門:如運營、銷售、法務等基于他們對產品的理解,給出建議;
  • 老板:這就不解釋了吧,懂得都懂……

總之只要有了idea,我們就可以把它列到我們的需求池了。

03 如何填寫需求池

有了想法之后,怎么樣結構化地去管理需求呢?學姐這就來分享一個比較好的模版~

需求池一般由兩部分組成,一是需求內容,包括名稱、價值、優先級、提出人、文檔等;二是需求狀態,包括迭代、進度、人員、發布時間等。下面詳細講解每一項該如何填寫。

1. 需求內容

名稱:

每個需求都要有一個清晰的名稱——雖然聽上去像是廢話,但是學姐在看簡歷的時候,經??吹揭恍懙貌惶玫捻椖棵Q,看了半天也不知道到底在做了啥,導致學姐面試的時候經常熱衷于幫童鞋們改項目名字~

那么需求名稱要怎么寫得好呢?首先,在需求還不太明確、只有一個idea的時候,可以用需求的目的、需求的價值去代替,比如“搜索體驗優化”。隨著需求逐漸明朗,盡量用比較清晰、可以確切描述功能的名字,這樣不容易混淆,比如“搜索列表頁新增篩選器”就比“搜索列表頁優化”更明確。

價值:

這個也是學姐的老生常談啦,之前寫文章介紹過,這里就不詳細張開了,我們需要用一兩句話來描述需求的價值。我們可以用“用戶痛點+論據+解決方案”的句式,也可以用“幫助用戶+論據+解決方案”的句式,下面是兩個例子:

  • 目前的商品詳情頁相比競品,展示的信息少,用戶做購買決策難(用戶痛點),轉化率僅40%,遠低于競品(論據),因此需要對商品詳情頁進行改版(解決方案)。
  • 調研顯示50%的客戶有在平臺投放廣告的需求(論據),為了幫助這些客戶獲取更多目標用戶(幫助用戶),我們會通過算法匹配在合適的列表頁展示廣告位(解決方案)。

優先級:

我們要根據需求的價值,得出需求的優先級。優先級怎么排,學姐之前也講過一個簡單的公式:核心用戶的核心需求&核心用戶的非核心需求&非核心用戶的核心需求;:

需求的優先級我們一般用P00、P01、P1、P2表示,這樣比較有層次,數字越小優先級越高。核心用戶的核心需求一般是P00或者P01,核心用戶的非核心需求是P1,非核心用戶的核心需求是P2。當然,具體的數字其實不重要,重要的是要在某個迭代里,所有的需求一定要有相對的優先級排序。

提出人:

在需求收集這一部分學姐也提到了不同的需求來源,如果需求的提出人是其他部門的,我們應該把TA的名字填入,這樣需求有任何進展,我們可以及時告知。

文檔、交互、視覺等:

這就不贅述了,需求文檔怎么寫之前學姐也教過,大家貼上鏈接就行了。在需求進入評審之前,如果還沒有完整的文檔,至少也要有需求描述+交互設計稿,在需求開發之前,文檔、交互和視覺缺一不可。

2. 需求狀態

迭代:

對于已經明確有排期的需求,我們把迭代號填寫進去,這樣我們只要篩選一下就可以看到每個迭代中有哪些需求了,如果有些童鞋走的不是敏捷開發,那么填寫版本號也是一樣的。

進度:

排入迭代的需求,我們需要對其標注研發的進度,用未開始、已開始(未完成)、已完成來表示,如果有必要的也可以把開發了百分之多少填寫進去~

人員:

一旦需求開始研發,我們就可以把相關人員給填上了,比如研發寫一欄、測試寫一欄,有必要的也可以把視覺、交互設計師也單獨寫上,這樣做視覺還原的時候方便找人。

發布時間/版本:

在需求進入迭代之后就應該填寫,這樣方便追蹤需求的進度。

04 如何維護需求池

首先,我們要明確需求池應該由哪些角色來維護。需求內容(需求名稱、價值、提出人、優先級、文檔、交互&視覺)這一部分,由產品經理本人填寫;需求狀態(迭代、進度、人員、發布時間)這一部分,一般由項目管理或者研發負責人填寫,當然如果是比較小的團隊,也可以產品經理自己填寫。

其次,我們需要及時更新需求池。除了把新增的需求填入之外,當需求有進展的時,我們要及時更新需求池。比如在需求逐漸明朗,有了需求文檔、設計稿的時候我們要及時更新鏈接;比如需求排入了某個迭代,開始開發的時要及時更新需求狀態和上線時間;比如需求的優先級產生變化,我們也要及時調整,甚至刪除一些分析下來覺得不靠譜的需求。

最后,我們要時不時看一下需求池,畢竟這是記錄我們靈感的地方。看一下自己還有哪些idea沒有被實現,趕緊把需求文檔補起來;也可以回首一下自己這個月完成了多少個需求,獲得滿滿的成就感~當然,隨著互聯網行業的發展,現在市面上有很多完善的需求管理工具,比如Ones、Jira、TAPD等等。

專欄作家

海貝學姐,公眾號:海貝學姐,人人都是產品經理專欄作家。十年大廠產品經驗,精通產品方法論和產品知識。

本文原創發布于人人都是產品經理,未經許可,禁止轉載。

題圖來自Unsplash,基于 CC0 協議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!