Uka 在 2023/02 加入團隊，我跟她共事時期 2.5 年。我們團隊從 2022/02 草創時期，至今公司人員近 40 位同仁，而開發團隊成員（含 App 工程師、Web 工程師、後端工程師、專案/產品經理、測試工程師、維運工程師等等）約 20 位。😳
.
團隊成員的感謝
Retro 會議中的感謝時間，Uka 的角色被團隊成員廣泛認為是極為重要且不可或缺的。多位成員表達了對 Uka 的高度肯定與感謝，她的貢獻在多個面向都帶來了巨大影響。
首先，在 產品與專案文件撰寫 上，Uka 將規格書撰寫得細緻而完善，甚至超乎團隊預期，為工程師節省了大量時間。在她加入之前，團隊的溝通多依賴口頭傳達，需求模糊、文件不足，常造成困擾；而她的加入讓這一切走向正規化，讓大家「幾乎不用再擔心文件不足」的問題。文件的邏輯清晰度與細心程度，更是獲得了極高的評價。
在 品質保證（QA） 上，Uka 展現出卓越的細心與專業。她能精準測出細微問題，並與工程師快速討論完成測試。在 QA 團隊人手不足的時期，特別是在 T 與 M 尚未加入前，Uka 經常主動支援，甚至半夜加班，填補人力缺口。她不僅具備強大的測試能力，還能協助解決問題並提供專業建議，成為團隊極大的後盾。
在 溝通與協調 上，Uka 亦展現了不可或缺的價值。她在工程師與設計師之間扮演橋樑，讓需求轉換與跨部門協作更為流暢，有效弭平溝通隔閡，確保資訊清晰傳遞。
此外，Uka 的 主動積極與支援 更是深得人心。她總是能在關鍵時刻主動提供協助，解決開發上的問題，回答大量疑問，並提出專業建議。有同事形容，與她合作時會感到「很舒服」，因為「該出現的東西會自動跑出來」，這正體現了她讓大家無後顧之憂的特質。
整體而言，Uka 不僅是一位優秀的產品經理，更是一位極佳的同事與夥伴。她的邏輯清晰、文件嚴謹、QA 能力出眾，以及溝通協調與主動支援，讓團隊運作更加順利與舒適。會議中，多位成員都感嘆她的即將離開將是公司的一大損失，因為她不僅是一位出色的主管，更是一位值得珍惜的好同事。😊
—
App Team 有她的重要性
- 溝通與協作模式的挑戰 (Uka 離職後)：
- Uka (PM/QA) 角色影響：Uka 的離職對團隊產生巨大衝擊，特別是在規格文件撰寫、品質、以及工程師與設計師之間的溝通橋樑作用。她過去協助解決許多問題，並確保了文件品質和協調順暢。
- 缺乏 Uka 後的影響：團隊預期在 Uka 離職後，產能可能會受到影響，特別是規格書的詳細度和品質可能會下降。設計師可能不會畫出詳細設計圖，或無法提供完整的數值定義。
- 新的溝通窗口：
- 若遇到缺圖或規格問題，初步建議先找「L」溝通，因其可能最能協助。若「L」無法回答，再尋求「S」或直接在群組中詢問。
- 發言者強調，若設計畫面有問題，需要透過「L」協助與設計師討論，或團隊成員直接與設計師溝通。
- 對「好的 PM」的定義與尋找困難：團隊普遍認為 「好的 PM 不好找」。好的 PM 應具備全面能力，如撰寫 PRD（產品需求文檔）與 Spec（產品規格文件）、測試計畫、AB Test、API 文件，甚至需要判斷產品成敗、定義資料埋點，並能協調各方。討論中對比了台灣與國外 PM 角色的差異，認為台灣的 PM 普遍能力不足，且工作文化可能導致 PM 較少機會像國外一樣晉升為 CEO。
- 過去缺乏規格的開發經驗：有成員分享過去在沒有 Uka 這樣優秀 PM 的情況下，開發工作非常艱難。特別是在合約交易等複雜功能，若缺乏規格，工程師需憑藉經驗和「sense」來預設數值和格式。這也讓他們更加體會到有 Uka 這樣 PM 的重要性。
總體而言，此次會議不僅是任務分配，更是一次團隊對未來工作模式和挑戰的深度討論，尤其在失去關鍵角色 Uka 之後，團隊成員們正在積極尋找新的協作方式，並對「好的 PM」的重要性有了更深刻的體會。
—
PM 在團隊中的角色
產品經理 (PM) 在團隊中扮演著至關重要的角色，其重要性從成員對 Uka 的高度評價以及對過往糟糕 PM 經歷的抱怨中可見一斑。
PM 的重要性
- 溝通與協調的核心： PM 被視為團隊中合作、討論與溝通最為密切的夥伴。他們是開發團隊與需求方（如設計師、QA）之間的橋樑，確保資訊流通暢順。
- 問題解決者： 像 Uka 這樣的 PM 能夠解決許多問題，是團隊的重要資產。當他們缺席時，團隊會感到溝通困難和不便。
- 規格與設計的產出者： PM 負責產出規格書，並確保其具有高度的細節和品質。在開發初期，當規格文件不足時，PM 的存在對於填補這些空白至關重要，可以避免開發團隊「直接死去做」複雜的功能（如合約交易）。他們也負責與設計師溝通以取得設計圖，確保設計與開發的一致性。
- 保障開發品質與效率： 一位好的 PM 能確保交付的設計和規格品質高，減少開發過程中的問題。Uka 的缺席被預測會影響產能，因為將無法再提供同等細緻度與品質的規格書。
- 團隊的保護者： 好的 PM 會為團隊「擋隕石」，即抵擋來自需求方不合理或模糊的要求。他們需要會與需求方爭論，而不是讓工程師直接面對不合理的需求。
成員們抱怨過去遇到的 PM
成員們對過去遇到的 PM 經歷有諸多不滿，這也反襯出優秀 PM 的稀缺性與價值：
- 缺乏思考與過度依賴工程師： 有人抱怨前公司的 PM 「什麼東西都要問，什麼東西都要叫工程師幫你想」，認為他們應自行思考並提供方案，而不是把決策壓力推給工程師。
- 需求管理不善： 過去的 PM 常常無法有效管理需求方，導致功能不斷被偷塞，或是無法分辨 Bug 和新功能，甚至直接答應不合理的要求，讓工程師陷入困境。
- 規格模糊或不足： 許多 PM 提供不夠詳盡的規格書，導致工程師需要「通靈」來理解需求，自行猜測應有的格式、數值或行為，這在處理如合約交易等複雜功能時，可能導致嚴重的問題。
- 將工程師推上前線： 有些 PM 會直接將工程師拉進與需求方的討論，導致工程師需要直接應對需求方的質疑，這被認為是不專業的行為，因為「如果回的話，那就不需要 PM 了」。
- 不願承擔責任或應對衝突： 有的 PM 不敢對需求方說「不」，導致工程師被迫接受不合理的要求。優秀的 PM 需要能夠在必要時與需求方「槓起來」，為團隊爭取權益。
- 惡劣的工作文化： 某些公司的 PM（或整體公司文化）甚至會鼓勵工程師寫出「80 分就好，能寫 60 分就寫 60 分」的程式碼，或是刻意增加複雜度（如多一點迴圈），以便將來有更多的維護或報價機會，這被認為是一種非常不道德且有害的行為。
- 過勞與缺乏支持： 像 Uka 這樣身兼 PM 和 QA 雙重角色的員工，儘管能力很強，但也可能因工作量過大而感到「太操」。這暗示了公司可能在 PM 角色上的支持不足，導致個人過度負荷。
總體而言，一位好的 PM 能顯著提升團隊的效率與產能，並為開發人員提供清晰的指引和保護。相反，一位糟糕的 PM 則會導致溝通混亂、規格不清，甚至影響團隊士氣和產品品質。這使得好的 PM 在業界中「非常難得」，被認為是需要「去廟裡拜拜」才能求到的稀有資產。
—
沒有她時：規格不足、全靠經驗支撐
在 2023 年之前，Uka 還沒加入時，我們團隊並沒有專職的產品經理。當時的規格文件往往只是需求方簡略描述，再搭配設計圖，但缺乏完整的細節。工程師在開發過程中，常常得依靠經驗和直覺來補足缺漏。
像我自己，就必須憑著對加密貨幣產業的嗅覺，去推測數值或資料格式的合理性。這樣的方式耗時費力，也容易造成誤解與返工。特別是在原生 iOS/Android 向 Flutter 過渡的階段，我和阿遠的合作模式，幾乎是我直接給答案，甚至提供截圖，讓他比照 iOS 的做法處理。這種方式雖能勉強推進，但缺乏制度化流程，風險很高。
有她後：規格完整、開發更順暢
Uka 加入之後，情況徹底改變。她逐步掌握產品細節，開始撰寫完善而嚴謹的規格書。第一次看到她的文件時，我便感到驚艷。雖然我不一定會全部細讀，但她已經把大部分細節規範清楚，讓工程師能有依循的標準。
這讓我可以直接請阿遠去看規格書，若還有疑問再找 Uka 確認。我的負擔瞬間降低許多，團隊也不再需要反覆依靠口頭溝通來補漏洞。
有她在：專業 PM 的真正價值
隨著時間推進，Uka 不僅能撰寫規格，更逐步掌握整個產品脈絡，協助管理功能開發流程。無論是 Web 還是 App 團隊，都能依循她的文件與說明順利推進；若文件有不足，詢問她幾乎總能立刻得到清楚的答案。
這讓團隊真正體會到「有她在」的不同：
- 產品推進更順暢，少了混亂與反覆確認。
- 工程師能專注在開發，而非揣測需求。
- 溝通效率提高，跨部門協作更和諧。
Uka 的專業，讓我們第一次感受到擁有一位「真正的 PM」對團隊的重要性。🙃
逍遙文工作室 
隨意留個言吧：）～