听老板的还是听业务的

原创
2021/07/07 22:42
阅读数 70

前几年公司为了吸引客户,提供了API给外面客户来查询海运订单的货物动态。在船运业里,几乎每个大的船公司的在线系统里头都有公开的用来查询货物动态的服务,不需要登陆。只要你有订单号码,不管是哪个客户的,你都可以用来查询其动态。公司的API提供的服务也是如此。但是,这两年由于疫情缘故,船运业务一路高歌,一柜难求,业务量暴增。集团的船运业务订单量也是非常客观。由于货多船少,再加上很多港口延期,客户不容易得到其货物最新动态,自然地,在线查询业务访问量也是暴增,同时,第三方平台也采用爬虫策略来获取其平台订单需要的数据。如此一来,API便出现了性能瓶颈。虽然有配额,但是还是顶不住客户的无效访问。故此,相关业务部门便提出,对于使用API来查询货物动态的客户,其必须是该订单的相关货主,而不可以随便看所有订单。

这个需求看起来确实不难,而且在开发之前,搞业务的同事还特意在聊天大群里头分享了真实业务是什么样子的,期望做到的是什么样子的,可以说说得很清楚了,当时也没人质疑。简单来说,系统需要配置和维护一套关联表,该表存储了API客户与系统注册的客户的关联,当API客户调用API的时候,需要对其传入的订单号码相关联的货主与上述关联表进行对比,如果任何货主都与API客户没有关联,那么,该订单的动态信息就不可以返回给该API客户。可以说是基于之前API的业务逻辑,多加一层过滤条件而已。 当开发同事准备开发的时候,我也与该开发组的TL讨论了具体的实现方案。说实话,如果了解了需求和相关业务之后,写代码的时间真的不需要多长时间,厉害的同事半天都搞得定。

经过了半个月的开发,今天开发TL在群里说已经上线,准备将实现逻辑和实施步骤分享给业务部门,准备开始推广。当我看到这个新的API的时候,立刻觉得有问题,完全不符合业务部门的要求;接着我拉下最新代码找到了实现的地方,果不其然,与讨论的具体实现方案是完全不一样的;向业务部门求证,说这个方案绝对有问题,完全不符合真实业务,不会去推广的;最后私底下问实现该方案的开发,TA说是老板定的实现方案。我翻了翻历史聊天,果真,开发部门老板自己定了方案。实现的效果就是,API客户一定是订单上的某一货主,不然不能够获得货物动态。但是,这个假设完全是不正确的。

说实话,这个业务场景对于了解海运业务或者摸索了公司系统多年的同事而言是非常常见的,有能力通过API获取数据的公司,要么自己本身是个很大的货主(发货方或收货方或货代),其订单上肯定有一家货主是它自己;但还有不少的第三方平台,它们不是订单上的货主,但是真正的货主却又和该平台有生意来往,想通过该平台来获取货物动态。基于这个基本知识,再加上我们系统其他功能模块,可以说是非常容易实现的,至少设计的时候也要考虑到的。结果呢,因为老板说了要这么实现,就完全不顾真实业务场景了。老板优先。

这个方案在群里分享后,业务部门的同事立刻又写了一封邮件,再次重申了为什么这个方案有问题,期望的是什么。然后又来一次电话会议,就这个业务讨论了很久,一会儿站在技术角度,一会儿又站在业务角度,PDM/老板等时不时抢话说。我就做个吃瓜群众。就如前面所言,业务的需求和邮件说得清清楚楚,现实业务到底什么样子的。而且会上的老板和PDM,对这个系统也是很了解的,怎么就往复杂里整呢。吵了半个多小时,还是勉强接受了业务的要求。

讨论完后开发TL和老板又拉上我讨论代码的问题了。我也是醉了。为什么呢,几位看着代码来讨论该怎么实现,讨论着讨论着,发现有问题,就在讨论业务方到底有几种可能性,如何在代码里头实现这几种可能性。说白了,业务上还是有一些不是很清楚的地方,但从整体来看,并不影响实现,只不过是过滤条件的强与弱的问题,再者,到底哪个可能性才更加符合这次业务的需求,拉上业务方一块讨论就可以的。非得几位码农挂着电话瞎几把扯一个小时,最后还不得问业务。唉。更奇葩的是,给业务方提建议的时候,把觉得比较复杂的可能不需要的业务省略掉不提,等业务方自己提后再说。业务方对整个业务都熟悉得很,为啥不把几种可能性都提出来,让业务方更清楚,让这个需求更早确定呢。

其实,不单单是这次小改动,还有很多类似的应用或者改进,都是听老板听PDM的,而不考虑现实业务场景的。所谓Customer Focus,实际上在公司更多是Boss Focus.怪不得做出来的很多产品,根本没有多少客户买单。而那些真正冲在第一线获取客户痛点的PDM提出来的业务,才更容易落地。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部