FAQ-UML 在產品經理的日常工作中有多大作用？

01-04

產品經理，介於用戶/客戶、領導/老闆、技術團隊之間的這樣一個軸心角色，負有完全的責任做到以下三條：

1. 充分了解並理解用戶/客戶的要求

2. 向領導/老闆證明產品的客戶價值和市場潛力

3. 向技術團隊準確傳達需求

要做好這三點，需要有比較強的分析和交流能力。

分析問題、跟人交流總得有個方式方法吧，而UML恰好提供了一套分析問題的工具集和準確交流的圖形化語言。

所以我堅持認為，UML是產品經理技能庫的No. 1 Skill，再也找不出這麼稱手的工具來支撐工作。

當然UML現在很龐大，作為產品經理甚至程序員，掌握用例圖、類圖和時序圖、必要時候會畫畫狀態圖，就完全夠用了。要學會這點充其量一個禮拜時間吧。這一禮拜的時間投資，不僅僅是收穫一個得心應手的工具，UML還在潛移默化地灌輸一種分析問題的方法論，讓你從散兵游勇成為正規軍。

UML工具多得很，請參考UML相關工具一覽，免費的好用的也有不少，比如韓國人做的StarUML。即便是收費的，有大把錢燒的互聯網公司，買個EA的license也不是問題吧。

有人說，交流用文檔、或者畫畫草圖就行了。

有那個時間去斟詞酌句把文檔寫漂亮，有那個時間一遍遍地給人畫並且解釋你那草圖是什麼含義，為什麼不學學用UML來描述，準確無歧義，交流無障礙。UML本來就是一個很棒的草圖工具，何必捨近求遠？退一萬步說，就算是寫文檔，起碼也該研究下「編寫有效用例」一類的技能，讓文檔格式標準化吧。

有人說，可以用各種原型工具，通過畫UI來傳達需求。

我就不信，UML這麼單一標準的東西都學不會，會搞得懂各種平台下的UI DESIGN SPEC。

畫出來那個原型幹什麼用？本質上還是在不斷畫草圖，不停給人解釋你的草圖。畫UI不是產品經理該乾的活兒，用用正規武器，不要再讓人覺得「如果你什麼都不會，就去做產品經理吧」。

這些年，「互聯網思維」和「敏捷」這兩個玩意兒，讓一些從業者給自己的懶惰和愚蠢找到了借口，以程序員尤甚，現在程序員還反轉過來勸產品經理UML無用。而大凡說UML無用的人，對UML都是一知半解。不信？諸位看官，請誠實地回答一下：

你是不是認為Sequence Diagram就是個流程圖，或者將Sequence Diagram畫成了業務流程？

UML圖是給碼農，架構師，專利局，版權局看的。老闆不看，市場不看，設計不看，產品經理懶得看，更懶得畫。UML是系統分析師的專用工具，我見過一個系統分析出生的產品經理搞了一堆UML講立項PPT，什麼介面，系統，時序了。業務老闆直接看睡著了，與會的其他人也睡著了，後來我幫他把所有的UML圖全刪，精簡了一堆技術化的廢話。只留5頁最精華的，立項才算通過，給boss就講大局的就行啦。執行的時候，可以找碼農們去討論如何設計和實現！

一般中小型的項目，核心主程序員都具備一定的系統分析和設計能力，他們看了前端APP原型，理解需求，自己可以UML建立系統模型。人力不夠，或者涉及到大型複雜系統設計的時候，才會去再招個系統分析師來做這事。

產品經理的首要職責是抽象場景，管理需求，最終推動需求落地。立項時，找利益關係人，比如需求方，Boss等參與，這裡面主要講清楚業務流程就可以。研發時，xMind用於梳理功能，有利於功能規劃，版本規劃。原型草圖主要給交互設計師，UI設計師，APP工程師看。UML主要是給系統分析師/工程師看的。實例圖用於搭建資料庫，時序圖用於編寫介面，流程圖用於編寫輸入/輸出邏輯。狀態枚舉值用於狀態機開發用，狀態之外就是異常。

