建模語言很重要，建模思想更重要。

接下來大家將會看到的是一個系列的文章，分為上中下三篇。本文是第一篇，我將以我在實際工作中遇到的情景作為案例和大家分享我的“建模方法論”。這個方法論是我通過看書和自己的思考，再加上工作中的實際經驗總結而來。

建模方法論的概況

1. 整個建模方法論的結構

2. 為什么需要掌握建模技術

1）幫你從業務出發推導出具體要做的功能

在我們從0-1 打造一個軟件的時候，我們面臨著這樣的問題，這個軟件應該有哪些模塊？每個模塊有哪些功能？

如果是一個面向C端的產品，有可能你自己就是一個目標用戶，你可以將自己代入情景，尋找痛點，找到要做的功能。

可是，如果是一個面向B端的產品，因為B端軟件的業務屬性非常重，如果你對業務不是那么熟悉，那么在一開始你可能對于上面提到的兩個問題會感到沒有頭緒。即使你對業務非常熟悉，也不一定就能保證你做出的軟件符合業務的要求。

因為，在熟悉業務和做出符合業務要求的軟件之間，還有一個鴻溝，你需要掌握建模技術幫你跨越這條鴻溝。

2）進入大廠的必備技能

騰訊對于產品經理的要求分為通用能力、專業知識、專業技能、組織影響力這幾個大的模塊，在最重要的專業技能模塊中包含了對產品規劃能力的要求，具體又劃分為5個等級，其中第3等級的標準中就包含了對建模能力的要求。

名詞說明

為了大家看文章的過程更加的順暢，這里對一些基礎的名詞做一些說明。

1. 業務

百度定義：“業務”更白話一些來說，就是各行業中需要處理的事務。

我的定義：公司為了實現某個目標而需要開展的工作，或者所需要處理的事務。

2. 建模

百度定義：建模就是建立模型，就是為了理解事物而對事物做出的一種抽象，是對事物的一種無歧義的書面描述。

我的定義：建模是一個過程，目的是為了把復雜的事物用圖形或者文字的方式描述出來，便于自己思考和他人的理解，最后輸出的可能是一些圖形或文字的說明；在軟件領域里主要使用UML來進行建模。

3. UML

UML全稱是Unified Modeling Language，統一建模語言。

很多人認為學會了UML就學會了建模，這種想法真是大錯特錯。UML僅僅是我們用來建模的工具，是否真的會建模取決于你的建模思維，不同的人使用UML建立的模型可謂天差地別。就好比你學會了Java編程語言，并不能表明你是個優秀的程序員，你是否是個優秀的程序員取決于你的編程思維。

閱讀本篇文章需要讀者具備一定的UML基礎知識，這樣可以更好地幫助你看懂本文中的一些術語。不懂UML的小伙伴也不用沮喪，可以先把文章看完，回頭再去充充電，UML學起來很快的。

建模第一步：了解業務概況

所謂業務概況，就是先大致了解下公司有哪些業務，這些業務是如何配合從而支撐起公司的運轉。我們只需要把最主要的業務環節梳理出來即可，每個業務環節具體不需要非常細致。

我所在的教育培訓行業的業務概況：

目的：了解業務概況的目的，是讓我們對于客戶公司的業務有一個大致的認知，為我們接下來開展工作奠定基礎。

如何了解業務概況

• 我們可以通過一些行業分析報告，或者在網上找到這樣的資料；
• 如果是給自己的公司做管理軟件，我們也可以通過簡單的調研了解業務概況。

建模第二步：找到業務目標

1. 什么是業務目標

簡單說，業務目標就是客戶或者公司對于軟件系統的期望?？蛻粝Ｍ孟到y來做什么，即建設系統的目的是什么、準備用它來做什么。

舉例：

• 為市場人員提供線索管理系統；
• 幫助銷售部管理好客戶，提高銷售部的工作效率；
• 采集營銷和管理數據，進行商業分析，提供決策支持。

2. 找到業務目標的作用

為我們大致劃分了系統將涉及到的業務范圍，為后續的調研決定了方向。

3. 如何獲取業務目標

