轉眼間就快到了比賽的尾聲，今天想跟各位聊聊過去我在做 Product Owner 的一些心路歷程

序章

我與產業的第一次接觸是在某音樂平台做 QA team intern
當時在公司有看到專案的 PM ，真的覺得

WOW 這氣勢也太帥！

不論是走路的步調、拿著相對輕薄的筆電、一身雅痞的行頭
如同秋風掃落葉般的快速與我們討論需求
那樣的俐落與幹練對於還是學生的我來說，只能望之心嘆（真的只差他不是開跑車來上班了）

以後我一定也要變得這樣

最後雖然做的事情有像到，但殊不知最終身材走了樣

等到兵役服完後，我到了一間乙方公司繼續了我的 QA 生活
那時的 PM 們則是完全不同的面貌
有的精明幹練，跟在他們旁邊做事，可以享受循序漸進的專案節奏感
有的差強人意，都火燒屁股了駐點開發的 case 了，還會看到他上班上一半去抓 神奇寶貝 寶可夢
唯一共通的是 襯衫、領帶、高腰褲(沒有貶義，但他們顯然很不樂意這樣穿，因為加班的時候就會解開束縛)

那時候我才知道 PM 有分成 產品經理 (Product Manager)、專案經理（Project Manager）
一個管往哪走，另一個管何時好

專案自由度

很幸運的第二份工作找到一間甲方公司，作為一間甲方公司的軟體開發，在一定程度上獲得了不少專案的自由度
並且在努力的與 Stakeholder 的周旋當中，也獲得了不少信任，可以來主導一些需求探索與發想
因為了這項關係，讓我有種在做自己的東西的感覺，也真正意義上的變成了 PO (Product Owner)
進而產生了更多責任感，和一些動力讓我去更加的瞭解市場

也就是我在 D3 - 敏捷有 3+1 行，行行出狀元 中提到的
從幫別人做東西 變成 這是我們的專案

不停迭代的優化

除了跟著 Stakeholder 的大方向走之外
身為 PO 的人也要時時刻刻去了解市場的一些脈絡

知己知彼，百戰不殆

因為是一個 to C 的平台，所以要了解到目前市場上主流設計模式
最後在產品中添加了所謂的明亮模式與暗黑模式

由於同樣產品為論壇性質，就親身到其他論壇來去了解進稿這方面的操作流程(一用就是三十天 XDD)
讓我可以在後續評估 Markdown 語法和其他 html editor 的差別

雖然即將進入而立之年，也要卯足最大的力氣，把一些新技術、新玩意帶入團隊讓大家一同成長
還好在 2020 年底就將設計圖切換到 figma 上做使用 (順便開了很多 Page，沒想到後面要收錢）

市場是現實且殘酷的，唯獨不斷地進步才能保證自己不被淘汰

做你該做的事

隨著執行 Scurm 即將邁入第六年，如果要把沿途的檢討事項列出來，大概三十天都不夠寫
但有一項卻可以串穿整條過程

PO 就該做 PO 的事情

不是整天忙進忙出，累得半死，做了很多事。就代表做得很好、可以獲得鼓勵
PO 要把時間花在 PO 的項目

團隊人力不足 這或許是個藉口
但擔任 PO 期間，我還真不巧把我自己的技能樹一路亂點
從 系統架構 到 上線部署 CI/CD
從 SA分析 到 程式碼品質掃描 SonarQube
傳統 Linux 起服務、Azure AKS、Aliyun ACK ...
java struts2、Spring Boot、React、React-native ...
MSSQL、Redis、MongoDB ...

樣樣都摸過！
樣樣都不精通！甚至到一知半解，不懂裝懂

我既不是天才，也不是精英
在最公平的一天二十四小時上，我花了很多在不是我該做的事情
沒讓團隊優先產出最有價值的項目
也沒讓 Stakeholder 覺得安心和取得平衡
讓大家一起走了不少冤枉路。

PO的工作項目理當要花費很多時間去剖析，這是一件很容易被忽略的事情

PO 講話，要言之有物，言必有中
這樣別人才能聽得懂你想表達的東西
就像是
PO 文，不附圖一樣
會缺乏公信力

但根據我最近點的技能樹告訴我 (什麼 ISO27001、27017 智慧財產權之類的)
使用網路上的圖片作為素材真的很危險
除非是使用 cc0之類的才可以不用備註出處
直接使用
最後來一張符合今天主題的圖片作為結尾吧

參考資料：
無