產品經理:流程圖你都會畫嗎?
流程圖是產品經理必不可少的技能之一,但流程圖你僅限于只會畫基本框圖和跨職能流程圖嗎?本文就來介紹下與產品經理相關的各種各樣的流程圖表現形式吧!
本文目錄:
- 流程圖分類;
- 行為型的圖;
- 結構型的圖;
- 總結。
一、流程圖分類
UML有很多種,大體可以分類兩類:行為型的圖和結構型的圖。平時工作中的流程圖,只要能把事情清晰的表明,用何種流程圖表現形式,其實都無所謂。
但是,作為一名產品經理,共有哪些種類的流程圖在工作中有可能會遇到或者用到,你是不是應該要了解一二呢?說不定哪天你就需要用到其中一種。
二、行為型的圖
說明:作為產品崗,行為型的圖我們要著重了解,甚至是活學活用。
- UML活動圖
- UML狀態機圖
- UML序列圖/時序圖/順序圖
- UML用例圖
1. UML活動圖
某一個角色通過多個動作完成某項工作的過程。
舉例:把水果放冰箱
活動圖中的圓邊矩形,表示流程中的活動,多個活動之間的帶箭頭線條表示活動的先后順序。
該圖只是表現一個正向流程,了解一個新事物,建議從簡入手,先去掉所有判斷條件,拿生活中常見的生活場景舉例,達到融會貫通。
2. UML狀態機圖
某個事務狀態改變的過程。
舉例:一個問題從提出到回答的狀態變化
整個過程是問繞著“問題”這個事務進行的。每一個綠色的框框代表一個當前問題的狀態。同樣,從簡入手,先不考慮復雜的情況,學會再說。
3. UML序列圖/時序圖/順序圖
多個角色參與,期間經過多個步驟,最終完成某項工作的過程。
舉例:顧客在某APP點個外賣
圖中有三個小人,每個小人代表一個角色。角色與角色之間有一條線條連接,表示角色之間如何交互。顧客點外賣,涉及到幾個角色,幾個過程,如果遇到此情況,可以考慮使用UML序列圖。
好處在于能夠清晰的表達整個過程所涉及到的角色,以及角色與角色之間的關系,各角色是如何參與到此過程中的。
4. UML用例圖
什么角色通過軟件系統能做什么事情。
舉例:我要在某個系統向某位同事提問
設計任何一個系統,首先必須搞清楚有哪些參與者,這些參與者都能在系統里做什么,都有什么功能。
那么使用用例圖來表示,再好不過了。用例圖其實還有更復雜的表現方式,比如擴展(extend)、包含(Include)。
1)包含(Include)
包含關系用來把一個較復雜用例所表示的功能分解成較小的步驟。如果是將一個功能拆解,大事化小,可以使用包含關系。
【箭頭指向】:指向分解出來的功能用例
2)擴展/繼承(Extend)
擴展關系是指用例功能的延伸,相當于為基礎用例提供一個附加功能。如果是兒子與父親的關系,那么就是某功能繼承自上一個功能,可以使用擴展關系。
【箭頭指向】:指向基礎用例
三、結構型的圖
說明:結構型的圖,大部分我覺得知道就好,大部分是開發小伙伴需要精通的東西,我們產品人實在需要用到,請教下開發小伙伴們就好。
不過,如果對技術感興趣的產品經理,我覺得你可以鉆研一二。俗話說,技多不壓身嘛!
- 類圖
- 對象圖
- 構件圖
- 部署圖
- 包圖
1. 類圖
某一類東西的抽象或者統稱。比如:人類。
說明:每一個軟件系統都會牽涉到很多人、業務和物品等,這些東西之間可能會有很多關系,發生很多事情。
類圖就是任何一個系統、任何一個項目的底層,能幫助我們識別出這些人和事,并理清他們的關系。
類(Class)一般包含3個組成部分。第一個是類名;第二個是屬性(attributes);第三個是該類提供的方法( 類的性質可以放在第四部分;如果類中含有內部類,則會出現第五個組成部分)。
類名部分是不能省略的,其他組成部分可以省略。類名書寫規范:正體字說明類是可被實例化的,斜體字說明類為抽象類。
屬性和方法書寫規范:修飾符 [描述信息] 屬性、方法名稱 [參數] [:返回類型|類型]。
屬性和方法之前可附加的可見性修飾符:加號(+)表示public;減號(-)表示private;井號(#)表示protected;省略這些修飾符表示具有package(包)級別的可見性。
如果屬性或方法具有下劃線,則說明它是靜態的。描述信息使用 << 開頭,使用 >> 結尾。類的性質是由一個屬性、一個賦值方法和一個取值方法組成。書寫方式和方法類似。
2. 對象圖
類的實例化,描述一個具體的東西
說明:需求分析時,其實我們接觸到的是一個又一個具體的東西。比如:見到一個個具體的人,一份又一份具體的業務數據等,這些具體的東西其實就是對象。
類圖和對象圖的區別:
無論是類圖還是對象圖,其實都是為了方便構思數據庫底層的數據表結構該如何設計,表與表之間有什么關系。
對象與類是很類似的,人是一個類,但男人和女人就是人類的實例化,表示具體的對象。在數據庫中,有可能就會有一張男人表、女人表;也有可能只有一張叫Person的表。
下面三種圖,產品經理幾乎用不到,此文不過多闡述,如需有小伙伴需要了解,可私下交流。
- 構件圖:用來描述軟件內部物理組成的一種圖。
- 部署圖:描述系統如何部署、本系統與其他系統是什么關系的一種圖。主要是物理設備,區別與軟件設計維度的系統架構設計。
- 包圖:將同一類業務形態的類圖打包放一起,便于維護管理與閱讀。
總結
結構型的圖,如果有點技術背景的小伙伴看,可能會更加清晰明了;如果是非技術出身的產品小伙伴有哪里不夠明白的地方,歡迎留言交流,互相學習互相進步。
作者:會飛的豬能上樹,微信公眾號:刻意練習產品經理(ID:kylxpm520)
本文由 @會飛的豬能上樹 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自Unsplash, 基于CC0協議
學習了!
什么軟件畫
坐等樓主回復
visio就可以啊
大神,提供個轉件下載地址唄!
關注我公眾號,有送工具下載地址
很詳細,很落地,很有用,贊
今天發推文了嗎你,就在這劃水
今天發推文了嗎你,就在這劃水
軟件工程和管理信息系統的流程圖畫的最標準
信管專業路過
怎么簡單怎么來就好,軟件工程肯定最標準
2. UML狀態機圖 那邊“問繞”是打錯字了吧
親,真細心,是圍繞
問題分類包含哪兒是不是寫錯了?問題分類包含新增問題分類、修改問題分類、刪除問題分類、搜索問題分類等等,而不是問題
內容只是舉例,會用就好
用例圖終于看懂會用了,非常棒,謝謝作者。
不客氣,有幫助就好
感覺直接原型整起來
流程圖是必備,至于流程圖的表現形式就不用糾結
這么畫開發一定很好理解吧。。。
就是我自己不太好理解
怎么簡單怎么來就好,我只是全部列出來
天秀~~
拿本大學教材《軟件工程》看看比較靠譜
正解
好像是《系統分析與設計》 ??
我們是系統分析與設計
看來同是軟件工程專業哈哈
不,我是信息管理與信息系統
大學教程是正規系統,就是不夠輕便?,F在產品都很少畫E-R圖這些了。
怎么簡單怎么來就好,我只是全部列出來
當狀態較為復雜,且根據不同邏輯,事務可在不同狀態間變化,這樣的情況,上述UML的狀態機理圖能較好的滿足嗎?
比較復雜,建議用泳道圖
泳道圖該怎么畫更容易理解呢
將一件事描述清楚
很硬核
謝謝