科技業菜鳥 PM 必備：與工程師溝通的英文專用術語大補帖！（下）科技業菜鳥 PM 必備：與工程師溝通的英文專用術語大補帖！（下）

在上篇文章中，我們深入探討了產品的核心技術與運營術語，掌握了產品的「骨幹」。然而，如果想成為專業的科技業 PM，光是理解技術還不夠，你還必須知道工程師「如何」工作，以及「與誰」工作。

本文（下篇）將繼續帶你進入 PM 的日常戰場：敏捷開發流程、版本控制，以及產品與設計團隊的關鍵語言。這些術語將提升你的會議效率，讓你能夠精準地將用戶需求轉化為工程師可執行的任務，真正成為團隊中不可或缺的溝通橋樑！

Table of Contents

科技業 PM 專用術語：軟體開發與版本控制術語篇

理解產品的技術骨幹後，接下來要成為一個能與工程師順暢溝通的 PM，還必須了解他們日常協作和程式碼管理的工作流程。

敏捷開發（Agile Development）

敏捷開發是一種迭代、漸進式的開發方法，強調彈性與快速反應，而非僵化的計劃。

User Story（使用者故事）：是敏捷開發中常用來描述產品功能或需求的一種方式，主要以「使用者的角度」用簡單日常語言寫出使用某個功能的目的和動機。撰寫格式大多是「作為一個[使用者角色]，我想要[達成的目標]，以便[使用動機或期望成果]」。
例句：The user story for this feature is, “As a returning user, I want to reset my password to regain access to my account.”
（這個功能的使用者故事是：「身為一名回訪使用者，我想要重設密碼以重新進入我的帳號。」）
Sprint（衝刺）：團隊約定好的一段短時間（通常是 1 至 4 週），大家全力衝刺完成一小部分產品或目標。等到階段性目標完成後，團隊再一起後驗收成果、檢討過程，再開始下一輪 sprint。

例句：Our goal for this sprint is to complete all the user stories related to the new login feature.（我們這次衝刺的目標是完成所有與新登入功能相關的使用者故事。）

Scrum：一種常見的敏捷框架，將專案分解成多個短期的 sprint，並透過一系列固定的會議來確保團隊溝通順暢。

例句：We’ll be using Scrum for this project, so we’ll have a two-week sprint cycle.
（這個專案我們會用 Scrum 敏捷開發，所以會有一個兩週的衝刺週期。）
Kanban：另一種敏捷框架，專注於可視化工作流程，並限制每個階段的進行中工作量（Work in Progress、WIP）。
Backlog（待辦清單）：專案中所有待完成的任務與需求清單，可分為以下兩種：

Product Backlog（產品待辦清單）：由 PM 維護，包含所有產品需求。
Sprint Backlog（衝刺待辦清單）：團隊在每次 sprint 會議中，從 Product Backlog 中挑選出來並承諾在該週期內完成的任務。

Daily Stand-up（每日站立會議，簡稱「站會」）：團隊成員每天站著快速地分享三件事：昨天做了什麼、今天要做什麼，以及是否有任何阻礙。

例句：Let’s keep the daily stand-up brief and to the point. What’s your progress?
（讓我們保持每日站立會議簡短且切中要點。你的進度如何？）
Retrospective（回顧會議，或簡稱 Retro）：在每次 sprint 結束後，團隊共同回顧這個週期中做得好的地方、需要改進的地方，並制定改善行動。
Research Spike（研究高峰）：在一個 sprint 週期內，團隊特別撥出時間，針對某個技術問題進行深入研究，而非實際開發。這個目的是評估一個功能的可行性或找出最佳的技術方案。
Go-No-Go（放行／不放行）：在專案重要階段（如上線前）召開的決策會議。所有相關人員會根據準備情況，共同決定「放行」（Go）或「不放行」（No-Go）。這是一個關鍵的風險評估點。

瀑布式開發（Waterfall Development）：

瀑布式開發是一種傳統且線性的軟體開發流程，整個專案會被劃分為數個明確的階段（例如：需求分析 → 系統設計 → 開發 → 測試 → 上線），而每個階段都必須完全完成後才能進入下一階段，就像水流一樣「一層層往下流」。

這種方式在過去大型企業或政府專案中非常常見，因為它流程明確、文件完整、容易管控時程與成本。但缺點是缺乏彈性，如果後期才發現需求改變或方向錯誤，修改成本會非常高。

例句：Traditional enterprises often prefer the Waterfall model because it provides a clear, step-by-step structure.
（傳統企業常偏好使用瀑布式開發，因為它能提供清楚且可控的開發流程。）

對比敏捷開發（Agile Development），瀑布式更像是「先規劃、再執行」；而敏捷則是「邊執行、邊調整」。

版本控制（Version Control）

Repository（儲存庫，簡稱 repo）：是 GitHub 中包含應用程式程式碼的資料夾。所有程式碼的變動歷史都儲存在此，例如 front end 和 backend 的 repo。

例句：The engineering team created two separate repositories (or repos): one for the front end user interface and another for the core backend services.

（工程團隊建立了兩個獨立的儲存庫：一個用於前端使用者介面，另一個用於核心的後端服務。）

