起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識 搭訕是產品經理的基本功，需求管理也是?。ㄏ拢?/h2>
接著《搭訕是產品經理的基本功，需求管理也是！（中）》來繼續講需求管理，當然，這篇是完結篇。
之前我們已經通過需求分析和篩選，評定了需求的優先級，這時候就應該把這些整理好的需求，通過一個表格給呈現出來，功能需求列表Feature List就是這樣一個承載器。
輸出功能需求列表
什么是功能需求列表？顧名思義，就是把需求分析、篩選和評定優先級之后的結果，以產品功能的形式展現出來，再用列表的方式將其呈現。這是需求分析之后，提出解決方案的第一步。
功能需求列表的價值，一是在于幫助產品經理自己理清思路，二是在于幫助項目團隊的其它成員了解產品功能需求，好讓他們提前做好相關準備。
我們來看一下功能需求列表大致包含哪些內容：
- 模塊：一般來說，每個模塊下分3~6個子模塊是合理的，否則要考慮重新劃分。
- 子模塊：也就是一級模塊的二級分類，這里就已經涉及到產品架構的梳理了（但我們這里只是大致地梳理一下，后期在產品設計的下一個環節“搭框架”會進一步調整）。
- 功能：要給用戶提供什么功能，給這個功能起個名字。
- 功能描述：這個功能具體包含哪些操作，可以描述的具體一些，如支持用戶填寫基本信息可自由創建課程，進入課程空間就可對課程進行編輯和管理，還可發布、刪除課程等。
- 用戶價值描述：也就是可以給用戶提供什么價值。
- 需求優先級：這塊是整個Feature List工作中核心的部分，判斷的準確直接影響著將來產品的方向，我們只需要將我們之前評定的需求優先級照抄過來就好。
- 開發量：一般由研發部門的項目經理或者開發來確定。
- 投入產出比：簡單來說，就是商業價值除以開發工作量（或開發難度），當然每個團隊可以找出一個合適自己產品需求ROI的計算方法。
- 備注：覺得需要強調的，比較特殊的東西。
上圖是功能需求列表的一部分，當然現在也有越來越多的產品經理直接通過腦圖軟件來進行功能需求的梳理，然后通過腦圖軟件自帶的標注、附件、筆記、優先級排序等功能進行說明，比如下圖這樣的：
形式其實并不是那么重要，重要的是團隊成員能夠通過你的文檔更加清楚地了解產品的功能需求，也便于產品經理和團隊成員進行溝通。有了這份功能需求列表，我們就可以召集團隊相關成員進行一次需求評審會議了。
參加需求評審會議的可以有產品經理、老板/領導、運營以及市場相關人員、開發主管、測試經理等。為了保證需求評審能夠順利進行，最好提前做好相關的準備，產品經理要能夠講清楚需求的來源，為什么要做這個需求，做這個需求有什么意義，這個需求需要哪些功能配合，同類競品是否有該功能需求，為什么這個需求的優先級比較高……
整個需求評審的過程，考驗了產品經理對需求的熟悉程度以及對需求的判斷能力。同時，參與評審的人也將會對你提出的需求提出自己的看法，是否同意該需求，并且會提出同意或者不同意該需求的理由。需求評審是多人圍繞已經收集到的需求進行評審的過程，通過集合大家的智慧，能夠避免一個人閉門造車拍腦袋進行決策的局限。
如果時間比較充足，有些產品經理在需求評審會議上還會展示產品低保真原型，用來輔助說明，讓大家更加理解這個需求以及需求以后會是怎樣的樣子，這樣也能夠讓自己在講解需求的時候更加有依有據，避免錯過一些有用的需求。當然，我們這里只是第一次需求評審，到了后期產品原型乃至ui設計稿全部定稿的時候，依然需要進行產品的需求評審。
如何管理需求——需求池
之前就已經說過，需求是每個產品經理日常工作都離不開的一部分，貫穿著產品的整個生命周期。所以，如何管理需求，就成為所有產品經理必備的一項技能了。
在這里要給大家介紹一下需求池這個東西。
什么是需求池？
嗯，你可以把它類比為一個需求的收集器。需求池其實就是存放跟產品有關的未來可能會做的功能點的聚集地，然后在規劃新版本的時候，從池子里根據“輕重緩急”和“優先級”來篩選出幾個需求，排一排、整一整，弄成一個新的版本項目計劃。
需求池工具有很多，比如Project、Execl、MindManager等等都可以作為需求池管理工具，你也可以使用一些團隊協作軟件（如tower、tita、明道、teambition等）里面的項目管理功能來做需求池工具。
一般來說，我會將需求池按產品的功能模塊來進行劃分，這樣所有關于產品功能的需求都會被歸類到相應的產品模塊里。當然，這個需求池里還會包含來自運營及其它部門的需求。我們要做的就是告訴這些需求提出者，他們的需求我們都重視了，已經放到了需求池當中，但是是否安排開發需要根據所有需求進行“輕重緩急”和“優先級”的權重比較才能決定。我們需要定期去審核和分析這些需求，是做還是不做、要做的話是什么時候做？
對需求池的建議有兩點：
1、不必考慮能不能做或者是做了沒用什么的這樣的限制，先不必設置偽命題，只要是覺得OK的，都可以先列出來，在產品生命周期管理中，靠譜的、不靠譜的、緊急的、不緊急的；
2、需求池需要產品經理經常去整理，不然就失去了需求池本身的意義，如果你不去整理，不論是市場環境，用戶行為都有可能發生變化，任何一個產品都是變化很快的，這個時間段的需求有可能過一段時間就失去意義了。這個整理其實就是復原了一次需求的分析和篩選過程，同時還要去進行需求的優先級定義，每一次安排產品版本計劃的時候都要重新審視一遍需求。
總結
需求管理是一個完整的閉環過程，同時也貫穿著產品經理工作的每一天，比如：
1、我們是不是每天都要去思考這個需求是否需要去做？這個需求到底重要不重要，緊急不緊急；
2、我們是不是經常都要去用工具把需求給做出來，用visio這樣的流程圖工具去梳理業務流程，用axure這樣的原型工具去設計產品原型，做的同時還得思考這個功能需求究竟放在產品的哪個功能模塊合適；
3、我們是不是每天都要去和各種人溝通需求，和設計師溝通需求，和前端工程師溝通需求，和后臺開發溝通需求，還要和測試、市場、運營、銷售等溝通需求。同時，你還要和用戶談需求，讓用戶了解和認識你的產品；
不得不說，要做好產品經理真不是一件容易的事情。
ps：限于篇幅，產品設計需求描述這部分分為上、中、下三篇文章來講，如對我的文章有更多想法和意見，歡迎關注我的公眾號找我交流。
相關閱讀：
作者：壹百度（微信公眾號：倒退集），在線教育企業服務領域產品經理，創業公司Team Leader。常常自詡是文藝青年和極客青年的結合體，在宅與不宅之間可以自由切換，曾主導多款重量級產品的產品策劃和設計工作。
本文由 @壹百度 原創發布于人人都是產品經理。未經許可，禁止轉載。
更多精彩內容，請關注人人都是產品經理微信公眾號或下載App
接著《搭訕是產品經理的基本功，需求管理也是！（中）》來繼續講需求管理，當然，這篇是完結篇。
之前我們已經通過需求分析和篩選，評定了需求的優先級，這時候就應該把這些整理好的需求，通過一個表格給呈現出來，功能需求列表Feature List就是這樣一個承載器。
輸出功能需求列表
什么是功能需求列表？顧名思義，就是把需求分析、篩選和評定優先級之后的結果，以產品功能的形式展現出來，再用列表的方式將其呈現。這是需求分析之后，提出解決方案的第一步。
功能需求列表的價值，一是在于幫助產品經理自己理清思路，二是在于幫助項目團隊的其它成員了解產品功能需求，好讓他們提前做好相關準備。
我們來看一下功能需求列表大致包含哪些內容：
- 模塊：一般來說，每個模塊下分3~6個子模塊是合理的，否則要考慮重新劃分。
- 子模塊：也就是一級模塊的二級分類，這里就已經涉及到產品架構的梳理了（但我們這里只是大致地梳理一下，后期在產品設計的下一個環節“搭框架”會進一步調整）。
- 功能：要給用戶提供什么功能，給這個功能起個名字。
- 功能描述：這個功能具體包含哪些操作，可以描述的具體一些，如支持用戶填寫基本信息可自由創建課程，進入課程空間就可對課程進行編輯和管理，還可發布、刪除課程等。
- 用戶價值描述：也就是可以給用戶提供什么價值。
- 需求優先級：這塊是整個Feature List工作中核心的部分，判斷的準確直接影響著將來產品的方向，我們只需要將我們之前評定的需求優先級照抄過來就好。
- 開發量：一般由研發部門的項目經理或者開發來確定。
- 投入產出比：簡單來說，就是商業價值除以開發工作量（或開發難度），當然每個團隊可以找出一個合適自己產品需求ROI的計算方法。
- 備注：覺得需要強調的，比較特殊的東西。
上圖是功能需求列表的一部分，當然現在也有越來越多的產品經理直接通過腦圖軟件來進行功能需求的梳理，然后通過腦圖軟件自帶的標注、附件、筆記、優先級排序等功能進行說明，比如下圖這樣的：
形式其實并不是那么重要，重要的是團隊成員能夠通過你的文檔更加清楚地了解產品的功能需求，也便于產品經理和團隊成員進行溝通。有了這份功能需求列表，我們就可以召集團隊相關成員進行一次需求評審會議了。
參加需求評審會議的可以有產品經理、老板/領導、運營以及市場相關人員、開發主管、測試經理等。為了保證需求評審能夠順利進行，最好提前做好相關的準備，產品經理要能夠講清楚需求的來源，為什么要做這個需求，做這個需求有什么意義，這個需求需要哪些功能配合，同類競品是否有該功能需求，為什么這個需求的優先級比較高……
整個需求評審的過程，考驗了產品經理對需求的熟悉程度以及對需求的判斷能力。同時，參與評審的人也將會對你提出的需求提出自己的看法，是否同意該需求，并且會提出同意或者不同意該需求的理由。需求評審是多人圍繞已經收集到的需求進行評審的過程，通過集合大家的智慧，能夠避免一個人閉門造車拍腦袋進行決策的局限。
如果時間比較充足，有些產品經理在需求評審會議上還會展示產品低保真原型，用來輔助說明，讓大家更加理解這個需求以及需求以后會是怎樣的樣子，這樣也能夠讓自己在講解需求的時候更加有依有據，避免錯過一些有用的需求。當然，我們這里只是第一次需求評審，到了后期產品原型乃至ui設計稿全部定稿的時候，依然需要進行產品的需求評審。
如何管理需求——需求池
之前就已經說過，需求是每個產品經理日常工作都離不開的一部分，貫穿著產品的整個生命周期。所以，如何管理需求，就成為所有產品經理必備的一項技能了。
在這里要給大家介紹一下需求池這個東西。
什么是需求池？
嗯，你可以把它類比為一個需求的收集器。需求池其實就是存放跟產品有關的未來可能會做的功能點的聚集地，然后在規劃新版本的時候，從池子里根據“輕重緩急”和“優先級”來篩選出幾個需求，排一排、整一整，弄成一個新的版本項目計劃。
需求池工具有很多，比如Project、Execl、MindManager等等都可以作為需求池管理工具，你也可以使用一些團隊協作軟件（如tower、tita、明道、teambition等）里面的項目管理功能來做需求池工具。
一般來說，我會將需求池按產品的功能模塊來進行劃分，這樣所有關于產品功能的需求都會被歸類到相應的產品模塊里。當然，這個需求池里還會包含來自運營及其它部門的需求。我們要做的就是告訴這些需求提出者，他們的需求我們都重視了，已經放到了需求池當中，但是是否安排開發需要根據所有需求進行“輕重緩急”和“優先級”的權重比較才能決定。我們需要定期去審核和分析這些需求，是做還是不做、要做的話是什么時候做？
對需求池的建議有兩點：
1、不必考慮能不能做或者是做了沒用什么的這樣的限制，先不必設置偽命題，只要是覺得OK的，都可以先列出來，在產品生命周期管理中，靠譜的、不靠譜的、緊急的、不緊急的；
2、需求池需要產品經理經常去整理，不然就失去了需求池本身的意義，如果你不去整理，不論是市場環境，用戶行為都有可能發生變化，任何一個產品都是變化很快的，這個時間段的需求有可能過一段時間就失去意義了。這個整理其實就是復原了一次需求的分析和篩選過程，同時還要去進行需求的優先級定義，每一次安排產品版本計劃的時候都要重新審視一遍需求。
總結
需求管理是一個完整的閉環過程，同時也貫穿著產品經理工作的每一天，比如：
1、我們是不是每天都要去思考這個需求是否需要去做？這個需求到底重要不重要，緊急不緊急；
2、我們是不是經常都要去用工具把需求給做出來，用visio這樣的流程圖工具去梳理業務流程，用axure這樣的原型工具去設計產品原型，做的同時還得思考這個功能需求究竟放在產品的哪個功能模塊合適；
3、我們是不是每天都要去和各種人溝通需求，和設計師溝通需求，和前端工程師溝通需求，和后臺開發溝通需求，還要和測試、市場、運營、銷售等溝通需求。同時，你還要和用戶談需求，讓用戶了解和認識你的產品；
不得不說，要做好產品經理真不是一件容易的事情。
ps：限于篇幅，產品設計需求描述這部分分為上、中、下三篇文章來講，如對我的文章有更多想法和意見，歡迎關注我的公眾號找我交流。
相關閱讀：
作者：壹百度（微信公眾號：倒退集），在線教育企業服務領域產品經理，創業公司Team Leader。常常自詡是文藝青年和極客青年的結合體，在宅與不宅之間可以自由切換，曾主導多款重量級產品的產品策劃和設計工作。
本文由 @壹百度 原創發布于人人都是產品經理。未經許可，禁止轉載。
頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂的頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂的頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂的頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂的頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂的頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂的頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂的頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂的頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂的頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂的頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂的頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂的頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂的頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂頂
3篇已讀，贊一個！
不錯，學習啦
哈哈，感興趣的話可以關注我個人公眾號：倒退集
不定期分享產品干貨、職場感悟等
受教
哈哈，感興趣的話可以關注我個人公眾號：倒退集
不定期分享產品干貨、職場感悟等
不錯