需求池是什么？所有需求都匯集在一個地方，這個地方就叫需求池。

需求就像是水，而需求池裝滿了需求，方便需求匯總與查找。

一、為什么要弄一個需求池出來？

因為一般需求是很多很多的，這些需求之所以多主要原因一方面是因為來源廣，老板、公司運營、商務、用戶等需求方都可以提需求，有時候是用戶提出的一些小細節改動屬于小需求，有時候是加一整個功能模塊的大需求，另一方面是因為需求提很容易，拍個腦袋想一想又一個需求了，為了能夠讓這些零零散散的需求（不一定不重要）不被遺忘，所以都統統把這些需求登記到需求池里面，方便后期查詢，不會遺漏或遺忘掉。

二、如何做一個需求池？

需求池絕大部分情況都是用表格的形式創建的，主要的工具是Excel表格，一般Excel表格的表頭會有這幾個字段：平臺、功能模塊、需求類型、需求概述、需求描述、需求來源、優先級、狀態等，當然還有一些字段會增加或刪減，具體看實際使用情況。

需求池Excel表格關鍵字段

下面分別介紹表格中的幾個重要字段。

1. 平臺

即需求屬于哪個平臺，比如：是App端、還是小程序？或者是客戶端、還是后臺管理？

2. 功能模塊

即需求所屬功能模塊，比如：后臺管理端的用戶管理模塊。

3. 需求類型

需求類型一般可分為bug類、優化類（可分為體驗優化與功能優化）、新增功能等，類型可根據具體情況自定義。

4. 需求概述

即用簡短的語言描述需求，便于快速定位該條需求的主旨。

5. 需求描述

即需求的具體描述，描述要清晰，保證完整性、無二義性。

6. 需求來源

需求來源可以是客戶、領導、銷售、運營、競品等。

7. 優先級

由于研發資源有限且需求“魚龍混雜”，需求一定要有優先級，不是所有需求都能被滿足，也不是所有需求都要馬上做。

8.狀態

即需求的當前狀態，如：待排期、開發中、已完成、拒絕、暫停等。

9. 計劃開始時間、計劃完成時間與實際完成時間

這三個字段對應被接受的需求，便于后續需求完成情況的追蹤。必要時，可增加開發人員、測試人員字段。

三、需求池做好后，如何讓大家共同編輯？

建立好這個表格之后，比較笨的做法就是把這份表格發給可能提出需求的人，然后定期收集他們寫好的需求之后匯總，這樣會增加產品經理一部分的工作量，首先定期整理，需要把多份表格復制黏貼到一份表格，即便你懂一些excel快捷操作也需要花一些時間，如何能夠提高效率？這里我們一般會使用石墨文檔、金山文檔、騰訊文檔等在線共享文檔進行編輯。

舉例騰訊文檔，只需要在電腦端登錄微信，找到騰訊文檔小程序后打開騰訊文檔，然后建立表格后分享鏈接出去，其他人就可以共同編輯，就省去了產品經理整理和匯總需求的麻煩。

以上都是比較常規的操作，當然還需要根據公司的相關習慣去做，有的公司會有類似于teambition、worktile、tower這類的協同辦公平臺，也是有需求池，需求池都大同小異，主要是搜集方式不一樣，這個倒不復雜，這類軟件也是很容易就能上手并知道怎么做。

四、需求池越做越大，開發資源有限，我該怎么辦？

需求池永遠都逃避不了的就是需求會越來越多，開發改進的速度很有可能跟不上需求提出的速度，導致需求越來越多積壓起來，所以這個時候需要排一個需求優先級，先把重要緊急的需求先挑出來，先做該需求，或者做一些對產品未來規劃幫助比較大的，或者先做老板提過來的需求，再去解決其他需求，對于已完成的需求，應該要標記為已完成，并把已完成的需求移動到另外一張已完成的表中，這樣就不會看到需求越來越多了。

需求池的需求永遠很難做完，這是沒有關系的，對于如何解決掉需求，很多時候會使用到敏捷開發的方法對需求進行快速處理。

敏捷開發也就是10人組成一個小的開發團隊，一個蘿卜一到兩個人一個坑，組成最小作戰團隊，每個作戰團隊只負責一個小需求，而需求完成時間是兩個星期，一個星期開發，一個星期測試上線，可以讓需求能夠快速更新迭代，當然對于比較大的需求，則需要派更多的人手去做，這樣能快速的“消滅”需求，讓產品不斷的進行“新陳代謝”。

五、需求池的需求只是記錄，不是最終的詳細需求。

需求池的需求只是做需求記錄，一般寫的比較簡單，有時候寫得只有寫的人才能看得懂，這個時候溝通就很重要。

一般會在間隔一定時間內召開一次需求確定會議，對需求池里的需求，確定在接下來的一段時間都要處理哪幾個，這個會議的參與人一般由需求提出方和產品經理以及技術負責人參加，定好接下來做什么需求后，則需要產品經理詳細的和需求方溝通，了解詳細的需求情況，才開始進行原型繪制，最后在召開評審會的時候也需要需求提供方參加相關的會議，避免傳達錯誤。

六、需求池的優先級劃分

缺陷優先級從2個角度來提及：

一個是產品的缺陷優先級；一個是公司的缺陷問題優先級；

6.1 產品缺陷產生的優先級

比如在前面提到的小程序登錄問題，屬于這類問題。由于是用戶的必經路徑、也是產品未深度體驗之前的頁面，由于影響范圍大、覆蓋用戶群體多，在產品上是一定要修復的。

根據重要、緊急層度。如果要想讓產品在用戶得到好的口碑和轉化傳播，這類問題就要優先處理。

6.2 產品缺陷問題

公司的缺陷也分兩類，一類是技術框架的問題；一類是業務的問題。

技術框架的問題

公司缺陷和商業模式最相關的是業務問題，但技術框架同樣重要。比如之前選擇的是開源系統，在后期選擇使用php的形式自主開發，就是技術框架失敗導致公司缺陷

若不切換技術框架，隨之而來的開發時間周期會隨著迭代指數型增長；同樣也不兼容未來的產品擴展。

公司業務的問題

比如我們之前有嘗試過做鄭州、長沙等二三線城市的沙龍活動。為此開發當地的報名系統，結合當地的地域內容和用戶習慣做開發整合，實際上這類業務是有問題的，因為活動頻率太低。

比如我們在做產品銷售，會有熱賣單品和普通單品。熱賣單品為了滿足更多訂單需求，就增加了用戶的個性化自定義屬性的選項，實際上反而利潤急速降低。

負責普通單品的sku產品團隊在開發資源上就會減少，甚至是迭代進度延期，盡可能把時間都給在熱門單品的產品。

最終導致商品更新換代沒有品控，不標準化。

七、總結

總的來說，需求池就是一個記錄需求的地方，一般使用騰訊文檔等在線文檔讓團隊成員共同操作，最后匯總了需求還需要經過大家一起開會篩選出那些是接下來需要做的需求，排列需求優先級，需求池里的需求不會特別詳細，需要產品經理進一步溝通之后，繪制出詳細的原型圖或需求文檔，把原型圖等交給開發才能進行研發，測試并上線。