在XBO最后一周的心态转变历程

本周:

  1. 完成了权限管理的技术栈迁工作
  2. 持续阅读《The Effective Executive》
  3. 意识到要交付线上可用的功能,为此许下承诺并负责到底
  4. 心态上,完成从“道不同,不相为谋”,到“把对方当用户,为之提供有效服务”的转变

承诺的压力

权限管理的重构与协同设置功能有所相关,我放在一起做了。按照最开始的规划,周二是能上线的。但到了周一,才注意到当初有疏忽的点,协同设置的修改,影响到移动端的客服显示了。当晚召集小伙伴,重新分析一波,确认周二能把相关改动做好。

周二那天感受到了,我感受到了时间的压力。

当天上午的时候,用户管理还没有完全重构好,但接口已经调通了。考虑到还要在几个环境去测试,还要跟移动端联调,我产生了“先保证功能可用,后面再重构”的想法。

这里主要是这样考虑的:上周我信誓旦旦,说这周二能搞定; 如果周二搞不定,那就是打脸了。虽说这个功能并非很重要,这并不影响MOBY的下单,但这是我的承诺,没有做到,损失的是我的信誉。不能按时完成任务,降低的是我的可信度。所以我周二那天有着“必须搞定”的念头。

但同时,我又觉得,这些丑陋的代码不经过整理就上线了,我的内心无法忍受。但如果继续重构,会增加调试时间,可能今天赶不上上线。

我很矛盾,导致有些心神不宁,明显感到状态不如上周专心致志。

尤其是到了午餐时间,我还想再写一个小时,不想中断编码节奏,但肚子又饿得慌。我知道,如果我继续写,1点多的时候叫个外卖,中午就不休息了,那我前一个小时的质量能得以保证,但下午就崩溃了; 而如果我去吃饭,刚吃完了必须休息一会儿,所以现在的编码状态一定会被打断,得一个多小时会才能恢复,但下午的质量能得以保证。

犹豫在三,我选择了先去吃饭。“越是有压力的时候,越要保持正常作息”。

吃完了在酒店里,根本睡不着,于是起身去公办室。我隐约觉得这个状态下,接下来很可能会写bug。

于是我准备像压力妥协,我说,“先把功能上线吧,代码质量后面再说了”。

结果一联调,发现仍有考虑不周全的地方,后端客服查询接口需要增加过滤参数; 预约逻辑也要改,不然影响到下单,无法走流程!

查询接口增加参数在可控范围内,但预约失败却是始料不及的。预约功能非常关键,但之前梳理逻辑的时候,居然没考虑到这一点,必须要指出,这里我的失误非常严重。

怎么办?我当即做了以下调整:

  1. 首先,接受周二无法上线的事实
  2. 接着,找到开发预约功能的火柴哥,重新梳理一波逻辑,确定明天能搞定
  3. 找到余经理,告诉他由于之前考虑不周,影响到预约功能了,需要明天才能上线
  4. 重新调整心态,继续进行用户管理的重构,不降低代码质量。

第3点的秘诀是:调整对方预期,许下新的承诺。这里的关键点是,自己主动找人,而不是等到别人来找你,二者有天壤之别。让别人来找你,然后你才告诉对方这事不能按时完成,你就留下不靠谱的印象了。

第4点是《The clean Coder》里提到的,“越是紧要关头,越是要冷静。战胜压力靠的是你平时遵守的纪律”,“如果你笃行重构,此时要更多地重构”。这标志着我心态转变:从理论到实践,对该价值观的真正确认。

事实证明,越是时间紧急,越不能想着赶工。因为总有意料之外的事情:到了周三,一切准备就绪了,却发现,原来权限管理本身就有bug,这在旧版本的权限管理就存在的,只是一直没暴露出来,结果又花了好些时间修复。

所以前人说的不错,唯有按部就班,保持井然有序,才是致胜的秘诀。

无法上线的功能价值为零

周二晚上新的权限管理在测试环境可见的时候,我通知了陈总,跟他说即将上线新的权限管理,用户体验更佳。陈总觉得不错,跟我说“谢谢”,还问我啥时上到生产。我说,等测试完功能没问题就上线。

