这周接了一个定制化的开发任务,让我长了不少教训.
本来预估的1人天的事情结果搞了差不过3天才勉强弄完.
这个事情让我不得不反思自己的工作方式和能力.
根据以往经验,正常来说一个定制化的告警邮件发送插件功能一天就能做完并附带调通,最多不超过两天。但是这次这个客户的对接开发工作给了我一次扎扎实实的教训.
首先第一天,同意进行定制开发的流程刚审批完,销售竟然就说客户当天就想要.这个情况是比较少见的,虽然我对于内部人员沟通时都预估的1人天的工作量,但这绝对不是说从开始开发到交付只需要一天的时间,也就是说这个时间进度上,销售是有理解偏差的.我当天跟销售反馈说,做不到当天就完成交付,他却说客户很急,我说既然客户这么急那应该早几天就跟我说本次的定制化开发大概率会实施,并且客户很急,那样我就会提前进入开发中,然后销售竟然又把锅扔给我的一个上级,说他早就跟我领导说过这事了.我对此只能无言以对.
客户为上,我只能尽量加急开发,因为我的经验告诉我,一天时间应该能搞定,可是没曾想,由于客户给的文档里没有提到接口有权限认证,并且这个认证方式需要用到客户的sdk,而这个sdk也是之前客户给的文档里没有提到的,所以我一开始的代码写的就偏差比较大,所以第一天没能完成.
然后第二天,客户补充了认证的方式,我几乎是重新开发,结果开发完后调试时又发现客户给的文档还是有不完整的地方,中途反复改过代码不下两次,然后接口通了,我的接口调用能收到响应结果为成功了,但是最重要的一点,邮件没收到,这种情况就需要客户那边定位问题了,但由于时间已经很晚了,客户没有回复,于是第二天也没能完成.
第三天,客户给出最后一个文档没有的细节补充,然后终于能收到邮件了,但是竟然还是有一些问题,邮件内容存在中文乱码情况,根据我这边服务打印的日志里记录的报文,是能正常显示出接口调用发送的数据是正常的,并且很诡异的是,两个字段我都是完全一样的处理方式,可结果是一个字段乱码而另一个字段正常,这不得不让我怀疑是客户给的sdk的问题或者是客户那边的服务器的处理逻辑问题,同时,客户取出我日志里记录的报文去调用同样的报文却能收到正常的邮件,这便又是一个无法解释的现象,似乎问题是我这边代码的问题,之后我反复排查也没能定位到原因是哪个环节的,百思不得其解.
最后,客户那边传来消息,说他们自己又通过什么其他方式搞定了,可以收到正常的邮件了.并且这个消息还是销售告诉我的,在我和客户所在的群里,客户根本没说这事.这就太让我好奇了,我不禁要想是否是客户定位到了是他们的问题,不愿意直说,因为这么短的时间内,他们不可能单独开发一整套的逻辑去完成这个事,最可能的情况是他们基于我推送的数据做了简单的发送处理,或者干脆就是修复了他们服务器的一个可能导致乱码的bug.
最后销售也只是淡淡给我留言说,"我刚和客户沟通了，目前能收到邮件，乱码的问题他们也会去查原因。辛苦了".
这就是本次事件整个的经过.过程中我也是压力山大,因为销售从一开始就在对我传达客户很急的意思,并表示客户一直在催他,甚至骂人.
现在来看,还好最后这个事情算是完成了,因为客户那边领导层的目的达成了,完成了对他们各个生产数据库的监控报警.否则我现在不要说在这里写文章总结,可能因为这个事情影响到绩效甚至更严重的后果都有可能.
所以,无论这个事情过程中谁是谁非,谁的责任更大,我都应该吸取教训,一定不能再让这样的事情再次发生.
1.预估工作量时需要更谨慎和仔细些,确认清楚客户的对接开发是否需要用到指定的sdk.
2.了解客户想要完成的deadline,一次都不能忘记,我唯一忘记的这次就给我埋了坑.
3.对销售说工作量时,要强调实际的完成时间和工作量之前的区别,避免误解,因为他不知道我手上的其他工作的紧急程度.
4.跟客户强调一定要提前通知我开发,给出足够的缓冲.这样我才能做到让问题提前暴露出来.
总的来说,定制化对接开发工作由于大部分客户都无法提供测试环境,一个接口又可能涉及到两三个系统间的交互,问题定位链条较长,并且联调又是和客户的开发人员进行的远程协作,这就造成了各种预想不到的情况很多,且沟通效率很低,整体进度不容易把控,我需要尽可能提前预研和发现问题,以求在客户计划的deadline之前完成交付.
网友评论