软件项目交付期：谁来编写验收标准？

去年带团队做电商系统交付时，客户突然在评审会上问：“你们这‘智能推荐’功能到底怎么算合格？”我当场卡壳——这才发现，验收标准这东西要是没写透，能把交付期拖成拉锯战。  

其实验收标准哪有什么“标准答案”？它得像块海绵，吸饱客户想要的、团队能做到的、测试能验证的。我们组产品老张常说：“别想着一个人憋出来，客户嘴里的‘好用’，得翻译成能落地的条条框框。”  

谁在写？产品牵头，但得“众人拾柴”

产品负责人肯定是第一责任人，毕竟最懂客户那本“需求经”。但光他一个人写容易跑偏——就像上次老张自己写了套验收标准，开发一看直摇头：“这‘界面美观’咋量化？”后来我们改成“产品牵头搭骨架，团队填肉”：客户成功经理补充实际使用场景，UX设计师标清交互细节，服务台专员把历史投诉里的坑都挖出来。  

最有用的还是“三剑客”凑一块儿碰。去年做支付模块，产品、开发、测试挤在小会议室吵了三小时：产品说“到账要快”，开发说“银行接口延迟至少2秒”，测试补刀“得考虑网络波动时的兜底方案”。吵完写出来的验收标准，连财务对账的老王都说“这回知道咋验了”。  

质量工程师老李在这事儿上特较真。有次验收标准写“系统稳定”，他直接打回去：“稳定是啥？7×24小时无宕机？还是错误率低于0.1%？”他还爱翻旧账：“上次那个‘快速加载’没写并发数，上线后50人同时点就崩了，这次得把INVEST原则带上——独立、可商量、有价值、能估算、大小合适、可测试，少一条都不行。”  

怎么写？两种路子，看菜下饭

写验收标准跟做菜似的，有的适合“列菜单”（规则导向），有的得“讲故事”（场景导向）。  

规则导向适合非功能需求，比如“系统必须扛住1000人同时下单”“数据加密符合GDPR第32条”，明明白白划红线。我们做政府项目时全用这套，客户审计时拿过来就能对。  

场景导向更接地气，尤其敏捷团队爱用。就像给功能编个小剧本，用Gherkin语法写——其实就是五句话：场景是标题，Given说“谁在啥时候”，When说“干了啥”，Then说“该咋样”，And用来加细节。  

举个真实例子：我们做会员预注册功能时，验收标准这么写——  

场景：预授权用户小李想注册  

Given：我是拿到邀请码的小李，正在登录页  

When：我输邮箱、点“注册”按钮  

Then：系统认出我是预授权用户，跳转到完善资料页  

And：页面顶部显示“欢迎回来，请补全信息”  

别小看这几句，测试用它写自动化脚本，客户看了也懂“哦，原来是这样”。  

Gherkin不是Cucumber，别搞混了

很多人以为Gherkin就是Cucumber，其实差远了。Gherkin是写验收标准的“剧本”，Cucumber是把剧本变成自动测试的“放映机”。我们试过直接用Cucumber跑测试，结果发现剧本写得糙，机器根本读不懂——后来先把Gherkin写扎实，再用Cucumber转代码，效率高多了。  

这套组合拳还带出了BDD（行为驱动开发）的思路：验收标准不再是文档，成了“需求即代码”。上次迭代，我们把Gherkin语句直接嵌进开发分支，测试跑脚本时就能对照着改bug，客户中途改需求？更新Gherkin就行，不用重写一堆文档。  

验收标准是“共同想象”的落地

现在回头看，验收标准哪是张纸啊，是团队和客户对“好产品”的共同想象。写得越实，后期扯皮越少——就像盖房子，图纸画明白了，瓦工泥工才知道咋干。  

最近在学用“需求卡片”代替长文档，把验收标准拆成小条贴墙上，客户路过都能指指点点。上周客户指着“注册页加载不超过2秒”说：“这个得加粗，我们上次用竞品等了5秒就关了。”你看，当验收标准活起来，交付期反而顺了。