很多时候不明白合格是什么意思？今天给你讲明白

今天跟大家聊聊“合格”这个词，我发现很多人对这个词的理解老是跑偏，搞得大家做事情要么战战兢兢，要么就是稀里糊涂。我自己的体会是，合格不是一个终点，它就是你干活的起点，是个很基础的线，过了这条线你才能算上交了作业，至于好不那就是另一个话题了。

我刚开始工作那会儿，特别想把事情做到完美，恨不得每个细节都抠到不行。记得有一次做个小功能模块，老板说“赶紧上线，差不多就行”。我，花了双倍时间去优化代码结构，加了一堆自以为是的健壮性检查，结果上线时间拖了三天。等我把这“完美”的代码交上去后，老板的反应是皱着眉头问我：“你这怎么慢了这么多？功能实现了吗？测试那边说你这里有个边界没测到。”

那一刻我就明白了，我理解的“好”跟老板理解的“合格”完全不是一个频道。

合格的定义，就是满足基本需求

后来我学乖了，每次接任务前，我都会主动把需求掰开了揉碎了问清楚。

• 第一步，我先确定“必须实现的功能点”是什么。这就像盖房子的地基，少了肯定不行。如果一个系统要求能处理每秒一百万次的请求，那么能稳定处理十万次，那就是不合格的。合格的标准是能够稳定跑满一百万次，不多不少，能扛住。
• 第二步，我关注“非功能性需求”里的底线。比如安全性，代码不能有明显的注入漏洞，数据传输得加密。这不是说要用最顶级的加密算法，而是指能通过常规的安全扫描测试，不留明晃晃的后门。
• 第三步，时间点和交付标准。老板说三天交，那么三天内把核心功能跑起来，让测试人员能上手测，这就是合格了。我非要等到第三天晚上才把所有注释和文档补齐，那虽然是更但可能已经超出了“合格”的范围，成了“超额完成”。

我的实践路子

我开始转变思路，把工作流程拆成好几段。

我接手一个项目，比如要开发一个用户登录系统。我不会一上来就设计整个数据库模型和高并发方案。我会先搭个最简单的框架，实现能用用户名密码登录，能返回一个Token就行。这是“最小合格产品（MVP）”的概念。

我把这个“能跑”的版本立马丢给测试同事，让他们去跑最基本的流程，验证账户创建、登录、登出。他们反馈说：“密码校验太弱了，直接明文传的。”这就是一个明确的不合格项。

我立马回来，把密码校验改成MD5加盐（当时的行业标准，现在看来也未必是最好的，但那个阶段是合格的）。然后再交回去测试。

测试过关后，我才开始着手处理那些“锦上添花”的部分，比如图形验证码、多设备登录限制等等。这些东西做完了，系统就不只是“合格”了，而是“优秀”了。

关键在于，我没有在最开始就陷在对“完美”的追求里，把大量时间浪费在那些非核心、非硬性要求的细节上。合格的意思就是，你拿出来的东西，别人接手后能继续往下干，不会因为你的东西有硬伤而被退回来重做。

我总结了一下，合格就是那条红线，你得踏在线上，而不是踩在线下，更不是站在线上跳舞。踏在线下就意味着返工，站在线上跳舞意味着你浪费了本可以花在下一阶段优化上的时间。

下次接到任务，别急着想怎么做得最先搞清楚“什么情况下这东西才能被接受”。把那个接受的标准搞明白了，你的效率自然就上来了，心里也没那么多包袱了。