欧雷的周报：2021 年第 20 周

在微信朋友圈看到个网友发了条状态——

我评论了句：「Engineers are problem-solvers. 面向技术本来就有问题。」陶师傅回复我：「如何理解分工会越来越细这句话？」

由于在那之后并没有进行讨论，故在此针对评论来展开说说我的看法。在这里，将讨论的范围局限于软件生产，并且主要是 web 开发——

分工的产生

一般来说，不考虑管理人员，软件生产相关的分工是按照生产流程来的，以下就是按照软件生产流程的上下游关系排序的主要分工：

1. 产品设计——产品经理、交互设计师；
2. 外观设计——UI 设计师；
3. 软件开发——软件工程师；
4. 软件测试——测试工程师；
5. 部署维护——运维工程师。

在不同企业或部门中，根据实际情况，可能会出现同一岗位的人会参与到多个环节中去，如一家企业或部门没有专门的测试工程师和运维工程师，产品经理、交互设计师和 UI 设计师会去兼做软件测试相关工作，而软件工程师就去做些部署维护的活儿；也可能会在某个环节中细化出更多的岗位，如软件开发这个环节细分出架构师、前端工程师、后端工程师等。

那么，由特定工具或场景所催生的岗位，如 Java 工程师、Go 工程师、微信小程序工程师、H5 工程师等算不算是分工细化呢？我认为不算——这类岗位受企业业务等变化影响太大，易变性高，随时随地会消失。

影响自己所处岗位稳定性的是解决自己所处环节的问题的能力，而不是自己所用所熟悉的工具是什么。假如你是通过「Java 工程师」的身份进的某个企业，某天该企业决定将 Java 全部替换成 Go，你是主动辞职或者等着被辞退，还是学习 Go？

分工细化的前提是流程环节比较复杂，并且因操作规范化程度不够或其他什么原因导致不能自动化，无法用机器取代人工，因而要拆分出子环节并找到对应的人去处理。

分工的变化

以我短浅的目光看来，至少近五年主流的分工形式不会有什么变化。但随着低代码开发平台的成熟，分工必然会发生变化。

现在的软件生产，几乎还是由一家企业或部门一条龙地从最基本的单元做起（忽略开源工具），逐渐变成完整的软件产品。若低代码开发平台比较成熟了，那些面向业务的企业完全可以在采购低代码开发平台后裁减大量原本用来开发、维护系统的人员，只留下不几个基于低代码开发平台配置或开发满足业务需求的功能的人员即可。

这种情况下，面向业务的企业就像那些传统企业一样，人员构成绝大部分是解决业务问题或维持公司正常运转的，只有一个由少数人员组成的 IT 部门负责系统功能的开发和维护，不需要很高的技术能力。

这样一来，做低代码开发平台的企业就成了面向业务的企业的供应商，那些做 UI 组件或其他基础设施的面向技术的企业又是做低代码开发平台的企业的供应商。

以低代码开发平台的成熟并崛起为契机，产业结构和企业员工构成会发生变化——从产业层面来说，完善了从原材料到可销售成品的生产链，分工变细了；从企业员工构成来看，面向技术的企业没有什么变化，而面向业务的企业在岗位上会缩减或合并，分工变粗了。

低代码开发平台不仅会影响产业结构和企业员工构成，在探索的过程中还会诞生出一些很好的方法论、框架，带领技术进入下一个潮流。