项目验收怎么定标准，避免「做完了但不算数」

项目扯皮最多的，不是做得好不好，是「算不算做完了」。 而这个问题的答案，在开工那天就该写下来，不是等到交付那天再谈。

三层验收，缺一层就有争议

功能验收：能不能用。 按需求文档逐条走一遍，每条要么通过，要么记录为待修复。这一步最基础，但只有它是不够的。

数据验收：数据对不对。 新建一条数据、改一条、删一条，看关联的数据有没有跟着变。很多问题不体现在功能上，体现在数据不一致上。

性能验收：多快、能扛多少人。 这一步最常被跳过，然后在上线第一周出事。

验收流程要写清四件事

• 谁验：必须是能拍板的人，不是「大家看看」
• 多久：提交后几个工作日内反馈，超时视为通过（这一条对双方都是保护）
• 不通过怎么办：列问题清单，开发方限期修复，修完再验一次
• 验收后改需求算什么：属于新需求还是缺陷修复，要事先分清

三个常见的坑

口头验收： 「我看过了，可以」——出了问题没有任何凭据。验收必须有书面记录，哪怕是邮件确认。

边做边改不留记录： 项目过程中改了十几次，每次都口头说，最后没人说得清「现在的版本到底对应哪版需求」。

尾款付完就没人管： 所以尾款要和质保期挂钩。行业常见做法是留一成到两成，质保期结束后支付。

质保期该保什么

质保期保的是「缺陷」，不是「新需求」。缺陷是没按需求实现或者实现错了；新需求是当初没提、现在想要的。

这两件事在合同里必须分开写，否则质保期会变成无限期免费开发。 常见约定是质保期三个月到一年，期间缺陷免费修，新需求单独报价。

最后

验收标准的价值不在于严格，在于双方事先都同意。 一份双方都签过字的验收清单，能让交付变成一件走流程的事，而不是一场谈判。