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

　　剛開始，我們通常會(huì)拿別人的需求文檔作為模板來套用，這種格式化的需求文檔看起來挺專業(yè)，但慢慢地會(huì)感覺到別扭。因?yàn)槊宽?xiàng)需求定義所需要的表達(dá)元素都不一樣，多了沒必要，少了又說不清楚。而這種填空式的文檔，總會(huì)讓人有一種束縛感。

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

　　我們先來說說編寫需求文檔的步驟。

　　1、建立版本功能需求樹。

　　也就是需求的結(jié)構(gòu)化可視化處理。

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

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

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

　　將零散需求結(jié)構(gòu)化處理之后，便要進(jìn)行進(jìn)一步的細(xì)化，也就是畫出需求細(xì)枝。

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

　　把所有的細(xì)枝都畫完之后，我們的需求樹便已完成?？吹竭@個(gè)需求樹，自己心里已經(jīng)大概知道需求文檔要寫些什么了。

2、建立需求文檔目錄結(jié)構(gòu)。

　　需求文檔的目錄結(jié)構(gòu)，就是用來確定文檔的內(nèi)容和表達(dá)形式的一種有力手段。在寫需求內(nèi)容前先把整個(gè)文檔的目錄結(jié)構(gòu)確定后，編寫文檔的效率會(huì)大大提高，也會(huì)使得文檔的表達(dá)邏輯更為清晰明了。

　　一般情況下，產(chǎn)品經(jīng)理都會(huì)有自己的一套比較常用的目錄結(jié)構(gòu)，用于快速地建立文檔框架。但是在很多時(shí)候，通用目錄結(jié)構(gòu)可能并不能滿足特定需求下的表達(dá)效果。因?yàn)椴煌男枨笏枰褂玫降谋磉_(dá)方式是不一樣的，只有針對(duì)性地采用合適的表達(dá)方式才能使你編寫的需求文檔產(chǎn)生事半功倍的效果。

　　比如，針對(duì)用戶端APP形態(tài)的功能定義，則更側(cè)重的是信息架構(gòu)、頁面展現(xiàn)、用戶體驗(yàn)，所以在原型設(shè)計(jì)和關(guān)鍵交互要求是需要重點(diǎn)說明的。因此，在這部分需求的內(nèi)容結(jié)構(gòu)上，需要將“原型設(shè)計(jì)”及“交互說明”單獨(dú)列入到目錄結(jié)構(gòu)中去。

　　比如，針對(duì)后臺(tái)功能，側(cè)重的是數(shù)據(jù)處理和存儲(chǔ)，所以在數(shù)據(jù)項(xiàng)定義、數(shù)據(jù)流轉(zhuǎn)、規(guī)則說明等方面需要進(jìn)行完整說明。而如果這幾部分內(nèi)容較多，則也是需要進(jìn)行劃分，最終體現(xiàn)在目錄結(jié)構(gòu)中。

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

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

　　所以，我們在寫文檔之前進(jìn)行目錄結(jié)構(gòu)設(shè)定，是為了框定文檔的內(nèi)容和表達(dá)方式，相當(dāng)于我們建筑里的框架結(jié)構(gòu)。搭建好之后，便可以進(jìn)行快速填充了。

3、詳細(xì)需求內(nèi)容填充。

　　做好以上兩步，那這一步就變得簡單多了。因?yàn)槟阒懒艘獙懯裁?，而且還知道要怎么寫，剩下的無非就是時(shí)間問題了。

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

　　4、需求文檔版本更新。

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

　　我們可以稱之為需求文檔迭代。這個(gè)工作最重要的就是版本管理。每次文檔更新，我們都需要像產(chǎn)品版本一樣給予定義一個(gè)版本號(hào)。這個(gè)版本號(hào)跟產(chǎn)品版本要區(qū)分開來，文檔版本號(hào)是在產(chǎn)品版本之下的，所以只需要進(jìn)行簡單的命名即可。

　　通常，我會(huì)將需求文檔版本號(hào)命名為Rx，如R1，R2，R3等等。R表示requirements，即需求。默認(rèn)將首次發(fā)布的需求文檔版本定為R1，后續(xù)每次變更修改則依次命名為R2，R3……且要說明此次版本變更的說明。另外還有就是修改人，修改時(shí)間等信息。

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

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

　　1. 編寫產(chǎn)品需求之前的核心工作是分析理解需求，弄清楚用戶到底要什么？重視需求分析，腦補(bǔ)用戶使用場景，理解用戶目標(biāo)，完整地渲染出用戶需要的產(chǎn)品功能，做出用戶需要，可用，好用的產(chǎn)品設(shè)計(jì)。

　　2. 需求文檔的目的是產(chǎn)品經(jīng)理將用戶需求通過分析設(shè)計(jì)轉(zhuǎn)化為研發(fā)人員可理解（有來龍去脈），可實(shí)現(xiàn)（邏輯完整通暢）的產(chǎn)品開發(fā)說明書。要用研發(fā)人員可以理解的語言及方式來描述，要考慮使用對(duì)象的閱讀體驗(yàn)。

　　3. 了解必要的技術(shù)實(shí)現(xiàn)原理和流程。如對(duì)接微信支付，你需要了解微信支付接口相關(guān)的技術(shù)能力及對(duì)接流程，通過整合自己的業(yè)務(wù)需求和流程，做出合理、可實(shí)現(xiàn)的設(shè)計(jì) 。

　　4. 當(dāng)沒有專門的交互設(shè)計(jì)師時(shí)，產(chǎn)品經(jīng)理需要同時(shí)考慮交互體驗(yàn)設(shè)計(jì)，但絕不要沉浸在交互設(shè)計(jì)效果的模擬實(shí)現(xiàn)上。能說一句話說明白的事，就不要去做交互，因?yàn)槟悴皇墙换ピO(shè)計(jì)師，你的工作重心在于需求定義本身。

來源：人人都是產(chǎn)品經(jīng)理