經驗上講：一般用UML進行系統分析的工作量相當於預先進行了一次「准編碼」，如果UML搭建出來的模型有問題，就在UML的基礎上修改，分析師和架構師評審OK後，再交付給碼農們正式編碼開發。也就是說，整個項目進行了至少兩次代碼編寫。通過這裡，可以看出UML會延長項目周期時間，至少1倍編碼時間，對於求快的項目，都會省略掉UML這種過程，直接對著prototype原型草圖開幹了。至於以後要拓展，要兼容的功能點，以後再說，先把當下過了。從這個角度來看，在一些創業型，小型，獨立的，趕工期的項目，很少有團隊去通過UML進行一次預設計——太費時！

以前做單機遊戲，離線工具，由於工作範圍單一，產品單一，用戶單一，設計產品的工具大部分是Axure，Mind之類的，沒怎麼用UML工具，最多畫個流程圖。但後來從事平台，大型通信SaaS，物聯網，交易系統設計和分析，就用上UML。

下面是我的一些項目經驗中涉及到UML的感悟：

Android系統工具：

由於我也當過Windows碼農，我就寫個Windows演示代碼給Android+Linux資深碼農，說我要在Android需要這麼一個類似功能，至於具體的數據結構和邏輯交互，他再自行安排就完事了。因為整個界面就一個輸入框和一個確認按鈕，我用Windows C#演示代碼用了300行搞定，但那位資深碼農用Java，C和彙編就寫了上萬行代碼。因為他要在Android上重新開發一個引擎庫，這個引擎庫要很多代碼量，但UI Java層和我類似，只需幾百行代碼。比如我輸入1，他就要對1的內存序列做解析，比如字元串的「1」，整數1的序列，長整數的1，浮點數的1.0，高精度浮點數的1.0，然後要對這五種1做不同的邏輯處理，五種之外他又預留了兼容處理辦法，以免我輸入額外的1，導致Android手機變成磚頭。

這麼複雜的系統，他用了UML工具嗎？沒有！因為我們項目非常急，三個月開發，然後火急上線！更重要的是，他是老手，他以前在就做成功過類似的事情，全公司只有他懂Android底層代碼，其他人也看不懂。所以，我們的APP一開始考慮非常簡單粗暴，甚至沒有登錄，註冊這些功能！！！產品上線後，APP激活數很大，三個月達到100萬。我們才考慮這裡加點登錄，那裡搞點廣告的，但也沒有做什麼UML建模，因為十萬火急要和超英趕美，所以費時費力的破事都省略掉了——包括UML建模。還有他高考650多分，985學歷讓我深信他搞這種純技術的事絕對沒問題！因為我覺得UML如果可以讓系統第一次設計正確率達到60%才可以開工，但有的人直接編碼整體正確率就可以達到90%，那就不需要UML了。

不過這裡面合作有一個很有意思的地方，我是需求提出方，他是底層代碼實現方，其實他說的技術術語我聽不懂，我的用戶也聽不懂，我說的需求他又覺得太飄。於是在我和他之間有這麼一位程序員幫了忙，這哥們也不寫代碼，他就理解我的大白話需求，然後翻譯成他的底層需求和技術用語，我老闆甚至覺得這哥們不寫核心代碼是不是沒有幹活。到現在我細想，他不就是在做需求分析，代碼測試的事嗎，只是沒用UML而已。

物聯網：

我要做一個綁定功能，就需要涉及到終端硬體系統，業務系統，資源系統，手機前端APP系統4個系統的整體交互。如果是放在以前的工作，我最多在APP畫幾個界面，交互幾個跳轉就完事了，但這完全不管用。說白了，那也僅限於APP系統設計，沒有後台系統，硬體系統支持，不管用。

