LabHub

博客

PoC 为什么到不了生产环境 — 成功标准、安全评审、交接

한국어English日本語中文

PoC 的坟场 — 它们是怎么死的

FDE 工作里最令人泄气的一幕,是技术上成功的 PoC 无声无息地消失。演示会上有掌声,对接人也满意,三个月后一问——什么都没发生。做尸检的话,死因通常是下面五种之一。

关键在于:五条没有一条是代码问题。从 PoC 到生产的这段路,分出胜负的是运营设计,不是工程功力。而且在这段路上,FDE 的角色是双层的:既是写代码的工程师,同时也是照看成功标准、日程与干系人的事实上的项目经理。哪一刻你认定后一层不归自己管,上面五种死因之一就被预订到你名下。下面四章,按顺序讲的正是后一层的活。

开工之前,把成功标准写成文档

成功标准文档在 PoC 开始之前写,和客户一起写,一页纸。数字、期限、裁判三者齐备才算标准,缺一个就只是感想。

[PoC 成功标准 — 构造的示例]
目标    :将客服文档检索到首次响应的时间缩短 40%
测量    :以 100 通会话为样本,测量检索到首次响应时间,为期两周
基线    :现行平均 90 秒(开始前用一周的预测量达成共识)
判定    :54 秒及以下为成功;裁判为客户方呼叫中心运营主管
失败条件:二次检索率超过 15% 时,无论速度如何判为失败
下一步  :成功后 4 周内启动试点扩大范围与预算讨论

这份文档里最值钱的一行是失败条件。事先写明失败条件的 PoC,即使失败也会留下信任——因为所有人都确切知道了什么行不通。反过来,没有失败条件的 PoC,即使成功也留下怀疑。而最后一行——成功之后会发生什么的承诺——是让 PoC 通向决策的那根线。

安全评审、权限、数据边界

安全评审不是 PoC 的最后一道关,而是第一周的日程。第一周就约客户安全团队开 30 分钟的会,敲定三件事。

第一,数据边界。客户数据最远走到哪里?会不会流向外部 API,流出的是哪些字段?日志里留下什么?会不会被用于模型训练?把这些问题的答案画成一张图并达成一致,之后本会出现的反对意见大半就被提前消化了。第二,权限。PoC 账号按最小权限申请,并盖上失效日期。图省事收下的管理员权限,会在日后的安全审计里变成折损整个 PoC 信誉的证物。第三,评审时间表本身的共识。第一周就问清生产转换需要哪些审查、通常要几周,最后一周的惊吓就消失了。

PoC 代码里藏着的负债

PoC 代码为了快速证明而刻意举债。问题在于这笔债隐形着,却成了生产决策的依据。讨论转产的时候,必须把负债清单摆上桌面。

抢在客户之前亮出这份清单,是 FDE 的诚实,同时也是转产报价的依据。「演示都跑通了,生产为什么要三个月」这个问题的答案,就是这份清单。有一点要注意:负债清单要用报价的语言说,不要用威胁的语言说。「还清这五项需要这么多周」在客户耳中听起来是计划而不是成本,而清单越具体,转产预算的审批就越快。

交接文档 — 为离开那天准备

FDE 的成功条件很特别:没有你也能转,才算成功。驻场结束那天系统跟着停摆,那就不是交付,是出租。所以交接文档不是最后一周才写,而是从项目中期就开始积累。

[交接文档目录 — 构造的示例]
1. 系统概览   — 一张架构图和数据流向
2. 运维流程   — 启动、停止、部署、备份、恢复
3. 故障手册   — 高频症状各自的前 30 分钟动作
4. 权限与联系人 — 账号清单、审批人、升级路径
5. 已知边界   — 做不到的事、未决问题、临时措施清单
6. 扩展路线   — 讨论过的下一步与被搁置的事项

客户日后翻得最勤的,是故障手册。FDE 工程师养成 RPG 的交接角色被设计为只能在带运行手册的任务上游玩,理由相同:没有手册的系统,是交不出去的系统。交文档那天别只交文档——让客户工程师照着手册亲手处理一遍某个故障场景,这场彩排做完才算收尾。

亲手练习

PoC 运营的手感,靠压力之下的决策练习养成。

FDE 完全指南系列

评论

还没有评论。

登录后即可发表评论