验收标准的颗粒度不能一刀切，得先看验收的目的是什么。说白了，不是为了让文档好看，而是为了双方能清晰判断“这一步到底过了没”。所以核心原则就是：标准必须能直接执行，并且能当场验证。
举个例子，如果你写“系统响应速度快”，这就不合格。什么叫快？客户说3秒算快，你觉得1秒才叫快，当场就吵起来。正确的写法应该是“页面加载时间不超过2秒，以Chrome开发者工具测试为准”。这样颗粒度就对了：有具体数字，有验证手段。
每个阶段的验收标准，必须落到一个具体的动作或指标上。比如“完成数据迁移”就不如“完成1000条客户数据的迁移，迁移后数据完整率100%，且与源系统比对一致”。后者能测试，能签字，能打钩。
实操中我建议把每个标准拆成三个要素：验收对象（哪个模块）、验收条件（什么状态下算通过）、验收方式（怎么测）。这三要素齐全了，颗粒度基本到位。
B2B项目往往分需求确认、原型评审、开发交付、试运行、正式上线等阶段。每个阶段的验收重点不同，颗粒度自然不能一成不变。比如需求确认阶段，验收标准颗粒度可以粗一点，因为这时候看的是方向和框架。
在需求确认阶段，你写“功能清单覆盖业务需求”就够了，不需要具体到每个按钮的交互逻辑。但到了开发交付阶段，就得细化到“登录功能支持手机号和邮箱两种方式，密码输入错误三次后锁定账号30分钟”。因为这个阶段是要落地了，模糊标准只会让验收变成扯皮。
试运行阶段更特殊，颗粒度要偏向“业务连续性”。比如“系统连续运行72小时无宕机”或者“并发用户达到50人时响应时间仍低于3秒”。这些标准直接关联实际使用体验，写粗了根本发现不了潜在问题。
所以一个实用技巧是：越靠前的阶段，颗粒度越偏向宏观确认；越靠后的阶段，颗粒度越偏向细节验收。但无论如何，每个标准都得有明确的是/否判定，不能留灰色地带。
很多团队怕扯皮，就把验收标准写成天书，每条都精确到像素级。这其实是个大坑。过度细化会让验收流程变得极其繁琐，每个小点都要反复核对，团队和客户都累，最后验收变成走过场，反而失去了意义。
我见过一个项目，验收标准里写“按钮颜色为#2B7CE6，圆角为4px，字体大小为14px”。这种细节有没有必要？说实话，如果客户没提UI规范，这就是给自己加戏。验收标准应该聚焦在“功能是否满足业务需求”上，而不是给设计稿做二次审核。
颗粒度的“最小必要”原则很简单：只要这个标准不写，双方可能产生分歧，那就必须写；如果写了反而增加无效工作量，那就果断删。比如“系统支持导出Excel”这个标准，你只需要写“导出文件格式为.xlsx，内容包含列表所有字段”，不需要写“Excel文件名格式为yyyyMMdd_项目名称”。
另外建议在验收标准里加一条“争议处理机制”。比如“双方对某项标准理解不一致时，以合同附件中的业务需求说明书为准”。这能有效避免因为颗粒度问题导致的无限扯皮。
拿一个实际项目举例：某公司采购CRM系统，分三阶段验收。第一阶段是“客户管理模块”。粗颗粒度的写法是“实现客户信息增删改查”，这完全不行。合格的写法应该是“支持录入客户名称、电话、邮箱、公司名、备注五个字段；删除客户后数据进入回收站，30天内可恢复；查询支持按姓名和公司名模糊搜索”。
这里面每个点都能测试：录一个客户看看字段全不全，删一个客户看看回收站，搜一个名字看看模糊匹配。客户当场就能验证，不需要任何解释。这才是颗粒度到位的标准。
还有一个小技巧：验收标准最好附带验收脚本。比如“按以下步骤测试：1. 点击新增客户，填写五个字段后保存；2. 在列表中查看新增记录；3. 点击删除，检查回收站”。脚本不需要多复杂，但能把标准变成可操作的动作。
最后提醒一句：验收标准写完后，一定要让客户方也签字确认。很多项目出问题，就是因为双方对标准理解不一致。你写“系统响应快”，客户以为0.5秒，你以为是3秒，验收时必然翻车。颗粒度写到位，再加上双方确认，才能让验收真正服务于项目交付。
