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

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

一、需求文檔模闆到底能不能套着寫？

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

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

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

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

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

先說結論：

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

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

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

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

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

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

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

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

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

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

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

四、寫在最後

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

作者：胡子邯 ；公衆号：産品經理的日常反思

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

題圖來自Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部