文章為作者結合自身工作經(jīng)(jing)驗總結的樣編編寫(xiě)需求文檔的方法(′?｀*)，希望可以對你的寫(xiě)產(chǎn)寫(xiě)產(chǎn)產(chǎn)品工作帶來(lái)幫助。

作為產(chǎn)品經(jīng)理，品需品需編寫(xiě)需求文檔是求文求文產(chǎn)品工作環(huán)節中最基本的，同時(shí)也是檔編檔的大步非常??重要的工作。

剛開(kāi)始，樣編我們通常會(huì )拿別人的寫(xiě)產(chǎn)寫(xiě)產(chǎn)需求??文(′?｀*)檔作為模板來(lái)套用，這種格式化的品需品需需求文檔看起來(lái)挺專(zhuān)業(yè)，但慢慢地會(huì )感覺(jué)到別扭。求文求文因(′?｀*)為每項需求定義所需要的檔編檔的大步表達元素都不一樣，多了沒(méi)必要，樣編少了又說(shuō)不清楚。寫(xiě)產(chǎn)寫(xiě)產(chǎn)而這種填空式的品需品需文檔，總會(huì )讓人有一種束縛感。求文求文

經(jīng)過(guò)自己多年的檔編檔的大步工作錘煉，最終慢慢形成了自己的一套需求文檔編寫(xiě)步驟和方法，從此屢試不爽。而也就從這之后自己對需求文檔的有了更(geng)深一層的理解。

我們先來(lái)說(shuō)說(shuō)編寫(xiě)需求文檔的步驟。

1、建立版本功能需求樹(shù)。

也就是需求的結構化可視化處理。

通常，產(chǎn)品經(jīng)理會(huì )有一個(gè)需求池。我們根據需求的重要性和緊急性從需求(′?｀*)池中挑選出部分需求，作為產(chǎn)品迭代版本的工作內容。確定了要納入版本開(kāi)發(fā)的需求點(diǎn)之后，接下來(lái)要做的并不是編寫(xiě)需??求，ヾ(′?｀)?而是畫(huà)需求樹(shù)。

這一步要用到的工具便是思維導圖軟件。我們將從需求池取出來(lái)的零散需求，以分類(lèi)別的方式進(jìn)行結構化處理。如按模??塊化分，按用戶(hù)角色化分等，從而讓一個(gè)個(gè)的需求點(diǎn)組成一個(gè)個(gè)較完整??的功能。這樣的好處是，讓需求點(diǎn)之間形成聯(lián)系，ヽ(′ー｀)ノ而這個(gè)過(guò)程則可能會(huì )演化出新的必要性需求，也將之納入到版本需求中去。

這個(gè)時(shí)候的需求導圖，類(lèi)似于樹(shù)干加上枝干，已經(jīng)形成了產(chǎn)品需求樹(shù)的大概樣子(??ヮ?)?*:???。

將零散需求結構化處理之后，便要(yao)進(jìn)行ヽ(′ー｀)ノ進(jìn)一步的細化，也就是畫(huà)出需求細枝。

在每個(gè)需求點(diǎn)之下，都會(huì )有些關(guān)鍵的，重要的元素構成。將這些元素畫(huà)出來(lái)，有利于后面的需求文檔編寫(xiě)工作，避免產(chǎn)生遺漏。

2、建立需求文( ?° ?? ?°)檔目錄結構。

需求文檔的目錄結構，就是用來(lái)確定文檔的內容和表達形式的一種有力┐(′д｀)┌手段。在寫(xiě)需求內容(◎_◎;)前先把(ba)整個(gè)文檔的目錄結構確定后，編寫(xiě)文檔的效率會(huì )大大提高，也會(huì )使得文檔的表達邏輯更為清晰明了。

一般情況下，產(chǎn)品經(jīng)理都會(huì )有自己的一套比較常用的目錄結構，用于快速地建立文檔??框架。但是在很多時(shí)候，通用目錄結構可能并不能滿(mǎn)足特定需求下的表達效果??。因為不同的需求所需要使用到(??ヮ?)?*:???的表達方式是不一樣的，只有針對性地采??用合適的表達方式才能使(shi)你編寫(xiě)的需求文檔產(chǎn)生事半功倍的效果(guo)。

