之前我們已經(jīng)通過需求分析和篩選，評定了需求的優(yōu)先級，這時候就應該把這些整理好的需求，通過一個表格給呈現(xiàn)出來，功能需求列表Feature List就是這樣一個承載器。

輸出功能需求列表

什么是功能需求列表？顧名思義，就是把需求分析、篩選和評定優(yōu)先級之后的結果，以產品功能的形式展現(xiàn)出來，再用列表的方式將其呈現(xiàn)。這是需求分析之后，提出解決方案的第一步。

功能需求列表的價值，一是在于幫助產品經(jīng)理自己理清思路，二是在于幫助項目團隊的其它成員了解產品功能需求，好讓他們提前做好相關準備。

我們來看一下功能需求列表大致包含哪些內容：

1. 模塊：一般來說，每個模塊下分3~6個子模塊是合理的，否則要考慮重新劃分。
2. 子模塊：也就是一級模塊的二級分類，這里就已經(jīng)涉及到產品架構的梳理了（但我們這里只是大致地梳理一下，后期在產品設計的下一個環(huán)節(jié)“搭框架”會進一步調整）。
3. 功能：要給用戶提供什么功能，給這個功能起個名字。
4. 功能描述：這個功能具體包含哪些操作，可以描述的具體一些，如支持用戶填寫基本信息可自由創(chuàng)建課程，進入課程空間就可對課程進行編輯和管理，還可發(fā)布、刪除課程等。
5. 用戶價值描述：也就是可以給用戶提供什么價值。
6. 需求優(yōu)先級：這塊是整個Feature List工作中核心的部分，判斷的準確直接影響著將來產品的方向，我們只需要將我們之前評定的需求優(yōu)先級照抄過來就好。
7. 開發(fā)量：一般由研發(fā)部門的項目經(jīng)理或者開發(fā)來確定。
8. 投入產出比：簡單來說，就是商業(yè)價值除以開發(fā)工作量（或開發(fā)難度），當然每個團隊可以找出一個合適自己產品需求ROI的計算方法。
9. 備注：覺得需要強調的，比較特殊的東西。

上圖是功能需求列表的一部分，當然現(xiàn)在也有越來越多的產品經(jīng)理直接通過腦圖軟件來進行功能需求的梳理，然后通過腦圖軟件自帶的標注、附件、筆記、優(yōu)先級排序等功能進行說明，比如下圖這樣的：

形式其實并不是那么重要，重要的是團隊成員能夠通過你的文檔更加清楚地了解產品的功能需求，也便于產品經(jīng)理和團隊成員進行溝通。有了這份功能需求列表，我們就可以召集團隊相關成員進行一次需求評審會議了。

參加需求評審會議的可以有產品經(jīng)理、老板/領導、運營以及市場相關人員、開發(fā)主管、測試經(jīng)理等。為了保證需求評審能夠順利進行，最好提前做好相關的準備，產品經(jīng)理要能夠講清楚需求的來源，為什么要做這個需求，做這個需求有什么意義，這個需求需要哪些功能配合，同類競品是否有該功能需求，為什么這個需求的優(yōu)先級比較高……

整個需求評審的過程，考驗了產品經(jīng)理對需求的熟悉程度以及對需求的判斷能力。同時，參與評審的人也將會對你提出的需求提出自己的看法，是否同意該需求，并且會提出同意或者不同意該需求的理由。需求評審是多人圍繞已經(jīng)收集到的需求進行評審的過程，通過集合大家的智慧，能夠避免一個人閉門造車拍腦袋進行決策的局限。

如果時間比較充足，有些產品經(jīng)理在需求評審會議上還會展示產品低保真原型，用來輔助說明，讓大家更加理解這個需求以及需求以后會是怎樣的樣子，這樣也能夠讓自己在講解需求的時候更加有依有據(jù)，避免錯過一些有用的需求。當然，我們這里只是第一次需求評審，到了后期產品原型乃至ui設計稿全部定稿的時候，依然需要進行產品的需求評審。

如何管理需求——需求池

之前就已經(jīng)說過，需求是每個產品經(jīng)理日常工作都離不開的一部分，貫穿著產品的整個生命周期。所以，如何管理需求，就成為所有產品經(jīng)理必備的一項技能了。

在這里要給大家介紹一下需求池這個東西。

什么是需求池？

嗯，你可以把它類比為一個需求的收集器。需求池其實就是存放跟產品有關的未來可能會做的功能點的聚集地，然后在規(guī)劃新版本的時候，從池子里根據(jù)“輕重緩急”和“優(yōu)先級”來篩選出幾個需求，排一排、整一整，弄成一個新的版本項目計劃。

需求池工具有很多，比如Project、Execl、MindManager等等都可以作為需求池管理工具，你也可以使用一些團隊協(xié)作軟件（如tower、tita、明道、teambition等）里面的項目管理功能來做需求池工具。

一般來說，我會將需求池按產品的功能模塊來進行劃分，這樣所有關于產品功能的需求都會被歸類到相應的產品模塊里。當然，這個需求池里還會包含來自運營及其它部門的需求。我們要做的就是告訴這些需求提出者，他們的需求我們都重視了，已經(jīng)放到了需求池當中，但是是否安排開發(fā)需要根據(jù)所有需求進行“輕重緩急”和“優(yōu)先級”的權重比較才能決定。我們需要定期去審核和分析這些需求，是做還是不做、要做的話是什么時候做？

對需求池的建議有兩點：

1、不必考慮能不能做或者是做了沒用什么的這樣的限制，先不必設置偽命題，只要是覺得OK的，都可以先列出來，在產品生命周期管理中，靠譜的、不靠譜的、緊急的、不緊急的；

2、需求池需要產品經(jīng)理經(jīng)常去整理，不然就失去了需求池本身的意義，如果你不去整理，不論是市場環(huán)境，用戶行為都有可能發(fā)生變化，任何一個產品都是變化很快的，這個時間段的需求有可能過一段時間就失去意義了。這個整理其實就是復原了一次需求的分析和篩選過程，同時還要去進行需求的優(yōu)先級定義，每一次安排產品版本計劃的時候都要重新審視一遍需求。

總結

需求管理是一個完整的閉環(huán)過程，同時也貫穿著產品經(jīng)理工作的每一天，比如：

1、我們是不是每天都要去思考這個需求是否需要去做？這個需求到底重要不重要，緊急不緊急；

2、我們是不是經(jīng)常都要去用工具把需求給做出來，用visio這樣的流程圖工具去梳理業(yè)務流程，用axure這樣的原型工具去設計產品原型，做的同時還得思考這個功能需求究竟放在產品的哪個功能模塊合適；

3、我們是不是每天都要去和各種人溝通需求，和設計師溝通需求，和前端工程師溝通需求，和后臺開發(fā)溝通需求，還要和測試、市場、運營、銷售等溝通需求。同時，你還要和用戶談需求，讓用戶了解和認識你的產品；

不得不說，要做好產品經(jīng)理真不是一件容易的事情。

ps：限于篇幅，產品設計需求描述這部分分為上、中、下三篇文章來講，如對我的文章有更多想法和意見，歡迎關注我的公眾號找我交流。

相關閱讀：