本文作者將分享自己在后臺需求文檔的撰寫上的心得和建議，enjoy~

近期在工作上獨立完成了一份后臺的需求規(guī)格說明書，因此有了一些心得體會。在這之前，我瀏覽過許多關(guān)于后臺設(shè)計的文章，大部分文章都是在闡述如何設(shè)計后臺，給了我們很多設(shè)計理念上的建議與幫助。

只是，無論什么樣的設(shè)計都最終都需要以文檔的形式產(chǎn)出，因此，本文我將在后臺需求文檔的撰寫上分享自己的心得和建議。現(xiàn)在，我們先來做做下筆前的思想工作：

為什么要進(jìn)行后臺設(shè)計？

我們設(shè)計后臺的初心，都是為了支撐業(yè)務(wù)，并進(jìn)一步提高運(yùn)營效率和產(chǎn)品競爭力，這是我們在設(shè)計后臺時需要時刻提醒自己的。由于后臺的產(chǎn)品不需要過多的考慮UI和交互設(shè)計，所以在明確好業(yè)務(wù)邏輯和系統(tǒng)架構(gòu)之后，將效率的提升作為后臺產(chǎn)品的重要指標(biāo)（KPI），注意避免用戶在使用你的產(chǎn)品時，做太多重復(fù)、機(jī)械的操作。

下筆的前提

關(guān)于后臺的設(shè)計還是需要老話重提。產(chǎn)品經(jīng)理一定要對你所設(shè)計的后臺業(yè)務(wù)了如指掌，親自深入到業(yè)務(wù)的實際工作中去，將工作流拆分成多個環(huán)節(jié)，形成功能的初步構(gòu)想。期間，你需要記錄下業(yè)務(wù)的整體流程和涉及到的元素，如字段、字段限制、業(yè)務(wù)要求等。

我個人的習(xí)慣是先將這部分內(nèi)容寫于紙上，清楚的梳理好業(yè)務(wù)之后，再將內(nèi)容轉(zhuǎn)化成電子檔。在紙上，你可以迅速的對內(nèi)容進(jìn)行編輯、修改，甚至可以將原型直接畫出，讓功能先簡單的呈現(xiàn)出來，再進(jìn)行調(diào)整改動，這樣可以減少很多電腦操作的時間。

同時還需明確目標(biāo)用戶，也就是這個功能是給誰用的。一般后臺的目標(biāo)用戶都是公司內(nèi)部人員，如運(yùn)營、市場等等，用戶就在身邊，那么產(chǎn)品經(jīng)理千萬不能浪費機(jī)會，一定要與用戶進(jìn)行溝通，提煉出他們的需求。以下是可以提的一些問題舉例：

• 過去是怎么處理這項業(yè)務(wù)的？
• 哪一個環(huán)節(jié)給你帶來困擾或者說需要花費你大量的時間去完成？
• 你最希望實現(xiàn)的功能是什么？
• 誰可以操作這項業(yè)務(wù)？操作的范圍又是哪些？
• 是否需要對用戶的操作行為進(jìn)行記錄？
• ……

大家可以根據(jù)實際情況進(jìn)行問題的列舉和提問，只有充分地融入到用戶中，才能設(shè)計出走心的后臺哦。

總結(jié)一下，下筆之前需要明確幾個要素：角色、角色的權(quán)限（包括功能權(quán)限和數(shù)據(jù)權(quán)限）、業(yè)務(wù)流程、所需字段、操作日志等。

下筆的順序

無論是功能還在初擬階段還是已經(jīng)開始撰寫需求文檔，下筆的順序一定是從核心功能（業(yè)務(wù)）->分支功能（業(yè)務(wù)），因為核心功能是奠定整個后臺的基礎(chǔ)，其他功能都是圍繞著核心功能延伸開來。無論是字段規(guī)則還是業(yè)務(wù)規(guī)則，其他功能都必須與核心功能保持一致，才能夠保證后臺的順利運(yùn)行。

當(dāng)你完成核心功能的設(shè)計和文檔撰寫時，可以先與研發(fā)討論設(shè)計是否合理和可行，接著再進(jìn)行分支功能的設(shè)計，這么做避免后期需要推倒重做的窘境。

