用人话说，「生产」是从无到有发明人们所须要的物品，能够是实物，也能够是虚构的；软件就是那个被发明的「物品」，从无到有去发明软件就是「软件生产」。
先提了个问——软件生产是膂力密集型劳动还是脑力密集型劳动？
流程
只管细节各不相同，但任何物品的生产流程都可能形象为需要、设计、实现、测验与保护这几个环节，视状况能够进一步简化为需要、实现与保护，并在此基础上周而复始直至产品或厂商的生命完结。
依据行业、畛域等的不同，会在上述几个环节中各自退出一些细分环节。
以我所处的以 Web 相干技术为根底提供软件及服务的行业、畛域为例，以后业内支流的生产流程为——
在接到需要后，要先对其进行剖析，论证是否为伪需要以及概念、逻辑的完整性、严密性，若没问题就进入设计环节，包含产品设计、UI & UX 设计和软件设计。其中，UI & UX 设计也可被认为是产品设计的一部分。
不像单机利用那样只有客户端，当今的应用软件根本都蕴含客户端和服务端两局部，即前端和后端。因而，软件的设计与实现都要同时思考这两局部。
软件设计次要包含软件的结构设计，即软件架构，以及技术选型。在进行结构设计时，要有肯定的前瞻性，具备一些弹性，可能较为轻易地应答将来肯定工夫内的变动。
应该留神的是，软件架构受行业趋势和规定、组织战略目标和客户需要影响，技术选型受软件架构、团队布局和人员素质限度，而不是反过来。
以此为分界线，需要与设计是脑力密集型劳动，剩下的实现、测验与保护根本是膂力密集型劳动。
在这整个流程中，须要辅以行政治理和项目管理伎俩进行资源调节与过程管制，以保障产品如期交付并符合要求。
分工
一般来说，不思考管理人员，软件生产相干的分工是依照生产流程来的，以下就是依照软件生产流程的上下游关系排序的次要分工：
- 产品设计——产品经理、交互设计师；
- 外观设计——UI 设计师；
- 软件开发——软件工程师；
- 软件测试——测试工程师；
- 部署保护——运维工程师。
在不同企业或部门中，依据理论状况，可能会呈现同一岗位的人会参加到多个环节中去，如一家企业或部门没有专门的测试工程师和运维工程师，产品经理、交互设计师和 UI 设计师会去兼做软件测试相干工作，而软件工程师就去做些部署保护的活儿；也可能会在某个环节中细化出更多的岗位，如软件开发这个环节细分出架构师、前端工程师、后端工程师等。
那么，由特定工具或场景所催生的岗位，如 Java 工程师、Go 工程师、微信小程序工程师、H5 工程师等算不算是分工细化呢？我认为不算——这类岗位受企业业务等变动影响太大，易变性高，随时随地会隐没。
影响本人所处岗位稳定性的是解决本人所处环节的问题的能力，而不是本人所用所相熟的工具是什么。如果你是通过「Java 工程师」的身份进的某个企业，某天该企业决定将 Java 全副替换成 Go，你是被动辞职或者等着被解雇，还是学习 Go？
分工细化的前提是流程环节比较复杂，并且因操作规范化水平不够或其余什么起因导致不能自动化，无奈用机器取代人工，因此要拆分出子环节并找到对应的人去解决。
交付
从软件的交付形式上来看有我的项目型软件和产品型软件，会对流程细节和开发心态等方面产生影响。
我的项目型软件相当于一次性交易，须要先招标或通过市场销售人员拉客户，与客户议论具体需要后签合同。进入研发后，大家的心态就是——尽量早日实现，能用就行，可维护性、优雅什么的都靠一边儿去！
做这类软件，会被 deadline 倒逼着从一开始就集中火力，就像晓得本人哪天要死，但在死之前肯定要做完某件 / 些事一样，顶着微小的精神压力尽全力、拼膂力。
以我的项目型软件为主的企业或部门，若是我的项目需要多的话，在一个我的项目做完还没怎么喘息就要进入下一个我的项目，开启对集体来说的恶性循环——精力与精神资源的耗费大于补给，在业余能力上成长甚微——只有我的项目不多、工夫短缺或人员足够这三个条件至多满足一个时才可能终止循环。
产品型软件则绝对更加秉承长期主义，须要继续迭代、不断改进，不像我的项目型软件那样交付完就差不多等于完结了。
这类软件的需要次要是由产品经理来开掘与把控，相比我的项目型软件，大家的心态更偏向于把软件做好，也更在乎各层次设计的美感、可维护性等。
从企业角度来说，产品型软件个别是对外的 XaaS 在线服务；但从部门角度来看，就是对内的中台服务。在这样的企业或部门中，集体在业余上的成长什么的也自不用说，开启良性循环的概率比做我的项目型软件为主的企业或部门更大些。
相较之下，产品型软件的生产是脑力密集型劳动，我的项目型软件的生产则是膂力密集型劳动。
优化
为何要优化？因为——
「降本增效」是人们在生产过程中永恒不变的话题、永远的谋求。
欧雷《聊聊中后盾产研一体化：引子》
除非能找到像虫洞那样进行「跳跃（leap）」的伎俩，让想法刚一呈现就曾经实现，否则优化一件事的极限就是实现这件事所需的最小信息量 / 工作量——
要做成一件事须要固定的信息量 / 工作量，就看这部分信息 / 工作是做到哪里；要做好这件事就得达到这个信息量 / 工作量，少了就做不好，多了就是无用功。
欧雷的想法
然而，这个「最小信息量 / 工作量」只能是理论值，就像从一个地点去另一个地点的理论间隔肯定会大于它们之间的直线间隔一样——影响一件事的因素超过一个时必定会或多或少地做「无用功」。
优化就是针对特定问题在特定场景下从工夫和空间上寻找综合的最优解——像不像算法？就是算法！
生产流程中的需要、设计、实现、测验与保护这几个环节是必须的，就算在某些状况下看起来是打消了某（几）个，但理论并没被打消，只是被转移了。
比方以后企业或部门在生产时没有设计环节，并不是软件生产没有设计这个环节，而是设计这个环节被开源软件提供者或其余上游供应商做掉了。
软件生产的参与者往往有很多人，因而而产生的岗位分工重叠、信息传递失真等会导致做很多「无用功」，造成工夫和空间上的资源节约。
这么一看，优化方向很明确——削减分工的重叠局部，缩小信息传递的环节等——以使面向业务的生产流程进行增员为指标进步生产力。
我感觉「以常识作为全链路的惟一可信起源（Single Source of Truth）」是一种形式，日后会在「聊聊中后盾产研一体化」系列文章中具体论述。
以我短浅的眼光看来，至多近五年支流的分工模式不会有什么变动。但随着低代码开发平台的成熟，分工必然会发生变化。
当初的软件生产，简直还是由一家企业或部门一条龙地从最根本的单元做起（疏忽开源工具），逐步变成残缺的软件产品。若低代码开发平台比拟成熟了，那些面向业务的企业齐全能够在洽购低代码开发平台后裁减大量本来用来开发、保护零碎的人员，只留下不几个基于低代码开发平台配置或开发满足业务需要的性能的人员即可。
这种状况下，面向业务的企业就像那些传统企业一样，人员构成绝大部分是解决业务问题或维持公司失常运行的，只有一个由多数人员组成的 IT 部门负责零碎性能的开发和保护，不须要很高的技术能力。
这样一来，做低代码开发平台的企业就成了面向业务的企业的供应商，那些做 UI 组件或其余基础设施的面向技术的企业又是做低代码开发平台的企业的供应商。
以低代码开发平台的成熟并崛起为契机，产业结构和企业员工形成会发生变化——从产业层面来说，欠缺了从原材料到可销售成品的生产链，分工变细了；从企业员工形成来看，面向技术的企业没有什么变动，而面向业务的企业在岗位上会缩减或合并，分工变粗了。
总结
人是人类流动各种问题的起因，人参加的局部越多，参加的人越多，效率就越低，能耗就越大，应将膂力密集型劳动尽可能「外包」给自动化、智能化的工具或机器去解决，正如所长林超的一期视频里说的那样——
人们在解决了一方面问题的同时，会在另外一方面去制作问题，而后再去解决，如此往返。无论思维、方法论和伎俩如何变，人的本色和需要不会变，因而人类社会的倒退是螺旋回升的——
历史不会重演，但会押韵。
马克·吐温
道、法、术、器，越向后越易变，越不重要。求道，变法，换术，易器。
本文其余浏览地址：集体网站|微信公众号