入職半年的反思 & PM 的溝通修煉（下）｜PM敬

Photo by Imagine Buddy on Unsplash

距離上次更新文章竟然已經五個月了（人真的好容易懈怠哈哈）不過 2025 年末確實因為公司的人事調整，工作變得非常忙碌，回過神來，原來自己也已經入職超過半年。對於「PM」這個角色的理解也從初期的摸索，多了一些更深入的心得與反思。

回頭看剛入職時寫的文章，發現如今的想法已和當時大不相同。雖然到現在還是覺得每天都充滿新的挑戰，也從未停止意識到自己還有很多成長空間這件事，但那些卡關、感到挫折的時刻，或許正是成長最真實的樣子，因此反而是我最想留下文字紀錄的部分。

這次讓我再度提筆的契機仍然是「溝通」，可以算是我上一篇寫的**《PM的溝通修煉》**下集🤣，只是這次談論的對象不是老闆和工程師，而是客戶。

事件回顧：從消失的資料看見小公司的協作流程痛點

事情是這樣的，某天客戶反應系統其中一個欄位的資料在特定日期後全部消失了，並表示這個欄位因有對帳需求所以必須存在，確認後發現是後端工程師在一次版本更新中將該欄位移除了。雖然後續建議客戶使用另一個欄位替代，也順利解決了需求，但這件事仍然讓我耿耿於懷好一段時間。

耿耿於懷的點不在於被客戶唸，而是那種沒能掌握專案狀況的無力感：

1. 資訊不對稱：我竟然不知道那個欄位是何時被移除的

2. 業務理解掌握度不足：我對特定欄位在客戶端的使用情境理解不夠深入

我們公司的前端有明確的上版規則與流程，但後端卻沒有，由於該欄位是直接吃後端的資料，如果沒特別留意實在難以發現。這不禁讓我反思，在小公司節奏快、流程相對不夠嚴謹的情況下，身為 PM 的我是否該制定一套像前端一樣的上版流程？又或是主動追蹤每次後端的調整？

Maybe 請工程師在涉及資料欄位增減或邏輯調整時，在協作工具中同步記錄。但實際執行起來絕對不會這麼理想，且後端也不像前端一樣可以透過畫面清楚知道哪些地方做了調整😵‍💫。

如果我能清楚掌握後端工程師每次上版更新的內容，便能主動告知客戶異動，客戶也能即時反應他們的需求，進而避免對方自己發現資料不見了、跑來問，我們才發現刪到重要資料的問題。

由於我們的軟體服務還在開發初期，許多功能與欄位仍然是跟著客戶的需求不斷調整，並不是一套已經穩定運行的成熟系統，有些欄位甚至是因應客戶需求先預留的，真正的使用情境往往要等實際營運、跑過業務流程後才會逐漸明朗，本來覺得自己每天都在使用系統，對產品已經有一定的掌握度，這次經驗確實直接給了我一記當頭棒喝。

除了流程，這件事也讓我開始思考與客戶溝通時的「溫度」與「界線」

Photo by Volodymyr Hryshchenko on Unsplash

我是一個很不喜歡產生誤會的人，因此向來習慣將每件事解釋得很詳細；也認為溝通時保持親切禮貌的語氣，是專業的一種表現，所以回覆總是會加上「～」、「！」或是「哦、呢」等語助詞，雖然本意是為了正確傳遞資訊與維持專業，久了卻發現這樣的溝通方式會帶來一些副作用，例如：過多的解釋是否顯得不夠自信，有時甚至會被解讀為心虛或推諉；太親切的語氣是否模糊了專業的邊界，容易讓客戶產生「這件事很好商量」的錯覺，進而將 PM 的額外協助視為理所當然。

所以我決定稍微調整自己與客戶溝通的方式（算是一個小小的實驗）暫時收起過多的語氣詞，嘗試用更中立的口吻，僅針對問題給予直接回覆，想看看這樣是否更能在解決問題的同時仍然保持專業的形象。至於「解釋」的時機點、要詳細到什麼程度，這部分我還在思考與尋找平衡點的路上。

以上就是最近工作的反思與迷惘，有空會再把這半年累積的其他想法慢慢寫下來（希望不用再等五個月）總之～成長果然是一條漫漫長路，如果你也有一樣的困擾，或是也在這條路上緩慢前進著，歡迎分享你的想法，我們一起修煉😆。