酷播亮新聞
本文作者將分享自己在後台需求文檔的撰寫上的心得和建議，enjoy~
近期在工作上獨立完成了一份後台的需求規格說明書，因此有了一些心得體會。 在這之前，我瀏覽過許多關於後台設計的文章，大部分文章都是在闡述如何設計後台，給了我們很多設計理念上的建議與幫助。
只是，無論什麼樣的設計都最終都需要以文檔的形式產出，因此，本文我將在後台需求文檔的撰寫上分享自己的心得和建議。 現在，我們先來做做下筆前的思想工作：
為什麼要進行後台設計？
我們設計後台的初心，都是為了支撐業務，並進一步提高運營效率和產品競爭力，這是我們在設計後台時需要時刻提醒自己的。 由於後台的產品不需要過多的考慮UI和交互設計，所以在明確好業務邏輯和系統架構之後， 將效率的提升作為後台產品的重要指標（KPI）， 注意避免用戶在使用你的產品時，做太多重複、機械的操作。
下筆的前提
關於後台的設計還是需要老話重提。 產品經理一定要對你所設計的後台業務瞭如指掌， 親自深入到業務的實際工作中去，將工作流拆分成多個環節，形成功能的初步構想。 期間，你需要記錄下業務的整體流程和涉及到的元素，如字段、字段限制、業務要求等。
我個人的習慣是先將這部分內容寫於紙上，清楚的梳理好業務之後，再將內容轉化成電子檔。 在紙上，你可以迅速的對內容進行編輯、修改，甚至可以將原型直接畫出，讓功能先簡單的呈現出來，再進行調整改動，這樣可以減少很多電腦操作的時間。
同時還需明確目標用戶，也就是這個功能是給誰用的。 一般後台的目標用戶都是公司內部人員，如運營、市場等等，用戶就在身邊，那麼產品經理千萬不能浪費機會，一定要與用戶進行溝通，提煉出他們的需求。 以下是可以提的一些問題舉例：
- 過去是怎麼處理這項業務的？
- 哪一個環節給你帶來困擾或者說需要花費你大量的時間去完成？
- 你最希望實現的功能是什麼？
- 誰可以操作這項業務？ 操作的範圍又是哪些？
- 是否需要對用戶的操作行為進行記錄？
- ……
大家可以根據實際情況進行問題的列舉和提問，只有充分地融入到用戶中，才能設計出走心的後台哦。
總結一下，下筆之前需要明確幾個要素：角色、角色的權限（包括功能權限和數據權限）、業務流程、所需字段、操作日誌等。
下筆的順序
無論是功能還在初擬階段還是已經開始撰寫需求文檔， 下筆的順序一定是從核心功能（業務）->分支功能（業務）， 因為核心功能是奠定整個後台的基礎，其他功能都是圍繞著核心功能延伸開來。 無論是字段規則還是業務規則，其他功能都必須與核心功能保持一致，才能夠保證後台的順利運行。
當你完成核心功能的設計和文檔撰寫時，可以先與研發討論設計是否合理和可行，接著再進行分支功能的設計，這麼做避免後期需要推倒重做的窘境。
後台系統的目標用戶可能是運營人員、市場人員……，而需求文檔的目標用戶一定是你的研發同事們，需求文檔是你輸出的一個產品，因此我們一定要讓需求文檔變得更清晰更易 懂。
什麼樣的需求文檔研發愛看？
簡潔、高效
設計時要遵循“簡潔、高效”的原則。 能用一個詞說明清楚的事，千萬不要用一句話。
前後描述一致
設計後台時，模塊之間必然會有關聯性，不同的模塊可能會涉及到相同的字段，因此對於每項字段、字段類型、字段說明等內容必須保持一致，不要有前後矛盾的情況。
善用表格、圖文並茂：
後台中的功能結構、角色權限的分配等結構性內容採用表格的形式；
數據流向、業務流程用流程圖、泳道圖等描述清楚；
功能用原型圖呈現，原型圖中的信息進行歸類，不能因為是後台，無需考慮太好的用戶體驗而忽視了頁面的清晰整潔度。
原型圖的各類按鍵規格保持一致，讓研發或UI更好的設計，降低溝通成本。
描述方法：
一般後台功能可分為列表數據、功能操作（增刪改查等）兩大塊。 可以從以下方式進行描述：
（1）列表數據
- 字段： 字段名稱、字段類型、字段描述、數據來源、字段規則等；
- 列表： 呈現字段、排序規則、分頁規則、狀態等。
（2）功能操作
方法一：事件流程法
比較複雜的後台功能在同一個功能點中可能包含多個事件，所以復雜後台功能可按照：基本事件流程、子事件流程與特別需求來描述。
方法二：條件描述法
這個方法適用於查詢功能，直接對需要查詢的條件、規則進行描述。
方法三：輸入輸出法
輸入處理輸出大部分是由開發來考慮的，但產品經理如果能站在開發的角度，明確輸入、處理、輸出的內容，那會省去很多開發的理解成本。
方法四：簡要測試用例
測試用例可直接用來表述簡單、常見的功能，直擊功能的目的。 前提是這類功能一定是比較常見的，不需要過多的深入描述，開發也能懂。
一些小TIPS：
- 需不需要描述很細節的東西？ 這個問題要取決於整個開發團隊的默契度，以及在開發之前是否已經形成了標準的規範，如果是，那麼產品經理可以適當減少一些細節描述，簡要概括，將重點放在業務的流程和邏輯上 。
- 大部分情況下，前台需求決定後台需求，後台產品經理設計前一定要與前台產品經理進行深入溝通，不管是對目前有的功能還是未來的前台需求規劃，後台產品經理都要了解，提前做好 規劃，眼光放長遠，思考功能的可持續性。
- 有些團隊的後台文檔可能會由若干個產品經理共同完成，建議對每個模塊的作者做好標註，方便開發找到負責人溝通。 同時，做好各大模塊的標題和大綱，供開發查找。
- 一份需求文檔一定會修改好幾個版本，一般採用R（Requirement）0、R2.0……來表示版本號。
本文由 @有餡兒的丸子 原創發佈於人人都是產品經理。 未經許可，禁止轉載。
題圖來自StockSnap.io，基於 CC0 協議