到了周三在测试环境通过测试时,发现分支管理很不合理,想上个线,给feature分支的开发者带来很大负担:分支开发者本地合并主干代码,解决冲突后,再提交到主干,而在那之后feature分支的代码就被污染了; 想该功能单独上线,需要重uat切个分支出来,再cherry-pick feature分支相关的提交记录。

这里的关键,我的分支,一共有70+个提交,我得cherry-pick这么多提交,之前合并主干遇到冲突, 很多会再遇到一次,得再一次手工解决。

我开玩笑说,这特么上个线比上炕费劲多了。

我找到余经理,跟他说,我这么多提交去cherry-pick,很有可能会失误,得想个办法。余经理说,那就不急着上线呗,你的功能先放一放,到时跟其他功能一起从测试环境同步过去。

当时我就想,那好,既然你不着急上线,那我也不着急了。反正我该做的已经做了,剩下的就交给你了,这功能上不了线也怪不了我。

我顿时觉得心理轻松了许多。

但后来我突然想起到了陈总昨天的那句“谢谢”。陈总是感受到了我们想把事情做好,不断完善,提供更佳的用户体验的态度而道谢的。如果我把负责推到余经理身上,认为我只管开发,不管上线,那我是在开空头支票,这不是专业人员应有的态度。而且,从成果产出的角度讲,功能没上线,没有被真正的用户使用到,那么成果产出为零,该功能的价值为零。

把这层想明白,我就着手合并代码,开始了我的cherry-pick之旅。我花了一个上午合并代码,解决冲突,然后再写了份cherry-pick操作步骤。下午再找到相关开发人员,帮他们cherry-pick一波。大半个下午过去了,代码才准备就绪,上了uat。

最终,经过一番细致而繁琐的操作,新的权限管理上线了, 我也总算没食言。

把对方当用户的意识

周六做交接的那天,跟我交接权限管理的同学已经谈妥一切,旁边在打王者的SH突然拽了吧唧地来了一句,“你不能走,权限管理只做了门店端的,总部端的你没做,你要做完了才能走”!

这里我脑子里转过无数念头:

  1. 我特么周日的机票,你能留得住我?
  2. 跟我交接的DC与我言谈甚欢,又不是你来交接,你管个毛线?
  3. 本来重构是你们的工作,我接手了,是减轻了你们的工作量,你还不知足?
  4. 你那代码写得跟什么一样,一派业余,我把你代码重头以尾改了一遍,你特么不好好学学怎么写代码,有资格在这儿叫板?

也许他也是开玩笑的,但他的语气当时让我我很不爽,所以我在各种可以作出的回应中,我选择了直接怼。我告诉他,“你们开始做的时候,就是门店端的权限管理,所以我完成的就是门店端的。 我当初是主动提出接手做,你不能说因为我做了门店端的,就必须把总部端的也做了,懂吗”!我教育了他一波,让他懂点分寸,别贪得无厌,不知好歹。

其实在XBO我怼过不止一个人了,这样说来,好像我还挺嚣张的: 在别人的地盘,怼别人。

这个跟性格有关,也跟价值观有关。被我怼的人,做事的态度我根本看不上, 如果是组建团队,这些人第一时间就会淘汰出局; 正所谓“道不同,不想为谋”,哪儿凉快哪儿呆去呗。

所以这件事本身而言,只是个小插曲,无关痛痒。可是后来,我想到一个画面,XBO的一群前端围着我们的前端,认真地听讲,了解项目结构的样子。我突然想,是不是有种更高的境界,可以海纳百川,让这些我原本看不上的人,也为我所用?

瞬间,我转换了思路。我们是否有共同的利益点,我是否有需要他的地方? 结合《The Effective Executive》,“为外界提供有效的服务”,电光火石之间,我想通了:我可以把他转化为我们组件的用户。所以对于用户,我不会去看他的缺点,而会去倾听他的需求,为他提供服务。

豁然开朗,我似乎打开了通住新世界的大门。

以上,是这周全部心态转变的历程。

Fork me on GitHub