后臺系統(tǒng)的目標(biāo)用戶可能是運(yùn)營人員、市場人員……，而需求文檔的目標(biāo)用戶一定是你的研發(fā)同事們，需求文檔是你輸出的一個產(chǎn)品，因此我們一定要讓需求文檔變得更清晰更易懂。

什么樣的需求文檔研發(fā)愛看？

簡潔、高效

設(shè)計時要遵循“簡潔、高效”的原則。能用一個詞說明清楚的事，千萬不要用一句話。

前后描述一致

設(shè)計后臺時，模塊之間必然會有關(guān)聯(lián)性，不同的模塊可能會涉及到相同的字段，因此對于每項字段、字段類型、字段說明等內(nèi)容必須保持一致，不要有前后矛盾的情況。

善用表格、圖文并茂：

后臺中的功能結(jié)構(gòu)、角色權(quán)限的分配等結(jié)構(gòu)性內(nèi)容采用表格的形式；

數(shù)據(jù)流向、業(yè)務(wù)流程用流程圖、泳道圖等描述清楚；

功能用原型圖呈現(xiàn)，原型圖中的信息進(jìn)行歸類，不能因為是后臺，無需考慮太好的用戶體驗而忽視了頁面的清晰整潔度。

原型圖的各類按鍵規(guī)格保持一致，讓研發(fā)或UI更好的設(shè)計，降低溝通成本。

描述方法：

一般后臺功能可分為列表數(shù)據(jù)、功能操作（增刪改查等）兩大塊。可以從以下方式進(jìn)行描述：

（1）列表數(shù)據(jù)

• 字段：字段名稱、字段類型、字段描述、數(shù)據(jù)來源、字段規(guī)則等；
• 列表：呈現(xiàn)字段、排序規(guī)則、分頁規(guī)則、狀態(tài)等。

（2）功能操作

方法一：事件流程法

比較復(fù)雜的后臺功能在同一個功能點中可能包含多個事件，所以復(fù)雜后臺功能可按照：基本事件流程、子事件流程與特別需求來描述。

方法二：條件描述法

這個方法適用于查詢功能，直接對需要查詢的條件、規(guī)則進(jìn)行描述。

方法三：輸入輸出法

輸入處理輸出大部分是由開發(fā)來考慮的，但產(chǎn)品經(jīng)理如果能站在開發(fā)的角度，明確輸入、處理、輸出的內(nèi)容，那會省去很多開發(fā)的理解成本。

方法四：簡要測試用例

測試用例可直接用來表述簡單、常見的功能，直擊功能的目的。前提是這類功能一定是比較常見的，不需要過多的深入描述，開發(fā)也能懂。

一些小TIPS：

1. 需不需要描述很細(xì)節(jié)的東西？這個問題要取決于整個開發(fā)團(tuán)隊的默契度，以及在開發(fā)之前是否已經(jīng)形成了標(biāo)準(zhǔn)的規(guī)范，如果是，那么產(chǎn)品經(jīng)理可以適當(dāng)減少一些細(xì)節(jié)描述，簡要概括，將重點放在業(yè)務(wù)的流程和邏輯上。
2. 大部分情況下，前臺需求決定后臺需求，后臺產(chǎn)品經(jīng)理設(shè)計前一定要與前臺產(chǎn)品經(jīng)理進(jìn)行深入溝通，不管是對目前有的功能還是未來的前臺需求規(guī)劃，后臺產(chǎn)品經(jīng)理都要了解，提前做好規(guī)劃，眼光放長遠(yuǎn)，思考功能的可持續(xù)性。
3. 有些團(tuán)隊的后臺文檔可能會由若干個產(chǎn)品經(jīng)理共同完成，建議對每個模塊的作者做好標(biāo)注，方便開發(fā)找到負(fù)責(zé)人溝通。同時，做好各大模塊的標(biāo)題和大綱，供開發(fā)查找。
4. 一份需求文檔一定會修改好幾個版本，一般采用R（Requirement）0、R2.0……來表示版本號。

本文由 @有餡兒的丸子? 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自StockSnap.io，基于 CC0 協(xié)議