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到生产的最后一公里我们不见不散。
