剛進 IT 團隊時，「Product Owner、Scrum Master、Project Manager」常被新人聽成三個都在管事的人；其實在健康的 Agile 團隊中，三者分別負責三個不同問題：Product Owner 決定要做什麼與為何值得做（WHAT/WHY）、Scrum Master 守護團隊怎麼做（HOW）、Project Manager 掌握時程預算與風險並對外溝通（WHEN/BUDGET/RISK）。
如果你也在 offer letter 上看到這些頭銜，腦袋瞬間空白——很正常。真的。這篇就跟著 Myra 走完她在 Team Nova 的第一個 Sprint，你會知道該問誰、為什麼要問他。
那封 offer letter：三個頭銜同時出現的瞬間
Myra 在 Tuesday evening 收到 offer letter。她看了三次，截圖給媽媽，又看第四次，因為其中一句寫著：她會被 onboarded 到 Team Nova，並且會和 Product Owner、Scrum Master、Project Manager 密切合作。
三個職稱。聽起來都像「負責的人」。但她在 engineering college 的 four years 裡學會了反轉 linked list、理解 compiler，卻沒人教她：為什麼一個 IT 團隊看起來需要三個人，才知道誰在做決定。
所以她開了 five browser tabs。看完更亂。關掉也更亂。
Day One：人很多，答案很少
Day One 的 daily stand-up，Myra 被帶進玻璃隔間。八個人站成一圈，咖啡杯、短句、節奏很快。她的主管介紹：Priya 是 Product Owner，Sam 是 Scrum Master；Rakesh 是 Project Manager，從 client 那層樓用視訊加入。
Myra 笑、點頭。腦袋沒有存到任何「他們到底在幹嘛」。她決定不問教科書式的問題，改用一種笨但有效的方法：看他們怎麼工作。Sprint 跑完就懂了——後來她甚至覺得，自己以前怎麼會覺得這很難。
Product Owner（Priya）：決定 WHAT / WHY 的人，擁有 backlog
Product Owner 的核心責任是決定要做什麼（WHAT）以及為什麼值得做（WHY）：他們擁有並管理 backlog，設定優先順序，代表客戶聲音，並在選擇之間做取捨。
Myra 的 second day，她旁聽一場 Priya 在看 backlog 的會議。上面是一串 user stories，句型像短故事：「As a user, I want to...」。其中一條是「As a user, I want to save an item for later so I don't lose it while browsing.」
Priya 說，客服上個月收到 forty complaints，都是使用者瀏覽時把商品弄丟、找不回來。這個數字讓她判斷：這個「稍後保存」功能，比起清單上其他五個更值得先做，所以拉進下一個 Sprint。
沒有人吵。不是因為 Priya 最大聲，而是因為她的工作就是把「客戶到底在痛什麼」這件事背在身上。然後把它翻成優先順序。很安靜，但也 arguably harder。
同一週，Myra 也看到 Priya 拒絕一個資深開發者提的需求：一個很炫的動畫。想法不差，只是不適合讓團隊把兩週（two-week sprint）花在這上面。Product Owner 的工作裡，有一部分很不討喜：保護團隊時間，必須對優先順序誠實，甚至有點「狠」。
Scrum Master（Sam）：守住 HOW 的人，移除阻礙、照顧流程健康
Scrum Master 的核心責任是守護團隊如何運作（HOW）：主持並促進 Scrum 儀式、移除阻礙、改善流程；Scrum Master 不是主管，也不是指揮官，他們不決定做什麼，而是讓團隊能順利把事情做完。
Myra 開始注意 Sam，是因為他看起來沒有在寫 code，也沒有在排優先順序，但他整天都在處理「摩擦」。那種小到很煩、但卡住就會讓你崩潰的東西。
例如 daily stand-up 上，開發者 Arjun 說自己卡住 two days，原因是等不到其他團隊的 API access。Sam 沒有丟一句「不關我的事」，他說他會在會後追。那天下午，Arjun 就拿到需要的東西。卡住解除。很快，但背後其實就是協調、追蹤、把門敲開。
再例如 sprint planning。本來預期 thirty minutes 的會議，越拖越長，快逼近 ninety。Sam 介入得很輕：他提議把只影響兩個人的討論先 park，改 offline 處理。會議節奏瞬間回來。
two-week sprint 結束會有 retrospective。Sam 會主持，但不搶話；他問問題、讓沉默的人也能說話。那週，最安靜的人是 Myra。她被拉進來講了一句有用的話。你很難說這是「管理人」，比較像「讓團隊更能合作」的教練。
順帶一提，這裡有個常見混淆：Scrum 不是 Agile 的同義詞。Agile 是思維（mindset），Scrum 是落實 Agile 原則的其中一種框架。
Project Manager（Rakesh）：掌握 WHEN / BUDGET / RISK 的人，照顧大局與對外溝通
Project Manager 的核心責任是掌握時程、預算與大局風險（WHEN/BUDGET/RISK）：管理 scope、dependencies 與跨團隊協作，並對外溝通，讓 stakeholders 不會「被意外嚇到」。
Rakesh 一開始更難看懂，因為他 not always in the room。他有時從 client 那層樓視訊加入，螢幕後面還會看到 client 的 logo。Myra 到 second week 才抓到他的重點：一通 status call 裡，Rakesh 對 client 說明 status report——做完多少功能、離 launch 還剩幾個 Sprint、以及專案是否 tracking within budget。
Rakesh 在意的是 Priya 和 Sam 不會一直盯著的那一類事：deadline、cost、scope 的變動、和三個其他團隊（three other teams）的 dependencies，還有「如果 client 突然想在中途加一整個新模組會怎樣」。這些問題很少出現在 stand-up 的一分鐘更新裡，但一旦爆開，影響會很大。
也因此，當第三方供應商的工具延遲，產生連鎖反應時，通常是 Rakesh 要先把影響算清楚：launch date 會不會被推？成本會不會增加？leadership 要不要今天就知道，還是等 Friday 的更新也行？這些不是寫在 user story 裡的工作，但它就是專案「能不能交付」的外框。
用「三個問題」把一切對齊：他們在乎同一個產品，但問題不同
把 Product Owner、Scrum Master、Project Manager 放在同一個 Sprint 裡看，最簡單的記法是：三者關心同一個產品，但各自是某個問題的「最後負責人」。Priya 的問題是要做什麼、為何重要；Sam 的問題是團隊怎麼運作、哪裡卡住；Rakesh 的問題是是否準時、在預算內、以及外部 stakeholders 有沒有被意外驚到。
而且這三個問題會重疊。延遲可能是 Sam 正在清的 blocker 引起，而 blocker 可能源自 Priya 排進來的優先項。你不需要把它想成三條平行線，更像三個鏡頭拍同一個畫面，各自對焦不同。
同一天、三種視角：Myra 看見他們各自「忙什麼」
有個安靜的 Thursday，Myra 乾脆做了一件很新人會做的事：把三個人一天做什麼，按小時記下來。不是為了八卦，純粹是想讓輪廓變清楚。
Priya：早上 daily stand-up，接著和兩位客戶通話收 feedback；下午寫 user stories，晚一點和團隊一起 grooming the backlog（把接下來可能要做的功能先談清楚）；最後看 demo，確認這個 Sprint 交付了什麼。
Sam：同樣出現在 stand-up，但接下來是處理一個人的 permissions issue、準備 sprint board，還花二十分鐘 coaching 一位比 Myra 還新的成員，讓對方知道 retrospective 怎麼跑；收尾則在安排 Friday 的 retro。
Rakesh：節奏最分散。早上先看 status report，上午跟 client 通話，中午後追 budget，接著和另外兩位專案負責人做風險檢視，最後更新 roadmap，讓 leadership 隔天一早看到最新狀態。
同一個 Sprint。三個人像在看三張不同的地圖。
新人最常踩的誤會：把三個角色當成上下級
在健康的 Agile 團隊中，Product Owner、Scrum Master、Project Manager 不是嚴格的上下階層，三者也不會在彼此領域有單向覆蓋權：Priya 不能指揮 Sam 怎麼跑 retrospective；Sam 不能替 Priya 決定哪個功能最重要；Rakesh 也不能直接走進 Sprint 就重分派任務，而不走團隊同意的流程。
Myra 幾乎就誤會成「Project Manager 在最上面」。這個誤會很常見，也很容易讓溝通變形：Scrum Master 在 stand-up 問你卡什麼，不等於你被主管盤問；Product Owner 改了 priority，也不等於在推翻 Project Manager。很多時候只是各自把自己的問題顧好。
當然，意見衝突會發生。Myra 看過 Priya 和 Rakesh 為了一個功能要不要延後（保品質）還是硬上（保 deadline）來回討論 fifteen minutes。重點是，那不是「上對下命令」，而是不同優先事項之間的協商。
實務上你該問誰：Myra 到 third week 才真正放鬆
到 third week，Myra 不再因為「不知道找誰」而焦慮。她開始能把問題分類，然後直接走向對的人。
如果 Myra 不懂「為什麼要做這個功能」，或不確定哪個需求更重要，她問 Priya。她得到的是客戶問題與優先順序的解釋，而不是一句「叫你做就做」。
如果 Myra 被環境或存取權卡住超過半天，例如設定或權限類問題，她會在 stand-up 提給 Sam。她看到的效果是：within the hour，就有人帶著正確的 access 來協助，而不是她自己悶著頭撞牆。
如果 Myra 想把自己手上的 task 連到 client 的 deadline、或想知道跨團隊 dependencies 會不會影響交付，她去看 Rakesh 的 project updates，因為那張圖是「超過單一 Sprint」的。
這裡其實有點溫柔：這三個角色的存在，本來就讓新人永遠有地方可以把問題放對位置，而不是逼一個人扛起所有答案。
現實世界會變動：有些公司會合併角色，但三個問題不會消失
還是要保留一個限定語：real-world variation 很大。不同公司對職稱與邊界的畫法會變，有些 organization 會把 Scrum Master 和 Project Manager 合併成一個角色，especially in smaller teams 或仍在轉型 Agile 的公司；有些 product-led companies 甚至不使用「Project Manager」這個頭銜，把責任折進 Product Owner 或 Engineering Manager；startups often 會讓一個人戴兩頂、甚至三頂帽子。
但就算頭銜改了，三個問題仍然存在：總有人在決定 WHAT/WHY、總有人在守住 HOW、總有人在看 WHEN/BUDGET/RISK。你不必死背 org chart，你只要聽懂對方正在問你哪一種問題，就知道怎麼回、該拉誰一起進來。
回到 Myra 的 third retrospective：她終於看懂「房間的形狀」
到 third retrospective，Myra 不再像旁觀者。她看得出來：Priya 想的是下一百個使用者在乎什麼；Sam 想的是團隊有沒有空間做出好工作；Rakesh 想的是六個時區外的 client，Friday 之前要看到一個能放心的狀態更新。
三個問題。一個產品。Myra 在 two weeks 前還搞不懂，a fortnight 之後已經能把問題問到正確的人。
如果你正要開始自己的第一個 Sprint，別急著把所有術語背起來。你只要在會議裡留意：大家此刻在問的是 WHAT/WHY、HOW，還是 WHEN/BUDGET/RISK。抓到這個，你會站得更穩。
