PM 常見的技術用語：從 API 到系統架構的基礎概念｜EP78
在產品開發過程中，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 的指定欄位。
- 預判技術風險：理解佇列積壓、鎖定衝突、緩存失效等問題的影響，提前制定應對方案，例如當搶購商品時，系統需要準備什麼應對措施。
但這篇並非記錄所有的技術名詞，只是先記錄我在工作中有遇到的關鍵字，後續再陸續補充其他技術細節。
如對這系列文章有興趣可以再觀看：
92會員
166內容數
《思維的創意想像》是工作之餘發起的 Side Project，因為近期快速吸收各種資訊跟商業知識（Input），但一直沒有地方輸出（Output），因此想透過這系列記錄學到的內容，包含商業知識、產業洞見，或是職場分享等等，目前已有產品開發、客戶成功、社群行銷、思維增長、職場日記等系列文章。
留言0
查看全部
你可能也想看
Google News 追蹤
實際就業後，會發現收集與分析需求，通常都不是工程師在做，會有另一群人，以非工程的角度收集及分析需求，然後在開發過程中蹦出不同的火花，於是很好奇另一群人的想法是什麼？我不敢說這本書能完全代表另一群人的想法，但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
本文整理了有關技術文件寫作的重要觀念，包括 docs as a product、內容優先，並說明如何構思文件架構。
軟體系統的發展歷程大多相似，首重解決基本需求、提供操作介面，進而提升安全性、擴充功能、優化操作。
前年第一次藉公司機會，參加了DevOpsDay的活動。雖然devOps一詞各自表述，大多狀況還是偏向維運會遇到的技術為主，做為平時開發、跟使用者訪談需求的工作內容來說，參加聚會如果沒有一定的知識，對講者所提到的狀況比較難有共鳴...
程式設計中不可或缺的一部分
介面是使用者與程式互動的媒介，因此介面的設計會影響使用者的體驗和感受。一個清晰明白、易懂的介面，可以讓使用者輕鬆地使用程式，並獲得良好的使用體驗。
需要與程式設計師密切溝通
設計師需要了解程式的功能和需求，並根據使用者的習慣和需求進行設計。設計師和程式設計師之間的溝
系統的分析與規劃
在談到程式設計時，首要的是進行系統的分析與規劃。程式設計的起點通常是系統分析與規劃，這涉及到如何分析和設計系統的大原則和方向。為了達到預期效果，重要的是擁有對產業的清晰邏輯認識和深入了解。
進行深入了解
若要進行系統分析，必須對企業的設計和程式設計的對象進行深入了解，以充分理
替產業做設計
有人要我談程式設計，那我就稍微談一下。我從事的大都是產業的工作，所以我們也從如何替產業做設計來談起。基本上，每個產業都會有自己的作業流程，大同小異。但是基礎來做都是一樣的，都會有客戶、物料、產品、供應商、員工等資料。不同的是，由於企業型態的不同，他們每個人有不同的作業流程。這個作業流
提到後端工程師，似乎就只是開發 API，但一個複雜的系統其實不太可能只透過 API 就能完成，例如一個簡單的功能，註冊會員，其實是由好幾個不同類型的工作互相配合，您才能收到開通信，才確保資料庫不會有一堆未開通帳號等。所以今天就來聊聊一個系統有幾種不同執行方式的工作。
實際就業後，會發現收集與分析需求，通常都不是工程師在做，會有另一群人，以非工程的角度收集及分析需求，然後在開發過程中蹦出不同的火花，於是很好奇另一群人的想法是什麼？我不敢說這本書能完全代表另一群人的想法，但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
本文整理了有關技術文件寫作的重要觀念，包括 docs as a product、內容優先，並說明如何構思文件架構。
軟體系統的發展歷程大多相似，首重解決基本需求、提供操作介面，進而提升安全性、擴充功能、優化操作。
前年第一次藉公司機會，參加了DevOpsDay的活動。雖然devOps一詞各自表述，大多狀況還是偏向維運會遇到的技術為主，做為平時開發、跟使用者訪談需求的工作內容來說，參加聚會如果沒有一定的知識，對講者所提到的狀況比較難有共鳴...
程式設計中不可或缺的一部分
介面是使用者與程式互動的媒介，因此介面的設計會影響使用者的體驗和感受。一個清晰明白、易懂的介面，可以讓使用者輕鬆地使用程式，並獲得良好的使用體驗。
需要與程式設計師密切溝通
設計師需要了解程式的功能和需求，並根據使用者的習慣和需求進行設計。設計師和程式設計師之間的溝
系統的分析與規劃
在談到程式設計時，首要的是進行系統的分析與規劃。程式設計的起點通常是系統分析與規劃，這涉及到如何分析和設計系統的大原則和方向。為了達到預期效果，重要的是擁有對產業的清晰邏輯認識和深入了解。
進行深入了解
若要進行系統分析，必須對企業的設計和程式設計的對象進行深入了解，以充分理
替產業做設計
有人要我談程式設計，那我就稍微談一下。我從事的大都是產業的工作，所以我們也從如何替產業做設計來談起。基本上，每個產業都會有自己的作業流程，大同小異。但是基礎來做都是一樣的，都會有客戶、物料、產品、供應商、員工等資料。不同的是，由於企業型態的不同，他們每個人有不同的作業流程。這個作業流
提到後端工程師，似乎就只是開發 API，但一個複雜的系統其實不太可能只透過 API 就能完成，例如一個簡單的功能，註冊會員，其實是由好幾個不同類型的工作互相配合，您才能收到開通信，才確保資料庫不會有一堆未開通帳號等。所以今天就來聊聊一個系統有幾種不同執行方式的工作。