編輯導語：產品一般都需要搭建強大的內部管理端，常常面臨流程長，操作復雜，角色多，多個內部系統聯動，與業務用戶和開發難以用簡短的溝通或者文字說明解釋的清楚的問題。而這些內部產品的邏輯很難從競品處獲得參考。對產品經理的工作帶來了很大的困難和挑戰。面對困難產生的焦慮最好的辦法就是“具體”。為了解決這一業務問題，決定要啟動的情況下，這篇文章分享給大家怎么做。

做產品一定要明確需求目標和價值，如果僅僅是為了湊需求個數而做需求，還不如不做，寧愿停下來花時間去學習。產品目標就像團隊仰望的星空里的北極星，指引大家前進。想清楚為什么做以及目標和價值是最重要的。

然后就是抽象、拆解、歸納業務問題，借助可視化的方法梳理邏輯，定義對象、場景、角色、操作、流程、狀態，消息。就像建筑師設計樓房一樣，規劃用地目的、功能區、鋼筋結構、水電走向，這樣從0到1形成的產品文檔才可解釋性強，易于理解。

按照確定目標和價值，抽象問題（定義解決問題的對象），拆解問題（梳理業務及產品流程），歸納問題（將類似模塊合成服務），形成需求文檔，過程中使用UML的可視化圖來可視化邏輯。

基本上以上做到了，產品文檔在業務用戶和開發同學的視角中就是邏輯清晰，評價優秀的了。產品落地實現，業務發展重構，或新入職同事了解學習，都是寶貴資料。

一、確定目標價值

我們在制定目標前，先思考清楚現有背景下，公司部門的愿景，自身的優劣勢，立足的核心差異點，給用戶帶來的核心價值是什么。價值就是業務的核心訴求，是產品的商業模式決定的。核心的價值可以向：增加“收益”，降低”成本“，防范”風險” 三大方向去思考。最后，在考慮資源的基礎上制定以可量化的目標指標去衡量落地效果。

確定好目標之后，分析跟理想的目標狀態的差距在哪里，梳理出問題點。再將現實業務問題，轉化在系統中解決問題。從0到1解決問題，我們要用到常用的思維：抽象、拆解、歸納。借助UML可視化建模圖形會更好的協助產品經理自己理清思路，同時也能直觀明確的用圖形和文字來傳遞信息給開發和用戶。

UML是一種面向對象的，定義良好、易于表達、功能強大的建模語言。合理、有效地利用幾種模型進行思考&設計，能夠極大地提高產品工作和溝通效率。

二、抽象

1. 抽象屬性及操作+類圖

面向對象是對現實世界的理解和高度抽象的方法，能夠高效地將現實世界抽象化成簡單的模型。把對象按照類型進行抽象，形成一個具有共同屬性集合，就是類。

重點提煉：解決問題的類名、屬性、操作。

類名：即解決問題主體的名稱；

屬性：即該類的共同度量屬性，每個對象用屬性的值描述其特點；

操作：即為類的一個行為或者發生變化的過程。

舉例，流量服務平臺管理端，需要對每個流量主的每個資源位置按照商務約定規則來計費結算，以實現流量主的流量變現。存在以下幾個問題：

• 流量主多：每天的有億級別的流量的進入，需要給成百上千的流量主計算流量收益
• 單價各異：流量的價格標準，根據平臺運營目標，經常變動。即同樣流量在不同標準下收益不同
• 審批驗收：一旦人工調價，需要提交給老板申請費用審核，才能支付給流量主
• 嚴謹對賬：為了保證對賬嚴謹性，需要能記錄每次價格的變動

抽象出”結算計費規則“類，來記錄、計算、變更收益。以不變應萬變。

策劃出類，系統中就可以很便捷的落地對象的”新建“，”列表“場景。

三、拆解

1. 拆解事件狀態+狀態圖

類模型僅能表示系統各部分/模塊的靜態關系，通過狀態模型，可以描述一個實體基于事件反應的動態行為。狀態模型描述相應外部發生的操作序列，但是不描述操作做了什么，對什么操作，或者如何實現。狀態之間通過事件連接起來就成了狀態圖。

