昨天我拒绝了两个小改动

August 29, 2018

技术管理

这是一件很简单的小事情,但是我还是想记录一下,因为这两天上下班路上,我进行了很多的思考。

事情发生在一个业务项目中。最近有比较大的版本变动,业务工作量突然增大,于是我也承担了几个业务项目的开发。其中 A 项目已经进入了集成测试期了,这个项目在昨天晚上上线的。B 项目正在测试期中,C 项目正在开发联调中,还没有提测。其中 A 项目本来就比较坎坷,一开始评估的时候,没有评估客户端的工作量,后来发现需要客户端配合,我就临时接手这个项目了,接手的时候,只有 UI 的改动,用不了半天时间就搞定了,结果除了 UI 变动外,还有很多跳转啊,推送啊,断断续续投入了不止两三天的工作量进去。

所以由于这个项目进入开发前的一系列失误,导致后面很被动。特别是客户端,为了保证最后项目可以上线,只能挪用其他项目的时间来填补这个意外的工作量的洞。因为这些跳转啊,推送啊,会影响到具体的业务,我还是忍住了脾气配合完成了。但是到了昨天下午,当天晚上就发包上线了,测试单 Q 我,说有两个 UI 的小改动,问我好改吗,好改的话就改一下。然后被我直接拒绝了。我觉得这是我工作这么长时间来,少有的这样拒绝别人,稍微有点下不去手。

拒绝的原因其实有挺多的。

第一,我手头上有三个项目,我需要在不同的项目来回切换,确实很麻烦。针对我们现在项目的特点,这样的修改,加上找代码,编译,打包,运行,找测试环境,前前后后所有时间加起来,我大概估计这样的修改平均耗时得在一个小时左右。

第二,我平时不做业务项目,这样的修改可能只是一些纯 UI 上的变动,不会出其他问题。但是,万一呢,因为我确实不熟悉这些业务。万一改出个线上 bug 算谁的?本来是来帮忙分担些业务的工作量的,总不能帮倒忙吧~~

第三,提出这两个改动的时候,已经很晚了,集成测试都好几天了,为啥不早点说呢,进集成测试前又不是没有看到这个页面,为啥要在离最后发版的前几个小时来提这样的小改动。不管这是产品提出的,还是测试提出的,我觉得这都不算称职。别的业务方向都回归差不多了,你这个时候再发一个新的包,你让人家怎么办?重新测还是不重新测?重新测就得晚下班,不重新测就要信任你不出幺蛾子,人家凭什么信任你啊。

第四,我觉得我不能做老好人,形成习惯了,他们会变得越来越随意的,什么时候提改动都可以,不着急,只要还没上线就可以。从我个人来说,就是消耗我自己的时间,替别人擦屁股。从我们团队来说,我的小伙伴可能也经常碰见这样的问题,降低的是我们整个团队的效率。每个人需要为自己负责,每个团队也需要为自己团队负责。

所以,我会对我的团队要求,在进入集成期的代码,原则上是需要冻结起来的,制定这样一个小规则,然后去实践这个规则,约束自己,也约束别人。哪怕你手头上只有一个项目,哪怕你很闲,我也希望你把这个时间用在其他地方,不用在这个地方。

当然,这个小规则需要获得认同,当然,我觉得获得认同很容易。我相信的~~

--- EOF ---

添加新评论