比如，針對用戶(hù)端APP形態(tài)的功能定義，則更側重的是信息架構、頁(yè)面展現、用戶(hù)體驗，所以在原型設計和(he)關(guān)鍵交互要求是需要重點(diǎn)說(shuō)明的(de)。因此，在這部分需求的內容結構上，需要將“原型設計”及(′?_?`)“交互說(shuō)明”單獨列入???到目錄結構中去。

比如，針對后臺功能，側重的是數據處理和存儲，所以在數據項定義、數據流轉、規則說(shuō)明等方面需要進(jìn)行完整說(shuō)明。而如果這幾部分內容較多，則也是需要進(jìn)行??劃分，最終體現在目錄結構中。

再( ?° ?? ?°)如，涉及到多系統間業(yè)務(wù)交互的，或者業(yè)務(wù)流程較為復雜的，則可能需要考慮加入(???)系統間業(yè)務(wù)交互說(shuō)(shuo)明、接口定義、業(yè)務(wù)流程描述等內容。

如此這般，(′?_?`)都是需要針對不同類(lèi)型的需求采用不同的表達方式來(lái)描(╬?益?)述需求。最終的目的也都是為了讓文檔使用者（開(kāi)發(fā)工程師）更容易理解你所定義的需求。

所以，我們在寫(xiě)文檔之前進(jìn)行目錄結構設定，是為了框定文檔的內容和表達方式，相當于我們建筑里的框架結構(???)。搭建好之后，便可以進(jìn)行快速填充了。

3、詳細需求內容(′_｀)填充。

這一步，最重要的就是把需求??描述得更(geng)容易理解，要站在開(kāi)發(fā)工程師的角度來(lái)考慮如何表達。另外就是邏輯要嚴密，不要產(chǎn)生需求漏洞。

4、需(xu)求文檔版本更新。

產(chǎn)品需要迭代，??需求文檔也一樣。當你的需求文檔發(fā)出去之后，經(jīng)過(guò)評審，以及在后續項目進(jìn)行過(guò)程中都有??變更需求定義的可能，這就涉及到了文檔的更新問(wèn)題。

我們可以稱(chēng)之為需求文檔迭代。這個(gè)工作最重要的就是版本管理。每次文檔更新，我們都需要像產(chǎn)品版本一樣給予定義一個(gè)版本號。這個(gè)版本號跟產(chǎn)品版本要區分開(kāi)來(lái)，文檔版本號是在產(chǎn)品版本之下的，所以只需要進(jìn)行簡(jiǎn)單的命名即ヽ(′▽?zhuān)?ノ可。

通常，???我會(huì )(hui)將需(xu)求文檔版本號命名為Rx( ?ヮ?)，如R1，R2，R3等等。R表示requirements，即需求。默認將首次發(fā)布的需(′_｀)求文檔版本定為R1，后續每次變更修改則依次命名為R2，R3……且要說(shuō)明此次版本變更的說(shuō)明。另外還有就是修改人，修改時(shí)間等(deng)信息。

而在具體內容修改的地方，最好能把改動(dòng)的地方標識出來(lái)，比如用高亮的字體顏色進(jìn)行區分。這樣能讓開(kāi)發(fā)人員(yuan)一目了然，便于閱讀。

最后，對于需求文檔的編寫(xiě)，還需要明白如下幾點(diǎn)：

編寫(xiě)產(chǎn)品需求之前的核心工作是分(fen)析理解需求，弄清楚(′?｀)用戶(hù)到底要什么？重視需求分析，腦補用戶(hù)使用場(chǎng)景，理解用戶(hù)目標，完整地渲染出用戶(hù)需要的產(chǎn)品功能，做出用戶(hù)需要，可用，好用的產(chǎn)品設計。需求文檔的目的是產(chǎn)品經(jīng)理將用戶(hù)需求通過(guò)分析設計轉化為研發(fā)人員可理解（有來(lái)龍去脈），可實(shí)現（邏輯完整通暢）的產(chǎn)品開(kāi)發(fā)說(shuō)明書(shū)。要用研發(fā)人員可以理解的語(yǔ)言及方式來(lái)描述，要考慮??使用對象的閱讀體驗。了解必要的技術(shù)(′▽?zhuān)?實(shí)現原理和流程。如對接微信支付，你需要了解微信支(zhi)付接口相關(guān)的技術(shù)能力及對接流程，通(′；д；`)過(guò)整合自己的業(yè)務(wù)需求和流程，做出合理、可實(shí)現的設計 。當沒(méi)有專(zhuān)門(mén)的交互設計師時(shí)，產(chǎn)品經(jīng)理需要同時(shí)考慮交互體驗設計，但絕不要沉浸在交互設計效果的模擬實(shí)現(╯‵□′)╯上。能說(shuō)一句話(huà)說(shuō)明白??的事，就不要去做交互，因為你不是交互設計師，你的工作重心在于需求定義本身。?