Post

什麼是 PoC?

這一年好常在做 PoC

但以前在做 PoC 的時候,雖然大概知道它是「做一個簡單的版本來驗證可行性」,但具體到底要做什麼,其實還是模模糊糊的

剛好最近團隊又有新人進來,就想順便整理一下:什麼是 PoC?什麼時候該做?要怎麼開始做?


在開發中,我們常會遇到這些情況:

  • 「這功能好像可行,但不確定技術能不能撐得住…」
  • 「新技術看起來不錯,但要導入前還是想試試看…」
  • 「這方向好像有搞頭,但怕踩雷、不敢直接開幹…」

這時候,PoC(Proof of Concept,概念驗證)就登場了

PoC 是什麼?

PoC(Proof of Concept)中文是「概念驗證」 簡單說,就是:

用最小的投入去驗證一個技術方向「可不可行」

它不是 Demo,不是 Prototype,也不是 MVP

它只做一件事:降低風險,回答「這件事到底做不做得成?」

PoC 的特色

  • 開發週期短:通常 1~2 週內要有成果
  • 聚焦驗證點:只測最關鍵、最有風險的部分
  • 不做完整產品:不追求 UI、美觀或架構完整性

舉例說明

情境:

我們想在客服系統中導入 ChatGPT 回應常見問題

該怎麼做 PoC?

✅ 要驗證:

  • ChatGPT API 能否穩定串接
  • 回應速度是否小於 1 秒
  • 對特定問題是否能給出合適答案(準確率 > 80%)

❌ 不做:

  • 登入驗證流程
  • 使用者介面設計
  • 上線與部署腳本

完成後,整理出簡單的測試資料與回應結果,就能讓團隊快速決定:「這個方向值不值得做下去?」

PoC、Prototype、MVP 差在哪?

類型重點是否可用對象
PoC驗證可不可行技術團隊
Prototype模擬互動流程設計/PM/Stakeholder
MVP最小可用產品早期用戶

工程師怎麼開始一個 PoC?

  1. 觀察風險或機會點
    • 發現系統可能的瓶頸、新技術、或可優化之處
  2. 明確要驗證什麼
    • 例如:「Kafka + KSQL 能不能每秒處理 5000 筆事件?」
  3. 設定成功標準
    • 例如:延遲 < 200ms、準確率 > 85%、CPU 使用 < 80%
  4. 定義範圍(重點!)
    • ✅ 要驗證:
      • 模擬 1 萬筆訊息流進 Kafka
      • 使用 KSQL 做條件過濾並導出結果
      • 效能是否穩定
    • ❌ 不做:
      • 不接入真實資料
      • 不寫 UI、管理後台
      • 不建 CI/CD
  5. 快速實作,交付可驗證成果
    • 用 mock 資料或簡單 CLI script 即可
    • 以可跑 demo + 數據報告為主
  6. 整理報告與建議
    • 成功與否結論、是否建議進入正式開發或 MVP 階段

PoC 的優缺點

優點

  • 降低技術或整合風險
  • 快速試錯、加速決策
  • 成本低、資源投入少
  • 有助提案與說服他人

缺點

  • 範圍窄,無法代表全系統狀況
  • 成果容易被誤解為半成品
  • 沒有驗證標準可能導致判斷模糊
  • 做太久反而浪費資源

什麼情況該考慮 PoC?

  • 對新技術、架構、整合流程有疑慮
  • 團隊內對方向有爭議,需要客觀數據佐證
  • 想提案新功能但需要先證明「技術做得到」
  • 想降低試錯成本、不願直接開發完整產品

總結:PoC 是工程師降低風險的利器

PoC 的價值,不只是證明「做得到」,更是幫助團隊做出明智決策

身為工程師,你可以主動提出一個 PoC,讓自己不只是做事的人,更是懂判斷方向的人

技術不是只是能不能做,而是值不值得做 PoC 幫你把「值不值得」變得更清楚

補充:Spike 跟 PoC 有什麼差別?

最近有 team member 看了這篇文章跟另外一篇關於 Spike Item 的內容後,突然問我:「Spike 跟 PoC 到底有什麼差別啊?」

我覺得這問題很好,也蠻多人其實不太確定兩者的界線,就順手整理一下,附上我們自己團隊常用的例子和比對方式

範例對比

Spike 範例

「我們要不要選用 Redis Stream?有哪些替代方案?有什麼限制?」

Spike 任務可能是:

  • 查 Redis Stream、Kafka、RabbitMQ 的比較
  • 整理優缺點 + 建議方向
  • 回報給 PO 或團隊做後續決策與估點

產出物:一份調查比較表或 Notion 調查頁面

PoC 範例

「我們能不能用 Kafka + KSQL 處理即時報表?」

PoC 任務會去:

  • 搭 Kafka 環境
  • 模擬資料流、實作查詢
  • 評估效能指標(如延遲 < 200ms)

產出物:可以實際跑的 demo + 數據報告

何時用哪一個?

情境用哪個?
不知道選哪個框架Spike
想知道這個技術能不能撐高流量PoC
團隊對技術實作方向有爭議Spike(先了解選項)→ PoC(再驗證可行性)
想快速 demo 一個 AI 自動標籤功能給主管看PoC
  • Spike 是為了解決「資訊不足」的問題,幫助團隊設計與估點
  • PoC 是為了解決「技術不確定」的問題,幫助團隊驗證與決策

兩者都很重要,但目標不同、成果不同

在實務上,也常會出現「Spike 後決定做 PoC」的情境

This post is licensed under CC BY 4.0 by the author.