編輯導語：產品需求文件撰寫可能是產品經理必備技能之一。而在撰寫需求文件時，我們應當先了解需求、從而可以更準確地下筆。那麼，文件撰寫是否有什麼注意事項？本文作者就結合其案例經驗向我們闡述了需求文件的一些要點事項，讓我們一起看一下吧。
各位大大好，我是一枚工作一年的產品小白。撰寫產品需求文件是自己工作職責的一部分，下面分享一些自己對需求文件的理解，如有不當，還望各位大大多多指教～
本文分為如下4個模組，全文約3500字，閱讀完畢大約需要5分鐘。
- 為什麼要寫產品需求文件；
- 需求文件需要注意的一些點；
- 實際案例；
- 個人小結。
在我看來，寫需求文件的目的主要有如下幾個。
1. 明確產品需求，避免遺漏一個專案的需求有很多，把需求都記錄在文件裡並把具體的邏輯縷清，這樣能避免需求遺漏，同時方便管理。
2. 方便其他人員查閱，降低團隊成員的溝通成本當團隊其他成員需要了解專案需求時直接閱讀文件就好了，也方便了產品經理離職時的工作交接。
3. 資訊存檔，作為功能開發的依據如果開發出的功能不合預期，那麼文件可以作為依據，避免出現相關人員之間相互推諉責任的情況。
二、需求文件需要注意的一些點文件是寫給別人看的！文件是寫給別人看的！！文件是寫給別人看的！！！
既然文件時給別人看的，那就應該讓讀者以最小的代價去看懂文件。所以文件的結構、可讀性、對產品描述的完整性和對文件的維護更新非常重要。
1. 文件結構個人理解的文件結構是整個文件是由哪些內容組成的，它們的層級關係是怎樣的。比如在一級標題下分別有哪些二級標題，每個標題的具體內容分別講什麼。
合理的結構可以讓文件內容有條有理。可以先規劃好整體的文件結構，然後再開始寫具體的內容，建議開啟word或WPS中的導航窗格，方便預覽文件的整體結構，也方便快速檢視某個模組的內容（單擊檢視中的導航窗格即可開啟）。文件結構規劃圖示例：
如果是B端產品的文件，可能還會涉及一些非功能性的描述，比如安全性、與其他系統的資料互動規則、資料的儲存備份規則等等。其實沒有標準的文件結構，具體看專案情況來定，能把需求明確清晰的表達出來就行了。
在WPS中開啟導航窗格：
文件的可讀性還是蠻重要的，先不說內容寫得怎麼樣，起碼排面要有，特別是一些要交給客戶和領導的文件，沒有排面可不行。如果想要文件具有比較強的可讀性，需要注意以下幾個點。
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）功能說明
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協議。