我主要的精力集中於市場競爭，用戶體驗和APP前端原型的設計。我們組的項目經理就很厲害，研發開會的PPT就是架構圖，時序圖。我們的物聯網項目涉及到六、七個部門的溝通和交流，哪些功能該放在哪個系統里做，該放在哪個部門開發，他搞得清清楚楚，搞得同事們都沒脾氣了，按道理這事要吵一通架：這個功能應該前端開發，那個功能應該後端開發。這事讓我來協調，我也就能夠打通設計，APP，後台，但他能夠打通到硬體，接入，服務等部門。總的來說，他充當了需求分析師，架構協調師的角色。UML畫得很好，根據UML時序圖就清楚的看出哪些功能歸誰開發。公司的新專利會由他安排人員編寫，然後他來審核。

有時候我覺得產品經理要想推動項目落地，還是需要有個給力的項目經理和需求/系統分析師。

推薦系統：

如果僅僅是畫個破UI，商品詳情下面來個三個商品推薦列表，一頁！搞掂！3000塊實習生就能搞掂這個破頁面。但該展現哪三個商品，這又是另外一套系統來搞掂！

數據採集是一個系統，實時數據是一個分支，離線數據是一個分支，離線採樣試驗數據又是一個分支。

數據過濾又是一個系統，過濾方法有ABCD，權重有1,2,3,4。

然後就是個性化推薦分析。

最後是輸出結果。

手機通信：

要做一個手機eSIM上網的APP。UI就一個首頁。控制項就一個開關：開就上網，關就不上網。這個頁面讓掃地阿姨都會做！問題如何實現上網？需要一步步做系統分析。要涉及到4G無線通信系統。細分下來，基站系統，管道，運營商鑒權，SIM卡系統，高通晶元，Android底層系統，Service服務，APP UI系統，都要層層分析。這麼多系統之間有各種不同的通訊協議，光是這塊，我們就要招聘專門的協議工程師來打通所有系統的通訊。這個項目正式編碼就1個月，但是我在這之前做了建模，准編碼，就花費了2個半月——1個{啟動}按鈕按下去，背後涉及到數個系統，數千行代碼的編寫，我甚至用了偽代碼來表示邏輯演算法。

PS：之前的SaaS產品系統分析師直言不諱的就說我這個搞互聯網的就是一個畫UI，畫流程圖的（汗！）。因為光是畫原型/流程圖，項目是不能落地的，還得藉助UML進行更細更深的分析，很多底層工程師，系統工程師和協議工程師根本就不看UI，他們要的是系統分析的場景，流程，數據表，實體，活動，狀態枚舉，時序等等。產品經理/需求分析師需要拆解給他們。

按我的經驗看來，跨系統的應用/服務需要用到UML，很多東西不是畫個UI原型就完事了。之前我在做某個物聯網項目，立項的時候把原型畫好了給Boss們審核，結果他們說，別這麼急，還沒到界面這一層，先把場景，硬體，服務，協議全部打通再搞APP。

著作權和專利權：

軟體著作權申請文檔里需要提交結構圖，流程圖，用例圖，這些可以用UML來表示。最後還要附上60頁的代碼。

軟體專利就不需要具體的代碼，只需結構，流程，用例外加標註說明即可。

也就是說，專利聚焦於設計，著作權聚焦於實現，都會用到UML工具來建模。

所以：一般的研發序列是：先建模，驗證合理性，有重大創新的，緊急申請專利，再編碼，最後申請著作權。所以產品/項目經理不會畫UML，可以讓系統分析師畫。沒有的話，主程序也可以！什麼？沒有主程序，那就讓水平較高的碼農畫吧。因為專利和著作權是有政府補貼的！！！有的公司甚至用專利來掙錢，你可以認為他們公司的律師團隊都是UML看圖高手！

2B業務系統：

