需求文件（prd）編寫心得

摘要： 背景：沒有真正迭代需求文件的經歷，而只是編寫幾個不同格式的需求文件出來給到開發和UI。並且在後期的需求變更中增加到文件中，本身文件並沒有起到期望中的知道作用。 本人也是經過多次查詢，嘗試，才得出自己認為一個比較好的文件模板。 首先，要搞清楚需求文件是幹嘛的？在我看來有兩個作用，一個產品...

背景：沒有真正迭代需求文件的經歷，而只是編寫幾個不同格式的需求文件出來給到開發和UI。並且在後期的需求變更中增加到文件中，本身文件並沒有起到期望中的知道作用。

本人也是經過多次查詢，嘗試，才得出自己認為一個比較好的文件模板。

首先，要搞清楚需求文件是幹嘛的？在我看來有兩個作用，一個產品經理通過文字和流程圖的手段，從頭到尾擼一遍產品功能和流程，這個過程是要用文字表述出來，而且要依照一定的格式，所以對自糾自查非常有幫助。二個作用就是通過語言的精準性，將需求表達出來，作為最終確認的一個規範，交付確定性。

而並不是指導開發去開發的作用。那個只要UI去知道就可以了，可以在藍湖上將UI做成互動檔案。

好，回到需求文件，那麼如何做好自糾自查，以及做好完備性和準確性呢？

無非是輸入輸出和材料工具。

學過專案管理的同學對這個都比較熟悉，這個方法用在需求文件中是非常合適的。具體如下截圖：

依據上面的表格，逐一填寫，尤其表述清楚輸入時什麼，輸出是什麼，然後說明中間做了哪些動作，以及需要哪些條件，這樣逐一拆解模組和功能，根據顆粒度的不同可以到模組，功能，按鍵。

下面是目錄的截圖：

如上是一個登陸模組的說明，分為三大塊，分別是需求說明（就是上面的表格），介面展示（原型的對應頁面截圖，並在截圖上做簡要標註），用例流程（將模組的功能用流程圖表示出來，更加直觀，便於參照文字說明進行理解）。然後如果有下級功能，用此種方法去細化類推即可。

基本上，用這種方法，就可以出一份比較正規清晰的需求文件了。其他的表頭部分就不說了，都是些可有可無的東西。比如版本說明，修訂人說明，專案分析，功能導圖，產品流程圖等等。

以上，是一些需求文件的個人心得。

明天和大家分享一本書，名字叫做《即興演講》，謝謝大家，晚安。