在實際工作中，業務目標一般是公司高層領導或者項目發起人提出來的。比如公司的CEO可能希望為公司開發一款軟件，用于提高公司辦公效率，節約公司運營成本，也有可能是IT部門根據公司的業務狀況整理得到的。

注意：客戶提出的業務目標需要評估后，才能知道軟件是否能夠支持到這些業務目標。

建模第三步：涉眾分析

1. 什么是涉眾

涉眾是與要建設的業務系統相關的一切人和事。

首先，要明確的一點是，涉眾不等于用戶，通常意義上的用戶是指系統的使用者，而這僅是涉眾中的一部分。

如何理解與業務系統相關的一切人和事呢？

凡是與這個項目有利益關系的人和事都是涉眾，他們都可能對系統建設造成影響。

目的：為后續進行業務建模分析業務主角做準備。

2. 如何發現涉眾

大家可以從以下大類去尋找涉眾：

1）業主

① 業主和業務方的區別：

業主是系統建設的出資方、投資者。雖然大多數情況下業主指的就是系統的需求提出者和使用者，即業務方，但并不是絕對的。

比如，可以假設系統建設是由一家國際風險投資機構投資的，它本身井不管理和運營這個系統，它只是從資本上擁有這個系統并從運營收入中獲得回報。

即使業主與業務主是重合的， 但是業主從概念上講井不等于業務方，他們關心的內容是不一樣的。了解業主的期望是必需的和重要的，業主的錢是這個項目存在的原因。若系統建設不符合業主的期望，撤回投資，那么再好的愿望也是空的。

② 業主關心的點：

一般來說，業主關心的是建設成本、建設周期以及建成后的效益。

雖然這些看上去與系統需求沒什么大的關系，但是建設成本、建設周期將直接影響到你可以采用的技術，可以選用的軟件架構，可以承受的系統范圍。

一個不能達到業主成本和周期要求的項目是一個失敗的項目，同樣，一個達到了業主成本和周期要求，但卻沒有賺到錢的項目仍然是一個失敗的項目。

2）業務提出者

① 業務提出者簡介：

業務提出者是業務范圍、業務模式和業務規則的制定者，一般是指業務方的高層人物，比如CEO、高級經理等。他們制定業務規則，圈定業務范圍，規劃業務目標。他們的期望十分十分重要。實際上，系統建設正是業務提出者經營目標和管理意志的體現。

雖然他們的期望一般都比較原則化和粗略化，但是卻不能違反和誤解，否則系統將有徹底失敗的危險。換句話說，業務提出者的期望是系統建設的最高綱領。

② 業務提出者關心的點：

業務提出者一般最關心系統建設能夠帶來的社會影響、效率提升、管理改進、成本節約等宏觀效果。換句話說，他們只關心統計意義而不關心具體細節。

但是，如果建設完成的系統不能給出他們滿意的統計結果，這必定是一個失敗的項目．在系統建設過程的溝通中，他們的意志一般是極少妥協的，系統分析員不必太費心去試圖說服他們接受一個與他們意志相左的方案。

實際上，由于他們的期望是非常原則化和粗略化的，因此留給了系統建設者很大的調整空間和規避風險的余地。

3）業務管理者

① 業務管理者簡介：

業務管理者是指實際管理和監督業務執行的人員， 一般是指中層干部，他們將業務提出者的意志付諸實施，并監督底層員工工作的作用。他們的期望也很重要，一般也是系統的主要用戶之一。

② 業務管理者的關心點：

業務管理者關心系統將如何實現他們的管理職能，如何能方便地得知業務執行情況，如何下達指令、如何得到反饋、如何評估結果等。

業務管理者的期望相對比較細節，是需求調研過程中最重要的信息來源。系統建設的好壞與業務管理者的關系最多，也是系統分析員最需要下功夫的。

業務流程、業務規則、業務模式等絕大部分來自業務管理者。系統分析員必須要把業務管理者的思路想法弄清楚，業務建模的結果也必須與業務管理者達成一致。

業務管理者應當成為需求評審小組的成員，如果可能，他們甚至應當成為需求分析小組的成員與系統分析員一同工作。

