我当过项目经理，也当过交付经理，见过忒多“完美项目”最终烂尾，也见过忒多“烂尾项目”横空出世。所谓质量负责人，不是啥高高在上的质检官，就是项目出难题了，能最快把烂摊子收拾烂的那群人。他们不负责把产品修得有多像苹果，他们只负责确保我们的车能在路上跑，且别把乘客送进海里。 日常里，我的脑子里全是“返工”两个字。
那会儿认定返工是低级毛病，目前明白，返工就是资源被锁死，工期被拖死，客户信任被践踏。作为质量负责人，我实际上是在替老板挡子弹。
要是项目上线了全是 Bug，那是交付团队没本事；但要是连个需求都没搞清楚就扔出去，那才是我这行最大的失误。
故此，我平时最烦就是那种“为了赶进度能够牺牲质量”的口头禅，哪怕老板嘴上说着“我们看重质量”，转身就要推掉下周的需求。
这时候我得站出来，把数据摆出来，把风险讲清楚，哪怕得罪人，也得把路走正。 技术上，我不背那些复杂的 ISO 标准要么 FMEA 表格，那些文牍玩意儿我当年在仓库里都嫌费事。我的脑子里只有一套好办的逻辑：需求对不对？代码写得稳不稳？测试覆盖到底了没？要是业务逻辑跟实际用场景对不上，哪怕测试用例写得再花哨，那也是耍流氓。记得我之前带过一个电商项目，上线前我让团队做了 80% 的测试用例，但关键流程全漏了。结局一上线，用户下单后显示“支付成功”，但钱根本到不了账户。
那一刻我慌了，不是怕担责，是真怕人回家哭。
后来我直接穿透代码，找到那个绕过校验的 bug，那是个后台逻辑漏洞，强行屏蔽了支付接口。项目保住了，但我得承认，那次出于过度测试害得的“假保险”反而成了我们团队最大的教训。
再后来，我也不能也不敢为了省那点测试人力，去给核心流程套一层又一层的测试层。质量不是越细越好，得是精准，不是堆砌。 说到沟通，我认定最难的还是如何跟用户说质量。
那会儿总张嘴就说“我们需求更严谨一点，细节拍板成败”，用户一听就烦，心想你们是不是又要改需求。
后来我发现，用户要的是“好用”和“好办”，不是“零毛病”。
故此作为质量负责人，我不该只盯着 Bug 说“不中”，我应当盯着“体验”说“更好”。
比如上次大促，需求方说手机端要快，我反而建议把后台功能砍掉，主打一个“极简”。结局用户认定我们懂技术，懂用户，反而认定我们靠谱。
这就是质量负责人的角色，别让人家认定你是来挑刺的，你是来帮他们省费事的。 管理上，最难的是平衡。工期紧、需求杂、人手少，这时候质量负责人就是那个定海神针。
有时候老板为了赶进度，想直接甩锅给质量部门，“你们把关不严，目前都出事了”。
这时候我得反过来怼回去，但不是情绪化地吵架，而是拿出数据讲话。
比方说，要是提前压缩 30% 的测试工夫，会出现多少个无法预测的并发场景？要是强行上线，风险成本是多少？我不仅要讲风险，还要给方案。
比如建议采用灰度发布，小流量先跑，跑通后再全量，这样风险可控，体验也能在线。
有时候我就连得跟老板吵一架，告诉他：“你们想把项目做快，但老百姓的保险底线不能崩。目前崩了，赶明儿如何谈质量？”这种硬气，有时候比讲道理管用。 自然，做质量负责人也是一把双刃剑。你忒强硬，项目好办崩；你忒软弱，项目肯定完蛋。
这就是为啥我不喜爱用“起初、其次”这种套路，出于做事不能等到预备好了再启动。今天项目进人了，我要就是第一个发现那个接口响应慢，哪怕老板在隔壁谈笑风生，我也得把难题点出来，哪怕被骂。我见过忒多人拿着放大镜找缺点，最终发现根本没人想听真话。我就认定，质量负责人得像个“火药桶”，平时不显山露水，关键时刻能炸得全场闭眼。 最终说点实在的，质量不是一锤子买卖。项目终止后，别急着把质量负责人扔给人力资源要么重新启动，他们得跟着业务跑。项目终止后的半年，质量人员得介入，帮团队复盘，帮流程优化。
不然项目一终止，质量就是空的。我见过忒多团队做完项目就解散，东西带走了，坑也留下了。
故此，我常跟团队说，项目终止不代表质量终止，持续改进才是正道。
哪怕项目再大，哪怕资源再大，质量这事儿，一辈子管不到头。 总的来说，当质量负责人，我不做那个只会盖章签字的签字笔，我不做那个只会喊口号的啦啦队。我是要做那个在废墟里捡回价值的人，也是那个能在火线下守住的火种。别告诉我啥“职业素养”，告诉我，我是哪位，我干的是啥，我为啥如此干。就如此点实在话，希望能帮你在那些光鲜亮丽的项目里，守住那碗清汤。