什麼是 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」的情境