我们团队在负责公司的仓储系统，目前有一名实施岗位的同事在处理线上问题，他总是忙到不可开交，每天rtx都是一排排消息。但处理了半年以后，我们的线上问题还是很多，每天他还是很忙，问题却完全降不下来。
那如果我们去掉实施呢，质量会不会更好一点？
我仔细回想了我们以前团队的情况，发现以前都是产品经理在处理线上问题，每个人每天可能花30%精力，很影响产品本身的工作。所以，我们引入了实施岗位，线上问题全部由实施对接处理，产品经理基本上不参与。针对仓储系统问题一直比较多的情况，我们抽调了产品经理，开发工程师，实施工程师组成了异常处理小组，耗时三个月集中处理线上问题。
但随着异常逐渐减少，异常处理小组解散了，过了足月有余，异常又开始反弹，实施又忙不过来了。并且由于实施岗位的存在，我发现了一个很有意思的事情，即使新需求上线引起的问题，很多时候也都是实施在跟进解决，他甚至不知道哪个问题是新需求引起的。
讲到这里，大家可能都会发现一个显而易见的问题，那就是团队的质量没有人管了，线上的问题全是实施处理了。产品经理可能不知道自己的需求出了问题，开发，测试都不知道自己的需求出了大bug，还可能因为有实施兜底，因此开发，测试环节都少了一份谨慎，上线代码时更少了一份谨慎。
一个团队的产出质量一定要跟每个人牢牢绑在一起，不管是通过绩效考核来约束，还是通过谁的问题谁来处理来约束。这样才能让每个人都时刻把质量作为一道红线。
那么，如果没有实施，我们线上问题该如何受理呢？
首先，由产品经理对接业务部门提出的问题，如果是咨询类的，直接回复即可。如果是系统bug，转给开发处理。如果是需要定位问题的，由测试介入，初步定位后转给开发。
其次，产品经理只负责分类问题，对接业务，不负责跟进问题，开发能否及时处理也由项目专员来跟进。
再次，模块责任制，产品经理，开发，测试都有自己负责的模块，出问题后相关人员一起解决。
最后，需求责任制，某个需求线上出了问题，产品经理，开发，测试都要承担责任，形成利益共同体，减少解决问题前的互相指责和甩锅问题。
实施，其实是一个畸形的岗位，是我们内部质量不可靠衍生的产物。无论有没有实施，如果我们不尽快推行责任制，线上问题都不会减少。