程序员你觉得是业务重要还是技术重要?

程序员你觉得是业务重要还是技术重要?

我年轻时在大厂时,特别羡慕公司的业务架构师。

当时公司的架构师,是分三种的:

  • 业务架构师:搭建业务流程体系,提升公司外部竞争力;
  • 基础架构师:技术基础设施搭建;
  • 数据架构师:数据研究,并汇报给高管的;

我们重点说一下这位业务架构师,就我当时自己接触到的,他做如下一些事情:

  • 从无到有,告知你,得有一个新的业务系统;
  • 专门到各个部门去串,目的是将各个业务系统打通,且用他的方案,用他「抽象」好的方案;
  • 画出纯业务的架构图,流程图,注意,图上是跟技术完全没关系的;

我们具体展开来说一下。

第一条,当大家争论不休的时候,他会提出:搞一个价格系统出来,各个业务部门的系统,从这个系统读取基础价格。

在另外一个会议上,当另外一波人,又开始着吵的时候,他又会说:需要一个「比价系统」。

且他是现场在会议室里,画出整个的业务流程,期间很多人提出各种问题,他也是秒回的,逻辑很清晰。

当时我是佩服的不得了,怎么会有这种人。精通业务,了解行业的业务,抽象能力又好。

他解决的问题,都不是个人问题,小问题,而是解决一大波人的问题。且给出了解决方案。

当时,我就觉得,这种人的贡献,确实比纯粹的技术人员要大的多。

果然价格系统和比价系统上线后,业务上,通畅了很多,极大的提高了各个部门的业务流程的执行效率。

我当时一度觉得,整个互联网电商所有的核心系统拓扑图,都在他脑子里了。

第二条:到处走。

这也是业务架构师日常重要的工作,要打通什么业务,需要各个部门协作的,他就会去沟通。

他首先会把整个业务架构流程,告知大家,有问题的,提出来,他会当场给出方案。

注意,还包括技术问题。当时这位虽然是业务架构师,但是技术能力也是很强的。

当时我们的商品系统的数据库表的通用设计方案,就是他出的。一套基于mysql,但是又可以动态扩展字段的,且还支持属性继承和覆盖,期间的递归追溯商品属性,也是他出的。

因此呀,很懂业务,又很懂技术的人,能做大的贡献。这是我的判断。

也是一个,能得到高管重视和依赖的人物。

至于第三条,其实就是熟悉业务,并抽象出最核心的图出来。他画的图,不复杂,跟我之前看到的超多元素,超过连线的不一样。

他那种是结构图,简单清晰,又容易看懂。

真是牛,你只有真正深懂业务了,把那些不重要的都去掉后,才能画成他那样的图。

很多人做不到的,我现在都还做不到的。

小结

我个人认为,懂业务肯定是更重要的,但是,这里有一个大前提,就是是真的比较懂。

方能做出更大的贡献。

当然你作为技术人员,很懂业务又很懂技术,那挺吃香的,尤其是,你还是一直在同一个行业里。