B端產品需求文檔怎麼寫？

B端，或者2B，通常指的是英文中的 to busniss，中文即面向企業的含義。與B端相對應的，是C端，或者2C，一樣指的是英文中的 to customer，即面向消費者的意思。所以，人們日常所說的B端產品，就是指面向企業的產品，好比企業中用到的一整套內部辦公軟件，內部財務結算軟件，辦公erp平臺，以及幫助企業實現數字化轉型的雲計算平臺，大數據分析平臺，AI人工智能平臺，這些都屬於面向企業的B端產品。

而與之相對的C端產品，就是指直接面向普羅大衆的產品，直接面向消費者羣體。其中，互聯網app即是其中的產品之一，包括微信、QQ、外賣app、淘寶、抖音等都是直接面向消費者的C端互聯網產品。

在產品研發的層面，B端產品經理和C端產品經理的工做職責也是不同的。

相比起C端產品更加追求用戶的新鮮感和體驗感，B端產品更加註重爲客戶下降生產成本，提高生產效率。

所以，C端產品經理須要發動大腦去想如何知足用戶的衣食住行需求，並不是常重視知足用戶的新鮮感；而B端產品經理則要更加貼合企業實際，將客戶需求轉換爲產品功能，提高客戶的生產和辦公效率，下降生產成本。

1、產品需求文檔是什麼？

產品需求文檔做爲從需求到功能的具體實現指南，是全部開發、測試人員在產品開發過程當中的必備文檔。我的認爲，不論是B端仍是C端，產品需求文檔都應該具備如下特色：結構鮮明、邏輯完整、表達準確、通俗易懂。

結構鮮明：是指文檔總體上要有鮮明的行文框架，每個章節都應該有其合理的佈局，而且章節之間的關係顯而易見。邏輯完整：是指產品文檔的在內容上具備強烈的邏輯性，尤爲是在需求背景和產品策略的部分，產品經理要在這裏回答衆多個爲何，好比爲何要作這個需求，爲何這個功能是這樣的邏輯。表達準確：是指每一句話，每個詞，甚至每個定義都不該該有任何歧義，開發和測試在看到這句話以後，就知道表達的意思是什麼，而不是造成各自的解讀。通俗易懂：重要性也很高，是指產品文檔的表達應該是普通的書面表達方式，同時要避免錯句。

2、B端文檔的撰寫視角

B端產品特有的一些性質，好比收費性質/客戶導向/監控和日誌管理等，都要求B端的產品需求文檔在結構上體現這些差別性。

那麼，對於帶有鮮明行業特性的B端產品，如何寫一份好的產品需求文檔？

在寫了20+份文檔又額外研究了十幾份文檔後，我總結出B端文檔在撰寫時應該具備的幾個視角：

1. 邏輯視角

B端產品需求文檔更應該重視產品策略，文檔的開頭及隨後大部份內容都應該重點介紹產品的設計策略，更重要的是講清楚爲何要這樣作。需求背景、產品策略和策略原因更應該成爲B端產品需求文檔的核心，而不是像C端產品重點描述前端頁面上的設計樣式。

寫過學術論文的朋友都知道，論文的重點在於論，而不是單純地介紹你作了什麼。

B端產品需求文檔也是同樣，講清楚爲何這樣設計，對後續的開發流程其實有很大的幫助，尤爲是測試環節。

B端產品會涉及到衆多策略，好比產品自己的策略/收費的策略/產品監控策略/數據處理策略，這些策略的規則和啓停條件都應該在產品需求文檔中進行說明，而不是簡單地在後續前端頁面設計中直接告訴開發人員哪些操做須要封禁而不作緣由上的解釋。

同時，這些策略的要涵蓋產品全部的發生狀況，包括正常流程和異常流程下的操做方式，都應該予以說明，要保證策略在場景覆蓋上的普遍性。在這裏，表格是我比較經常使用的一種方式，經過多維度來涵蓋全部狀況下的對應規則。

同時，在對策略作了具體的羅列以後，更應該對全部狀況下的策略進行總結。這不只僅是對產品經理自身思惟的梳理，更能夠方便後續的開發流程，保證開發節奏。

除了要闡述清楚某一項策略的前因後果，更重要的，文檔的結構在順序上和框架上也要具備很強的邏輯性，好比第一節和第二節的關係是什麼，都要在撰寫時想清楚。

我的認爲最好的排序規則是總分，根據需求背景開始逐漸由宏觀過渡到微觀，這樣的順序更容易幫助開發人員理解本身要作什麼以及爲何這麼作。

