业务开发角色分哪几种

在一个业务团队中，有哪些开发角色，每个角色的体验是什么样的，你是属于哪个角色，每个角色相互之间是如何认为的呢。

在一个成熟且较大的业务团队中经常会人为的划分如图的几个开发角色，先不着急说这样划分是否合理，实际上这样的团队分工非常常见，这也是我所在团队原有的组织形态。

每个角色都在诉说的自己苦楚，说自己的活是多么的无聊。

这里看下几个角色分别是怎么划分的，具体参考 CRM 领域语言，从底到上：

• 中间件开发 | 通用技术开发：一般情况下业务团队不会直接进行中间件开发，一般有公司特有的中间件团队承担，小公司团队估计会自己撸的

• 业务基础工具开发：以我观察到的，这个组或者成员一般开发的内容为各类业务工具性产品，比如自己开发报表引擎，云呼，审计，IM，组织架构，权限，工单等等，主要是结合业务开发的属于通用类的工具，一般又没有业务属性

• 业务基础领域开发：这个组或成员已经涉及到业务了，但是研发的重点在业务基础领域，比如标签系统，客户、商机、联系人、拜访、代办、服务、客满等等基础模型的服务。有的时候看起来这个团队就是干 CRUD 的，那估计是没有理解什么是服务化。

• 业务中台开发：这是个神奇的设定，以前这个组织不存在，现在很流行，到处宣传的风风火火，但是我认为这个组织的存在形式大于实际用途，只会降低效率，要么你是阿里，要么你就别搞什么中台。业务中台的逻辑下次再写个文章单独说说我看到的故事。在我们以前这个团队中，中台的存在就是业务开发，只是把服务化的接口包一层业务，称之为通用的业务逻辑，再给最上面的业务开发，实际上有点鸡肋。不懂业务不行，开发的都是各种业务又和另一个团队几乎重叠，增加了团队间的很多协作成本。本来一个人干完的活，需要三四个人一起才能说清楚。实际上只要服务化做的好就可以了。

• 前端业务开发：这个是专门写各种业务逻辑组合的，实际上因为他们最懂业务，所以基本上中台的活、基础领域的活都会去开发一部分，没办法，人家提供的玩意不好用啊。这个角色也是觉得自己价值成就最低的角色，为啥呢，好像就是时时刻刻根据业务逻辑编排接口，底层服务人家写好了，这个角色写写组装组合就好了，时间久了总会角色自己的抽象、架构、技术能力都没有进步。

你喜欢做哪一种业务开发

当时在团队中做了一个调研问卷，十几二十个人让大家选一下自己喜欢的领域和原因。大部分人都选择了中间件开发和基础工具开发，原因是他们觉得开发这个技术会更牛逼，更容易成长。部分人选择了业务基础领域开发和业务中台开发，原因是他们觉得既能锻炼技术和架构能力，也能懂业务，也非常好。几乎没有人选择想做前端业务开发，因为他们举得就是每天写代码编排别人的代码，繁杂又没有成就感。可惜的是当场的人 90%都是做前端业务开发的。。。

每种开发面临什么样的难题

开发人员喜欢做哪一种开发，肯定是有一定的原因和印象的，这些原因可以总结为一个个标签。

• 中间件开发 | 通用技术开发：这个角色非常关注高性能、高并发，做的东西不愁没人用，一般感觉是很专业很有深度的，符合大多数刚开始入行的技术人员的梦想。

• 业务基础工具开发：如果可以选择，我可能是最喜欢做这个的，写写业务通用、专用工具，比如报表引擎、工流程引擎、IM 系统等等，即没有业务的拖累，又和业务有一些交集；既不那么底层和细分，又在某个领域上有精深的理解。

• 业务基础领域开发：这个领域更讲究业务通用性和模型抽象，比如你开发一个 CRM 系统，客户、商机、联系人这些核心模型如何进行抽象满足业务上多变的诉求，非常考验设计能力。以前我呆过的团队都试图将这个部门进行专有的人设计和维护，但都是失败的，因为要设计出通用的业务模型，势必要非常懂前端的业务逻辑和未来趋势，所以多数情况下这个部分会由前端业务开发专家一起参与共建出来。

• 业务中台开发：这个领域更侧重于业务抽象和流程抽象，他所沉淀出来的东西是通用的商业能力。比如基于淘宝的业务中台，再造一个陶特，此时可不是某一个业务模型通用就够的，是全流程的抽象复用，包括店铺、商品、购物车、下单、交易、履约、物流等多方面的业务流程串联。

