多少人给你解释的机会

Posted 2020-08-16

这两个星期是够忙的，十月中旬在老大面前一口承下24号完成任务，当时有个工作十几年的同事就在旁边提醒，不要太着急，还是到月底吧，最后折中的方案就是争取24号，最迟30号，幸好留了个回旋的余地。

当时的任务就是在原生中开发h5，心大的我以为全部按照现代浏览器的标准去开发就行了，但实际问题很多，pc上面什么都对，到了app里面可就是另外一回事了。最大的几个问题如下，安卓4.4以下布局乱了，某些样式不支持导致的，比如fixed布局；比如安卓不能触发input type=file的弹框；比如ios中虚拟键盘会挡住输入框；还比如电脑上能发图，手机上就不知道图发到哪里去了，电脑上能压缩，手机上就失败，等等，还有很多接口需要原生配合来实现，有时候问题一出来，就表现在界面上，不管是不是前端的问题，别人先找前端问，这又得去帮忙追溯问题。所以，看似很简单的一个东西，加上这些问题，就没有那么简单了。

十多天的开发时间中，还有很多时间是在沟通，各个部门的人不在一起。特别是最后几天，内部测试的时候问题不断，简直是一波未平一波又起，不断的被问“现在怎么样了”，“还有哪些问题”。或者是“这个功能为什么是这样，不是这样xxx”。或者严重一点就是，“你现在这么多问题，我怎么给你提测”。不断的bug和问题还有需求变更来袭的时候，还要沟通确认，这个时候写代码的效率和健壮性是很有影响的，我只得一个一个先记下来，解决一个划掉一个。前天老大和项目经理居然来了(我们分别在两个地方办公)，加上技术经理三个人坐在我后面，前端组就2个人开发，刚开始还有点正襟危坐，但后面气氛就好多了，老大和项目经理马上投入进来，帮忙想办法解决问题，十张传输有问题，先做一张的。键盘按钮切换繁琐，就改变下ui设计。有其他项目组做过类似的功能的直接拉人过来问，甚至直接看代码，帮忙理清逻辑。从没有一句话类似于“你这个为什么还没好？”或者“你的bug这么多怎么用”之类的话。有人打趣老大是来视察，老大忙解释说，“不是，不是，就来看看，学习学习”。虽然当天几个重要的问题最后也没有解决，但让我心态大好。前天改掉ui之后10点了。说实话我没有时间去分析问题的原因是什么。

到昨天，再来人打断我之前我先去找别人，大问题一个一个都解决了，安卓发图不成功是因为原生返回url被解码了，文件服务器不认。ios发不了大图是nginx服务器限制了，却没有触发fail回调，导致界面上得不到响应。键盘的问题，是项目经理帮我问到了代码，但是昨天发现自己把一个大写字母写成了小写。周五下午还是提测了，虽然测试人员报了一些bug，但我已经没有多少担心了。回头看看那些看似很难搞的问题，其实原因可能很简单。如果像个无头苍蝇一样，只会劳而无功。

再回头看这个事情，从时间预估到开发到测试。一开始我就预估错误，单纯只是从技术角度去看这个问题，认为就是做几个功能而已，但忽略掉了这件事情是需要几个部门协调完成的，需要处理pc，ios和安卓三个端。编码的时间可能只占到了一半，沟通和调试花费更多的时间；

另外一个开发不够专注，前几天的开发过程中我其实左右开弓了，一边和原生沟通，一边写另外的功能，中途还需要和同事协调，在手机上测试。特别是问题一个一个来的时候，不能这个搞搞那个搞搞，结果什么都没处理好。欲速则不达。正确的处理顺序是，先一个一个确保核心功能没有问题，比如发文字，发图。其次是重要流程上的问题，比如应该1然后2。再处理相互体验上的问题。在开发的过程中，我们都会遇到这样的情况，比如说，我调用了同事的接口，我发现了他返回的值是有问题的，但是可能因为我还忙其他的事情，也没有来得及跟他说，最后就没有管了，但这个bug报上来，首先还是会记在你的头上。所以，遇到这样的问题，你应该马上说，一次性做好，不要心想反正我的代码没有问题，到时候报上来了再说吧，报上来的结果就是先算你头上。

最后要说的是沟通：沟通分三种，和别的部门的同事沟通，和自己同事沟通，和领导沟通（和下属沟通呢？不好意思，这个我不能瞎分享）。和别的部门的同事沟通，往往是要他们帮忙协助做一些事情，一定要在群里拉上他们的leader或者负责人，因为这样一个是让他们的领导知晓这件事情，知道他们的员工在做事情，另外一个这样他们也会及时响应你。如果公司文化喜欢发邮件那就是得抄送领导。在群里人多，记得要@到相应的人，不然你丢个问题出去，没有人理你。最后就是帮完忙记得说谢谢；和自己同事沟通，是很要注意的，说的直接一些，你们是有竞争关系的，一个问题往往牵连到很多人，程序员有个毛病总是会先去怀疑别人，认为自己的代码没有问题。或者只从技术的角度去看，没从业务的角度去看，认定这个就是这样的，我不会改。如果你说他的代码有问题，他可能跟你急。所以用词一定要恰当，甚至于比找别的部门的人还要客气点。当然会有很nice的程序员，这个就是要注意下。其实比起在软件上聊，可以跑过去问的就跑过去问，涉及人多的就干脆开个会，这样效率更高。聊天软件上更适合扯皮和扯淡，一言不合还留下证据了（来啊，相互伤害啊...）；还要注意的是有问题不要表现就是这个问题不关我的事，这是最忌讳的。

和领导沟通，有的听你解释，有的不听解释，除了完成许下的承诺，整个过程中要提供透明度，不能有问题不报，因为软件有bug这个很正常，报上去是因为领导有他的经验、资源和见识，可能会给你提供有力的支持。当然，像我这样，老大都来前线了，自然是前面的工作没有做好。所以把事情做好，不但是说自己的代码没有问题，而是确保产品没有问题，不要等到你需要向leader解释的时候。

bb这么多，让大家见笑了。欢迎拍砖。