在產品開發過程中，PM 對技術概念的理解深度可能會影響需求落地精準度 與開發時程可控性，若能掌握一些基本技術用語，不僅能幫助 PM 更好地理解技術限制與實作可能性，更能提升與工程師的溝通效率。
一、API 基礎概念
⠀⠀（一）HTTP 方法：GET/POST/PUT/DELETE
- 核心差異：GET 用於「讀取資料」（如查詢商品資料），POST 用於「新增資料」（如新增商品），PUT 用於「更新」（如編輯商品），DELETE 用於「刪除」（如刪除商品）。
- 應用場景：在進行 API 串接時，或自行用 Postman 呼叫 API，需理解什麼情境要觸發什麼請求，例如查詢都是用 GET 為主，新增都是用 POST 為主。
⠀⠀
（二）API 與 Endpoints
- 技術定義：API（Application Programming Interface）是系統間溝通的橋樑，Endpoints指特定功能的存取路徑（如
/product/details）。 - 應用場景：使用者透過
/product/details，加上 GET，即可查詢商品，有時不同版本也會有 v1/v2 的區分，另外每隻 API 也會有各自的速率限制（Rate Limiting），例如 1 秒最多打 5 次。
⠀⠀
（三）狀態碼（Status Codes）
- 常見代碼：200 OK（成功）、404 Not Found（資源不存在）、500 Internal Server Error（伺服器錯誤）。
- 應用場景：呼叫 API 時，為了確認有沒有呼叫成功，對方通常會回傳代碼+回傳結果，以 GET/product/details 為例，若呼叫成功，則會獲得 200 加上商品詳細內容。
⠀⠀
（四）悲觀鎖（Pessimistic Locking）
- 基本定義：假設會發生衝突，先鎖定資源再操作
- 應用場景：當多個用戶同時購買同一商品時，需使用鎖定機制避免超賣；或當用戶支付訂單時，需鎖定訂單狀態，防止重複付款。
⠀⠀
⠀⠀
二、後端與資料庫核心概念
⠀⠀
（一）CRUD 操作
- 基本定義：CRUD 分別代表 Create（新增）、Read（讀取）、Update（更新）、Delete（刪除）四種資料操作。
- 設計影響：在設計功能或介面時，需明確規範每項功能或欄位的 CRUD 權限（如客服人員僅有 Read 權限、或訂單頁面只能 Read）。
⠀⠀
（二）SQL
- 基本定義：SQL（Structured Query Language）是用於管理和查詢關聯式資料庫的語言，PM 雖然不需要自己寫 SQL，但理解其基本概念在某些撈資料的情境可以更好地與工程師溝通。
- 應用場景：想了解「過去 30 天內，完成註冊但未下單的用戶數量」，需要資料庫中查詢 users 表和 orders 表，並使用 JOIN 和 WHERE 條件篩選資料。
⠀⠀
（三）索引 Indexing
- 基礎定義：索引是資料庫中用來加速查詢的技術。
- 應用場景：用戶反映「訂單查詢」頁面載入很慢，可能是查詢
orders表時缺少索引，導致全表掃描（Full Table Scan）。
⠀⠀
（四）任務佇列（Task Queue）
- 基礎定義：「先進先出」（First In, First Out, FIFO）的數據結構，用於管理需要按順序處理的任務。
- 應用場景：當用戶下單時，系統將訂單資料放入佇列，由背景服務逐筆處理（如庫存扣減、發送確認信）。
⠀⠀
（五）暫存（Caching）
- 基礎定義：將常用數據暫存在快速存取位置（如記憶體）的技術，用於減少資料庫查詢壓力與提升系統效能。
- 應用場景：將熱門商品資訊（如名稱、價格、圖片）儲存在緩存中，減少資料庫查詢次數。
⠀⠀
⠀⠀
三、系統架構與 DevOps 基礎
⠀⠀
（一）微服務（Microservices）vs 單體式架構（Monolithic）
- 單體式：所有功能打包成單一應用程式，部署簡單但難以擴展
- 微服務：拆分成獨立服務，利於團隊分工但增加維運複雜度
⠀⠀
（二）負載平衡（Load Balancing）
- 運作原理：將流量分散到多台伺服器，避免單點過載。
- 情境案例：規劃電商大促活動時，需提前與工程團隊確認負載測試（Load Test）結果。
⠀⠀
（三）CI/CD（持續整合/持續部署）
- 實際流程：開發 → 自動化測試 → 合併到主分支（Branch） → 自動部署到預發環境（Stage） → 手動上線（Prod）
- 應用場景：理解 CI/CD 流程和 Branch 後，可更準確評估哪個功能要放在哪個分支，並在幾號可以上線，同時也能理解 Hotfix 的概念。
⠀⠀
⠀⠀
四、總結：如何累積技術概念
最近在工作中，發現若能多懂一點技術名詞，在和工程師溝通時能順暢許多，除了開需求時能更貼近他們語言，在遇到日常異常處理、Bug 修復，也能更清楚知道系統的根本問題出在哪。
- 提升溝通效率：使用正確術語，與工程師對齊需求，例如 API 的指定欄位。
- 預判技術風險：理解佇列積壓、鎖定衝突、緩存失效等問題的影響，提前制定應對方案，例如當搶購商品時，系統需要準備什麼應對措施。
但這篇並非記錄所有的技術名詞，只是先記錄我在工作中有遇到的關鍵字，後續再陸續補充其他技術細節。
如對這系列文章有興趣可以再觀看：
