0
0

程序员懂业务有多重要?

四火 发表于 2018年07月09日 14:08 | Hits: 355
Tag: Career | 业务

Image result for complex程序员懂业务有多重要?印象中我从来都说,“很重要”这句没有营养的废话。在许多项目中,业务才是真正驱使价值兑现(冠冕堂皇的说法,基本上意思就是“赚钱”)的法宝,而技术实际上有诸多选择,选择某一项并无太大区别。可是,老实说,下意识地,在技术和业务难以两全其美的时候,我还是倾向于选择那些从技术角度更有趣,但是业务上显得没“那么”重要的项目。我不讳认这一点,但是随着这些年的经验积累,或者说经历的项目的洗礼,业务的分量已经越来越大了。

在华为的时候,我做过一些杂七杂八的项目,其中最大的一个项目是一个大型的电信门户网站,由于我参与的是基线版本的研发,定制业务少,变态需求少,扩展性、性能、可维护性这些技术层面的因素考虑更多,因而总体来看,还可以说是一个技术比重明显大过业务的项目。

来到亚马逊,换过几个 team,第一个呆的时间比较长的 team 是 Demand Forecasting(销量预测),由于团队比较成熟,组织结构无论是人员上还是代码上,解耦都做得还可以,因而我更关心的是数据的 ETL 过程、schema、版本、可视化等等这些通用而并不耦合业务逻辑的东西。我们当然有业务方面的需求,但是这个 team 的核心还是在数据上面,大量的机器学习内容,不太可能内建太多的业务逻辑,主要影响销量预测还是数据本身。但是这个团队中,我接触了不少领域知识,这是一个比较大的变化,而这部分和预测算法,以及机器学习相关的领域知识,不同于某些典型的纯业务范畴的领域知识(比如说许多医疗领域、金融领域等等),可以说是技术和业务之间的灰色地带——既有技术的部分,也有业务的部分。

接着是 Contribution Profit 这个组,计算成本和盈利。从架构和系统上和大数据更深入地打交道,却基本上没有了机器学习的内容。主要原因在于,成本和盈利情况的计算,并不,或者说基本上不需要机器学习的技术,主要还是一些复杂的统计量化的方法,包括一大堆逻辑纷繁的公式。所以从业务和技术的角度上看,每天既要从系统上和元数据角度去解决那些大数据计算存储方面的问题,又要深挖业务逻辑,尝试去理解一些数值的缘由。加上我们的工具不足够出色,许多本来应该由数据分析师(Data Analyst)来做的工作,被迫转嫁到了程序员工程师的头上。这个角度看,业务逻辑的比重已经非常大了。当时我们组的同事也可以大致上分成两部分,一部分擅长业务,一部分擅长技术。

现在来到 Oracle,在 Storekeeper 组每天的工作包含了云设备(包括 instance 等等)管理,我最初的理解是,应该说工程师主要的贡献应该是提供不同种类的工具,让 Data Center 的技术人员去使用它们来管理。但是,和上面一条的情况类似,工具不足够好用,加之我们算是一个相对比较年轻的团队,还有很多相对混乱的地方,有大量的业务问题需要工程师介入以后才能解决。比方说某些数据的修改,由于工具的缺乏,这些现场的技术人员只能给工程师开 ticket,然后由工程师去更新数据。毫无疑问,这里存在大量的业务逻辑需要厘清,每当新需求分析的时候,通常比技术层面难度更高的是以沟通和梳理业务为主的部分,去和许许多多不同的用户聊,去现场了解情况,去和不同的 team 谈,从而逐步理清思路,了解问题,给出可行的解决方案。我觉得这些事情在一个足够成熟的团队中,是很难遇到的,即是机遇,亦是挑战,很难一刀切谈好坏。

老实说,曾经业务的东西从打心眼里是远不如技术受到我的重视的,再加上我换了那么多领域,我一直觉得只有技术的东西才是持久的,业务的东西却一直在变。但是这样的观点也在慢慢改变。一个是我留意到,有一些同事能够专注于某一领域(比如说 billing 系统,做了几年,换了几个团队,甚至公司,却一直研究账单系统;再比如和我现在打交道的一位 TPM,在亚马逊、微软干过,现在来到 Oracle,都在云计算的最底层处理涉及硬件和设备的需求,考虑到本来云计算就没多少年,在这一块领域,她可以说是非常罕见的老江湖了),这一旦在进一步职业选择的时候,如果选择到了相同的领域,无疑是在经验上有很大优势的。这也促使我在这一次求职的时候所说,希望在几年后的三十五岁的时候,明确一个大致上希望精进的方向。也许未来的新业务难以预测(比如哪怕就在五年前有谁能知道区块链居然能火成这样?),但是有一个大致熟知的领域为根基去伸展枝叶,会比一直没有清晰的门路强。当然,我不觉得之前的各个业务领域的积累是浪费,毕竟,眼界不只取决于深度,还取决于广度。

程序员工程师,毕竟主要做的是工程,不是研究。和生活更紧密,和实际问题更贴近,因而有大量的非技术问题和知识需要把握。入职以后,今年给自己的一个小目标,就是想提高包括沟通和业务理解在内的软实力,一定程度上也是我的短板。业务本身兴许未来能用到,更多的可能是用不到,但是对于业务和技术两条腿走路的多数程序员来说,瘸了哪一条都显得受限许多。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接《四火的唠叨》

你可能也喜欢看:

  1. 不同团队的困惑
  2. 系统设计的典型分层和涉及的知识点
  3. 研发团队的角色和构成
  4. 从工具使用的痛苦说开去
  5. 谈谈数据绑定

原文链接: http://www.raychase.net/4866

0     0

评价列表(0)