核心流程是如何設計訂單，訂單的起源來自於哪裡，訂單如何結算。一個訂單要從開始，到走完，要涉及多個公司，多個部門，多個操作審批，多個應用服務界面，才能完整的走完整個訂單流程。

招聘：

我們在做一個全新的B2B+SaaS系統，我負責前台分析和設計，我的後台工程師說一定要有全面可行的物理模型，他才會開始執行代碼後台開發，就這樣被卡一段時間。有大型系統分析/後台設計的產品經理/需求分析師，有興趣加入我們的，歡迎私信我。

UML是一個面向真實環境的標準建模工具，程序猿必學，一般多於大型軟體系統設計上，例如ERP。

產品經理，是這幾年互聯網流行起來一個辭彙，也是被業界和媒體大肆炒作起來業內的流行詞，不論什麼行業，只要跟「經理」一詞掛上鉤就立馬高大上了，最起碼脫離底層員工這一身份。

真是這樣么？未必。

為什麼產品經理很少討論UML呢？

現階段，至少2018年前，國內產品經理還是魚龍混雜的行業，沒系統方法論，也沒有行業標準，好像只要跟產品兩字有關，你工作就是產品經理活兒似的。同時，產品經理三大必備文檔之一：產品需求文檔中就有涉及到流程圖、時序圖及狀態圖，這些例圖的概念都源自UML，只是因產品經理所處行業不同、水平不同、出身不同對這些圖理解上出現偏差。

還有一些大型互聯網公司，好像產品經理只需會畫流程圖，其它不需要，一般不會用UML畫圖。一是PM對技術理解的專業性不足；二是自身對事物理解不夠細緻深透。也就很少過多去討論其中細節，是因產品經理只需要把其產品需求及功能開發描述清楚就行了，真實情況也是這樣。

UML只是個工具，用不用更多在於你表述問題是否簡單直接清楚明了，而不是在於使用何種工具。

就此打住。

做過很多年的表示剛畢業時也認為uml沒用，因為沒幾個公司用也看不懂，當時的狀態就是會畫，不知怎麼用。

做了多年後發現uml非常有用，不會用的人基本上沒有了解什麼時候該畫什麼圖，什麼時候有必要畫什麼圖，各種圖都該給誰看。

首先uml圖的作用就是統一認識和分析結果，有人會說統一認識寫文檔即可，純文字和空口白牙的講一樣會產生理解差異，團隊項目最怕理解差異，因為產生理解差異，你說的是這個意思，他理解的是那個意思落實到代碼就跟需求不一樣了，而且外包項目更關鍵。

尤其是有外國人參與的項目，英語、法語、義大利語、日語、韓語等且不說因為翻譯問題產生的差異，各國習慣不一樣純文字的文檔更是會產生理解差異。而uml的一大作用就是用圖片為主輔以文字使得項目組開發人員之間能統一認識，消除理解差異。

當然非外包敏捷式開發可以簡單一些，但是不表示可以不做需求文檔，不畫uml圖，依然要在充分需求分析的基礎上展開，只是確認能在項目組內達成共識的簡單需求可簡化或省略，但是在複雜需求上不可省略。

建議還是得學一下，雖然是一種建模語言，對於現在很多自稱產品經理的人來說可能有點難，但正常一個大學畢業的估計最多花兩周就能摸透。沒有其他比uml圖更適合更容易描述需求了。

個人輸出文檔：uml（時序圖、類圖、用例圖、狀態圖）+xmind+axure+word

先回答下一個子問題。

「為啥不常見討論？」

主要與"產品經理大江湖"的水性有關。

在輿論的江湖上討論少，並不代表 UML 對 PM 的日常工作沒價值，而事實可能正好相反，UML 對於 PM 團隊的業務分析、產品設計、系統開發用處很大，而且系統越複雜，UML 的價值越大。當然，這只是業內少數專家（如 UMLGreatChina 首席專家張恂老師）的認識和看法，屬於小眾。

