從幾個細節問題出發,如何寫好產品需求文檔?
這篇文章暫時不討論什么是需求文檔,也不強調需求文檔的重要性等等,就簡單地從各種細節問題出發如何寫好一份需求文檔。
一份好的需求文檔的標準是什么?不同項目不同規模的團隊有不一樣的評判標準,個人覺得能清晰準確把握需求各項要素,寫完之后各相關部門同事能清楚明白,那就是一份好的需求文檔了。想要做到清晰和準確卻不是一件簡單的事,作為缺乏經驗的產品新人,我覺得可以從一些細節問題上開始做好。
有人會覺得需求文檔根本不需要那么嚴謹細膩,這樣會浪費很多時間。寫產品需求文檔本就是一個鍛煉自己邏輯思維和推敲求證的過程,嚴謹細膩的態度可以讓我們更全面的考慮問題,從而寫出一份好的需求文檔,減少團隊成員的理解障礙?,F在就把我平時寫需求文檔遇到的一些細節問題拿出來給大家分享一下,希望大家都能避免這些不必要的錯誤。
排版規范
我們會寫各種文檔,如圖能做到每一份文檔都有統一的排版,將更方便各部門同事閱讀。格式的標準包括文檔頁眉、各類型文字的字體型號、大小、顏色;表格規范;流程圖統一規范等等。
文檔的命名
如果能做到高度概括,精準定義,可以幫助團隊成員快速準確把握文檔的內容,避免跑偏。需求文檔的命名可以從文檔的意義,作用,性質方面考慮。
名詞的定義
第一次出現在文檔中的特殊名詞一定要精準描述,不可有缺失。產品肯定明白自己寫的內容是什么,但并不代表團隊里面的人都能理解。每個人對事物的理解都不一樣,如果不做好名詞的定義解釋,很容易產生歧義,從而產生分歧。用普通的電商網站舉個例子,如果在需求文檔只是簡單描述說“后臺實現XX功能”,那就麻煩大了。這個“后臺”可以指的是買家個人中心、賣家后臺系統甚至整個網站的后臺管理系統等等,如果不正確命名并解釋清楚,開發看起來會很痛苦。
盡量不用大段大段文字描述需求,不是每個開發都有耐心開得下去。
盡量用表格或者流程圖進行描述,比如說要說清楚不同角色間不同的功能權限,用表格列出來可以清楚明白地表達和比照;另外一種就是流程圖了,正所謂一圖勝千言。建議大家都可以學習和使用UML的一些相關知識,比如用例圖、類圖、序列圖、活動圖、狀態圖等,它們可以清楚詳細的描繪出任何一種事物和各種邏輯關系。從開發的角度看,他們是很喜歡這種表達方式的,如果你能正確熟練的使用的話。
牽扯到專業術語要弄清楚再寫
比如說某些登錄輸入框需要用到正則表達式,如果自己沒弄懂什么是正則表達式,最好別寫在需求文檔上。需求文檔不是開發文檔,我們不一定要用開發的語言去描述,只要把功能邏輯講清楚即可。
不要留空白
很多時候我們在寫文檔的過程總會有些內容未確定,但是請養成好習慣,不要留空白的地方,未確定的地方寫“待定”或者“TBD”,并交代清楚和誰待定,這將有利于你接下來的工作對接。
善于舉例
寫需求文檔的目的就是跟團隊相關成員講清楚需求,在描述需求的時候多舉例子可以幫助閱讀人員更好的了解需求。我們可以像講故事一樣去描述需求,但是千萬別跑偏了。
圖文一致
需求文檔我們會用到交互原型圖,原型的截圖和文字說明必須保持一致,而且截圖必須與實現情況相符。
寫這篇文章的主要目的是想引起大家對文檔細節的重視,從細節中發現問題,并找到相應技巧和方法去把需求文檔寫好。上面只是列出了幾條細節問題,如果大家在寫文檔過程中發現更多細節問題和文檔技巧歡迎交流學習。
本文由 @samuel(微信號:suns_up) 原創發布于人人都是產品經理?,未經許可,禁止轉載。
很實用,謝謝~
7個lol域名 打包1000 有意者私聊 不講價
皮膚 天賦 符文 天天 攻略 全民 媽了個逼
?? ?? ??