編輯導讀：產品經理不是在寫需求文檔，就是在寫需求文檔的路上。盡管寫需求文檔是一個基礎功，但是如何寫好，以及B端和C端寫需求文檔有什么區別，值得我們深究。本文作者對此進行了分析，與你分享。

接上兩篇內容《B端原型繪制入門》和《快速入手甲方項目》的最后內容，這兩篇一個是原型一個業務，現在繼續說一下落地，也就是需求文檔怎么寫。昨天上午剛交付了最近負責的小程序前后端文檔，加起來快2W字，最終開發也簽字確認了，趁著熱乎跟大家分享一下。

一、需求文檔模板到底能不能套著寫？

市面上的文檔模板太多了，直接可以搜到的，各種教學，各種視頻都在講，你一個新人怎么能不會寫文檔，所以這里面的水分，相信付過費的才能知道。

模板是可以套的，比如說公司內不是沒有模板，那我能不按他模板寫自己寫嗎，一般情況下不能，在寫文檔之前大家要明白一個事實，就是你現在到底在公司承擔的是什么角色，是團隊的沖鋒還是后勤補給。這里不涉及到職位，是什么角色大家自己掂量著判斷，如果是后勤部隊，那你寫的文檔只寫了核心業務，基本跳轉，剩下的部門寫的沒那么專業，是沒問題的。至于模板上什么頁面響應了，硬件支持了，你不寫一點問題沒有，刪掉就可以了。但如果你是團隊的沖鋒，你要負責團隊和開發部門的對接，需要向不懂網絡老板匯報，這時候就需要搞明白所做的東西需要哪些支持了，總不能項目做完，沒有環境支持，該買設備買設備，該買服務器買服務器，都要考慮到。

還要注意一點就是模板歸模板，不能死套，舉個例子，比如模板上讓你寫了產品功能，需求描述，功能介紹，沒說貼圖的事，某個頁面存在六個面包屑，每個頁面都有幾個業務，你能不貼圖像寫作文一樣描述需求嗎，是不行的，復雜的業務記著貼圖描述。

所以那些簡歷造假的，找到的工作能力不配職位的，這才是他們頭疼的問題。

二、C端文檔和B端文檔的區別

先說結論：

C端重跳轉，頁面狀態，分享路徑等

B端重業務邏輯，數據的輸入輸出，約束條件等

這次正好負責了前后端的文檔撰寫，能更好根據自己這一段的經驗來描述，有一個很大的感受就是前后端是有很大關聯的，舉個例子，前端的用戶分為兩種，一種是VIP，一種是普通用戶，在前端我需要給VIP賬號更好的體驗，讓他能干更多的事有更多的權利，這句話很明顯是一句沒有經過處理的需求描述，那轉化成產品需求應該是什么呢，“普通用戶擁有的權限為XX，XX，VIP用戶擁有的權限為XX,XX,XX,XX，未登錄時默認展示全部，當用戶登錄后，進行展示內容分層”，這是產品需求，也是經過梳理后的業務需求，這句話需要寫在前端的文檔里，那我現在怎么去描述后端的這部分？大家可以做個小思考。

經過這樣的前后端梳理，是很有趣的，而且能有一個全局的思考，不會隨便說一些奇怪的需求，見識的多了，也就理智了，這句話也適用于生活。再舉個例子，拿之前很火的一個傳統行業提出的需求“手機屏幕能跟隨手機殼變色”來說，如果這個人懂基本的技術實現方式，數據庫，一些業務邊際他就不會提出這個，當然這個也有點夸張，但我相信大家還是有遇到過這樣的人。

三、具體應該注意什么，怎么寫？

先說基本的，什么項目背景，角色，閱讀對象等亂七八糟的寫不寫，這取決與你們公司的流程，是產研一家，還是人家根本不知道你這些東西，如果不知道你就要好好寫了，如果天天在一塊探討業務，那還寫個屁，還有最后面的功能性需求，例如頁面響應，拓展需求，易用需求等，上面說過了你要不是沖鋒陷陣的，就不用寫，你也不會寫，只需要把基本核心業務，基本流程寫清楚，原型上做好跳轉就行了，這一步也不是像我說的那么簡單，是需要鍛煉和總結的，而且當面臨大型程序時是很容易出錯的，這就需要之前的總結了。

中間的最重要，也就是菜單/頁面描述，需求描述這些，我有個習慣，在文檔寫之前先把這部分的目錄寫好，也就是頁面結構序號先寫上，這樣后期會比較清晰，然后就是把寫好的描述標題，依次按頁面粘到結構上就可以開寫了。

頁面/模塊描述不要瞎寫，該頁面/模塊主要實現什么業務就寫上什么，如果實在沒有，只是展示，那就寫XX信息展示，這塊優先寫業務，其次操作。

數據排序/來源，有就寫沒有就不寫，來源不知道的就自己搞清楚，如果有來源別忘了搞清楚輸出，排序一般為倒序，特殊情況自己考慮

頁面描述，優先寫清楚所有跳轉，跳轉涉及到的業務也清楚，判斷，業務流程，操作，按鈕，各種權限，字段都要考慮到，這就是基本的文檔撰寫，建議不知道的不要不寫，如果現在在團隊里有人帶，建議都問清楚，這對后續業務理解有很大幫助

字段描述，這塊可以比作開發的基本工作手冊，這里有一個容易犯的錯誤就是，畫原型的時候咱們會把所有文字處理好，是肯定不會換行和省略號的一般，但如果用戶就是要瞎寫，或者標題就是特別長怎么辦，再或者你花了登錄頁，什么約束都沒寫，用戶設置密碼五個1，這寫問題后續是不是很可能出現問題？所以文檔這塊內容要描述清楚，文字多的一行放不下了怎么處理，上傳的地方限制的數量，大小，讓輸手機號，用戶輸一堆密碼該怎么限制，這些都是基本的，要描述清楚，就算你不懂什么格式，限制，那就寫“不允許換行，多的做適應性處理”，那開發也可以自由發揮，就怕沒有寫到，而開發也沒有注意，那后續就很可能出現問題。

四、寫在最后

上面所有的內容還需要考慮一個前提，公司怎么要求的，如果有硬性要求還是要按規章制度走，可以找兄弟部門或者內部要一份標準的，在去調整文檔，剩下的歡迎討論補充，大家一起進步。

作者：胡子邯 ；公眾號：產品經理的日常反思

本文由 @胡子邯 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議