Git ：最廣泛使用的版本控制系統，它負責記錄每一次程式碼變動的歷史，是團隊成員共同開發、追蹤進度、並能隨時回溯到任一時間點的核心工具。
GitHub：全球最大的程式碼託管與協作平台，基於 Git 這個版本控制系統，讓工程師能夠將程式碼儲存於 repo 中。團隊主要會在 GitHub 上進行版本追蹤、共同開發、審查程式碼，以及管理軟體開發的生命週期。
Branch（分支）：Git 中的「平行工作空間」。工程師從主線（Main Branch）分出來開發新功能或修復錯誤。它是一種風險隔離機制，確保單一功能的問題不會立即影響到主要產品。
Commit（提交）：將程式碼的變動儲存到本地 repo 的動作，每一次 commit 都包含一個簡短的訊息，說明變動內容。
Merge（合併）：將一個 branch 的程式碼變動合併到另一個 branche（通常是主線）的動作。
Pull Request（合併請求，簡稱為 PR）：是工程師完成功能開發後，向團隊發出的一個請求，請求將自己的 branch 程式碼合併回主線。這也是一個重要的程式碼審查環節。

例句：I’ve finished the payment feature and created a pull request. Can you review it?
（我已經完成付款功能並發了一個合併請求。你能幫我審閱嗎？）

photo credit: Unsplash

科技業 PM 專用術語：產品與使用者體驗術語篇

雖然工程師專注於程式碼實作，但 PM 必須掌握產品與設計團隊的語言，才能準確地將使用者需求，轉化為工程師可執行的任務，確保最終的成果能確實提供使用者價值。

Minimum Viable Product（最小可行性產品，簡稱 MVP）：在專案初期不會一次把所有功能都做完，而是先用最少的資源，開發出「足以驗證市場可行性」的核心功能。這個版本就是 MVP，目的是快速發佈、收集使用者回饋，並依據回饋持續迭代。

例句： We decided to launch the MVP with just the basic video upload and sharing features, allowing us to quickly gather user feedback before developing advanced editing tools.

（我們決定先推出只有基本影片上傳和分享功能的 MVP，以便在開發進階編輯工具前，快速收集使用者回饋。）

User Experience（使用者體驗，簡稱 UX） vs. User Interface（使用者介面，簡稱 UI）：UX 是使用者與產品互動時的整體感受，從登入、使用到完成任務，每一個環節的流暢度與易用性都是 UX 的範疇。UI 則是介面的外觀，包含按鈕、字體、配色與排版等視覺元素。UI 只是 UX 的一部分。
A/B Testing（A/B測試）：
一種常見的產品測試方法，會將使用者分成兩組或多組，分別讓他們看到不同的產品版本，然後比較哪一組的表現（例如：轉換率、點擊率）更好。

例句：We’re running an A/B test on the new homepage layout to see if it increases sign-up rates.
（我們正在對新版首頁進行 A/B 測試，看看它是否能提高註冊率。）
Beta Test（Beta 測試）：產品正式發佈前，將功能開放給一小群外部真實用戶進行測試的階段。目的是在產品大規模發佈前，從實際用戶那裡收集真實的使用回饋和發現潛在的 Bug，以驗證產品的市場接受度與穩定性。

Feature Flag（功能開關）：內建於程式碼中的一個設定開關，它允許產品團隊遠端且即時地控制特定功能是否對選定的使用者群體開放。想像它是一個總電源開關，讓你不需要重新部署程式碼，就能決定哪個群體可以看到哪個新功能。例如，你可以將一個新功能藏在 Feature Flag 後發布，然後只針對一小群使用者開啟進行 beta 測試。這能有效地在不影響所有使用者的情況下，測試新功能、進行 A/B testing，或在出現問題時，迅速 kill switch 以防止災難。

例句：We can use a Feature Flag to roll out the new checkout flow to only 10% of our users initially, allowing us to monitor performance and easily kill switch it if any major bugs appear during the A/B testing.

（我們可以利用功能開關 (Feature Flag)，最初只將新的結帳流程發佈給 10% 的使用者，這樣就能監控性能表現，若在 A/B 測試期間出現任何重大錯誤，也能輕易地緊急終止 (kill switch) 該功能。）

Wireframe（線框圖）/ Mockup（視覺稿）/ Prototype（互動原型）：
Wireframe：最基礎的產品草圖，只呈現功能區塊與佈局，沒有任何視覺細節。
Mockup：在線框圖的基礎上，加入顏色、字體、圖片等視覺元素，看起來就像最終產品的靜態圖。
Prototype：可互動的視覺稿，能模擬產品的點擊與操作流程，讓使用者與團隊在實際開發前，就能體驗產品的流暢度。

如何將這些專業術語應用於日常溝通？

透過上下兩篇的學習，你已經掌握了超過 50 個科技業 PM 必備的英文專用術語，這些詞彙將成為你與工程師之間最有效率的共通語言。

從「聽得懂」到「用得好」，PM 們掌握這些詞彙只是第一步，若想進一步演練，強力推薦你用 VoiceTube Hero 強化英語能力。Hero 會透過真實情境幫助你熟悉更多商務與技術英文詞彙，再透過系統化訓練，將英語力內化，讓你在面對工程師時，能夠自信地表達自己的想法。順利掌握這些術語，你與工程師之間的距離將不再遙遠，也能建立起深厚的信任與默契，全面提升你的專業度。