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