項目過程的初期一項重要的
工作就是評審需求，每個公司或者團隊可能都有自己的一套流程、方案，但有效的
需求評審，離不開產品和研發的共同參與。本文所分享的方案主要是針對這一輪或若干輪產品、研發共同參與的評審。
這樣的需求評審在研發側往往只有研發主管盡心去了解了具體的需求細節，在研發參與需求評審的會議上，大部分研發的同學也像走馬觀花一邊純粹聽了一遍產品的同學朗讀需求文檔，事后開發的時候又發現很多細節問題，有沒有？？
下面是要給大家分享的一個方案，這個是我在我們項目組中推行實踐過的方案。
其實說起來很簡單，就是把需求評審會議上的角色轉換一下，讓研發的同學來講解需求文檔，讓產品的同學來聽。貌似每個產品的同學聽到這個方案都是先叫好的，好像是讓他們從這個會議的朗誦角色中解脫了，負擔輕了一大截似的。其實，應該說產品的同學負擔會更重了。
那么下面講講實施細則
1.要求研發的同學在評審之前仔細閱讀需求文檔并有所思。一般到了研發參與評審的階段，需求文檔已經包括了相當的細節。而研發的同學應該有自己的思想，要能夠挑出文檔中的問題，能夠做到有效的補充。這對于研發的同學來說是提高了要求。在我們團隊實施這一方案的初期，由于團隊規模本就不大（5人以下），所以當時我給出的要求是每個人都要熟悉我們負責部分的需求，要能提出有效的問題，評審時隨機挑選一名同學來進行講解，講解完后其他同學的問題也可以提出。對于規模稍大的團隊可能需要做些修改，可以把需求切割，再把團隊切割（3人一組也許比較好），照例還是要求一部分人必須熟悉至少一塊需求。這樣做的目的主要是由一種壓迫感“強制”研發側的同學去思考產品需求，后面應當逐步轉化為“自覺”的去思考才算達到了目的。
2.文檔的要求，研發的同學需要時間來熟悉文檔，哪怕讓他看一遍可以在上下班的路上來思考，但起碼應該在評審的前一天就有文檔發到研發手里，讓研發的同學可以開始熟悉需求。具體的哪些方面應該細節化，哪些方面可以延時細節化，視研發和產品直接的配合習慣來確定，這方面需要產品的同學把握。
3.會議中對產品同學的要求，不要認為研發的同學去講解，產品的同學就沒事可做了，相反，產品的同學可能要做的事情更重要了，產品的同學需要用心聆聽研發同學的講解，盡量盡早的發現研發同學對于需求的誤解。而研發同學也往往會讓產品的同學更清楚得認識到哪些功能可能是暫時行不通的，甚至研發的同學還可能給產品的同學提供新的思路。
當然各個團隊自己的評審需求的流程可能都不一樣，可以根據自己的需要來做調整。這個方案在我們團隊經歷的項目過程中實施，個人感覺還是有效果的，沒有消滅研發過程中再去發現細節問題，但有效的減少了此類問題，特別是誤解。