• 前端业务开发：这是个感觉上最苦逼的组织。普遍感受是没有什么技术含量、不断堆业务逻辑、跟着业务变化非常快、技术上没有什么沉淀。同时这个组织也是最懂业务的组织，离业务最近、最懂业务策略的变化、业务视野最强。

业务开发在做什么

这里我们只关注前端业务开发的工作，因为大部分人都是在干这个工作。即便你原来是做基础工具的，随着工具的成熟，你要么被优化，要么转岗，要么开始做业务开发，因为只有业务开发是真正创造了业务可感知的价值。那么业务开发在干啥呢？在一个成熟的业务开发团队，他们要干的活基本是如图这样的。。。。这也是先前我们这个团队中不少人的体感，每天在抱怨的问题。在半年年度总结时，你问他感觉这份工作干起来怎么样，有什么问题吗？ 大部分都会若有如无的带上几句：感觉就是每天在翻代码、修修补补，if else 一下。。。

现在的业务开发模式

作为一个业务开发，每天的活主要应该就是根据业务逻辑编排各个依赖方的代码，同时涉及人家不愿意干的边角料，自己 CRUD 一下，最终对返回的结果封装裁剪包装一层返回给前端。所以可以总结业务开发的核心就是：业务逻辑编排和裁剪包装问题是这样个没有技术含量的活，你想怎么做，怎么做出一朵花呢。

理想中的业务开发模式

在我历史的多个团队中，都分别有一些这方面的尝试，有的比较成功，有的比较别扭。总体上确实能解决一些问题，只是看能解决 80% 还是解决 20%。在我理想的开发模式中，业务开发的核心工作：业务逻辑编排和包装应该是配置化的，配置后可被调试、管理、发布、回滚，如图所示：

• 所有通用领域的服务（无论是 dubbo 还是 http）首先应该被验证确实是通用的，有业务沉淀过的，而不仅仅只是 DB 的 CRUD

• 所有的基础组件也应该被抽象为一个个服务，而不是每个人随意写的不统一的各类操作

• 所有的服务都应该被统一做元数据的管理，注册为业务开发所需要的 function

• 业务开发要做的事情是要最这些原子化的服务进行流程流程编排或服务编排，编排结果直接给到前端即可。

所以在前端业务和通用领域之间需要有一个 业务开发引擎层，这个层次负责所有业务的编排。

简化一下如图示，这一层的核心目的不是玩，确实是为了解决一些问题：

• 开发模式上快速适应多变的业务场景

• 技术上告别低质量的 CRUD，把大量的时间花在如何沉淀更可被复用的底层业务服务。

• 提升技术人的工作体验和成就感

业务开发编排引擎

下图是以前做过的一个业务服务编排引擎的技术实现，具体的模块可以分为：

1. 元数据中心：负责所有服务的注册和管理

2. 服务框架：负责则所有编排逻辑的执行和优化策略

3. admin console：是开发人员的可视化开发界面，可以边调边写，甚至可以做到服务即文档。

图中写到了一些可以用来编排的脚本语言，以及涉及到非常细节的东西，但是实际上这只是一种思想，你可以用自己喜欢任何方式达到这个目的。

比如如下图的 graphql，他完全可以做到这一点，可以基于 graphql 实现你要的业务编排引擎。当然你可能需要对它的开源代码进行一些定制化。

业务开发应该有自己的价值观

在一个团队中，总有人在做一些看起来高大上的工作，也有一些人在做脏活累活。那么业务开发很多时候就是那个看起来的脏活累活，但是我想说的是业务开发可能也是最有价值的团队。这里举个例子：2022 年很多互联网大厂都优化了，看一下一般小厂中优化的是哪些人吧。在我们公司中，所有的技术中间件，基础工具，技术中台、业务中台的人技术几乎裁光了，没裁掉的也全部合并到业务团队去了。在一个业务团队中，留下的也就是几个最懂业务的开发，那些做通用领域的也不需要了。所以，是不是觉得竞争力高了那么一点点。

业务开发即能接触到一些核心技术，从而拓宽自己的技术视野和深度，同时也是最接近业务的人，能快速的拓宽自己的业务视野。做为一个业务技术，通过上述业务的抽象编排，既能锻炼自己的技术能力，业务抽象能力，还能够满足公司的需要，快速适应公司业务变化诉求。所以这么想一想是不是觉得业务开发也很考验功力，并不是大家一直理解的只会 CRUD。

下一次可以介绍下这个业务编排引擎怎么做。