[D3-2] 當你不小心踏入PMI-PBA的陷阱之後，要在對的時候用對的圖形表達你的想法。

26 種圖形、表格和模型不是讓你用來填報告書厚度的。

1. Business Objectives Model:
   看到 Business Objectives 這個名字，你就該肅然起敬， Business Objectives 耶，這講的是你公司的企業目標，而不是商業目標，這兩個翻譯的差別很大。當你看到這個 Model 的時候，請馬上直覺反應這事情不單純…
   因為身為 Business Analyst 的你，必須埋頭挖掘公司現在面臨的問題。請記得挖公司外部的競爭問題，不是公司內部的問題…那還輪不到你來挖，除非你是老闆…不，是老闆的話，你根本不可能想去挖。就像挖井、挖糞、挖金礦一樣，你永遠不知道挖到的是什麼，是大便還是黃金？端看你怎麼運用它，豬糞也是可以變成黃金的。
   當挖到問題後，請將腦袋的思考邏輯轉個方向，思考當這個問題解決之後，你公司會得到什麼，能夠得到的東西就是 Business Objectives，於是乎，你可以得到要達成這個 Business Objectives 的解決方案，可能會和哪些系統相關，然後，我們就進入到 Ecosystem Map了。
2. Ecosystem Map:
   有鑒於上一段寫得太多，我決定接下來所有的工具都簡單寫…這不是偷懶，而是你能想像自己看完 20幾段上面那樣的文字嗎？我承認我不行，很懶。做好一件工作，重要的不是搞得多複雜難懂，而是搞得越簡單越好，某位姓蓋茲、名鼻耳(每個人都有鼻子和耳朵！)的世界首富曾經說過：「世界的進步是由懶人推動的。」好的，我完全贊成這句話。我愛懶人。
   所以，上面的廢話這麼多，你想也知道我只想跟你說， Ecosystem Map 的作用很簡單，它就是將你想開發的系統(人或組織都行)放在圖上，然後把周遭所有相關連的其他系統都畫上去，不論它是間接還是直接的，全部通通都畫上去就對了，但記得將重點系統畫出來就好，不要手癢又多畫了很多有的沒的，因為這張圖在你有生之年大概只會用上個那麼一次…
3. Context Diagram:
   一不小心上面還是廢話太多。所以，相對於 Ecosystem Map 那麼大一張圖來說，Context Diagram 就更簡單了，你看範例圖就知道(避免版權爭議，我就不貼圖了，請翻閱 BAG p.96)。
   就像是把 Ecosystem Map 簡化一般，在圖像正中央的就是我們可愛的、機車的、打算開發的系統，其他周遭的方框都是直接跟它連連看的其他系統。就這樣！畫出直接連結的系統就好，還是一樣再次提醒…不要手癢！再畫就把你手Ｘ掉！(自主規律中)
4. Feature Model:
   好了，從 Context Diagram 中我們可以看到相關連的系統之後，就大概知道會有哪些功能需要開發，因此，再看到這張圖就很簡單了，最常用的說法就是叫它樹狀圖，簡單來說，就是把你要開發的系統(簡稱開系？發統？)中所有的功能依照大項目、中項目、小項目的方式，一路寫出來，寫完之後，我們就可以拿上面的大項目放到 Use Case Diagram 上了。
5. Use Case Diagram:
   Use Case Diagram 大概是軟體業中最愛畫的一張了，第一次看到它已經是二十年前的事(煙~)。簡單來說，這張圖最大的重點是左右的人形，它們代表的是和系統互動的人(Actor)，有些比較大的系統，可能會有十幾種 Actor 會和系統互動，而且有些 Actor 不一定是真的人，而是另外的外部系統。
   過去為了簡便，圖中的每個圈圈是由 Feature Model 中的大項目而來，但這樣的做法因人而異，因此，你得視公司文化和上司的喜好而做出改變。
   當我們在圖上看到有哪些 Actor和哪些小圈圈(Use Case的簡圖)互動後，我們可以知道在不同需求下大致的操作邏輯，而這些邏輯可以用 Process Flow 來呈現。