那為什麼似乎江湖上的大多數人不知道，不理解，或者還沒意識到 UML 的巨大價值呢？我看這主要與傳播學、營銷學等方面的應用，以及科普沒做好有關。

這就像 2000 年之前的神州，大部分軟體人不知道要做版本控制；2005 年之前，大部分人不知道要寫單元測試；2010 年之前，大部分人不知道迭代、演進才是當代軟體開發的正道......可是你能說，因為之前大家的討論少，所以版本管理、單元測試、迭代開發之類統統都沒用，沒價值嗎？不能吧，時間已經說明了一切。大眾的認知、領悟需要一個相對緩慢的過程。

所以，UML 啥時會在 PM 大江湖上熱起來，我看還要繼續做好功課，等待時機。

。。。

UML 的意義在於 unified。這個東西不 cool，HTML 也不 cool。不 cool 的東西要想有用，就要有其它優勢。UML 和 HTML 的承諾都是 ubiquitous 和 heave-lift。這兩個東西缺一不可。如果沒有 heave-lift，就算你的東西滿大街白送，人家也不會要。

不同在於，HTML 做到了這兩點：HTML renderer 很難寫，但是又每個平台都有。UML 沒做到：畫個普通簡圖誰不會？而 UML 的 render/editor 既沒有做到底層格式統一，也沒做到視覺效果完全一致。所以UML 是一個既不 cool，也沒用的東西。

我見過的產品經理，一個懂UML的也沒有，完全不必討論產品經理用不用UML什麼的。

當然，往好處想想，我見過的程序員，懂UML也一個都沒有。

UML在我們這行快成車庫之龍了，除了一些真的屌爆了的企業，根本沒有人去堅持用下去。

UML比較程序員也比較笨重。

UML中流程圖還比較常用。

用例圖可以用文檔替代。

類圖、活動圖等程序員用。

日常工作，Mou + Sketch + MindNode 基本就夠了。

文檔的本質還是溝通和備忘。標準化的流程執行不好，反而增添負擔。

做碼農前幾年，也覺得UML似乎沒啥用

然後最近1-2年UML用的越來越多，因為發現它確實有用

不清楚再過幾年，自己會不會再次改變看法（對UML的）

UML的規範太過複雜，真正有用的部分個人認為不超過20%。但這剩下的80%妨礙大家真正去掌握並運用它，所以出現大量負面評級乃至推廣受阻，真的不足為奇。具體到產品經理這個角色，我覺得UML雖然是model工具，但真正能幫到產品經理的部分不是很多，它其實更適合具體設計而不是概念整理和原型設計。另外，市面上好的UML工具極少，要麼很貴。

概念圖的標註越多，其價值越小

總結了這幾年的說法，UML主要是不cool，沒什麼特別不好的地方，也沒什麼特別好的地方。

產品經理這種角色怎麼可能會去看/畫 UML圖？！

現在提UML，必有人噴『笨重』，畢竟它是軟工鼎盛時期的產物。

產品狗講的是用戶故事（userstory），通俗易懂的語言描述；

交給程序狗，他們轉化成用例（usercasediagram），這玩意兒有邊界（boundary），有活動（activity），有角色（role），並可直接交有測試狗去推導測試用例（testcase）；

他們接著會做靜態模型和動態模型，映射到UML的規範里：靜態模型體現為classdiagram、componentdiagram、或者再後期的deploymentdiagram，動態模型則是sequencediagram、activitydiagram。

UML是程序狗們之間交流的最好語言，（假設他們對uml各模型、概念、元素是掌握比較好的）那用UML清晰高效。

學習開源組件或系統時，幾個主要的UML圖也會快速有個宏觀全局的認識和了解。

總之對於技術人員來說，UML是十分有用的。

個人經驗

上學的時候學過怎麼用,工作中完全不用.

但是學怎麼用的過程中學到的東西工作中用的到.

同樣是畫流程圖...能畫的條理清晰邏輯嚴謹模塊明確也是能比一般人厲害那麼一點點的.

當然,這是不是UML的功勞就另說了.

uml是一種語言，是所有參與者有共同認知的語言，都說降低學習成本，讓別人一看就懂，不使用同一描述，自己畫一個別人很難和你第一時間理解一致，uml不在視覺在於方便交流而已！

大公司架構師用的，小公司程序員用的

我在大三暑假, 有一個學醫的妹子說要畫 UML 的類圖 (不知道她什麼課), 然後我按照她的題目要求, 認真畫了一下, 不知道過了多久, 有一天我發現我微信被她拉黑了~ 哦耶!!

學校的軟體工作坊的課老師有要求要用 UML, 作業要評分數, 老師說很重要. 我工作的時候從來沒有用過, 當然也有可能我還沒有要到用的時候吧~

討論這東西,感覺就和討論演算法和數據結構在實際工作中的作用一樣, 看人

其實一個軟體還能被拿來討論有沒有用這個話題，那它必然是還有用。所謂無用的話，只是無用的領域比較大（比如這些年最火熱的網頁啊，app開發啊，直接axure高保真都出來啦，當然用不著麻煩還不美觀的ｕｍｌ），但是對於小眾但實實在在需要邏輯能力比較縝密的各種軟體開發，比如進銷存軟體啊　ＥＲＰ軟體啊這些，相對視覺和交互，對於功能架構的要求更高，這個時候ＵＭＬ的優勢就顯現出來啦，這是這些軟體開發不是互聯網主流市場，懂的人少而已，但並不表示無用

　　　　　　　　　　　　　　　　　　　　－來自於一個也是不懂ｕｍｌ的土鱉ｐｍ　　　　

許多流行起來的開源項目（Linux、Apache、MySQL...）確實沒有使用UML建模，但是這些項目的核心領域多為基礎設施領域。基礎設施領域的"負載"（需要依賴的領域的數量）比較低，只需關注計算機的資源，不需關注醫院、稅務、物流....。因為負載低，基礎設施級別的分解和復用相對容易，而且基礎設施領域有大量的教材和先行例子，程序員在學校里已經受過這方面的教育，大腦比較容易把握基礎設施領域問題的複雜性，所以對顯式建模的要求沒有那麼高。

很多能夠帶來利潤的系統"負載"比較高，除了核心領域（如醫院）的知識，還要依賴於其他非核心域的知識，而且，核心域並沒有那麼多人去研究。很少有類似這樣的書，把一家醫院的流程，各種業務對象之間的關係，用某種方法（彩色UML建模也好，以前的數據流圖＋ER圖也好）研究得透透的。要在市場上獲得競爭優勢，有必要把復用的級別提升到核心域的復用（因為其他的好處，競爭對手也能獲得），這確實很難，但再難也要做。這時，建模技能就必不可少了。

在這方面，不少媒體有誤導。媒體會訪問某些「知名程序員」對建模的看法，得到的回答可能是「對我來說不重要」。這裡面的原因是：基礎設施領域的程序員更容易得到媒體青睞成為「知名程序員」，因為「晶元」、「操作系統」等辭彙上的光環會把媒體晃暈。更不客氣地說，其中一些「知名程序員」實際上僅僅是「玩家」，不了解開發帶來利潤的軟體需要付出的辛勞。

和我們生活工作密切相關的軟體，媒體關注得太少。一名白領，早上起來用微波爐熱牛奶，開電視看新聞，坐電梯下樓，刷卡坐地鐵，手機看微博，打卡進公司，用公司的業務系統工作。上面這句話中涉及到至少七個系統，其中估計只有微博的開發人員能登上媒體的版面。你知道微波爐的軟體是誰寫的嗎？大多數開發人員做的軟體和「知名程序員」不一樣，讓「知名程序員」來做這些軟體，也未必做得來。Linus能做好一個醫院信息系統嗎？

轉自：UML八大誤解