B端產品設計與需求評審過程大致是怎樣的流程？本篇文章里，作者就進行了一番梳理，從需求編寫、需求溝通、需求評審會議等維度進行了拆解，一起來看一下，或許會對你有所幫助。

簽完合同，定完項目范圍，會有一個項目章程書，產品經理需要編寫產品需求文檔，包括業(yè)務流程圖、數(shù)據(jù)流程圖，開發(fā)的同事看見項目章程書只會對項目有個大概的了解，并不清楚自己該做些什么開發(fā)，需要產品經理帶領團隊細化需求。

一、需求編寫

產品經理寫了第一版需求文檔初稿后，就可以找相關開發(fā)同事溝通了。

我的需求文檔內容一般包括業(yè)務流程圖和原型圖含說明文字，因為業(yè)務流程圖可以幫助自己更好得理解項目全局，流程圖體現(xiàn)了每個模塊和每個功能之間的關聯(lián)性，在流程圖上一畫就可以發(fā)現(xiàn)邏輯漏洞，業(yè)務流程圖順了，整個項目需求就順了。

如果畫流程圖的過程中，發(fā)現(xiàn)畫不下去的情況，一般就是對項目的需求沒有很好的理解，那么就先去翻閱項目書，看看有沒有什么遺漏的部分，如果還是不解，那么就找項目經理或者前期參與的相關同事，目的是對整個項目的需求有全局的理解。

產品經理作為整個研發(fā)團隊的需求輸入方，必須對每個需求都了如指掌。一方面，對項目非常了解才可以把需求文檔寫清楚，不會亂七八糟得到處是錯。另一方面，這有助于產品經理領導力的形成，每次與研發(fā)團隊做需求交流的時候，研發(fā)同事都會提出非常多的質疑，如果產品經理經常無法自圓其說，總是被找到很多漏洞，那么產品經理在團隊中的領導力會大打折扣。

產品經理雖然不是領導崗，但在團隊職責中屬于領導屬性，需要有與研發(fā)battle的能力，所以準備工作一定要充分，才可以以理服人，讓研發(fā)團隊信服你。

下圖是業(yè)務流程示意，業(yè)務流程關鍵在于簡單易懂且不遺漏，千萬不能復雜了，別人看不懂的業(yè)務流程圖不是好流程圖。

下圖是我在墨刀上做的設計稿（去敏截圖），以前我習慣用axure做原型設計，但墨刀在線版確實方便不少，看個人喜歡，以效率導向做工具的選擇。

二、需求溝通

在與相關研發(fā)同事做私下交流的過程中，產品經理需要對需求做一遍闡述，在闡述的時候，往往自己就會發(fā)現(xiàn)不少設計漏洞，配合的同事也會發(fā)現(xiàn)闡述漏洞，發(fā)現(xiàn)漏洞，優(yōu)化設計，是這場交流的目的，這也是為了提高后面需求評審會的效率。

當然，這就需要產品經理做一個評估，是單個交流效果高，還是團隊一起交流效率高。我的經驗來說，不同的需求要區(qū)別對待。有些大的框架需要和研發(fā)負責人溝通，有些同事這方面的能力比較欠缺，如果拉著一起評審，反而浪費他的時間，降低溝通效率。

我的原則是，評審會議上，不說話的人就不該來參加這次會議，屬于互相浪費時間。而有些需求，涉及的功能模塊非常多，互相之間都有關聯(lián)，那么一定要把相關的同事都喊上，否則很容易出現(xiàn)一模一樣的事情講多次都無法拍板的情況，把大家都湊在一起，互相之間的約束關系，都攤開來說，整體規(guī)劃設計。

所以需求評審會議前期的需求溝通，按需組織，需要產品經理對需求、對需求的實現(xiàn)、對團隊成員的分工職責，有一個全局把握后決定。

三、需求評審會議

準備好需求文檔后，就可以開正式的需求評審會議了。產品經理需要發(fā)正式的郵件，一般情況就發(fā)給相關團隊成員（研發(fā)同事、測試同事、項目經理、銷售售前等，根據(jù)團隊情況而定），并抄送給相關方（如老板，發(fā)給老板的目的主要是向上管理，讓他知道下進度情況，一般情況老板不必參會）。

產品經理要把準備好的需求文檔（業(yè)務流程圖、原型圖、說明文檔等）作為附件一并發(fā)送，并預定會議室和會議時間，會議時間一般定在郵件發(fā)出后的1-3日，因為要保證團隊成員在會議前有足夠的時間看一遍文檔，在看的過程中，對有疑問的地方，標注出來，回復給產品經理，一般被標注的地方就是邏輯矛盾點，也會成為評審會議溝通的重點，這樣可以提高會議的效率。

文檔內容很多，如果直接在會議上打開，并沒有提前瀏覽，會出現(xiàn)兩個問題。

第一個問題是，團隊沒有足夠的時間消化并理解需求，看得模棱兩可，容易遺漏問題，沒有及時發(fā)現(xiàn)，那么等會議結束開始干活的時候，就會發(fā)現(xiàn)這也有問題、那也有問題，出現(xiàn)返工情況。

第二個問題是，團隊如果在會議上第一次看到文檔，會提出很多很多無謂的問題，而這些問題當他們看了全部文檔后其實就不是問題了，那么會導致會議效率低下，團隊氛圍不佳，會認為評審會議又臭又長，浪費時間。

四、需求評審會議紀要

需求評審會議結束的時候，產品經理需要發(fā)會議紀要的郵件，把會議討論內容，下一步的todo項，郵件發(fā)出，這封郵件非常重要，因為表示需求已經通過了評審，研發(fā)同事可以開始正式干活了，需要緊接著就輸出開發(fā)設計文檔供大家評審。

研發(fā)同事在編寫開發(fā)設計文檔過程中，依然會找產品經理不斷得溝通需求，以確認開發(fā)方案可以滿足需求，還有一種情況是，研發(fā)同事發(fā)現(xiàn)如果需求做適當調整，開發(fā)難度將會大大降低，縮短工期，那么也需要和產品經理溝通，做一些權衡的考量。

在開發(fā)方案定下來之前，需求依然存在調整的情況，如果需求文檔做了變更，那么產品經理需要同步變更給團隊，最好就是拉個會議，把幾日內溝通的情況，與大家溝通一下，這也屬于需求評審，如果有不合理的地方，團隊提出，再做調整，需求文檔和開發(fā)方案是一個漸進明細的過程。

有變更一定要做書面記錄，不然會出現(xiàn)信息不一致的情況，會出現(xiàn)返工或扯皮，導致團隊氛圍不佳。

以上就是針對B端產品設計與需求評審過程的簡單分享。