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