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

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

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

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

基本上以上做到了，產(chǎn)品文檔在業(yè)務用戶和開發(fā)同學的視角中就是邏輯清晰，評價優(yōu)秀的了。產(chǎn)品落地實現(xiàn)，業(yè)務發(fā)展重構(gòu)，或新入職同事了解學習，都是寶貴資料。

一、確定目標價值

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

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

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

二、抽象

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

面向?qū)ο笫菍ΜF(xiàn)實世界的理解和高度抽象的方法，能夠高效地將現(xiàn)實世界抽象化成簡單的模型。把對象按照類型進行抽象，形成一個具有共同屬性集合，就是類。

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

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

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

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

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

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

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

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

三、拆解

1. 拆解事件狀態(tài)+狀態(tài)圖

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

狀態(tài)：對象的某個條件或狀況。所有對象都具有狀態(tài)，當某個事件發(fā)生后，對象的狀態(tài)發(fā)生變化；

事件：對對象的一個時間和空間上的操作，事件觸發(fā)狀態(tài)的轉(zhuǎn)移。

舉例：流量服務平臺通過讓流量主創(chuàng)建資源位置，來接入流量?？紤]審核和靈活開關(guān)設計了多方可操作的狀態(tài)。

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

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

靈活開停：流量主接入測試，需要經(jīng)常開關(guān)來控制流量是否接入。同時，運營測發(fā)現(xiàn)問題資源位需要及時關(guān)停來控制成本。

拆解出狀態(tài)圖，系統(tǒng)中就可以明晰的同步用戶對象的狀態(tài)和操作。

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

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

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

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

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

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

3. 拆解場景流轉(zhuǎn)+全景圖（自創(chuàng)）

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

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

拆解出全景圖，系統(tǒng)即可以實現(xiàn)權(quán)責分明的權(quán)限和全流程操作管理。

舉例：內(nèi)容平臺的的內(nèi)容變現(xiàn)板塊-派單模式的全景圖

四、歸納

1. 歸納統(tǒng)一服務+協(xié)作圖

當我們的業(yè)務逐步發(fā)展，要思考將統(tǒng)一的模塊整合成規(guī)范化服務，避免重復性建設。可復用性的服務建設可以支持產(chǎn)品實現(xiàn)快速的多模式裂變。可用協(xié)作圖來表現(xiàn)這種復用服務與對接模塊的關(guān)系，UML中的協(xié)作圖包括3方面的內(nèi)容：對象、鏈、消息，展示了發(fā)送和接收消息的各對象結(jié)構(gòu)上的組織。

舉例：內(nèi)容平臺的內(nèi)容變現(xiàn)板塊的通用結(jié)算模塊協(xié)作圖，統(tǒng)一結(jié)算模塊經(jīng)過搭建完成后可以快捷安全的接入多種內(nèi)容激勵模式，年支付金額也達到上億規(guī)模。

五、需求文檔的核心模塊

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

六、感悟心得

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

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

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

作者：izziezhang，騰訊IEG產(chǎn)品策劃；公眾號：騰訊大講堂

本文由 @騰訊大講堂 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash，基于 CC0 協(xié)議