验收标准的第一要义是能被客观验证。如果写的是“系统运行稳定”，那什么叫稳定？客户可以说感觉不稳定，项目组可以说挺稳定的。这种主观描述在验收时就是定时炸弹。更好的写法是“系统连续运行72小时，无宕机、无报错，响应时间不超过2秒”。这样双方都能拿数据说话，谁也糊弄不了谁。
颗粒度其实就体现在这种可验证性上。越细的标准，往往越容易验证。比如功能验收时，写“支持批量导入”就不如写“支持一次性导入5000条客户数据，导入时间不超过30秒，导入成功率达到99.5%以上”来得实在。客户看到这种描述，心里就有底了。
但也要注意，不是越细越好。如果每个按钮的每个点击动作都要写进验收标准，那文档能写成天书。关键是把那些容易产生歧义、影响核心交付物质量的地方写清楚。说白了，颗粒度的取舍就在于“哪些模糊地带最容易引发争议”。
我自己的经验是，验收标准至少要能回答三个问题：交付物是什么？它要达到什么状态？怎么证明达到了？三个问题都能用客观事实回答，颗粒度就算合格了。否则就需要进一步细化，直到每个模糊点都被消除。
分阶段验收意味着每个阶段的侧重点不同，颗粒度自然也要跟着调整。比如需求确认阶段，验收标准偏重文档和方案，颗粒度可以相对粗一些。写“需求规格说明书通过双方评审”就够了，没必要规定评审时每个人必须提几个问题。因为这个阶段的核心是达成共识，不是测试细节。
到了开发完成阶段，颗粒度就得细起来。比如“用户登录功能”可以拆成“用户名密码登录、手机验证码登录、第三方账号登录”，每个登录方式下再写“输入正确信息能成功登录、输入错误信息有提示、连续输错5次锁定账号15分钟”。这种颗粒度才能保证开发出来的东西真的能用。
集成测试阶段的验收标准又不一样。这时候关注的是系统间的交互，颗粒度应该聚焦在接口和数据流上。比如“订单管理系统与库存管理系统同步数据，订单创建后库存扣减在10秒内完成，扣减数量与订单商品数量一致”。写得太粗，集成问题发现不了；写得太细，又会陷入每个字段都要验证的死胡同。
说实话，很多项目在验收阶段出问题，就是因为颗粒度没有跟着阶段走。前期写得太细，客户觉得你们在抠字眼；后期写得太粗，客户又觉得你们在糊弄。最好的办法是每个阶段开始前，双方一起确定这个阶段的验收重点，然后围绕重点来定颗粒度。
颗粒度也不是越细越好。我见过一个项目，验收标准写了厚厚一本，连每个页面按钮的像素位置都规定了。结果开发团队花在改样式上的时间比写核心功能还多，最后项目延期两个月。客户倒是满意了，但成本超支了，双方都不开心。
过度细化的另一个问题是僵化。验收标准定得太死，团队就没有灵活性。比如规定“数据导出必须是Excel格式”，结果客户中途想改成CSV，按验收标准就得走变更流程，耗时耗力。其实如果颗粒度适当放宽，写成“支持常用格式的数据导出”，反而给双方留了调整空间。
还有个实际问题：验收标准写得太细，评审成本会直线上升。每个细节都要双方确认，光开会就能开一周。而且细节越多，出错的概率越大，万一某个小功能没达到标准，整个阶段验收可能就被卡住了。这对项目进度是灾难性的。
所以颗粒度应该有个“黄金区间”：细到能消除主要风险，但粗到不限制执行灵活性。说白了，就是抓大放小。核心功能、关键性能、安全要求这些必须写细；而界面布局、非核心功能、临时性方案这些可以写得相对宽松。这样既保证了交付质量，又给了团队发挥空间。
说了这么多理论，实际怎么操作呢？我推荐一个方法：用“验收清单+验收标准”的格式。验收清单列出这个阶段要交付的所有东西，比如“用户管理模块”、“报表系统”、“接口文档”。每个清单项后面跟着具体的验收标准，标准要符合我们前面说的可验证原则。
比如用户管理模块的验收标准可以写：“支持新增、编辑、删除用户操作，每个操作在2秒内完成；用户信息包括姓名、手机号、邮箱、角色，手机号和邮箱支持格式校验；角色权限控制精确到菜单级别，管理员能看到全部菜单，普通用户只能看到被授权的菜单”。这样的颗粒度既具体又不会太琐碎。
实际操作中，我建议让项目组和客户一起编写验收标准。项目组负责提技术细节，客户负责提业务需求。双方共同讨论每个标准是否合理、是否可验证。这个过程本身就能消除很多误解。比如客户说“数据要安全”，项目组可以追问“具体是指传输加密、存储加密还是访问控制”，通过讨论把模糊需求变成具体标准。
最后还要留个“验收标准调整机制”。因为项目过程中需求可能会变，验收标准也应该相应调整。但调整必须走正式流程，不能口头说改就改。建议在每个阶段验收前一周，双方再review一遍验收标准，确保颗粒度仍然合适。这能避免验收时才发现标准已经过时了。