Scope Models的用途是在幫你將範疇定義出來，有了範圍，你才不會迷失方向作出無謂的浪費(Scope creep)，接下來就是開始進入 Process Models囉。

1. Process Flow:
   又稱流程圖、泳道圖。對，就是那個有著 Yes or No 的菱形的流程圖。而泳道(Swimming Line)則可以將之視為不同部門/模組該做的事，一條泳道一個部門/模組。這張圖大概是我看過最受工程師歡迎，但也最快被改來改去然後丟掉不用的一張圖了。
2. Use Case:
   通常我將 Use Case 稱之為系統規格文件，雖然不完全正確，但比較容易理解。這個表格可以和 Use Case Diagram 相互連結起來，因為在 Use Case Diagram 中每個可愛的小圈圈都是一個 Use Case，畫個圈很簡單，但要寫出裡面的所有資訊就沒那麼簡單了。
   雖然 Use Case 在開發過程中是必要的文件，但當你看到 Use Case 這張表格中描述的所有資訊時，我就不相信你有辦法認真看下去…當然，你必須看過一次並快速了解它，然後就將它丟在旁邊吧，因為隨著系統開發進度的發展，每張 Use Case 都會改啊改的，永遠改不完…喔，對了，我有說過這張表其實是給人看的嗎？對，當你想睡又睡不著的時候就可以看的。
3. User Story:
   這大概是我最愛的工具了。在系統開發的最初期，你得去了解用戶想拿你的系統幹什麼事、怎麼操作你的系統(想象中)，或者甚至是他們現在用什麼方法解決你想解決的問題的(好繞舌…)。通常來說，我會用錄音機將訪談內容錄下來之後，再回頭慢慢將 User Story 整理出來，如果你想一邊訪談一邊整理，我不反對，但會祝你好運。請記得，User Story 就是用戶在使用你系統時發生的故事，有時間前後順序的，千萬不要寫成條列式的需求表囉。

其實 Process Model 也不過就這麼簡單，告訴你流程方法而已，然後，我們要注意的是這些流程方法是否符合公司的規範，也就是 Rule Models。

1. Business Rule Catalog:
   這沒什麼好講的，其實就是公司規章，也就是開發系統時，必須絕對遵守的規則和規範。譬如說：公司加薪的規範是每年最高加 3%，你就別忘記把系統內的加薪規範檢查欄位忘了加上這條規則，否則到時候死的絕對不只是你一個人。
2. Decision Tree & Decision Table:
   嗯，一次講兩個。這絕對不是我偷懶，而是 BAG 上面就是這樣寫的。為什麼？因為這兩個工具基本上是同一件事，但在不同情境下使用。
   Decision Tree 適合在單純、單一條件下(喊1做A，喊 2做B)。
   Decision Table 適合在複雜、多重條件下(喊1+2做A，喊2+4+3做B)。
   就醬，這麼簡單。通常來說，工程師都喜歡 Decision Tree，但做到最後都會自己想辦法畫 Decision Table，因為他們會發現事情從來不會那麼單純…

公司的規範是如此的絕對，不能逾越，所以，兩組工具就足以寫上一大堆了…有了規範，我們可以在安全的舒適圈裡開始腳踏實地，設計資料、填寫資料了，所以接下來的 Data Models就要肩負起這個責任。

1. Entity Relationship Diagram:
   簡稱(常稱) ER Diagram。簡單來說，就是在系統內的資料、角色、模組間的零/一對多(0/1…n)、多對多(n…n)、多對零/一(n…0/1)的關係。
   譬如說，一個爸爸有兩個小孩，一個小孩只會有一個爸爸和一個媽媽。如果你和資料庫工程師熟悉，請他打開資料庫中的表格(Table)關聯圖，就可以看到展開來一大票、一大堆方框框的 ER Diagram 了。
2. Data Flow Diagram:
   要注意的是，這張圖上所有談的事情都是和資料有關，無論是資料(Data)的儲存(Store)位置、被處理(Processed)的位置，以及這些位置之間的關聯性，甚至是由哪個人(Actor)產出這些資料，取得這些資料等等。
