关于交付过程中解决问题的一些思考

在客户现场遇到紧急的问题，通常这类问题客户都没办法立即处理，提交到交付同学这边后，交付同学一般会赶紧的找到开发同学，临时打了一个包，或者自己现场编写脚本，在半个小时到两个小时内处理这类问题。这其中根本没有所谓的流程规范，有的就是快速沟通、1v1快速处理，在最短的时间内处理掉客户的问题，这是我之前的做法；现在出现问题后，先收集问题表像，在深入到里面，查日志，查报错信息，手机完成后，在内部的工单系统进行提交，同事会对问题进行确认，确认后提交开发同学修改，修改后跟随版本迭代发版，再由交付人员给客户现场升级，验证后，关闭工单，同步客户已的问题。

两种处理方式在效率上会在实际的工作中体现的比你想象的更大，1v1可能只需要两个小时，但是通过走流程，这个1v1可能变成了一周，两周，甚至一个月，才能解决这个问题，这种落差让我很难受。晚上我就在想，这个东西是不是真的需要流程规范吗？我提出了质疑。处理这个问题的人，从头到尾，始终是我和开发同学或者运维同学在实际操作，加上这些流程之后，流转的效率从两个人，扩展到了两个人+一个团队。效率下降是必然的。就算走了流程，其实解决问题的还是这两个人，也就不存在说，如果多个解决方案的人去询问开发同学，他们忙不过来的情况了。

但是和朋友沟通之后，我的质疑被打消了一些，但是还是存在。我把我的疑问和朋友说之后，朋友给我分析了一下公司的情况：公司想要做大起来，流程规范是必要的，因为随着公司体量越大，流程和规范就会越重要，会让公司流转更加顺畅；其次流程规范也是一种数据统计，让公司管理层发现问题所在。最后建议，一方面有问题处理的时候，选择效率高去解决问题，另一方面也要按照公司的流程去走。（现在实际的工作中也是这么做的）

之所以说打消了一部分质疑，是因为从流程规范中，发现了问题的跟踪或者说某个环节有问题的根源，然后着手去解决他，这个其实是有价值的，去分析某个环节的问题，或者某个组件的问题，定位到一直发生问题的根源，解决这些问题，减少这些问题的发生，我觉得可以接受这些。另一方面是交付的产品质量，没有达到走流程的基本条件，这种流程加上去会让交付同学承受太多他们不能承受的重~，还吃力不讨好。按照现状，我还是觉得直接处理会好很多。

交付这个岗位，虽然工作时间不长，我也只是一个小测试，从自我感觉来讲，交付真的要关注产品的质量，毕竟，我们的目标是：快速交付高质量的产品。