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

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

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

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

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

一、確定目標(biāo)價(jià)值

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

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

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

二、抽象

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

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

重點(diǎn)提煉：解決問題的類名、屬性、操作。

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

屬性：即該類的共同度量屬性，每個(gè)對象用屬性的值描述其特點(diǎn)；

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

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

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

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

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

三、拆解

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

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

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

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

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

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

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

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

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

2. 拆解順序流程+時(shí)序圖

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

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

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

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

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

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

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

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

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

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

四、歸納

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

當(dāng)我們的業(yè)務(wù)逐步發(fā)展，要思考將統(tǒng)一的模塊整合成規(guī)范化服務(wù)，避免重復(fù)性建設(shè)?？蓮?fù)用性的服務(wù)建設(shè)可以支持產(chǎn)品實(shí)現(xiàn)快速的多模式裂變?？捎脜f(xié)作圖來表現(xiàn)這種復(fù)用服務(wù)與對接模塊的關(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)容激勵(lì)模式，年支付金額也達(dá)到上億規(guī)模。

五、需求文檔的核心模塊

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

六、感悟心得

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

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

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

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

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

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