前言
身為軟體產品經理，其必備能力當然是理解什麼是軟體、軟體是怎麼樣開發、形成的。但不諱言，許多公司並非很在意這項必備能力，當然，這件事情沒有標準、存在很大的模糊空間，每個公司的軟體開發背景不同，會根據當時的時空背景所留下來的慣例所影響（好的開發慣例叫文化、不好的開發慣例叫歷史共業）。
再者，軟體產品經理的基本功將長期影響軟體維護性與擴增性，但在短期內的影響並不是這麼顯著，所以有些公司更重視商業模式與提案能力，所以反而使用者故事（User Story）寫得漂亮比較重要，他們要求快速的成果，剩下是以後的事情。
以我個人的經驗，我服務過多間公司的新創部門，即使不同公司產品與服務差別很大，但是對於同樣是新創單位來說，軟體開發的邏輯並不會差太多，簡單來說，就是『先求有再求好』。但是當一段時間過去，你就會發現剛做好的軟體還來不及整理、來不及修，新的專案又來了。
因此這時候就必須要累積一些好的習慣，譬如系統架構、配置與組態、架構模型、介面設計、輸出樣式等，這些內容應該在設計階段被完整產出與紀錄，並指定好後續維護的負責人，所以瞭解一些基本架構還是必須的。
本文一樣，會擷取一些書的資訊、與網路大大們的資源，盡可能提供簡易、快速的guidline，而不重複造輪。因為我也是半路出家，所以歡迎有更多的資訊補充建議、或資料解讀修正建議。
在進入主題之前，想先聊一下形塑成『產品』或『服務』的能力。Evvone Tsai 在他的書『打造360度行銷產品力』中提到。
產品力必須包含三種能力：
- 發覺需求的能力，也就是洞察設計思考的能力；
- 滿足需求的能力，也就是專案管理和協作能力，必須能觀看全局；
- 傳遞價值的能力，也就是看到事物的優點與價值，並能整合外部資源，讓客戶買單的能力。
其中，第一步是指洞察與設計思考的能力。那究竟是洞察與設計什麼呢？洞察就是指你要歸納你想解決的問題、以及相關的角色關係。設計則是指你取得這些資訊之後，轉換成為軟體可以處理的方式。
舉例來說，記帳APP要解決的問題是 記帳很麻煩、沒有動力記帳、或是個人的帳戶資訊很複雜、很難用軟體管理。
https://www.bnext.com.tw/article/43112/fortune-city
記帳城市用一個虛擬城市的概念（有虛擬建築、虛擬工人等等），將一個人每天發生的金額出入，用一個有趣的方式保存下來，提供紀錄、療癒、玩樂、分析建議等功能。
所以真實世界所發生的事情（我早上去買咖啡、搭公車、買網購、睡覺前研究買保險），最終都會被變成一列一列的資料（包含我個人的資料、我的預算、我的消費、我的城市）被記錄在虛擬世界裡（APP）。
因此在做系統規劃時，必須優先關注實體活動的映射，這個重點包含兩個，一個是使用者故事，也就是使用者要這個系統做什麼事情（處理什麼資訊）（Job to be done）、第二個則是這些資訊的架構應如何建立、才能滿足使用者故事的需求。
好的使用者故事，前方連結用戶的實際需求，後方連結系統開發邏輯。也就是你不能把使用者故事寫的太空泛、不能寫得跟軟體離很遠、無法想像。而使用者故事本身以及後面的需求分析文件，比較常見的方法就是善用物件導向的概念來達成。
第一題，什麼是物件？
在『邁向物件導向程式設計』一書中提到：
我們生活四周存在著許多的『物件』，如有形物件的汽車、微波爐等，和無形物件的銀行帳戶、學生成績等。不管那種物件都可用狀態(State)及行為(Behavior)兩種資訊來描述，如汽車的車速、檔數是狀態的描述，加速(減速)、換檔是行為的描述。銀行帳戶的餘額、利息是狀態的描述，存款(提款)、結清是行為的描述。
所以到這邊，我們開始把實體活動概念化，在上述的例子中，我們知道一台車子、或一個帳戶，可以叫做物件（Object）。而多個同類型物件的集合，就叫做類別（Class）。
參考：
類別定義一件事物的抽象特點。類別的定義包含了資料的形式(屬性, Field)以及對資料的操作(方法, Method)。我們也可以想像成類別是汽車的設計藍圖(blueprint)。
再者，在我自己的文章內也有提過
class類別，就是像一個模組，可以產出具有相似特性的實體(物件)
也有人會說他像是一個蛋糕模子，可以一直套用 生產蛋糕。
你可以想像在程式裡面跑來跑去的東西叫做物件（Object），因為物件才是一個有實體活動映射的資訊。譬如說 人類是一個類別，那人類本身並不代表人、只是一個抽象的概念，『我』才是那個有在做事的人，所以在程式裡面 可以讀取『我』的資訊（譬如性別、身高等等），或者讓我這個物件去做事情（登記姓名、更換住址等）。
第二題，什麼是物件導向設計
關於物件導向，認識物件導向就必須認識『封裝、繼承、多型』（當然也算是物件導向的基礎拉，只是本篇不打算寫這麼細）
提供自行閱讀內容參考：
簡單來說，當有了一個可以與實體活動映射的虛擬資訊：物件（Object），我們就可以比較容易想像這個物件要開始做什麼事情。
譬如記帳APP，會有一個名為Joey的User物件、這個Joey會擁有一個Account物件，所以我們可以在程式裡面找到Joey的Account
最重要的動作就是記帳，所以我們可以想像這樣
Joey = User.Create(Name = Joey)
新增一個叫Joey的物件
Joey.Account.NewRecord(Action = Deposit, Amount = 100)
在Joey的Account增加一筆紀錄，存款一百塊
諸如此類，我們已經想像好這個記帳APP的一些物件行為，所以未來當Joey想要重複的新增資料或查詢資料，就可以一直用這個物件來做事情。
如果換作另外一種非物件導向的方式，你就必須用一個查詢的function、從User資料表裡面找到Joey，再用一個儲值的function、從Account資料表裡面找到Joey的帳戶執行存100塊。這變成是方法驅動、而非物件驅動，這個時候你就必須要很熟悉你有哪些方法與資料表、而這些方法與資料表如何互相搭配使用。
而物件導向便能提供很直覺的『這個物件可以做什麼』，也就是在User底下查在這個物件能幹嘛、直接呼叫即可。
當然，對於物件導向，其相對的缺點就是你必須花很多時間去處理關係。
物件導向既然擁有這麼抽象而複雜的特性，也就造成了它在撰寫上一開始就必須克服的時間成本。為了能夠做到封裝，所以我們必須多花一些時間在分析物件的責任歸屬，為了做到繼承，所以我們必須多花一些時間在分析物件之間共有的責任與資料，為了日後擴充方便，我們必須多花一些時間創造出合適的抽象介面來讓物件實做。
這些都是伴隨著物件導向設計而來的工作。我們不能否認，使用結構式的程式設計不必付出這些時間成本；當然，自然也享受不到繼承與介面的優點。
第三題，這跟開發軟體有什麼關係？
資訊相關科系可能會有『軟體開發方法』或是『軟體工程』這類的課程，會介紹軟體開發模式、或稱為資訊系統開發模式、或稱為軟體流程模式。
這些所謂的模式，就是在開發軟體的過程中，作為軟體專案的接合劑，連結軟體開發技術實作面及軟體管理面的相關議題，並提供解決的流程方向。也就是透過標準化的程序，提供管理軟體開發及維護的架構，增進品質、提升效率，提供軟體開發過程中的可視性與可評估性。
常見的開發模型如：瀑布模式、漸增模式、雛型模式、螺旋模式等等。這些模型，在軟體發展之方法論中是指『程序』（Process），而除了程序，相當重要的另一部分則是『表示法』（Notation）。
而軟體產品經理的職責在於管理、建立、追蹤與記錄整個軟體開發過程。所以對於模式的基本認識是必要的，但在實際的環境中，如文章最前面提到，這些軟體開發流程因公司而異，相異程度我認為還不小。
所以對於開發模型的程序而言，我認為不應拘泥於招式，而重要的是保持彈性、認知這些模型的知識、並且觀察模式相異之間的優劣處，對於軟體產品經理而言會是很重要的實戰經驗。
但『表示法』（Notation），這一塊反而是我認為比程序更重要的，因為它代表著軟體產品經理的溝通能力。
UML，Unified Modeling Language，中文名為『統一塑模語言』，是一種標準化的標記語言，使開發者對軟體系統有具體說明、視覺化、建構與文件化的物件。特別是在物件導向的軟體開發中，UML是很重要的觀點之一。
1997年年底，OMG組織（Object Management Group，對象管理組織）採納UML 1.1作爲基於物件導向技術的標準建模語言。UML所涵蓋的內容是『表式法』而非『程序』，UML是與程序無關的(Process Independent)，也就是說，無論以任何程序來開發軟體系統，都可以使用UML來建構軟體模型。
此外，UML不僅用在物件導向軟體開發，UML中有些概念與圖形甚至可說是與物件導向無關，也使得UML的應用領域越來越廣(資料庫設計、韌體設計、資訊管理等)。
譬如使用者與系統的關係，便是UML重要的一環
上述這個是簡單的範例，人形代表Actor、橢圓形代表Use Case、方形代表System。線可以代表執行的關係，再更複雜的，有同形式的線，譬如相依、或者是延伸，另外，也可以在Use Case中加入條件，在特定條件下才會觸發等等。
第四題，UML簡單來說應該怎麼用？
回到UML本身，先簡單整理一些基礎
UML是作為系統開發過程中，用來作為開發人員溝通的一種工具。舉例來說，專案或產品經理用於表達使用者故事；系統分析師用於討論系統架構；軟體工程師用以設計系統；使用者用以記錄硬體或是軟體元件的配置情形。
這樣的工具，有助於視覺化系統、詳述系統行為、指引建構樣板等等
而再進一步，UML提供了完整的guidline，幫助使用者透過不同角度來觀察與建立系統。包含一個上層觀點與四個底層觀點，上層觀點即為使用案例觀點，其應影響四個底層觀點，包含設計觀點（描繪類別/物件/系統行為）、處理流程觀點（非功能性的部分，例如執行緒或性能）、實作觀點（明定設計觀點的內容所位於的模組或元件）、部署觀點（執行時的環境與相關部署）。
而對於4+1觀點中的每一個觀點，可以利用UML所提供的多種圖形來表達。對於很講究系統開發流程的專案來說，可能甚至會幾乎都用到、但對於一般的專案，大多就使用類別圖、活動圖或使用案例圖等等。
也就是如系統開發模式的選擇，並沒有好壞之分。相關的圖形與應用說明可以參考這篇文章，提供快速入手的概覽。
而倡導簡約之道、「萃取UML 中最有用的一小部分」的Martin Fowler，則適合已經有些經驗的軟體產品經理細細品味。
總結，這為什麼是入門課？
老實說，對於我所認識的在業界軟體產品經理或工程師，UML沒有用處。就算有用的人，多半也覺得這個是老舊、負擔的流程。但對於我來說，這卻成了一種復古的浪漫，瞭解UML以及其軟體開發模式的發展，是很有趣的。
關於圖形優於文字的表達力這個觀點，毋庸置疑，在日常的生活工作中應該都有體會。當然，用圖形符號進行有效溝通，有一個前提就是：看圖的人都能準確、一致地理解這些圖形符號的具體涵義。
現在講求敏捷，凡事都追求MVP、最小可行性產品，其中一個重點是因為軟體開發的成本一直在降低，因此不再需要準備健全才開始開發，兼顧所有開發基礎與執行架構的觀念已經被淘汰。
但無論時代如何改變，你總是會遇到客戶或是你的長官，還是喜歡那種看起來很完整、很有邏輯於結構性的提案，這時UML何嘗不是一個很棒的工具？
那這篇就到這邊，ㄅㄅ
REF:
