FDE系列12PoC的正確姿勢——用最小代價驗證最危險的假設本文是《FDE工程師-從AI技術實現到業務落地》系列文章第12篇“客戶說先做個PoC驗證一下。”這句話可能是FDE工作中最容易被誤解的一句話。大多數人對PoC的理解是錯的大多數技術人理解的PoCProof of Concept概念驗證“做一個簡化版的系統證明技術方案可行。”但FDE理解的PoC“用最小的代價驗證這個項目最危險的假設是否成立。”這兩個理解看起來差不多但實際做起來天差地別。“證明技術方案可行”意味著你默認技術方案是對的PoC只是走個過場。“驗證最危險的假設”意味著你承認我可能錯了PoC是為了找出哪里錯了。前者是說服客戶后者是驗證真相。PoC的黃金法則1-2-11個核心場景不要試圖在PoC中覆蓋所有場景。只選最能代表項目價值的那個場景。客戶說要優化供應鏈——PoC只做庫存預測這一個場景客戶說要AI客服——PoC只做訂單查詢這一個場景客戶說要數據中臺——PoC只做銷售數據可視化這一個場景一個場景做好了比十個場景做一半更有說服力。2個關鍵指標PoC只關注2個指標技術指標方案能不能跑通準確率、響應時間、覆蓋率業務指標方案能不能產生價值效率提升、成本降低、用戶滿意度每個指標都要有明確的成功標準。場景技術指標業務指標智能客服意圖識別準確率 85%人工客服工單減少30%庫存預測預測準確率 80%庫存周轉率提升15%換線優化參數預測準確率 90%換線時間縮短50%1周完成PoC不是一個迷你項目它是一個快速實驗。1周足夠。第1-2天數據準備第3-4天方案實現第5天驗證和匯報如果1周內做不出PoC說明這個方案太復雜了或者你選錯了場景。PoC的一頁紙計劃書PoC不需要復雜的文檔一頁紙就夠了PoC計劃書 項目名稱XXX 核心假設XXX我們最危險的假設是什么 驗證目標XXX驗證什么 驗證方法XXX怎么做 成功標準XXX什么算驗證通過 時間計劃XXX1周之內 資源需求XXX需要什么 風險評估XXX可能出什么問題這份計劃書需要客戶簽字確認。PoC的執行流程階段一準備第1-2天數據準備拿到客戶真實數據不是模擬數據了解數據質量臟數據、缺失值、格式問題確認數據可以用于PoC環境搭建搭建最小運行環境確保數據可以正常接入關鍵產出數據可用性確認階段二實現第3-4天快速實現不要追求優雅追求能用用最熟悉的工具不要學新東西做好失敗的準備關鍵產出可運行的PoC原型階段三驗證與匯報第5天驗證結果對照成功標準逐項檢查收集數據形成結論匯報要點結果驗證通過/有條件通過/不通過數據關鍵指標的實際值發現過程中發現了什么建議下一步應該怎么做關鍵產出PoC結論報告PoC的三種結果結果一Go繼續驗證通過項目進入集成落地階段。行動把PoC方案升級為生產級方案。結果二Pivot調整部分驗證通過但有些假設不成立需要調整方案。行動調整方案重新驗證。結果三No Go放棄驗證不通過核心假設不成立。行動停止項目及時止損。“No Go不是失敗而是成功排除了一個錯誤選項”。PoC的常見陷阱陷阱一用模擬數據做PoC用模擬數據做PoC什么都驗證不了。客戶的數據永遠是臟的、亂的、不完整的。用模擬數據驗證通過的方案一上真實數據就崩。PoC必須用客戶真實數據。陷阱二PoC做太多了PoC覆蓋了3個場景花了3周結果第1個場景沒通過后面2個場景白做了。PoC不要貪多1個場景1周夠了。陷阱三把PoC當免費開發有些客戶把PoC當成免費試用讓FDE做很多功能做完了就不了了之。PoC的產出物是驗證報告不是可交付的軟件。在PoC開始前就要和客戶說清楚PoC產出的代碼不能直接用于生產環境。PoC自檢清單我有沒有識別出最危險的假設我有沒有選對1個核心場景我有沒有設定2個關鍵指標我能不能在1周內完成我有沒有用客戶真實數據我有沒有和客戶確認PoC的產出物不是可交付的軟件 關注「AI拉呱」本系列持續更新中。下一篇預告FDE系列13系統集成——從PoC到生產的最后一公里我們不見不散。