起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識寫需求文檔時的注意事項
編輯導語：產品需求文檔撰寫可能是產品經理必備技能之一。而在撰寫需求文檔時，我們應當先了解需求、從而可以更準確地下筆。那么，文檔撰寫是否有什么注意事項？本文作者就結合其案例經驗向我們闡述了需求文檔的一些要點事項，讓我們一起看一下吧。
各位大大好，我是一枚工作一年的產品小白。撰寫產品需求文檔是自己工作職責的一部分，下面分享一些自己對需求文檔的理解，如有不當，還望各位大大多多指教～
本文分為如下4個模塊，全文約3500字，閱讀完畢大約需要5分鐘。
- 為什么要寫產品需求文檔；
- 需求文檔需要注意的一些點；
- 實際案例；
- 個人小結。
一、為什么要寫需求文檔
在我看來，寫需求文檔的目的主要有如下幾個。
1. 明確產品需求，避免遺漏
一個項目的需求有很多，把需求都記錄在文檔里并把具體的邏輯縷清，這樣能避免需求遺漏，同時方便管理。
2. 方便其他人員查閱，降低團隊成員的溝通成本
當團隊其他成員需要了解項目需求時直接閱讀文檔就好了，也方便了產品經理離職時的工作交接。
3. 信息存檔，作為功能開發的依據
如果開發出的功能不合預期，那么文檔可以作為依據，避免出現相關人員之間相互推諉責任的情況。
二、需求文檔需要注意的一些點
文檔是寫給別人看的！文檔是寫給別人看的?。∥臋n是寫給別人看的?。。?/p>
既然文檔時給別人看的，那就應該讓讀者以最小的代價去看懂文檔。所以文檔的結構、可讀性、對產品描述的完整性和對文檔的維護更新非常重要。
1. 文檔結構
個人理解的文檔結構是整個文檔是由哪些內容組成的，它們的層級關系是怎樣的。比如在一級標題下分別有哪些二級標題，每個標題的具體內容分別講什么。
合理的結構可以讓文檔內容有條有理?？梢韵纫巹澓谜w的文檔結構，然后再開始寫具體的內容，建議打開word或WPS中的導航窗格，方便預覽文檔的整體結構，也方便快速查看某個模塊的內容（單擊視圖中的導航窗格即可打開）。文檔結構規劃圖示例：
如果是B端產品的文檔，可能還會涉及一些非功能性的描述，比如安全性、與其他系統的數據交互規則、數據的存儲備份規則等等。其實沒有標準的文檔結構，具體看項目情況來定，能把需求明確清晰的表達出來就行了。
在WPS中打開導航窗格：
2. 文檔可讀性
文檔的可讀性還是蠻重要的，先不說內容寫得怎么樣，起碼排面要有，特別是一些要交給客戶和領導的文檔，沒有排面可不行。如果想要文檔具有比較強的可讀性，需要注意以下幾個點。
1）大段文字描述時，可以分點描述的內容就分點描述（以有序列表或無序列表的形式分點），同時也要注意內容的分段。示例：
2）盡量以表格的形式去展現內容，比如描述同一個事件的多種狀態時，用表格就比用大段文字合適。示例：
3）如果有某些需要重點強調的內容，可以給字體標上一些顯眼的顏色，以便讓讀者一眼就能注意到，特別是大段文字描述時，更應該突出重點內容，以便讀者能捕捉重點信息。示例：
4）文檔里的配圖/表格加上題注，讓讀者知道這個圖/表主要想表達什么內容，減少讀者的認知成本。通過通配符可以批量為圖片設置自動題注，有需要的小伙伴可以去百度一下。示例：=
5）此外還有一些細節。
文字的行間距、段落的段間距在很大程度上也會影響文檔的視覺效果，行間距、段間距太小，文檔看起來會顯得很擁擠，太大文檔看起來會顯得很松散。
至于行間距和段間距要設多少，就要看正文字體是多大了，比如5號字體比較適用單倍行距，具體的大家可以去百度一下，反正看起來順眼就行。
3. 對產品描述的完整性
對產品描述的完整性是指盡可能的把一個產品的功能規則全部描述出來。
比如短信驗證碼的相關規則包括：多久能獲取一次驗證碼、某段時間內最多可以獲取多少次驗證碼、驗證碼有多少位數、有效期是多久等等。
如果對產品規則描述得不齊全，可能會導致程序在開發時遺漏掉某些功能（有些程序真的是按照需求文檔進行開發，完全不多想其他），別人讀起來也可能會感到疑惑：為什么這個功能沒有對xxx進行限制??？
個人覺得要想做到盡可能全的把規則羅列出來，可以從以下3個方面著手：
1）寫文檔前一定要先把產品吃透，自己要先知道開發這個產品是為了解決什么問題，有哪些功能和相關規則，各個功能模塊間的關系是怎樣的，有哪些需要特別注意的點，同時要能熟練地使用產品。
如果自己都沒有把產品吃透，那很難寫出文檔的。
2）培養自己全方位思考問題的意識。一件事情發生前、發生時、發生后的規則分別是什么，是否有什么前置條件或特殊條件，如果某個條件不滿足會怎么樣等等，自己要主動有這樣的意識去思考，而不是單純的靠經驗，想到什么就寫什么。
平時可以有意識的去訓練自己，讓自己養成這樣思考問題的習慣。
3）多體驗各種產品，研究它們的功能都有些什么約束規則，為什么要這么設計（比如淘寶的搜索框是怎樣設計的，具體有什么規則，為什么要這么設計）。
可以對各種情況進行嘗試，比如在填寫某個信息時故意輸入很多位數，探究其對輸入信息的校驗。也可以多看一下別人寫的需求文檔，里面也會對規則進行約束性的描述。
總而言之就是要多看文檔或多體驗其他產品，讓自己知道，這一類功能要進行這樣的約束，是怎樣進行約束的，而且也可以在這個過程中讓自己形成全方位思考問題的意識。
4. 文檔維護及更新
對于這個方面，個人的做法是這樣的，每一個功能模塊就起一個文檔來寫，如果把所有的功能都寫在一個文檔里，文檔會非常的冗長，而且不利于分工進行開發。
實際案例：一個項目由多個產品經理同時負責，每個人都負責相應的功能模塊，如果把需求都寫在一個文檔里的話，會很難同步各方的信息（用云文檔可以解決信息同步困難這個問題，但我們公司沒有這樣做）。
每次對功能進行改動后，就復制一份文檔，然后在上面更新改動的內容，并給一個新的版本號，大版本直接由1.0升到2.0，小版本就由1.0升到1.1，如果是很小很小的改動，不給新的版本號也可以，直接在當前最新版本的文檔里寫就好了。
同時還要寫明版本信息，說明是誰改動了文檔，什么時候改的，相比于上一個版本改了什么東西。一個功能模塊的文檔經過多次迭代后是這樣的：
三、實際案例
版本信息
1. 需求概述
1）需求來源
對多款競品進行分析并結合產品自身戰略方向得出需求。
2）需求目的
提供多種登錄方式供用戶進行登錄，減少用戶登錄的操作成本，降低用戶流失率。
3）功能說明
2. 登錄功能需求
1）UI原型圖
2）功能流程圖
3）前端規則
手機號登錄
- 手機號要輸入11位數，否則提示：手機號格式錯誤。暫不考慮海外手機號碼登錄。
- 60秒后才能再次獲取驗證碼，在此期間，獲取驗證碼按鈕置灰不可點擊且顯示倒計時動畫。
- 手機驗證碼最多能輸入5位數，否則提示：驗證碼格式錯誤。
- 手機驗證碼錯誤則提示：驗證碼錯誤。
- 輸入了過期的驗證碼，則點擊登錄后提示提示：驗證碼無效或已過期，請重新獲取。
- 在第5次獲取驗證碼時彈出提示：驗證碼已發送，請在[下次可獲取驗證碼時間點]再次嘗試獲取。在驗證碼冷卻期內再次點擊獲取驗證碼按鈕，則提示：請在[下次可獲取驗證碼時間點]再次嘗試獲取。
- 根據后端返回的標志判斷是否為第一次登錄，如果是，則登錄成功后進入創建賬號流程，否則直接進入APP。
賬號密碼登錄
如果登錄失敗則彈出提示：賬號或密碼錯誤，請重新輸入。
社交賬號快捷登錄
單擊社交賬號登錄按鈕后，根據相應社交APP的狀態作出響應：
其他
- 單擊“賬號密碼登錄”可以跳轉到賬號密碼登錄的界面，單擊“手機號快捷登錄”可以跳到手機號快捷登錄的界面。
- 單擊登錄遇到問題可以跳到“常見問題解答”界面。在兩種登錄模式下都是跳到同一個界面。
4）后端規則
手機號登錄
- 以第1次單擊獲取驗證碼按鈕的時間點為準，同一手機號一個小時內最多可以獲取5次短信驗證碼，以單擊第5次獲取驗證碼的按鈕時間點為準進行計時，60分鐘后可再次獲取驗證碼。比如在7:24:00第1次獲取驗證碼，則在7:24:00—8:24:00期間只能獲取5次驗證碼。
- 獲取驗證碼后需要等待60秒才能獲取下一次驗證碼。
- 驗證碼有效期為5分鐘，發送多個驗證碼時以最后一個為準。
- 如果該手機號為首次登錄，則返回標志至前端。
賬號密碼登錄
如果賬號或密碼錯誤，或賬號不存在，則返回登錄失敗標志。
社交賬號快捷登錄
每個社交賬號都可以創建一個獨立的賬號，例如使用qq/微信登錄的賬號，它們之間的數據不共享。
5）測試要點
各個功能是否遵循如上規則。
四、個人小結
這篇文章主要是講文檔的結構和關于可讀性的一些注意事項，都是一些偏展示形式的東西，但要真正寫好一份文檔，對產品的熟悉和理解才是最關鍵的，個人覺得，一份好的文檔=好的想法+好的展現形式。
文章中的登錄功能是是參考了簡書，上面關于社交賬號登錄的描述不是特別詳細，有興趣了解的小伙伴們可以去下載APP自己體驗一下。
小弟目前經驗尚且不足，歡迎各位大大對文章做出評論～
本文由 @活蹦亂跳的大咸魚 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基于CC0協議。
是否還需要增加一個“頁面要素”的說明？
二級評論
學到了