有一个朋友的软件产品，我经常使用，也时不时的帮他挑出一些Bug（缺陷）。我对他的一个劝告是出现任何问题都要埋怨开发人员。你会好奇，为什么我会这么建议呢？
现代专业化的过程
其实就是不停分工的过程。我记得以前没有需求人员和测试人员，用户直接对着开发人员讲解需求，我们需要保证软件使用的质量，用户出现任何问题都会找到我们。但现在开发都分前端和后端，测试也开始分什么功能和渗透等等。大规模的协作其实等于更精细的分工，分工其实就是责任的切换。
但这就造成了责任链路的传递，比如开发对产品负责，开发对测试提出的缺陷负责，产品对客户的满意负责，测试对整体的缺陷负责。更有甚者，开发对需求文档负责，对设计文档负责。
你看，任何的需求传递过程，其实不管如何往复，都会回到开发人员的一行行代码上。这着专业分工不可避免，这也就是说对于拥有真正控制权的是开发人员。
我又突然想起另一个事情：
有一个管理办公室的朋友和我聊天说……
大领导一旦发现团队一些行为问题的时候，领导不会骂具体的团队负责人，而是会骂他这个管理办公室的负责人。因为如果直接骂具体的团队，就等于把管理办公室架空了。管理办公室再也无法推行任何的措施。
这也就是说，我们骂谁的话，其实就是强化了这个角色的责任。
回到软件研发上
因为软件在编写和维护的过程上，有太多太多的隐含知识。我们需要让研发的具体人员变得更愿意承担更多责任，而不是一厢情愿的设置更多的流程与环节来保证最终的质量。在拥有责任之后，再从研发人员的视角逐渐扩展整个需求探索和质量保证体系。
我的一位台湾的资深测试朋友和我说过这段话：
测试只是体温计，体温计不能改变体温的事实。
质量不是测试的责任，系统运行也不是运维的责任，需求也不是产品经理的责任。
凭什么你就允许质量有问题的东西上线？凭什么线上资源的占用你不应该思考改善？凭什么看着有问题的需求你可以做下去？
当提交代码的瞬间，我觉得其实是一个承诺的过程，反正我觉得挺神圣的。
所以说，愿意承担更多责任的人值得更多的尊重。
要骂就骂开发。
