第 10 章　六周完成一个可验收试点

10.1 六周是一种约束

企业项目的复杂程度不同，不可能都在六周内完成。但限定一个较短周期，能够迫使团队缩小范围、提前暴露风险并持续取得证据。

六周试点不是建设完整平台，而是让一类真实用户在一段真实流程中使用系统，并判断是否值得继续投资。每一周都应产生新的事实，而不只是更多代码。

第一周确认项目理解与现实一致。团队观察用户工作，梳理当前流程，抽取真实样本，并确认数据、接口、权限和关键角色。同时记录业务基线，例如处理时间、错误率、转派率或人工成本。

项目边界也要再次确认：哪些用户参加，处理哪类任务，使用哪些数据，明确不做什么，什么错误不可接受。

这一周最重要的成果不是界面，而是经客户确认的问题定义。如果现场事实推翻了售前阶段的设想，应立即调整。

第二周只盯住最可能让项目失败的假设。

风险在数据，就用真实数据验证质量和权限；风险在模型能力，就建立小型测试集；风险在系统接入，就先打通关键只读接口；风险在用户采用，可以先用人工模拟未来服务，观察结果是否有价值。

方案评审不应只展示架构，还要展示坏消息：哪些假设已被推翻，哪些风险仍未解决，是否需要缩小范围。核心假设不成立时，第二周停止或改向，比第六周才承认失败更专业。

关键风险可控后，团队开始完成端到端流程。先让一条路径从输入走到结果，再扩展更多功能。

系统应使用真实身份和受控数据，包含基本日志、权限、错误处理和人工确认。界面只需支持用户完成任务，不必追求完整产品形态。

评测与开发同步进行。每修复一种失败，就补充相应用例；每增加一个工具，就测试超时、错误参数和权限；每更新知识，就检查旧版本是否仍被检索。

第四周让少量真实用户开始使用。观察他们如何操作、在哪一步离开、是否理解系统边界。用户说“很好”不等于采用，真实行为比会议反馈更可靠。

第五周不再堆新功能，而是集中处理试用中暴露的问题。失败可能来自数据缺失、检索错误、模型误解、权限、入口不便或流程责任不清。团队要按类型统计，而不是见一个修一个。

同时补齐生产所需的基本能力：监控与告警、成本限制、故障降级、版本记录、操作审计和人工接管。还要确认用户遇到问题时找谁，业务中断时能否返回原流程。

如果范围在试用中变化，应公开记录。用加班把新增需求藏进原计划，只会制造无法维护的系统。

最后一周由客户使用约定的验收样本和业务指标检查。除了效果，还要验收权限、安全、日志、异常和人工接管。

试点结束通常有四种决定：达到目标并扩大范围；价值成立但需要先补基础设施；部分假设成立，重新定界再试；核心价值或可行性不足，停止项目。

每一种都比含糊地宣布“POC 成功”更有意义。

每周演示应使用当前数据和真实流程，而不是专门准备的理想样本。团队同时展示已完成事项、失败记录、风险变化和需要客户决策的问题。

短周期沟通能防止双方在不同想象中前进。会议的目标不是证明团队一直正确，而是让项目持续接近事实。

决策日志记录重要取舍、依据、参与人和日期。风险日志记录风险概率、影响、应对方式和负责人。

证据链把需求、数据样本、评测结果、试用反馈、版本和业务指标连接起来。它能说明系统为什么这样设计，也能在验收和扩展时减少误解。

记录应当轻量，但不能依赖某个人的记忆。企业项目真正昂贵的重复，往往来自决策背景消失。

六周试点的核心不是速度，而是用时间约束保护范围，并持续产生证据。先确认现场与基线，再验证最大风险，随后构建最小闭环、进入真实试用、修复失败模式，最后独立验收。

即使试点通过，项目也没有结束。用户是否长期使用、业务指标是否持续变化，决定系统能否真正留下来。