利用程式設計原則解釋職場困境

正當我在麥當勞吃著嫩煎雞腿堡配著無糖綠邊看漫畫「關於我轉生變成史萊姆這檔事」時，突然耳朵不由自主的補捉到了後方不遠處傳來的一段對話

小明：「唉~我真搞不懂 PM 在幹嘛，整天只會出張嘴，啥都不管，死都死其它人」

小華：「總會安排需求跟時程管理吧？」

小明：「需求就是客戶說的照單全收，問為什麼要這功能不清楚，問使用的情境也說不明白；時程就是說下星期要給，要大家儘量趕；唉，常常連規格書都沒有」

小華：「疑？那老闆不管的嗎？」

小明：「老闆只聽他的啊，還幫他說話呢，說都他一個人在承擔客戶的壓力，要多幫忙他」

小華：「有個狀況外的老闆當他靠山，那我想沒救了」

小明：「唉，別提了，再講下去我都要哭了」

聽完對話，感覺就是一個無能的 PM 加上一個可憐的工程師，面對這種情況，我想身為工程師是無能為力的。反正是別人的事，正當準備將注意力拉回手邊的漫畫時，突然靈光一閃，想到了程式設計原則，下面為了方便說明，給對話中的 PM 起了小王這個名字。

從對話中分析，小王有六個功能

• 完成專案
• 需求管理
• 時程管理
• 規格書撰寫
• 需求訪談
• 處理客訴

小明有一個功能

• 實作需求

畫成 UML 是這個樣子

基於單一責任原則，我們可以把面對客戶的部份跟面對專案的部份分開，小王被拆成小王 1 跟小王 2

一個人怎麼可能會變成兩個？這明顯不可能。幸好，我們還有接口隔離原則，將功能從人上抽離出來建立角色，小王 1 是面對專案的部份，角色為專案經理，小王 2 是面對客戶的部份，角色為業務，小明的角色是工程師

好的，就算拆解完 UML 圖，好棒好厲害，那對這件事情有什麼幫助？

因為上面這張圖是理想中的畫面，回頭看對話，其實會發現小王對於 PM 這個角色的功能實現幾乎沒有

看到這邊，也許你會發現，原來小王根本不是 PM 啊！這是在程式設計中很常發現的壞味道，一個類別做的事情跟名稱不符，這時候就會需要進行最簡單但重要的重構，rename

不過這還不是我想表達的重點。分析完畢後，我的疑問是，小明真的無能為力嗎？