”圖解”產品：產品經理業務設計與UML建模

過時+簡單。同時也說明一個問題，其實打工人做的事情基本上都不是什麼很難度高的一件事情。早期的產品經理就是這樣的水平啊。且我也不認爲微信是一個很複雜的產品，就是這麼簡單的產品確是用戶最多的產品。 所以需要自信，從心底的認爲自己做的東西有價值。因爲不是越複雜才叫越有價值。

認真地看完了這本書，對於產品同行們來說，可以快速瀏覽閱讀。 這本書主要介紹了一個模型，包含四層九要素： 定方向（產品戰略、解決方案）、 搭框架（功能框架、非功能框架）、 做細節（業務流程、業務操作、信息結構） 畫界面（信息設計、交互設計） 個人覺得比較有用的部分是介紹功能框架，業務流程，業務操作，信息結構這幾個部份，作者分別介紹了uml的幾種圖：用例圖、業務流程圖、狀態圖、類圖等，並詳細介紹了這幾種圖該怎麼畫，這些是可以在書中學習到的。 對於自己來說，給自己啓發的幾個點： 1、要從用戶需求出發，站在用戶的角度思考問題，而不是一開始就從系統角度，應該要做哪些功能； 2、在信息結構這塊，要梳理類的屬性，類之間的數量和關鍵關係，這對信息的呈現來講有重要關係；

本書最有用的內容就在最前1-2章介紹的產品設計結構。後面的UML純從結構化思維來看，有沒有無足輕重。其次，UML最初出現是爲了，設計能轉換爲開發語言減少工作量，後續慢慢脫離實際迭代要求的場景就慢慢退出舞臺了。

本書更適合B端產品經理 主要講了4層9要素 產品戰略和解決方法 產品框架：功能類，非功能類 業務流程 界面設計 提到了UML

太差了，和書的主題都不匹配，講了些不相關的。

產品經理一方面要梳理線下業務流程，明確用戶到底想要什麼（用戶需求），另一方面要爲產品開發團隊給出產品需求，明確待開發的產品如何支持用戶的需求，這之間的橋樑就是“業務模型”。 不同的業務構造出的“業務模型”本身是千差萬別的，但“構造技術”相通，基本都來自UML，大部分的產品經理也有了解或使用這種技術，說明UML在產品設計中是一種有用的工具，但爲什麼大部分產品經理使用不起來呢？放在需求文檔中，並沒有對文檔的完整度、清晰度、準確度做出貢獻，更像是一種點綴。 我自己的感受是標準的UML過於概念化，而且實際上更偏向於一種軟件編碼設計的工具，對產品經理羣體不是很友善。關於產品經理如何使用UML的資料，也都是碎片化的文章。 對於我而言，本書可以看做是寫給業務產品經理日常工作手冊。其中印象深刻的，有如何使用UML設計產品用例、業務流程、產品信息結構的最佳實踐，也有常見的非功能需求列表，很有指導價值。除了這些“術”，也給出一個“道”，以業務爲中心的四層九要素設計框架（和《用戶體驗要素》中以用戶體驗爲中心的五層十要素設計框架類似）。 還有一點，這本書的編寫和思維方式也值得學習，以“演繹”的方式，從作者設定的業務設計框架和定義出發，逐步推演出一部關於業務類產品設計方法的“大廈”，和我們產品經理追求寫出一個高質量的需求文檔一樣，本身就具有較好的完整性、清晰性和準確性。也可以跟隨作者的思路和知識“地圖”，再次擴展。 最後，我真正做產品策劃這小半年以來，體會到產品設計不是紙上談兵，仍然是一門實踐性極強的崗位，需要將學習到的知識真正應用到產品設計中，才能成爲自己的知識與智慧。

在書的最後，作者強調了 UML 和用戶故事之間的關係部分。致謝部分也提到了張恂老師。這讓我想起了一段往事。 幾年前我曾經和張在知乎上有幾次爭論。我的觀點是，產品經理最重要的是市場和品牌管理，以及用故事界定產品。建模交給架構師和技術團隊。Scrum 過程對產品經理的要求是做好客戶代表，重點是驗證模型，而不是即寫故事又做模型。否則你讓在研發部門的業務架構師、需求分析師幹什麼呢？你如果越俎代庖，怎麼發揮架構師和工程師用uml建模的專業性價值呢？你又怎麼確定產品經理的uml建模的準確性呢？ 爲什麼會有這個爭議，就是因爲互聯網的爆發將產品經理崗位職責泛化了。 所謂產品經理，就是產品的管理者。而產品是企業用來出售營利的商業單元。產品經理要解決的核心問題是：做什麼，賣給誰，怎麼賣。這三個問題中，第一個問題是產品形態問題，第二個問題是市場問題，第三個問題是營銷問題。因此，市場營銷和領域知識是產品經理的核心技能。但反觀互聯網產品經理，把重點都放到了領域知識上，甚至深入到技術研發的角度，這是錯誤的。 技術研發有專門的研發團隊幹。我不認爲有純粹的技術團隊。技術是用來應用的。科學可以純粹，但技術不行。因此技術人員必需能把握產品的應用方向，就是要和產品經理雙向奔赴。只是產品經理重點放在如何通過產品打通市場上，技術重點放在研發出根據產品經理規劃滿足市場需求的產品上。 相對大量學計算機的技術人員而言，經過市場營銷訓練的產品經理更加難得。讓產品經理用軟件工程工具建模，是暴殄天物，也是對工程師專業性的褫奪。

剛看到書名時有點開心，可算有本產品相關的書籍和UML深刻結合起來，也印證了我的產品道路是正確的，至少沒有走偏。大部分觀點和作者一致，能產生一些共鳴。軟件是互聯網產品的載體，互聯網產品經理應該掌握軟件工程方面的知識，並探索出屬於自己的方法論靈活運用。 對於UML，是一種工具，目的是建模，抽象現實，使用哪些圖、細化到什麼程度因場景、閱讀者而異。 對於產品文檔，當然是越詳細越好，但時間成本也相應越來越高，“用最少時間，編寫最少內容，且該文檔能被研發人員快速看完、正確開發”是非常理想的狀態。 對於流程驅動、用例驅動、領域驅動，對於瀑布、RUP、敏捷開發，對於用例、用戶故事，是軟件行業發展到不同階段解決不同問題的產物，沒有孰優孰劣，應該根據產品情況、項目規模選擇性使用。

太水貨了這本書，沒有啥乾貨，看完只覺得浪費我時間。 第一次看目錄還覺得挺有看頭的，說不定可以跟平時裏工作場景進行一下驗證，便加入到書架中，抽國慶空閒時間翻閱了下這個書，結果沒想到看完以後啥收穫也沒有，廢話一堆還故弄玄虛，將幾個所謂的理論百度粘貼後堆砌在一起後就開始水字數，再自己臆想中一下實際案例，還不如大學老師爲了水資格出的教材質量高。本書唯一的看點就是目錄這塊了，回頭可以搜關鍵詞找找對應的材料看看。 氣死我了，一般的爛書我忍忍就算了，這次算我走眼浪費寶貴的國慶假期看這破玩意，不吐不快！

我是書作者擎蒼，感謝各位閱讀，大家可到公號「圖解產品設計」上學習更多知識和案例。[微笑][微笑][微笑]