總之，B端產品需求文檔要在介紹完需求背景以後，須要花適當的篇幅來介紹每一項產品策略，以及策略這樣設計的緣由。

2. 技術視角

B端產品每每不少狀況下是偏向技術的，尤爲是雲計算、AI、大數據這些與底層技術緊密相關的產品。產品經理在作一項功能的時候，應該考慮需求在實現時候的技術可行性。

同時，也須要判斷這個需求的實現須要哪一層開發的支持，並在產品需求文檔對應章節的內容後對該層開發人員進行標記提醒。

與此同時，產品經理最好能將需求層面的邏輯和技術實現時候的邏輯在關鍵點上保持同步。

好比，我最近在作的一個需求，是將產品中的某一項功能開始計費。目前，這項功能的服務是處於免費狀態。那麼，產品經理在撰寫產品需求文檔的時候，就應該明確該項服務的狀態量會發生改變，並在文檔中對新增狀態和字段進行定義。

這樣一來，技術人員能夠在寫代碼的時候直接參考需求文檔中新的定義量，並根據文檔中的狀態啓停條件設置自身代碼中的if-else語句策略，是算法設計的一種參考。

代碼講究的是全面，哪怕是一個小几率發生的事件，也須要在代碼中考慮，否則代碼就會報錯。

所以，正如策略視角中說到的，產品需求文檔要在考慮正常策略流程的同時，將全部異常策略下的狀況羅列清楚，這對提高開發效率也是一件有益的事情。

同時，測試也能夠直接參照產品需求文檔開始工做，而不須要本身規劃測試場景和測試用例。

總之，從技術視角而言，產品需求文檔須要羅列並考慮所有使用場景（正常+異常），並儘量的對新出現的狀態和字段進行定義，並在產品需求文檔中進行說明。

3. 客戶視角

客戶視角，並非說要把產品需求文檔拿給客戶去審覈，而是要在需求設計時考慮客戶的體驗。當產品交付客戶以後，使用產品的也是客戶公司的員工。所以，B端產品的設計，要在知足客戶降本提效需求的同時，兼顧客戶員工的使用需求，在必定程度上知足用戶體驗。

關於用戶體驗上的設計，通常要在前端頁面設計的部分進行展現，並告知前端開發如何操做。因爲各家產品在自身頁面交互設計上都有統一的流程，所以只要告知前端開發作哪種指引或者提示，並將該種提示在文檔中進行說明。

3、產品需求文檔的框架

結合本身的經驗，我總結出一份B端產品設計文檔的大體框架，從開始到最後能夠分爲：背景介紹、策略介紹、前端展現和排期。

這個框架給個人感受，有點相似學術論文的框架，兩者有殊途同歸之處。

背景介紹部分，主要介紹該需求的背景，包括需求來源、需求規劃、需求預期、競品狀況、名詞解釋及可行性分析。這一部分中須要將該需求的前因後果說清楚，在功能上相似於論文中的introductin部分，對全文進行導讀。

策略介紹部分，是整個產品需文檔中最爲重要的部分。要從上述的邏輯視角和技術視角進行全面的介紹，尤爲是規則上的制定和其制定的緣由。好比我所從事的雲計算行業，須要進行計費、服務啓停、監控策略的制定，更要對產品自己各模塊的策略進行介紹。這部分相似於論文的methodology部分，重點介紹方法和方法論。

前端展現部分很容易理解，主要關注功能在用戶可見頁面的流程和跳轉操做，並對正常和異常狀況下的操做方式和規則在前端頁面進行說明。這就須要用到產品經理必備的UE畫圖能力（固然也能夠將該部分交由UE同事負責）。這部分相似於論文中的results，對於策略執行後的具體表現進行說明。

而最後的排期部分，相似於論文中的appendix部分，看似多餘但實則有用。該部分須要對評審時各方預估的工做量和排期進行記錄，將其做爲該項目管理的一個指標或者參考。

在雲計算產品的設計流程中，有時候還會涉及到API或者SDK的設計，須要產品經理對該接口的名稱和參數進行定義，以後交由開發同窗開發。

總結

總之，B端產品和C端產品的差別性較大，產品經理在設計產品和撰寫產品需求文檔時，要分別有所側重，且B端產品更加註重策略邏輯和技術性，但也要兼顧用戶體驗。

其實寫任何東西都是思惟輸出的過程，形式是次要的，重要的是要將思惟梳理清楚並將其轉化爲文字，同時要讓看的人明白本身要作什麼以及爲何要這樣作。