③ 對于業務管理者的期望可以提出建議：

在系統建設過程中，業務管理者的期望可以有所妥協，一個經驗豐富的系統分析員可以給他們灌輸合理的管理方式，提供可替代的管理方法，以規避導致高技術風險或高成本。

4）業務執行者

① 業務執行者是哪些人：

業務執行者是指底層的業務操作人員，是與將來的計算機直接交互最多的人員。

他們最關心的內容是系統會給他們帶來什么樣的方便，會怎樣的改變他們的工作模式。

② 業務執行者的需求的特點：

業務執行者的需求最為細節，系統的可用性、友好性、運行效率等與他們關系最多。

系統界面風格、操作方式、數據展現方式、錄入方式、業務細節都需要從他們這里了解。他們將成為系統是否成功的試金石。系統的界面風格、操作方式、表單細節等是系統分析員向他們調研時需要多下功夫的地方。

③ 管理業務執行者的期望：

這類人員的期望靈活性最大，也最容易說服和妥協。同時，他們的期望又往往是最不統一的，各種各樣的古怪要求都有。

但是，不管他們的期望有多古怪，都必須服從業務管理者的期望。系統分析員需要做的事情是從他們的各種期望中找出普遍意義，解決大部分人的問題，對于特殊的問題盡量予以說服，必要時可以依靠說服業務管理者，來影響和消除那些不合理的期望。

5）第三方

第三方是指與這項業務有關系的，但并非業務方的其他人或事。比如購物網站系統，如果交易雙方是通過網上銀行完成支付交易的，則網上銀行就成為了購物網站系統的一個涉眾；如果貨物是通過郵政系統交付的，那么郵政系統就成為購物網站系統的一個涉眾。

一般來說，第三方的期望對系統來說不會產生什么決定性影響，但大多會起到限制作用，成為系統的一個約束。通常，在最終系統中，這些期望將體現為標準、協議和接口。

另一種典型的第三方是項目監理，項目監理的期望也會對系統建設起到約束作用。

6）承建方

承建方，也就是你的老板。實際上老板的期望也是不容忽視的。

通常老板關心的是通過這個項目是否能賺到錢、是否能積累核心競爭力、是否能樹立品牌、是否能開拓市場等。老板的期望將很大的影響—個項目的運作模式、技術選擇、架構建立和范圍確定。

比如，如果老板試圖通過這個項目打開和培育一個新興市場，樹立起公司品牌，并不惜成本，那么系統分析員就要盡可能的深入挖掘潛在業務，建立擴展能力很強，但成本較高的業務架構；選擇那些比較新、具有一定領先優勢但風險較高的技術。

反之，如果老板只想通過這個項目賺更多的錢，關心的是投入產出比，那么系統分析員就需要引導業務方壓縮業務范圍，選擇風險小的成熟技術。甚至可能放棄成本較高的架構化開發模式，僅僅考慮系統的可維護性是否能夠接受，而較少考慮系統擴展能力。

一個業主滿意但老板不滿意的項目，恐怕也不是一個成功的項目吧？

7）相關的法律法規

相關的法律法規是一個很重要的，但也最容易被忽視的涉眾。

這里的法律法規，既指國家和地方法律法規，也指行業規范和標準。例如，服務行業建立客戶檔案，就必須保障客戶的隱私權，系統設計時就不能夠將涉及隱私的信息向非授權用戶開放。

極端情況下，業務方有時提出來的一些需求違反了法律法規，系統分析員如果知曉則應當指出來，說服無果的情況下則應當與老板商量在合同里留下免責條款。

另外，有時必須得遵守一些行業規范?，F在許多行業都有本行業的信息系統建設標準，如信息安全標準系統建設時就必須考慮信息安全的問題。

3. 制作涉眾匯總表格

在分析完涉眾后，我們可以簡單整理成表格，為我們后續的調研打下基礎，知道哪塊業務去找哪些人。

至此前三個步驟告一段落，后面的兩個步驟是整個建模過程的核心，將會在接下來的一周內分享給大家。

作者：一點優秀，教育行業產品經理，微信號：gentleman52520，歡迎交流

本文由 @一點優秀 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議