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

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

一、需求編寫

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

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

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

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

產(chǎn)品經(jīng)理雖然不是領(lǐng)導(dǎo)崗，但在團(tuán)隊(duì)職責(zé)中屬于領(lǐng)導(dǎo)屬性，需要有與研發(fā)battle的能力，所以準(zhǔn)備工作一定要充分，才可以以理服人，讓研發(fā)團(tuán)隊(duì)信服你。

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

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

二、需求溝通

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

當(dāng)然，這就需要產(chǎn)品經(jīng)理做一個(gè)評(píng)估，是單個(gè)交流效果高，還是團(tuán)隊(duì)一起交流效率高。我的經(jīng)驗(yàn)來說，不同的需求要區(qū)別對(duì)待。有些大的框架需要和研發(fā)負(fù)責(zé)人溝通，有些同事這方面的能力比較欠缺，如果拉著一起評(píng)審，反而浪費(fèi)他的時(shí)間，降低溝通效率。

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

所以需求評(píng)審會(huì)議前期的需求溝通，按需組織，需要產(chǎn)品經(jīng)理對(duì)需求、對(duì)需求的實(shí)現(xiàn)、對(duì)團(tuán)隊(duì)成員的分工職責(zé)，有一個(gè)全局把握后決定。

三、需求評(píng)審會(huì)議

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

產(chǎn)品經(jīng)理要把準(zhǔn)備好的需求文檔（業(yè)務(wù)流程圖、原型圖、說明文檔等）作為附件一并發(fā)送，并預(yù)定會(huì)議室和會(huì)議時(shí)間，會(huì)議時(shí)間一般定在郵件發(fā)出后的1-3日，因?yàn)橐ＷC團(tuán)隊(duì)成員在會(huì)議前有足夠的時(shí)間看一遍文檔，在看的過程中，對(duì)有疑問的地方，標(biāo)注出來，回復(fù)給產(chǎn)品經(jīng)理，一般被標(biāo)注的地方就是邏輯矛盾點(diǎn)，也會(huì)成為評(píng)審會(huì)議溝通的重點(diǎn)，這樣可以提高會(huì)議的效率。

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

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

第二個(gè)問題是，團(tuán)隊(duì)如果在會(huì)議上第一次看到文檔，會(huì)提出很多很多無謂的問題，而這些問題當(dāng)他們看了全部文檔后其實(shí)就不是問題了，那么會(huì)導(dǎo)致會(huì)議效率低下，團(tuán)隊(duì)氛圍不佳，會(huì)認(rèn)為評(píng)審會(huì)議又臭又長(zhǎng)，浪費(fèi)時(shí)間。

四、需求評(píng)審會(huì)議紀(jì)要

需求評(píng)審會(huì)議結(jié)束的時(shí)候，產(chǎn)品經(jīng)理需要發(fā)會(huì)議紀(jì)要的郵件，把會(huì)議討論內(nèi)容，下一步的todo項(xiàng)，郵件發(fā)出，這封郵件非常重要，因?yàn)楸硎拘枨笠呀?jīng)通過了評(píng)審，研發(fā)同事可以開始正式干活了，需要緊接著就輸出開發(fā)設(shè)計(jì)文檔供大家評(píng)審。

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

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

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

以上就是針對(duì)B端產(chǎn)品設(shè)計(jì)與需求評(píng)審過程的簡(jiǎn)單分享。