狀態：對象的某個條件或狀況。所有對象都具有狀態，當某個事件發生后，對象的狀態發生變化；

事件：對對象的一個時間和空間上的操作，事件觸發狀態的轉移。

舉例：流量服務平臺通過讓流量主創建資源位置，來接入流量。考慮審核和靈活開關設計了多方可操作的狀態。

初期需審核：初期需要通過審核才可上線，保證流量接入正常。

多角色參與：需要流量主，審核人，開發等多角色協作操作，同步進度。

靈活開停：流量主接入測試，需要經常開關來控制流量是否接入。同時，運營測發現問題資源位需要及時關停來控制成本。

拆解出狀態圖，系統中就可以明晰的同步用戶對象的狀態和操作。

2. 拆解順序流程+時序圖

狀態模型能表示狀態的轉移，但是不能表示有一定次序的操作和狀態變化，這時，就需要用時序圖來實現角色、對象之間有順序的流程。構成時序圖主要有幾個要素：對象、激活、消息、生命線。

生命線：一個對象的底部都繪制了一條垂直虛線，當一個對象向另一個對象發送消息時，此消息開始于發送對象底部的生命線，終止于接收對象底部的生命線。

激活：是時序圖中的對象執行一項操作的時期，將對象的生命線拓寬成矩形，表示對象是激活的。

拆解出時序圖，實際是對產品服務的業務流程完整的梳理。是一個非?！贝缶钟^“的規劃。

舉例：內容平臺的內容變現板塊派單模式的流程圖，因為涉及資金支付，實現上有多個部門合作，流程長，完善的時序圖向開發和用戶展示了在產品流程中是如何協作完成一次需求的下達，接收，驗收，審批，支付。

3. 拆解場景流轉+全景圖（自創）

狀態模型能表示狀態的轉移，但是不能表示有一定次序的操作和狀態變化，時序圖來實現角色、對象之間有順序的流程,但無法反饋用戶操作狀態。是否有一種圖，能反饋用戶角色的操作，及帶來的狀態反饋？

全景圖是筆者在遇到如上問題自創的一種圖形，展示了用戶對象對一個類的全生命周期操作，從一個場景是如何轉化到另外一個場景，特別適合復雜的多角色操作。

拆解出全景圖，系統即可以實現權責分明的權限和全流程操作管理。

舉例：內容平臺的的內容變現板塊-派單模式的全景圖

四、歸納

1. 歸納統一服務+協作圖

當我們的業務逐步發展，要思考將統一的模塊整合成規范化服務，避免重復性建設。可復用性的服務建設可以支持產品實現快速的多模式裂變?？捎脜f作圖來表現這種復用服務與對接模塊的關系，UML中的協作圖包括3方面的內容：對象、鏈、消息，展示了發送和接收消息的各對象結構上的組織。

舉例：內容平臺的內容變現板塊的通用結算模塊協作圖，統一結算模塊經過搭建完成后可以快捷安全的接入多種內容激勵模式，年支付金額也達到上億規模。

五、需求文檔的核心模塊

• 需求價值/背景
• 需求目標
• 需求內容：需要充分說明：業務流程，屬性，角色，操作，狀態，轉移，權限，指標說明等。輔助UML圖例。
• 優先級
• 期望完成時間
• 迭代版本

六、感悟心得

筆者從入職騰訊以來，一直在流量生態部流量產品中心，雖然部門名稱有變化，也陸續做過廣告平臺，內容平臺，增長數據平臺，但從一入職部門的目標就沒有變過：一切以解決問題為目標。的確，產品經理既需要仰望星空，規劃制定產品的北極星目標；又要腳踏實地，與團隊合作一磚一瓦地拆解問題、解決問題。

本文是作者在做偏平臺b端產品的過程中的思考和經驗分享，篇幅有限，很多內容這一篇文章無法詳細展開，歡迎小伙伴們再@我一起交流學習。

最后，希望我們做的產品能讓用戶稱道，我們撰寫的產品文檔的每一筆每一劃都令人懷念！

作者：izziezhang，騰訊IEG產品策劃；公眾號：騰訊大講堂

本文由 @騰訊大講堂 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議