解决问题的方式

Overview

1月份还是继续施工,不同的是,能不能安然回家过年就看这个月的进度,这篇博客也是写了开头,断断续续,1月开稿,2月才完工,依旧是麻烦多多的一个月。

最初讨论设备电池续航和安装问题时,和几位领导同事们一起讨论了漫长的时间也毫无结果,因为没有一个人完整地了解设备的情况与现场情况,在各自假设的场景下表达着自己的意见,僵持不下,最后我们的项目运营经理说了一句话:“到现场解决问题”。因为负责项目施工的是他,如果有人继续冒出各种不切实际的想法,比如“试一试这么解决下行不行”,一般只会增加更多的麻烦。

DevOps的理念中让程序员,也就是开发者参与运维,而从去年开始的项目,则是让开发者介入了施工(Construction),所以这里可以发明一个新词了:DevCons,理念是让软硬件开发人员介入现场施工中,获取第一手的现场资料,现场解决遇到的新问题,减少后期埋坑和多脸懵逼找原因的尴尬情况,但也有可能出现上面那样的情况,了解了实际情况后开始出现反效果,大多数人是不会允许bug长久地存在,看到了就需要解决,而现场的麻烦总是毫无征兆地出现,接连不断,结果就是进入僵持不下的状态。

很多线上人员认为可以顺手解决的问题并不容易解决,而现场作业人员迫切的需求又很难得到快速处理。一次是在施工和测试最忙的时刻,驻扎在办公室里的同事寄过来几套未成型的设备,要求现场立刻部署并派人测试;另一次则是和我一起的项目运营经理提出在施工用的App里追加一个城市选择,需求几经辗转,还是回到了我这边。在白天施工结束后,花了一个多小时,设计页面,测试接口,直接给运营经理编译了一个新版的App。类似的问题出现过不止一次,好像已经成了常态,如果能得到快速解决,矛盾就会化解,如果因为一些缘故拖延,很容易演变成争执,其实还是沟通不顺畅的问题,也许是消息传递的层次太多,也许是参与其中的无关人士太多,总之容易造成混乱。

卷入麻烦多了,大概也有了一点解决思路:

(1)压住问题;

(2)找到直接引起麻烦的人,或者能够直接解决麻烦的人;

(3)第二步无法解决时,将问题完全暴露出来;

(4)问题暴露后,让领导去寻找对方处理问题;

(5)第四步无法解决时,让领导去寻找对方领导处理问题;

(6)第五步仍旧无法解决时,那就寻求更多人的力量吧。

一般情况下,都可以在第二步就解决问题,而第一步要做的,就是不要害怕。