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