3. Data Dictionary:
   再次說明，如果你和資料庫工程師熟悉，請他打開資料庫設計表，就可以看到這張圖了。簡單來說(我好常用這句話…)，它就是資料表的設計說明。如果你和資料庫工程師不熟的話，那我假定你和 Excel 熟悉，打開 Excel 開始製作表格，那就是它了(誤)。
4. State Table & State Diagram:
   又來一次講兩個了，我愛 BAG(大誤)。這兩個工具實際上是同一個，只不過是將將系統的各種狀態，一個用表格(State Table)的方式呈現，另一個用圖形(State Diagram)的方式呈現。而且聽說 State Diagram 是許多工程師喜歡看的圖，我真的不懂，這又不是美女/帥哥圖，怎麼那麼愛看這張圖？
   嗯？因為這張圖可以一目瞭然地協助工程師追蹤 Bug？這句話見仁見智，看你怎麼運用它而定囉。

將資料整理完畢之後，我們擁有的是非常非常多的數據，也許你會稱之為大數據(現在還是很流行)，但更精確的是你有了處理這些數據的方法。因此到現在你有流程、有資料，系統差不多可以做好了，接下來就是要提供操作介面給人用囉，那就是 Interface Models 的工作了。

1. Report Table:
   不囉唆，又是一個給人看的工具。囉哩巴唆寫了一堆，其實只是為了應付應付，繳交報告而已，交完之後，大概只有遇到外部審查的時候才會拿出來說：「你看！我有做這些工作！」。通常來說，大多數時候都是寫在 E-Mail 裡面就好，而且也不會每次都寫這麼多項目…除非你跟PM還是BA有仇…不然就是跟你的上司、老闆過不去，跟他們過不去就是跟你的口袋深度過不去…
2. System Interface Table:
   這是系統和系統之間的溝通規範，通常被稱作系統開發規格書。最常看到的地方是在軍用系統，也就是一點錯誤都不能犯的地方。這個工具會規範出系統間溝通的時候所需要採用的格式、協定和反應時間等等資訊，以人話來說，就是系統間溝通用的語言文法。因為如果A系統講的是英語，B系統講的是法語，你總得提供兩個系統對方的文法書，彼此才看得懂對方說什麼鬼話吧？
3. User Interface Flow:
   直接翻譯：使用者介面流程圖。簡單來說就是一張 over-all 的 UX 設計圖。裡面每個方框都代表著一張系統的畫面(視覺/UI)設計圖，而每個連結就代表著是：「按下上面這個按鈕會跳到下面這個畫面」這樣的意義。
4. Wireframe & Display-Action Response Model:
   Wireframe 講的其實就是 UX 設計圖，你可以清楚地在圖上看到畫面上哪邊該放圖片，哪邊該放說明，哪邊該放按鈕，而每個地方全部都有個編號對應到 Display-Action Response Model 上的說明。
   在 Display-Action Response Model 中，則是針對每個編號說明它在每個狀態下的動作，以及對自身物件的變化(譬如按下按鈕後要從紅變綠)。
   我通常的做法是在 A4 大小的 Word 中，將Wireframe放在左上角，它正下方放視覺設計圖(UI)，而右邊則放著一整張的 Display-Action Response Model，而每張 A4 則會對應到 User Interface Flow中的某個框框。
   這樣形成 UX(Wireframe)+UI → 動作說明(Display-Action Response)→操作動線(User Interface Flow)，因而在開發系統的時候，就非常一目瞭然了。

以上！所有 BAG D3 的 Models 結束！

從 Scope Models(範圍)、Process Models(流程)、Rule Models(規範)、Data Models(資料)、Interface Models(操作介面)，終於可以把我們對整個系統的想法給文件化、說清楚了。

1. Organizational Chart (組織圖：跟公司要就有，見 BAG P.40)
2. Decomposition model (分解模式：見 BAG P.63)
3. Fishbone diagram (魚骨圖：PMP 講很多，見 BAG P.22)
4. interrelationship diagram (關聯圖：見 BAG P.23)
5. SWOT diagram (優劣分析：見 BAG P.19)